Skip to content
DevTest Solutions - 10.4
Documentation powered by DocOps

Transactions Tab for Stateless Transactions

Last update March 1, 2018

When viewing a stateless transaction on the Transactions tab, you can see the components that are shown in the following graphic.

Transactions Tab for Stateless Transactions, marked up.

  • A: To view and edit stateless transactions, use the Stateless Transactions list. To add, move, or delete stateless transactions, use the toolbar at the bottom of the pane.
  • B: One logical transaction (in the stateless transaction list) contains exactly one Meta transaction and any number of specific transactions. The Transactions list shows these transactions under the logical transaction. To add, move, or delete stateless transactions, use the toolbar at the bottom of the pane.
  • C: To view and edit transaction requests and response data for either Specific or Meta transactions, which are selected from the Transactions area, use the Transaction Basics area. You can select a match style for the specific transaction here.
  • D: The Request Data panel shows the stateless requests.
  • E: The Response panel shows the response to the stateless requests.

    Note: If you add or change several transactions, click Refresh icon. The magic string and date variables are created for you. Existing magic strings and variables are not modified.

Transaction Basics Editor

To view and edit transaction data for specific or meta transactions, use the Transaction Basics editor. Select a specific transaction or META from the Transactions list.

The Transaction Basics editor lets you specify the following information:

  • Match Style
    Values:

    • Signature
    • Operation
  • Operation
    Defines the operation that is selected.
  • Allow duplicate specific transactions
    Specifies whether to allow DevTest to respond more than once to the same call, choosing a different response.
    Values:
    • Selected: DevTest can respond multiple times to the same call, with different responses. Round-robin matching only happens if this check box is selected. For round-robin to work, each response must be under a specific request. With multiple responses for one request, round-robin matching does not occur.
    • Cleared: DevTest can respond only once to a specific call.

Request Data Editor

The Request Data editor allows you to update the data that is associated with a request.

Request Data Editor

Arguments

VSE uses the operation name and arguments to look up a matching response for an incoming transaction.

Adding and Removing Arguments

The META transaction is a template for the specific transactions. For more information, see Logical Transactions. Therefore, arguments can be added to and removed from the META transaction, and these changes apply to all specific transactions in that logical group. Arguments cannot be directly added to or removed from specific transactions.

Modifying Arguments

  • Name
    Defines the name of the argument, which is parsed from the request. In most cases, this field should not be modified. It can only be changed at the META transaction level, and these changes propagate to the specific transactions.
  • Name in Session
    Defines a value that the application automatically generates when magic strings are identified. The value can be referenced in the current (or later) responses using the {{ }} notation. If this field is not empty, the incoming value is stored in the session using the specified name. This value should not typically be modified.
  • Comparison Operator
    Defines an operator to use in the matching logic. By default, for a specific transaction, all arguments are expected to match exactly. To change this and create more flexible matching logic, modify the comparison operator. See Argument Match Operators for the definitions of the comparison operators.
  • Magic String
    Specifies whether to include the specified value as a candidate for magic strings.
    Values:
    • Selected: If this check box is selected and you click Regenerate magic strings, the specified value is a candidate for magic strings. Selecting this check box does not override the rules for identifying magic strings. You cannot use it to force something to be a magic string; it is still subject to the VSE magic string properties in the lisa.properties file.
    • Cleared: If this check box is not checked and you click Regenerate magic strings, the specified value is excluded as a candidate for magic strings. If something was used as a magic string and you did not want the magic string substitution to happen, clear this check box and select Regenerate magic strings.
  • Date Pattern
    Defines the pattern by which the application interprets incoming and specified values as dates. This value is automatically generated and should not typically be modified.
    This pattern is a Java date and time pattern. It is a strict interpretation, so the values must match the pattern precisely. If both (or either) values cannot be parsed as dates, then the argument is deemed not to have matched. If both values can be parsed as dates, they can then be compared as dates using the following operators:
    • =
    • !=
    • <
    • <=
    • >
    • >=
    You can still use "Anything," "Regular Expression," and "Property Expression." If you use "Regular Expression," the incoming value is treated as a string.
  • Case Sensitive
    Specifies whether matching is case-sensitive.
    Values:
    • Selected: All matching is case-sensitive.
    • Cleared: The comparison operators ignore case.
    Default: Selected.
  • Is Numeric
    Specifies whether argument values are processed as strings or numbers.
    Values:
    • Selected: The application processes argument values as numbers.
    • Cleared: The application processes argument values as strings. That means "10000" is considered less than "9" because "1" comes alphabetically before "9".
    Default: Cleared.

Mass Change

To perform a mass change of request arguments, click Mass Change . The Change Request Arguments dialog appears.

Change Request Arguments dialog

To specify mass changes, complete the fields on the Change Request Arguments dialog as appropriate, and click Update.

Attributes

To add, edit, move, and delete key/value pairs, use the Attributes tab.

Meta Data

To add, edit, move, and delete Meta data key/value pairs, use the Meta Data tab.

Match Script Editor

To insert a sample match script for your information, right-click the Match Script panel. You can also switch the match script on or off by selecting or clearing the Do Not Use the Script check box.

To designate the scripting language, use the language drop-down on the lower right of the pane.

  • Language
    Designates the scripting language to use.
    Values:
    • Applescript (for OS X)
    • Beanshell
    • Freemarker
    • Groovy
    • JavaScript
    • Velocity
    Default: Beanshell

To hide or display line numbers, the editor toolbar, and the editor status bar, right-click on the left side of the Match Script panel, then select the appropriate options from the short-cut menu. The following graphic shows all options that are displayed.

Match Script Editor Stateless

A match script defines how VSE decides whether a specific transaction matches the incoming one. To receive a match that is based on the specific condition, write BeanShell scripts performing appropriate actions.

For example:

/* always match name=joe */ 

ParameterList args = incomingRequest.getArguments();

if ("joe".equals(args.get("name"))) return true else return 

defaultMatcher.matches(); 

You do not need to specify a match tolerance level or match operator for the match script to work. The match is found based on the condition in the match script.

By default (with no match script) an inbound request is matched against a service image request by comparing operations, arguments, or both to come to a true/false "Do they match?" answer. A match script simply replaces this logic with whatever logic makes sense and must still come to the true/false "Do they match?" answer.

The script can use the default matching logic. Inside the script, use the expression, "defaultMatcher.matches()". This expression returns a true or false using the VSE default matching logic.

The match script is similar to a scripted assertion. Basically, it is a regular BeanShell script but with the following additional variables preloaded for you (and the usual properties and testExec variable):

  • com.itko.lisa.vse.stateful.model.Request sourceRequest (the recorded request)
  • com.itko.lisa.vse.stateful.model.Request incomingRequest (the live request coming in)
  • com.itko.lisa.vse.RequestMatcher defaultMatcher (you can default to this variable)

Return a Boolean value from the script; true means a match was found.

If there is an error evaluating the script, VSE deliberately ignores the error and defaults to the regular matching logic. If you do not think your script is being run, review the VSE log file.

A good way to add logging and tracing into your match scripts is to embed calls to the VSE matching logger. The VSE matching logger produces the messages in the vse_xxx.log file, where xxx is the service image name. For example:

import com.itko.lisa.VSE;

VSE.info(testExec, "short msg", "a longer message");

VSE.debug(testExec, "", "I got here\!\!");

VSE.error(testExec, "Error\!", "Some unexpected condition"); 

return defaultMatcher.matches(); 

If you log messages at INFO, later when the production settings are applied to the logging.properties file, the log level is WARN and your messages appear as a DevTest test event (a "Log Message" event).

Tips from logging.properties:

  • To simplify debugging, keep a separate log for VSE transaction match/no-match events.
  • Change INFO to WARN or comment out the following line for production systems:

    log4j.logger.VSE=INFO, VSEAPP

  • The INFO value typically reports every failure to match.

Match Script Editor Toolbar

Match Script editor toolbar

The Match Script editor toolbar lets you perform the following functions:

 Returns you to the last edit that was made

 Finds the next occurrence of the selected text

 Finds previous occurrence

 Finds next occurrence

 Toggles the highlight search

 Shifts the current line to the left four spaces

 Shifts the current line to the right four spaces

 Inserts comments slashes (//) at the cursor position

 Removes the comments slashes (//)

Response Data Editor

To view and edit the response information, use the Response Data editor.

  • To edit the expected response for a transaction, use the Response Body area.
  • To add, order, delete, and navigate through responses, use the toolbar as described in the Match Script Editor Toolbar.
  • To enlarge the Response Data Editor panel, click .
  • To customize the Response Data editor, click , as described in Customize the Response Editor.
  • To inspect the Validation Results, view the XML schema source, and see the error log, use the buttons at the bottom of the panel.

Response Data Editor stateless

Edit the Think Time Spec field as necessary.

Response Data Editor Meta Data tab

To add, edit, move, and delete key/value pairs, use the Meta Data tab.

Tip: You can only add properties if the response is text. You cannot add properties to a binary response.

Was this helpful?

Please log in to post comments.