Business rules

1
 Document history
Version Date Author Changes made
1.0 7/18/2010 Laurent SEYMAN Document creation
1.1 10/5/2012 Laurent SEYMAN Addition of the best practices
1.2 10/11/2012 Laurent SEYMAN New template 2012
1.3 8/14/2013 Laurent SEYMAN Update for EasyVista 2013

The present document covers EasyVista's business rules that are available from the Business rules menu of the
Administration module. It constitutes a collection of business rules implemented during work carried out on our customers'
premises and for our partners. Also, its content may constantly change.

2
Index
A. Definition 5

B. Functioning principle 5

C. Stages in creation 5
C.1. Defining the business rules........................................................................6
C.2. Managing the associated processes.........................................................7
C.3. Testing the business rule............................................................................8

D. The business rules present as standard 9

D.1. Send mail to supports/groups with actions to complete.........................9
D.2. Calculate the time needed to start the processing of an incident........11
D.3. Calculate the processing time of an incident by an outsourcer...........14

E. Examples of implemented business rules 18

E.1. Update the employees manager with the department manager..........18
E.2. Copy the requested start date..................................................................20
E.3. Notification to the requestor when his/her incident
is being processed....................................................................................21
E.4. Notifying the requestor when the incident is redirected
or escalated................................................................................................22
E.5. Automatic reopening of suspended incidents........................................25
E.5.1. Configuring the scheduled alert 25
E.5.2. Creation of the WebService 27
E.5.3. Configuring the business rule 29

E.6. Updating the group in charge of the incident.........................................30

E.7. Replacement of the location of the incident by that
of the requestor..........................................................................................32

F. The other parameters of business rules 33

F.1. PROCESS_MAX_RECURSION..................................................................33
F.2. PROCESS_TIME_RECURSION.................................................................33
F.3. PROCESS_POOLING_MAX_THREAD......................................................33
F.4. PROCESS_POOLING_TIME......................................................................33
3
G. Import/Export business rules 34
G.1. Export business rules................................................................................34
G.2. Import business rules................................................................................34

H. Wizards for business rules 34

H.1. Enable..........................................................................................................34
H.2. Disable.........................................................................................................34
H.3. Business rule editor...................................................................................34
H.4. Priority level................................................................................................35
H.5. Delete...........................................................................................................35

I. The Monitoring menu 35

I.1. Monitoring Current activity....................................................................35
I.2. Monitoring - History...................................................................................35

J. Warning: the best practices 36

4
A. Definition
Business rules are mechanisms for executing workflows when a database event occurs (addition or modification of a field).
These processes can only be used with the following action types:

Calculation of the latest possible solution date

Send email

Conditional step

nternal database step

WebService step

Automatic processing

, with the exception of the stages requiring manual processing (Operation processing, validation or notation) which are not
allowed. The business rules were introduced in the 2010 version of EasyVista. Consequently they cannot be used in a prior
version.

B. Functioning principle
The functioning principle is as follows:

For each event referenced on a table, the system will automatically add a trigger (if several events are related to
a single table, a single trigger will be added).

When the event concerned occurs, this trigger will write information on the event (fields modified, values before
and after, etc.), into a dedicated table (SD_PROCESS_POOL)

A new system mechanism (on the application server) continuously scans this table for each of the accounts
managed and launches the processes associated with the event. This mechanism is known as the pool manager.
The scanning interval is two minutes by default. This scan is important for all modifications made outside the
direct EasyVista usage environment (such as data import). The default value of two minutes is a system
parameter that it is possible to modify.

Each time an insertion or update event occurs on the database, the application server checks whether a
processing rule is associated with this event and, if so, it calls the pool manager to allow it to execute the
corresponding processes.

The main constituents of a business rule are:

The SQL trigger: This trigger is generated by the system when a business rule is added to a table. It contains
the mechanism for writing into the process pool table. It exists in an SQL version and in an Oracle version. You
have control over this trigger in order to edit the input conditions.

Parameters: This involves specifying the conditions for the execution of the business rule. A business rule may
be executed by addition or update and in this case on one or more fields of the table in question.

The associated process: This workflow will be executed each time the event occurs.

5
C. Stages in creation
In the example that follows, we are going to use a very simple process to update the status of an item of equipment which was
pre-assigned to a user. This event occurs when the value contained in the next user field is updated (NEXT_USER_ID).
Creating a business rule involves a definition stage, a stage for managing the associated workflows and a test stage.

C.1. Defining the business rules

A rule is added using the button from the menu Business rules > Definition:

It is possible to use an alias, meaning a pre-existing model, or to directly select the table(s) that will be covered by the rule.
Selecting an alias aims to simplify the writing of complex rules because the corresponding tests and tables are already included.
In our example, the business rule to be implemented does not involve the complex filter and it is also possible to directly select
the equipment table (AM_ASSET):

The fields to be completed are as follows:

Description: name of the business rule

6
 Active: to be checked to activate the functioning of the business rule

Force execution during the integration: to activate the process corresponding to the business rule when
importing data

Comment: comment explaining the functioning of the business rule

Table: name of the table affected by the business rule ("read only", because this was chosen in the previous
stage)

On insert: triggers the business rule when a record is inserted

On update: triggers the business rule when a record is edited.

Click on the button to enter the SQL condition for triggering the business rule. The syntax may be slightly
different, depending on whether you are working on an SQL or Oracle database. In our example (SQL) this always ends with
BEGIN @@FIRETRIGGER@@ END:

Once entered, the condition may be saved as an alias, which allows it to be used on other business rules.

C.2. Managing the associated processes

The workflows associated with business rules are specific and because of this, they are not designed in the dedicated reference
table, but directly on the wizard:

In the example below, we are going to use an internal update stage to change the status of the equipment:

7
Note: the specificity of the workflows associated with business rules limits the type of available actions to the
following values: Send Email, Calculation of the latest possible solution date, Conditional step, Internal database step,
Web service step and Automatic processing.

C.3. Testing the business rule

The test phase is essential to make sure that the business rule works properly. In our example, this consists of completing the
name of the next user of the equipment using the pre assignment wizard, in order to observe the change of the equipment's
status:

8
The correct functioning of the business rule can also be displayed in the monitoring history (menu Business rules >
Monitoring - History):

D. The business rules present as standard

The examples described below are present as standard in EasyVista's test set database. Only the operational business rules
are described, with the exception of rule models.

D.1. Send mail to supports/groups with actions to

complete
Objective: to send a reminder in the form of an e-mail to technicians with actions to perform
Prerequisite: none

The condition can limit triggering the business rule to only those actions related to an incident

9
IF EXISTS (SELECT * FROM INSERTED INNER JOIN SD_CATALOG ON SD_CATALOG.SD_CATALOG_ID =
INSERTED.SD_CATALOG_ID INNER JOIN AM_REFERENCE SD_CATALOG_REF ON SD_CATALOG.CATEGORY_ID =
SD_CATALOG_REF.REFERENCE_ID WHERE SD_CATALOG_REF.REFERENCE_GUID = '{E9C336A1-F7A7-4145-9F28-
FDD883BFF389}') BEGIN @@FIRETRIGGER@@ END

10
The process to apply is composed of a single e-mail dispatch stage:

Below are the details of the e-mail dispatch stage:

11
D.2. Calculate the time needed to start the processing of
an incident
Objective: to calculate the time that elapses between the creation of the incident and the beginning of its processing
Prerequisite: free field 1 must be made visible on the incident form

The condition limits the triggering of the business rule to incidents:

IF EXISTS (SELECT * FROM INSERTED INNER JOIN SD_REQUEST ON SD_REQUEST.REQUEST_ID =

INSERTED.REQUEST_ID INNER JOIN SD_CATALOG ON SD_CATALOG.SD_CATALOG_ID =
SD_REQUEST.SD_CATALOG_ID INNER JOIN AM_REFERENCE SD_CATALOG_REF ON SD_CATALOG.CATEGORY_ID =
SD_CATALOG_REF.REFERENCE_ID WHERE SD_CATALOG_REF.REFERENCE_GUID = '{E9C336A1-F7A7-4145-9F28-
FDD883BFF389}') BEGIN @@FIRETRIGGER@@ END

12
The process to be applied is composed of a conditional stage and the two internal update stages:

SELECT * FROM AM_ACTION WHERE AM_ACTION.ACTION_ID = @@ID@@ AND AM_ACTION.START_DATE_UT IS NOT

NULL AND AM_ACTION.ACTION_ID IN ( SELECT MIN(AM_ACTION.ACTION_ID) FROM AM_ACTION
INNER JOIN AM_ACTION_TYPE ON AM_ACTION_TYPE.ACTION_TYPE_ID = AM_ACTION.ACTION_TYPE_ID
INNER JOIN SD_REQUEST ON SD_REQUEST.REQUEST_ID = AM_ACTION.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_CATALOG.SD_CATALOG_ID = SD_REQUEST.SD_CATALOG_ID
INNER JOIN AM_REFERENCE SD_CATALOG_REF ON SD_CATALOG_REF.REFERENCE_ID =
SD_CATALOG.CATEGORY_ID WHERE AM_ACTION_TYPE.ACTION_TYPE_GUID in ('{73A8ECF9-DBB0-49CA-8D3B-
55D6C46008D7}', '{5A2C97E9-9982-4A0C-8E8A-29BEC12B39D1}', '{F51E3FAA-05B1-474F-AA32-0BB8C3D261BD}') AND
AM_ACTION.REQUEST_ID IN (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID=@@ID@@) GROUP BY
AM_ACTION.REQUEST_ID)

13
SELECT {@getSLADelay(SD_REQUEST.SUBMIT_DATE_UT,AM_ACTION.START_DATE_UT, SD_REQUEST.SLA_ID,
AM_REQUESTOR.LOCATION_ID)@} FROM AM_ACTION INNER JOIN SD_REQUEST ON SD_REQUEST.REQUEST_ID =
AM_ACTION.REQUEST_ID INNER JOIN AM_EMPLOYEE AM_REQUESTOR ON AM_REQUESTOR.EMPLOYEE_ID =
SD_REQUEST.REQUESTOR_ID WHERE AM_ACTION.ACTION_ID = @@ID@@

14
UPDATE SD_REQUEST SET SD_REQUEST.AVAILABLE_FIELD_2='#[VAR.MY_DELAY]#' FROM SD_REQUEST INNER JOIN
AM_ACTION ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID WHERE AM_ACTION.ACTION_ID = @@ID@@

D.3. Calculate the processing time of an incident by an

outsourcer
Objective: to calculate the time spent by a support group on an incident
Prerequisite: available field 1 must be made visible on the incident form

15
The condition limits the triggering of the business rule to incidents having a Finished meta-status:

IF EXISTS (SELECT * FROM INSERTED INNER JOIN SD_CATALOG ON SD_CATALOG.SD_CATALOG_ID =

INSERTED.SD_CATALOG_ID INNER JOIN AM_REFERENCE SD_CATALOG_REF ON SD_CATALOG.CATEGORY_ID =
SD_CATALOG_REF.REFERENCE_ID INNER JOIN SD_STATUS ON SD_STATUS.STATUS_ID = INSERTED.STATUS_ID
INNER JOIN SD_META_STATUS ON SD_META_STATUS.META_STATUS_ID = SD_STATUS.META_STATUS_ID WHERE
SD_META_STATUS.META_STATUS_GUID = '{FADD193C-E50F-4AB8-BE4B-928D6E2B2CD4}' AND
SD_CATALOG_REF.REFERENCE_GUID = '{E9C336A1-F7A7-4145-9F28-FDD883BFF389}') BEGIN @@FIRETRIGGER@@
END

16
The process to be applied is composed of a succession of conditional and internal database step:

17
18
19
E. Examples of implemented business rules
The examples below are a range of business rules implemented for our clients or partners. They will be listed by increasing
level of difficulty. For each rule, we will describe the processing to be performed, the triggering event and the process applied.
Only the SQL version of the code for the condition will be supplied.

E.1. Update the employees manager with the department

manager
Objective: to copy, onto the employee's form, the manager of this employee's department
Prerequisite: the managers of departments must be associated with each department without exception

20
The condition limits the triggering of the business rule to only those employees for whom the hierarchical manager is empty.

IF EXISTS (SELECT MANAGER_ID FROM INSERTED WHERE MANAGER_ID IS NULL) BEGIN @@FIRETRIGGER@@
END

The process to be applied is composed of a single internal database stage:

UPDATE AM_EMPLOYEE SET MANAGER_ID=AM_DEPARTMENT.MANAGER_ID FROM AM_DEPARTMENT INNER JOIN

AM_EMPLOYEE ON AM_DEPARTMENT.DEPARTMENT_ID = AM_EMPLOYEE.DEPARTMENT_ID WHERE
AM_EMPLOYEE.EMPLOYEE_ID=@@ID@@

21
E.2. Copy the requested start date
Objective: ensure that the desired implementation date for a request, entered via a questionnaire, is copied onto the request's
form
Prerequisite: the questionnaire for entering the requested start date for the request must be associated with the workflow.

The condition limits triggering the business rule to the reply given in the questionnaire:

IF EXISTS (SELECT * FROM INSERTED WHERE QUESTION_ID = 3) BEGIN @@FIRETRIGGER@@ END

The process to be applied is composed of a single internal database stage:

UPDATE SD_REQUEST SET SD_REQUEST.REQUESTED_CHANGE_DATE_END=SD_QUESTION_RESULT.RESULT_DATE

FROM SD_REQUEST INNER JOIN SD_QUESTION_RESULT ON
SD_QUESTION_RESULT.REQUEST_ID=SD_REQUEST.REQUEST_ID AND SD_REQUEST.REQUEST_ID = (SELECT
REQUEST_ID FROM SD_QUESTION_RESULT WHERE @@ID@@)

22
E.3. Notification to the requestor when his/her incident is
being processed
Objective: send notification e-mail to the requestor when the processing action related to his/her incident/request/problem is
dealt with by a technician
Prerequisite: none

The condition limits triggering the rule to only those operation processing and transition processing actions caused by dealing
with an incident, a service request, change request or problem.

IF EXISTS (SELECT * FROM INSERTED

INNER JOIN AM_ACTION_TYPE ON AM_ACTION_TYPE.ACTION_TYPE_ID = INSERTED.ACTION_TYPE_ID
INNER JOIN SD_REQUEST ON SD_REQUEST.REQUEST_ID = INSERTED.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_CATALOG.SD_CATALOG_ID = SD_REQUEST.SD_CATALOG_ID
INNER JOIN AM_REFERENCE SD_CATALOG_REF ON SD_CATALOG_REF.REFERENCE_ID =
SD_CATALOG.CATEGORY_ID
INNER JOIN AM_DEPARTMENT ON SD_REQUEST.DEPARTMENT_ID = AM_DEPARTMENT.DEPARTMENT_ID
WHERE AM_ACTION_TYPE.ACTION_TYPE_GUID IN ('{5A2C97E9-9982-4A0C-8E8A-29BEC12B39D1}', '{79D3DE90-FF41-
408D-9705-35599029F2D3}')
AND SD_CATALOG_REF.REFERENCE_GUID IN ('{E9C336A1-F7A7-4145-9F28-FDD883BFF389}', '{78B158B9-13BC-461B-
BFDF-7FFFA1F6F34F}', '{E93064E7-CAA7-4994-A790-49B5F1FE4EA4}', '{30EAC00A-C4D0-41B9-85E9-090C11248D06}',
'{DAD06D4C-D4A1-4F26-B715-7FB8D3E88B71}')) BEGIN @@FIRETRIGGER@@
END

The process to be applied consists of dispatching notification e-mail to the requestor of the incident/request/problem:

23
E.4. Notifying the requestor when the incident is
redirected or escalated
Objective: send notification e-mail to the requestor when his/her incident/request/problem is redirected or escalated
Prerequisite: none

24
The condition limits triggering the rule to only those operation processing and transition processing actions caused by the
redirection or escalation of an incident, a request or a problem.

IF EXISTS (SELECT * FROM INSERTED INNER JOIN AM_ACTION_TYPE ON AM_ACTION_TYPE.ACTION_TYPE_ID =

INSERTED.ACTION_TYPE_ID INNER JOIN SD_REQUEST ON SD_REQUEST.REQUEST_ID = INSERTED.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_CATALOG.SD_CATALOG_ID = SD_REQUEST.SD_CATALOG_ID INNER JOIN
AM_REFERENCE SD_CATALOG_REF ON SD_CATALOG_REF.REFERENCE_ID = SD_CATALOG.CATEGORY_ID INNER
JOIN AM_DEPARTMENT ON SD_REQUEST.DEPARTMENT_ID = AM_DEPARTMENT.DEPARTMENT_ID WHERE
AM_ACTION_TYPE.ACTION_TYPE_GUID IN ('{5A2C97E9-9982-4A0C-8E8A-29BEC12B39D1}', '{79D3DE90-FF41-408D-
9705-35599029F2D3}') AND SD_CATALOG_REF.REFERENCE_GUID IN ('{E9C336A1-F7A7-4145-9F28-FDD883BFF389}',
'{78B158B9-13BC-461B-BFDF-7FFFA1F6F34F}', '{E93064E7-CAA7-4994-A790-49B5F1FE4EA4}', '{30EAC00A-C4D0-41B9-
85E9-090C11248D06}', '{DAD06D4C-D4A1-4F26-B715-7FB8D3E88B71}')) BEGIN @@FIRETRIGGER@@ END

The related process consists of sending e-mail to the requestor when the incident/request/problem is redirected or escalated:

25
SELECT * FROM AM_ACTION INNER JOIN AM_ACTION_TYPE ON AM_ACTION_TYPE.ACTION_TYPE_ID =
AM_ACTION.ACTION_TYPE_ID WHERE AM_ACTION_TYPE.ACTION_TYPE_GUID = '{D389211B-E8CF-49D1-9D41-
B74C4C68B9D7}' AND AM_ACTION.ORIGIN_ACTION_ID IN (SELECT ORIGIN_ACTION_ID FROM AM_ACTION WHERE
ACTION_ID = @@ID@@ AND ORIGIN_ACTION_ID IS NOT NULL)

SELECT * FROM AM_ACTION INNER JOIN AM_ACTION_TYPE ON AM_ACTION_TYPE.ACTION_TYPE_ID =

AM_ACTION.ACTION_TYPE_ID WHERE AM_ACTION_TYPE.ACTION_TYPE_GUID IN ('{E7D59FBA-0EA4-4268-ADA0-
D2A93DF1BE37}', '{BD4103BF-AE42-42AD-9C7A-E6E7AC1665CC}') AND AM_ACTION.ORIGIN_ACTION_ID IN (SELECT
ORIGIN_ACTION_ID FROM AM_ACTION WHERE ACTION_ID = @@ID@@ AND ORIGIN_ACTION_ID IS NOT NULL)

26
27
E.5. Automatic reopening of suspended incidents
Objective: ensure that the resumption of suspended incidents is automatic when the specified resumption date is reached (this
date is entered during suspension)

Prerequisite: the specified resumption date must be entered during suspension. This field must be made mandatory on the
suspension wizard. It is essential to set up a scheduled alert to complete a field that will be used as the trigger for the business
rule.

E.5.1. Configuring the scheduled alert

E.5.1.1 Filter
The filter included in the scheduled alert will select incidents having:

A 'Pending' meta-status

A reopen date scheduled after the current date

SD_REQUEST.STATUS_ID IN (SELECT STATUS_ID FROM SD_STATUS WHERE META_STATUS_ID=4) AND

SD_REQUEST.REQUEST_ID IN (SELECT REQUEST_ID FROM AM_ACTION WHERE END_DATE_UT IS NULL AND
EXPECTED_START_DATE_UT<GETUTCDATE())

E.5.1.2 Scheduling
The alert will run hourly:

28
E.5.1.3 Script to run
The script of the scheduled alert will insert a text called 'Automatic reopen for On hold incidents' in the available field 1 of the
SD_REQUEST table (incidents/requests/problems)

UPDATE SD_REQUEST SET AVAILABLE_FIELD_1=AUTOMATIC REOPEN FOR ON HOLD INCIDENTS WHERE

SD_REQUEST.REQUEST_ID IN (#LIST_ID#)

E.5.2. Creation of the WebService

The creation of the WebService is done using the menu Parameters > WebService of the Administration module. You may

add a new record using the :

29
http://localhost/webservice/smobridge.php?wsdl

30
31
E.5.3. Configuring the business rule

The condition for triggering consists of updating the Available field 1 of the SD_REQUEST table
(SD_REQUEST.AVAILABLE_FIELD_1):

The condition limits triggering the business rule to only those incidents with available field 1 completed:

IF EXISTS (SELECT REQUEST_ID FROM INSERTED WHERE AVAILABLE_FIELD_1 IS NOT NULL) BEGIN
@@FIRETRIGGER@@ END

32
The process to be applied is composed of a single stage that launches the web service for the resumption of an incident
(EZV_RestartRequest):

E.6. Updating the group in charge of the incident

Objective: to change the incident's responsible group on the incident form. By default, the incident's responsible group is the
group to which the technician who entered this incident belongs. The aim is to replace this group by the one in charge of
performing the processing action. The name of the group is updated when the processing action is generated
Prerequisite: none

33
The condition limits triggering the business rule to the generation of an action of the Processing Operation type
(ACTION_TYPE_ID =20) or Closing Operation type (ACTION_TYPE_ID =34):

IF EXISTS (SELECT GROUP_ID FROM INSERTED WHERE GROUP_ID IS NOT NULL AND (ACTION_TYPE_ID=20 OR
ACTION_TYPE_ID=34)) BEGIN @@FIRETRIGGER@@ END

The process to be applied is composed of a single internal database stage:

UPDATE SD_REQUEST SET OWNING_GROUP_ID=AM_ACTION.GROUP_ID FROM AM_ACTION INNER JOIN

SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID WHERE (AM_ACTION.ACTION_TYPE_ID=20
OR ACTION_TYPE_ID=34) AND SD_REQUEST.REQUEST_ID=(SELECT REQUEST_ID FROM AM_ACTION WHERE
ACTION_ID = @@ID@@)

34
E.7. Replacement of the location of the incident by that
of the requestor
Objective: to change the location of the incident, which by default is identical to that of the recipient, to the location of the
requestor
Prerequisite: none

The condition limits triggering the business rule to only those incidents for which the requestor is different to the recipient:

IF EXISTS (SELECT REQUEST_ID FROM INSERTED WHERE RECIPIENT_ID <> REQUESTOR_ID) BEGIN
@@FIRETRIGGER@@ END

35
The process to be applied is composed of a single internal database stage:

UPDATE SD_REQUEST SET LOCATION_ID = (SELECT a.LOCATION_ID FROM AM_EMPLOYEE a

INNER JOIN SD_REQUEST b ON a.EMPLOYEE_ID = b.REQUESTOR_ID WHERE b.REQUEST_ID = @@ID@@) WHERE
REQUEST_ID = @@ID@@

Note: an identical business rule can be established to replace the incident's department with that of the requestor.

F. The other parameters of business rules

The other parameters are accessible from the menu Parameters > Other parameters of the Administration module. There
are 4 parameters related to business rules:

F.1. PROCESS_MAX_RECURSION
This parameter can avoid infinite loops between processes that call each other. The default value of the parameter is 4, which
means that the process returns control if we call the same process 4 times over a period defined in the parameter below.

F.2. PROCESS_TIME_RECURSION
This parameter defines the time interval between two procedure calls. The default value is 2 (seconds). Therefore, if we
involuntarily define an infinite loop, SmoServer detects the loop if we call a process on a given record 4 times in less than 2
seconds.

F.3. PROCESS_POOLING_MAX_THREAD
This parameter defines the maximum number of processes that may be simultaneously executed. A high value may cause
performance problems (10)

36
F.4. PROCESS_POOLING_TIME
This parameter allows specifying the processing frequency of certain processes triggered by the use of external tools (import or
direct modification in SQL (120000ms representing 2 minutes).

G. Import/Export business rules

G.1. Export business rules

It is possible to export the business rules and associated processes via the Import/Export and Export menu in the
Administration module. The export is performed in two stages: exporting the business rule, then exporting the
workflow/associated process. The order in which the export is performed is of little importance.

G.2. Import business rules

The import of business rules must be performed in the following order:

import the workflow/associated process

import the business rule

otherwise the process will not be automatically associated with the rule and will have to be manually attached to it.

H. Wizards for business rules

H.1. Enable
Used for activating a business rule. This functionality is also available via the business-rule Editor wizard by checking the Active
box on the first page of the Wizard.

H.2. Disable
Used for deactivating a business rule. This functionality is also available via the business-rule Editor wizard by unchecking the
Active box on the first page of the Wizard.

H.3. Business rule editor

Used for editing a business rule and associating a process with a business rule.

37
H.4. Priority level
Used for specifying a level of priority for executing a business rule. To do this, a priority level must be associated with a business
rule (numeric value). Several business rules may have the same priority level. They will then be triggered before the rules with
lower priority levels. A priority level of 1 takes precedence over a priority level 2. Only the rules with an associated priority level
may be selected as reference business rules. Choosing a reference business rule allows its priority level to be applied to the
current rule:

with the same priority level if the "Insert at the same level" option is selected

with a higher priority level if the "Insert before" option is selected

with a lower priority level if the "Insert after" option is selected

H.5. Delete
Used for deleting a business rule. Caution: deleting a business rule does not delete the associated process.

I. The Monitoring menu

This menu can be accessed from the Administration > Business rules menu

I.1. Monitoring Current activity

Displays the state of the queue of business rules to be processed. The absence of records in this list indicates that the
processes started by the business rules are finished.

I.2. Monitoring - History

Used for displaying the execution history of the business rules and, if necessary, making sure that the process has performed
the correct processing:

38
The detailed execution log can be consulted via the icon and the log section:

J. Warning: the best practices

The business rules require compliance with the following rules otherwise the performance of the application will be harmed:

never fail to specify a trigger condition, to limit calls to the process. To this end, we recommend, in so far as
possible, moving the tests present in the process to the location of the trigger condition

avoid triggering on all fields of the table, particularly when the data for this table is being updated (the process
can then go into an infinite loop) and, for a business rule triggered during an update on a given field, avoid
updating this field in an internal update stage.

avoid processes that trigger other business rules

avoid having a large number of business rules on high-volume tables such as "incidents" or "actions"
(SD_REQUEST and AM_ACTION).

prefer several simple processes to a single complex process, defining a trigger condition per process

take care to optimize the SQL code by avoiding, in so far as possible, requests including sub-requests, preferring
joins in the processes

test the business rule in the test or acceptance environment before putting it into production

look at the whole of the execution logs and make sure that the business rule executes as quickly as possible to
avoid interactions (the business rule is triggered again although the previous launch is not yet finished). Just
because a business rule is processed does not mean that no execution error has occurred (such as an SQL
crash). Do not hesitate to regularly check the logs to ensure that each of the stages has correctly executed.

39