After Business Rule Order 1000 versus Async Business Rule

[ryanbalcom]

What is the performance difference between an after business rule with an order of 1000 versus a Async business rule with order 100?

I suspect they are equivalent because when I run the business rule debugger it appears that after business rules with an order of 1000 run asynchronously?

Business Rules Best Practices - ServiceNow Wiki

http://wiki.servicenow.com/index.php?title=Execution_Order_of_Scripts_and_Engines#gsc.tab=0

[antin_s]

Hi Ryan,

How are you saying the BR runs asynchronously? User waits for response from both Before and After Business Rules? Are you saying the response comes back to user without even executing the 'After' business rule?

Hope this helps. Mark the answer as correct/helpful based on impact.

Thanks

Antin

[ryanbalcom]

Antin,

Thanks for taking the time to respond! I am seeing what appears to be an after business rule with order 1000 (Create PIR for MI Tickets) running as an ASYNC business rule be examining the Debug Business rule log.

Example:

14:59:43.131: Finished executing after update business rules on incident:INC005738671 before engines (order <1000)

14:59:43.166: Execute after update business rules on incident:INC005738671 after engines (order >=1000)

14:59:43.167: Execute before insert business rules on sys_trigger:ASYNC: Create PIR for MI Tickets before engines (order <1000)

14:59:43.168: Global       ==> 'myBusinessRule1' on sys_trigger:ASYNC: Create PIR for MI Tickets

14:59:43.168: Global       <== 'myBusinessRule1' on sys_trigger:ASYNC: Create PIR for MI Tickets

14:59:43.168: Global   Customer Updated       === Skipping 'myBusinessRule2' on sys_trigger:ASYNC: Create PIR for MI Tickets; condition not satisfied: Condition: current.name == "Open Cloud Import"

14:59:43.168: Global   Customer Updated       === Skipping 'myBusinessRule3' on sys_trigger:ASYNC: Create PIR for MI Tickets; condition not satisfied: Filter Condition: nameSTARTSWITHASYNC: RescheduleModel^EQ

14:59:43.169: Global   Customer Updated       === Skipping 'myBusinessRule4' on sys_trigger:ASYNC: Create PIR for MI Tickets; condition not satisfied: Filter Condition: script=SNC.ServiceMappingFactory.recomputeLayer(current);^EQ

14:59:43.169: Finished executing before insert business rules on sys_trigger:ASYNC: Create PIR for MI Tickets before engines (order <1000)

14:59:43.171: Execute after insert business rules on sys_trigger:ASYNC: Create PIR for MI Tickets before engines (order <1000)

14:59:43.171: Global       === Skipping 'myBusinessRule5' on sys_trigger:ASYNC: Create PIR for MI Tickets; condition not satisfied: Condition: current.system_id == "ACTIVE NODES" || current.system_id == "ALL NODES" || (previous != null && (previous.system_id == "ALL NODES" || previous.system_id == "ACTIVE NODES"))

14:59:43.172: Global       ==> 'myBusinessRule6' on sys_trigger:ASYNC: Create PIR for MI Tickets

14:59:43.172: Global       <== 'myBusinessRule6' on sys_trigger:ASYNC: Create PIR for MI Tickets

14:59:43.172: Finished executing after insert business rules on sys_trigger:ASYNC: Create PIR for MI Tickets before engines (order <1000)

14:59:43.172: Finished executing after update business rules on incident:INC005738671 after engines (order >=1000)

[antin_s · Accepted solution]

Hi Ryan,

Yes, I get your point. But there shouldn't be any difference from the end user perspective for the 'After' Business Rules with order less than 1000 and more than 1000 (except the order in which they execute).

Hope this helps. Mark the answer as correct/helpful based on impact.

Thanks

Antin

[Kalaiarasan Pus]

Internally, Async rule are run as scheduled jobs. It creates a entry in sys_trigger table in the system.

You can verify if after rule creates a entry on this table or not. I hope it doesn't and clears your doubt.

[The SN Nerd]

The only real performance difference is in the UI.

After business rule - Control is not returned to the user until the business rule is complete. The code is executed in the foreground.

Async business rule - Control is returned immediately to the user. The code is executed in the background.