SOAP Transaction Monitor


with SOAP Transaction Definitions

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.

Transaction Context

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.

Transaction Error Status

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:


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 SOAP Transaction Definitions

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:

Initial
The step property for the first Web service operation called in the transaction.
End
The step property for the last Web service operation called in the transaction indicating that the transaction was completed successfully.
Participant
The step property for the all of the Web service operations called after the initial operations and before the end operation call.



The following describes the steps you use to configure a Generic SOAP Transaction monitor definition.

To add a new SOAP Transaction definition

  1. Select the Transactions tab from the Main View navigation menu

  2. Click on the Transactions root node in the left side object tree menu

  3. 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

  4. 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.

  5. 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:

    1. 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.

    2. 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.

    3. 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. See the section JaxView Tools for examples of regular expression syntax.

      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.

    4. 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.

    5. 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.

    6. 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.

    7. Repeat these steps to add other step definitions to the transaction.

  6. 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.

  7. Complete the Threshold and optional Baseline settings sections of the Add Transaction form as indicated.

  8. 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.

Transaction Properties

SOAP Transaction properties form is divided into four sections as described below.

Transaction Steps

The Transaction Steps section includes 10 Transaction step sub panels that you use to configure how JaxView will monitor the individual operations that comprise the Transaction. Some properties could be the same for every step. Each step has the following property settings:

Operation Name:
Use the drop down menu to select the name of an operation for this step of the transaction. The operations must have been added to the Service object tree as part of a Service definition before they can be added to the transaction.
Operation Property:
Select whether this operation is the first (Initial) operation, a participant or the last (End) operation in the Transaction.
Note: Some transactions could have multiple End operations. When a message with the correct context is sent to the last operation then the transaction is considered to have completed successfully by the JaxView monitor.
Step Context:
If each step of the transaction has its own context location then enter an XPath expression or Regular expression that will match on the context string for each step. For example XPATH:Envelope/Header/Server/Loc/ or REGEX:.*href=(d*).* . See the section JaxView Tools for examples of regular expression syntax. If the context is the same for all steps, use the Transaction Context field in the Transaction Setting sub panel to for this expression.
Context Location:
Select the message that contains the context data. This will be either the Request or Response message for this operation. For example in a login action normally the context location will be in the response.
Notification Path:
An XPath expression that will return any notification strings in the messages exchanged in the transaction. For example, this expression should be designed to extract notification strings such as rollback, commit, etc. from the message.
Error Notification List:
If string returned by the Notifcation Path XPath expression contains the any of the strings entered in this field then the transaction status will be reported as an error. For example, if the string "rollback" is entered in this field and when an Transaction is executed and the XPath expression returns the string "rollback", then the transaction will be in error for alerting purposes.
Note: This does not mean the transaction will end. This is only for the status of the transaction. The transaction will not end until an "End" operation has been called or the transaction has timed out.

Transaction Settings

Title:
The unique title for this transaction. This title will be displayed in the Transactions object tree as a reference to this transaction monitor(required)
Description:
A short description of what what this transaction monitor does (optional)
Disabled:
Check this box to disable this transaction monitor.
Monitor Schedule (optional)
Select the monitor activation schedule for this monitor. When the option None is selected, the monitor will run 24 hours a day. Time limited schedules can be defined in Schedules node under the Admin object tree. See the section Admin Tab for more information on setting schedules.
Transaction Context:
Enter one or more XPath expressions that point to the value of the transaction instance context. JaxView uses these to extract the context data of messages in the transaction. Use this field if the context location and pattern in the same for all steps of the Transactions. For example: Envelope/Header/CoordinationContext/Identifier/child::text().
RegEx Transaction Context:
Enter one or more regular expressions to extract the context data for this transaction. Use this field if correlation context is a cookie in the http header and the context location and pattern in the same for all steps of the Transactions. See the section JaxView Tools for examples of regular expression syntax. For multiple regular expressions, each expression should result in only ONE value.
NOTE: If XPath Transaction Context is set then this property setting will be ignored.
Timeout:
This is the value of the timeout in seconds that JaxView will wait for the transaction to be completed. If the transaction has not ended within this period of time then the transaction monitor will timeout and be reported as in error.

Baseline Settings

Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.

Threshold Settings

Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.

Error Condition:
Set the monitor measurement condition that is considered to be a failure or critical performance threshold.
Warning Condition (optional):
Set the monitor measurement condition that is considered a warning threshold or degraded performance level.
Good Condition (optional)
Set an optional monitor measurement condition below which the system performance is considered to be acceptable.