I Promised Myself ........

I promised myself when I started this blog that I would not use it as a soap box to expel the evil spirits of the day, but today I am going to make an exception.

So by now most of you are aware that I am implementing Dynamics AX 2009 and had decided early on in the project to use the Application Integration Framework (AIF) to interface to and from the system. I attended the Microsoft Convergence Conference in Orlando in March this year and after hearing Michael Merz speak, it was in the bag.

Back home during early negotiations with Microsoft and the suggested "Partner" we emphasized this point over and over. At no point does anyone stop me and say "but nobody here in South Africa knows how to use the AIF and certainly not with the BizTalk Adapter". So come time to install the AIF and the BizTalk Adapter our Partner's have no experienced skills base and everyone spins out trying to read the outdated documentation. In short it was not properly configured by the time my BizTalk consultant walked on site to write the interfaces.

It took us several working days to get the BizTalk Adapter to successfully pass XML documents into AX and get a return receipt. How that was done is just another whole story on its own. Once our BizTalk guru has documented the "undocumented" on his blog I will post a reference to it.

So now it works. We then start to pile on the volumes of our daily journals into the test DAX environment and it falls over. We eventually work out that if we chunk the data and send in lots of small journals it works. Our average daily journals into our current system from our LOB systems can vary from about 3000-9000 lines. We had to break them down to roughly 1000 lines each for the AIF to consume without rolling over on its back. To add to this my developer has written a cracker of an interface to bring in our payroll data as journals into DAX. This journal can be up to 6000 lines long and it loads perfectly but when he tried to validate it, it fell over with an out of memory error. In fact quite similar to the error that we were experiencing from the AIF side.

Well if you just imagine there was much wailing and gnashing of teeth. Here we had spent millions on an "Enterprise" solution and it fell over on a few thousand line journal. I sat and contemplated how I was going to tell our Executive Committee on Friday that I had spent millions on the software, had consultants on site who charged like wounded buffalo, and the system was not capable of processing what our current system could. A rusty bread knife and the thought of me slowly perishing in a pool of my own blood suddenly looked appealing. Anyway this passed quickly as I banged out out my plight on the support site with Microsoft.

Well friends it looks like AX has a default install that pretty much matches itself up with something like, say, Quickbooks. ie, it looks good but don't ask it to handle volumes. It would appear that the default size for memory allocation in the AOS is set to 10 MB at installation. To change this default buffer size requires changes in the AOS Server registry and a new entry in the AXC File. Another issue is a restriction on the RPC which also requires a registry setting to increase the MaxRpcSize. One can also increase the maxbuffersize of the client.

Now I have to ask the question, how can one market and sell Enterprise software and then install it with such limitations? I have gone through all the documentation provided with the product and also anything else that I have gleaned from the net and nowhere can I find reference to these settings.

Bad form Microsoft.

- Paul Steynberg