Integrations
The Integration is where most configuration and settings are stored.
An Integration defines the connection between a Process and the single system it’s connecting with. It is a record that contains all of the properties and configurations for that unique connection.
As previously stated, Integration has a many-to-one relationship with Process. This means multiple Integrations can exist for one Process and each unique Integration will define the way in which the Process connects with that particular system.
Incident Process - JIRA = one Integration
Incident Process - ATOS = one integration
Incident Process - SAP = one integration
Incident Process TOTAL = three integrations
Unifi will automatically create a Trigger (Business Rule) for the Process being integrated (if one doesn't already exist) when you run 'Build' either on the Integration or Message once your Create Message is configured.
For step-by-step instructions on how to configure Integrations (and other Integration components) see the Integration Guides section of the documentation.
The Details fields to be configured for the Integration record are as follows:
Field | Type | Description |
Name | String | The name of the integration. |
Description | String | A description of what this Integration is for and what it does. |
Service type | String | The type of web service this integration is using (SOAP/REST). |
Message format | String | Automatically pre-process incoming messages for simpler message scripting. |
Application | Reference | Application containing this record. |
Process | Reference | The process this integration belongs to. |
Company | Reference | The company this integration belongs to. |
Message format choices: XML, JSON, Advanced
The choice selected here will determine the object that's available to the 'Identify message script'.
Company
This is usually the name of the service provider being connected to, as opposed to the name of the manufacturer of the software.
Messages are central to the functionality of Unifi. Upon receipt of an inbound request, Unifi will be able to identify the Message, know how to process it and subsequently what actions to perform based on the Message configurations. For that reason, it is very important that each Message within an integration be unique (more on that in the Messages section).
The Message Identification fields to be configured for the Integration record are as follows:
Field | Type | Description |
Identify message script | Script plain | The script used to extract the unique message identifier from the incoming request payload. It identifies which message record is used to process the request. |
Unifi automatically looks for a header called
X-SND-EB-Message-Name to use as the message name. If the header is found then the Identify Message Script is not executed.Both the
payload and headers are passed into the script. The following example will parse the XML payload and identify the message name from the first child element of the body node:function identify(xmlDoc) {
var message_name = '';
message_name = '' + x_snd_eb.utils.identifyFirstChild(
xmlDoc,
'/soapenv:Envelope/soapenv:Body'
);
return message_name.split(':').pop();
}
The following is an example which returns the message name from a JSON payload:
function identify(payload) {
return (payload.$message_name || '') + '';
}
The Attachment Settings fields to be configured for the Integration record are as follows:
Field | Type | Description |
Send existing attachments | Boolean | Set to true to send attachments which were added to the record before it was bonded. |
Allowed content types | String | Comma separated list of attachment content types that are allowed to be sent to this integration. |
Max attachments per bond | Integer | The maximum number of attachments allowed to be sent per bond. |
Max attachments size per message | Decimal | The maximum size of all the attachments in a single message in MB. |
Max attachments size per bond | Decimal | The maximum size of all the attachments in a single bond in MB. |
The Bond Settings fields to be configured for the Integration record are as follows:
Field | Type | Description |
Bond cleanup | Integer | Number of days after bond closure that all its associated Transactions, HTTP Requests and Bond Attachment records are deleted. |
The Feedback Settings fields to be configured for the Integration record are as follows:
Field | Type | Description |
Enable UI messages | Boolean | Allow information and error messages to be shown to the user as UI Notifications. Only applies to certain notifications. |
Note bond history | Boolean | Use the ‘Note bond history’ to process bond history updates. |
Note attachment history | Boolean | Use the ‘Note attachment history’ to process attachment updates. |
Add note script | Script plain | Script for adding integration updates to the target record. There is no need to call update() on the target. |
The General Error Handling fields to be configured for the Integration record are as follows:
Field | Type | Description |
Sync error message | Reference | The message to use when an inbound message cannot be processed synchronously. |
Async error message | Reference | The message to use when an inbound message cannot be processed asynchronously. |
The Timeouts fields to be configured for the Integration record are as follows:
Field | Type | Description |
Sync timeout | Integer | The amount of time in seconds to wait for a request to be accepted by the external system. |
Async timeout | Integer | The amount of time in seconds to wait for an asynchronous receipt. |
MID server timeout | Integer | The amount of time in seconds to wait for the MID server to respond (only applies to connections using MID servers). |
The Retry fields to be configured for the Integration record are as follows:
Field | Type | Description |
Retry delay | Integer | The amount of time in seconds to wait before retrying a failed outbound request. |
Retry limit | Integer | The number of times sending an outbound request is attempted. |
There are some fields which are visible in native ServiceNow. These can be viewed by clicking the hamburger menu & selecting 'Open in platform'.
The following non-selectable Integration fields are visible on the platform Integration record (and are controlled by Unifi):
Field | Type | Description |
State | String | The current state of the integration. It can be Active, Off, or Paused. |
Status | String | The current status of the integration. It can be Up, Down, or Awaiting. |
Build date | Glide Date Time | The last time the integration components were generated using the Build action. |
Active | Boolean | The integration is enabled when a connection is made active. |
The Properties fields to be configured for the platform Integration record are as follows:
Field | Type | Description |
Run event actions | Boolean | Should this integration run Event Actions for transactional events? |
Heartbeat frequency | Integer | The amount of time in seconds to wait between trying an outbound heartbeat request. |
Heartbeat message | Reference | The message that should be used to periodically test the integration. |
These are used for debugging purposes.
*Attach logs/payloads:
The attached logs were previously controlled by the
Attach logs and Attach payloads checkboxes on Integration, but they are now overridden off by the Enable Integration Attachments system property (logging attachments this way is now deprecated and has been replaced by the Unifi Portal and Activity Log). This property acts as the master switch and effectively disables the checkboxes on the Integration.
Note: the checkboxes have been removed from the Integration form but can still be edited from the list view.
NOTE: When copying Integrations, the ServiceNow System Administrator (admin) role is required to see and to select Application Scope.
Last modified 2yr ago