Read this chapter to learn about the logging functionality present in the Business Process Manager and the various ways in which it can be utilized.
The purpose of logging is to record the history of a process execution. As the run-time data of each process execution alters, the changes are stored in the logs.
Note
Process logging, which is covered in this chapter, is not to be confused with software logging. Software logging traces the execution of a software program (usually for the purpose of debugging it.) Process logging, by contast, traces the execution of process instances.
There are many ways in which process logging information can be useful. Most obvious of these is the consulting of the process history by process execution participants.
Another use case is that of Business Activity Monitoring (BAM). This can be used to query or analyze the logs of process executions to find useful statistical information about the business process. This information is key to implementing "real" business process management in an organization. (Real business process management is about how an organization manages its processes, how these processes are supported by information technology and how these two can be usede improve each other in an iterative process.)
Process logs can also be used to implement "undos." Since the logs contain a record of all run-time information changes, they can be "played" in reverse order to bring a process back into a previous state.
Business Process Manager modules produce logs when they run process
executions. But also users can insert process logs. (A log entry is
a Java object that inherits from
org.jbpm.logging.log.ProcessLog.) Process log
entries are added to the LoggingInstance,
which is an optional extension of the
ProcessInstance.
The Business Process Manager generates many different kinds of log,
these being graph execution logs, context logs and task management
logs. A good starting point is
org.jbpm.logging.log.ProcessLog since one can
use that to navigate down the inheritance
tree.
The LoggingInstance collects all log
entries. When the ProcessInstance is saved,
they are flushed from here to the database. (The
ProcessInstance's logs
field is not mapped to Hibernate. This is so as to
avoid those logs that are retrieved from the database in each
transaction.)
Each ProcessInstance is made in the
context of a path of execution and hence, the
ProcessLog refers to that token, which
also serves as an index sequence
generator it. (This is important for log retrieval
as it means that logs produced in subsequent transactions shall
have sequential sequence numbers.
Use this API method to add process logs:
public class LoggingInstance extends ModuleInstance {
...
public void addLog(ProcessLog processLog) {...}
...
}
This is the UML diagram for information logging:
A CompositeLog is a special case. It serves as the parent log for a number of children, thereby creating the means for a hierarchical structure to be applied. The following application programming interface is used to insert a log:
public class LoggingInstance extends ModuleInstance {
...
public void startCompositeLog(CompositeLog compositeLog) {...}
public void endCompositeLog() {...}
...
}
The CompositeLogs should always be called
in a try-finally-block to make sure that the
hierarchical structure is consistent. For example:
startCompositeLog(new MyCompositeLog());
try {
...
} finally {
endCompositeLog();
}
If logs are not important for a particular deployment, simply remove
the logging line from the jbpm-context section
of the jbpm.cfg.xml configuration file:
<service name='logging'
factory='org.jbpm.logging.db.DbLoggingServiceFactory' />
In order to filter the logs, write a custom implementation of the
LoggingService (this is a subclass of
DbLoggingService.) Having done so, create a
custom ServiceFactory for logging and
specify it in the factory attribute.
Process instance logs must always be retrieved via database queries.
There are two methods to achieve this through
LoggingSession.
The first method retrieves all logs for a process instance. These
logs will be grouped by token in a map. This map will associate a
list of ProcessLogs with every token in the
process instance. The list will contain the
ProcessLogs in the same order as that in
which they were created.
public class LoggingSession {
...
public Map findLogsByProcessInstance(long processInstanceId) {...}
...
}
The second method retrieves the logs for a specific token. The list will contain the
ProcessLogs in the same order as that in
which they were created.
public class LoggingSession {
public List findLogsByToken(long tokenId) {...}
...
}
Having perused this chapter, the reader will now know how logging works in jBPM and has some idea of the various uses to which it can be put.