A challenge for enterprises is to ensure conformance of their business processes with imposed compliance rules. Usually, the latter may constrain multiple perspectives of a business process, including control ow, data, time, resources, and interactions with business partners. Like in process modeling, visual languages for specifying compliance rules have been proposed. However, business process compliance cannot be completely decided at design time, but needs to be monitored during run time as well. This paper introduces an approach for visually monitoring business process compliance. In particular, this approach covers all relevant process perspectives. Furthermore, compliance violations cannot only be detected, but also be visually highlighted emphasizing their causes. Finally, the approach assists users in ensuring compliant continuations of a running business process.
Correctness issues of business process models have been intensively studied for
more than a decade. While early work focused on syntactical correctness and
soundness (e.g., absence of deadlocks and lifelocks), recent approaches have
focused on how to ensure the compliance of business processes with semantic
constraints. Usually, respective compliance rules stem from domain-speci c
requirements, like, for example, corporate standards or legal regulations [
In this context, approaches addressing the compliance of running business process instances are covered by the notion of compliance monitoring [3{5]. In general, events of running process instances need to be considered to detect and report run-time violations of compliance rules (cf. Fig. 1). Thereby, reactive and proactive monitoring need to be distinguished. Regarding the former, compliance violations are reported once they have occurred. In turn, proactive monitoring ⋆ This work was done within the research project C3Pro funded by the German Research Foundation (DFG) under project number RE 1402/2-1.
CRM
aims to prevent compliance rule violations; e.g., by suggesting appropriate tasks
that still need to be executed to meet a compliance rule. While early approaches
for monitoring compliance focused on the control
ow perspective, more and
more, additional process perspectives have been considered as well (e.g. [
As example consider the event log from Fig. 2 that refers to an order-to
Fig. 2: Event log of order-to-delivery processes and compliance rules
delivery process. Compliance rule c1, which is shown on the right, is satis ed in
one case, but violated in another. In particular, the depicted log refers to two
different request items related to customers Mr. Smith and Mrs. John. These items,
in turn, trigger two di erent instances of compliance rule c1. In both cases, the
amount is greater than 10,000 e and hence a solvency check is required.
However, the latter was only performed for the request item of Mr. Smith, but not for
the one of Mrs. John (i.e., c1 is violated in the latter case). Besides the violation
of c1, compliance rule c2 is violated twice as well. While the violated instance of
c1 can never be successfully completed, the violations of c2 still can be healed by
informing the agent. The rule examples further indicate that solely monitoring
control ow dependencies between tasks is not su cient to ensure compliance
at run time. In addition, constraints in respect to the data, time and resource
perspectives of a business process must be monitored as well as the interactions
this process has with partner processes [
This paper sketches an approach for visually monitoring multiple perspectives
of business process compliance. For this purpose, we annotate the visual extended
Compliance Rule Graph (eCRG) language [
The remainder of this paper is structured as follows: The approach for visually monitoring multiple perspectives of business process compliance is outlined in Section 2. Section 3 concludes the paper and provides an outlook on future research. 2
eCRG Compliance Monitoring
This paper utilizes the extended Compliance Rule Graph (eCRG) language for
compliance monitoring [
In the following, we sketch the approach towards visually monitoring multiple perspectives of business process compliance at runtime. As discussed in Sect. 1, e c n eu Task r c c O e c en Task s b A
e c recnu Message
c
compliance monitoring is based on streams of events, which occur during the
execution of business processes, and aims to determine or prevent compliance
violations. For this purpose, we extend the approach presented in [
Events The processing of event logs requires a well-de ned set of events. As the approach enables compliance monitoring for multiple process perspectives, we not consider only events referring to the start and end of tasks, but additionally monitor data ow events as well as events that correspond to the sending and receipt of messages. Furthermore, events may include temporal information as well as information about involved resources. Table 1 summarizes the supported event types. Each event refers to the occurrence time as well as a unique id. The latter enables us to identify correlations between the start, end and data ow events of the same task or message. eCRG Markings To monitor the state of a compliance rule, we annotate and mark eCRG elements with symbols, colors and text (cf. Figs. 5). Such a marking of an eCRG results in an annotated eCRG highlighting whether or not the events corresponding to a particular node have occurred so far. Furthermore, it describes whether the conditions of edges and attachments are satis ed, are violated or have not been evaluated yet.
Event Processing We exemplarily describe how events are processed for an
eCRG (cf. Fig. 6) and refer to [
date datestart timestart timestart–timeend dateend timeend Task Task performer performer esg Sender a s e Message s dnM date time a s k s a T
date time
Receiver tno ittacaved ittacaved irnnung ltceepodm isekppd occ abs future e m iiittsonP D23etche2m0b2e3r n past October 26th 2013 .
c rak aen ed t tnom .scon
. iiftesasd .tacesnon c . c e litaevdo .tasnon
c Update Marking
Effect
Propagation Fig. 6: Processing of start, message, data and end events ≠ ≠ ≠ ≠ ≠ ≠ .
c rka aen ed t tnom .scon
. iiftesasd .teacsnon c . c e liteavdo .tasnon c
Effect Propagation < 2d < 2d < 2d < 2d < 2d < 2d < 50 < 50 < 50 < 50 < 50 < 50
Fig. 7b illustrates the handling of a message event. In particular, the marking of the activated message node request, which matches the event, changes to ▶. Accordingly, the starting time is set. Start events are processed like message events, but additionally store information about the responsible actor. Start and message events are handled non-deterministically; i.e., the changes are applied to a copy of the original marking. Fig. 7c shows the handling of data events. In particular, the corresponding data ow edge is annotated with the data value passed. Fig. 7e illustrates the handling of an end event. In particular, the annotations of request is changed to ✓ and its ending time is set accordingly.
Fig. 7g illustrates how a marking is updated to the current point in time. In particular, the annotations of point in time nodes, which now refer to the past, change to ✓. Finally, time conditions on running task nodes or sequence ow edges are skipped (⨉) if they are no longer satis able (cf. Fig. 7g).
According to Fig. 6, e ects of events and updates must be propagated to indirectly a ected eCRG elements in order to ensure correct annotations (e.g., activation of subsequent task nodes) as well as to detect contradictory annotations related to the data and resource perspectives. In particular, data values are propagated from writing and reading data ow edges to dependent data object and data container nodes (cf. Fig. 7d). In turn, resources are propagated from task nodes to dependent resource nodes via the connecting resource edges. The propagation fails, if a resource, data object or container node was set to a di erent value before. In this case, the respective edge is skipped (⨉). Furthermore, conditions and relations are evaluated as soon as possible (cf. Fig. 7d). If any element of the eCRG corresponding to a task or message node is skipped (e.g., due to a failed data/resource propagation or a violated condition), the corresponding task or message node will be skipped as well. Then, outgoing sequence ows of completed nodes are marked as satis ed, whereas non-marked incoming edges of already started nodes are skipped. Sequence ow edges from and to skipped nodes are skipped as well. Task and message nodes, in turn, become activated when all incoming sequence ows they are depending on are satis ed. Additionally, task or message nodes will be skipped if they depend on sequence ows that were skipped as well. Note that the latter might require skipping further sequence ow edges, and so forth (cf. Fig. 7h). Finally, Fig. 7i provides a marking that ful lls c1 for the request of Mr. Smith. In turn, Figs. 7h+7k highlight con icts regarding time and resource perspectives.
The non-deterministic processing of start and message events may result
in sets of markings. Therefore, single ful lling or con icting markings do not
imply (non-)compliance with the related rule. For this purpose, [
propagation of effects of event 37 propagation of effects of event 38 customer 15,000 Fig. 7: eCRG markings and handling of events
Summary and Outlook
Business process compliance has gained increasing interest during the last years.
Several approaches focus on compliance monitoring at run time [3{5]. However,
existing approaches do not provide a satisfactorily solution combining an
expressive language with full traceability [
As next step, we will investigate algorithms for eCRG-based compliance
monitoring utilizing the eCRG operational semantics we presented in [