Transactions Tab for Stateless Transactions

When viewing a stateless transaction on the Transactions tab, you can see the components that are shown in the following graphic.
dts103
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.
    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
Mass change icon.png. 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:
Return icon.png Returns you to the last edit that was made
Find icon.png Finds the next occurrence of the selected text
Find previous icon.png Finds previous occurrence
Find next icon.png Finds next occurrence
Toggle icon.png Toggles the highlight search
Shift left icon.png Shifts the current line to the left four spaces
Shift right icon.png Shifts the current line to the right four spaces
Insert comments icon.png Inserts comments slashes (//) at the cursor position
Remove comments icon.png 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 Enlarge icon.png.
  • To customize the Response Data editor, click Wrench icon.png, 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.