=Paper=
{{Paper
|id=None
|storemode=property
|title=Logic-based ad-hoc Business Process Management: Concepts and Challenges
|pdfUrl=https://ceur-ws.org/Vol-682/paper8.pdf
|volume=Vol-682
|dblpUrl=https://dblp.org/rec/conf/esws/AnicicSS10
}}
==Logic-based ad-hoc Business Process Management: Concepts and Challenges==
https://ceur-ws.org/Vol-682/paper8.pdf
Logic‐based ad‐hoc business process management: Concepts and
Challenges
Darko Anicic Nenad Stojanovic Ljiljana Stojanovic
FZI Karlsruhe FZI Karlsruhe FZI Karlsruhe
Haid-und-Neu Strasse 10-14 Haid-und-Neu Strasse 10-14 Haid-und-Neu Strasse 10-14
76131 Karlsruhe 76131 Karlsruhe 76131 Karlsruhe
+49 721 9654958 +49 721 9654852 +49 721 9654804
Darko.Anicic@fzi.de Nenad.Stojanovic@fzi.de Ljiljana.Stojanovic@fzi.de
ABSTRACT However, these requirements are quite challenging and require a
The need for unpredicted, real-time changes in the business different view on the process flexibility: flexibility in a process is
process is increasing tremendously. However, a well-founded not defined a priory (like in business rules) but it is calculated in
approach for representing these processes in an executable the real time, based on the constraints which are defined (mainly)
form is missing. In this position paper we introduce the a priory, in the design time. Obviously, it requires a different
concept of the event-driven ad-hoc business process formalism for representing business processes: one that enables
management and present some of challenges. declarative representation and reasoning with constraints.
Keywords In this position paper we present such an approach based on the
Ad-hoc BPM, Logic Programming, Complex Event Processing logic.
1. MOTIVATION 2. A UNIFYING FRAMEWORK FOR
An increasing dynamics in today business and life requires EVENT-DRIVEN AD-HOC PROCESSES:
flexible infrastructures that can sense a problem or opportunity MODELING AND REASONING
almost immediately after their occurrence (ideally: before they
will appear) and react accordingly. It is especially relevant for the
Figure 1 depicts the main aspects of event-driven ad-hoc
business processes which are underpinning complex work or life
processes addressed in this work. In particular, the figure shows
situations, like emergency management, since many unexpected the conceptual relationships between executing tasks, the
events (problems or opportunities) can happen all the time and workflow scheduler, and the dynamic change manager. Tasks that
traditional approaches for coping with the diversity in business need to be executed are scheduled by the scheduler. The
processes, like using business rules, are simple not feasible. scheduler orders executing tasks according to the model specified
Indeed, if we consider a forest fire, so many parameters can be by a concrete workflow. The dynamic change manager (DCM)
changed every second (like the direction of the wind, the intensity may alter the scheduling plan, i.e., the order in which tasks are
of fire) so that any a priory coded adaptivity will fail. scheduled for execution. This may happen due to detection of
Additionally, even someone wants to define adaptivity in design- certain events that represent unexpected situations.
time, there are situations which cannot be calculated in advance.
For example, if during the fighting against the fire a very strong
wind starts, the correct action can be calculated only in the
moment of the execution, since there are so many parameters that
can influence the decision and which will be know in the real-
time, like the intensity of the fire, the number of available
firemen, the environment, … It means that the system must
reason about these events in real time in order to calculate
corresponding change in the workflow. This is what we call ad-
hoc process changes and corresponding processes event-driven
ad-hoc processes. Therefore, any precoding of the possible
changes (alternative paths in the process execution) will decrease
the flexibility of the process, i.e. the efficiency of the running
process instance.
Figure 1. Conceptual architecture of event-driven ad-hoc
processes
48
In the presented conceptual architecture, tasks are seen as external events depict the current radiation measurements, weather
event sources. The scheduler receives a stream of events from conditions, traffic information, and the present situation in the
these sources, and schedules them in time. The incoming event decontaminated zone.
stream is denoted by the arc pointing from tasks to the scheduler
(see Figure 1). As events may represent statuses of executing Complex events. Complex events represent more meaningful
tasks (e.g., start, end etc.), scheduling an event amounts to situations of interest.
scheduling of a task (process). Process scheduling must ensure They help in assessing different situations and making real time
that scheduling satisfy all constraints, specified by the workflow decisions
(possible after reordering some events in the incoming stream).
Reordering is realized by sending events from the scheduler back Constraints. Control flow graphs are typically used to represent
to tasks (depicted by the arc in the reverse direction). main activities and their basic dependencies in a workflow. More
For example, such an event may carry information that a fine-grained dependencies are specified by constraints; they
corresponding task is either allowed (for execution), rejected, or capture global temporal and causality interactions. Yet another
delayed. Task events are also gathered by the dynamic change situation when constraints are useful is when specific
manager, which additionally receives external events (e.g., events requirements need to be taken into account (though they may be
from various information sources or sensors etc.). The manager omitted in other situations).
correlates these events into complex events (relevant with respect
to a particular business domain). Hence the manager utilises event Ad-hoc changes. Emergency response workflows need to cope
processing to detect real-time situations that require certain with unpredictable changes. Classical workflow management
decisions. Decisions may deviate an ongoing workflow instance. systems offer good process support as long as the processes are
They are made by humans, however DCM with its event structured and do not require much flexibility. However
processing capabilities help in discovering situations (that might emergency response workflows are expected to be flexible. In
require deviations). The deviation (adaptation) is typically driven practice, it is not feasible to specify all possible cases that may
by the need to take into account new emerging issues (e.g., emerge in an incident situation. For example, it may happen that
something accidentally happen) or to optimise the execution with during one emergency situation, another one happens. We can try
respect to certain events (that just happened). Finally, complex to structure typical flow of response activities in one incident
events may further be used externally for e.g., activity situation, but not in other ones (if they occur).We assume that ad-
monitoring, various analytics etc. (see Figure 1). hoc changes in workflows are, in major cases, a subject of
In the following we describe main elements: human’s decision; CEP provides just a means to detect real-time
situations that possibly require ad-hoc (unpredictable) changes.
Control flow graphs. The focus of the following use case is to
manage an emergency situation caused by a nuclear plant
With previously described building components (control flow
accident. Let us imagine that due to a critical accident in a nuclear
graph, constraints, (complex) events, changes) we define the main
plant, a large quantity of radioactive substance is released in
problems addressed in this paper:
atmosphere.
Complex event processing. Process multiple streams of atomic
In such a situation, an emergency response system coordinates
events with the goal of detecting complex events, according to
with a number activities including emergency responders,
meaningful event patterns.
ambulances, fire trucks etc.
Ad-hoc workflow scheduling. Given the fact that tasks are
represented as events, decide whether the scheduling of event
Events. Events play a few important roles in our framework. We
streams that satisfies both the workflow constraints and ad-hoc
summarise the roles in the following list:
changes exists
– Control flow graph: workflow tasks are typically modeled in
terms of their externally observable events (such as start, end,
commit, precommit, abort etc). Such events can be directly 3. CONCLUSION
incorporated as nodes in a control flow graph; scheduling of the Hitherto, approaches to ad-hoc and dynamic process-aware
control flow amounts to scheduling of events. (For brevity, our information systems acted on the assumption that decision on
running example collapses all significant events for the same task process changes are not strictly time sensitive. The emphasis was
into one event.) rather on full support to process modifications. In many practical
– Workflow constraints: temporal and causality relationships cases (e.g., emergency management) the time to react on certain
among workflow tasks are expressed as events. Verification of situation is limited. Further on, decisions on ad-hoc process
workflow constraints is performed as the task of proving that a modifications need to be carefully assessed taking into account
given set of events with their temporal and causality interactions many changing parameters. To address these requirements, we
is consistent. have proposed a framework for event-driven ad-hoc processes.
– Complex event patterns: events are used to build more complex The framework features both event processing capabilities as well
event patterns; that may be used for various monitoring or as capabilities to accept on-line process changes. The framework
analytical purposes, or initiate ad-hoc changes in a workflow. In is based on declarative rules, and as such it features greater
this scope, events can represent not only tasks, but external events flexibility with ad-hoc changes.
too (e.g., events from various sensors, other workflows or
services etc.).
Our framework for event-driven ad-hoc processes needs to sense
for events all the time during its operation. For example, real time
49