So a few weeks ago, Harriet (seen at right) was talking with me about some customizations she was making to Discovery. Part of that customization involved making a few business rules, and this reminded her of a long-standing question she had. "What on earth" she asked "does it mean when I select async for when a business rule runs? And why would I ever want to make that choice, whatever it means?"
Harriet knew all about our Wiki page on Business Rules; that was how she learned out to do them in the first place. But what it says about async business rules just wasn't clicking with her. They remained a deep mystery, and this mystery was causing her to lose sleep.
Well, ok, I made up that last part. But here's the answer I gave her:
If you're not familiar with the term async, it's short for asynchronous, which in turn means not synchronous, or not happening at the same time. In the context of a business rule, what this means is that the script inside the business rule doesn't run at the same time.
Let's use an example (at right, click to enlarge) to illustrate.
This business rule is triggered whenever a record in the Change Request table is updated, and the condition below is met:
current.category=="Service-now Deployment"&& current.approval=="approved"&& current.state=="2"
The condition is evaluated synchronously, meaning at the same time the record is updated. For async business rules, the condition is always evaluated after the database operation (the update, in the case of our example). It's what happens next that differentiates the async business rules...
For other kinds of business rules, the script inside the business rule is executed synchronously, or at the same time that the business rule is triggered. This is the behavior you're familiar with. If our example was an after business rule instead of an async business rule, its script would run at the same time the business rule was triggered.
For async business rules, however, this is not the case. Instead, when an async business rule is triggered, all that happens is that a scheduled job is created to run the script in the business rule as soon as possible, but at some point in the future. This could be a second or two, or several minutes, or even more — it depends on how many scheduled jobs are backlogged at the moment the business rule runs.
Ok, that's what happens — but why would you want to do this? Our example shows a great reason: the script in this business rule makes a web services call. This might take several seconds to run. If this business rule were not asynchronous, the update of the user's screen would pause while the script making the web services call ran. That's the main reason to use an async business rule: to do something that takes longer than you'd like the user to wait, and that doesn't have to be done before the user's screen is updated.
So, Harriet, there you go!
8 Comments
