Different Ways to Implement Asynchronous Inbound APIs in ServiceNow

[Daxin]

As discussed in the previous post, embracing asynchronous integration patterns is crucial for designing scalable, high-performing ServiceNow instances. The core principle remains consistent: acknowledge external requests instantly, then process the data in the background, preventing user session blocks, avoiding timeouts for long running jobs and optimizing system resources.

This article is about to explore various this can be achieved.

Out-of-the-Box Capabilities

1.Import Set APIs

• Mechanism: The most widely used and often default method for inbound data integrations. When an external system sends data to an Import Set API endpoint, ServiceNow receives and loads it into a staging (import set) table.
• Asynchronous Processing: ServiceNow sends an immediate success response back to the requesting system. The actual transformation of this staged data into your target tables (e.g., Incident, CI, User) occurs asynchronously via Transform Maps. Thus, completely decoupling the inbound API call's thread from the data processing.
• Ideal for: Bulk data loads, periodic synchronizations, and scenarios where immediate real-time updates to the target table are not strictly necessary.

 2. REST API Trigger - Asynchronous (Integration Hub)

• Mechanism: Flow Designer's REST API Trigger allows you to create dedicated endpoints that initiate a flow. When an external system sends a message to this endpoint, ServiceNow immediately responds with an HTTP 200 OK and returns the flow's execution_id.
• Asynchronous Processing: All subsequent steps defined within the flow are executed asynchronously by the Flow Engine in the background. The external system receives quick confirmation and can continue its process without waiting for the flow to complete.
• Ideal for: Any inbound REST API where you need to implement custom logic with low-code/no-code simplicity. This approach significantly speeds up implementation and enhances maintainability, though it requires an Integration Hub subscription.

Custom Implementation Approaches

1.Scripted REST/SOAP APIs with Event Processing/Staging table

• Mechanism: For highly customized inbound logic, you can build Scripted REST or SOAP APIs. Upon receiving an external API request, your script quickly extracts necessary data and immediately either triggers an event using gs.eventQueue() passing relevant data as parameters or insert the data into a staging table.
• Asynchronous Processing: Your Scripted API can then send an immediate, custom acknowledgment back to the calling system (e.g., a specific status code or a unique transaction ID). Subsequently, a Script Action (for events) or a Business Rule / Flow Designer flow (for staging table processing) can be configured to run in the background, handling the complex processing when they are triggered. 
• Benefit: Offers maximum flexibility in defining the immediate response message sent to the calling system, allowing for custom acknowledgment formats and status codes. It completely decouples the API acknowledgment from the potentially long-running processing logic.

2.Scripted REST/SOAP APIs with Asynchronous Subflows

• Mechanism: This combines the flexibility of Scripted APIs with the power of Flow Designer. Instead of triggering an event, your Scripted API directly invokes a Flow Designer subflow asynchronously.
• Asynchronous Processing: The key is using the inBackground() method when calling the subflow:

// Example: Invoking a subflow asynchronously

sn_fd.FlowAPI.getRunner().subflow('global.my_async_subflow').inBackground().withInputs(inputs).run();

This ensures the subflow executes in a separate thread, allowing your main API script to return an immediate response.

• Benefit: This option offers the best of both worlds: fine-grained control over the inbound API's immediate response (via scripting) combined with the low-code development, visual process management, and easier maintenance benefits of Flow Designer for the actual data processing.

Conclusion:

These are some of the options to implement asynchronous inbound integration. Ultimately, your choice should always consider factors like integration complexity, required response times, data volume, team expertise, and adherence to your organization's broader integration strategy and maintenance models. By carefully weighing these aspects, you can implement inbound APIs that are not only functional but also highly efficient and resilient.