Business Rules


Definition

A business rule is a mechanism used to run processes when an event occurs in an Service Manager database table, e.g. when a record is inserted or when its fields are modified.

EndDefinition

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  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

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

    example  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 EasyVista.
  • 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 Service Manager (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 based on the environment of the database (SQL or Oracle)
    • 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

 

Step 1: Create the business rule.

1. Select Administration > Business Rules > Definition in the menu.

2. Click Add icon.png.
 

Step 2: Specify the business rule parameters.

1. Specify the parameters of the step 1.

  • Select the alias for the rule to initialize the SQL trigger condition.
  • Click Next.

2. Specify the parameters of the step 2.

  • If you have 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
  • Click Next.

3. Specify the processes to be run when the business rule is triggered in step 3.

  • Click Create a New Process.
  • Specify the properties.
  • Click Save.
    The table of related processes will be refreshed.
  • Click Edit form icon.png next to the new process.
  • Configure the steps in the related process using the graphic editor.
     

Adding a process

  • Click Plus icon.png.
     

Modifying a process

  • Click N/A link in the table.
    Only processes whose parent query uses the same main table as the one used by the business rule will be available.

4. Save the new business rule by clicking Save.

Note: Click Save as Alias to save the business rule as a new template.

How to define the priority level of business rules

Step 1:Display the business rules.

1. Select Administration > Business Rules > Definition in the menu.
 

Step 2: Define the rules sequence.

Manually by using the priority levels

1. Select the first rule in the sequence.

  • Launch the Priority Level wizard.
  • Enter the priority level 1.
  • Click Finish.

2. Select the second rule in the sequence.

  • Launch the Priority Level wizard.
  • Enter the priority level 2.
  • Click Finish.

2. Repeat these actions for each rule in the sequence.

 

By using the data entry wizard to define the sequence of business rules based on a reference rule.

1. Select the first rule in the sequence.

  • Launch the Priority Level wizard.
  • Enter the priority level 1.
  • Click Finish.

2. Indicate the reference business rule.

  • Select another business rule in the sequence.
  • Launch the Priority Level wizard.
  • Click on the N/A hyperlink on the Reference Business Rule field.
    The list of business rules linked to the same main table will be displayed with their priority level.
  • Click on the reference business rule.

3. Define the order of each business rule based on the reference business rule.

  • Select the option you want: before, at the same time or after the reference business rule.
    The priority level of the new rule will automatically be calculated.
  • Click Finish.

How to debug a process associated with a business rule

Step 1: Select the process to be debugged.

1. Select Administration > Business Rules > Related Processes in the menu.

2. Open the process you want to debug.

3. Check the Keep a Trace of the execution box.

4. Save the process.
 

Step 2: Consult the report monitoring.

1. Wait for the execution of the business rule associated with the process.

2. Select Administration > Business Rules > Monitoring - History.

3. Click Display popup icon.png next to the process to display the details of its execution.

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 2021/02/11 19:12
Created by Administrator XWiki on 2013/03/25 18:11

Shortcuts

Powered by XWiki ©, EasyVista 2021