Ebonding Between Two ServiceNow Instances: A Comprehensive Guide with Examples

[sadif_raja]

Ebonding is the integration of one ServiceNow instance with another SNow instance, commonly used for modules such as Incident, Change, and Problem. This integration often requires scripting and debugging to ensure smooth data transfer. Ebonding can be implemented through methods like Scripted REST APIs, Table APIs, and Import Set APIs.

 Advantages of Using Import Set APIs:

1. **Flexible Field Mapping**:
Example: Suppose you have a "State" field in the Incident table where the values are different between the two instances (e.g., "In Progress" in Instance A and "Work in Progress" in Instance B). With Import Set APIs, you can script in the transform map to map these differences, ensuring the data aligns between the instances.

2. **Effective Debugging**:
Example: When you receive data from the other instance, you can view all the fields and values under the "Input Rows" in the Inbound Web Service related links. If an Incident record fails to import correctly, you can check these input rows to identify which field might be causing the issue.

3. **Error Identification**:
Example: If an Incident fails to import due to a missing or mismatched field, the error message can be found in the "Import Sets" related link under the Inbound Web Service. This can help you identify and resolve the problem quickly.

4. **Script Execution**:
Example: If you need to ensure that a specific field is transformed or validated before it is inserted, you can write an On Before Script in the Transform Script section. For instance, you might want to check that an Incident's "Priority" field is always set based on "Impact" and "Urgency" before inserting the record into the target instance.

 Key Configuration Steps for Ebonding with Examples:

- **REST Message**:
Example: Create a REST message in Instance A to communicate with Instance B's Incident module. In the REST message, set up the endpoint URL of Instance B (e.g., `https://instanceb.service-now.com/api/now/table/incident`) and configure an auth profile with ITIL and REST API Explorer roles. Add the HTTP method `POST` for creating records and `PUT` for updating them.

- **Business Rule**:
Example: In Instance A, create an After Business Rule on the Incident table that triggers when a new Incident is created. This BR will send a REST message payload to Instance B with the Incident data. You can use `gs.executeAsync()` to make the call asynchronously, which enables you to track the outbound payload logs in the ECC queue. For example, the payload might look like this:

javascript
var restMessage = new sn_ws.RESTMessageV2('incident_create_rest', 'POST');
restMessage.setStringParameterNoEscape('number', current.number);
restMessage.setStringParameterNoEscape('short_description', current.short_description);
restMessage.executeAsync();
```

This ensures the Incident data from Instance A is sent and logged properly.

- **Inbound Web Service**:
Example: In Instance B, create an inbound web service for the Incident table. Add the required fields like "Number," "Short Description," and "State" to the transform map. Set the "Number" field as Coalesce "True" so that updates can be mapped to existing records instead of creating duplicates. If an Incident already exists with the same "Number," it will be updated rather than a new one being created.

For example, you might set up the following transform map logic:

```javascript
// Transform Script to map priority based on impact and urgency
if (source.u_impact == 1 && source.u_urgency == 1) {
target.priority = 1; // Critical
} else {
target.priority = 2; // High
}
```

### Complete Example:

**Scenario**: Two ServiceNow instances (Instance A and Instance B) need to exchange Incident records. An Incident created in Instance A should automatically create or update a corresponding record in Instance B.

1. **REST Message Setup in Instance A**:
- Create a REST message with the endpoint URL of Instance B's Incident table.
- Add HTTP methods `POST` for creating and `PUT` for updating Incidents.

2. **Business Rule in Instance A**:
- Create an After Business Rule on the Incident table in Instance A. This BR will send the Incident data to Instance B whenever a new record is created or updated.

javascript
var restMessage = new sn_ws.RESTMessageV2('incident_rest_message', 'POST');
restMessage.setStringParameterNoEscape('number', current.number);
restMessage.setStringParameterNoEscape('description', current.description);
restMessage.executeAsync();
```

3. **Inbound Web Service Setup in Instance B**:
- Create an inbound web service in Instance B for the Incident table.
- Configure the transform map to map fields like "Number" and "Description." Set "Number" as Coalesce "True" to ensure updates are applied to the correct record.

4. **Handling Choice Fields**:
- If the "State" field values differ between the two instances, use a transform script to map them appropriately:

```javascript
if (source.state == 'In Progress') {
target.state = 'Work in Progress';
}

This approach ensures a smooth ebonding process between two ServiceNow instances with minimal manual intervention.

Mark helpful (👍) if this was valuable to you!

[AshwaniK4856193]

How will we handle duplicates record this way ??