One of the goals of service-oriented architectures is to design application infrastructure that more closely matches business processes. These business processes often involve exchanges with multiple systems. For example, placing an order for a product can involve exchanges with an inventory system as well as an accounting system. When service consumers and producers are communicating with each other in a coordinated fashion to accomplish a business process, it is called a transaction.
Transactions are central to many businesses that have implemented service-oriented architectures for their information systems. Monitoring the performance and metering the usage of transactions based on Web service technology can be a challenge. This can be further complicated by the evolving technologies and standards used by vendors to implement transactions in the service-oriented infrastructure. JaxView provides operations management the capability of monitoring SOAP transactions.
A transaction instance is an instance of the sequence of messages required to complete the steps of a business process. The loosely-coupled nature of Web services presents a challenge to controlling and coordinating the steps of transactions. The details of how message coordination is implemented can vary. The transaction monitor supports WS-Transaction and WS-Coordination protocols. In general, the messages are associated with each other by way of context data that is included as part of the message payload. JaxView uses this context to identify transaction instances for monitoring and reporting purposes. There may also be transaction-specific notification content within the messages. This notification content is often used to communicate success or failure states for transaction steps. JaxView can be configured to monitor message for select notification content and use this in the event threshold logic for the monitor.
Transaction monitoring is unique in JaxView in that transaction monitor object are not displayed in the Services tab. You use the Transactions tab to work with transaction monitoring in JaxView. The Transactions tab is divided in to two main sections. On the left side is the Transactions object tree that you use to add, edit and navigate to Transaction definitions. On the right is a display panel you use to edit Transaction definitions or view transaction results as recorded by JaxView. The following sections describe how you work with transactions in JaxView.
The Transactions object tree is a hierarchy of transaction definition objects defined in JaxView.
The contents of the right side display panel of the Transactions page is determined by the context selected in the left Transactions object tree. Each object node in the left Transactions object tree includes an action menu that you access by selecting the node and then use the right mouse click to display the node action menu. The following table describes the nodes in the tree and their associated actions:
|
Object Node |
Action Menu Item |
Description |
|---|---|---|
|
Transactions Root node |
Add New Transaction |
Add a new Transaction definition to the Transactions object tree |
|
Transaction definition node |
Add Rule |
Add a new rule definition to the Rules object tree |
|
Assign Rule |
Assign a rule definition to the selected Transaction definition |
|
|
Edit Transaction |
Edit the selected Transaction definition |
|
|
Delete |
Delete the selected Transaction definition from the Transactions object tree |
|
|
Enable |
Enable the selected Transaction definition (if it has been previously disabled) |
|
|
Disable |
Disable the selected Transaction definition. |
Clicking on a node in the Transactions object tree displays the View Transaction table for the node content in the right panel. This table is the history of the transaction as monitored by JaxView . The following figure is an example of an View Transaction table displayed in the right side panel when either the Transaction Root node or a specific transaction definition node is selected.
The View Transaction tables include seven columns of data. The following describes the table contents.
Before you can use a transaction monitor, you must add a Service definition for each of the services that provide operations for the transaction to the Services tab in JaxView. You then add the SOAP transaction monitor in the Transactions object tree. You use the Transactions object tree action menu to add and edit monitor definitions.
The Add Transaction form for the SOAP Transaction type is divided into four sub panels. You use these panels to edit the transaction definition. The following figure shows an example of the Edit Transaction panel showing the sub panels in their default collapsed state.
The first sub panel is the Transaction Steps section. This section also contains sub panels. These are used to define the steps of the transactions and define expressions for extracting information from the messages exchanged for each step. You add all the operations for the transaction in the Transaction Steps section, identifying the “initial” and "end" operations. When the end operation is called then the transaction is considered to be completed.
Transactions are coordinated by way of context data that is exchanged as part of the messages of the transaction. This is how one transaction is distinguished from another. In order to enable transaction monitoring, JaxView must know how to extract the context data for messages that are part of a transaction.
Web service transaction context can be handled in several ways. In cases where the service operations are as provided within the same organization, the transaction context may be the same for each step of the transaction. In the case that one or more operations are services provided by a partner or other organization, the context may change from one step of the operation to another. Understanding what context data is exchanged and how to extract this data from request and response messages is essential for monitoring transactions with JaxView.
Reporting the status of a transaction is more complex than reporting the status of a single Web service exchange. With a call to a single Web service operation, the status can be set according to a single criteria. For example, if the call to the Web service operation is being monitored for response time, the status is set based on the time it took to respond. If the operation is being monitored for content, the status is set on whether the content matched the criteria given.
With the need for coordination between Web service producers and consumers, transactions need to communicate more information about the progress of the transaction. This is to account for the possibility that the transaction request can not be completed due to a violation of business logic (for example, inventory is not available) or a failure of one of the systems required to complete the transaction. Transaction status in JaxView can be set to report an error on the following criteria:
Error condition threshold for the individual operations in the transaction. These can be Step response time for an individual operation or total transaction response time for completion of the transaction
Notification strings returned by the operations in response messages, such as “abort” or “rollback”
Fault messages in the responses returned by any operations involved in the transaction
The error condition thresholds and notification strings are configuration properties that are controlled in the transaction definition. The following figure illustrates how these two properties are configured in a transaction step.
Creating a new SOAP Transaction Definition in JaxView requires the configuration of multiple transaction steps. The number of transaction steps will depend on the business process and how it is implemented in the SOA environment.
Note: Each service endpoint and operation used in the business logic of the transaction must be added as a separate object to the Services object tree in JaxView before you can create a transaction that uses those service producers and operations.
For each Web service operation called as part of the transaction, you will want to define a step within the JaxView transaction definition. Each of the steps has a step property that gives an indication of the sequence the step holds in the transaction. The step properties used in JaxView are:
The following describes the steps you use to configure a Generic SOAP Transaction monitor definition.
To add a new SOAP Transaction definition
Select the Transactions tab from the Main View navigation menu
Click on the Transactions root node in the left side object tree menu
Right-click the mouse to display the action menu for the node and select Add New Transactions. The Add Transactions page is displayed in the right panel
Select the Generic SOAP Transaction monitor type from the Add Transactions list by clicking on the monitor type name. The Add Transaction configuration page is displayed in the right panel.
Configure the steps for the transaction using the numbered Step sub panels in the Transaction Steps section of the Add Transaction form. Click the up or down arrow icon on the sub panel title bar to reveal the configuration panel for that step. Use the following steps to add steps to the transaction:
Use the drop down menu for the Operation Name field to select the Web service operation name for this step in the transaction. This will be the name of the operation as it appears in the JaxView Services object tree.
Use the drop down menu for the Step Property field to select the property for this step. If this is the first step of the transaction, select Initial. If it is the last step in the transaction, select End. For other steps, select Participant.
If the context meta data is unique for this step, enter one or more XPath expressions or regular expressions to match on the relevant context data in the messages to this operation in the Step Context field. For multiple matches, prefix each expression with the string “XPATH:” or “REGEX:”. This text string, including the colon character, acts as a delimiter to separate multiple expressions. For example XPATH:Envelope/Header/Server/Loc/ for XPath expressions and REGEX:.*(d*).* for regular expressions. If the context meta data is common for all steps of this transaction, enter the expressions to match the context data using the fields in the Transaction Settings section.
Use the drop down menu for the Context Location field to select where the context meta data will appear in the message exchange for this step of the transaction. Depending on the implementation of the Web service transaction, the context may appear in all messages. In the case that the context changes from one step to another, you must be sure to correlate the context match expressions in the Step Context field with the Context Location selected for this step of the transaction. For the initial step (Step 1), the context may only appear in the Response message after an activation or login request message has been sent. In this case, select the Response option.
To have JaxView monitor the transaction step for a specific notification content string or strings, enter one or more XPath expression(s) to match the location of the notification string(s) within the messages exchanged for this step in the Notification Path field. For multiple matches, prefix each expression with the string “XPATH:” . This text string, including the colon character, acts as a delimiter to separate multiple expressions. For example, XPATH:Envelope/Header/State/Notifications/child::Status/child::text(). Depending on the implementation of the Web service transaction, the notification strings may appear in the same location in all messages or may be specific to the service being invoked.
To have the transaction monitor status set based on the content of notification strings, enter the text string that, if matched, should trigger an error status in the Error Notification List field. To include multiple strings, separate each string with a comma. JaxView will scan any text string returned from the XPath query entered in the Notification Path field for occurrences of the string(s) entered in the Error Notification List field. For example: abort,rollback, fail.
Repeat these steps to add other step definitions to the transaction.
Complete the Transaction Settings section as indicated. If the transaction implementation uses a common context meta data for all of the steps of the transaction, enter the XPath expression(s) or regular expression(s) for extracting the context data in the corresponding Transaction Context field.
Complete the Threshold and optional Baseline settings sections of the Add Transaction form as indicated.
Click the Save button near the bottom of the form. After a short refresh cycle, the new transaction monitor definition is added to the Transactions object tree.