About Record Change Event: Setup and Monitoring

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.

RCE Concept

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.

RCE EventSetup1

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.

RCE DocCompare

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:

RCE DocTrigger

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).

RCE Details1

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.

RCE PurchDoc

Since the changes are monitored on this field, this has been recorded in the Record Changes table:

RCE DetailsResult1

Result

When processing this via the Connection, the output file is as follows:

RCE Result1

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”

RCE EventSetup2

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.

RCE PurchDoc

Result

Now, the recorded changes in the Record Set Table only registers the Parent table, which will export the entire Purchase Order Document.

RCE DetailsResult2

All of the Purchase Order Lines are included in the export, even though only the first purchase line has been updated.

RCE Result2

About Nico

As the Product Owner, Nico van Wijk is responsible for our Enterprise Mobility and Business Integration Solutions for Microsoft Dynamics NAV. Nico manages all aspects of customer project delivery from initial planning to retaining a customer for life. That challenges him to provide leadership and insight to blended teams of contributors from To-Increase, the customer organizations, and partners. He also participates in setting the direction and driving the development of the mobile and integration solutions. In his years with To-Increase and, earlier, with Dynamics Anywhere, Nico has played a part in the rapid evolution of mobility, supported by increasingly powerful capabilities. Before that, he was a developer for Microsoft Dynamics NAV solutions at Qurius (now Prodware), the large European Dynamics partner. Nico has a B.A. electrical engineering degree from the HZ University of Applied Sciences. When away from work, Nico loves to travel and explore the world.
This entry was posted in BIS Concept, Connectivity Studio, EDI Studio, Notification Management, Replication Management. Bookmark the permalink.

Leave a comment