Distribution schedules
The process of transferring data can be triggered manually or by scheduling a batch job through the distribution schedule in HQ. This distribution schedule can contain one or more channel data groups and one or more scheduler jobs. When the Commerce solution is deployed, a default database is systematically created, and we recommend that you avoid creating a second database or renaming the default one.
Distribution schedules act in an asynchronous mode when you are coordinating the communication and data delivery between Commerce and the stores. The scheduler is linked with scheduler jobs and channel database groups. With scheduler jobs, you can set up the direction of the data flow, for either downloading or uploading the data. Creating a batch job as a scheduled job means to set up a job that will be run at a specific time and that allows for scheduled batch processing of data. The advantage of using a batch job as a scheduler job is the fact that you have a run history that logs information about when the batch job has been run and whether it finished successfully or with an error. If it ends in an error, a batch job log is available.
Scheduler jobs are made up of sub jobs that specify the tables and table fields that contain the data to distribute. Headquarters includes predefined scheduler jobs and sub jobs that meet the replication requirements of most organizations.
The types of predefined jobs are:
- Download jobs – Send data that has changed from Headquarters to channel databases. Modifications to records are tracked through SQL Server change tracking.
- Upload jobs (P-jobs) – Pull sales transactions from a channel into the Commerce database. P-jobs upload data incrementally, which means that they do not update data that was previously uploaded. To ensure that the data hasn’t already been uploaded, the Async Client library checks the replication counter for records that have already been received from a location. A record is uploaded only if its replication counter is more than the largest value that is found.
The distribution scheduler records use SQL change tracking in the operating system to determine what data should be inserted, updated, or deleted in the channel database groups, which is called a delta (or changes only). The first time that the job is run, or when the SQL change tracking settings dictate that a full push is required (typically around three days), a full push of all data can be sent to the store. Existing data in those tables will be truncated (fully deleted) and the new data will be inserted. SQL change tracking is aligned to the distribution scheduler records, to the tables, not just the scheduler jobs. This Full data sync process can also be manually run through the Channel database page, which does not use a change tracking engine.
The Channel database group allows you to group more similar channel databases into one data group. The advantage of creating a channel database group is that you can specify which channel databases should be included.
For instance, if you have two channels, both of which are connected with their own Commerce Scale Unit on-premises and need to have the same data, you can connect the scale units into one channel database group. After this action, both scale units will have the same data in their databases.
Each channel database group is defined as having a Commerce channel schema that aligns to a version of a database, such as AX2012R3 or AX7. This feature allows for use cases for different versions of the Store Commerce in the field and for constructing schemas and mappings for non-Dynamics Store Commerce databases.