It seems a bit hypocritical of me to use the word Matador when i really hate bullfighting and the cruelty that goes with it. But what are we if we don’t push the limits on all that we live in. Living on the fringe of any values we hold is exciting and necessary sometimes cause it allows us to see across and still resist the urge and hold true to our values.
Anyway this article is not to publish my philosophical ideas, rather it is simply to share my experiences in how to shape an AX solution (including interfaces).
I have been in AX for almost a year and half now but i have had a chance to work on the most wonderful project that any AX technical person would love to work on. Wonderful as in so many different things to experiment including AX 2012, retail implementation, around 40-50 interfaces, changes to core posting engine, customized settlement, extensive changes to retail sales order posting and more. It has come at a cost though, the project has been extremely stressful, literally consuming all of my time. It has also tested the limits of my consulting skill to deal with the client and manage team.
The project was a retail implementation of AX and involved extensive integration between AX and retail store system. We had to pull in the data from the stores into AX. It included posting sales orders, purchase order packing slip, invoicing them, receive payments, post and settle payments and a lot more, pretty much everything would have to be done through interfaces.
The challenge was how to pull in such a volume of data and reliably post this in AX? Do we go the route of AIF services? How do we ensure that all transactions are getting processed and how do we track errors and reprocess those that have failed? Can AIF alone do it? What are the other options? AIF integration typically revolves around using XML documents, also AIF integration allows disparate systems to connect by contracts. In this case XML becomes the contract. However in many cases the existing data is already in a database and clients would typically like to send this volume of data through direct tables. Maybe AIF is not the solution in such cases, maybe the solution is to move data into AX staging tables and then write simple X++ classes that can be batch scheduled. AX is a bit lacking in this area and there are issues around batch posting. However weighing the odds this seems like a better option, which we took but leveraged the Retail framework in an innovative way.
A few of the issues we faced were working around numerous AX bugs in Retail and getting that beast of engine to work. Others issues we continue to face after going live is Number sequences. Due to the volume of transactions, we constantly run into number sequence exceeded errors. This has a cascading effect in that even if one number sequence is exceeded all posting stops and hence all interfaces start failing. If i have had a bit more experience i would not have let this happen, but the functional team went for pretty and not functional! Other issues we face around infrastructure sizing and database sizing and maintenance. Having a DBA in place during well before implementation is critical.
Another challenge we faced was around the volume of data we have to send out. Setting up AX jobs to do this really slows down the system. There was a need to interface out all customers, products, open items, aging snapshot for all legal entities. It becomes increasingly difficult to ensure timely completion of these jobs in AX every day. Instead we took the route of SQL jobs to push the data out. Infact we wrote SQL jobs to update aging snapshot within AX!
There is so much to say but I will reserve it for another post.
