Commerce Data Exchange best practices
This topic is intended for people who implement functionality that is related to data synchronization (Commerce Data Exchange [CDX]) in a Microsoft Dynamics 365 Commerce environment. It gives best practices advice for implementations.
Proper data configuration and data synchronization are crucial to correctly functioning implementation. Regardless of business requirements, IT infrastructure, and overall preparedness, if data isn't correctly synchronized, the whole environment is effectively useless. Therefore, a top priority is to understand what is required to configure, generate, synchronize, and verify data across the full implementation from Commerce headquarters through the Commerce Scale Unit to the brick-and-mortar stores that use Modern POS with an offline database.
Before you go through this topic, it's important that you understand the concepts of a channel (store), registers and devices, and the Modern POS offline database. Therefore, we recommend that you review some of the resources at the end of this topic, such as the Device management implementation guide and the overview of the Commerce architecture.
The main content of this topic is organized into tables, where the first column includes lists of tag-like "associated areas" to help you more quickly find best practices that are related to your areas of concern. For new implementations, you might find it useful to copy these tables to a location where you can check off the various best practices as they are completed. In this way, you can help ensure that the implementation is prepared as well as possible before you move forward to production.
|Associated areas||Best practice|
||Go to Retail and Commerce > Headquarters setup > Parameters > Commerce scheduler parameters, and set the Try count field to 3. If the value of this field is too high, download sessions might fail during high-usage times.|
||Go to Retail and Commerce > Channel setup > POS setup > POS profiles > Functionality profile, and then, in the Functions section, set the Days transactions exist field to a value that is the same as, or close to, the value that is defined for the return policy. For example, if the return policy states an item can be returned within 30 days, set this field to 30, 31, or 60 if special exceptions are allowed beyond the normal policy (this would be twice the normal policy, allowing for faster returns even beyond the normal policy limits).|
||We highly recommend that you have either a "dummy" channel database group (that is, a group that isn't associated with any distribution schedule job) that you assign to the newly generated terminals, or a special offline profile where the Pause offline synchronization option is set to Yes. In this way, data generation can occur when it's required and when the system is most available to do it. (However, the system might pause multiple times as required.)|
Practices that affect performance
|Associated areas||Best practice|
Don't generate data for offline databases until that data is required so that an offline database can be used. The following scenario shows why this best practice is important.
A new Modern POS offline database that has been added to the relevant channel database group inherits all existing download sessions since the last full database synchronization occurred. One hundred new Modern POS instances that have offline terminals are created, and a full synchronization hasn't occurred in two months. Only five scheduler jobs have actual changes every 20 minutes. (For example, these changes might involve prices and discounts, or customers, which can be updated often.) In this scenario, up to 2,000,000 download sessions are immediately generated and must be applied, regardless of whether the newly created terminals are activated and capable of applying this data.
Even at the best times, this type of exceptional data generation is large and affects performance. At the worst (that is, busiest) times, it severely impairs the environment's performance. Therefore, we highly recommend that you either have a "dummy" channel database group (that is, a group that isn't associated with any distribution schedule job) that you assign to the newly generated terminals, or set the Pause offline synchronization option for the offline profile to Yes. By setting the Pause offline synchronization option to Yes, you stop data generation for anything that uses the offline profile. Therefore, data generation can occur only when it's required, instead of constantly, and only when the system is most available to do it. (However, the system might pause multiple times as required.)
||No more than one P-job (upload batch job) should occur at any time. If multiple P-job upload batch jobs are created that might occur in parallel, table locking and delays (performance degradation) could occur while data of the uploaded transactions is being applied. The job doesn't have to occur multiple times at the same time. It can just occur frequently.|
- Commerce Data Exchange troubleshooting
- Commerce Data Exchange implementation guidance
- Dynamics 365 Commerce architecture overview
- Select an in-store topology
- Device management implementation guidance
- Configure, install, and activate Modern POS (MPOS)
- Configure and install Commerce Scale Unit (self-hosted)