stephenmann: Dynamics AX Retail CDX (a good example of how not to integrate applications)

[Blog bot]

Источник: http://www.stephenmann.net/single-po...e-applications
==============

Retail CDX (commerce data exchange) is the interface that Dynamics AX uses to send and receive information to Retail stores running AX Retail POS.
Retail POS is a .net application that runs at the stores and can interface to opos hardware such as receipt printers, cash drawers, eftpos machines and dual displays.  It makes use of a SQL database that runs on a server located at the store.  Parts of the Retail POS application can be modified using the Retail SDK which contains the source code for most modules.  Being a .net application it does not have any support for x++ code, data dictionary, table relations, labels, AX database synchronization or the AX query engine so the code can be much more cumbersome and will use a lot of native SQL and hardcoded enums, labels, table relations and business logic.  Also each time the Retail POS application code is changed the application will need to be reinstalled for all the retail stores, unlike the AX client which would automatically get the latest code from the AOS.  It feels a bit like Microsoft may have gone down the wrong path with the Retail POS development.
There are two channels of communication between RetailPOS at the store and Dynamics AX at the Head Office.
Asynccommunication will synchronize specific tables between the store database and head office database. Related tables are grouped together into scheduler jobs. Scheduler jobs are run at different intervals depending on how time critical the information is.  SQL change tracking is used to identify any new or modified records in the databases and only the changes will be synchronized.  The tables are only synchronized in one direction, either from store to head office, or from head office to the store.
Real-timecommunication allows retail pos to fetch or update information at head office, this can also make use of the dynamics ax business logic at head office. To use the functions that require realtime at RetailPOS the store must have a reliable internet connection.

Here is a few examples of how the data is synchronized:
Asyncpush: Head office updates future dated prices and discounts for products.  A batch job for syncing product information is scheduled to run nightly in AX. This uses SQL change tracking to identify the new pricing records and packages up the data to be sent to the store.
Asyncpull: Head office has a batch job running every hour that requests retail sales transactions from the store.  The async client running at the store will see that this information was requested by AX and use Replication Counters to identify the new transactions, these are packaged up and sent to AX to be imported into the database.
Realtime:  Worker selects a customer to view their balance.  Realtime service call is made to AX in Head Office to get customer balance.  Balance is displayed on screen.
Realtime & async:  Worker at pos updates customer address, realtime service call is made to AX to update address in head office. If the call is successful, pos will also update the address in its own database.  A batch job for syncing customer information will detect the changed address in head office and it will be packaged up and sent to RetailPos. The async client at the store will overwrite the customer address information with what is in head office, since the address in head office is the same the record will be overwritten with the exact same data.

Real-time:
Real-time web service can be installed using the Dynamics AX installer or via powershell scripts.  There is a bug with windows 10 where the powershell script must be modified to get it to complete.  The realtime service setup creates and configures a website in IIS.  When installing you will be prompted for a SSL certificate thumbprint, this need to be a valid certificate for the address that the realtime service is running on.  Also you will need to provide the credentials for the AppPool user for the website. IIS will run the .net business connector as this user to connect to AX so the user must be in AX.  The .net business connector will call methods in the RetailTransactionService- classes in AX.
(Refer tohttps://technet.microsoft.com/en-us/.../hh575229.aspx)
POS will need to know the web address of the realtime service to use it.  This is configured in AX throughRetail->Setup->POS->Retail Scheduler->Channel integration->Realtime service profiles.
There are already a few sites describing the settings in this screen so I won’t do that.  Just make sure the passphrase is filled in, it can be anything but if left blank then the realtime will not work.https://technet.microsoft.com/en-us/library/hh580631.aspx
The information in this screen is synced down to pos through the async service.  Run the 1070 (channel configuration) or 1090 jobs to push these settings to the pos database.
Realtime not working? Make sure to check in the windows event viewer for error details.
Async:
There is a few different components here…
Head office message databaseClient message databaseFile shareRetailPos databaseAsync server IIS webserviceAsync client serviceUtilities (AsyncClientConfigurationUtility, RetailDatabaseUtility, DDPackView)
Push Jobs (AX -> POS)
For the push jobs (head office to store) AX will have a batch job which periodically executes a specified distribution schedule (eg. 1010 – customers).  This will identify a list of all the tables that need to be synced for the job (fromRetailConnScheduler*tables).  For each table it will grab some pre-generated SQL from theRetailCDXChangeTrackingSQLtable, this SQL is used along with the last SQL change tracking version number to identify the records that have changed since the last sync.
The identified records are further filtered down to store specific data through the Table Distrubution XML in the retail channel schema. The XML describes how all the tables link back to the RetailChannelTable. This is useful in cases such as when we only want to sync customers that are linked to the store through the stores address book relation, rather than sending all customers data to all stores.  Editing the XML is very manual and a mistake could wipe out all the data from a table at the POS databases, it would have been nice if they created a form with a tree view of the tables and just used the AOT table relations.
Custom fields and tables that also need to be synced to POS can be defined in the RetailCDXSeedData_AX63 class (or a class that extends this).  The class contains a list of all the Tables, Fields and which scheduler job they belong to.
Once the table distribution XML or channel schema class has been modified the RetailCDXSeedData_AX63 needs to be run to generate additional classes that are used during retail sync, this only needs to happen when the schema changes.  The RetailCDXChannelSpecificData_AX63 class will be generated which contains RecordSet based operations for filtering the data down to the store level based on the table distribution XML.
The RetailCDXXmlDataOutput_AX63 class is also generated which contains while select statements to read the data and generate the XML.
The generated XML is grouped with other files, compressed to .rpf and saved to a fileshare defined in the ‘Working folders’ setup in AX. The filename and status is then written to the AsyncServerHeadOffice database directly from AX.  The xml from the .rpf files can be extracted by using the DDPackView tool which is included when installing the retail components.
Every two minutes the Async clients at the stores will connect to the Async server website which also has a connection to the AsyncServerHeadOffice database.  The async server reads the AsyncServerHeadOfficedatabase and identifies that there is a new file to be sent and reads the file from the fileshare sending it to the async client.
The async client will write this into the AsyncClientMessage database and then update the data in the RetailPOS database.  This can either be a delta update where records are inserted, updated and deleted; or a full update where the entire table is deleted and then repopulated from the XML.  The async client connects to the async server again to write back the status of the update.  This is stored in the AsyncServerHeadOffice database and can be viewed in AX in the download sessions form.
Pull Jobs (POS -> AX)
For the pull jobs there is also a batch job scheduled in AX.  This writes a record to the AsyncServerHeadOffice database requesting the data from POS.  When the async client connects to the Async server website it identifies that the data has been requested, also packages the data into RPF files and sends it to the AsyncServer. The file is written into the fileshare where it is read and applied to the database by AX.
All pull tables in the POS database have a field calledReplicationCounterFromOriginwhich is an auto-incremented number, every new record gets a new number.  There is a table[RetailPOS].[crt].[TableReplicationLog]that stores a list of all tables that need to upload data. This table has a fieldFILTERMAX, which is a reference to the above[ReplicationCounterFromOrigin]field.FILTERMAXis always updated to indicate the last transaction uploaded.
That means any new records created in store DB will get a value in REPLICATIONCOUNTERFROMORIGIN greater than the one currently set in FILTERMAX. Every time the pull job runs, it checks REPLICATIONCOUNTERFROMORIGIN in all tables against the FILTERMAX value for those tables and sees if there are any new transactions that need to be uploaded, using the Async client service and sets the FILTERMAX values for the tables to the last uploaded value.(thanks to Aman for this part)
Happy times supporting all this!
Notes:
If you change something like the length of an extended data type in AX you will need to make sure the field length for all the related fields in the POS database are also updated otherwise you can get sync errors.  There are scripts that can be used to identify differences between the two database but they are not always accurate.Updates to the POS database schema need to be scripted in SQL and can be added to the create database utility.  Keeping the POS version and database schema up to date can be painful if you have thousands of stores.  AX does have some support for running different schemas for different stores during major upgrades.Some things such as POS layouts are only synced in one direction, so if the user changes their screen layout, then the Registers job is run, the users layout will be overwritten.The table names and field names in the POS database will match what is in AX. Where AX has extended tables which are stored only as a single table in the AX database, these will be split out into the individual tables when synced to the POS database.



Источник: http://www.stephenmann.net/single-po...e-applications