In this blog post I will elaborate on the processing of configuration models in Microsoft Dynamics AX 2012 R2 and R3.
Figure 1
Client 1 loads a configuration model using an RPC call to the AOS to retrieve an XML representation of the configuration model. After this the processing of the configuration session happens on the client.
When Client 2 wants to load a configuration model, it goes through the same process as Client 1, by retrieving its own XML representation of the configuration model, which it wants to load. Then processing of this model happens solely on Client 2. In this way processing is distributed on the hardware of the different clients.
However, the reality for many of our customers and partners is a bit different to the picture shown Figure 1.
Figure 2
The setup in Figure 2 should be more familiar to those of you who have experience with Microsoft Dynamics AX 2012. Instead of having fat clients as in Figure 1, the users are instead connecting to the Dynamics AX windows client, using a remote desktop session, set up on a Windows server running Terminal services.
Thus when Client 1 wants to load a configuration model, it happens via the Terminal service, which is then retrieving the XML representation of the configuration model from the AOS. The processing of the configuration session then happens in the context of the remote desktop session, which is on the host of the terminal services.
The same thing repeats itself when Client 2 wants to load a configuration model. The difference between this and the previous setup is, that processing for both configuration sessions are now centralized on the host of Terminal services. This processing includes not only the processing of the underlying configuration model, but also the processing related to handling the rendering of the UI.
When we look at what is happening at a lower level, with more details, the picture looks like this:
Figure 3
The diagram in Figure 3 shows what happens when the XML representation of the configuration model has already been retrieved from the AOS. From the Xpp client it is then passed on to the Product Configuration .NET component crossing the CLR interop. In the loading phase of the configuration model inside the .NET component, the following action are executed:
- Parsing the XML representation of the configuration model
- Creation of supporting data structures
After these processes the .NET component starts to process the loaded model and then starts to issue events whenever it is able to deduce that an attribute must take on a certain value. These events are send back to the Xpp client which updates the page accordingly.
At some point the user will want to accept the configuration and this is done by pressing the OK button on the dialog. When this happens a method is invoked on the .NET component, which aborts any running task, and starts a new task which verifies whether the configuration is complete. The definition of a complete configuration is that all mandatory attributes have been assigned a value.
If the verification fails in the first attempt, the configurator will issue a new task to attempt to deduce any unassigned mandatory attributes. In the illustrated example, the configurator is not able to deduce all mandatory attributes, and so a message will be shown that informs the user that additional assignments are required. The user must then assign values to the remaining mandatory attributes. Here the user makes a new assignment and then presses the Ok button again, to complete the configuration. This time the verification passes as all mandatory attributes now have a value.
An important thing to notice is that the configurator instance is active or ‘alive’ throughout the configuration session. As you may know, the .NET configuration component uses a background thread to process the configuration model without locking the UI. In this way the configurator is always able to act on new user input.