- Created by manikandan.subbiah (Unlicensed) , last modified by Enterprise IT on Mar 14, 2022
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 2 Next »
Overview
Each customer of SummitAI uses the SummitAI Application for managing different business processes. In certain situations, customers have specific requirements and want those requirements as a standard feature to make sure their business processes are fully operational.
Problem Statement
Following challenges were observed while developing such features separately for each customer:
- Longer wait time for customer from the time it is requested until it is released that leads to poor Customer Satisfaction (CSAT).
- Increased operational activities by going through build cycles, testing cycles and production cycles.
- Adds too many complexities.
- Makes the product bulky.
Solution
To address this, the business designer feature is primarily introduced in the SummitAI. Now, using the Business Rule Designer, the customers can create/configure their requirements by defining business rules that align with their business requirements directly using the front-end.
What is a Business Rule?
Technical definition
A business rule is a server-side script that runs when a predefined trigger satisfies the preconfigured condition(s) leading to a defined action. The Administrators can define a business rule in three steps.
Trigger - Lets you to define when (After or Async) the business rules should execute (Trigger Type: Create or Update).
Condition - Lets you to define criteria to apply the action.
Action - Lets you to define what should happen if the trigger – matches the set of conditions defined. The actions can be:
Update specific fields of the record
Notify set of audience
Use API to create or update record
Benefits of Business Rule Designer
Following are key benefits of Business Rule Designer:
- Do it yourself using the Front-end
- Enables automation of actions by defining conditions and specifying action to trigger when the condition is met
- Faster time to market
- Eliminates all Operational activities
- Reduces Feature requests
- No need to develop point solutions
Usage of Business Rules
This section provides you the various use cases for the following scenarios in Transitive and Reflexive Nature:
- Business Rules with same order number
- Business Rules with different order number
Transitive Nature:
a = b
b = c
c = d
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Priority = P1 | 100 |
BR 3 / 03-03-2021 | When Incident = Created | If Priority = P1 | Send Mail to WO | 100 |
BR 4 / 04-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 5 / 05-03-2021 | When Incident = Created | If Impact = High | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | ||||
1 | Condition Matches > BR 1 Executes | 100 | ||
2 | Condition Matches > BR 2 Executes | 100 | ||
3 | Condition Matches > BR 3 Executes | 100 | ||
4 | Condition Doesn’t Match > BR 4 Doesn’t Execute | 100 | ||
5 | Condition Doesn’t Match > BR 5 Doesn’t Execute | 100 | ||
Incident Database | ||||
Incident ID | Symptom | Category | Priority | Send E-Mail |
100 | Server problem | Server | P1 | Yes |
Parsing Logic / Inference | ||||
When all the business rules have the same execution order, then execute each of the business rules in incremental order of creation date. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | If Priority = P1 | Send Mail to WO | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Priority = P1 | 100 |
BR 3 / 03-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server | 100 |
BR 4 / 04-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 5 / 05-03-2021 | When Incident = Created | If Impact = High | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met | BR Executes | ||
1 | Condition Doesn’t Match | BR 1 Doesn’t Execute | 100 | |
2 | Condition Doesn’t Match | BR 2 Doesn’t Execute | 100 | |
3 | Condition Matches | BR 3 Executes | 100 | |
4 | Condition Doesn’t Match | BR 4 Doesn’t Execute | 100 | |
5 | Condition Doesn’t Match | BR 5 Doesn’t Execute | 100 | |
Incident Database | ||||
Incident ID | Symptom | Category | Priority | Send E-Mail |
100 | Server problem | Server | ||
Parsing Logic / Inference | ||||
When all the business rules have the same execution order, then execute each of the business rules in incremental order of creation date. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | If Priority = P1 | Send Mail to WO | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Priority = P1 | 99 |
BR 3 / 03-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server | 98 |
BR 4 / 04-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 5 / 05-03-2021 | When Incident = Created | If Impact = High | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met | BR Executes | ||
1 | Condition Doesn’t Match | BR 1 Doesn’t Execute | 100 | |
2 | Condition Doesn’t Match | BR 4 Doesn’t Execute | 100 | |
3 | Condition Doesn’t Match | BR 5 Doesn’t Execute | 100 | |
4 | Condition Doesn’t Match | BR 2 Doesn’t Execute | 99 | |
5 | Condition Matches | BR 3 Executes | 98 | |
Incident Database | ||||
Incident ID | Symptom | Category | Priority | Send E-Mail |
100 | Server problem | Server | ||
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order, execute them incrementally (incremental order of creation date), and then execute the business rules with lower-order nos. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | If Priority = P1 | Send Mail to WO | 98 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Priority = P1 | 99 |
BR 3 / 03-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server | 100 |
BR 4 / 04-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 5 / 05-03-2021 | When Incident = Created | If Impact = High | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met | BR Executes | ||
BR 3 / 03-03-2021 | Condition Matches | BR 1 Executes | 100 | |
BR 4 / 04-03-2021 | Condition Doesn’t Match | BR 4 Doesn’t Execute | 100 | |
BR 5 / 05-03-2021 | Condition Doesn’t Match | BR 5 Doesn’t Execute | 100 | |
BR 2/ 02-03-2021 | Condition Doesn’t Match | BR 2 Executes | 99 | |
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 98 | |
Incident Database | ||||
Incident ID | Symptom | Category | Priority | Send E-Mail |
100 | Server problem | Server | P1 | yes |
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order, execute them incrementally (incremental order of creation date), and then execute the business rules with lower-order nos. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | If Priority = P1 | Send Mail to WO | 99 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Priority = P1 | 98 |
BR 3 / 03-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server | 100 |
BR 4 / 04-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 5 / 05-03-2021 | When Incident = Created | If Impact = High | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met | BR Executes | ||
BR 3 / 03-03-2021 | Condition Matches | BR 3 Executes | 100 | |
BR 4 / 04-03-2021 | Condition Doesn’t Match | BR 4 Doesn’t Execute | 100 | |
BR 5 / 05-03-2021 | Condition Doesn’t Match | BR 5 Doesn’t Execute | 100 | |
BR 1 / 01-03-2021 | Condition Doesn’t Match | BR 1 Doesn’t Execute | 99 | |
BR 2/ 02-03-2021 | Condition Doesn’t Match | BR 2 Doesn’t Execute | 98 | |
Incident Database | ||||
Incident ID | Symptom | Category | Priority | Send E-Mail |
100 | Server problem | Server | ||
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order, execute them incrementally (incremental order of creation date), and then execute the business rules with lower-order nos. |
Transitive Nature (Mirror Image):
a = c (c1)
b = c (c1)
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Category = Server | Workgroup = Server Team | 100 |
BR 2/ 02-03-2021 | When Incident = Created | Medium = Email | Workgroup = Network Team | 100 |
Use Case: End user logs the incident with Symptom as Server Problem, Category as Server and Medium as email | ||||
Sequence of Execution | Condition Met | BR Executes | ||
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 100 | |
BR 2/ 02-03-2021 | Condition Matches | BR 2 Executes | 100 | |
Incident Database | ||||
Incident ID | Symptom | Category | Medium | Workgroup |
100 | Server problem | Server | Network Team | |
Parsing Logic / Inference | ||||
When all the business rules have the same execution order and want to update the same field, then execute each of the business rules in incremental order of creation date. The field value in the last business rule executed will be considered. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Category = Server | Workgroup = Server Team | 100 |
BR 2/ 02-03-2021 | When Incident = Created | Medium = Email | Workgroup = Network Team | 99 |
Use Case: End user logs the incident with Symptom as Server Problem, Category as Server and Medium as email | ||||
Sequence of Execution | Condition Met | BR Executes | ||
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 100 | |
BR 2/ 02-03-2021 | Condition Matches | BR 2 Executes | 99 | |
Incident Database | ||||
Incident ID | Symptom | Category | Medium | Workgroup |
100 | Server problem | Server | Server Team | |
Parsing Logic / Inference | ||||
When the business rules have different execution orders and want to update the same field, then execute each of the business rules in incremental order of creation date. The field value in the business rule with the highest order number will be considered. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Category = Server | Workgroup = Server Team | 99 |
BR 2/ 02-03-2021 | When Incident = Created | Medium = Email | Workgroup = Network Team | 100 |
Use Case: End user logs the incident with Symptom as Server Problem, Category as Server and Medium as email | ||||
Sequence of Execution | Condition Met | BR Executes | ||
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 100 | |
BR 2/ 02-03-2021 | Condition Matches | BR 2 Executes | 99 | |
Incident Database | ||||
Incident ID | Symptom | Category | Medium | Workgroup |
100 | Server problem | Server | Network Team | |
Parsing Logic / Inference | ||||
When the business rules have different execution orders and want to update the same field, then execute each of the business rules in incremental order of creation date. The field value in the business rule with the highest order number will be considered. |
Business Rule Database | |||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No | |
---|---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Category = Server | Workgroup = Server Team | 99 | |
BR 2/ 02-03-2021 | When Incident = Created | Medium = Email | Workgroup = Network Team & Impact= High | 100 | |
Use Case: End user logs the incident with Symptom as Server Problem, Category as Server and Medium as email | |||||
Sequence of Execution | Condition Met | BR Executes | Order No | ||
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 100 | ||
BR 2/ 02-03-2021 | Condition Matches | BR 2 Executes | 99 | ||
Incident Database | |||||
Incident ID | Symptom | Category | Medium | Workgroup | Impact |
100 | Server problem | Server | Network Team | High | |
Parsing Logic / Inference | |||||
When the business rules have different execution orders and want to update the same field, then execute each of the business rules in incremental order of creation date. The field value in the business rule with the highest order number will be considered. |
Transitive Nature (Complex):
a = b ,c, d
b, c = e
b, e = f
c = g
d = h
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server Update Impact = High Update Workgroup = Server Team | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server & Workgroup = Server Team | Update Priority = P1 | 100 |
BR 3/ 03-03-2021 | When Incident = Created | If Category = Server & Priority = P1 | Update Urgency = High | 100 |
BR 4/ 04-03-2021 | When Incident = Created | If Category = Server | Send Mail to Head of Server Team | 100 |
BR 5/ 05-03-2021 | When Incident = Created | If Workgroup = Server Team | Assign Analyst = Maxwell | 100 |
BR 6/ 06-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 7/ 07-03-2021 | When Incident = Created | If Impact = Critical | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server Problem" | ||||
Sequence of Execution | Condition Met | BR Executes | Order No | |
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 100 | |
BR 2/ 02-03-2021 | Condition Matches | BR 2 Executes | 100 | |
BR 3/ 03-03-2021 | Condition Matches | BR 3 Executes | 100 | |
BR 4/ 04-03-2021 | Condition Matches | BR 4 Executes | 100 | |
BR 5/ 05-03-2021 | Condition Matches | BR 5 Executes | 100 | |
BR 6/ 06-03-2021 | Condition Doesn’t Match | BR 6 Doesn’t Execute | 100 | |
BR 7/ 07-03-2021 | Condition Doesn’t Match | BR 7 Doesn’t Execute | 100 | |
Incident Database | ||||
Incident ID | 100 | |||
Symptom | Server problem | |||
Category | Server | |||
Impact | High | |||
Workgroup | Server Team | |||
Priority | P1 | |||
Urgency | High | |||
Send Mail | Yes | |||
Assigned Analyst | Maxwell | |||
Parsing Logic / Inference | ||||
When all the business rules have the same execution order, then execute each of the business rules in incremental order of creation date. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | If Category = Server | Send Mail to Head of Server Team | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Urgency = High | 100 |
BR 3/ 03-03-2021 | When Incident = Created | If Category = Server & Workgroup = Server Team | Update Priority = P1 | 100 |
BR 4/ 04-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server Update Impact = High Update Workgroup = Server Team | 100 |
BR 5/ 05-03-2021 | When Incident = Created | If Workgroup = Server Team | Assign Analyst = Maxwell | 100 |
BR 6/ 06-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 7/ 07-03-2021 | When Incident = Created | If Impact = Critical | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server Problem" | ||||
Sequence of Execution | Condition Met | BR Executes | Order No | |
BR 1 / 01-03-2021 | Condition Doesn’t Match | BR 1 Doesn’t Execute | 100 | |
BR 2/ 02-03-2021 | Condition Doesn’t Match | BR 2 Doesn’t Execute | 100 | |
BR 3/ 03-03-2021 | Condition Doesn’t Match | BR 3 Doesn’t Execute | 100 | |
BR 4/ 04-03-2021 | Condition Matches | BR 4 Executes | 100 | |
BR 5/ 05-03-2021 | Condition Matches | BR 5 Executes | 100 | |
BR 6/ 06-03-2021 | Condition Doesn’t Match | BR 6 Doesn’t Execute | 100 | |
BR 7/ 07-03-2021 | Condition Doesn’t Match | BR 7 Doesn’t Execute | 100 | |
Incident Database | ||||
Incident ID | 100 | |||
Symptom | Server problem | |||
Category | Server | |||
Impact | High | |||
Workgroup | Server Team | |||
Assigned Analyst | Maxwell | |||
Parsing Logic / Inference | ||||
When all the business rules have the same execution order, then execute each of the business rules in incremental order of creation date. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | If Category = Server | Send Mail to Head of Server Team | 97 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Urgency = High | 99 |
BR 3/ 03-03-2021 | When Incident = Created | If Category = Server & Workgroup = Server Team | Update Priority = P1 | 98 |
BR 4/ 04-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server Update Impact = High Update Workgroup = Server Team | 100 |
BR 5/ 05-03-2021 | When Incident = Created | If Workgroup = Server Team | Assign Analyst = Maxwell | 100 |
BR 6/ 06-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 7/ 07-03-2021 | When Incident = Created | If Impact = Critical | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server Problem" | ||||
Sequence of Execution | Condition Met | BR Executes | Order No | |
BR 4/ 04-03-2021 | Condition Matches | BR 4 Executes | 100 | |
BR 5/ 05-03-2021 | Condition Matches | BR 5 Executes | 100 | |
BR 6/ 06-03-2021 | Condition Doesn’t Match | BR 6 Doesn’t Execute | 100 | |
BR 7/ 07-03-2021 | Condition Doesn’t Match | BR 7 Doesn’t Execute | 100 | |
BR 2/ 02-03-2021 | Condition Doesn’t Match | BR 2 Doesn’t Execute | 99 | |
BR 3/ 03-03-2021 | Condition Matches | BR 3 Executes | 98 | |
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 97 | |
Incident Database | ||||
Incident ID | 100 | |||
Symptom | Server problem | |||
Category | Server | |||
Impact | High | |||
Workgroup | Server Team | |||
Assigned Analyst | Maxwell | |||
Priority | P1 | |||
Send Mail | Yes | |||
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order - execute them incrementally - then execute the business rules with lower-order nos. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | If Category = Server | Send Mail to Head of Server Team | 97 |
BR 2/ 02-03-2021 | When Incident = Created | If Category = Server | Update Urgency = High | 98 |
BR 3/ 03-03-2021 | When Incident = Created | If Category = Server & Workgroup = Server Team | Update Priority = P1 | 99 |
BR 4/ 04-03-2021 | When Incident = Created | Symptom contains "Server" | Update Category = Server Update Impact = High Update Workgroup = Server Team | 100 |
BR 5/ 05-03-2021 | When Incident = Created | If Workgroup = Server Team | Assign Analyst = Maxwell | 100 |
BR 6/ 06-03-2021 | When Incident = Created | If Category = Network | Update Priority = P2 | 100 |
BR 7/ 07-03-2021 | When Incident = Created | If Impact = Critical | Send Mail to WO | 100 |
Use Case: End user logs the incident with symptom containing "Server Problem" | ||||
Sequence of Execution | Condition Met | BR Executes | Order No | |
BR 4/ 04-03-2021 | Condition Matches | BR 4 Executes | 100 | |
BR 5/ 05-03-2021 | Condition Matches | BR 5 Executes | 100 | |
BR 6/ 06-03-2021 | Condition Doesn’t Match | BR 6 Doesn’t Execute | 100 | |
BR 7/ 07-03-2021 | Condition Doesn’t Match | BR 7 Doesn’t Execute | 100 | |
BR 3/ 03-03-2021 | Condition Matches | BR 3 Executes | 99 | |
BR 2/ 02-03-2021 | Condition Matches | BR 2 Executes | 98 | |
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 97 | |
Incident Database | ||||
Incident ID | 100 | |||
Symptom | Server problem | |||
Category | Server | |||
Impact | High | |||
Workgroup | Server Team | |||
Assigned Analyst | Maxwell | |||
Priority | P1 | |||
Urgency | High | |||
Send Mail | Yes | |||
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order - execute them incrementally - then execute the business rules with lower-order nos. |
Reflexive Nature:
a = b
b = a
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Symptom contains "Server" | Update Priority = P1 | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Priority = P1 | Update Priority = P2 | 100 |
BR 3 / 03-03-2021 | When Incident = Created | If Priority = P2 | Update Priority = P1 | 100 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met | BR Executes | ||
1 | Condition Matches | BR 1 Executes | 100 | |
2 | Condition Matches | BR 2 Executes | 100 | |
3 | Condition Matches | BR 3 Executes | 100 | |
Incident Database | ||||
Incident ID | Symptom | Priority | ||
100 | Server problem | P1 | ||
Parsing Logic / Inference | ||||
When all the business rules have the same execution order, then execute each of the business rules in incremental order of creation date. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Symptom contains "Server" | Update Priority = P1 | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Priority = P1 | Update Priority = P2 | 99 |
BR 3 / 03-03-2021 | When Incident = Created | If Priority = P2 | Update Priority = P1 | 98 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met | BR Executes | ||
1 | Condition Matches | BR 1 Executes | 100 | |
2 | Condition Matches | BR 2 Executes | 99 | |
3 | Condition Matches | BR 3 Executes | 98 | |
Incident Database | ||||
Incident ID | Symptom | Priority | ||
100 | Server problem | P1 | ||
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order, execute them incrementally, and then execute the business rules with lower-order nos. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Symptom contains "Server" | Update Priority = P1 | 100 |
BR 2/ 02-03-2021 | When Incident = Created | If Priority = P1 | Update Priority = P2 | 98 |
BR 3 / 03-03-2021 | When Incident = Created | If Priority = P2 | Update Priority = P1 | 99 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met | BR Executes | ||
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 100 | |
BR 3 / 03-03-2021 | Condition Doesn’t Match | BR 3 Doesn’t Execute | 99 | |
BR 2/ 02-03-2021 | Condition Matches | BR 3 Executes | 98 | |
Incident Database | ||||
Incident ID | Symptom | Priority | ||
100 | Server problem | P1 | ||
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order, execute them incrementally, and then execute the business rules with lower-order nos. |
Business Rule Database | ||||
Business Rule ID/Creation Date | Trigger | Condition | Action | Order No |
---|---|---|---|---|
BR 1 / 01-03-2021 | When Incident = Created | Symptom contains "Server" | Update Priority = P1 | 98 |
BR 2/ 02-03-2021 | When Incident = Created | If Priority = P1 | Update Priority = P2 | 99 |
BR 3 / 03-03-2021 | When Incident = Created | If Priority = P2 | Update Priority = P1 | 100 |
Use Case: End user logs the incident with symptom containing "Server" | ||||
Sequence of Execution | Condition Met /Not Met | BR Executes | ||
BR 3 / 03-03-2021 | Condition Doesn’t Match | BR 3 Doesn’t Execute | 100 | |
BR 2/ 02-03-2021 | Condition Doesn’t Match | BR 2 Doesn’t Execute | 99 | |
BR 1 / 01-03-2021 | Condition Matches | BR 1 Executes | 98 | |
Incident Database | ||||
Incident ID | Symptom | Priority | ||
100 | Server problem | P1 | ||
Parsing Logic / Inference | ||||
When all the business rules have different execution orders, filter the rules with the highest order, execute them incrementally, and then execute the business rules with lower-order nos. |
Do's and Don'ts
Do's
Understand the business rule parsing logic before configuring the Business rules.
Make sure the rules configured to achieve a set of requirements do not overlap with other rules.
Review the existing rules before creating new Business Rules.
Specify logical execution order for the rules.
Make sure the business rule updates actions do not conflict with existing matrices such as:
SLA Matrix,
Category/ Location based Workgroup and Analyst Routing
Classification based Workgroup routing
Classification /(Location or Customer) Workgroup routing
Priority based Response and Resolution time with skip days
CI based Priority and SLA Window
Urgency/ Impact based Priority
Workgroup/ Priority based SLA window restriction
SLA Window with holiday calendar based on specific location or analysts location
Category based Priority and SLA (optionally over-ridable)
Don'ts
Don't configure a requirement as a rule which will not help us to achieve full operation of the business process.
Configuring many rules may likely slow down the application.
Prerequisites
Rabbit MQ set up.
To set up Rabbit MQ- Download Erlang version 23.0 for the respective operating system and install. Use the default options during the installation and complete the installation. (Link - https://www.erlang.org/downloads/23.0)
- Set below environment variable under system variables
Variable name: ERLANG_HOME
Variable value: Path of erlang without bin - Add %ERLANG_HOME%\bin to the PATH environmental variable:
Variable name: PATH
Variable value: %ERLANG_HOME%\bin - Download and install Rabbit MQ server 3.8.13 (Link - https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.14)
To install Rabbit MQ server 3.8.14, perform the following steps:- Locate and double-click the rabbitmq-server-3.8.14.exe (It will usually be in your Downloads folder.)
- A dialog box will appear. Click Yes. The Choose Components screen is displayed.
Figure: Choose Components - Select components to install and click Next. The Choose Install Location screen is displayed.
Figure: Choose Install Location - Select Destination Folder by clicking Browse and and click Install.
Figure: Installing
Figure: Installation Complete - Click Finish to complete the installation.
- Make sure RabbitMQ is available in services and running.
- Open the command prompt with admin privileges and navigate to the path where rabbitmq server is installed. Execute the below command to enable the management interface rabbitmq-plugins enable rabbitmq_management
- Open a browser and access the management interface using the link, http://localhost:15672/
- Login with credentials guest/guest
- Summit.BusinessRule.EventListenerService service installation
In case of first time upgrade to Tahoe and above versions, the below installation command needs to be executed.Installation command for Business Rule Service
sc create "Summit.BusinessRule.EventListenerService" binPath= "<<InstallationDirectory>>\BusinessRuleEvent\Summit.BusinessRule.EventListenerService.exe" DisplayName= "Summit BusinessRule EventListener" start= auto sc start Summit.BusinessRule.EventListenerService Example: <<InstallationDirectory>> "E:\ToQA\v511\B013\01.Applications" So the binPath="E:\ToQA\v511\B013\01.Applications\BusinessRuleEvent\Summit.BusinessRule.EventListenerService.exe" sc create "Summit.BusinessRule.EventListenerService" binPath= "E:\ToQA\v511\B013\01.Applications\BusinessRuleEvent\Summit.BusinessRule.EventListenerService.exe" DisplayName= "Summit BusinessRule EventListener" start= auto
New Config keys are required to be added in web.config/app.config file
Config KeysThe below config keys are required to be added to the respective file for Business Rule Functionality.
Web.config of SummitWeb
<add key="BUSINESS_RULE_RABBITMQ_USERNAME" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PASSWORD" value="" /> <!--Comma Separated Hostname or IP Address--> <add key="BUSINESS_RULE_RABBITMQ_HOST" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PORT" value="5672" /> <!--Connection Timeout value in milli seconds--> <add key="BUSINESS_RULE_RABBITMQ_CONNECTION_TIMEOUT" value="1000" />
App.config of Summit.BusinessRule.EventListenerService
<add key="BUSINESS_RULE_RABBITMQ_USERNAME" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PASSWORD" value="" /> <!--Comma Separated Hostname or IP Address--> <add key="BUSINESS_RULE_RABBITMQ_HOST" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PORT" value="5672" /> <!--Connection Timeout value in milli seconds--> <add key="BUSINESS_RULE_RABBITMQ_CONNECTION_TIMEOUT" value="3000" /> <add key="BUSINESS_RULE_RABBITMQ_FETCH_COUNT" value="10" /> <add key="DEBUG_ENABLED" value="false" /> <add key="API_TIMEOUT" value="10000" /> <!--Email Processing Config Keys--> <add key="App:BaseURL" value="" /> <add key="Mail:From" value="" /> <add key="Mail:FromName" value="" /> <!--Orchestration Config Keys--> <add key="App:OrchestrationEnabled" value="true" /> <!--Orchestration connector in connection string--> <add name="RabbitConnector" connectionString="" /> <add name="SummitDB" connectionString="" />
ServerMonitor.exe.config
<add key="BUSINESS_RULE_RABBITMQ_USERNAME" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PASSWORD" value="" /> <!--Comma Separated Hostname or IP Address--> <add key="BUSINESS_RULE_RABBITMQ_HOST" value="" /> <add key="BUSINESS_RULE_RABBITMQ_PORT" value="5672" /> <!--Connection Timeout value in milli seconds--> <add key="BUSINESS_RULE_RABBITMQ_CONNECTION_TIMEOUT" value="1000" />
Note:
Data Migration across different Database Environment
If the data is migrated between DB environments, then make sure that the value for Summit_BusinessRule_Identifier key in Summit_config table must be unique. The same value for Summit_BusinessRule_Identifier configuration key cannot be used across different DB environments.
How to Configure a Business Rule?
To configure a Business Rule, perform the following steps:
- Select Admin >Basic > Infrastructure > Business Rule.
- On the BUSINESS RULE page, click ADD NEW on the ACTIONS panel. The following page is displayed.
Figure: BUSINESS RULE page - Select the Tenant and fill in the required details. For more information, see Field Description.
- Fill in the other required details under RULE DEFINITION, TRIGGER, CONDITION, and ACTION sections.
- Click SUBMIT. A new Business Rule is configured.
Field Description
The following table describes the fields on the BUSINESS RULE page:
Field | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
RULE DEFINITION | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | Type in a name for the business rule. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | Type in a detailed description. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Execution Order | By default, the execution order number is blank. Each Business Rule can be assigned an execution order number. The order number is the deciding factor when same field is updating from different Business Rules. Rule with higher order number is processed first and given precedence over rules with lower order number. Note: If the execution order number is same, then the business rule executed based on the created date. BR Processing Logics:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Active | If selected, the Business Rule becomes active. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TRIGGER | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Module | Select the Module from the drop-down list. As of now you can create Business Rules only for Incident Management Module. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When | You can define when this business rule should execute.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Trigger Type |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CONDITION | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When a Request Arrives | Use the condition builder to determine when the business rule actions should be executed.
Adding Conditions:A condition consists of the following parts:
Group Conditions (): Using the Group Conditions option, you can define multiple conditions as a single condition using AND/OR. Example: Consider that you want to trigger a business rule when an incident is created for Network Category with a Priority as P2 or Impact as Low. In this case, you can set the all the conditions as single condition as shown below using Group Conditions. To create a Group of Conditions, select the check boxes of respective condition rows and click (Group Conditions) icon. Note: Only adjacent conditions can be grouped. Already grouped condition rows cannot be used for another Group. To Ungroup Conditions, click (Ungroup Conditions) icon as shown below. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ACTION | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Time Zone for Notification and API |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
UPDATE FIELDS | Under this tab, you can configure update field values. You can update the both standard and custom field values. Update Action Type
Note:
The following fields become mandatory based on status value selection. Also, the for the mandatory fields the icon will not displayed at the end of every row.
Delete Fields You can delete an update field row by clicking on the icon present at the end of every row. Override Values
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NOTIFICATION | Under this tab, you can configure the notification templates for the business rule. You can create new notification template or use the existing notification template to send a notification to users. You can configure the following notification types:
E- Mail Notification To create E-Mail Notification, perform the following steps:
Field DescriptionThe following table describes the fields on the NOTIFICATION pop-up:
SMS Notification To create an SMS notification, perform the following steps:
Field DescriptionThe following table describes the fields on the NOTIFICATION pop-up:
Search Notifications You can search notifications using the Search Notifications search box. Filter By
Linked to this Business Rule Under this section, you can view the list of notification templates linked to this Business Rule. Also, you can edit and delete the notification templates available under this section. To edit a notification template, perform the following steps:
To delete a notification template, perform the following steps:
Linked to other Business Rule Under this section, you can view the list of notification templates linked to other Business Rules. Unlinked Notifications Under this section, you can view the list of unlinked notifications. These notifications are created but not linked with any business rule. Existing Templates Under this section, you can view the existing email notification templates which are configured for the selected Tenant and Module (Incident Management).
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
API | ADD API To add API, perform the following steps:
Field DescriptionThe following table describes the fields on the API pop-up:
Linked to this Business Rule Under this section, you can view the list of APIs linked to this Business Rule. Also, you can edit and delete the APIs available under this section. Linked to other Business Rule Under this section, you can view the list of APIs linked to other Business Rules. Also, you can edit and delete the APIs available under this section. Unlinked APIs Under this section, you can view the list of unlinked notifications. These notifications are created but not linked with any business rule |
ACTIONS
This section explains all the icons displayed on the ACTIONS panel of the BUSINESS RULE configuration page.
SHOW LIST
Click SHOW LIST to display the BUSINESS RULES table showing all the configured Business Rule details for the selected Tenant.
Figure: BUSINESS RULE LIST Page
Figure: BUSINESS RULE LIST Page
You can perform the following actions on the BUSINESS RULES Page.
- By clicking the (Edit) icon, you can edit the business rule order or execution order from the BUSINESS RULES Page.
- You can make the specific business rule active or inactive from the BUSINESS RULES Page.
To inactive a Business Rule, perform the below steps:- Uncheck the check Active check box, a pop-up displayed with a message as shown below.
Click OK to inactive a Business Rule.
Note:
To display the inactive business rules, click the Include Inactive check box.
- Uncheck the check Active check box, a pop-up displayed with a message as shown below.
CHANGE HISTORY
Click CHANGE HISTORY to view the changes that occurred on the Business Rule, the user who made the changes, the date and time when the change was made, and also the Old and New values for the Business Rule.
ACTIONS
This section explains all the icons displayed on the ACTIONS panel of the BUSINESS RULES LIST page.
FILTERS
Click Filters to specify particular filter criteria to display the Business Rules. On clicking the Filters icon, the FILTERS pop-up page is displayed.
ADD NEW
Click ADD NEW to configure a new Business Rule.
Notes:
End User screen will be frozen when manually escalated, reopened, closed/cancelled
Async rule will be processed based on the latest data of the Incident.
Admin has to configure the required notifications for the Business Rule. Default notifications applicable for Incident Management module will not be sent.
Orchestration call will be triggered for the Incident after business rule processing in case of update fields action.
Tenant Settings: Below Tenant configuration checks are applicable for Business Rule Configuration.
Enable Manual Incident Cancellation Icon
Enable Category Parent Node Selection
Enable Classification Parent Node Selection
Minimum Symptom Length
Description Length
Do Not Allow Images in Description
Enable Capture of Closure Category
Enable Secondary Analyst
Minimum Characters for Solution
Allow Analyst to Edit Symptom
Allow Analyst to Edit Description
Additional Information Tab
Known Issues
CC recipients are not grouped by customer.
- No labels