A business rule presents a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried. Using business rules enables us to accomplish tasks like automatically changing values in form fields when certain conditions are met, or to create events for email notifications and script actions.
Business rules can make use of scripts to take actions on records in the database. However, there are several other scripting options available on the ServiceNow platform, such as client scripts and UI actions. This article will guide you through the process to get a deeper insight into the topic.
When option
The When option determines when Business Rule logic executes in relation to the database access:
before
after
async
display
IMPORTANT: Business Rules do NOT monitor forms. The forms shown in the graphics on this page represent a user interacting with the database by loading and saving records in a form.
Before
Before Business Rules execute their logic before a database operation occurs. Use before Business Rules when field values on a record need to be modified before the database access occurs. Before Business Rules run before the database operation so no extra operations are required. For example, concatenate two fields values and write the concatenated values to the Description field.
After
After Business Rules execute their logic immediately after a database operation occurs and before the resulting form is rendered for the user. Use after Business Rules when no changes are needed to the record being accessed in the database. For example, use an after Business Rule when updates need to be made to a record related to the record accessed. If a record has child records use an after Business Rules to propagate a change from the parent record to the children.
Async
Like after Business Rules, async Business Rules execute their logic after a database operation occurs. Unlike after Business Rules, async Business Rules execute asynchronously. Async Business Rules execute on a different processing thread than before or after Business Rules. They are queued by a scheduler to be run as soon as possible. This allows the current transaction to complete without waiting for the Business Rules execution to finish and prevents freezing a user’s screen. Use Async Business Rules when the logic can be executed in near real-time as opposed to real-time (after Business Rules). For example use async Business Rules to invoke web services through the REST API. Service level agreement (SLA) calculations are also typically done as async Business Rules.
To see async Business Rules queued up for execution, use the Application Navigator in the main ServiceNow window (not Studio) to open System Scheduler > Scheduled Jobs > Scheduled Jobs. Look for Scheduled Job names starting with ASYNC. They go in and out of the queue very quickly and can be hard to catch on the schedule.
DEVELOPER TIP: Use async Business Rules instead of after Business Rules whenever possible to benefit from executing on the scheduler thread.
Display
Display Business Rules execute their logic when a form loads and a record is loaded from the database. They must complete execution before control of the form is given to a user. The purpose of a display Business Rule is to populate an automatically instantiated object, g_scratchpad. The g_scratchpad object is passed from the display Business Rule to the client-side for use by client-side scripts. Recall that when scripting on the client-side, scripts only have access to fields and field values for fields on the form and not all of the fields from the database. Use the g_scratchpad object to pass data to the client-side without modifying the form. The g_scratchpad object has no default properties.
Business Rule Process Flow
A table can have multiple Business Rules of different When types. The order in which the Business Rules execute is:
In the end I would recommend the ServiceNow Application Developer course. In case of development and consultancy, just contact us.
Comentarios