How to handle logging in BPEL Processes

1.1. Logging In Bpel

Logging can be performed on domain-level and system-level and you can use different mechanisms to log events, task details, …

In this post I’ve summarized the basic logging functionality you can use on bpel processes.


1.1.1. Process Logging Information

Oracle BPEL Process Manager uses the log4j tool to generate log files containing messages that describe startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information.

The log4j tool enables logging at runtime without modifying the application binary.
Instead, logging behavior is controlled by editing properties in Oracle BPEL Control
and Oracle BPEL Admin Console.

Two logging levels are supported in Oracle BPEL Process Manager:
· Domain
o Manages logging information within specific domains
· System
o Manages logging information on a system-wide level

1.1.1.1. Domain-wide Logging

These can be configured through the BPEL Console (http://hostname:port/BPELConsole) > manage BPEL domain > logging or by editing log4j-config.xml in $BPEL_HOME\integration\orabpel\domains\\config

The different domains to log about:
· .collaxa.cube.engine.deployment – deployment related logging
· .collaxa.cube.compiler – compilation related logging
· .collaxa.cube.messaging – messaging layer (as bpel used messaging services to scale)
· .collaxa.cube.security – server side security (fwrk)
· .oracle.bpel.security – inside validator logging
· .collaxa.cube.ws – everything that is related to communication (WSIF layer, SOAP, Adapters) – shows you at least a longer stack if something breaks there
· .collaxa.cube.xml – xml transformation, storage, hydration
· .collaxa.cube.services – logging for services like Notification or Human Workflow
· .collaxa.cube.engine.delivery – Delivery Service and Manager, responsible for callbacks, and first (initiating) delivery
· .collaxa.cube – cube related logging (system)

1.1.1.2. System-wide Logging

System-wide loggers are used for logging information about infrastructure, AXIS and WSIF bindings. They can be configured through the BPEL Admin Console (http://hostname:port/BPELAdmin) > logging or by editing log4j-config.xml in $BPEL_HOME\integration\orabpel\system\config

The different systems to log about:
· org.collaxa.thirdparty.apache.wsif – logger for system-wide WSIF
· org.collaxa.thirdparty.apache.axis.transport – logger to see what axis is sending on the wire
· org.collaxa.thirdparty.apache.axis – general axis related logging
· collaxa.cube.services – all BPEL PM wide services
· collaxa.cube.infrastructure – infrastructure such as DB connectors

1.1.1.3. Log Level

The following logging levels are available and listed here from highest priority to lowest priority. When a logging level is specified, all messages with a lower priority level than the one selected are ignored.

· Off
o Disables logging. This selection is the highest priority.
· Fatal
o Logs critical messages. After logging occurs, the application quits abnormally.
· Error
o Logs application error messages to a log; the application continues to run (for example, an administrator-supplied configuration parameter is incorrect and you default to using a hard-coded value).
· Warn
o Logs warning messages to a log; the application continues to run without problems.
· Info
o Logs messages in a format similar to the verbose mode of many applications.
· Debug
o Logs debugging messages that should not be printed when the application is in a production environment.
· All
o Enables all logging. This selection is the lowest priority.

1.1.2. Logging with Sensors

You can use sensors to generate application logging activity.

Note that logging with sensors impacts performance because sensor data objects are built even when logging is disabled.

You add sensors to specific activities and then extract data from variables. To do this, you must implement a custom sensor publishing action to do the log4j logging. For example, you can create a sensor on an invoke activity and create a message that is
sent to a JMS queue.

1.1.3. Logging with bpelx:exec in a Java Embedding Activity

You can also log messages by adding custom Java code to a BPEL process using the Java BPEL exec extension bpelx:exec inside a Java Embedding activity in Oracle JDeveloper.

The method addAuditTrailEntry(String):void enables you to add an entry to the audit trail.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s