Summary
Learn how to use the Record Change Event with or without the use of the setting “log changes incrementally”. When the business case requires an update to process the entire document or only the updated content.
Background on used functionality
In Business Integration Solutions, the Record Change Event triggers a pipeline, based on changes in the Microsoft Dynamics NAV database.
Usage
Use this event if you want to trigger an export based on record changes in Microsoft Dynamics NAV. You can configure a Record Change Event for a table by:
• Defining an internal document
• Providing table and field filters
• Specifying the logging mechanism for record changes, such as insert, modify, delete or rename
Use the Job Queue to process the Record Change Event automatically. On the Job Queue Entry card you can define the recurrence and interval of the Job Queue.
Concept
When you insert, modify, delete or rename a record in Microsoft Dynamics NAV, the Record Change Event generates a record set and all relevant record changes are captioned and stored in a change log table, namely N108 Record Set Member. This record set is the input for the first activity in the Pipeline, most likely the XML Generator Activity.
Event Setup
The Event Setup allows you to determine on which triggers the change log should monitor:
- Insert: all new entries in the table are monitored and stored as a change log
- Modify: All the included fields in the Internal Document are a trigger for this type and will result in an entry in the change log. If a Table is included, but no fields are listed, all fields will be monitored! Fields that are part of the Primary Key will not be monitored in this trigger
- Delete: all deleted entries in the table are monitored and stored as a change log
- Rename: All changes to fields that belong to the primary key will result in a rename. These are monitored and stored as a change log
- Log changes incrementally: Having this feature enabled, only changed records will be included
Log changes incrementally
When the Event Setup has this feature enabled, the output of the file will be handled differently.
Document design
When a Document is designed to be used in a Record Change Event for monitoring, it is recommended to use a trigger document and another document for processing.
The first Internal Document can be used for triggering/monitoring (“TI_CS_PO_INCR.TRIGG”) and the second can include multiple table model with relations and filters (“TI_CS_PURCHORD”). Make sure that the both Documents contains the same Root Element (E.g. the Purchase Header Table). The Record ID is passed in the Message through the Pipeline to communicate between the two documents.
If a different table in the Root Element of the second Document is used, then there will be no reference to the changed record, only filters will then be able to limit the number of records processed.
We’ve created an Internal Document “TI_CS_PO_INCR.TRIGG” with the following design:
Two tables are being monitored; Purchase Header and Purchase Line, on these tables only the fields listed are tracked. Even though the Tables have a relation, changes will be tracked on table level. However, if a relation is detected, the parent will be included in the record changes to be picked up by the Record Change Event when processing.
Details
Each Record Change Event will enable the Change log to keep track on the changes based on the Internal Document. E.g. If you change a field on the Item table and this field is monitored on more than one Internal Document on multiple Record Change Events, this will result in a new entry in the Change Log for each Record Change Event (Connection).
Monitor changes
Before changes are processed by the Record Change Event, the system will collect and store the changes into the N108 Record Set and N108 Record Set Member tables. To quickly access the changes, it is possible to view the entries from the Record Change Event Element, by clicking in the ribbon on Navigate à Details.
After the record change event has run, processed entries will be deleted.
Purchase Order changes
A Purchase Order with two order lines have a single change on the first order line, the promised receipt date has been changed.
Since the changes are monitored on this field, this has been recorded in the Record Changes table:
Result
When processing this via the Connection, the output file is as follows:
Because the option “Log changes incrementally”, only the updated line or lines of the Purchase Order will be exported.
Disable Log changes incrementally
When this setting is not active, all related records to a parent will be included in the export. Uncheck the “Log changes incrementally”
Please Note: Close the client and reopen, for changes to the Record Change Event to be effective.
Purchase Order changes
A Purchase Order with two order lines have a single change on the first order line, the promised receipt date has been changed again.
Result
Now, the recorded changes in the Record Set Table only registers the Parent table, which will export the entire Purchase Order Document.
All of the Purchase Order Lines are included in the export, even though only the first purchase line has been updated.