Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

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
Copier lien

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) {...}
  ...
}
Copy to Clipboard Toggle word wrap
This is the UML diagram for information logging:
The jBPM logging information class diagram
View larger image
The jBPM logging information class diagram

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() {...}
  ...
}
Copy to Clipboard Toggle word wrap
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();
}
Copy to Clipboard Toggle word wrap

13.2.  Log Configurations
Copier lien

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' />
Copy to Clipboard Toggle word wrap
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
Copier lien

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) {...}
  ...
}
Copy to Clipboard Toggle word wrap
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) {...}
  ...
}
Copy to Clipboard Toggle word wrap
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.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat