The CreateIncident Message will create a ticket on the target table of the integrated system.
As previous, after clicking the 'Messages' icon, you will see the following screen (note: both the previously configured messages are now visible in the list):
New Message Modal
The fields to be configured for the CreateIncident New Message modal are as follows:
The message name that is unique for this integration.
The primary purpose of the message.
The direction(s) this message is configured to support.
Your CreateIncident New Message modal should look like this:
Submit and view to further configure the Message.
Navigate to Message > Response.
The Response fields to be configured are as follows:
The immediate synchronous response to this message.
Turn this option on if you want inbound processing to occur asynchronously or this message is the first of an asyncronous message pair.
The asynchronous receipt to this message.
*This field is automatically defaulted to true.
Your Response form should look like this:
Navigate to Message > Bond.
The Bond fields to be configured are as follows:
Determine if the sender should own the bond or not in order for this message to be processed? Use 'Ignore' to process regardless of the owner flag. (Choices: Ignore, Must own, Must not own.)
Bond condition type*
The type of conditional check made on the bond. (None: no checks are made. State: checks against the state are made using the conditional checkboxes. Scripted: the 'Bond condition' script is used.)
Process this message when a new bond is required.
Set bond state inbound
Set the Bond State when receiving this message. Use 'None' to leave the Bond State alone or to modify it via a Message/Field Stage to Target script. (Choices: None, Pending, Open, Suspended, Vendor suspended, Closed)
*These fields are automatically populated.
Your Bond form should look like this:
Navigate to Outbound > Trigger.
Outbound Trigger Fields
The Outbound Trigger fields to be configured (as required)* are as follows:
The condition that the ServiceNow record must meet to trigger this message being processed.
Update the Outbound condition script field with the code below
*Outbound condition (as required):
It is not necessary for you to enter a condition. The value given is an example. You may create any condition (or not) to align with your business process requirements.
The code in the 'Outbound condition' script field should look like this:
This is an example of data-driving the trigger condition. This script checks whether the integration that this message belongs to is listed in a custom field on the assignment group which references the integration.
Your Outbound Trigger form should look like this:
Navigate to Outbound > Settings.
Outbound Settings Fields
The Outbound Settings fields to be configured are as follows:
The SOAP Action or the REST Method to use for this message. If this field is empty the SOAP Action will default to the message name and the REST Method will default to POST.
Your Outbound Settings form should look like this:
Navigate to Inbound > Settings.
Inbound Settings Fields
The Inbound Settings fields to be configured are as follows:
Bond reference method*
Method of searching for and validating an existing bond for incoming messages.
Reference lookup script
The script containing functions for extracting internal and external references from the request payload.
Update the code in the Reference lookup script field so that it looks like the code below
*This field is automatically populated & not editable.
Bond reference method:
Internal - lookup using the internal reference only.
External - lookup using the external reference only.
Both - lookup using both the internal and external references.
Bond reference method: The perspective of the available choices is in relation to the receiving instance i.e. Internal (internal reference) means the bonded ticket in our instance and External (external reference) means the bonded ticket in their instance.
Primarily used in relation to create and update type messages, these settings define which values to lookup against to search for and validate whether or not a bond already exists.
In the case of a create type message, we use 'External' because there is not yet a bonded ticket in the receiving instance to reference (if we were to receive a create type message which referenced a bond that already existed it would be rejected because we don't want to create another bond for a record we've already seen ).
In the case of an update type message, we use 'Both' because it's a more accurate method of validating updates are being sent to/received from the correct bonded records.
The code in the 'Reference lookup script' field should look like this: