This section describes a basic workflow for working with Business Transaction Management. It serves as an introduction to the major sections of the online help. The workflow includes the following steps:
The Business Transaction Management discovery process is entirely traffic-based. If messages are not flowing through the observed endpoints, the system cannot discover any application components nor can it discover the dependencies between these components. So, the first step in working with Business Transaction Management is to run traffic and allow a little time to elapse to give the system a chance to observe message traffic and to build a picture of your deployed system.
If this is the first time you are using Business Transaction Management, the next thing you will want to do is to look at the Management Console and get a sense of its basic parts and how it is organized. If you have run some traffic, you will be able to see services and their dependencies when you open the Management Console. Take a few minutes to get acquainted with the basic workings of the console:
"Getting to Know the Management Console" describes the parts and organization of the Management Console
"Viewing Data" provides a more detailed explanation of how you use the Management Console to view different types of data. It introduces the basic elements used to present performance data: maps, charts, tabular views, and dashboards. You might want to look at this now, or refer to it later as you view and interpret performance information.
After you run traffic, Business Transaction Management immediately starts gathering data to give you a complete picture of your environment and to help you understand the flow of work through it. Identifying the components that make up a distributed application and understanding how these components relate to one another allows you to answer two questions: "What do I have?" and "What is it doing?
Business Transaction Management uses tabular and graphical views to display topological and performance information. The following screen shot illustrates how endpoint dependencies, status, and performance data are represented in one graphical view.
When you first look at your environment, you might want to know about the location and status of the containers running the observed components. Next, you might want to view services to see that all the services you are interested in observing have been discovered. You can then look at how services are interacting with one another and how traffic is distributed among them in the case of replicated services.
It might now be necessary for you to make adjustments to the picture the system has constructed by registering services that could not be found, by resolving replication or duplication issues, by addressing versioning problems, and so on.
Having formed an accurate and complete picture of the services operating in your environment, you can now turn to look at operational data. By default, the system displays data for throughput, traffic, faults, average response time, maximum response time, and uptime. This should allow you to identify bottlenecks, faulty components, slow components, and unusually light or heavy traffic.
You can narrow the number of services displayed by using filters. You might also want to customize your view by adding instruments to the core measurements displayed in tabular views.
Using this information, you could decide to change the topology of your deployment: replicating some services, adjusting the processing capacity of others, and taking a closer look at faulty components.
A transaction is a sequence of operations that you want to monitor as a single unit. Business Transaction Management focuses on the monitoring of transactions to help you identify and resolve issues related to performance, to profiling usage, and to identifying the cause of failing components in a business process.
Based on the dependencies revealed by discovery, you can define a transaction to include services whose interactions interest you. You might exclude services that are not under your control, or you might decide to include ancillary services that you believe have an appreciable effect on performance. Defining a transaction is simple: you identify the beginning and end operation of a sequence of operations. You can then enable additional features that allow you to look at your transaction from different perspectives.
By default Business Transaction Management simply monitors the basic performance of a transaction. You can modify the default transaction definition to enable monitoring features that provide exactly the level of detail you need about performance and usage. For example you can add features that allow you to do the following:
Segment performance information by host address or by usage. Usage might be organized by user, by supplier, or by any criteria that helps you get useful performance information.
Log transaction instances
Log message content, which then allows you to search logged messages for specific information. For example, "which message had an order for 15,000 books?"
In addition to the performance information that is routinely gathered and that you can view at all times, you can have Business Transaction Management alert you in the following special cases:
You define a service level agreement based on some fixed value or a historical baseline, and you ask to be notified whenever performance crosses defined thresholds. For example, you want to know when throughput for the transaction dips below 100 requests in the last ten minutes.
You define a condition that tests for message content or for a certain fault, and you ask to be notified if this condition is met. For example, you ask to be notified when the value of a property associated with quantity ordered is greater than 1,000.
You define a condition that tests for the arrival of a message within a certain period, and you ask to be notified if the message does not arrive. You might use this to alert you about transactions that do not complete.
As you can see, Business Transaction Management offers a variety of options in monitoring your transactions. Which of these monitoring techniques you use depends on the questions you want to answer and on the issues you're trying to resolve. These questions might change as you proceed from development, to testing, to production. By creating a system that allows you to selectively enable and disable monitoring features, you can be sure to get exactly the information you need while minimizing the management system's performance costs.
Finally, as you learn to work with Business Transaction Management and identify processes that you want to archive and execute at will, particularly administrative tasks, you might want to create a script using the command line interface. You might use such scripts to do the following:
Configure your system
Resolve discovery problems
Resolve replication problems