This chapter explores the CAMM User Interface. Topics include:
Oracle Composite Application Monitor and Modeler (henceforth referred to as CAMM) can operate under two modes: service mode and standalone application mode. Under standalone application mode, start the CAMM UI by executing the [CAMM Installation]\bin\standalone.bat file.
Under the service mode, you can access CAMM UI either through a web browser after starting the manager process either by running "[CAMMInstallation]/bin/acsera.sh" or starting the "Oracle CAMM" Windows service.
CAMM UI consists of the following core components:
General Menu and Toolbar
The General Toolbar provides general purpose functionality such as quick navigation, view refresh, status, version, and shutdown. You can browse through previously viewed data easily by clicking the back and forward buttons. Displayed data can be force refreshed by using the refresh button. You also get status on CAMM or issue a shutdown command from the Manager item on the General Toolbar.
Double-Click Indicator
The dotted-grid icon next to a table indicates that the double-click operation is available for that data table. Typically, double-clicking displays next level details.
Navigation Pane (upper left)
There are two types of workspaces in the CAMM navigation pane: Monitor and Configure. In the Monitor workspace, you can navigate the managed environment and monitored applications in a tree. Use the Monitor workspace to traverse the CAMM tree model and identify abnormal activities. Use the Configure workspace to create, modify, and review various configuration settings for CAMM.
Main Display Window (upper right)
As you navigate through the CAMM tree model and configuration categories, detailed performance information and configuration settings are displayed in the Main Display Window. You can refresh the Main Display Window at anytime by clicking the Refresh icon.
Custom Views (lower left)
You can create custom views in CAMM by simply dragging and dropping display components. All custom views already created are listed in the Custom Views panel.
When CAMM starts up, the Operational Dashboard appears in the Main Display Window.
This dashboard displays the health of the system. By using the dashboard, you can investigate abnormal behaviors further by using the following navigation techniques.
The Operational Dashboard displays the health indicators for various key entities in the managed environment. CAMM uses traditional traffic light colors to represent the health of these various key entities.
Normal (Green): Within an acceptable range
Warning (Yellow): Approaching configured threshold
Violation (Red): Violated configured threshold
For each component, CAMM uses the following health indicators to provide a comprehensive view. These health indicators are:
Performance
The performance health indicator depicts the relative responsiveness of the monitored entity to the configured threshold.
Availability
The availability health indicator informs you to what extent a particular entity is available to service requests.
Errors
The errors health indicator informs you if the number of errors and exceptions encountered by this entity are approaching or violating the configured threshold.
Load
The load health indicator depicts how many operations have been performed and requests have been served by a particular entity.
CAMM is aware of clusters. As such, these indicators display overall health of a particular entity across the entire cluster. You can drill down for more details by clicking the plus (+) icon.
The status of multiple health indicators are actually a composite of several metrics. For example, the performance health indicator is comprised of metrics such as Average Execution Time and Number of SLO Violations. Using this detailed information, you can quickly determine the reason behind an abnormal status.
Health Indicator Drill Down Details are currently available for high level business functions only. Currently the following business functions are supported:
WebLogic Portal - Portal Applications
Oracle SOA Suite - BPEL Processes
WebLogic Integration - Processes
WebSphere Portal - Portal Applications
WebCenter - ADF/Portal Applications
Further drill-down is possible. By double-clicking the name of the entity, a new viewer relevant to that entity appears. For example, the entities can be business processes running on the Oracle WebLogic Integration platform. By double-clicking on one of these process names, CAMM opens up the Process Flow Viewer.
The Process Flow Viewer and other viewers provide even more application specific information to enable additional analysis.
The Process Flow Viewer is composed of two panels: the flow of selected processes on the left and the Main Display Window on the right. The Main Display Window shows information corresponding to the item selected in the navigation pane. The left panel shows the flow of the selected process. This is the same view a developer would see in Oracle WebLogic Workshop. This unique feature gives you the ability to communicate with others and solve performance problems faster.
Some process nodes are groups of nodes. By clicking the plus sign (+) and minus sign (-) icons, you can expand and collapse the node group. When a node group is collapsed, the information displayed in the Main Display Window is aggregated automatically for the entire node group.
You can drill down on other entries in the Operational Dashboard by double-clicking the entry. For example, when you select and double-click a row in the Operational Dashboard, a new pop-up window appears and provides relevant lower level statistics. You can select an entry in the Operational Dashboard and bring up detailed performance metrics by double-clicking on the operational dashboard.
A monitor workspace consists of the Navigation Pane and the Main Display Window. It is used to navigate the monitored components and display relevant metrics.
The Monitor Workspace is organized hierarchically using a tree view. Starting from the root of the tree, you can quickly drill down to the information you need. You can expand the tree to see more details by clicking the plus sign (+) icon.
When you select a lower level tree node, the Main Display Window displays performance data and renders graphs relevant to the selected item. For instance, when you select the csr desktop node in the css portal tree, the Main Display Window shows the Portal desktop performance table, Desktop hits and Desktop response time graphs.
You can double-click a portlet in the portal desktop layout view to drill down on each level and view the portal desktop structure.
The Oracle SOA Suite workspace is similar to WebLogic, but with a focus on BPEL processes, ESB, and Web Services as opposed to portals and WLI processes.
Like Oracle WebLogic, the Monitor Workspace in the left-hand pane is organized hierarchically using a tree view. Starting from the root of the tree, you can quickly drill down to the information you need. You can expand the tree to see more details by clicking the plus (+) icon.
When you select a lower level tree node, the Main Display Window displays performance data and renders graphs relevant to the selected item. For instance, when you select the Domains desktop node in the BPEL Processes tree the Main Display Window shows the BPEL process performance table, BPEL hits and BPEL response time graphs.
You can double-click on a BPEL Process in the BPEL Process Status view to drill down on each level and view the functional BPEL Process structure.
The WebSphere workspace is similar to the Oracle SOA Suite and Oracle WebLogic with a few differences in the node details.
The Monitor Workspace is organized hierarchically using a tree view. Starting from the root of the tree, you can quickly drill down to the information you need. You can expand the tree to see more details by clicking the plus (+) icon.
When you select a lower level tree node, the Main Display Window displays performance data and renders graphs relevant to the selected item. For instance, when you select the Virtual Portals desktop node in the WebSphere portal tree, the Main Display Window shows the Portal desktop performance table, Desktop hits and Desktop response time graphs.
You can double-click on a portlet in the portal desktop layout view to drill down on each level and view the portal desktop structure.
SOA 11g is discovered through the underlying WebLogic Application Server. You use CAMM's Resource Configuration wizard for specifying the Application Server details. Upon discovering the WebLogic Server container, CAMM detects the presence of SOA Suite components and discovers the Service Components.
SCA focuses on Composites, for example, OrderBookingComposite, OrderSDOComposite, and PartnerSupplierComposite. In turn, each composite provides detailed statistics on Decision Services, Mediators, Human Workflow, and BPEL.
You can double-click on a composite in the SCA desktop layout view to drill down on each level and view the composite desktop structure.
The Oracle WebCenter workspace focuses on ADF task flows, JSF pages, and Portlets with an emphasis on the WebCenter application hierarchy. The WebCenter hierarchy consists of applications utilizing both WebCenter Services and ADF Task Flows within their applications.
Starting from the root of the WebCenter node tree, you can quickly drill down to specific components that comprise a WebCenter application including ADF Task Flows and JSF Pages, as well as the underlying components. Users can then continue to drill-down in context to the ADF Task Flow functional view as well as the architectural view outlining the support Java EE components that make up the infrastructure of various entities within the ADF Task Flow.
In Oracle CAMM, thresholds configured for various measurements are called Service Level Objectives (SLOs). Configuring SLOs is a key activity for establishing and maintaining an effective performance monitoring system. It is easy to configure SLOs in CAMM. By right-clicking on any element, you can configure or view SLOs. This rule applies to the CAMM UI and all other viewers.
When you select Configure Service Level Objectives, CAMM displays the Service Level Objective Configuration window. This window allows you to apply existing SLOs or create new ones. When you click Create New SLO, CAMM guides you through the process of setting up a new SLO.
The steps for SLO creation are as follow:
Select a SLO file. CAMM can store SLO configurations in different files to improve configuration portability.
Define the SLO Entity Type. CAMM automatically selects the appropriate entity type for you based on the selected monitor element. For example, if you want to set a SLO on a Portal Desktop element, CAMM automatically sets the Entity Type for you.
Other information is filled in by default. Normally, there is no need to modify the SLO Entity values.
When you are done setting the SLO Entity Type values, click Create New SLO to go to the second step of the SLO creation process, Defining the SLO Parameters.
Follow these steps to define the SLO parameters:
Type in the name of the SLO parameter.
Select the performance metric.
Define the monitor window size, which determines how long the condition must persist before generating an alert.
Set threshold values for the SLO.
Select what actions to take when a trigger is fired. A list of preconfigured actions is available in the view pane.
Add new actions by going to the Action Configuration node in the Configure Workspace.
Click Save to set the SLO for this monitored element.
You can delete unwanted SLOs for any element from this window.
Note that setting SLOs in CAMM affects the operational dashboard. Typically, a fresh installation of CAMM has no SLOs defined. As a result, most of the traffic light indicators in the operational dashboard use the gray color - an indicator of no status.
CAMM is designed to propagate threshold violation events up the hierarchy. Therefore, when a SLO is set on a lower level metric, the higher level health indicator light becomes activated. Additionally, the health indicator light for the application server that hosts this component also becomes active. Oracle calls this containment approach to SLO event propagation. When a lower level SLO is violated, the violation event propagates all the way up the hierarchy and changes the status of all containers for this event.
For example, say we defined a performance threshold on the average response time metric of the CaseManagement portlet. We would expect the css portal and cgServer health indicator lights to become active because the CaseManagement portlet is part of the css portal, css portal is part of the cssdemo application, and cssdemo application is deployed on cgServer.
In addition to the containment concept, CAMM categorizes SLOs into the following types:
Performance
Availability
Error
Load
In the example, the average response time metric is correctly categorized into the performance type.
If you set a SLO on a metric in the load category such as Portal Desktop Visit Count, you will see the activation of load health indicators for all containers of the desktop. In our example, we set a SLO on the Portal Desktop Visit Count of the csr desktop. This activates the load health indictors for css portal, cssdemo application, and cgServer instance.
Right-click on any tree node and select View Service Level Objective Events to open a new window. You can see all the SLO violation events triggered for the selected entity. CAMM automatically applies a filter to show only relevant events.
Once new SLOs are added, CAMM updates the relevant graphs to visually display these new thresholds. Table 2-1, "SLO Line Types" explains the different line types.
| Line Description | Description |
|---|---|
|
Solid Red Line |
A violation threshold that triggers on high. |
|
Solid Yellow Line |
A cautionary threshold that triggers on high. |
|
Dashed Red Line |
A violation threshold that triggers on low. |
|
Dashed Yellow Line |
A cautionary threshold that triggers on low. |
Use this option to specify blackout time frames to prevent having a specified number of SLOs from being evaluated. You can prevent having unwanted alerts being fired during planned or unplanned down time.
Right-click any tree node and select Configure SLO Blackout to open a new window.
You can view any existing SLO blackout events in the new window.
Use this window to create, delete, or view the details of existing events.
Select an existing event on the list.
Click Delete SLO Blackout.
Confirm that want to delete the entry and click Yes.
Viewing SLO Blackout Summary List
Click SLO Blackout Summary List.
View the details on the existing SLO Blackout events.
Click Show SLO Blackout List to return to the previous window.
Click Create SLO Blackout to view the detail window
Refer to Table 2-2, "SLO Blackout Configuration" to fill in the columns as needed.
Table 2-2 SLO Blackout Configuration
| Column/Metric | Description |
|---|---|
|
Blackout Name |
Type in the name. |
|
Description |
Type in the description of the SLO you are creating. |
|
Blackout By SLO File |
Use to blackout at the file level. The SLO files display in a list where you can select them or cancel out of the window. This option restricts the blackout to the SLO file name. |
|
Blackout By Individual SLOs |
Use to blackout at the SLO level. The SLOs display in a list where you can select them or cancel out of the window. This option restricts the blackout to the SLO name. |
|
Blackout By Entity |
Use to blackout at the entity type level. The entity types display in a drop-down menu where you can select the entity. This option restricts the blackout to the entity type selected. |
|
year, month date, hour, minute, duration |
Use the guidelines to the right of these columns to enter the appropriate information. |
|
recurring |
Select how often you would like to run this blackout event from the drop-down menu. |
In CAMM, you can specify the length of the time the window information is to be displayed. To specify the length of this time window, select the appropriate length in the Time Frame drop-down box. The following Time Frame values are available:
1 hour
2 hours
4 hours
8 hours
12 hours
24 hours
Note:
The CAMM default data collection interval is 60 seconds. As you adjust the data collection interval, CAMM automatically adjusts the display time frames. To learn more about how to configure the data collection interval, refer to the Oracle Composite Application Monitor and Modeler Installation and Configuration Guide.CAMM automatically adjusts information displayed to fit the specified time window. You can drill down to see detailed performance information for a specific range of time.
For example, visualize the drill down process with two screen shots of the same graph with different Time Frames of the average response time for Portal campaign. The first graph has a Time Frame of 24 hours. The second graph has a Time Frame of 1 hour. By increasing the granularity of the Time Frame, you are performing a drill down operation.
In this example, an IT Operations staff noticed abnormally high response time with Portal campaign subsystem. The person decided to investigate further to evaluate the extent of the problem. By changing the Time Frame from 24 hours to 1 hour, this user is able to see that between 14:17 and 14:18, the Portal campaign response time jumped from an average of 1000 milliseconds to 5000 milliseconds. While the problem did not persist, it may warrant additional investigation.
Display Interval indicates the start and end time for the data displayed in the Main Display Window. Display Intervals change as you change the following settings:
Time Frame
Interval Context
Turning Off Time Frame Limitation
When you select a new Time Frame, the Display Interval automatically changes to fit the selected Time Frame. For example, if you were to change the Time Frame from 1 hour to 2 hours, the Start value of the Display Interval changes.
Display Interval can also be changed by setting the Interval Context. The settings for the Interval Context are:
Interval Context Set To End Time Is Current System Time
The default Interval Context for CAMM is to use current system time as End value for the Display Interval. In this default setting, you have a sliding Display Interval and can see the latest performance information in the Main Display Window.
Interval Context Set To End Time Is Fixed
You can also change the Interval Context setting to use a fixed time as the End value for the Display Interval. By selecting the fixed Interval Context, you can create a fixed time window to display performance data. The fixed time window is particularly useful for performing analytical tasks.
Date/Time Selector
When you select to fix the End time for the Interval Context, the CAMM UI enables a pair of Date/Time Selectors to allow you to set Start or End values for the Display Interval. Click the green icon next to the Start and End times to open up the Date/Time Selector.
The Date/Time Selector allows you to set a specific Display Interval to fit your needs. Additionally, the Date/Time Selector enables CAMM to compare current performance trends with historical data.
Note:
Changing the start and end time do conceptually different things. Users are advised to always change their time frame by modifying the end time first, and then the start time. Changing the end time moves the window in time, whereas changing the start time increases/decreases the size of the window.To support the display of data for more than twenty four hours, CAMM allows you to specify your own time frame for data display. To enable this, set Interval Context to End time is fixed and make sure the Use time frame? check box is unchecked. Turning off time frame limitation allows CAMM to display eight days worth of data.
For example, when you specify the time frame to be eight days by adjusting the start and end times through the Date/Time Selector, CAMM then adjusts its view to display eight days worth of data in a single graph. This feature allows you to perform trending analysis over time.
CAMM does not automatically refresh the information in the Main Display Window because its default Refresh Rate is set to None. However, you can specify how frequently information in the Main Display Window should be refreshed by selecting the appropriate value in the Refresh Rate drop-down box.
CAMM is capable of automatically refreshing the information in the Main Display Window at the following rates:
1 minute
2 minutes
5 minutes
This feature provides a quick and easy way for you to locate performance measurements. Based on the query string used, CAMM determines the most appropriate view to display. The following section describes the types of queries supported by CAMM.
The URL of an application can be used to find performance measurements in CAMM. A common use case for the URL query is to copy the URL of a slow performing J2EE application from the browser and copy it in the CAMM URL query dialog box.
URL query can be used to look up performance measurements and model visualizations for the following application types:
BPEL Processes (.bpel)
Portals (.portal)
Processes (.jpd)
Java Page Flows (.jpf)
Struts Actions (.do)
Web Services
Java Server Pages (.jsp)
Servlets
CAMM displays performance information in various formats. Most commonly used display formats in CAMM are tables and graphs.
As a general rule, you can gain more information about a data item by simply pointing the mouse over the interested item.
Minimum and maximum response time measurements are stored in their embedded database in addition to average response time measurements. The min and max metrics, if present, are displayed visually in the UI.
For tables, you can perform a table sort by clicking column headings. Columns can also be rearranged with a simple drag and drop action. The red sort directional arrow appears next to the column currently being sorted.
You can define the zoom in area using a click and drag operation. To zoom in, click and drag the mouse to the right. To zoom out, click and drag the mouse to the left.
Tip:
For graphs with extreme outliers, graph details are lost due to automatic graph scaling. To work around this problem, you can use the graph zoom in feature to review these details.You can toggle on/off vertical ruler in any graph by holding down the Ctrl key. The vertical ruler helps visually line up nodes in a graph for easier analysis.
There are several simple operations you can perform on various tables and graphs in CAMM. The following is a list of the right-click operations associated with tables and graphs:
Table 2-3 Right-click on Tables and Graphs
| Right-Click Operation | Description |
|---|---|
|
Copy cell value |
The right-click operation is available for tables only. This operation copies the cell value to enable common copy/paste operation (table only). |
|
Export as CSV... |
This right-click operation is available for both tables and graphs. This operation saves all the values in the table or graph as a comma separated value (CSV) file. The CSV file can later be imported into other applications such as Microsoft Excel. |
|
Count number of rows |
This right-click operation is available for tables only. This operation returns a count for the number of rows in the selected table (table only). |
|
Fit to View |
Make the table or graph file the entire pane. |
|
Restore View |
Restore the layout to the default state |
|
Show/Hide Table Columns |
Remove or un-remove columns from a table (table only) |
|
Enable/Disable Series |
Remove or un-remove a line from a graph (graphs only) |
For example, you can use the Count number of rows right-click operation to get a total row count for any table.
CAMM provides a number of analytical tools to enable performance analysis. One of these tools is the Comparative View. To access Comparative View, right-click the CAMM Main Display Window and select Create Comparative View.
After the Comparative View window appears, you can use the Date / Time Selector to specify start and end times for each of the two windows in the Comparative View. You can use this tool to compare performance statistics of two different time frames.
Tip:
You can use comparative views to determine if current performance of a specific application or component differs greatly from historical performance or baseline performance captured previously.Comparative views are useful to evaluate current performance characteristics against historical performance characteristics.
To improve collaboration among those who work on application performance issues, CAMM provides the ability to save any view as a PDF file. To save a specific view as a PDF file, right-click on the CAMM Main Display Window and select Save this view as a PDF file.
Easy Scroller is a feature to help you navigate different views in CAMM. To bring up Easy Scroller, right-click on a view in the Main Display pane and select the Easy Scroller option. Drag the box within Easy Scroller to navigate.
For some of the views, CAMM provides the zooming ability. This capability enables you to zoom into diagrams for more fine-grain details and zoom out for more coarse-grain structure.
On the Zoom In/Zoom Out Toolbar, the icon zooms in on the view by 10%, the icon zooms out on the view by 10%, and the icon returns the view back to normal size (100%). You can use the drop-down box to quickly zoom in or zoom out of the view.
While CAMM intelligently selects relevant performance metrics based on its AppSchema model, you can further customize the monitoring environment by configuring additional custom metrics. In addition, you can use custom metrics in problem diagnostic situations where additional visibility is needed to pinpoint problem root cause.
To configure a new custom metric, right-click and select Configure Custom Metric to begin. CAMM walks you through the configuration process.
Custom Metric Configuration window includes the following fields, see Table 2-4:
Table 2-4 Custom Metrics Configuration Window
| Field | Description |
|---|---|
|
Name |
This text field is for defining the display name for the custom metric. |
|
Resource Name |
This drop-down menu is for defining the resource where the custom metric will be collected. |
|
Class Name |
This text field is for defining the fully qualified class name (package + class) associated with the custom metric. |
|
Method Name |
This optional text field is for defining the method name associated with the custom metric. Usage:
Method field examples:
|
After you define the custom metrics, restart the application server instances associated with these customizations. The new custom metrics will be listed under the Custom Metrics node in the CAMM navigation tree.
Newly configured custom metric reports class level performance data, for example invocation count and response time.
You can add metrics to the Operational Dashboard by using the Promote to Dashboard feature. The following steps describe how to add new metrics to the Operational Dashboard.
To add new metrics to the operational dashboard:
Right-click on a node in the navigation tree and select Promote to dashboard to activate the Dashboard Configuration window.
Click Create Dashboard Promotion.
Select the metric to promote to Operational Dashboard from the drop-down menu.
Click Create.
Type in a name in the Name box.
Click Save.
Close the Dashboard Configuration window.
Click Yes to confirm you want to close the window.
Your action is now a new entry on the Operational Dashboard.
Functional View is a type of AppSchema Visualization - a visual way for CAMM to represent the information stored in its AppSchema model. This view is designed to help you understand how business functions are assembled with various functional building blocks. Table 2-5 provides a list of functional views currently available in CAMM.
| Entity Type | Function View | Description |
|---|---|---|
|
Process |
Process Workflow View |
This functional view depicts the workflow associated with the selected WLI and Oracle BPEL business process. It shows all the process nodes and the relationships among them. |
|
Pageflow |
Pageflow Functional View |
This functional view depicts the logical flow associated with a JPS or Struts pageflow. It shows all the pages in a pageflow and the relationships among them. |
|
OSB Proxy Service |
Proxy Service Functional View |
This functional view depicts the pipeline and stage flow associated with an OSB Proxy Service. |
Depending on the type of entity selected, CAMM displays different functional views. Right-click and select Display Functional View to bring up the relevant Functional View associated with the selected entity.
Topology View is another type of AppSchema Visualization - a visual way for CAMM to represent the information stored in its AppSchema model. This view is designed to help you understand how application environments are assembled with various applications, application server instances, and shared resources. This information helps you map composite applications and their building blocks to application server instances and share resources.
The highest level topology view graphically depicts domains, external resources, and shared database resources. The applications used in the following examples are CSS and MedRec demos.
For example, you can have a topology with two CAMM managed resources, CSS Domain and MedRec Domain, two external resources, and a shared database resource. The lines connecting various entities in the Topology Views depict calls made from one entity to another. You can get more information about a specific call by pointing the mouse over a specific line.
It is possible to hide different types of lines in the Topology View. To the line types, right-click the Topology View and highlight the Edge types option to reveal a list of different edge (arrow) types associated with the current Topology View.
The kinds of edge types are:
Deployment Edge Relationship between components defined in the deployment descriptors
Method Call Dynamic call created during runtime execution
The colors displayed in the topology view are explained in Table 2-6.
Table 2-6 Edge Types Color Codes
| Color | Description |
|---|---|
|
Red |
Deployment edges. Represents a reference in deployment descriptor (resource-ref, ejb-ref, ejb-local-ref). In struts modules, it will show forwards. |
|
Purple Edge |
Used in execution view to show that the method calls did not happen in the selected time frame. For example, probe point was created by agent, but no metrics were present for the selected time frame. |
|
Orange Edge |
Used in execution view, orange edge shows an active method call in the selected time frame. For example, there are metrics for that edge in the selected time frame. |
You can perform the following actions on edge types:
To hide all lines of a particular type in the Topology View, un-check a specific edge type. Checking a specific edge type makes these lines appear.
To hide all lines not connected with a specific entity, select a monitored entity in the Topology View, right-click and select Hide other edges.
To hide all arrows not connected to the managed entity, Highlight An Entity and select Hide other edges.
To display the topology specific to the selected managed resource, select a specific managed resource and double-click.
Drilling down on a specific managed resource reveals the relationship among the application server instance and the shared resources it uses. It is possible to reach this same view by right-clicking on the entity and selecting Display Deployment Topology option.
Drilling down on specific application server instance reveals calling relationship among J2EE applications and shared resources. This information is useful to understand how applications are distributed across the infrastructure.
CAMM can also show the Topology View in a tiered fashion, enabling you to better visualize dependency relationships among various servers and share resources. To access tiered Topology View, select an application entity in the Topology View, right-click and select Display Tier Dependencies.
CAMM brings up the Tier Dependency Topology View on the left pane and displays the associated External Calls in the Main Display Window. Table 2-7provides a list of metrics in the External Calls table and their descriptions.
Table 2-7 List of Metrics in the External Calls
| Column/Metric | Description |
|---|---|
|
Caller Class |
Name of the local class making the external call. |
|
Caller Method |
Method name in the local class making the external call. |
|
Target URL |
Target URL associated with the external call. |
|
Class |
Name of the target class associated with the external call. |
|
Method |
Name of the target method associated with the external call. |
|
Invocation Count |
Total number of invocations for a specific external call. |
|
Response Time (ms) |
Average response time in milliseconds for a specific external call. |
Tip:
External Calls contains information you can use to determine the types of calls made among various servers, applications, and shared resources. Use this information to diagnose problems associated with cross-JVM calls. The target URL provides clues as to the type of external call made.Note:
Topology View is available for nodes under Applications and Resources nodes. The Topology tab displays the Topology View associated with a specific application.Architecture View is another type of AppSchema Visualization; a visual way for CAMM to represent the information stored in its AppSchema model. This view is designed to help you understand the structure and behaviors of J2EE and SOA applications at the module and component level. Some Architecture Views also include built-in delay analysis to help identify potential bottlenecks in a given call path.
The Architecture View in CAMM is capable of showing application structure and component relationships at two levels: module and component levels. At each level, CAMM can show both active and potential call paths. Table 2-8 describes various types of Architecture Views.
Drill down on a specific application to launch into the Architecture View. This action demonstrates the logical progression of drilling from high level resource-centric topology view, down through application-centric topology view, to module-centric architecture view. Using this logical drill down, you can understand the structure of your application runtime environments and diagnose problems.
Table 2-8 Various Types of Architecture View
| Tab Name | Description |
|---|---|
|
This is the default Architecture View at the module level. The Module Level Execution view shows the active calling relationships among various J2EE modules (EAR, WAR, JAR, and so on). Shared resources are also included. |
|
|
The Module Level view shows the potential calling relationships among various J2EE modules. Shared resources are also included. It should also be noted that any object that is not connected within the static view will not be included at this level and if there are no static connections at all between objects, every potential object relationship will be displayed. |
|
|
This is the default Architecture View at the component level. The Component Level Execution view shows the active calling relationships among different J2EE components (EJB, servlet, JSP, and so on). Shared resources are also included. |
|
|
The Component Level view shows the potential calling relationships among various J2EE components. Shared resources are also included. Similar to the module level, any object that is not connected within the static view will not be included at this level and if there are no static connections at all between objects, every potential object relationship will be displayed. |
These various types of architecture views are color coded in order to provide additional information. Table 2-9 lists color codes and their meanings.
Table 2-9 Architecture View Color Codes
| Background Color | Description |
|---|---|
|
Orange |
The orange background color represents entry points into the application or module. The orange color also represents that these entities belong to the same application or module currently selected (in context). |
|
Green |
The green background color represents entry points into the application or module. The green color also represents that these entities belong to other applications or modules (out of context). The green color is also used to represent share resources. |
|
White |
The white background color represents that these entities belong to the same application and module currently selected (in context). |
|
Blue |
The blue background color represents that these entities belong to other applications and modules (out of context). The blue color also represents shared resources. |
CAMM graphically depicts active calling relationships among various J2EE modules and shared resources.
There are several ways to access the Architecture View. One way is through the Deployments node associated with a specific application under the Application Node. Application specific Architecture View can be accessed using the Deployments node on the Oracle Tree.
The Architecture View can also be accessed as part of a diagnostic drill down from the Operations Dashboard. Double-click on the problematic row on the Operations Dashboard to see a pop-up window with detailed performance data. Further double-clicking takes you to the appropriate Architecture View.
The last way to access the Architecture View is by right-clicking a managed entity and selecting the Architecture View. Right-click and select Architecture View to start the drill down process.
The arrows connecting various entities in the Architecture Views depict calls made from one entity to another. You can get more information about a specific call by pointing the mouse over a specific arrow. Mousing over arrows shows the details of a specific call in Architecture View
It is possible to hide different types of arrows in the Architecture View. To do this, right-click on the Architecture View and highlight the Edge types option to reveal a list of different edge (arrow) types associated with current Architecture View. Unchecking a specific edge type hides all lines of that type in the Architecture View. Checking a specific edge type makes these lines appear.
See Table 2-6 for the color descriptions of edge types. To hide all lines not connected with a specific entity, select a monitored entity in the Architecture View, right-click and select Hide other edges. Highlight an entity and select Hide other edges to hide all arrows not connected to the managed entity.
The Architecture View Summary provides the delay analysis associated with the active call path displayed. The table and pie chart displayed in the right pane guides you to leading delay contributors in the displayed call path. Selecting a specific component in the call path brings up component specific information. You will see the following tabs:
Summary tab first which includes high-level delay data for both inbound and outbound calls.
The Instrumentation tab shows detailed method level performance data associated with the selected component. Click the Instrumentation tab to see detailed performance measurements and information at the method level.
The Errors/Exceptions tab shows the errors metrics associated with the selected portal or BPEL process.
The SQL Statement tab shows SQL statements and their performance data associated with the selected component.
The Transactions tab shows the transaction events associated with the selected portal and children below.
Table 2-10 describes various types of metrics provided by CAMM.
| Examples | Metric Type | Metric Description |
|---|---|---|
|
Active Sessions Completions Pending Requests Running Instances Max Capacity Messages High |
A count of the monitored entity at a point in time. CAMM plots these snapshot counts in trend graphs. |
|
|
Requests Serviced Total Sessions [Processes] Aborted [Processes] Terminated [Method] Invocation Count Bytes Received |
A count of the monitored entity incrementally aggregated from the beginning of display time window. CAMM shows these aggregated counts in summary tables. |
|
|
Response Time Elapse Time Connection Delay |
Calculated every sampling period (default 60 seconds), the average timing is calculated by dividing the total amount of time needed to complete the monitored business unit of work by the number of completed business units of work. CAMM uses this data in the following two ways:
|
|
|
Min/Max |
Minimum and maximum response time measurements found per collection sampling intervals. These are stored in their embedded database in addition to average response time measurements. The default is 60 seconds. |