Monday, 26 August 2013

Model store deployment using batch files

One important step of AX development is deploying code to production. In AX2012 it is recommended by Microsoft to do so by import of model store. The frequency of this task varies from customer to customer. As we use agile development methodology in our organisation so we deploy code to production frequently.

The deployment cycle is weekly/bi-weekly depending on the requirement/urgency/severity of any bugs discovered and fixed etc. With this frequency we decided to semi-automate the process so that the person performing the task don't have to manually issue the commands and make the whole process smooth. Link to the scripts are at the end of the post.

The folder contains the following files

The process consists of 7 steps, two configuration files and two folders containing utility batch files. Lets look at them one by one.

The folder contains the following windows registry files

The first file changes the AOS configuration to a configuration named "Maintenance" and second one changes back to Original. The next two files do the same thing for the client configuration. This is done by merging these files in windows registry. Step 3 & 5 use these files.

This folder contains the files that either starts or stops a windows service on a server remotely.

Step 1 & 6 uses these files.

This file contain the details of the services that needs to be stopped/started as part of the import process. The file format is


Each server is on a new line. The file uses : as delimiter. The first field is used for ordering only. The second field is Server Name and the third is Service Name. These don't need to be AOS services only. In fact any service can be stopped/started.

This file contains the settings for the import process. The contents of these files are


Step 0 & 2 uses this file.

Step 0:
This step import the model store in a temporary schema. The reason this step is zero is that it can be performed before the actual import task is carried out. The script reads the setting file cImportExportConfig, presents the user all the details and asks to enter the choice as shown below

If the user enters 1. The batch file then imports the model store into the temporary schema. A log file is generated in the bin folder of the AOS.

Step 1:
This step stops all the services specified in the file cAOSServerConfig as shown below

The scripts stops each service independently and in parallel. The script stops the service and then waits until the service is stopped after which it displays the confirmation. In above case if 4 is entered, 3 different batch process runs each stopping the individual service.

Step 2:
This step applies the model store to the actual schema and in the process creates a log file in bin folder of the AOS as shown below

Step 3:
This step changes the AOS configuration to maintenance. The same is done for the Client configuration. These configuration should already exist. If the configuration names are different than these can be changed in the files by using notepad.

Step 4:
This step just start the AX Client to perform additional step (like synchronisation, report deployment etc.). These step are not automated but can be done.

Step 5:
 This step changes the AOS and Client configuration back to original.

Step 6:
This step uses the file cAOSServerConfig  and starts the services as shown below.

As with the stop script, this will start the services in parallel and wait for the service to start before displaying the confirmation.

Note: The scripts should be tested in a test environment before using them in production. The user should have all the necessary permission to perform different task remotely on a server.

This posting is provided "AS IS" with no warranties. Use code at your own risk.

Friday, 2 August 2013

WCF worker session inactivity timeout

One of the new features of Dynamics AX2012 was introduction of WCF services. Our organisation's current website uses BC.Net to integrate with AX. We are in the process of porting it to WCF.

When the customers are placing orders on our website one of the step is to show the product they regularly buy combined with the most popular products. To provide a fast experience to the customers we decided to use multiple simultaneous calls to AX to get the product details along with the stock check already done on these products. As these customers are external to our organisation hence we create these customers as Claim based users in AX (another new feature in AX2012) and apply xds security policy to filter out only the data that a particular customer is allowed to see.

This worked very well until we noticed that these simultaneous calls, for a customer, results in creation of multiple worker sessions in AX. AOS does reuses these sessions if they are free. If the session is busy serving a request AOS creates another session. In our case the duration of each request for an item, with its details, is around 200 milliseconds, so a page with 100 items resulted in 10-15 worker sessions. What we observed was that these sessions lasted for 30 minutes despite the request being completed in milliseconds.

This was a potential problem for us. With a customer base of more than 70 thousand customers, the AOSs could potentially be flooded with sessions that are not being used and could hit the upper limit of maximum concurrent sessions on an AOS very quickly (by default set at 2000, but can be changed). Once that limit is hit AOS refuses any more connection request and throws an error.

We tried to find whether this 30 minute inactivity time out can be changed to a value which is more convenient for us but failed to find any such setting. So we contacted Microsoft and they recommended the following change. To configure the WCF worker session inactivity time out on an AOS add the line

 <add key="SessionPoolFlushSeconds" value="180" />

to the <appSettings> section of file Ax32Serv.exe.config located at

C:\Program Files\Microsoft Dynamics AX\60\Server\<AOS NAME>\bin

A restart of AOS is required for the change to take effect. After the change the file should look similar to

As can be seen from the file we set it to clean up after 3 minutes. The clean up happens 3 minutes after the time the worker session is last used. So if a worker session is first created at 12:00 and then reused at 12:02, it will be cleaned after 12:05.

Note: Please be very cautious in making this change. Proper testing should be done before deploying the change to the production AOS(s). Setting a very low value could result in poor performance as AOS will have to recreate the session which is a time consuming task.

This posting is provided "AS IS" with no warranties. Use code at your own risk.