Chapter 13. Logging
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 used 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.
13.1. Log Creation
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:
Figure 13.1. The jBPM logging information class diagram
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();
}13.2. Log Configurations
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.
13.3. Log Retrieval
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 read this chapter, you now know how logging works in jBPM and has some idea of the various uses to which it can be put.
