![](bg3.png)
can be executed several times. Each execution is
known as process instance. Events collected during
system execution must be correlated into the correct
instance.
This paper presents a technique to obtain event
logs from traditional systems, paying special
attention to the event correlation improvement
regarding previous work. The technique consists of
three stages. Firstly, the technique records events
from the execution of traditional systems. During
this stage the technique allows experts to identify
candidate correlation attributes, whose runtime
values will then be collected together with each
event. As a result, events and their respective
attributes are then stored in a database in an
intermediate format (cf. Section 3.1). Secondly, the
algorithm proposed by (Motahari-Nezhad et al.,
2011) is adapted and applied with the event datasets
so to discover the most appropriate set of attributes
and conditions for the events correlation (cf. Section
3.2). Finally, the third stage applies an algorithm
based on the correlation set in order to correlate each
event with its corresponding process instance (cf.
Section 3.3). As a result, a standard-format event log
is obtained from the source traditional system.
Figure 1: Event correlation overview.
3.1 Event Collection
The event collection stage is in charge of the suitable
generation and storage of events throughout system
execution. Since traditional information systems do
not have any in-built mechanism to record events
about executed business processes, this stage
instruments information systems to record events.
The instrumentation is semi-automated by a parser
that syntactically analyzes the source code and
injects statements in particular places of the code to
record events during system execution.
This work follows the ‘a callable unit / a
business activity’ approach proposed by Zou et al.
(Zou and Hung, 2006). Callable units are the generic
elements (e.g., Java methods, C or COBOL
procedures, etc.) in which the parser injects
statements to record an event corresponding to the
execution of a business activity. Despite this fact,
not all the executions of callable units have to be
recorded as events. Some callable units such as fine-
grained or technical callable units do not correspond
to events and must be discarded. The injection in the
exact place is consequently supported by some
information provided by experts. Such experts (i)
delimit business processes with the start and end
callable units of each process; (ii) establish the
boundaries of non-technical source code to be
instrumented; and finally, (iii) they identify those
code elements that can be treated as candidate
correlation attributes.
This stage is supported by an improved version
of the tool presented in (Pérez-Castillo et al., 2011),
which supports the identification and addition of
candidate correlation attributes. Selection of
candidate correlation attributes is a key task, since
an incomplete list of candidate attributes may lead to
a non-suitable correlation. This stage provides
experts with all the possible selectable attributes.
These attributes are every parameter appearing in
callable units as well as the output and fine-grained
callable units that are invoked within those callable
units, which are considered to be collected as events.
The information about candidate correlation
attributes is injected together with a statement
enabling event collection.
Figure 2: Example of code instrumentation.
Figure 2 provides an example of the results
obtained after instrumenting a Java method of the
system under study (cf. Section 4). The two tracing
statements (see highlighted statements) are injected
at the beginning and at the end of the body of the
method. Those candidate correlation attributes that
are present in a method (e.g., a parameter or
variable) are automatically injected in the tracing
statements, i.e., the respective variables are in the set
of parameters of the invocation to the method
‘writeDBEvent’ (see Figure 2). However, not all
correlation attributes defined by experts are present
in all methods (e.g., due to the absence of a
particular variable). In this case, the respective
EVENTS
PROCESS
INSTANCE
PROCESS
A D
B
C
A D C
A DB
A
D
A
C
D
D
A
B
C
B
A
B
D
B
C
B
C
public class SocioFacadeDelegate
[...]
public static void saveAuthor(AuthorVO author) throws InternalErrorException {
writeDBEvent("SocioFacadeDelegate.saveAuthor", "Author Management", "", "start",
false, false, -1, false, 2, 8, "", "" + author.getId(), "" + author.isHistorico(),
"" + author.getNumeroSocio(), "", "" + author.getCotas());
try {
SaveAuthorAction action = new SaveAuthorAction(author);
PlainActionProcessor.process(getPrivateDataSource(), action);
} catch (InternalErrorException e) {
throw e;
} catch (Exception e) {
throw new InternalErrorException(e);
}
writeDBEvent("SocioFacadeDelegate.saveAuthor", "Author Management", "", "complete",
false, true, -1, false, 2, 8, "", "" + author.getId(), "" + author.isHistorico(),
"" + author.getNumeroSocio(), "", "" + author.getCotas());
}
[...]
ImprovingEventCorrelationforNon-processAwareInformationSystems
35