When you process the data synchronization log, automatically several actions are done, and several decisions are made based on the applicable setup. This flow shows the automatically executed actions and decisions when the data synchronization log is processed.


D365 FO D365 FO Start processing data  synchronization log Start processing data  synchronization log Split logged events over pages Split logged events over pages To improve the performance when processing a lot of logged events, you can use paging. For paging, the logged events are split over several pages that are run in parallel batch tasks.You define the paging setup in these fields of the Process data synchronization log dialog:Number of pages: It can be that you can run only a limited number of batch jobs in parallel or that you want to use a limited number of batch jobs. If so, define the maximum allowed number of pages. Page size: You can split the to-be-processed events over several batch task. Define the number of events to be processed by one batch task.On the pages, the events are grouped by RecId, table, and event type. So, all events of a specific event type that are logged for a unique record, are grouped on the same page. For example, if five change events are logged for customer X, these five events are grouped on one page.Example:The Number of pages is 4 and the Page size is 1000.- If 1.500 logged events are processed, these are split over 2 pages.- If 10.000 logged events are processes, these are initially split over 10 pages. However, only 4 pages are allowed. Therefore, a recalculation is done splitting the 10.000 events over the 4 allowed pages. As a result, 4 pages with each 2.500 events are processed.Notes:If you do not use paging, all to-be-processed events are added to one page and processed by one batch task.When selecting logged events to be processed, the synchronization parameters are considered:Last run: Only the events are selected with a created date and time after the latest run date and time.Synchronization delay (minutes): Only the events are selected that are logged before the current processing date/time minus the defined number of minutes. Combine logged events of same record and type Combine logged events of same record and type In the data synchronization log, several events can be logged for a unique record and event type combination. To prevent processing duplicate events, all logged events for a unique record and event type combination are further processed as one event. Finally, this results in only unique records in the outbound queue.Example:A sales order is changed several times. So, several events of type Update are logged for the sales order. When the data synchronization log is processed, these events are first grouped on one page. When the page is processed, these events are combined into one event for the sales order for further processing.Note:If you split logged events over pages, combining events for a unique record and event type combination is done separately for each page. Search for applicable messages and web service actions Search for applicable messages and web service actions For each processed event, the applicable messages and web service actions are searched for.The event is only further processed for the messages and web service actions that are 'subscribed' to the table and event type.Example:A message has a data synchronization setup for table events. One of the records is Customer (CustTable) for which only Update is selected. If an event is logged that a:New customer is created (Insert), the message is not subscribed to this event. As a result, for the message, this event is not further processed.Change is made to an existing customer (Update), the message is subscribed to this event. As a result, for the message, this event is taken for further processing. Are applicable messages  or web service actions  found for the logged event? Are applicable messages  or web service actions  found for the logged event? The logged event  is not added to the  outbound queue The logged event  is not added to the  outbound queue Find request message of applicable web service action Find request message of applicable web service action If a web service action is 'subscribed' to a processed event, find the request message that is defined for the web service action. This request message is used to check if the event complies with the source document of the message. Check if logged event complies with source document setup Check if logged event complies with source document setup For each applicable message, a check is done if the record, for which the event is logged, complies with the source document of the message.Checks are done if the record complies with, for example, the applicable document record ranges and join modes. Does the logged  event comply with  the source document? Does the logged  event comply with  the source document? What's the applicable  Redirect event setting? What's the applicable  Redirect event setting? No record is added to  the outbound queue No record is added to  the outbound queue Is the event logged  for a child record or  root record in the  source document? Is the event logged  for a child record or  root record in the  source document? Root record is  added to the  outbound queue Root record is  added to the  outbound queue Root record is  added to the  outbound queue Root record is  added to the  outbound queue Add root record to outbound queue Add root record to outbound queue If an event is logged for the root record of the applicable source document, the Redirect event setting is not applicable. On processing the data synchronization log, the logged event on the root record of the source document is added to the outbound queue. When the outbound queue is processed, the root record is exported. If, in the applicable document, child records are defined for the root record, these child records are exported as well.Note:Before a record is added to the outbound queue, a check is done if already a record exists for the unique combination of:- Record- Message or web service action- Event type- StatusIf, in the outbound queue, already a record exists for the unique combination, the record is not added to the outbound queue. Only child record  is added to the  outbound queue Only child record  is added to the  outbound queue Add root record to outbound queue (Redirect) Add root record to outbound queue (Redirect) When the data synchronization log is processed, the Redirect event setting of the message or web service action is considered. Each applicable table event, that occurs to a record, is logged in the data synchronization log for that record and related table.On processing the data synchronization log, by default, logged events for a child record of the source document are added to the outbound queue for the root record of the source document. When the outbound queue is processed, the root record and its child records are exported.Example:The source document has a root record 'Sales order' and a child record 'Sales line'. An event is logged for a sales line. If Redirect event is set to 'Yes', not the logged event on the sales line is added to the outbound queue. Instead, the event is added to the outbound queue as logged on the sales order. When the outbound queue is processed, the sales order and all its sales lines are exported by the message.Note:Before a record is added to the outbound queue, a check is done if already a record exists for the unique combination of:- Record- Message or web service action- Event type- StateIf, in the outbound queue, already a record exists for the unique combination, the record is not added to the outbound queue. Add child record to outbound queue Add child record to outbound queue When the data synchronization log is processed, the Redirect event setting of the message or web service action is considered. Each table event that occurs to a record is logged in the data synchronization log for that record and related table.On processing the data synchronization log, by default, log entries for a child record of the source document are added to the outbound queue for the root record of the source document. However, if Redirect event is set to 'No', only the logged event on the child record is added to the outbound queue. When the outbound queue is processed, the child record is exported. Based on the applicable document setup, the applicable parent records and the root record are also exported.Example:The source document has a root record 'Sales order' and a child record 'Sales line'. An event is logged for a sales line. If Redirect event is set to 'No', the sales line record is added to the outbound queue. When the outbound queue is processed, the sales line and the sales order are exported.Note:Before a record is added to the outbound queue, a check is done if already a record exists for the unique combination of:- Record- Message or web service action- Event type- StateIf, in the outbound queue, already a record exists for the unique combination, the record is not added to the outbound queue Record already  exists in the  outbound queue? Record already  exists in the  outbound queue? No record is added to  the outbound queue No record is added to  the outbound queue Record already  exists in the  outbound queue? Record already  exists in the  outbound queue? No record is added to  the outbound queue No record is added to  the outbound queue Record already  exists in the  outbound queue? Record already  exists in the  outbound queue? No record is added to  the outbound queue No record is added to  the outbound queue No Web service  action Message No Yes Yes No Child record Root record No Yes No Yes No Yes

Activities

Name Responsible Description

Split logged events over pages

D365 FO

To improve the performance when processing a lot of logged events, you can use paging. For paging, the logged events are split over several pages that are run in parallel batch tasks.
You define the paging setup in these fields of the Process data synchronization log dialog:
  • Number of pages: It can be that you can run only a limited number of batch jobs in parallel or that you want to use a limited number of batch jobs. If so, define the maximum allowed number of pages. 
  • Page size: You can split the to-be-processed events over several batch task. Define the number of events to be processed by one batch task.
On the pages, the events are grouped by RecId, table, and event type. So, all events of a specific event type that are logged for a unique record, are grouped on the same page. For example, if five change events are logged for customer X, these five events are grouped on one page.
Example:
The Number of pages is 4 and the Page size is 1000.
- If 1.500 logged events are processed, these are split over 2 pages.
- If 10.000 logged events are processes, these are initially split over 10 pages. However, only 4 pages are allowed. Therefore, a recalculation is done splitting the 10.000 events over the 4 allowed pages. As a result, 4 pages with each 2.500 events are processed.
Notes:
  • If you do not use paging, all to-be-processed events are added to one page and processed by one batch task.
  • When selecting logged events to be processed, the synchronization parameters are considered:
    • Last run: Only the events are selected with a created date and time after the latest run date and time.
    • Synchronization delay (minutes): Only the events are selected that are logged before the current processing date/time minus the defined number of minutes.

Combine logged events of same record and type

D365 FO

In the data synchronization log, several events can be logged for a unique record and event type combination. To prevent processing duplicate events, all logged events for a unique record and event type combination are further processed as one event. Finally, this results in only unique records in the outbound queue.
Example:
A sales order is changed several times. So, several events of type Update are logged for the sales order. When the data synchronization log is processed, these events are first grouped on one page. When the page is processed, these events are combined into one event for the sales order for further processing.
Note:
If you split logged events over pages, combining events for a unique record and event type combination is done separately for each page.

Search for applicable messages and web service actions

D365 FO

For each processed event, the applicable messages and web service actions are searched for.
The event is only further processed for the messages and web service actions that are 'subscribed' to the table and event type.
Example:
A message has a data synchronization setup for table events. One of the records is Customer (CustTable) for which only Update is selected. If an event is logged that a:
  • New customer is created (Insert), the message is not subscribed to this event. As a result, for the message, this event is not further processed.
  • Change is made to an existing customer (Update), the message is subscribed to this event. As a result, for the message, this event is taken for further processing.

Find request message of applicable web service action

D365 FO

If a web service action is 'subscribed' to a processed event, find the request message that is defined for the web service action. This request message is used to check if the event complies with the source document of the message.

Check if logged event complies with source document setup

D365 FO

For each applicable message, a check is done if the record, for which the event is logged, complies with the source document of the message.
Checks are done if the record complies with, for example, the applicable document record ranges and join modes.

Add root record to outbound queue

D365 FO

If an event is logged for the root record of the applicable source document, the Redirect event setting is not applicable. On processing the data synchronization log, the logged event on the root record of the source document is added to the outbound queue. When the outbound queue is processed, the root record is exported. If, in the applicable document, child records are defined for the root record, these child records are exported as well.
Note:
Before a record is added to the outbound queue, a check is done if already a record exists for the unique combination of:
- Record
- Message or web service action
- Event type
- Status
If, in the outbound queue, already a record exists for the unique combination, the record is not added to the outbound queue.

Add root record to outbound queue (Redirect)

D365 FO

When the data synchronization log is processed, the Redirect event setting of the message or web service action is considered. Each applicable table event, that occurs to a record, is logged in the data synchronization log for that record and related table.
On processing the data synchronization log, by default, logged events for a child record of the source document are added to the outbound queue for the root record of the source document. When the outbound queue is processed, the root record and its child records are exported.
Example:
The source document has a root record 'Sales order' and a child record 'Sales line'. An event is logged for a sales line. If Redirect event is set to 'Yes', not the logged event on the sales line is added to the outbound queue. Instead, the event is added to the outbound queue as logged on the sales order. When the outbound queue is processed, the sales order and all its sales lines are exported by the message.
Note:
Before a record is added to the outbound queue, a check is done if already a record exists for the unique combination of:
- Record
- Message or web service action
- Event type
- State
If, in the outbound queue, already a record exists for the unique combination, the record is not added to the outbound queue.


Add child record to outbound queue

D365 FO

When the data synchronization log is processed, the Redirect event setting of the message or web service action is considered. Each table event that occurs to a record is logged in the data synchronization log for that record and related table.
On processing the data synchronization log, by default, log entries for a child record of the source document are added to the outbound queue for the root record of the source document. However, if Redirect event is set to 'No', only the logged event on the child record is added to the outbound queue. When the outbound queue is processed, the child record is exported. Based on the applicable document setup, the applicable parent records and the root record are also exported.
Example:
The source document has a root record 'Sales order' and a child record 'Sales line'. An event is logged for a sales line. If Redirect event is set to 'No', the sales line record is added to the outbound queue. When the outbound queue is processed, the sales line and the sales order are exported.
Note:
Before a record is added to the outbound queue, a check is done if already a record exists for the unique combination of:
- Record
- Message or web service action
- Event type
- State
If, in the outbound queue, already a record exists for the unique combination, the record is not added to the outbound queue

See also

Provide feedback