Dynamics AX Retail 3rd party POS and E-commerce integration – AIF vs CDX

The theory…

Generically speaking there are two types of interfacing:

1. Batch processing
2. Transactional information exchange

Batch processing is used to periodically ship large data sets from one system to the other. In the context of Retail/sales channels, this typically involves shipping item master data and transactions. Shipping this type of data is often based on a non-real time recurrent schedule. As the receiving system has no clue when data is to be processed, batch processing always involves two separate interface flows: export data from system A and import from data in system B.

Transactional information exchange typically occurs when timing is important. For example, when orders have to claim exclusive stock in order to avoid selling air. Therefore, transactional information exchange is triggered by a specific business event which leads to exchange of only a slim set of data. As the information exchange is direct, the information exchange happens in a request/response manner between two systems. The information exchange can happen for 2 purposes:

1. System A requests system B to deliver information. Response: data or error.
2. System A requests system B to perform a task. Response: result or error.

Although batch processing can be supported by Service Oriented Architectures (SOA) as shown in the picture below, the major argument against this is performance. So roughly speaking, job scheduler solutions support batch processing where SOA is typically designed for transaction information exchange.

Source: Ashok Nare

Many people often ask me “why AX has so many integration tools”. But bottom line AX offers a generic integration framework for each of the two interface types:

• Data Import Export Framework (DIXF) for batch processing.
• Application Integration Framework (AIF) for service orientation.

For Retail, AX offers a specific framework which is typically designed to support the data exchange and general communication between the native AX sales channels (AX POS and online store) and AX backend: Commerce Data Exchange (CDX). Beside this framework the Retail stack offers Commerce Run Time (CRT) which is a service layer for the channel database. But due to the limited number of services currently available within CRT, this framework is left aside for this blog.

Retail CDX supports both the batch processing and service orientation types of interfacing with the following two components:

• Retail scheduler supports batch processing
• Real time service (RTS) supports service orientation.

Retail scheduler

Real time service

AIF vs CDX…

Now back to the comment in my introduction why I would leverage CDX and not the commonly used AIF framework for Retail 3rd party integration. First, let’s list the top 3 high level requirements which we often hear from our (enterprise) Retail customers:

And let’s take the following requirements as examples on the functional side:

And now let’s confront AIF and CDX with these requirements based on out-of-the-box capabilities:

To wrap up

In almost all real-life Dynamics AX Retail/3rd party integrations, AIF will involve a high level of customization which in turn will impose disproportional project risks. On the other hand, CDX lacks middleware abilities, but this will often also apply for AIF.

The requirements listed above are just a small grasp of the complete list of requirements we face in real-life Dynamics AX Retail/3rd party integrations. Keep your own list aside when we dive into the details of a CDX based solution in my following blogs regarding this topic.

Happy DAX’ing!
Patrick

Het bericht Dynamics AX Retail 3rd party POS and E-commerce integration – AIF vs CDX verscheen eerst op Patrick Mouwen.