Setting up SAP J2EE Engine 6.20 for Application Tracing and Remote Debugging

SAP J2EE Engine 6.20 is an environment for applications that are developed based on the distributed model. This suggests the existence of specific mechanisms for application calls tracing and remote debugging. They provide fast and easy error identification and correction.

Application Tracing

The application tracing mechanism enables you to log user calls in the log system of SAP J2EE Engine. This includes all operations performed by a client during its calls through the different modules – Web Container, EJB Container, Transaction Service, P4 Calls, DBPool Service, HTTP Service and EISConnector Service.

The trace file location is: <SAPj2eeEngine_install_dir> / cluster/server/services/log/work/DEFAULT.log . This file can be changed using the DefaultNormalFile property in the Log service “Properties” tab.

Note: Default.log file contains only log messages that cannot be found in another log file (for example, Error.log ).

Setting SAP J2EE Engine Tracing Mode

By default, the application tracing mechanism is disabled. To enable the tracing mode, you must complete two steps – enabling the application tracing, and setting a trace level.

Enabling Application Tracing

Complete the following steps:

The LogLevel and the NormalLogLevel properties must be changed
LogLevel=N NormalLogLevel=M
where M and N can be set to 7 or 8.
Enable the application tracing mechanism using the following console command from the ADMIN command group:
apptrace [enable | enableAll | disable]
All changes in server trace mode are logged as well.

Setting a Trace Level

The following options are available:

If apptrace –enableAll is executed in the command prompt, the operations of all users are traced.
If apptrace –enable is executed in the command prompt, consider the following conditions to trace the operations performed by the users

In the Servlet_jsp Engine, ?jsp_trace=N must be passed with the HTTP request to a servlet or ® JSP (that is, jsp_trace parameter must be added to the request).
In HTTP using ICMAN – SAP J2EE Engine communication protocol, a trace level can be set in the protocol header. The trace level can have the following values
TRACE_LEVEL_NO (no trace)
TRACE_LEVEL_ERRORS (errors and warnings are traced)
TRACE_LEVEL_200BYTES (only the first 200 bytes are traced)
TRACE_LEVEL_FULL (full trace)

Note 1: The jsp_trace parameter must be attached only to servlets or JSPs requests. If the parameter is attached to static components (html, txt, jpg, xml, and so on), no tracing is performed.

Note 2: All modules log similar events if the jsp_trace parameter is greater than zero. However, for the HTTP Service and Web container, a value between 0 and 3 has the following meaning:

0 (or less) – No tracing is performed
1 – Only if errors occur
2 – Only the name of the action is logged
3 – Full description of the action

The jsp_trace parameter is associated to user session – that is, it must be passed with the first request only, and the following requests are traced as well. In addition, JSP can be traced at compilation time by executing apptrace –enableall command and then passing jsp_trace parameter with the first request to the JSP.

Traced Components

The following list of components can be traced during client calls:

Web Container – includes JSPs or servlets invoked by the client along with errors that occur during the invocation
HTTP Service – all HTTP requests and responses can be traced
EJB Container – invoking Enterprise JavaBeans methods
Transaction Service – all events that occur during a client transaction can also be traced ( begin() , commit() , or rollback() of the transaction)
P4 Calls – in all generated stubs and skeletons, the names are logged of the method and the class invoked
DBPool Service – the following events can be logged

Take a physical and logical connection
Attempt to take a physical connection
Return of a physical connection
Commit and rollback of a connection
Invoke methods of a XAResource (including XID flag)

EISConnector Service – the following events can be logged

Connection closed
Connection error occurred
Local transaction committed
Local transaction rollback
Commit and rollback of XAResources
Start() method, including XID and flag

SAP J2EE Engine 6.20 Remote Debugging

SAP J2EE Engine server nodes can be run in debug mode in the terms defined by the Java Platform Debugger Architecture (JPDA). Using JPDA users can utilize debugging applications to connect to running Java virtual machines and perform typical debugging steps controlling execution of threads within the virtual machine.

To debug a SAP J2EE Engine server node, complete the following steps:

Configure the server node as a debug node.
Start a debugging session.

Step 1: Configuring Server Node as a Debug Node

First, to be able to run an SAP J2EE Engine server node in debug mode, start the Virtual Machine (VM) of the selected node with the options provided by JPDA.

Note: These are the standard options described in JPDA documentation at http://java.sun.com.

On the selected node, execute the SUSPEND command from the ADMIN Shell command group. The dispatcher does not send client requests to be processed by the “suspended” server element. To terminate the suspended state of the server node, use the RESUME command from the ADMIN Shell command group. You can run a number of server nodes in debug mode simultaneously. A list of suspended server nodes is displayed using the LSC –S command from the ADMIN command group.

Note: For information about these commands, refer to the Shell Commands Reference section in this manual.

Step 2: Starting a Debugging Session

After configuring a debug server node and connecting a debugger to the VM in which it is running, a request for debugging must be sent to this server node to initiate debugging. Since client requests are not sent to suspended server nodes, a “debugging” session must be started. Within this session, all client requests are sent to suspended server nodes only. This is done by attaching a cookie to the session. A debugging session is started by requesting the URL of either http://host:port/@@@DEBUG@@@ or http://host:port/@@@DEBUG@@@?ELEMENT_ID=n type in a browser, where n is the cluster ID of a suspended element. When the session is established, the ID of the server element that is to process the subsequent request is displayed in the browser.

If the first type of URL is used to establish the session, subsequent requests are sent to any of the suspended elements. The dispatcher node sends the first incoming request to the first of the suspended nodes, then the second request is directed to the second node, and so on, until all suspended nodes have served a request. After that, the dispatcher starts with the first one, and so on. If the session is established with the second type of URL, all subsequent requests are sent to the suspended server node with the specified cluster ID.

Note: If a JSP is to be debugged, it must be requested at least once before debugging so that it can be compiled to a servlet. You can also set the CompileOnStartUp property of Servlet_jsp Service to true for compiling the JSP when the application is deployed.

To extract debug information that is specific and is available only when the class is compiled with the -g option of the compiler, set the CompilerDebuggingInfo property of Servlet_jsp Service to true, or compile the class with -g option before deploying the application.

Refer to Service Administration Reference for information on Servlet_jsp Service properties.