In this paper, we demonstrate an application of rules in a business process scenario. As business processes, we consider data-intensive applications which need to move huge data files from server to server. By using the Business Process Model and Notation (BPMN) in our application, we enable clearly and hierarchically represented business processes. Such modeled processes can automatically be executed in a distributed environment with the Jadex open source middleware. Furthermore, the process execution is monitored with declarative rules, also implemented with Jadex. The demonstration shows the start of BPMNmodeled processes and their execution monitoring through logs and rules.
In business intelligence scenarios a huge amount of continuously growing data files
has to be processed in distributed environments. Examples are log file, database, and
campaign management as they are common in banking or telecommunication
organizations. For such tasks, organizations use data integration approaches. However,
The basic principle in such applications consists of an extraction of data files from
an operative system (like a web server), transformation of the data (on a staging server),
and storing it in an analytical platform (like a data warehouse), see Figure 1. Data
integration tools already handle diverse data file formats, however, they blank out that
organizational data primary exist as decentralized, distributed data files. In our approach,
we enable a declarative representation of business processes with the Business Process
Model and Notation (BPMN)
In this paper, we focus on the monitoring of business process execution. This
monitoring task has the goal to identify interesting occurrences during process execution.
Such occurrences can be normal process execution as well as failing executions like not
finished processes or exceeded average runtime of processes. For this process
observation tasks, we apply a rule-based approach (see
Web and Application Server Staging Server
Evaluation Server
We are currently developing a system for automating business processes for gaining flexibility in process arrangement, quality improvements of data processing, and cost savings. The system consists of distributed, autonomously acting components, which are centrally controlled. Besides distributed quality assurance processes and integrative information life cycle strategy, the system has a process modeling component based on the BPMN (see Section 2) and a monitoring component (see Section 4), which are presented in this paper. We use the Jadex system4 as a infrastructure supporting distributed agents and rules (see Section 3). In Section 5 and with a video5, we demonstrate the processing of agents and rules with a data staging example. 2
The de facto standard to graphically model applicable business processes is the Business
Process Model and Notation (BPMN)
In the following, we introduce a simple example use case. Figure 1 depicts an exemplary server setting where the first stage of server outputs large amounts of data (for example customer informations collected by a publicity campaign) which will be processed by the staging server. The staging server filters the input data according filters like e.g. correct addresses. The quality analysis of data provided by the evaluation server brings the setting to a close.
The notational model of the data processing is described in Figure 2. Before processing the collected data, the configuration data for the upcoming copy process has to be fetched and checked, possible configuration contents might be access credentials. The copy task is a collapsed subprocess (readily identifiable by the plus), in case of errors within this subprocess the error event leads to the error handling task. The expanded copy process is shown in Figure 3. After the data processing, the analyzing of quality (QA) step follows.
The expanded copy subprocess contains the following tasks: First the connection
to a specific server has to be established, and before copying the data the existence
is checked. Since of some data only one version is allowed to exist, a delete task is
integrated via the exclusive gateway. Each task is bonded with a error catching event
leading to the error handling task. Because of server-side connection problems, some
errors might be corrected by a simple retry after a couple of minutes, see the timer event
in Figure 3.
Basistechnologie aus der Informatik
The implementation platform used in this project is the open source platform Jadex
This is achieved by relying on established security protocols such as SSL. 3.2
Workflows and Rule Support BPMN workflow support for Jadex consists of a visual editor based on the open source eclipse stp editor and the workflow engine that is able to execute modeled workflows. The editor mainly extends the stp version with new input fields for annotating implementation data that is necessary for executing the workflow. Such modeled workflows can be directly loaded and executed within Jadex using the BPMN kernel, which enacts each workflow as a separate active component instance. A workflow can spawn new subworkflows either locally or on remote platforms and monitor their execution. Furthermore, as workflows are components, they can invoke services of other workflows or components via their provided service interfaces. Rule support is based on a typical forward chaining rule engine called Jadex Rules that is similar to JESS and Drools, but targeted towards a very lightweight engine solution that can be integrated with other application parts. One reason for such a lightweight solution was the requirement to be able to execute a rule engine as part of an active component, i.e. due to the actual number of such components many rule engines have to run concurrently. 4
The duty of the monitoring component is to observe process execution and signal successful or failure execution. This monitoring can depend on application specific attributes like duration of process execution time or transfered file size. As common for a rule-based approach, working memory elements based on templates and rules can be used for representing the involved data and knowledge. Templates describe via fields structured data objects. Rules consist of a condition and action part. If some working memory elements fulfill the condition part of a rule, the rule system executes its action part.
In our application, while tasks and processes are executed, logs are created within application components. We differentiate between effective and failure logs. The effective logs are grouped by BPMN process, micro agent, rule, and task start and end logs. Every time an agent, BPMN process, or a task is started or will terminate shortly after, a log will be created. In case of a failure within a task, rule, agent, or BPMN process a failure log is created. The basic layout of a log consists of the creation time, id, type, message, and parent id, but each log subtype extends this layout. For an overview of the currently used log types (implemented as Java classes), see Figure 5.
Working memory elements represent logs in the rule system. Consequently, in the condition part of a rule, types of logs and their fields can be tested. If a certain combination of logs was created, i.e. corresponding components were executed, a rule can fire and, thus, signal its execution with a further log. The rule depicted in Figure 6 creates a log of type CopyRuleEffectiveLog if two logs of type BeforeCopyTaskEffectiveLog and AfterCopyTaskEffectiveLog of the same process exist. Logs created through rule firing can be used in further rules for hierarchically testing log structures.
Thus, the application component implementor can model logs of a related type and rules describing certain effective or failure situations of an application component. (defrule CopyTaskRuleEffective ;; Matches log-objects of type BeforeCopyTaskEffectiveLog ;; which deal with files of size not equal 0.
?ctlog1 <- (BeforeCopyTaskEffectiveLog (taskStartTime ?tst) (sourceFilesize ?sfs) (processID ?pid1) (test(!= ?sfs 0))) ;; Matches log objects of type AfterCopyTaskEffectiveLog ;; which deal with of size not equal 0 and has the same ;; processID as above.
?ctlog2 <- (AfterCopyTaskEffectiveLog (processID ?pid1) (targetFilesize ?tfs) (taskEndTime ?tet)) ;; Task start time must be less task end time (test (< ?tst ?tet)) (test (!= ?tfs 0)) => ;; Creation of a combined working memory element representing ;; the firing of the rule.
(assert (CopyRuleEffectiveLog (logs ?ctlog1 ?ctlog2))))
The monitoring component itself is implemented as an agent which continuously receives logs from the executing application agents (see Figure 7). This happens via so called LocalMonitoringRepositories and one central MonitoringRepository that store the logs for later use. Thus, the monitoring component observes the execution of distributed acting agents in a central way. It further combines the results of the agents’ activities through firing rules.
A1 A2 A3 LocalMonitoring Repository A1 A2 A3 LocalMonitoring Repository A1 A2 LocalMonitoring Repository
MonitoringRepository
LoggingService
RuleSystem Agent Active instance The monitoring component is part of a distributed business process execution application, which is currently under development. The application is implemented with JAVA and the extension Jadex for distributed agents. 5
In the demonstrating example, we show the execution of an BPMN-modeled process for file transfer. For this task, following steps are executed: – Start of the Logging Service agent that initializes the rule engine and waits for incoming logs. – The specific working memory element Clock is initially created for representing the current time and, thus, enabling time-dependent rule firing. – The BPMN-process is started by the user. Internally, new agents are created which follow the process model and execute the related basic component implementation. During the process execution specific logs are created like BPMNProcessStartLog and BeforeCopyEffectiveLog. – Created logs and activated rules can be examined in a rule monitor window. – Each fired rule creates new logs like the CopyRuleEffectiveLog. – In a further run-through of the demonstrator another rule fires indicating that a copy task needs too much time to be processed. 6
Other data integration tools already handle diverse data file formats, however, they blank
out that organizational data primary exist as decentralized, distributed data files. User
of such systems are forced to manually move the data files to appropriate places or to
develop scripts and programs that move them around in distributed systems. To the best
of our knowledge, no other business intelligence software is focusing on the process
execution monitoring via rules. Hereby, processes report their execution via logs (e.g.
start and end logs) and rules observe those for identifying interesting monitoring
occurrences. This rule-based approach has following advantages. First, we decouple the
execution of the actual processes from their monitoring, i.e. we separate application
logic from monitoring logic. If new interesting occurrences shall be recognized
during execution the process component implementation has not to be changed but only
rules have to be added. Thus, maintenance shall be simplified. Furthermore, by using
rules, we allow a declarative representation of such interesting situations which can be
modeled by domain experts, in the ideal case, e.g. when domain specific languages are
introduced for rule modeling (see
In this demonstration paper, we present a combination of process modeling based on BPMN, process execution in a distributed environment, and process execution monitoring with rules. The demonstrator shows how these technologies can successfully be combined to monitor process execution in a distributed environment.