Net Change Caveats

One issue to be aware of with net-change based generation; because of transaction boundaries, there is a potential of missing certain records unless precautions are taken. Consider the following example:

It is possible that if a record’s last modified date is updated just before a net change query is run, but committed just after, then you may never fetch this record.

The approach we recommend for this is to set a Threshold on the OutboundInterfaceWriteRequest which fetches the net changed data. This threshold should be the max value you would expect any given transaction to be held open for the model you are updating. Note that this will result in some records updated around the boundaries of our net change query being sent twice, but will prevent records from being missed. In the previous example, if we use a threshold of 2 minutes, we would get the record that was missed previously.

Another common pitfall is when you have dependencies among interfaces. For example, we may have a Company outbound interface and an Employee outbound interface, where Employee includes a Company Name field. It is possible, if we’re running the net change for these entirely separately, that we might produce an Employee file that references a Company Name that has not yet been published to the Company outbound interface. To solve this problem, the Outbound API allows for one to specify multiple outbound interfaces to be generated together as a group, using the exact same date range; in this way, these types of integrity constraint violations can be avoided.