Chapter 3. Advanced Tracing and Logging

In this chapter, we will cover the following recipes:

  • Creating a custom logger in a BPEL process
  • Defining composite sensors
  • Adding a composite sensor
  • Monitoring a composite sensor
  • Configuring the logfiles
  • Changing the level of tracing
  • Editing the logfiles
  • Viewing logfiles in the Enterprise Manager Console
  • Viewing metrics and statistics

Introduction

In this chapter, we will explore the tracing and logging techniques in the Oracle SOA Suite. Note that the BPEL specification does not define the tracing and logging in a BPEL process. Rather, both functionalities require a BPEL server vendor extension. Tracing as well as logging becomes handy in various situations. If there are problems during BPEL process deployment, we can check the logfiles to see what went wrong if the error is not recognized from the console.

Another example is in situations where we know something is wrong inside a BPEL process; however, we are unable to pinpoint the exact position in the code. In that case, we use the tracing functionality to drill down into the problem to find the root cause of the situation we are investigating. The tracing functionality is also used for tracking a business process execution. Tracing provides insightful information on the steps performed by the business process. Tracing is more focused on the business process execution while logging is more oriented towards what is happening with the system. Of course, we have no problem configuring logging to be enabled only for a particular component. We can distinguish between the tracing and logging functionality from the point of view of the context they cover. While logging covers mainly the technical details of BPEL process execution, it is fair enough to say that tracing is more often used to cover the business aspects of BPEL process execution. Oracle SOA Suite provides two instruments for efficient tracing described as follows:

  • End-to-end instance tracing: We can trace a business process from start to finish inside the Oracle SOA Suite boundaries. With end-to-end instance tracing, we are able to trace all the data and flow from the beginning to the end of the BPEL process execution, being either response, fault, exit, or termination. For example, we can trace the business process that initiates from the portal. Also, the request from/to Oracle Service Bus (OSB) can be traced. Further more, we can trace a BPEL process and its external web services interaction and also the human task workflow interaction. In a single trace, we can receive, for example, a call from one BPEL process to an other BPEL process.
  • Sensors: Sensors are used as a springboard when we need to investigate the facts of a business process. Facts, for example, are presented in variables holding information, either business or process type. If we want to start investigating some problem, we need to gather information about the business process, and here we can utilize the sensors. In the Oracle SOA Suite, we can define two types of sensors:
    • Composite sensors are defined at the level of SCA (Service Component Architecture) composite. Remember we said that SCA involves interconnection between BPEL processes, how a BPEL process is exposed as a web service, and which web services a BPEL process is referencing. The composite sensors provide the ability to implement tractable fields on messages. We use composite sensors to monitor incoming and outgoing messages. The composite sensors are defined for the services and the referenced bindings.
    • BPEL process sensors are defined inside a business process. We can define BPEL sensors on variables, faults, and activities.

The sensor values are propagated via different channels. The common channel where data for both types of sensors is published is the database storage. Additional to this, the BPEL process sensor values can be propagated via a JMS queue, JMS topic, Custom Java class, and JMS adapter. We can observe the values of the sensors via the Oracle Enterprise Manager Console. The sensor values are seen in flow trace information of a business process instance. Sensor information has a separated section along with the flow of BPEL process and fault occurred in the business process.

The logging functionality provides very valuable information about what is happening inside the application. With the logging information, we can gather information about problems in the application, identify the flow of the problem, and learn the application's functioning. In the distributed environments where business processes run, the logging functionality is a fundamental requirement for the inter-exchange of information between systems. We can find different logging flavors in the Oracle SOA Suite. The fundamental logging system is the Java Utilities Logging (JUL) utility. We can also use the LOG4J logging framework. As the native logging support, Oracle SOA Suite uses the Oracle diagnostic logging (ODL) functionality.

Note

The LOG4J project home page can be accessed at the following URL:

http://logging.apache.org/log4j/1.2/

The elements that perform the logging job consist of formatters and handlers. The formatter defines the layout of the information to be logged. We have a plethora of formatters. For example, XMLFormatter wraps the logging content into XML and passes the content to the defined handler. As a result, we are able to see the XML formatted logging information. While the formatters define how the logging information will look, we can say that the handlers define where the logging information will be stored. While ConsoleHandler defines that logging information is printed to the console, FileHandler stores the logging information into a file.

In the following table, we summarize the most common properties of the three mentioned logging facilities:

Logging mechanism

Configuration

Formatters

Handlers

Java Utilities Logging

Properties file / via code

SimpleFormatter

XMLFormatter

StreamHandler

ConsoleHandler

FileHandler

SocketHandler

MemoryHandler

LOG4J

Properties file / via code

EnhancedPatternLayout

HTMLLayout

PatternLayout

SimpleLayout

XMLLayout

SerializedLayout

SyslogLayout

ConsoleAppender

FileAppender

JMSQueueAppender

JMSTopicAppender

OutputStreamAppender

RollingFileAppender

SMTPAppender

SocketAppender

SyslogAppender

ODL

Properties file / via Oracle Enterprise Manager Console

The logs are produced as plain text or XML

Primarily logging to the file

Each of the logging mechanisms also supports different types of log levels. Log levels define the granularity of the logging information. For example, the DEBUG log level shows all the logging information that exists, while the ERROR log level shows only critical business process information such as occurring exceptions. It is important to set a proper log level in order not to not collect too much or too little logging information. If we have too much logging information, it is much more difficult to find errors. The following table shows the mapping of the log levels between different logging mechanisms:

Java Utilities Logging

LOG4J

ODL

SEVERE

ERROR

FATAL

INCIDENT_ERROR:1

INCIDENT_ERROR:4

INCIDENT_ERROR:14

INCIDENT_ERROR:24

ERROR:1

WARNING

WARN

ERROR:7

WARNING:1

WARNING:7

INFO

INFO

NOTIFICATION:1

CONFIG

N/A

NOTIFICATION:16

FINE

FINER

FINEST

DEBUG

TRACE

TRACE

TRACE:1

TRACE:16

TRACE:32

The following recipes will show you how to most effectively utilize the tracing and logging functionality of Oracle SOA Suite.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset