BPM Events tutorial : Using rules to monitor and report on business processes
Using rules to monitor and report on business processes
Rules can also monitor business processes. They generate alarms, as well as real-time reports that managers can access online, or that can in turn be analyzed by other rules.This departs from more traditional reporting procedures that generate reports from archived data, by querying or running stored procedures on an operation database. In other words, BPM Events rules allow for generating event-driven reports, meaning the input of such reports is directly obtained from business events and transactions.
Let us assume we want to monitor what kind of request customers are sending from various regions at any time. We may have four types of requests: Product Order, Support, Service Order, and Training.
We want to know how many requests of each type have been served until now. Table 3 displays how the expected monitoring report looks:
Table 3. Report: Request distribution
Request type/origin
Asia
US
Europe
ProductOrder
Support
ServiceOrder
Training
In BPM Events, this type of monitoring report is called an infopad. An infopad is structured as a table (of one or two dimensions), with labeled rows and columns. Each element of this table is called a cell. A cell has several attributes. For example, each cell of the report shown in Table 3 holds two values:
1. A number that represents how many occurrences were recorded for this type of request for this day of the week.
2. A number that represents the average execution time for requests of this type, in the corresponding region.
Each cell of any infopad has a default attribute named count of type integer, that does not require declaring when defining the infopad. We use it to count the number of requests for each cell (req type / region). The infopad is created by executing the following statements:
The creation of this infopad is done only once, initially when publishing the application. For this reason, the infopad creation statements above are enclosed in an initialization section, in the rule file:
initialize { ... }
This initialization section is executed only once, when loading the rule file in the rule engine. The meaning of these statements is as follows:
"When loading the rule file, create an infopad called "ReqStats" of 4 rows and 3 columns, with column labels: "Asia", "US", "Europe", and with rows labeled "ProductOrder","Support","ServiceOrder", "Training". Each element (cell) of the infopad has an attribute (slot) avgtime of the integer type (int), and an attribute count of type int, which is always present by default (need not be specified)."
Note: The name ReqStats appears twice in the first line of the initialization section of the infopad creation statement. The first occurrence (left hand side) is the infopad variable, as it is known by the rules. The second occurrence (on right hand side) is the actual persistent name of the infopad, as used in the database and external systems. Usually, the infopad variable and the actual persistent name of the infopad are the same, but this is not required. This allows for writing rules that do not depend on the actual infopad name.
