Definition

EndDefinition

• Processes are arranged in a sequence of actions performed in steps.
• Steps of the process are defined and configured using a graphic editor.  See Characteristics of steps of a process.
• They are associated with action types using to define the handling to be performed. These are only automatic actions that do not require user intervention.
• They are triggered when a SQL condition associated with the business rule is fulfilled. A debugging tool enables you to monitor the progress of the processes.

Example

Use a business rule to send the same email to the Asset Manager when a new asset is added or when an asset is assigned to a new user.

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

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

Caution

• Creation events involving IT service requests are managed by workflows, not business rules. 

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

Menu access

• Business rule: Administration > Business Rules > Definition

• Process associated with a business rule: Administration > Business Rules > Related Processes. Then in the graphic editor, double-click the Start step or click

Screens description

Definition of business rule

Step 1
         

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
        

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)
        

• 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
        

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.

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

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

: Used to open the graphic editor in preview mode. 

Definition of a process associated with a business rule

BusinessRuleProperties

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 .
 

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  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  next to the new process.
• Configure the steps in the related process using the graphic editor.
   

Adding a process

• Click .
   

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

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