ServiceNow connects to an integration layer such as IBM webMethods in three patterns: synchronous API calls through the layer, asynchronous events through a message broker, and process-led orchestration where an engine such as Camunda owns a long-running flow. Each pattern fits a different kind of work and costs something different to run.
Direct connections to ServiceNow and where they stop working
#The simplest way to connect ServiceNow is direct: a ServiceNow script calls the API of a back-end system, or a back-end system calls the ServiceNow REST interface. For one or two stable interfaces, that is enough.
As the number of interfaces grows, each direct connection carries its own credentials, its own data mapping, its own retry logic and its own monitoring, split between two systems. When an interface fails, two teams read two logs. A change to one back end means a change in ServiceNow, and the other way round.
An integration layer takes that work out of ServiceNow and out of each back end. With IBM webMethods, Integration Server does the mapping and the routing, API Gateway publishes and protects the APIs, and Universal Messaging carries the messages. The layer can be the self-managed IBM webMethods Integration or IBM Integration SaaS, and the patterns below work the same way on both.
Pattern 1: synchronous calls through the integration layer
#How it works. ServiceNow calls an API that the integration layer publishes, for example on IBM webMethods API Gateway. Integration Server maps the request, calls one or more back-end systems and returns the answer while the ServiceNow user waits.
When it fits. Lookups and short actions where someone needs the answer on the screen: the contract status of a customer in an incident form, the owner of an asset, a check in another system before a change is approved.
What it costs to run. The layer and every system behind it must be available when ServiceNow calls, so the slowest system sets the response time the user sees. You need timeouts on both sides, a clear message for the user when a back end is down, and policies on the gateway for authentication and rate limits. One team owns the mapping, which is the point of the pattern.
Pattern 2: asynchronous events through a message broker
#How it works. ServiceNow sends a change, such as an incident created or a change request approved, to the integration layer as an event. The layer puts it on a message broker such as IBM webMethods Universal Messaging, and every system that needs it subscribes. In the other direction, events from the back ends arrive in ServiceNow as updates to its records.
When it fits. Updates that need no answer on the screen, changes that several systems consume, and systems that are not always available. Loading configuration items into the CMDB from discovery or asset systems is one example, often in batches.
What it costs to run. More components: a broker, its queues and their monitoring. And a new kind of failure: a message that arrives late, twice or out of order. Each consumer must be idempotent, and someone must watch the dead-letter queue and replay what failed. In return, one slow system no longer blocks ServiceNow.
Pattern 3: process-led orchestration with ServiceNow as one participant
#How it works. A process engine such as Camunda owns a flow that runs for hours or weeks and crosses several systems. ServiceNow is one participant. A service task in the BPMN process creates or updates a ServiceNow record through the integration layer, and an event from ServiceNow, such as an approval, moves the process on.
When it fits. Onboarding that spans HR, identity and equipment; a change that needs work in several systems in a fixed order; any flow where you must show afterwards which step ran when, and who decided.
What it costs to run. A further platform to operate, and a team that models BPMN. In return, the state of each long-running case lives in one place, with timeouts, escalations and compensation modelled in the process instead of scripted in several systems.
Should the workflow live in ServiceNow or in the process engine?
#ServiceNow has its own workflow tools, and a flow that runs mostly inside ServiceNow belongs there. The answer changes when most steps happen outside it. The state of the case is then spread across systems, and a process engine keeps it in one model that you can read, test and audit. Decide by where the steps happen, not by which team owns the request.
Choosing a pattern for each ServiceNow interface
#Choose the pattern for connecting ServiceNow per interface, not for the whole estate. An estate can use all three, each for its own kind of work. Three questions settle most cases.
- Does a user wait for the answer? Then use a synchronous call through the layer.
- Does the change go to several systems, or must it survive a system being down? Then send it as an event.
- Does the work take longer than a request and cross several systems with a state to track? Then let a process own it.
When an interface changes its nature, for example a lookup that grows into a multi-step approval, move it to the pattern that fits rather than stretching the old one. The same patterns apply across the ITSM, ITOM, CSM and HRSD workflows of ServiceNow and its Strategic Portfolio Management (SPM), on the ServiceNow AI Platform.
What to settle before you build any of them
#Five things decide whether a ServiceNow integration stays manageable, whichever pattern it uses.
- Ownership. One team owns each mapping, and everyone knows which team.
- A shared data model. Agree how an incident, a change and a configuration item look on their way through the layer, so each back end maps once.
- Credentials. Service accounts with the narrowest rights each interface needs, stored in one place and rotated.
- Monitoring and error handling. One view of each interface across ServiceNow and the layer, alerts that reach a person, and a written answer to who fixes a failed message and how it is sent again.
- Test environments. A ServiceNow sub-production instance connected to test back ends, and a test run against each ServiceNow release before production is upgraded.
How we connect ServiceNow to IBM webMethods, Camunda and Java services is on the page ServiceNow integration.
Questions
Should ServiceNow call our back-end systems directly?
Direct calls from ServiceNow suit one or two stable interfaces. Beyond that, an integration layer such as IBM webMethods owns the mapping, retries and monitoring in one place, instead of splitting them between ServiceNow and each back end.
When are asynchronous events worth the extra components?
Asynchronous events through a message broker are worth their extra components when several systems consume the same change, when a system is not always available, or when no user waits for the answer. The cost is a broker to run, idempotent consumers and a dead-letter queue that someone watches.
Should a long-running workflow live in ServiceNow or in Camunda?
A flow that runs mostly inside ServiceNow belongs in ServiceNow, and a flow whose steps happen mostly in other systems fits a process engine such as Camunda. In the second case, ServiceNow is one participant and the process keeps the state of each case in one model.
Which of the three patterns should we use?
Choose the pattern per interface, not for the whole estate: a synchronous call when a user waits for the answer, an event when a change goes to several systems, orchestration when the work runs long and crosses systems. An estate can use all three.
