Business Process Server enables you to employ the power of BPM Events to dynamically define, update, observe, store, and print reports, all without writing any Java code or SQL queries. You can consult reports at any time, either by a business manager or automatically by rules. In Business Process Server, reports are dynamic objects and not the result of the offline processing of historical data. Use BPM Events rules to generate alarms, send e-mail, or trigger an action. For example, modify priorities of business processes if abnormal values appear in the report.
You can, for example, define a a report called "MyTaskReport" that reports on the total number of tasks assigned and the average completion time for priority level that looks like Table 4.
Table 4. Sample "MyTaskReport"
Task priority
Volume
Average completion time
Critical "1"
10
23
High "2"
27
45
Medium "3"
58
150
Low "4"
64
1861
Using the MyTaskReport format, you can define a sample report entitled "MyTaskReport_Ver2" to display the following information:
The total number of tasks assigned until now.
The average completion time for each level of priority (Critical, High, Medium, Low).
The dynamic nature of Business Process Server enables it to build online reports, using event-driven rules based on events generated during the application processing. All rules in BPM Events are of the following form:
rule <rulename>
activated by <event header>
[if <conditions>]
then "{" <actions> "}"
The general meaning of such a rule is: "on reception of the specified events, if these events satisfy the conditions then execute the actions."
You should also observe some general practice concerning rules, including the following:
All names and keywords are case sensitive.
The <conditions> part expresses a condition to be satisfied by incoming events in order for BPM Events to execute the ActionList part. The condition may be a simple one, or it might include several conditions formed using operations such as AND and OR. For more information, refer to Rule condition as a logical expression.
The <actions> part consists of one or more actions to be performed in the specified sequence. While these actions are capable of performing diverse operations, the sample applications here focus on creating and manipulating reports.
Begin by defining the report structure in BPM Events. The report is implemented using a general structure called an infopad in Business Process Server. An infopad is structured as a table of elements called cells, with each cell containing several attributes. You can define an infopad by using the Rule Editor in BPM Designer to create a rule module, which adds the following statements in the initialize section:
initialize {
MyTaskReport_Ver2 := new
infopad<cell{comptime:int}>[4][1]("MyTaskReport_Ver2");
MyTaskReport_Ver2.addRowLabels("TaskPriority", list {"Critical", "High",
"Medium", "Low"});
}
The initialize section of the rule module is automatically executed when the module is loaded, typically when the application is installed into Business Process Server. At this time, an image of the report is created in memory, as well as in the database. This persistent image is used for recovery, as well as for access by Business Process Server front-ends.
The above statements:
1. Define each cell as having an attribute comptime of type int (integer).
2. In memory, allocate a table of four rows and one column ([4][1]), resulting in four elements (or cells).
3. Add the title ("TaskPriority") for the row dimension of the report and row titles (or labels): "Critical", "High", "Medium" and "Low".
4. Initialize the data in the cells to 0 (zero). For example, "comptime" and "counter" initialize to 0 for all the cells.
5. Create the infopad in the database. This stores all the infopad meta data information in the database.
Note: Each cell of any infopad always contains by default a "counter" attribute or slot. This slot does not require declaration. Additional slots are declared, like "comptime" above.
The total number of tasks assigned until now.