Say we have non-Retail B2B sales and B2C weborders in 1 company. We sell the same items through these channels. We expect the financial dimension values for the same financial dimensions to appear on our order lines but… they differ between these scenarios… HUH?
And at invoicing we get stuck (posting is cancelled) as in the B2C scenario we miss a mandatory financial dimension value CostCenter… ARGGGGG!
With the ongoing hunt for implementing ‘omnichannel strategies’ by Retail companies and the booming Microsoft Dynamics AX market, there must be a huge demand for integrating Microsoft Dynamics AX Retail with 3rd party POS and 3rd party E-commerce platforms. But when I google the internet for keywords like “AX 2012”, “Integration”, “3rd party”, “POS” and “E-commerce”, there are not too many hits. And if I find any hits, discussions quickly seem to head for the same solution: AIF (Application Integration Framework).
In my vision leveraging AIF in the Dynamics AX Retail area is a missed opportunity. To prove this and to provide more information regarding Dynamics AX Retail/3rd party integration in general, I’ve decided to write a series of blogs regarding this topic. In this blog post you can find the solution which I’ve recently implemented for a globally operating Retailer based on: Standard AX Retail CDX (Commerce Data Exchange). Here’s a picture of the entire architecture as described in the blog.
So here’s the challenge… we have Retail CDX up-and-running… how do we hook up any middleware to integrate with 3rd party POS systems, E-commerce and other sales channels?
Hmmm… let me add one nuance here which we might overlook: how do we hook up middleware without touching the integrity of Retail CDX?
In order to answer this question I think it’s good to shortly refresh our minds about Retail CDX. Then we’ll take a look at my solution for both the batch processing as well as transactional types of interfacing.
In my main blog post regarding Dynamics AX Retail 3rd party sales channel integration I presented the mechanism to trigger BizTalk to take action after an AX scheduler job run. In this blog I’ll provide some more details on this particular topic. Let me first explain how the change tracking mechanism is leveraged on AX HQ side and let’s then take a closer look on how change tracking can be leveraged on the channel database and Async client database for use by middleware like Microsoft BizTalk.
In my main blog post regarding Dynamics AX Retail/3rd party integration I mentioned leveraging Real Time Service to allow middleware (like Microsoft BizTalk) and 3rd party systems to report to AX on the results of their actions. As the meta data is written into the standard Dynamics AX Retail download sessions and upload sessions forms, these forms will now serve system administrators to have visibility and control even beyond their the Dynamics AX Retail CDX landscape (CDX -> see rectangle in the middle, beyond CDX -> bottom rectangle):
Some people hate it.. some people cherish it as a means to eternalize their brilliant designs… DOCUMENTING. One way or the other, in the bigger projects you can easily fill up a local library with all the paper produced. That’s why a good solution design is crucial in these projects. If such a design covers 1 system like AX, it’s easier to come to a holistic view on the desired solution. But what if your solution spans across multiple systems, all requiring some installation, configuration and customization. How do you keep the overview without getting lost in the details? For this situation your solution design needs an extra helper: the UML sequence diagram: