Scheduler Subjobs

Defining Replication Method

In the Subjob card you can set the Replication Method and combine it with a few more fields, to replicate the data in the table according to your requirements.

We typically refer to two types of subjobs: Normal and By Actions, which depend on the chosen Replication Method. Additionally, several other fields are available to define how table replication should be configured.

Below are several examples that illustrate each subjob type, explain the nuances of each replication method, and clarify when they should be used, along with other related fields, depending on the table type.

Normal subjobs

In a normal subjob, you set the Replication Method field is set to Normal.

When using normal replication method, and depending on the table, you have the option to use replication counters or not.

Normal
For this method you set the Replication Method to Normal and you leave the Replication Counter field empty.When using this method, all the records in the table are replicated.This method is usually used for setup tables because setup tables:
- Will not be replicated very frequently
- Will not have a high number of records
  - The data are exchanged between tables by comparing two tables and making them identical. Since this method often requires reading all table records in both databases, it is not recommended for big tables. However, for tables that neither create Actions nor have a Replication Counter, and from which records may be deleted, normal replication is the only option. The exchange is further specified in the What To Do field.Note: The consequences of deleting can be disastrous. Although deleting is an essential tool and very helpful during implementation and upgrades, it requires a lot of knowledge about the distributed environment to be used safely.
Normal with Replication Counter
For this method you set the Replication Method to Normal and you fill in the Replication Counter with the field in the table that you want to use as a replication counter. This must be a Integer field and an incremental field.
Note:
- For LS Central transactional tables like LSC Transaction Header, the Replication Counter field has been added to the table for this purpose.
- For specific scenarios, for Microsoft Dynamics 365 Business Central standard transactional tables like Item Ledger Entry, you can for instance use the Entry No. field as Replication Counter.

When using this method, only records above the last replication counter, stored when the replication ran last time, are replicated.

This method does not support delete action.

It is usually used for transactional tables (where records are not deleted, only inserted), as these tables do not have delete actions

Action subjobs

Action subjobs only run the new or modified data. To do that, the job uses preactions or actions to see what data have been added or updated since the job was last run.

Using this method limits the number of records that need to be replicated, and the method is useful when replicating master data from head office to stores.

By Actions

For this method you set the Replication Method to By Actions and you set the Action Table ID to:
- 99001612 - LSC Preaction table, when using Preactions
- 99001509 - LSC Actions table, when using Actions
- 99001527 - LSC Preload Action table, when using the Preload feature
When using this method, only new or modified records are replicated.

The job uses preactions or actions counters to see what data was added or updated since the job was last run.

This method is useful when replicating master data, because only new/changed records will be replicated
- Although Preactions must be enabled and managed when using the By Actions replication method - which may introduce some system load - this should not be a concern for Master Data tables, as they typically involve few changes between replications.

Defining Field List

A restriction list determines which fields should be included or excluded from replication which can also be defined in schedule a subjob using the Transfer Field List option at Subjob in the right bottom corner of scheduler subjob and the Field Transfer Type should be Include List or Exclude List. Once the field list is defined, the checkbox Transfer Field List Exist will be automatically enabled.

Linking Tables

Tables can be linked to replicate data with main tables using the Linked Tables option from the Subjob button and link between main table and linked tables can also be defined. For example – transaction entries tables can be linked with the Transaction header table. Once the linked tables are defined, the checkbox Linked Tables Exist will be automatically enabled.

Applying Filters

Filters can also be applied on the data to be replicated between databases using From-Table Filters options. Once the filters are defined, the checkbox From/To Table Filters will be automatically enabled.

Note: Subjobs that have the Replication Method By Action cannot be filtered.

The following table explains the filter options and shows where they can be applied:

Filter name	Filter function/properties	Web Replication	Value1	Value2
1. Const	An exact value is entered in Value1 to be used as filter. Examples: a date, text, code such as Dept. code:FOOD			No
2. Filter	The filter criteria depends on the way being used for replication. Web Replication For Web Replication you must use filters compatible with Navision/Business Central. You can use wild characters like ,?,\|,@, etc. Examples Replicating the Customer table with a normal subjob To replicate customer 10000 and 20000 only, use the following filter:Value 1: 10000\|20000* To replicate any customer whose name contains "John", use the following filter:Value 1: @John For more information see: Business Central: Entering criteria in filters Data Director For Data Director the valid criteria depend on the database type you are connected to. Most likely it going to be a SQL database. Examples Replicating the Customer table with a normal subjob To replicate customer 10000 and 20000 only, use the following filter:Value 1: in ('10000', '20000') To replicate any customer whose name contains "John", use the following filter:Value 1: LIKE '%John%' For more information see: Microsoft Learn - Transact-SQL: WHERE			No
3. From-Location	The From-Location in the job is used as the filter for the field in question. Example: Enter the Transact. Store No. the type From-Location		No	No
4. To-Location	Same as in From-Location but in the Data Director there can be more than one To-Locations. Rarely used with the Data Director because it reduces performance		No	No
5. <	Less than: Filters on jobs with a value lower than the one specified in Value1.	No		No
6. >	More than: Filters on jobs with a value higher than the one specified in Value1.	No		No
7. [..]	Range: Filters for jobs that fall within the range specified in Value1 and Value2.	No
8. min	Filters for the job with the lowest value.	No	No	No
9. max	Filters for the job with the highest value.	No	No	No
10. D-Range	Same as [..] (7) but the values in Value 1 and Value 2 are updated after each successful run. The interval between the both values is used to create new filters after each run.	No

Note: As concerns To-Location filters, bear in mind the following:

As many packages are created as there are receivers.
It is not recommended to use this filter for jobs that have many subjobs.
Subjobs with To-Location filters should preferably not be kept with other subjobs because of the reduced performance, but sometimes this may be necessary for the sake of consistency.

Filters 5-9 are plug-in independent. They can be used where Filter (2) can not be used.

Defining What To Do

The field What To Do specifies what the replicator should do when updating data in the To-Table ID field. This field only applies if the Replication Method is Normal. If the replication method is By Actions, this field is not relevant. In the latter case, the Action field in the Actions table contains the information about what to do.

There are 9 options:

Blank: Nothing is specified.

Update: Only changed records in the From Table are updated in the To Table.

Add: Only new records in the From Table are added to the To-Table.

Update-Add: Only changed and new records in the From Table are updated in/added to the To Table.

Delete: Only records that do not exist in the From Table anymore are deleted from the To Table.

Update-Delete: Changed records and non-existing records in the From Table are updated in/deleted from the To Table.

Add-Delete: Only new records and non-existing records in the From Table are added in/deleted from the To Table.

Update-Add-Delete: All changes, deletions and additions to the From Table are copied to the To Table. The resulting tables are identical.

Add-Only: Only new records are added to the To Table:-. If the record already exists the program returns an error message and does not replicate the scheduler job.

Note:It is extremely important to select the right option in this field. For example, it is safer to use the Add-Only option when replicating entries from store to head office than using the Add option. The reason is that if the number series for the records being replicated, overlap for two distribution locations, the Add-Only option only returns an error, while the Add option does not.

Normal with Replication Counter supports only the Add, Add-only and Update-Add methods.

Scheduler Subjobs

In this article

Defining Replication Method

Normal subjobs

Normal

Normal with Replication Counter