Multi-step HeartBeat Transaction


Working with Multi-step HeartBeat 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

It is common in Web services that transactions are coordinated by using a transaction context that is exchanged as part of the messages of the transaction. If the system you want to monitor using the heat beat transaction requires the use of context data, this data will have to be supplied as part of the SOAP messages entered in the Step Request fields of the applicable steps.

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. You will need to know if context data is required by the systems you are testing.

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:

Multi-step HeartBeat Transaction Definitions

Creating a new Multi-step HeartBeat 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.

The following describes the steps you use to configure a Multi-step HeartBeat Transaction monitor definition.

To add a new Multi-step HeartBeat 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 Multi-step HeartBeat Transaction 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. If necessary, add any special HTTP header name-value pairs into the Step Request Header field for the step. You may include multiple entries but enter only one name-value pair per line. If you have configured a previous step to match and retain header values, these retained values will be automatically added to the HTTP header of this step without the use of reference variables. See the steps below for examples.

    3. Enter the entire SOAP envelope content for this step into the Step Request field. Generally, you will need to cut and paste this from another reference and then make any necessary changes in the text area of the form.

      If this is not the first step of the transaction and successful completion of this step requires one or more values returned by the service in the previous step, you must add the appropriate content matching patterns to the previous step. You then include the matched values from the previous step into the current step by using the special reference variables inside the SOAP envelope content in this Step Request field. To include the value from the first matched expression in the previous step, you place the string [RESPONSE_VAL](0) at the position in the SOAP message where you want the value to be included. To include the second matched value, use the string [RESPONSE_VAL](1) in the SOAP message for this step.

    4. Enter one or more pattern matching expressions into the Response Match Value field. You can use regular expressions or XPath expressions. Separate multiple expressions with "XPATH:" or “REGEX:” to indicate the beginning of each expression string. For example, two XPath expressions can be entered as: XPATH://Post[@onlineResource]XPATH://Get[@onlineResource]. See the section JaxView Tools for examples of regular expression syntax. The order that the expressions are entered is critical to reference any retained values to be used in the next step of the transaction, as noted in the step above.

    5. Enter the names of the HTTP header values that you want to include in the HTTP header of the next step into the Response Header For Next Step field. You use this to retain HTTP header values that need to persist from one transaction step to another. The requirements are:

      • Each header name must be exactly the name and case as it is expected to appear in the response header. For example: Cookie as opposed to COOKIE
      • Each header name entered in this field must be delimited with square brackets. For example: [Cookie]
      • Each header name must be entered on a separate, single line in this field.

      Header values matched and retained by this step will automatically be added as header name-value pairs to the HTTP header of the next transaction step.

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

Multi-step HeartBeat Transaction Properties

The Multi-step HeartBeat 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 heart beat.
Step Title: The title for this step to show up in the step list when editing the monitor
 
Step Request Header:
Use this field to enter any additional HTTP header values that should be sent with the request for this step. Use the syntax of headerName=headerValue for each header parameter. Separate each name-value pair with a new line (CR/LF). For example:

Content-Type=text/xml; charset=utf-8
Cookie: JSESSIONID=F38862390CCC212A7B0FC6ED6EDC6541

Step Request:
Enter the SOAP envelope content to be sent to the Web service in this step of the transaction. If a value needs to be captured or retained from a the response from a previous step the following replacement variable pattern:

[RESPONSE_VAL](n)

where [RESPONSE_VAL](n) will be replaced with the nth matched value from the expression(s) in the Response Match Value field of the previous step. The first matched value will be n=0

[RESPONSE_STEP](n)

where [RESPONSE_STEP](n)will be replaces with the 1st matched value for the n step. This is good when you need to pass a variable from another step to this step of the transaction

Note: The scope of the replacement variables is limited to the step immediately before the current step.

Response Match Value:
Enter one or more regular expressions or XPath expressions to match on content returned from the service request in this step. REGEX: or XPATH: expressions to match on the response of the step request. In case of XPATH: multiple matches place multiple XPath expressions delimited by XPATH:
Response Header For Next Step:
Newline delimited list of headers in the response for this step to be used in the next step. Place the headers in brackets (for example [Cookie]). In this example JaxView will find the header 'Cookie' and its value in the response http header of this step and adds it to the http header of the next steps request.

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.
Interval:
The frequency, in seconds, at which this heart beat transaction will run.

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.