In most integrations each system knows just enough about the other to facilitate correlation and a semblence of process. On task records in ServiceNow this has normally been done using the Correlation Display and Correlation ID fields. If you want to integrate non-task records, then you would need to add fields like these to the table. If you wanted to use one record with many integrations, then you have even more to do.

In Unifi, correlation has been normalised for global use through the use of the Bond record.

Purpose

Bond records are used for much more than just storing correlation data; they are the glue that links everything together and ensures that you can maintain a high level of control in all your integrations. In addition to this, all transactions and attachments reference a bond making it easy to track communications.

A Bond record’s primary functions are:

• To store the internal and external references

• To give state control to each integration instance

• To provide insight into the health of the bond

• To track which system ‘owns’ the bond

• To store a running commentary of the bond history

• To ‘contain’ all transactions and attachments for the lifetime of the bond

• To track attachment totals

Document References

The references necessary for integration are stored on the bond. You do not need to store any integration data on the integrated record itself.

Internal reference

The display value of the reference field from the ServiceNow record. This is automatically captured based on the Reference field specified in the Process which the integration belongs to.

External reference

The reference used by the external system.

State Control

In complex integration processes it is often useful (or necessary) to track the state of the bond. This is mainly used to allow or prevent messages from being sent and received, but is also helpful to analysts who can quickly gain insight into what is happening without any additional configuration.

Every Message can be conditioned using the Bond state. Messages will check that the bond meets the bond condition specified before processing.

The Bond state can be set using the Set bond state inbound and Set bond state outbound fields on the Message. It can be also set manually in the Source to Stage (outbound) and Stage to Target (inbound) Message Scripts.

Health

Bond health can be determined by the Status field. This is constantly updated as transactions are flowing between the integrated systems.

Process Ownership

Ownership is not always used, but is extremely helpful in complex ticket integrations, especially where many systems might be involved (SIAM/Multi-vendor).

The Owner flag is used to track which system is currently in charge of the ticket. This allows complex security and process logic to take place, creating a much more robust integration.

The Owner flag can be set inbound and/or outbound using the Set bond owner inbound and Set bond owner outbound fields on the Message.

Transactional Data Cleanup

Automatic Cleanup

Unifi has a unique transactional management approach that is accomplished through the bond: all transactional data is stored against the bond until the bond state changes to Closed, at which point it is deleted. This balance gives integration admins full insight to view and debug integration issues while maintaining table efficiency.

Once the bond is closed, a scheduled job is created in the future using the Integration property Bond cleanup, which specifies how many days to wait before running the cleanup process.

The cleanup process deletes all Transaction and Bonded Attachment records.

Manual Cleanup

Some integrations may need to maintain an open bond for a significant amount of time, or even indefinitely. In this case, a traditional scheduled cleanup job should be created to run periodically to clear out historic records.

Cascade Delete

Deleting the Transaction record will cascade delete all Stage and HTTP Request records.

Debugging

You can view the Unifi logs from the Bond record by navigating to the 'Unifi Activity Logs' related list. Activity Logs are particularly helpful to ShareLogic when debugging Unifi itself and will be populated if logging is enabled when debugging.

Activity logs

In addition to the Transaction logs (for details of those click here), you will also see the following:

Business rule: <Your Trigger Business Rule>

These logs are defined in the Trigger on the process table being integrated.

For every attachment that is sent or received, a Bonded Attachment record is created that links to the attachment. This allows the system to automatically make size calculations and track if the attachment has been sent.

The attachment sits on the bond, but is also linked to and can be viewed from the transaction that sent it.

For implementations using multiple integrations with one record, one attachment can be added and it will automatically be sent and tracked across all the relevant bonds.

Unifi has automated checks that prevent attachments and updates being sent back to the originator (controlled by the Connection).

For help on setting up attachments please see guide for How to Handle Attachments.

Fields

The following table gives a description of the fields that are visible on the Bonded Attachment record:

State Control

The state is set in conjunction with the information contained on the Integration & Bond (concerning permitted file types & attachment sizes etc.) and is used to determine whether or not to send the attachment, or where it sits in the process. The Bonded Attachment lifecycle can be seen in the following table which describes the State field value choices: