What We’ve Got Here Is Failure to Communicate – Part 2

In Part 1 of this article, I delved into Inbound and Outbound design considerations. Now, in Part 2, I’ll cover considerations for a true eBonding type integration as well as other general tips I’ve learned through the years building integrations.

eBonding Design Considerations and Good Practices

As mentioned previously, the example I’m working from is a bi-directional application to application integration, meaning that the systems are integrating application records throughout the lifecycle of that application’s workflow. For example, an Incident in system X that integrates with a ServiceNow Incident and exchanges updates throughout the life of both incidents, regardless of who has ownership of the resolution. Many know this concept as “eBonding”. Simply put, this is integration of both data and process, where what data is exchanged, and when, are as a result of process and may also influence process.

The technical designs I’ve outlined above work very well for eBonding, and are in fact designed to work with this practice. In addition to the technical aspects, here are other considerations when designing an integration solution for eBonding:

• Both systems have to agree on the field mappings and data types. (No different than any other integration.)
• Both systems have to agree when mapped fields can be updated. This is especially important for things like the ServiceNow “state” field, which either controls or is controlled by workflow. In our Incident example, often the only states that are allowed to be set by the integration are canceled or resolved. Other states may change in the other system but aren’t automatically updated by the integration as it may affect workflows, SLAs, etc. Rather, information may be included in a work note so each system is aware of activity in the other, but the process is not potentially adversely affected by it.
• The integration needs to include mapping translations for field values that don’t match in usage across the systems. For example, if ServiceNow uses Priorities 1-4 and System X uses Severity 1-10, you’ll need to create a mapping matrix to map System X’s Severities into ServiceNow’s Priorities, and vice versa. (Also consider States, Categories, etc.)
• You’ll need to consider how Reference fields get populated and integrated, but I’ll discuss that more in the Good Practice Tips.

I’m including diagrams from the AT&T Incident eBonding I built for ServiceNow below. It details the integration flow for two scenarios: A “Proactive” incident initiated by AT&T, and a “Reactive” incident sent to AT&T. In both scenarios AT&T is the owner of the incident – responsible for the resolution, as the use case is AT&T owns the customer’s network and in the incident is network related.

Note the listing of updateable fields, and when, as well as uni and bidirectional flows of data.

The keys to a successful eBonding integration are the discussion of, and agreement on, the data what and when that will flow between the systems, and the rigorous test planning and testing of all lifecycle scenarios. These are vital to ensure you don’t break existing internal processes already developed and running in your ServiceNow environment.

Other Good Practice Tips

In addition to the primary design considerations outlined above, I recommend the following:

• While security is of the utmost importance, and is often the thing customers think about first, try to design and build your integration without the security layer, or use the most basic security possible. This allows you to prove out the design and confirm the connectivity first, and assumes you have sub-production environments to develop and test in. Security can almost always be layered in as a second step. This eliminates a layer to troubleshoot as you iterate your development.
• You’ll need to consider and account for integrating ServiceNow Reference fields *. As you know, these are fields that are stored as sys_ids in the integrating ServiceNow record, which is not likely to mean anything to the external system. Here are some guidelines for integrating Reference fields:
  • Consider if there is value in having the Reference data tables stored and maintained wholly in each system, so each is aware of the full dataset and mapping is an easier exercise. (There good reasons to do this, and reasons it’s often either impossible or a bad idea.)
  • Ensure that both systems have a field that uniquely identifies the reference in both systems. For example, for users records, email address may suffice.
  • Ensure that field data is included in the bidirectional payloads
  • Use the “Reference value field name” in your Web Service Import Set Transform Map Entry to use this field to choose the right ServiceNow reference record (using our out of box functionality again!)
  • Set up your Outbound Field Mapper to map the ServiceNow field to System X field, so that the external system doesn’t get the sys_id
  • And for goodness sake don’t try to use display value strings as unique identifiers!
• I suspect integrations that don’t use REST (or even SOAP) could use the same approach I’ve outlined. Even a file-based export could work the same, save for the nature of the outbound and/or inbound payloads.
• Wherever possible, the outbound integrations from ServiceNow should be run asynchronously. This is a general good practice with all integrations. For example, if the integration is triggered via a Business Rule, the Business Rule should be set to async if at all possible. This way the end user and the system (UI) do not wait on the integration to move forward, and the integration runs as system resources are available to it. The exception is if there is a business requirement for the system to wait on the integration, e.g. the end user is expecting to get a result back from the external system before proceeding. There are also technical reasons this can be a challenge: For example, you cannot run an async Business Rule on a comment or work note addition.
• Only use a Scripted Web Service if the inbound payload will not be in a name:value format that can easily map into a staging table, and rather requires scripting logic to manage the payload before injecting it into a ServiceNow record. Consider this a “last resort” in most cases.

Some of these points could warrant their own article; hopefully this article triggers your design thoughts and gives you ideas about how to manage your integrations.

Conclusion

Since its early days ServiceNow has had integration technologies built into, and fundamental to, the platform. Many a system has been integrated into ServiceNow in all shapes and flavors. While all kinds of new tools inside and outside of ServiceNow have attempted to simplify integrations, the “good old” ways still work when no other options exist (or existing options don’t quite fit the bill).