Service Catalog Cart API

[Jim60]

I've created a scripted rest api which submits a catalog item similar to the code found here: https://docs.servicenow.com/bundle/jakarta-application-development/page/script/server-scripting/reference/r_ServiceCatalogScriptAPI.html
(I did it this way as I wanted to provide access to submit a specific item with a single API call, in this case will only create one RITM.)

My problem is that cart.placeOrder() does not just create the request and return, it runs the entire catalog item workflow before returning the request number.  How can I detach the API call from the workflow?  (currently the workflow is all automation tasks and can take some time to complete.)

[Jace Benson]

So you want to queue the generation of the order, or you want the REQ to generate and the RITM to wait?

[Jim60]

Hello Jace, 

I want the API to return as soon as the REQ/RITM are created. I do not want the API to be stuck waiting until the RITM workflow is complete. 

I was able to improve this by setting up a task with an async Business Rule and a Wait condition until that task is closed.  The async rule allows the API to be released but I wish I could think of a better way.

Thanks

[Jace Benson · Accepted solution]

Ah, yea, if the item is just to run script or create an approval or a task, adding a timer for 1 second with move it the event queue from the current session. 

At least, that's the way I've gone around making items submit faster.

Workflow Best Practices : https://hi.service-now.com/kb_view.do?sysparm_article=KB0680098

How does a workflow timer help: https://hi.service-now.com/kb_view.do?sysparm_article=KB0647534

Text below;

# Scenario

On a ServiceNow instance a user can trigger the creation of a record, which in turn triggers a running Workflow and can also cause Business Rules and Script-Includes to execute. 

Occasionally, unexpected behavior occurs due to either long running Business Rules or Workflow Script execution.

One of the solutions available to implement is to place a one second timer. However, the question remains: How does a Workflow Timer help, and why is it used as a solution?

 
# What does a Workflow Timer do?

When a Workflow Timer runs for the first time a Scheduled Job is created. All Scheduled Jobs are stored in a table called sys_trigger.

A triggered Workflow Timer is stored on a table called wf_executing.

When the Scheduled Job is created, the timer activity is referenced in the document_key field of the sys_trigger record.

The Scheduled Job remains in the sys_trigger table until the timer duration is completed. The duration of the timer activity depends on the duration set on the timer itself, based on user configuration.

Once the duration is completed, the Scheduled Job runs and sends an event back to the Workflow to notify it, and the Workflow continues to run the next activity in line.

 
# Impact of the Workflow Timer

The Scheduled Job for the timer is run by a system user, and as all Scheduled Jobs, they are run in the background. 

This means that every script execution is run by system user and is also run in the background on the system scheduler. This allows Business Rules, Script-Includes and Workflow Scripts to run asynchronously, which allows for better system performance.

Also, having a timer activity in the workflow allows the system to stop and commit changes to the database after the last activity. By design, the Workflow Engine only commits changes in the database for the current object held in memory.

[Jim60]

Thank you.