For those who are using Windows 2008 as server platform and want to debug the Dynamics 2009 AIF… this will help!

We are using AIF WCF web services to communicate between a .NET portal and Dynamics Ax. And while developing we were unable to debug the code running in the Business Connector. Since we were able to do this on other customer sites I started coparing the infrastructure and the only difference was the fact that we were using Windows 2008 instead of Windows 2003…

I followed the usual steps to be able to debug the AIF code which I will elaborate in this post later on, but no success. I contacted the Microsoft support and they soon informed me about the fact that debugging the Business Connector on a Windows 2008 system is indeed a well known issue with for them! So there you have it, problem identified!

Two weeks later I was surprised as the support engineer contacted me about this issue and told me that they had a hot fix developed for this! (The thing was more like a kernel rollup since the kernel build number was already past the KR5 build number)

So to be able to debug, the first thing to do is to install the hot fix known as KB2251040 (I haven’t found this yet on the partner source knowledge base, but for those who need it, you can contact support to request this hot fix)

Installing the update

Run the update provided and you will eventually see the following screen where the installer checks the already installed parts.

Important: This update needs to be installed on all the machines if they are distributed on multiple physical servers. (In our case we updated the AOS / components on one box, and also the Business Connector on the IIS box)

Next the installer will ask you if you want to install the update on all instances of the AOS or select a specific one.

After the installer has finished, you will see the following file versions of the business connector:

There are several other files updated in the serverbin directory and in the clientbin but all should have the 5.0.1500.3076 version number. The list will also be complete when the KB article appears on partner source.

Steps to debug the AIF

Now that we have updated all of the components to work on the Windows 2008 platform, we can start worrying about the debugging itself. Several steps need to be taken into account to be able to debug, so let’s start.

Modify the AIFInboundProcessingService class

Firstly, imho the most important first so we do not forget this. There is method called runAsWrapper that we need to modify so that the runAs statement will not be used to run the message. Modify this so it matches the picture below.

Modify the client configuration

Open the client configuration tool and go to the developer tab. There you can check both checkboxes to enable the breakpoints in the business connector.

Modify the server configuration

Same thing on the server side. On the Application Object Server tab, make sure the checkboxes are enabled and restart the AOS service if needed.

Determine the Dynamics Ax user and enable debug mode for the user

Also very important is to set breakpoint with the right user. The user that runs the business connector will be used for setting breakpoint, etc..
This user will be specified when the logon call is used in the business connector. So make sure you debug with that user credential.

To enable debugging, open a Dynamics Ax 2009 client and set the debug mode to : When breakpoint.

Set the Business connector proxy user to the user you want to debug with everywhere

• On the application pool
• Inside dynamics Ax system services account

Allow the IIS windows service to interact with the desktop

This one is also crucial otherwise the IIS cannot interact with the debugger!

Add the debugging user to the Dynamics Ax Webservice Administrators

Log on to the AOS server with the debug user on the CONSOLE

Use the mstsc /admin command to log on to the AOS on the console session.

Manually start the Dynamics Ax Debugger

To finally start debugging, make sure you have opened an instance of the debugger on the machine where the business connector is running. In my case on the IIS web server. Make sure to run the debugger as Administrator

Today I am working at a customer site and today’s task is to move all objects from the USR layer to the VAR layer. (Don’t ask why but due to licensing we could not work in the VAR layer)
There is already data present, so we cannot just move the objects without further attention.          

There are some solutions to the problem that I’ve stumbled upon on the web (f.e. http://www.axaptapedia.com/Move_DB_objects_to_another_layer ) but these did not do the job entirely.
Some problems that you may encounter and need to be addressed are:          

• System fields that are in the range >= 60000 need to be taken into account
• Long table names will be shortened by the SQL server backend to 30 chars (25 name + the 5 chars long Id of the table) So when changing the Id of a table that has a long name, you also need to rename the table on SQL server to contain the newly obtained ID

As always, there are several ways to travel to Rome but this is what I did. I have created a wizard that can be run before moving the table to collect dictionary data. Then you can move the object to another layer and rerun the wizard again to do the actions needed after moving the object.          

In general, this is what we need to do:          

• Disable the synchronization code to prevent the system from executing a synchronization automatically
• Run the wizard to gather the current dictionary data
• Export the table and delete it from the USR layer
• Import the table in the correct layer
• Run the wizard again to gather the new dictionary data and update the SqlDictionary
• Re-enable the synchronization code and perform synchronization

So let’s start! (By the way: Don’t mind the to-do’s, labels, best practices) because it is working, but will need some polishing )         

Disable synchronization  

First we make an adjustment in the Application class, method DBSynchronize. We just make sure here the code is not executed. This is actually some stupid code and should be replaced with some kind of parameter to be able to enable / disable it.         

 

Now that the system will not synchronize until we make the change undone, we can start messing things up          

 Run the wizard before layer move        

 Before moving the table to another layer, we will gather all the current id’s to be able to lookup some stuff after the move to the other layer.  In the first step you need to specify the layers used and fill in the Pre-layer move option.      

 

Then depending on pre/post layer move, the wizard shows a tab where you can enter tables to process when pre-layer move, or shows the results directly as in the next figure. (After the move, he uses the tables he finds in the log table)     

 

Then the wizard gathers everything and shows the data. In this case the new ids are empty because we are processing before the move. Just click next and finish the wizard.       

Exporting the objects  

Now that we have collected the ids we need to remember, we can export the tables (without id’s and labels) and delete the objects.       

Importing the objects  

After deleting the objects in the USR layer, we can import them in the VAR layer. This is a normal import so nothing special here.          

Run the wizard post move and update the SqlDictionary  

Now that the table is in the correct layer with the new ids generated, we need to run the wizard again to run some scripts on the SQLDictionary system table. The SQLDictionary table contains a representation of what Dynamics Ax thinks is present in the SQL database. So this table is used by the kernel to determine whether a alter table or create table statement is needed at the database backend side. 

To make sure the kernel will not try to create tables that already exist in the database with that name, we have to make sure the old id’s are replaced by the new ones. Same thing for field id’s…       

So we run the wizard again and specify the post-layer move option.       

 

Then we will not be prompted to specify tables but the wizard will process the same tables / fields as in the pre-move run of the wizard.
We get to see what will be adjusted in the SQLDictionary table in the next step.       

 

 So we have the old id’s to look for in the SQlDictionary table and the new id’s to replace them. So let’s click next and let the wizard do the processing.
This will result in the dictionary to contain the right id’s and prevent the table to be dropped and recreated by SQL server and thus keeping all the data.       

 

Also note that the wizard takes care of long names that are shortened by SQL. The id is appended to the shortened table name so there is also a renaming needed at the backend side.      

So there you have it! Please feel free to comment on this.      

Caution: Doing stuff like this isn’t without any danger. The synchronization process does tons of stuff we (as non kernel developers) don’t know about so it might be possible there are some special cases in which this could be going wrong.
I try to process the tables in small bunches and take backups in the process so that I don’t have to run it for everything at once and en up halfway with some broken link in the SQLDictionary.      

Axaptapedia link…
http://www.axaptapedia.com/Moving_Table_between_layers 

Download…
http://www.ksaelen.be/DynamicsAxXpo/SharedProject_KeSae_TableLayerMove.xpo