business rule options

[Dinesh Kumar C]

I see 4 options in Business rules . Before After Async Display . I understood definitions of these but i would like to know what exactly one differs from another and will anyone explain with an example . Thank you  

[Arindam Ghosh]

Hi Dinesh,

Go through the link once all that provided above.

Most of your doubt will be clear.I will   explain still if you have doubts.

Thanks,

Arindam

[Ujjawal Vishnoi]

Hi Dinesh,

Business rule are kind of database trigger, that means whenever you are doing some CRUD operation on database then it runs. I will take the case of update here.

If you want run some piece of code just before updating in the database then we use before business rule. In this type of case we are concerned that our code should run first and then database update the record.

On the other hand we want that our code run just after it has been update in the database. May be you updated some values on the form and you want to use updated values in the script of BR. In such scenarios we go with after BR.

In we are not concerned about the timing to run BR script and want to enhance user experience. If we go with this approach then an entry gets created in sys_trigger (schedule job) and responsibility to run this code is depend on availability of the engine which run schedule job.   In such scenarios we go with async BR.

Lastly, when we want to send some variables available for client side script from server side then we can send such scratchpad variable by display business rule.

Hope this helps.

Regards

Ujjawal

[PriyaRanji]

Hi Dinesh,

Good Day

Please find the details highlighted below for your reference.

The following options are provided to determine the time the business rule should run.

Option   When the Rule Runs

Before   After the user submits the form but before any action is taken on the record in the database.

After         After the user submits the form and after any action is taken on the record in the database.

Async       When the scheduler runs the scheduled job created from the business rule. The system creates a scheduled job from the business rule after the user submits the form and after any action is taken on the record in the database.

Display Before the form is presented to the user, just after the data is read from the database.

Note: Asynchronous business rules do not have access to the previous version of a record. Therefore, these GlideElement methods do not work with async rules: changes(), changesTo(), changesFrom().

The following options are provided to determine the database operation that the system takes on the record.

Option   When the Rule Runs

Insert       When the user creates a new record and the system inserts it into the database.

Update   When the user modifies an existing record.

Query     Before a query for a record or list of records is sent to the database. Typically you should use query for before business rules. See Before-Query example.

Delete   When the user deletes a record.

Before Query Business Rule:

You can use a query business rule that executes before a database query is made to prevent users from accessing certain records. Consider the following example from a default business rule that limits access to incident records.

Name: incident query

Table: Incident

When: before, query

Script:

if(!gs.hasRole("itil") && gs.isInteractive())
{
var u = gs.getUserID();
var qc = current.addQuery("caller_id",u).addOrCondition("opened_by",u).addOrCondition("watch_list","CONTAINS",u);
gs.print("query restricted to user: " + u);
}

This example prevents users from accessing incident records unless they have the itil role are listed in the Caller or Opened by field. So, for example, when self-service users open a list of incidents, they can only see the incidents they submitted.

Display business-rules

• Display rules are processed when a user requests a record form.
• The primary objective of display rules is to use a shared scratchpad object, g_scratchpad, which is also sent to the client as part of the form.
• This can be useful when you need to build client scripts that require server data that is not typically part of the record being displayed.
• In most cases, this would require a client script making a call back to the server.
• If the data can be determined prior to the form being displayed, it is more efficient to provide the data to the client on the initial load.
• The form scratchpad object is an empty object by default, and used only to store name:value pairs of data.

To populate the form scratchpad with data from a display rule:

// From display business rule

g_scratchpad.someName = "someValue";

g_scratchpad.anotherName = "anotherValue";

// If you want the client to have access to record fields not being displayed on the form

g_scratchpad.created_by = current.sys_created_by;

// These are simple examples, in most cases you'll probably perform some other

// queries to test or get data

To access the form scratchpad data from a client script:

// From client script

if(g_scratchpad.someName == "someValue") {

  //do something special

}

Hope you got some idea! Refer to the links provided by friends above it provides more information and helps you out .

Please hit it as helpful/correct/like based on the impact.

Thanks,

Priyanka R

[dettemanon]

Thank you for the information! I have been looking for articles on this topic for a long time and have come across this topic. A lot of things became clear immediately.
Although many questions still put me at a dead end, I am afraid to take active actions in business. My friend, who already has his own company, calms me down and says everything will work out. It would be best if I learned how to delegate authority correctly. For example, to not be distracted by questions about software programs, should contact the company that will provide it — getparthenon.com. Plus, they will always provide technical support.
Do you think it is important to distribute tasks correctly in business?