Browse Prior Art Database

System and method to generate tracing information for a particular BPEL process instance into a separate log destination.

IP.com Disclosure Number: IPCOM000199985D
Publication Date: 2010-Sep-23
Document File: 7 page(s) / 166K

Publishing Venue

The IP.com Prior Art Database

Abstract

System and method to enable criterion based trace mechanism for BPEL instances. Application servers host many applications and currently running them in their environment. Each of these applications will be running on different threads. These threads would be performing logging and tracing the messages concurrently. Usually, the log or trace messages from several different applications will mix up in a single log or trace destination which is usually a file. However, in the environment where Business Process Choreographer is running several BPEL process instances, the trace messages from all these process instances will record into a single trace file. So, the messages traced for one process instance will mix up with the messages traced for other process instances. Currently there is no way to direct messages traced by particular process instance to a separate log destination (or trace file). To state the problem clearly, let us take an example scenario. Suppose trace is enabled for certain components as follows. com.ibm.bpe.*=all: com.ibm.task.*=all: com.ibm.ws.security.*=all: com.ibm.ws.staffsupport.*=all Suppose, we have WorkOrder BPEL process template deployed in the BPC cluster. This template allows users to create several WorkOrder process instances as orders come by. When these process instances are running concurrently, the trace messages generated by these instances will be recorded into a single trace file (usually in the logs/trace.logfile ). >From this trace file, it is difficult to segregate messages generated by a particular process instance. Moreover, the trace file fills up very fast depending on the number of process instances running and the level at which tracing is generated. With the generated trace file, it is difficult to walk through the trace messages generated by a particular process instance to debug any problems. Ability to configure tracing at per process instance provides many benefits. If there is a problem symptom experienced by all the process instances, we can enable tracing for particular process instance and investigate it easily. This invention proposes a system and method to configure BPEL engine to trace individual BPEL instances into a separate log or trace destination. The selection of a BPEL instance for tracing could be done by the users or could be selected based on some criteria. Details are provided below.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 01 of 7

System and method to generate tracing information for a particular BPEL process instance into a separate log destination .

Introduction

Logging is typically used for recording important events while running the applications. Usually logging is used by the administrators to monitor the system. In the similar lines, Tracing records more data which is used for debugging. Typically, the trace messages will go to a separate destination from the destination where log messages are recorded. The trace files are used by

product development and support teams to debug the problems.

WebSphere Application server uses JUL (

                                    for logging and tracing. JUL is tightly integrated with the product and it is recommended for logging and tracing in the user applications as well.

At the high level, there is a LogManager class that gets instantiated by reading the properties file containing the configuration data. The configuration file lists out various Loggers and Handlers. The Loggers are arranged in hierarchical fashion by LogManager, for example, the Logger com.ibm is the parent of com.ibm.websphere. The Handlers encapsulate logging/tracing destinations like files, sockets etc. Loggers are associated with Handlers which

publish the messages to corresponding destinations.

Each message which is logged or traced is termed as LogRecord. The LogRecords have various Levels. The Loggers and Handler are also set with a particular log Level. When the LogRecord's Level is greater than the Level of Logger and Handler, the LogRecord is published to the corresponding destination. Loggers and Handlers can optionally have a filter, which is a class used to decide whether or not to discard the logging or tracing request based on the contents of the LogRecord.

The Figure1 below illustrates the workings of JUL.

Figure1

-

java.util.logging)

Various ob

jects in JUL

1

Page 02 of 7

(This page contains 00 pictures or other non-text object)

Typically, the steps to log/trace a message are as follows.

// get the Logger object
Logger logger = Logger.getLogger(classname);
logger.entering(classname, methodname);
logger.logp(Level.WARNING, className, methodName,

                          "Message to be logged");
logger.exiting(className, methodName, contactPhoneNumber);

The messages logged or traced thus will go to same log files where server runtime logs or traces messages respectively.

The Level of the LogRecord determines whether the message is a log message or a trace message. As explained in the beginning, the trace messages are published to a different destination from the destination where log messages are published.

The Logging Levels are as below.

Level.SEVERE
Level.WARNING
Level.INFO
Level.CONFIG

Trace levels are as below.

Level.FINE
Level.FINER
Level.FINEST

2

Page 03 of 7

That is, if the LogRecords have log Level as Level.SEVERE or Level.WARNING or Level.INFO or Level.CONFIG then the corresponding message is termed as Log message and

published in the corresponding destination (Systemout.log, System...