In addition to the metrics it provides about transactions, services, endpoints, and operations, Business Transaction Management allows you to view additional information about the JVM context within which a request executes and to see more detailed information about the request as it executes across distributed JVMs.
The additional views are the following:
The JVMD view allows you to view the details of an executing Java Virtual Machine (JVM) process for the period within which a given operation executes. You can see stack frames for executing threads, thread state information, aggregate information about the frequency and cost of method execution, information regarding the holding of Java and DB locks, and details about the objects in the Java heap. JVMD also stores historical data for each JVM it monitors so you can view data relating to things that have happened in the past and get a sense for historical trends.
The Request Instance Diagnostics view allows you to trace the path of a request in a WebLogic domain and to generate a report of all the metrics associated with a particular instance of the request.
The following sections describe the information you can get from these views as they relate to transaction operations and explain how you can access these views from the Business Transaction Management console.
For information on how to configure Business Transaction Management to access these views, see Enabling Access to the JVMD and RID Views.
Using JVMD to access additional information can be useful in situations like the following:
You are viewing summary information for a transaction and see that a particular operation is unusually slow or faulty. You want to get more information about the execution of that step, and you initiate a drill through to JVMD from this point.
You are viewing the details of a logged transaction instance and you notice that one of the steps in the transaction did not behave as expected. You would like more details about the execution of this step from JVMD, and you initiate a drill through to JVMD from this point.
You are viewing a collection of logged messages in the message log search tool and you notice a message that appears abnormal or unusual. You would like to get more details of the handling of that message using JVMD, and you initiate a drill through to JVMD from this point.
You can access the JVMD console from the following entry points:
Message Log tab for a service, endpoint, logical operation, physical operation, or transaction. Right-click on row and select Drilldown to JVMD from the drop-list.
Transaction Instance Inspector. Right click on an operation (either in the graph or grid view) and select Drilldown to JVMD from the drop-list. When a step is executed repetitively, the first endpoint on which it was executed is selected.
Message Search Log tool Right-click on a message row and select Drilldown to JVMD from the drop-list.
In each of these cases, a new window is displayed showing the JVMD view. In the multi-VM case, JVMD shows a VM group target and aggregate information for that group.
For information on how to enable access to the JVMD page, see Enabling Access to the JVMD and RID Views.
To view information about an operation (message) in the Request Instance Diagnostic view, that message must be assigned an Execution Context Identifier (ECID). This section explains what an ECID is, how ECIDs are assigned, how they map to transactions, and how you can access and use the Request Instance Diagnostic view from the Business Transaction Management console.
Data is displayed in the Request Instance Diagnostics view only for operations executing in a WebLogic (10.3.x) domain with JRF 11.1.1.1.0 or higher. (The installation of SOA 11g, OSB 11g, and Fusion Applications already includes the JRF.)
For information on how to enable access to the Request Instance Diagnostics page, see Enabling Access to the JVMD and RID Views.
ECID information for a message request or response is displayed in the Business Transaction Management console even if you have not installed a JVMD agent or configured a connection to the EM console; however, without having satisfied these pre-requisites, you will not be able to open the Request Instance Diagnostic view for a given ECID.
You can use the Message Log Search tool to find all messages that have a given ECID. For more information, see Using the Message Log Search Tool.
An ECID is an identifier for tracking a request, for components into the Oracle technology stack. It is usually generated by the outer-most Oracle component handling the request and may be propagated by the Oracle components handling that request, even crossing server boundaries. The creation and propagation of ECIDs enable the sharing of context and of diagnostic data between components.
Transaction operations (messages) that have been handled by Execution Context aware components represent steps in a request that were assigned an ECID shared by all the request steps. If Business Transaction Management observes that a message has an associated ECID, it assigns the ECID as an intrinsic property of the message request and response, and it notes the value of the ECID in the message header. The ECID value for a given operation and phase is stored in the standard properties requestECID and responseECID.
Because transactions might span multiple Oracle execution contexts, it is possible for different messages in a transaction to have different ECIDs. It is also possible for the same ECID to be shared by operations in different transactions. The next section describes how ECIDs are mapped to transaction operations (messages).
In addition to using ECIDs to drill down to the JVMD or RID views, ECIDs are also useful in the following situations:
You want to define a transaction where the start and end message are not the same. In this case, you can use a common ECID value to correlate the start and end message. This enables BTM to measure performance for such a transaction.
You want to manually correlate two disconnected operations using ECID as the shared key value.
You want to search for a message that has a specific ECID value.
Depending on how a transaction has been defined and deployed, the messages it contains might have one or more ECIDs. It's important to understand the mapping between ECIDs and transaction messages. This section describes two possibilities.
Multiple transaction definitions; one ECID
Consider a call chain A -> B ->C ->D ->. If I define transaction X to include ABC, and transaction Y to include CDE, the messages in an instance of X and an instance of Y that resulted from a single invocation will have the same ECID.
Multiple ECIDs; one transaction.
If transaction X includes the call chain A -> B ->C, and B executes on a non-Oracle platform, the message that corresponds to operation B will have no ECID, and the messages for A and C will have different ECIDs.
For a given operation, the ECID for a request may not be the same as the ECID for a response.
In short, seeing multiple ECIDs for a single transaction, or the inverse, does not mean that anything is wrong; it can provide valuable information about operation flows and invocation boundaries.
The Request Instance Diagnostics view, which provides information about a given ECID, is accessible from the following locations:
Transaction Summary tab. Right-click on an operation (in the graph or grid view) and select Request Instance Diagnostics from the drop-list.
Message Log tab for a service, endpoint, logical operation, physical operation, or transaction. Right-click on row and select Request Instance Diagnostics from the drop-list.
Transaction Instance Inspector. Right click on an operation (either in the graph or grid view) and select Request Instance Diagnostics from the drop-list.
Message Search Log tool Right-click on a message row and select Request Instance Diagnostics from the drop-list.
It is possible that the Request Instance Diagnostics page displays no information for a given ECID. This can be because the default sample rate for the JVM monitoring tool is longer than the step duration, and the specified ECID executed outside of the sampled period.
The Request Instance Diagnostics page displays a list of the JVMs through which request steps with the specified ECID executed. For each JVM the following details are displayed:
One or more target JVMs where the request executed.
JVMs can show up more than once with the same ECID if the RID (relationship ID) is different for a request step. (The RID is a sequence of digits that represents the relationship of the current step's execution to the execution of the request as a whole.)
The start time and duration of the request.
The request name, the individual step in the request; for example, jsp, EJB, or DB.
The CPU and memory use by the JVM.
Garbage collection statistics (GC Major/Minor).
The bar graph displayed at the bottom of the Request Instance Diagnostics view shows the thread state in each JVM snapshot taken within the duration of the request. Each color represents a different thread state; a color key is shown on the right.
You can click on any bar in the bar graph to display a pane with detailed information for the given thread and the thread stack.
The Request Aggregate tab does not contain information relevant to transactions.
You can access the Request Instance diagnostics page in different ways. For example, you notice that a particular operation is taking an unusual amount of time and you want more information about its runtime context. If an ECID is supplied for the operation, you can drill in to the Request Instance Diagnostics page and get additional information. Alternately, you obtain an ECID from an external source and you want to see whether messages bearing this ECID participate in any transaction. You would use the Message Log Search tool to search for all messages associated with this ECID. Having found the messages, you can see the corresponding services and operations, view related instances, and find the transaction instance that included the message of interest.
To enable access to the JVM Diagnostics and Request Instance Diagnostics views, you must do the following:
Install the JVMD agent on all nodes hosting your monitored services.
Deploy the JVMD manager in EM.
Install a Business Transaction Management observer on all nodes hosting your monitored services. (This would already be the case if you are able to observe traffic.)
For RID only: enable instance logging. To access message content, you must also enable message content logging.
Configure Business Transaction Management to access the EM console as explained next.
Note:
ECID information is displayed in the Business Transaction Management console even if you have not installed a JVMD agent or configured a connection to the EM console; however, without having satisfied these pre-requisites, you will not be able to open the Request Instance Diagnostic view for a given ECID.The following procedure explains how you connect to the EM console. This is required to enable drill down to the JVM Diagnostics page and to the Request Instance Diagnostics page.
Select System Services from the Navigator.
Find and select the AP_Sphere_Service entry.
Select Admin > Edit Setup Data for AP_Sphere_Service.
Click the Edit XML button.
Scroll to the bottom of the XML document and find the emgcURL element.
Edit this XML element so that it contains the base URL for the EM console. For example, if you have an EM console running at https://adc2101158:4473/em, you would enter https://adc2101158:4473, and the edited entry would look like this:
<pfx6:emgcURL>https://adc2101158:4473</pfx6:emgcURL>
Note that the namespace prefix might be other than pfx6; use whatever value appears in the XML text.
Click the Apply button to save changes.
You will have to supply login information for the JVM Diagnostics console when you access it. Single sign on is not supported.