In this blog post I will explain how on user interactions are handled by the product configuration module for Microsoft Dynamics AX 2012 on the Enterprise portal.
The figure above, is a high level illustration of how user interactions in general are processed on the Enterprise Portal (EP) for Microsoft Dynamics AX 2012. The clients access the AOS through EP, which is a web implementation built on top of Microsoft Sharepoint, hosted on a web server (IIS). The communication between EP and the AOS is synchronous using the .NET Business Connector RPC call. Each RPC call must be completed and returned, before http request timeout is exceed on the IIS.
To understand what implications the above has, when using the Product configuration module, we will go through the sequence of events, which take place when the user loads a configuration model and assigns a value to an attribute.The above illustrates the sequence of loading a configuration model and assigning an attribute a value on the Enterprise portal.
Loading a configuration model
When the user wants to configure a product, e.g. from a sales order, the requests will be handled by EP. The EPPCConfigurator web control will be loaded, inside the web control a proxy Instance of the PCEnterprisePortalMain class is created. This proxy is used to interact with the AOS Product configuration logic.
On the AOS, the XML representation for the specific configuration model is retrieved from the database. Then the XML string is passed as argument to Product Configuration Server API, which unlike the Client API is design to support synchronous execution. In the creation of the ProductConfigurationServer instance, the XML is parsed and supporting data structures are created, just like on the Windows client implementation.
Once the data structures have been created, the configurator instance can start processing the constraints and calculations of the configuration model. Unlike the Windows client however, the processing on EP needs to respect a fixed time limit, in order not to cause a timeout on the web server.
Another difference between the Windows client an EP is the way the model is being processed. The EP implementation will attempt populate all visible enumeration and Boolean attributes. This is the equivalent of opening all the visible attribute controls on the active component in the form, and letting the configurator deduce feasibility of the values of each attribute.
The more attributes that are visible, the less time that is available to process each attribute. For components with over 20 enumeration and boolean attributes, it can happen that there is not enough time to process the feasibility of all values within the domain of the attribute.
Assigning values to attributes
When the user makes an assignment to an attribute, the web form is then posted back to EP and a request to assign the attribute is made on to the AOS. On the AOS, each call from EP executes in its own context, this implies that a new instance of the configurator is created. This instance must again parse the XML representation of the configuration model, before being able to process the user assignment. After this, the instance is disposed and a new one is created to process the assignment , same as before.
The main problem can be seen from the diagram in Figure 2, is the activation line of the ProductConfigurationServer object. Unlike the Windows client implementation , the configurator instance is not kept alive throughout the configuration session. The synchronous execution combined with the time limitation is the main limiting factor, which forces us to create and dispose instances of the configurator for each request.
The consequence of this is that the EP implementation of the configuration module, is not able to deliver a user experience which is similar to that of the Windows client for models of medium to high complexity.
Please keep this in mind when considering implementations of the Product Configuration module on Enterprise Portal for Microsoft Dynamics AX 2012.