Transaction workflows may contain integration configurations that share data with external systems. In some cases, such as when the integration scans data for security concerns, it is important to know if the user has made changes to certain fields since the last time the integration was run.
This section describes how to assemble the necessary fields and configurations to identify such changes.
Note: It is recommended to use the DetectChanges() and ModifedOn() functions for any new configurations. See the function descriptions in theFull Function Reference Listfor details.
Overview:
Once configured, each time the calculated fields in a transaction are recalculated, the HashAndModifiedOn() function evaluates the tracked fields and generates a composite value derived from those fields. The first time the function runs within a trans-action, it stores the composite value (the Hash value) and the current date and time.
Each time it runs after the first time, the function recalculates the composite value and compares it to the stored value. If the value has changed, the old composite value is replaced with the new value and the date and time are updated to the current date and time. Note that this stores the date and time the changes were detected by the function, and not when the changes actually occurred.
In the background, whenever an integration is completed successfully, the system stores the date and time the integration was performed. Each different integration configuration is tracked separately, so the most recent date and time information is avail-able for each. These dates and times can be retrieved using a calculated field, providing a reference date to determine if the data was changed since the last time the integration was performed.
With the date of the integration, and the date that changes were detected in the tracked fields, the IsDateGreaterThan() function is used to compare the dates. If the tracked fields were changed after the last integration, the function returns "True". This result can be used in a trigger to re-run the integration, activate a validation, or affect any other feature that uses the trigger.
Configuration:
1. Identify and create the necessary fields.
Tracked Fields These are the fields that will contain the data that will be monitored for changes. These fields may already be part of the workflow, or may be new fields created specifically for tracking. All field types can be tracked.
Caution: Use caution when tracking fields that may be changed by the integration. That change will be detected and trigger the integration again, creating a loop.
Hash Reference Field This field will contain the generated composite value from the HashAndModifiedOn() function.
This should be a Text Area field with no default value.
Detected Changes Timestamp Field
This field will contain the date and time that the HashAndModifiedOn() function detected changes to the tracked fields.
Hash Function Field This field will contain the HashAndModifiedOn() function. This should be a standalone Text Area field containing just this function.
HashAndModifiedOn(p0,p0,p0,...,p1,p2)
P0: Placeholders for all Tracked Fields to be included in the hash calculation should be provided, separated by commas.
P1: The Code of the Hash Reference Field must be the second-to-last parameter after all of the tracked fields. This condition is literal and must contain the Code of the field without any square brackets, no placeholders or functions can be used here.
P2: The Code of the Detected Changes Timestamp Field must be the last parameter. This
con-dition is literal and must contain the Code of the field without any square brackets, no place-holders or functions can be used here.
Example: HashAndModifiedOn([[tracked field 1]],[[tracked field 2]],[[tracked field 3]], HashReferenceFieldCode,DetectedChangesTimestampFieldCode)
Date Comparison Field This field retrieves the date of the integration and compares it to the last detected changes date from the HashAndModifiedOn() function. This field will resolve to "True" if changes are detec-ted after the integration, or "False" if no changes are detecdetec-ted.
IsDateGreaterThan(p0,p1,p2)
P0: Placeholder for the Detected Changes Timestamp Field.
P1: Placeholder containing the date and time the relevant integration was last completed
successfully. The following placeholder can be placed directly in the function, or can be included in a calculated field that is then referenced in the function.
If using a field, a Date Picker field should not be used or the time component will be lost. A Textbox field should be used.
[[Integrations/Integration[Code='code']/StartTime]]
Thecodeshould be the code of the integration configuration defined for the workflow.
P2: Tolerance in milliseconds. The system date/time format is accurate to a ten-millionth of a second. Even dates that seem to be calculated at the same time will have a small difference. If the P0 date is only greater than the P1 date by less than the provided tolerance, it will not be
con-sidered a difference and the function will return false.
Example: IsDateGreaterThan([[Detected Changes Timestamp Field]], [[Integ-rations/Integration[Code='IntegrationConfigurationCode']/StartTime]],1000) With this configuration having a tolerance of 1000 milliseconds, if the Detected Changes Timestamp Field date is earlier than the integration timestamp or less than one second after, it will not be considered a change.
Integration Flag Field If the relevant integration has not yet been performed, the IsDateGreaterThan() function will try to compare the Detected Changes Timestamp Field with a non-existent date, and return an incorrect "true" value.
This field can be any type of field, but must be updated by the relevant integration when it runs.
Any triggers created to detect the changes should also check this field to confirm the integration has been performed at least once in the current transaction.
Tip: Any of the fields used in this configuration can be hidden. Since many of the fields will only contain raw data used in the functions, it is probably best to hide them.
2. Once the fields have been configured, the results can be used in triggers. The trigger conditions should check the Date Com-parison Field for a true result (Field - Equals - 1) AND the Integration Flag Field should equal the value inserted by the integ-ration.
3. The triggers can then be used to reactivate the integration or for any other controls.