IBM Support

RIT Action Group actions for parallel message handling explained

Technote (FAQ)


Question

This document details how and when parallel message handling takes place in an Action Group, and details some of the consequences of parallel message handling

Answer

Introduction


The IBM Rational Integration Tester RIT application allows tests and stubs to be constructed using actions or building blocks in a message tree. The Action Group action itself does nothing but is a folder containing other actions. The Action Group causes some of the contained message actions run in their own threads.


What is an Action Group for?


An action group is intended to permit the construction of tests in these circumstances:

  • Two or more messages must be received by the test and the order in which the messages will arrive cannot be determined. This approach is not necessary where the messages remain available (i.e. the messages arrive on a message queue and are not consumed by any software other than RIT).
  • A single message must be consumed by more than one message action in the test or stub. (A message can be consumed twice with different filters so that different validations are applied for each set of messages.)


When should and Action Group not be used


An action group is not intended to be used for any other purpose than those given above. If another use case for an action group seems to have been found then carefully consider whether the test could be restructured to avoid the use of an action group.

Sometimes a tester will use an action group only to logically group a series of test steps and keep the test layout tidy, even though there is no intention to run message actions in parallel. This can lead to the development of tests which fail in unpredictable ways, or tests which pass when they should fail. See the pitfalls of action groups described later in this document.

Pitfall 1: Hidden Failures


When an action fails (or has a validation failure) within an action group this does not cause the containing test to fail.

A tester may add a failure action to each action within the Action Group and set a flag tag to be detected in the main body of the test. This flag could then be detected in the main body of the test using a conditional action and a failure raised using a failure action. However testers taking this approach need to be aware of problems with state shared between threads (see pitfall 2 below).


Pitfall 2: Parallel Message Handling and State


A test or stub has a tag store in which tags are defined and tag values are kept and updated through the execution of the test or stub. An action group does not have a separate tag store but shares the tag store of the containing test or stub.

A tag value set outside an action group can be overwritten within an action group. If the tag value is also set by a standard action within the action group and read by a message action (in a separate thread) there is no way to know which value the tag will have when read back.

Often where the above problem has occurred simple testing will consistently give the same result. The problem may only reveal itself when run under a heavy load or on hardware with a different speed.

    For example it is possible to create a validation failure with the following test construction:
      • Set value = 24.
      • Action Group Start.
        • Set value = 25.
        • Send Request (to IBM MQ) including value.
        • Receive Reply (from IBM MQ) to read back the value sent and validate it is 25.
          (Validation fails - value read back is 24.)
      • Action Group End.
    This is an example of a behaviour which would be different if the actions in the Action Group did not run some message actions in parallel. It is also impossible to prove logically that this test will always fail, even though it has never succeeded during observation.

    Note that had we validated for a return value of 24 the test would seem to always pass, but could still fail at some future time.



Why is an Action Group not always needed for a Send Request and Receive Reply pair?


Although a RIT test may appear to define procedural tests in which the actions execute in sequence (with loops and conditional blocks as defined) under the hood RIT is aware that message receipt actions must be listening for incoming messages prior to the first point in time when the message could be received.

RIT takes responsibility for preparing to receive the incoming message before sending the outgoing message whilst at the same time permitting the test to construct filters and correlation IDs in the ordinary flow of test execution.

A similar approach is taken with the subscribe action which may receive a response (even though it is not linked to a send request action in the way that a receive reply action is).


How is parallel message handling organised in an Action Group?


Within an action group the following tasks will run within a separate thread:
  • Send Request Actions (which share the thread with their Receive Reply Action)
  • Receive Reply Actions
  • Subscribe Actions
  • Receive Request Actions
Each such message action (or message action pair) will have a distinct thread.

One consequence of this design which testers using Action Groups should be aware of is that any tag values intended for use inside a Send Request Action within an action group should be prepared beforehand outside the Action Group to avoid possible intermittent errors.


Previewing a test containing an Action Group


IBM Rational Integration Tester contains an undocumented feature. Since this feature is undocumented there is no guarantee that it will be unmodified or even included in future releases. However the 8.0, 8.5 and 8.6 releases of the software include an execution sequence preview window.

To see the execution sequence preview window hold down CTRL and SHIFT and launch a single test from the GUI by clicking the "run" toolbar button. A window containing a tree view will appear. (Close the window when you wish the test to proceed.)

The contents of this tree shows underlying class names in the application software and the view was apparently intended for use by the RIT software developers rather than the end users. However it is useful because with a little guess work the class names can be tied back to actions within the test, and we can see that items below a Thread Action within the tree will be run in their own thread, commonly at the start of the Action Group.


Further reading


The formal documentation regarding Action Groups can be found in the product manual's action group description although most of that information is in this article.

Readers interested in the common problems of multi-threaded execution may like the developerWorks article writing multi-threaded Java applications which is brief overview of the problem and the traditional approach in a modern language. One response to these problems is the rise of functional programming languages. The curious reader new to this topic may enjoy developerWorks' busy Java developer's guide to Scala.

Document information

More support for: Rational Test Workbench
Rational Integration Tester

Software version: 8.0, 8.5, 8.6

Operating system(s): AIX, Linux, OS X, Solaris, Windows

Software edition: All Editions

Reference #: 1694027

Modified date: 05 February 2018