In this chapter, we will cover the following recipes:
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:
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.
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 |
---|---|---|---|
Properties file / via code |
|
| |
Properties file / via code |
|
| |
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.