You define transactions on the logical level by specifying which operations participate in the transaction. Business Transaction Management monitors transactions by looking at individual endpoints, and it displays the level of information you require. The level of detail it provides ranges from the minimum of aggregate performance information to the maximum of message content logging. Using Business Transaction Management to monitor transactions is an iterative process: initially you want to look at the greatest possible number of endpoints to get an overall feel for service usage and for potential trouble spots. As you identify these, you want to look at a narrower set of elements but in greater detail. By using this approach, you can get exactly the information you need without straining system resources.
You might want to define and monitor transactions in order to do the following:
Assess the performance of business transactions. Business Transaction Management provides information about which transactions are completing, which are failing, and which get stuck. It also tells you how long it takes a transaction to complete as a whole and what part of that duration is used by each operation in the transaction.
Find transaction instances based on message content.
Troubleshoot problems with transactions: analyze bottlenecks and diagnose the reason for bad performance or failed transactions.
Users playing different roles might use information about transaction performance as follows:
Operations personnel need to determine which transactions are impacted by server or component downtime. This helps them prioritize their work and schedule maintenance.
Developers need to understand which transactions are impacted by implementation changes to components.
A business application owner needs to monitor charts that depict the performance and throughput of transactions.
You define transactions by using the discovery process to identify operation flows. Based on the dependencies revealed by discovery, you can define a transaction to include services whose interactions interest you. You can then modify the default transaction definition to enable monitoring features that provide exactly the level of detail needed about performance and usage. Features include segmenting information by user or host address, instance and property logging, and message content logging.
This section describes this iterative process of defining transactions and the level of detail that is made available as you enable each feature. It includes the following sections:
A transaction is defined by the following:
A primary operation flow. This is specified by providing the start message, which triggers the flow. The start message is typically the request message for the initial operation of the flow.
Additional operation flows if needed, which must be manually correlated to the primary flow.
The ending message of the transaction. By default this is the response message from the initial operation of the primary operation flow. However, you can change it to model more complex transactions.
You can alter the transaction's view of the operation flows by deleting one or more operations from a flow.
Business Transaction Management allows you to include the same operation in multiple transactions; the only limitation is that the same operation cannot be the starting operation of more than one transaction. If you do include an operation in multiple transactions, Business Transaction Management is able to keep accurate aggregate measurements for each transaction's overall response time, counting the invocation of the shared operation appropriately as it is called by each of its owning transactions. Business Transaction Management is also able to handle situations where services are replicated, accurately collecting performance information as one replicate or another is used in a failover or load balancing architecture.
A transaction executes many times in a given period; Business Transaction Management tracks the flow of messages included in the transaction and can map these to particular transaction instances.
A transaction instance starts when an instance of the primary operation flow is started.
A transaction instance ends when the system sees an instance of the ending message that correlates to the instance's starting message.
In addition to the operation flows it contains, a transaction is also defined by settings that specify the following information:
The scope of the transaction: how long you expect a single transaction to run. Business Transaction Management uses this value to figure out when to stop looking for messages for a given transaction instance
How long to retain logged messages that you might want to assemble so that you can view a particular instance of a transaction
Whether transaction monitoring is enabled and whether free text search is enabled
Whether segmentation, instance logging, and message content logging are enabled
In order to allow the user to extract as much information from a message without logging the content of every message, Business Transaction Management offers the use of properties, which are associated with transaction operations. Properties can be associated with parts of the message header or message payload. You can use them in the following ways:
Once you define the start and end operation of a transaction, by default Business Transaction Management determines the intervening operations based on traffic flow, and it creates message fingerprints to link together (correlate) the operations of a transaction instance. You can also define manual keys as an alternate means of correlating transaction messages.
You will need to manually correlate operations in the following cases:
To add a secondary operation flow to the transaction. This might be necessary in the case of asynchronous systems like JMS, or desirable if you want to connect two operation flows that share underlying data but are not causally connected. For example, you have one flow defined by an order entry, and another flow defined by the fulfillment of the order. The same order is involved in two otherwise disjoint processes.
To define a transaction whose end message is not the end message of the operation that starts the flow.
To define a missing message condition
See "Correlating Messages in a Transaction Using Manual Keys" for additional information on what you need to correlate in each of these cases.
A single transaction definition can contain operations that are correlated automatically and other operations that are correlated manually.
When you select an operation and choose to create a transaction, Business Transaction Management displays a Create Transaction Definition tool with default values already filled in. According to this default definition:
The start message of the transaction is the request message of the operation you selected; the ending message is the response message of that operation.
Transaction monitoring is enabled. That is, Business Transaction Management will collect data that enables it to calculate and display the following measurements: the number of started and completed transactions, throughput, average response time, maximum response time, and faults.
Messages in the transaction are correlated using message fingerprints (calculated by Business Transaction Management).
Segmentation, instance and property logging, and message content logging are disabled.
The default configuration is sufficient to give you a first broad look at your transaction. It can help you identify slow links, faulty services, and unexpected traffic spikes. It can also show you if overall transaction performance is degrading or not completing on time. You can also create fixed value and baselines service level agreements (SLA's) based on the measurements collected for the transaction.
You can customize the default transaction definition in the following ways:
Change the operations that are included in a transaction and change the end operation. You might want to do this because the transaction contains one way operations, because you want to limit the transaction to fewer operations than the overall request flow, or because you want to add services in those cases where services are rarely invoked and therefore cannot be found within the discovery period.
Correlate messages using message keys.
Turn on features that will give you more detailed information about the transaction.
The following subsections describe the features you can add to your transaction definition.
The following are the features you can add to provide a more detailed picture of transaction performance and message content.
You can segment transaction measurements based on host address and by individual consumer. Consumer segmentation might be useful if you have usage contracts with specific customers or if you want to identify customers that make especially heavy or light use of your services.
Segmentation by host address can help you understand the distribution of requests in your network. You can discover whether some network segments or hosts are bearing a disproportionate load of the traffic, or that problematic transactions are all executing on a particular host.
Enabling instance logging allows you to see a list of transaction instances captured in a given time period. You can assemble and inspect a given instance, view any property values for that instance, and create conditions based on these property values.
You can also search on the logged properties and find the related transaction instance.
The features you enable for a transaction record information for the entire transaction and for select operations. In addition to this continual monitoring, whose results you must analyze to discover performance issues, you can also configure Business Transaction Management to alert you about special situations by using conditions and service level agreements.
Service level agreements define standards of performance for your transactions based on aggregate measurements. Business Transaction Management then monitors deviations from those standards, and when deviations occur, an alert is issued and displayed in the Management Console.
Conditions can alert you when an expected message does not arrive, when a specified message property value is encountered, or when a fault occurs. They are tools to help you detect issues in specific transaction instances. When the condition is triggered and satisfied, Business Transaction Management assembles the corresponding transaction instance, allowing you to view its content and perform whatever analysis is needed for troubleshooting or other performance evaluation.