Business Rules


A business rule is a mechanism used to run processes when an event occurs in an Product name - ev itsm.png database table, e.g. when a record is created or when its fields are modified.

These processes are arranged in a sequence of actions performed in steps defined in the graphic editor. They start when the SQL trigger condition associated with the business rule is fulfilled. A debugging tool enables you to monitor the progress of the processes.

Each step:

  • Describes the type of action to be performed. These are automatic actions that do not require user intervention.

    Example documentation icon EN.png Sending an email, calling a SOAP web service or a REST API

  • Can be performed one after another or at the same time as other steps.
  • Can be associated with entry conditions (conditional steps).
  • Can store information in the form of instance variables which can be used later on in the process.

Example

When a new asset is added or when an asset is assigned to a new user, a notification email is sent to the Asset Manager. In both cases, the contents of the email is identical ==> How can you define business rules using a common process?

1. Create two business rules:

  • Business rule 1, triggered when a new Equipment form is created:
    • Main table is AM_ASSET, triggered on insert
  • Business rule 2, triggered when the Next User field in the existing Equipment form is updated:
    • Table is AM_ASSET, triggered on update of the NEXT_USER_ID field 

2. Associate the same process by creating the following steps:

  • One Start step
  • One Send Email step:
    • Email is sent to the Asset Manager
    • Message body contains the equipment reference and update date
  • One End step

Notes

  • You manage business rules via different parameters in the Other Parameters menu. The prefix of these parameters is {ADMIN} BR (Business Rule).
  • Creation events involving IT service requests are managed by workflows, not business rules. 
  • You can define a business rule in two steps. First, you declare the business rule. Next, you associate the process that should be run.
  • You can define processes:
    • Individually: In this case, they are available to all business rules using the same table but they are not active as long as they are not associated with a business rule.
    • Directly in a business rule: In this case, they are directly associated with the business rule but are also available to other business rules using the same table.
  • A process defined using a given table can be associated with one or more business rules defined using the same table.
  • Any modification made to a related process will automatically apply to all of the business rules with which it is related.
  • A related process cannot end early. It must always run until the End step.
  • Business rules whose processes are unable to run until the end are placed in the Error filter in the list of rules. This can be:
    • A business rule whose SQL trigger condition is incorrect.
    • A business rule whose process steps are inconsistent.

Best Practice big icon.pngBest practice

  • To make it easier for you to create business rules, aliases (templates) have been provided by Logo - EasyVista.png. We recommend that you use them whenever possible and that you modify the SQL trigger condition if required.

    Example documentation icon EN.png Use the standard Incident alias and modify the SQL condition by defining a rule applicable only to the status, Suspended.

  • Once you have modified the SQL trigger condition of a standard alias, you should save it as a new alias. This enables you to create customized business rule templates.
  • Create related processes that can be used by several business rules. You can then associate them with different rules without having to reconfigure the steps in the processes.
  • Use the debugging tool to monitor the progress of processes associated with business rules found in the Error filter.
  • You should comply with the following recommendations to ensure optimal performance when the process is run.
    • You should always define a trigger condition in order to limit calls to the process. You should move existing tests in the process to this condition.
    • Avoid triggering all of the fields in the table to avoid looping the process, especially when updating data. If a business rule is triggered when a given field is updated, avoid updating this field during an internal update.
    • Avoid processes that may trigger other business rules.
    • Avoid creating too many business rules for tables with large data volumes, e.g. AM_ACTION or SD_REQUEST.
    • Create several simple processes instead of one complex process and define one trigger condition for each process.
    • Optimize the SQL code by avoiding queries that contain sub-queries and by using joins in processes. Open url.png To find out more, see the rules on defining SQL queries.
    • Test the business rule in the test or acceptance environment before using it in the production environment.
    • Go through the whole execution log. Check that each business rule is run in the shortest possible time to avoid interactions, e.g. a given rule is run again even though it was not completed when it was last run. Processed business rules may contain execution errors.

Screens description

Definition of Business Rule

Menu access: Administration > Business Rules > Definition

Step 1
         Business rule - step 1.png

Use an Alias: Business rule template used to initialize the information for a new rule, such as the main table, the fields affected when the rule is triggered on update and the SQL trigger condition. You can modify this information subsequently.

  • A list of standard aliases is provided by Logo - EasyVista.png.
  • Once you have modified the SQL trigger condition of a standard alias, you should save it as a new alias (step 3).

Table (Note: This is automatically loaded and is non-modifiable when an alias is selected): Name of the main table used by the business rule for defining the SQL trigger query and filtering the processes associated with the rule, i.e. only those defined using the same table.
 

Step 2
        Business rule - step 2.png

Description: Name of the business rule. 

Active: Used to indicate whether or not the rule is active. The trigger condition is evaluated only if the rule is active.

Force Execution during the Integration: When the business rule is run and the related processes affect fields updated by an external data import (e.g. integration of the LDAP directory), this indicates whether the imported values should be replaced by values in Product name - ev itsm.png (box is checked) or whether they should be kept (box is not checked).

Comment: Comment explaining how the business rule works. 

Table (Note: Non-modifiable, selected in the previous step): Name of the main table of the business rule.

On Insert/On Update: Used to indicate whether the rule should be run when a record is created or when one or more fields in the main table are updated. If you select the On Update option, you must specify the fields whose update will trigger the business rule.

[ EDIT CONDITION ] (Note: Only for modifying the SQL trigger condition of the alias)
        Business rule - SQL Condition.png

  • MSSQL/Oracle: SQL Condition: SQL instruction that describes the trigger condition of the business rule. Enter the condition in the text box corresponding to the environment of your database (SQL or Oracle) and click [ SAVE CONDITION ]. Note: MSSQL syntax must always end with BEGIN @@FIRETRIGGER@@ END.
  • [ SAVE AS ALIAS ]: Used to save the business rule as a template to initialize information for new business rules using the same table. 

Step 3
        Business rule - step 3.png

[ CREATE A NEW PROCESS ]: Used to create a new process automatically associated with the rule. It will also be available for other rules defined using the same main table.

Plus icon.png : Used to associate a process with a business rule. Note: Only processes using the same main table as the one used by the business rule are available.

Edit form icon.png : Used to open the graphic editor in edit mode and define the steps in the process. Note: Modifications are taken into account by all business rules with which the process is associated. 

Display popup icon.png : Used to open the graphic editor in preview mode.
 

Defining a process associated with a business rule

BusinessRuleProperties

        Business rule - Associated process.png

Menu access: Administration > Business Rules > Related Processes, in the graphic editor, double-click the Start step Graphical process editor - Start step icon.png or click Graphical process editor - Toolbar - Process properties icon.png

Name: Name of the process. 

Target Table: Name of the main table that defines the context in which the process is used. Only business rules using the same main table can be associated with the process.

Parent Query: Parent query used in the process that enables you to define the available tags and roles for each step.

Keep a Trace of the execution: Used to indicate if the debugging mode is enabled for monitoring the progress of the process using log files (box is checked) or not (box is not checked). Note: To view the log files: Administration > Business Rules > Monitoring.

BusinessRulePropertiesEnd

Procedures and Wizards

How to create a business rule

 Select Administration > Business Rules > Definition in the menu and click Add icon.png.

2. Define the configuration of the new rule and click [ NEXT ] to move on to the next window.

  • Step 1: Select the most suitable alias for the new business rule to initialize the SQL trigger condition.
  • Step 2:
    • If you select the On Update option, you must specify the fields whose update will trigger the business rule.
      • You can select the All the table's fields option if the rule should be run when any table field is updated.
      • You can select the fields you want manually from those associated with the main table. Click Plus icon.png to add a new field.
    • To modify the SQL condition that will trigger the business rule, click [ EDIT CONDITION ]. Once you have made the required modifications, click [ SAVE CONDITION ].
  • Step 3: Specify the processes to be run when the business rule is triggered.
    • To define a new process:
      • Click [ CREATE A NEW PROCESS ].
      • Specify the properties of the process and click [ SAVE ]. The table of related processes will be refreshed.
      • Click Edit form icon.png in the table.
      • Define and configure the steps in the related process using the graphic editor.
         
    • To add another process, click Plus icon.png.
    • To select an existing process, click N/A in the table. Only processes whose parent query uses the same main table as the one used by the business rule will be available.

3. Click [ SAVE AS ALIAS ] to save the business rule as a new template.

4. Click [ SAVE ] to save the new business rule.

How to define the priority level of business rules

1. Select Administration > Business Rules > Definition in the menu and display the list of business rules.

2. You can enter the priority level of each business rule manually to define the order in which it should be run.

  • Select the first rule in the sequence. Select the Priority Level wizard and enter priority level 1. Click [ FINISH ].
  • Select the second rule in the sequence. Select the Priority Level wizard and enter priority level 2. Click [ FINISH ].
  • Repeat this procedure for each rule in the sequence.

3. You can use the data entry wizard to define the sequence of business rules based on a reference rule.

  • Select the first rule in the sequence. Select the Priority Level wizard and enter priority level 1. Click [ FINISH ].
  • Select another business rule in the sequence.
    • Select the Priority Level wizard.
    • Select the Reference Business Rule by clicking N/A. The list of business rules linked to the same main table will be displayed with their priority level. Select the rule you want.
    • Specify if the new rule in the sequence should be run before, at the same time or after the reference business rule. The priority level of the new rule will automatically be calculated.
    • Click [ FINISH ].
  • Repeat this procedure for each rule in the sequence and define its order based on a reference rule.

How to debug a process associated with a business rule

1. Specify the process to be debugged.

  • Select Administration > Business Rules > Related Processes in the menu and open the process you want to debug.
  • Select the Keep a Trace of the execution box and save the process.

2. Once you have run the business rule associated with this process, select Administration > Business Rules > Monitoring.

Wizards

Business rules

Enable: Used to enable the business rule and test its trigger condition. 

Disable: Used to disable the business rule, its trigger condition will no longer be tested.

Best Practice icon.png To see disabled business rules, select the Archived filter.

Business Rule Editor: Used to open the window for defining the business rule. 

Priority Level: Used to define the order in which a given business rule should be run as compared with other rules using the same main table. You can enter a priority level manually for each business rule or you can define its order in the sequence based on a reference rule.

Delete (Note: Only for elements not used in the application): Used to delete the business rule. Note: This does not delete processes associated with the business rule.

Related Processes

Delete: Used to delete the process. Note: You should first delete all links between the process and business rules by selecting Administration > Business Rules > Definition.

Tags:
Last modified by Unknown User on 2017/03/17 15:44
Created by Administrator XWiki on 2013/03/25 18:11

Shortcuts

Recent Updates

Haven't been here in a while? Here's what changed recently:

-   Product name - ev itsm.png
-   Product name - ev sas.png

Interesting Content

How to Automate Integration
Add a Shortcut to an App
History
Quick Dashboard
Full text search - Stop Words

Powered by XWiki ©, EasyVista 2018