- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2024 05:41 PM - edited 12-19-2024 07:18 PM
When working with integrations in ServiceNow, you may need to make asynchronous calls to third-party REST APIs. Asynchronous calls allow the system to process other tasks while waiting for the API response, improving performance and user experience.
Step-by-Step Implementation On Making Asynchronous REST API Calls Using ServiceNow Business Rules
1. Create a REST Message
- Navigate to System Web Services > Outbound > REST Message.
- Click New and configure:
- Name: Third Party API
- Endpoint: https://api.thirdparty.com/resource (Replace with the actual API endpoint)
- Define a REST message function:
- HTTP Method: POST (or GET, depending on the API requirements)
- Add required headers, query parameters, or request body.
2. Create a Business Rule
Create a business rule to trigger the asynchronous API call.
- Navigate to System Definition > Business Rules.
- Click New and configure:
- Name: Async API Call
- Table: The table you want to monitor (e.g., Incident).
- When: After (ensures the record is created before the API call).
- Use this script in the business rule's advanced tab:
(function executeRule(current, previous) {
var ga = new GlideAjax('AsyncApiProcessor');
ga.addParam('sysparm_name', 'invokeApi');
ga.addParam('sysparm_incident_id', current.sys_id.toString());
ga.getXMLAnswer(function(response) {
gs.info('Async call completed. Response: ' + response);
});
})(current, previous);
3. Create a Script Include
- Navigate to System Definition > Script Includes.
- Click New and configure:
- Name: AsyncApiProcessor
- Accessible From: All applications
- Use this script:
var AsyncApiProcessor = Class.create();
AsyncApiProcessor.prototype = {
initialize: function() {},
invokeApi: function() {
try {
var incidentId = this.getParameter('sysparm_incident_id');
var incident = new GlideRecord('incident');
if (incident.get(incidentId))
{
var restMessage = new sn_ws.RESTMessageV2('Third Party API', 'default'); restMessage.setStringParameterNoEscape('parameter1', incident.short_description);
restMessage.executeAsync();
gs.info('Async REST API request sent: Incident ID ' + incidentId);
return 'Request initiated successfully.';
}
}
catch (e)
{
gs.error('Error in AsyncApiProcessor: ' + e.message);
return 'Failed to initiate request.';
}
},
type: 'AsyncApiProcessor'
};
Testing the Integration
- Trigger the business rule by creating or updating a record.
- Verify logs in System Logs > All for request confirmation.
- Check the third-party API for the response.
Best Practices
- Use proper error handling and logging (gs.error, gs.info).
- Secure sensitive information with Encrypted Text fields or properties.
- Handle API retries and throttling gracefully.
Want to See It in Action?
For a live demo of how to implement this process step-by-step, check out my video on my YouTube channel, TechTalk with Bill. Subscribe for more hands-on ServiceNow tutorials and demos!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-12-2024 01:13 AM
Thank you for appreciating my post!
Generally, you should use async for API integrations in "2. Creating Business Rules" because it improves performance, scalability, and resilience.
Why Use async?
- Improved Performance: The business rule queues the API call and moves on, freeing up the system to handle other tasks.
- Non-blocking Operations: Transactions complete faster by offloading API calls to the background.
- Scalability: The system can handle more concurrent transactions without being blocked by slow API responses.
- Resilience to API Delays: External APIs with high latency won’t hold up other processes.
- User Experience: Users don’t experience delays caused by external API calls.
- Future-proofing: async supports modern, event-driven architectures and prepares your system for future integrations.
When to Be Cautious:
- Use synchronous processing only when the API response is crucial for the current transaction.
- Ensure robust error handling to manage async complexity.
In most cases, using async builds faster, more scalable, and resilient systems unless immediate results are essential.
Let me know if you'd like further clarification! 😊
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2024 04:59 PM
Hi, Bill!
Thank you for posting interesting content!
Let me ask you one question.
Is there a reason why I don't set "2. Creating Business Rules" to Async for asynchronous API integration?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-12-2024 01:13 AM
Thank you for appreciating my post!
Generally, you should use async for API integrations in "2. Creating Business Rules" because it improves performance, scalability, and resilience.
Why Use async?
- Improved Performance: The business rule queues the API call and moves on, freeing up the system to handle other tasks.
- Non-blocking Operations: Transactions complete faster by offloading API calls to the background.
- Scalability: The system can handle more concurrent transactions without being blocked by slow API responses.
- Resilience to API Delays: External APIs with high latency won’t hold up other processes.
- User Experience: Users don’t experience delays caused by external API calls.
- Future-proofing: async supports modern, event-driven architectures and prepares your system for future integrations.
When to Be Cautious:
- Use synchronous processing only when the API response is crucial for the current transaction.
- Ensure robust error handling to manage async complexity.
In most cases, using async builds faster, more scalable, and resilient systems unless immediate results are essential.
Let me know if you'd like further clarification! 😊
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-12-2024 03:59 PM
Hi, Bill!
Thank you for your reply.
My question was difficult to understand, so the intention of the question was misunderstood.
I'm really sorry.
I wanted to know the reason for setting the business rule of 2 as below.
When:After
Script:GlideAjax(async)
I thought that when I met asynchronous requirements, I would set my business rules to:
When:Async
If you don't mind, please let me know your thoughts.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-12-2024 06:16 PM
Hi @Tatsuki_sanpei ,
Thank you for raising this point. It is recommended to configure the "When" attribute to Async whenever possible, especially when working with asynchronous JavaScript calls, as demonstrated in the code example. However, since JavaScript is not a strongly typed language, you can adopt multiple approaches depending on the purpose of your query. For instance, in our example, we utilize "When" set to After, in combination with executeAsync calls, to achieve the desired outcome.
Hope this helps, let me know if you have further questions you can always book me for a call for additional guidance. 😊
Thanks,
Bill