4 Discovering Services and Dependencies

This chapter explains how you use Business Transaction Management to discover containers, services, and dependencies. Using this information you can get an exact picture of how your distributed application works, what components have performance issues, and what components require closer monitoring. It includes the following sections:

For a complete and up-to-date list of the types of services and components that Business Transaction Management can discover and monitor, refer to the Business Transaction Management Certification Matrix. You can locate this document by searching for "BTM certification" at http://support.oracle.com.

4.1 About Discovery

Discovery is the process that allows you to identify the business components that make up a composite application and to understand how they relate to one another (their dependencies.) This section explains the concepts and processes you must understand to get exactly the information you need during the discovery process. It explains

  • how Business Transaction Management models a wide variety of component types

  • the steps of the discovery process

  • how you can limit discovery for technologies that include a large number of intermediate endpoints

  • how you can manually register services that are not automatically discoverable

  • how you can model JDBC calls

For information about resolving discovery problems, see Section 12.7, "Resolving Discovery Issues."

4.1.1 What Can Be Discovered

Business Transaction Management can discover the following elements:

  • Application components: this includes the logical service that designates a deployed component type, the endpoints (instances of that service), and the operations that can be invoked on an endpoint.

  • Containers

  • The dependencies between components

Business Transaction Management can discover a wide variety of component types and the containers in which they reside. The same model is used to represent interconnected components no matter what the component type: the model consists of services that interact by sending request and response XML messages. The model also assumes that each of the services is described by a WSDL specifying the service's location and its interface. If such a WSDL does not exist because the component is not a web service, Business Transaction Management constructs an artificial WSDL that it uses to enable the system to process the component consistently. The model is illustrated by the following figure.

Description of svcs_and_msgs.gif follows
Description of the illustration svcs_and_msgs.gif

For example, if you have a composite application consisting of a web service that calls an EJB that accesses a database via JDBC, it will be modeled as three services that communicate using XML messages. When you use the Business Transaction Management console to view discovered components, these are listed as services, and the messages they exchange are listed as operations belonging to these services. A message corresponds to either the request or response phase of an operation.

In some cases, the observed traffic type suits this model perfectly; for example, a JAX-WS service or a JAX-RPC service. In other cases, Business Transaction Management must map the component type in a way that is compatible with its basic model. The detail of this mapping might be important if you plan to discover and monitor components that are not web services.

Business Transaction Management discovers components by observing the message traffic that flows from one component to another. Based on the data derived from observing this traffic, Business Transaction Management can also discover how these components are related to one another and draw a map of their dependencies. Dependency information provides an accurate picture of how your composite application is really behaving. It might alert you to the fact that certain components are never called, and it provides a basis for defining business transactions.

4.1.2 The Discovery Process

The most important fact to understand about discovery is that it is entirely traffic-based. If messages are not flowing through the observed endpoints, Business Transaction Management cannot discover any application components nor can it discover the dependencies between these components. When in doubt, send traffic. This section outlines the steps involved in discovering distributed application components in your observed environment. To learn more, read the sections that are linked to from the following steps.

Before discovery can happen, you must install the observers in the environment you want to observe, and you must configure the observer communication policy to define communication between the observers and the monitor or monitor groups responsible for the further processing of the data discovered by the observers.

Discovery happens in two stages: during the priming stage, observed traffic causes the observer to start communicating with the monitor; during the observation stage, a measurement policy is applied to the data that flows from observer to monitor. This is to say that it might take a little while to build a complete picture of your working system. One symptom of this is that if you send 100 messages and Business Transaction Management reports seeing only 98, the messages that are not accounted for are the messages that served to prime the discovery process.

Discovery involves the following steps:

  1. Send traffic through your system.

  2. Check the containers being observed. If load balancers are being used, these must also be visible. (Restarting the containers after installing Business Transaction Management is not enough to make them visible, you must send traffic to have them be seen.)

  3. View services to see that all the services you are interested in observing have been discovered.

  4. Check that measurements are being taken by looking at the Summary or Analysis tab for a service. Throughput, traffic, maximum response time, and average response time should be available for all the services involved in message traffic. If measurements are inaccurate or missing, it's possible that not enough time has elapsed for Business Transaction Management to calculate traffic measurements or perhaps monitoring was disabled.

  5. Look at dependencies in the Service Map to see how traffic is flowing in your system.

  6. Adjust as necessary. Generally speaking if the discovered picture does not meet your expectations, the first thing to do is run more traffic to make sure Business Transaction Management has had time to see all pieces of your system. If that does not resolve your problem, you might need to do one or more of the following:

    • enable probes that are appropriate for the objects you are trying to discover.

    • manually register a service; see Section 4.5, "Manually Registering a Service."

    • resolve discovery problems due to versioning policy or replication problem.

4.1.3 Limiting Discovery

Depending on the technology, some messages flow directly from a client to a service; others flow through a host of intermediate endpoints before they reach their actual destination. Such intermediate endpoints might comprise the implementation of a messaging system, a job scheduling system, a distributed system, and so on. When installing probes for technologies that use intermediate endpoints, Business Transaction Management allows you to specify whether you want to monitor all endpoints or just the endpoints at the edge of such systems; often these are the endpoints that directly represent the business services of interest. By default, the monitoring of intermediary endpoints is turned off. This improves monitoring performance and eliminates data that is not essential to monitoring your distributed applications.

Figure 4-1 shows a number of observers monitoring endpoints conveying messages from a client to a service (EP5). Note endpoint EP1 and endpoint EP4 at the edge of the message flow. Note also the dotted line which indicates the relaying of context information. If you choose to monitor all endpoints, all the endpoints shown in the figure will be discovered and monitored by Business Transaction Management.

Figure 4-1 Modelling Intermediate Endpoints

Figure is described in text.

Figure 4-2 shows you how message flow is modeled if you choose to restrict the number of endpoints monitored. In this case, only the client, EP, and EP5 are discovered and monitored. Context information is still conveyed from the client to the final recipient, EP5.

Figure 4-2 Limiting Endpoint Discovery

Figure is described in text.

The observer communication policy gives you the option of controlling the monitoring of intermediate endpoints for SOA, OSB, and EJB probes. Options for monitoring different technologies vary slightly. For example, in monitoring EJBs, you have the following options: you can choose to model the edge of flow, which models only the first local EJB in a local request flow; you can choose to model all, which models all local EJBs; and you have the option to model none (no local EJBs). How you model local EJBs has no effect on the modeling and monitoring of remote EJBs, which are always monitored. For additional information about the observer communication policy, see Section 12.1.2, "Configuring the Observer and Monitor," especially Section 12.1.2.11, "Advanced Settings Field Reference," which describes the options you use to control the monitoring of intermediate endpoints.

4.1.4 Modeling JDBC Calls

Very large transactions or high JDBC volume might strain BTM resources when the JDBC probe is enabled and instance logging is turned on. It is also possible that calling one operation can result in a large number of calls to the database. For example, one Fusion Application operation can translate into hundreds of SQL statements. To reduce this overhead and free up resources, you can elect to have Business Transaction Management record a summary of these calls rather than noting each one individually.

If you decide to use JDBC summary mode but also want to investigate individual calls, you can use data base management tools to do so. The main idea behind the JDBC summary option is to make BTM performance more efficient while, at the same time, allowing you to get information about slow or faulty sql statements.

Settings in the observer's communication policy determine whether JDBC summary mode is enabled. This section describes the information displayed by BTM when JDBC summary is enabled. For more information about the communication policy, see Section 12.1.2.11, "Advanced Settings Field Reference.".

When JDBC summary is enabled, JDBC calls are represented as shown in the figure below.

Figure 4-3 JDBC Call in Summary Mode

Figure is explained in text.

The measurements given for the JDBC call specify the average time for the call and the number of calls. In the case illustrated below, 22 calls have been made, averaging 20 ms each. In summary mode, the operation name is always execute. (When JDBC summary is disabled, the executePrepStmt, executePrepStmtBatch, executeQuery, and executeBatch statements are all individually discovered.)

4.1.4.1 Understanding the Display of JDBC Summary Data

With JDBC summary enabled, the transaction instance and message log display will include two additional columns showing the summary count and fault count for each calling service. (In the observer communication policy you can specify a time-out value. If SQL call times exceed this value, BTM will send an extra time-out summary message.)

The next figure shows the additional information shown when JDBC summary is enabled. Note the way response time is reported for the execute statement (only part of the display is shown). Any row containing summary information will be marked with a sigma symbol.

Figure 4-4 Instance Inspector: New Columns for JDBC Summary

Figure is described in text.

Two additional built-in properties are defined for the request phase of a message to support JDBC summary mode: aggregateCount and aggregateFaultCount.You can use these properties in searches. For example, you could look for an execute message whose aggregate fault count is greater than 100.

When JDBC summary is enabled, BTM records all JDBC operations individually, but when logging message content, the information is sent in one abridged summary observation per caller, which includes payload information only for the number of slowest SQL statements and faults you specified in the observer communication policy settings. (For information on setting options that control logging of summary content, see Section 12.1.2.11, "Advanced Settings Field Reference.")

When you display message content for a summary observation, the xml listing, ExecuteSummaryContent, will look like the following. The main sections of the output are shown in bold type in this text and described following the example.

<ExecuteSummaryContent>
    <ExecuteCount>52</ExecuteCount>
    <FaultCount>2</FaultCount>
    <SumResponseTime>77</SumResponseTime>
    <AvgResponseTime>1.54</AvgResponseTime>
    <SummaryStartTime>1376876999364</SummaryStartTime>
    <SummaryEndTime>1376877000390</SummaryEndTime>
    <Caller>
        <Service>LogService</Service>
        <Operation>haveFaults</Operation>
    </Caller>
    <CapturedFaults>
        <Fault>
            <ArriveTime>1376877000364</ArriveTime>
            <Content> <![CDATA[select * from noneexisttable]]> </Content>
            <FaultContent> <![CDATA[ORA-00942: table or view does not exit]]> </FaultContent> 
        </Fault>
        <Fault>
            <ArriveTime>1376877000386</ArriveTime>
            <Content> <![CDATA[select * from noneexisttable]]> </Content>
            <FaultContent> <![CDATA[ORA-00942: table or view does not exist]]> </FaultContent>
        </Fault>
    </CapturedFaults>
<TopNSlowestMessages>
        <TopNMessage>
            <Content> <![CDATA[INSERT INTO calculationlog
                       (leftoperator,rightoperator,operatortype, result,logdate)
                       VALUES(?,?,?,?,systimestamp)]]> </Content>
            <ResponseTime>4</ResponseTime>
            <ArriveTime>1376876999360</ArriveTime>
            <ExecuteCount>10</ExecuteCount>
            <AverageTime>2.30</AverageTime>
            <MinTime>2</MinTime>
        </TopNMessage>
        <TopNMessage>
            <Content> <![CDATA[DELETE FROM calculationlog where id=?]]> </Content>
            <ResponseTime>4</ResponseTime>
            <ArriveTime>1376877000150</ArriveTime>            
            <ExecuteCount>10</ExecuteCount>
            <AverageTime>1.60</AverageTime>
            <MinTime>1</MinTime>
        </TopNMessage>
        <TopNMessage>
                <Content> <![CDATA[UPDATE calculationlog SET leftOperator = ?,
                 rightOperator = ?, operatorType = ?, result = ?, 
                 logDate = systimestamp where id = ?]]> </Content>
                <ResponseTime>3</ResponseTime>
                <ArriveTime>1376876999552</ArriveTime>
                <ExecuteCount>10</ExecuteCount>
                <AverageTime>1.80</AverageTime>
                <MinTime>1</MinTime>
        </TopNMessage>
    </TopNSlowestMessages>
</ExecuteSummaryContent>

The section titled ExecuteSummaryContent shows the following information for summary observations:

  • ExecuteCount: the total JDBC calls made, including exceptions

  • FaultCount: count of all JDBC exceptions that occurred in this summary

  • SumResponseTime: The sum of all SQL statements' response time

  • AvgResponseTime: The average of response times across the summed JDBC call

  • SummaryStartTime: See Note below.

  • SummaryEndTime: See Note below.

  • The calling service, and operation

In the communication policy, you can also specify the number of exceptions you want captured. For each such exception or fault, the following information is shown in the section titled CapturedFaults:

  • ArriveTime: the time when the exception arrived. See Note below.

  • Content: The SQL statement where the exception occurred

  • FaultContent: The full text of the SQL exception content

In addition, the section TopNSlowestMessages shows the following information for each of the N slowest SQL statements. (You specify a value for N using the communication policy.)

  • Content: SQL statement name (but not the parameters passed to these)

  • ResponseTime: the execution time in microseconds for this SQL statement

  • ArriveTime: Start time. See Note below.

  • ExecuteCount: how many times this SQL statement was called

  • AverageTime: the average time for all SQL statements recorded

  • MinTime: the minimum time for all SQL statements recorded

Note:

Times for ArriveTime, SummaryStartTime, and SummaryEndTime are given using a UNIX timestamp (based on seconds since 1/1/1970). To convert this value to a readable date and time, look for a conversion tool on the Internet by searching for "UNIX time conversion."

4.1.4.2 Updating Transaction Definitions After Changing Summary Options

If you have already created a transaction and you decide to change the setting of JDBC summary, you will need to run more traffic and then update your transaction definition. This is because, depending on your JDBC summary setting, BTM will discover the JDBC service operations for SQL execution under different names.

  • When JDBC summary is disabled, the executePrepStmt, executePrepStmtBatch, executeQuery, and executeBatch statements will all be individually discovered

  • When JDBC summary is enabled, the executePrepStmt, executePrepStmtBatch, executeQuery, and executeBatch statements will all be combined into a single execute operation

If you change the JDBC summary setting after creating a transaction definition, please do the following:

  1. Run traffic through the JDBC service again to discover the new operations.

  2. Edit the transactions that use JDBC services by removing the old operations and including the newly discovered ones.

If you don't update your transaction definition, BTM will be unable to recognize the newly discovered JDBC service operations as being part of the transaction, and it will not be able to record measurements for traffic to that service.

4.1.5 Registering a Service Manually

There are cases where Business Transaction Management cannot discover SOA-type components directly: for example, the service resides in a container that cannot be observed or the service resides in a container where no observer has been installed. In such cases, it might still be able to discover the object if you manually register the service.

While it is possible to discover services in this way, it is not usually possible to monitor their performance without the services being directly observed. For more information, see Section 4.5, "Manually Registering a Service."

4.2 Viewing Discovered Containers

Discovery displays information about containers hosting Business Transaction Management system services and hosting observed components. This section describes the information available about a container. It also explains how you edit container profile information and how you unregister a container.

4.2.1 Viewing Container Information

You can view container information from the Explorer > Container view or from the Maps> Container Map view.

To view a container map:

  1. Select Maps >Container Map in the Navigator.

  2. Float-over help specifies the host name for each container. Pass your cursor over the containers to display the help.

  3. Opening the Tabs area and clicking on a container icon displays the Profile and Services tabs for the container. See the next section for a description of the tab contents.

4.2.2 Viewing Summary and Detail Information

To view summary information about discovered containers and their contents:

  1. Select the Explorer > Containers view in the Navigator. Information about discovered containers is shown in the main area. By default Business Transaction Management shows information about all known containers. Use the Filter control to filter the displayed information about containers.

  2. Click the plus icon by the container name to display the contents of the container. This allows you to view the application components hosted in the selected container.

  3. Click the plus icon by the component name to view the operations that make up that component. The operations are listed in a tree view under the container.

To view detail information about a discovered container:

  1. Select the container in the main area.

  2. Double click the container name. Two tabs are shown in the details pane: Profile and Services.

  3. The Profile tab displays information about the container and the deployed observer; the table below describes the fields of the Profile tab. User-defined fields can be filled in by editing profile information.

  4. The Services tab displays information about the services running in this container.

Field Description
Notes User-defined field. Specify any information that helps you understand the use or contents of the container
Base address The http-based address (entry point) for this container
Aliases All the IP addresses by which the container might be known to the Sphere. This might include VPN adapter address, user-defined aliases, or other addresses Business Transaction Management discovers by observing message traffic to the container. This information is useful in investigating improper setup of the container.
Container Type The container type and version number.
OS The operating system and version
Host The host name where the server is running.
Identifier Unique identifier for this object in Business Transaction Management.
Administration UI Console User-defined field: URL of administrative console for the container. You can use this link to launch the console Although Business Transaction Management supplies a value for this address, it might not be accurate and should certainly be changed if the console is moved. You can change this value by editing the container profile.
Monitoring Details Information about the observer deployed in the specified container and dates for last discovery, registration, synchronization with the Sphere, and version.
Contact information User-defined field to provide contact information for the server administrator or other support personnel.
Routing details Information about any load balancers observed routing messages to the container

4.2.3 Editing Container Profile Information

To edit container profile information.

  1. Select the container in the container map area or in the main area.

  2. Select the Modify > Edit Profile for <container> item.

  3. Change any of the editable fields (shown in yellow).

  4. Click Apply.

4.2.4 Unregistering a Container

Unregistering a container removes the container and all discovered serves deployed in the container from the sphere registry. You might need to do this after completing one of the following tasks:

  • Moved a container to another sphere.

  • Uninstalled the Business Transaction Management observer from a container.

  • Uninstalled or physically removed the container from your system.

You should unregister the container only after you have completed one of these tasks. Otherwise, an unregistered container will register itself upon startup if nothing has changed.

  1. Select the container in the Maps > Container Map view or in the Explorer > Container view.

  2. Select DeleteContainerNameRegistration from the Modify menu.

  3. Click Delete.

4.3 Viewing Discovered Services

Business Transaction Management displays information about discovered services, service endpoints, routers that distribute message traffic to endpoints, and service operations.

  • services refer to logical services

  • endpoints refer to service instances and routers

  • operations are invoked by request and response messages that one service sends to another

When you start Business Transaction Management, no services are shown. For services to be discovered:

  • Services must be deployed to application servers where observers have been installed and the appropriate probes have been activated.

  • Traffic must flow from one service to another service (unless you manually register a service).

Once services are discovered, you can access information about them from the Services To Endpoints and Services To Operations Navigator views. You can view services dependencies in the Maps > Service Map view.

4.3.1 Service Types

Business Transaction Management assigns a type to a service based on the type of the first endpoint discovered for the service. Service types include Web Application, Web Service, and Database. (A web application is a component that interacts with the user via HTML pages (screens)). Note that a service might have multiple endpoints of different types and be discovered by different observers. For example a web service might have multiple endpoints on different containers implemented using different technologies: JAX-RPC, JAX-WS, WCF, and so on.

4.3.2 Deployment Topologies and Service Information

The service information displayed varies with the topology of your deployment. If you have only one instance of a service running, one endpoint for that service is shown. If you have several instances of a service running, several endpoints are shown for that service.

There are a variety of reasons why you might discover and have to monitor several instances of a service:

  • The service is replicated for performance or failover. In this case all the replicated instances are shown as the service's endpoints. The router distributing traffic to those instances is also shown; the router name is the endpoint name with the suffix Router.

  • The service is deployed in a container with both secured (HTTPS) and unsecured (HTTP) ports. One endpoint will be shown for each port only if traffic flows to that port.

  • A WSDL includes different bindings for a service, each binding defining a different set of operations that can be implemented by different endpoints. This case is rare, but Business Transaction Management will recognize it and discover the endpoints.

4.3.3 How the Existence of Routers is Inferred

It might take a while to determine that a router is being used to re-direct traffic. Business Transaction Management uses the Host headers in HTTP traffic to detect when messages were originally sent to a different address than the container where they were observed, and connects the caller to the recipient in the dependency graph.

When the Host header contains a different host name but the same port, Business Transaction Management will initially add aliases for the container and its endpoints. When the Host header contains a different port than the container is actually listening on, or the same Host header is observed in traffic sent to two or more containers, Business Transaction Management infers the existence of a hardware load balancer between the caller and the service, and will add router endpoints to the sphere model as needed to connect the caller and its target endpoints in the dependency graph.

4.3.4 Viewing Services

You can view service using either the Services To Endpoints view or the Services to Operations view from the Navigator.

To view Services To Endpoints, select the view from the Navigator. Business Transaction Management displays information in the main area of the console. The following table describes the contents of this view.

The Services To Endpoints view is useful in that it shows endpoint replicates. Replicates are distinguished by their address, shown in the main area. They also have distinct definitional and performance information, as shown in the Tab section of this view.

Column name Description
Name The Name of the service. Expand the top logical service name to show the endpoints it contains. Expand an endpoint to view its operations.
Up/Down Arrow Green arrow specifies that the service, endpoint, or operation is running; Red arrow specifies that it's down. Yellow indicates that a service contains endpoints; some of which are running and some of which are down.
Address Address of the service's container. Replicate endpoints will have different addresses.
Type The type of the service. This is based on the type of the first service endpoint discovered.
Container type The type and version of the service container.

To view detailed information about each service, endpoint, or operation double click the desired element to display detailed information in the Tab area, which includes the following data:

Tab Description
Summary Shows a summary of performance measurements for the object selected in the main pane.
Analysis Shows performance information across a specified period of time.
Alerts Shows alerts for the selected object.
Message Log Shows available messages if message logging is enabled for a given operation.
SLA Compliance Shows the compliance of the selected object with service level agreements defined for the given object.
Profile Shows definition of selected object. You can edit some of this information by selecting Modify > Edit Profile for object name.
Dependency Shows the dependencies between the selected object and related objects.
Policies Lists the policies applied to the currently selected object.
Downtimes Specifies the scheduled downtimes for the selected object.
Properties Specifies the properties defined for the selected object. Use the Edit button to modify, duplicate, or delete these properties.

To view Services-To-Operations, select it from the Navigator. Business Transaction Management. The type of information displayed is the same as for the Services-to-Endpoints view. Tab information is also the same.

4.4 Looking at Dependencies

In addition to discovering business components, Business Transaction Management can discover how components relate or depend on one another by observing message traffic as it flows from one component to the next. Dependency information provides an accurate picture of how your composite application is really behaving. It might alert you to the fact that certain components are not being called, and it provides a basis for defining business transactions.

You can view dependencies between services, endpoints, (service instances), or operations. Each dependency map provides information appropriate to the element selected.

You can also delete dependencies if dependency graphs show out-of-date dependencies.

4.4.1 Showing Related Elements

No matter what type of dependency it is showing, a dependency diagram is rooted in the selected object and displays all the links that lead out from and into that starting point. Anything that is not directly upstream or downstream of the root object is not shown. To display these additional elements, click on the wrench icon to display the Layout and Show-Related controls.

The default value for Show Related is None, meaning that only elements directly linked to the root object are shown.

  1. Select One to show the next level of objects indirectly linked to the root object, or select All to show all objects linked to the root object.

  2. Click OK.

4.4.2 Service Dependencies

To view service dependencies

  1. Select the Services To Endpoints view or the Services to Operations view in the Navigator.

  2. Double click on the service of interest to open the tab area if it is not already open. If it is open, just select the service of interest.

  3. Select the Dependency tab. Business Transaction Management displays the dependencies between the selected service and the other services with which it interacts. Arrows display traffic flow; their thickness indicates relative throughput size.

  4. You can move the cursor over the services displayed to have Business Transaction Management display their component type.

You can also display service dependencies by choosing the Maps > Service Map view from the Navigator.

4.4.3 Endpoint Dependencies

To view endpoint dependencies:

  1. Select the Services To Endpoints view in the Navigator.

  2. Expand the service of interest to display its corresponding endpoints. A (logical) service might have several corresponding endpoints if the service has been replicated or if different endpoints are used for secure/unsecure communication.

  3. Double click on the endpoint of interest to open the Tab area. If it is already open, just select the endpoint of interest.

  4. Select the Dependency tab. Business Transaction Management displays the dependencies between the selected endpoint and the other endpoints with which it interacts. Arrows display the direction of traffic flow and relative throughput. For each endpoint, the host name and port for the container where the endpoint resides are also displayed. The means by which the endpoint is discovered is shown in parenthesis; the following table describes the possible types.

Means of discovery Meaning
observer The endpoint was discovered by an observer
router The endpoint was discovered by a router. (The existence of a hardware router was inferred based on discrepancies between the HTTP Host header and the physical address of the observed container(s).)
registered The endpoint was manually registered
DTA The existence of the endpoint was inferred based on outbound traffic addressed to it from an observed endpoint.

As you pass the cursor over individual endpoints, Business Transaction Management displays the endpoint name, the container's host and port, and the service and component type of which the endpoint is an instance. Core measurements are also given.

4.4.4 Operation Dependencies

To view dependencies between operations:

  1. Select the Services to Operations view in the Navigator. You can view dependencies between logical or physical operations. Logical operations are listed immediately under the service; physical operations are listed under logical operations. The name of a physical operation takes the form

    endpointName on containerName

    For example: checkCredit.CreditServiceSOAP on uitest20:7011

  2. Double click the operation of interest to open the tab area. If it is already open, select the desired operation.

  3. Click the Dependency tab if it is not already selected.

  4. The call chain containing the operation is shown.

  5. Pass the cursor over the operation to display additional float-over help.

4.4.5 Deleting Dependencies

You might need to delete all dependencies if your application has changed and the dependency graph does not reflect these changes. Dependency data does not age out, so in those cases where the graph includes obsolete data, you might want to clear all dependencies and regenerate the graph by running more traffic.

To delete dependencies:

  1. Select Delete Dependencies from the Admin menu

  2. Click Delete.

  3. To regenerate dependencies, run more traffic.

4.5 Manually Registering a Service

Normally, if a service is not under direct observation, it cannot be discovered or monitored. But you can manually register a service, display it, and obtain measurements for calls going out to it.

You should register a service if you will have outgoing calls to the service but cannot install an observer on the service's container. Once you register the service, the system will be able to record measurements and log messages that are observed on the client side of the message exchange.

After registering the service, you might want to use the registerExternalContainer command to group its endpoints into an external container. Otherwise, by default, manually registered endpoints are allocated to the System container, and are displayed under the Unassigned Endpoints node.

To register a service:

  1. Choose Admin > Register > Service WSDL from the main menu.

  2. Specify the URL of the service's WSDL and click Next.

  3. Specify the name by which the service will be registered with the sphere. By default, the name is extracted from the WSDL definition; you can use an alternate name if you like.

  4. Optionally, specify a version for the service.

  5. Click OK.

The service should now be listed in the summary area of the Services to Endpoints or Services to Operations view.

4.6 Deleting Discovered Objects and Starting Over

Creating a useful discovery configuration can be an iterative process, particularly in the early stages of using Business Transaction Management. You might find that default settings for enabling probes are turning up too much information, or that changing your deployment or the observer-monitor topology results in redundant or erroneous information. To spare you the need to reinstall the system or to manually remove all observed entities and related artifacts, Business Transaction Management provides the deleteAll command. This command deletes objects already discovered along with related artifacts such as transactions, properties, registered services, devices, and containers.

Use this command judiciously to avoid unwanted loss of data, which includes historical data related to observed objects. The command is most appropriate when you start working with Business Transaction Management and are fine tuning your discovery scheme. It should never be used in a production environment.

See Section 10.11, "deleteAll" for more information.