{"id":4512,"date":"2015-10-18T21:30:00","date_gmt":"2015-10-18T21:30:00","guid":{"rendered":"https:\/\/patrickmouwen.com\/?p=4512"},"modified":"2024-01-26T11:56:15","modified_gmt":"2024-01-26T11:56:15","slug":"dynamics-ax-retail-3rd-party-integration-solution-based-on-cdx-biztalk","status":"publish","type":"post","link":"https:\/\/patrickmouwen.com\/technicalint\/dynamics-ax-retail-3rd-party-integration-solution-based-on-cdx-biztalk\/","title":{"rendered":"Dynamics AX Retail 3rd party POS and E-commerce integration – Solution Design"},"content":{"rendered":"

So here’s the challenge\u2026 we have Retail CDX up-and-running\u2026 how do we hook up any middleware to integrate with 3rd party POS systems, E-commerce and other sales channels<\/em>?<\/span><\/p>\n

Hmmm\u2026 let me add one nuance here which we might overlook: how do we hook up middleware without touching the integrity<\/em><\/span> of Retail CDX?<\/p>\n

In order to answer this question I think it’s good to shortly refresh our minds about Retail CDX. Then we\u2019ll take a look at my solution for both the batch processing as well as transactional types of interfacing.
\n<\/p>\n

Standard AX\/Retail CDX<\/h2>\n

Dynamics AX Retail CDX builds upon the principle that data should efficiently be distributed to decentral sales systems like POS systems. This efficiency should maximize data actuality in the sales system, even in low bandwidth environments and even when large datasets (for example products) are exchanged. This principle is relevant as a sales system should have the highest possible uptime and therefore should never be directly dependent on interfaces with central systems for its day-to-day operations. Further, Retail CDX is designed for enterprise environments where multiple sales systems are to be served from 1 or multiple AX instances with a variety of time zones, currencies, local tax requirements etc. Keep this in mind when looking at CDX overview picture below which only shows a 1 AX instance\/1 sales channel situation.<\/p>\n

\"Standard<\/a>So what exactly is the flow of things within the CDX landscape<\/em>?<\/span>
\nFor the batch processing side of the landscape, it’s basically all about the AX database, channel database and two ‘helpers’ to ship the data over between the two databases: a central helper (Async server<\/strong>; HQ side) and a local helper (Async client<\/strong>; channel side). The helpers only do something when they receive instructions. After receiving instructions, they do their job and write a standardized report on their job (meta data) back into their own meta databases. In addition, the local helper also reports his meta data to the central server helper, so all local meta data about everything happening in the CDX landscape can be synched back into AX by the Retail > Periodic > Data distribution > Process status messages<\/strong> batch job.<\/p>\n

To be more precise:<\/p>\n

    \n
  1. AX hands over an instruction to download information to the central helper.<\/li>\n
  2. The central helper contacts the AOS which is the gateway to the AX database , downloads the required data, serializes that data into XML files, wraps these XML files into 1 binary file<\/strong> and outputs that file to a working folder which was configured in AX and synched to the central helper’s interface meta database as part of the CDX setup.<\/li>\n
  3. The local helper periodically requests the central helper if there any new instructions to be executed. The frequency for this request is defined in the Async server profile<\/strong> configuration in AX. In case of any data to be shipped, the central helper responds with a download instruction including a reference to the working folders. The local helper then writes this instruction into its interface meta database, executes the instruction (downloads the binary file), unpackages the binary file into XML files, de-serializes the XML files, injects the content of the files into the channel database, writes meta data about this operation into the interface meta database and reports the same information to the central helper (which the central helper writes into its own interface meta database).<\/li>\n<\/ol>\n

    Hooking up middleware: batch processing (non-real time)<\/h2>\n

    So the actual transport of data between AX and the channel databases is done by XML files?<\/em><\/span>
    \nYES – let’s take a short look into those files (note: you can use the tool DDPACKVIEW for this) – the example here is the 1000 scheduler job for currencies:
    \n    \"CDX<\/a>As you can see the binary ‘package’ contains 1 header XML file and multiple XML files with data. The header XML files indicates which XML files containing data (‘data files’) are attached in the binary package and which operations should take place for the different data files (delete or insert\/update). The data files ‘just’ contains the data to be deleted or inserted\/updated:<\/p>\n

    \"CDX<\/a>As you can conclude from the “ax.” prefix of the tables, the files and data 1:1 reflect the target Retail channel database schema and data in AX, which is recognizable from the RecId<\/strong> value for the currency table. This is because we picked the AX 2012 R3 Retail channel schema for this example, where channel database schema and AX database schema are perfectly matched.<\/p>\n

    So why wouldn’t we just skip the channel database in the architecture and let middleware intercept and process the binary file with XML files?<\/em><\/span>
    \nI didn’t choose that path for the following reasons:<\/p>\n