2012 10 23_2649_rational_integration_tester_vi

Virtualization with IBM Rational
Integration Tester

Note
Before using this information and the product it supports, read the information in “Notices”
on page 137.

© Copyright IBM Corporation 2001, 2012.

VIRTUALIZATION WITH IBM RATIONAL INTEGRATION TESTER

1 INTRODUCTION ............................................................................................................................. 4
2 USING VIRTUALIZED APPLICATIONS FOR TESTING ........................................................................... 5
2.1 INTRODUCTION ....................................................................................................................... 5
2.2 THE OLD WORLD ................................................................................................................... 6
2.3 THE NEW WORLD ................................................................................................................... 6
2.4 WHEN TO USE VIE.................................................................................................................. 6
2.5 USING VIE STRATEGICALLY .................................................................................................... 6
2.6 SOLVING PROBLEMS WITH VIE ................................................................................................ 7
2.7 VIRTUAL APPLICATIONS – SIMPLE TO COMPLEX ........................................................................ 7
3 VIE ARCHITECTURE AND SETUP .................................................................................................... 9
3.1 OVERVIEW ............................................................................................................................. 9
3.2 DOMAINS AND ENVIRONMENTS .............................................................................................. 10
4 RATIONAL INTEGRATION TESTER PROJECT SETUP ........................................................................ 12
4.1 THE INITIAL SCREEN ............................................................................................................. 12
4.2 CREATING A NEW PROJECT................................................................................................... 13
4.3 EXERCISE: CREATING THE TRAINING PROJECT ........................................................................ 14
4.4 RATIONAL INTEGRATION TESTER LAYOUT ............................................................................... 18
4.5 RATIONAL INTEGRATION TESTER PERSPECTIVES .................................................................... 19
5 MODELING THE SYSTEM .............................................................................................................. 20
5.1 PERSPECTIVE OVERVIEW ...................................................................................................... 20
5.2 WORKING IN MULTIPLE ENVIRONMENTS ................................................................................. 20
5.3 LOGICAL VIEW...................................................................................................................... 21
5.4 EXERCISE: SETTING UP THE LOGICAL VIEW FOR A SIMPLE SYSTEM .......................................... 23
5.5 PHYSICAL VIEW .................................................................................................................... 25
5.6 EXERCISE: SETTING UP PHYSICAL VIEW FOR A SIMPLE SYSTEM ............................................... 26
5.7 ENVIRONMENTS ................................................................................................................... 26
5.8 EXERCISE: CREATING AN ENVIRONMENT ................................................................................ 26
5.9 EXERCISE: SCHEMA LIBRARY ................................................................................................ 27
5.10 EXERCISE: THE MESSAGE EXCHANGE PATTERN (MEP) ....................................................... 29
6 THE DEMONSTRATION ENVIRONMENT ........................................................................................... 31
6.1 MANAGING FLIGHT BOOKINGS ............................................................................................... 31
6.2 FINDING AND BOOKING HOTELS ............................................................................................. 32
6.3 FLIGHT ADMINISTRATION ....................................................................................................... 32
7 USING SYSTEM DATA TO BUILD A SYSTEM MODEL ........................................................................ 34

Page 1 of 138 © IBM Corporation 2001, 2012


7.1 OVERVIEW ........................................................................................................................... 34
7.2 SYNCHRONISATION OVERVIEW .............................................................................................. 34
7.3 BUILDING A MODEL FROM RECORDED EVENTS........................................................................ 35
7.4 RECORDING MQ MESSAGES ................................................................................................. 35
7.5 EXERCISE: SETTING UP THE TRANSPORTS .............................................................................. 36
7.6 EXERCISE: ADDING THE FLIGHT BOOKING MESSAGE SCHEMAS ................................................ 41
8 RECORDING EVENTS ................................................................................................................... 42
8.1 THE RECORDING STUDIO ...................................................................................................... 42
8.2 EXERCISE: RECORDING EVENTS FROM A TRANSPORT ............................................................. 43
8.3 EXERCISE: BUILDING OPERATIONS FROM RECORDED EVENTS ................................................. 45
8.4 EXERCISE: COMPLETING THE SYSTEM MODEL ........................................................................ 51
8.5 EXERCISE: RECORDING EVENTS FROM AN OPERATION ............................................................ 52
9 CREATING AND EXECUTING A BASIC STUB ................................................................................... 55
9.1 EXERCISE: MAKING A SIMPLE STUB FROM RECORDED MESSAGES.............................................. 55
9.2 EXERCISE: EXECUTING A STUB FROM RATIONAL INTEGRATION TESTER ..................................... 58
9.3 EXERCISE: MODIFYING THE STUB ON THE FLY ......................................................................... 59
10 PUBLISHING AND DEPLOYING STUBS ........................................................................................ 61
10.1 EXERCISE: USING RTCP ................................................................................................... 61
10.2 EXERCISE: PUBLISHING A STUB .......................................................................................... 62
10.3 EXERCISE: DEPLOYING A STUB ........................................................................................... 63
11 SYNCHRONIZATION .................................................................................................................. 65
11.1 A SECOND TEST SYSTEM – HOTELFINDER ........................................................................... 65
11.2 SYNCHRONIZATION ............................................................................................................ 65
11.3 EXERCISE: SYNCHRONIZING WITH THE HOTELFINDER WSDL ............................................... 65
12 CREATING A STUB FROM MEP ................................................................................................. 71
12.1 THE STUB EDITOR............................................................................................................. 71
12.2 TRANSITIONS .................................................................................................................... 71
12.3 EXERCISE: CREATING A STUB FROM THE MEP ..................................................................... 72
12.4 USING THE HTTP PROXY .................................................................................................. 73
12.5 EXERCISE: HTTP STUB EXECUTION ................................................................................... 75
12.6 EXERCISE: HANDLING NEW REQUEST OPTIONS .................................................................... 76
13 STORING AND MANIPULATING DATA ......................................................................................... 79
13.1 TAGS AND THE TAG DATA STORE ....................................................................................... 79
13.2 CREATING TAGS ............................................................................................................... 80



13.3 USING TAGS ..................................................................................................................... 82
13.4 EXERCISE: CREATING AND USING A TAG .............................................................................. 82
13.5 GUARDS ........................................................................................................................... 83
13.6 EXERCISE: USING GUARDS ................................................................................................ 83
14 DATA DRIVEN STUBS ............................................................................................................... 85
14.1 DATA SOURCES ................................................................................................................ 85
14.2 EXERCISE: CREATING PARAMETERIZED STUBS FROM RECORDED MESSAGES ........................ 85
14.3 EXERCISE: CREATING A DATA SOURCE WITHOUT RECORDED MESSAGES ................................ 89
14.4 EXERCISE: DATA DRIVING WITH REPEATING ELEMENTS........................................................ 92
14.5 EXERCISE: INPUT TAGS ..................................................................................................... 95
15 DATABASE STUBS ................................................................................................................... 97
15.1 INTRODUCTION.................................................................................................................. 97
15.2 THE RIT JDBC DRIVER ..................................................................................................... 97
15.3 EXERCISE: RECORDING SQL ............................................................................................. 99
15.4 EXERCISE: CREATING AND EXECUTING A DATABASE STUB ................................................... 101
15.5 EXERCISE: MODIFYING THE SIMULATION DATABASE ............................................................ 104
16 ALTERNATIVE MESSAGE FORMATS ......................................................................................... 106
16.1 EXERCISE: COBOL COPYBOOK MESSAGES ...................................................................... 106
17 DATA MASKING ..................................................................................................................... 109
17.1 EXERCISE: FIXED VALUE SUBSTITUTION............................................................................ 109
17.2 EXERCISE: DATA SOURCE SUBSTITUTION ......................................................................... 111
17.3 EXERCISE: AUTOMATIC VALUE CREATION ......................................................................... 112
18 DATA MODEL STUBS ............................................................................................................. 114
18.1 EXERCISE: RECORDING A WEB SERVICE WITHOUT A WSDL ............................................... 114
18.2 CREATING A DATA MODEL STUB AND ASSOCIATED OPERATIONS ......................................... 116
18.3 EDITING THE DATA MODEL STUB ...................................................................................... 126
19 STATE AND SESSIONS ............................................................................................................ 129
19.1 EXERCISE: TRACKING USER SESSIONS ............................................................................. 129
20 BEHAVIOURS ......................................................................................................................... 132
20.1 EXERCISE: THE TIMER BEHAVIOUR ................................................................................... 132
21 LEGAL NOTICES .................................................................................................................... 137



1 Introduction

This document serves as a training manual to help familiarize the user with the virtualization
functionality present in IBM® Rational® Integration Tester. The training exercises make use of a variety
of technologies, including IBM WebSphere® Application Server, WebSphere MQ, IBM DB2®, and web
services. It is assumed that the reader has a fair understanding of these systems.

The main objectives of this training course are to present the various functionalities of the Virtual
Integration Environment (VIE) and how best to use them in testing Message Oriented Middleware
(MOM) applications. In this course we will:

 Walk you through the installation of the different components of VIE on your PC
 Present the various perspectives in the design component of VIE, Rational Integration Tester,
describing how and when they are used
 Demonstrate how VIE can facilitate virtualization of services in a message oriented middleware
architecture by
o Recording messages or synchronizing with the system to provide a model of the system.
o Providing a graphical interface for the display and creation of messages
o Creating virtualized services for message based systems and databases from recorded
events.
o Allowing the running of virtualized services to be repeated over and over with little
manual intervention
 Demonstrate how to virtualize database connections within the system under test
 Create and utilize data models between a set of virtual services, allowing data to be persisted
and modified across services, and between executions of those services.
 Publish virtual services to the Rational Test Control Panel (RTCP), allowing them to be deployed
and managed from a central repository.



2 Using Virtualized Applications for Testing
2.1 Introduction
When we need to test a set of services within a Service‐Oriented Architecture (SOA), we may find that
some components of the system are unavailable. This may be for a number of reasons. It may be that a
particular service is still under development, and cannot be accessed yet. Perhaps development has not
even started yet. In other cases, services may be in use by others, and cannot be shared – or may be
expensive to use. Opening up access to other services might expose private data to testers, and so
those services are not available to the test team.
Alternatively, services may be available, but they might not be responding in the way that is necessary
to carry out a given set of tests – for example, users may want to check that the system responds
appropriately to error conditions. By stubbing a particular service to generate these errors, a tester
can have full control over the operation of the system, allowing them to test conditions that may not
exist within the live system.
Whatever the reason, while conducting SOA testing, it is likely that a tester will have the need for the
system to operate in ways that may not be currently available. This may cause delays, due to
dependencies on the components in question.
VIE is a set of integrated tools that allow you to stub out dependencies within a test environment,
allowing testing to continue without worrying about any missing components, or modifying existing
components to act differently. Your starting point may be a client application that communicates with
a service through the network, using one of the communication methods (or transports) supported by
VIE. This client application may present a GUI to a user, or it may simply be another service within
your architecture.

However, for whatever reason, this service is unavailable. In order to carry out our testing, we will
need to provide a virtual replacement for the service. Using VIE, we can create this replacement – a
virtual service that reacts to the same network traffic, on your existing test infrastructure.

You may already be familiar with the concept of a Virtual Machine (VM). Virtualization as implemented
with VIE should be thought of as more granular than VMs. VIE can virtualize an application or database
(or just part of that application or database), whereas VMs are designed to virtualize an entire
machine. VMs also require licenses for their applications and are generally still maintained outside of
the test team. VMs are less flexible for testing purposes whereas a virtualized application in VIE can



easily be manipulated to fit your testing purposes. For example, you may want your virtual application
to send in erroneous data for negative testing of your system.

2.2 The Old World
Stubbing out components of a system allows us to test that system without waiting for components to
become available. However, testers have traditionally been reliant on developers to create these stubs.
These stubs were usually not user‐friendly. There would be little chance that a tester could pick them
up and re‐use them. Additionally, maintenance would normally be handled by the developers. This
approach had little on‐going value and poor return on investment. VIE has been created to change this.

2.3 The New World
VIE moves testers into a new world where they build and maintain their own stubs. In fact, testers can
go even further – stubs become virtual applications. VIE does not require any coding; virtual
applications are easily maintained and universally understood, ensuring maximum re‐use.

2.4 When to use VIE
The chances are high that you are working in a complex, changeable environment. Functional (and
non‐functional) requirements change quickly and test environments and applications are in high
demand from other teams. This high pressure environment put lots of strain on test teams and is the
reason that VIE exists. VIE helps in 3 key areas:
1. It helps you to continue testing when environments are not available
2. It allows you to test earlier and more often, reducing the cost of defects
3. It allows you to force behavior in the SUT by being in control of the services (or more
specifically, the responses from those services).
With these 3 things in mind we can begin to think about the situations that VIE might be applied.

2.5 Using VIE Strategically
VIE is designed to be applied in all test phases from Unit Testing to UAT. Here is a golden rule: we
should always test as completely as possible. We know that when we are Unit Testing individual
operations or services that we may not always have the interfacing components available to test
against. So we virtualize these interfacing components to allow us to run our unit tests.
As we move through the test phases from Unit Testing to Integration Testing and onwards, we
introduce more “real” components into the system. The introduction of these real components has
been de‐risked through virtualization. These interfaces have been accurately modeled by VIE and
tested against. This is the concept of Incremental Integration Testing and it helps to visualize this:



Initially, we build a system using the first components that are available. Any other components that
are required are virtualized. We then introduce new components into the system in a prioritized,
controlled fashion, replacing the virtual components as we go. During this stage, we can perform
incremental integration testing. Eventually, we will reach a stage when all actual components are
available for test. We will then be able to carry out full end to end tests with very few surprises, as we
have been gradually building towards this stage throughout the entire test process.

2.6 Solving Problems with VIE
 Your testing project may be heavily reliant on integration with 3rd parties. This can be immensely
frustrating and costly. VIE can virtualize 3rd party interfaces to allow you to test on your own
terms according to your schedule
 Integration dependencies are not yet ready to participate in testing. Parallel development means
that some projects may not be ready to begin integration testing when your project is ready. VIE
allows you to virtualize interfaces (even before they have been built) and continue testing
 Running training instances of applications without access to large infrastructure. For training
purposes, you may not require access to production sized version of the application. You may
also not require access to any downstream applications. VIE can virtualize and simplify
interfaces, ensuring that training exercises do not impact the production systems
 Testing a database dependent application with scrubbed and isolated data. VIE can simulate
databases too. Of course, this means that you will have full control of all of the data to be used in
testing
 Providing a test system where otherwise there are none. It may be too expensive to build that test
environment. It may take too long to build it. It may be that the test environment is being used
by someone else for the duration of your project. VIE stands in to virtualize applications.

2.7 Virtual Applications – Simple to Complex
Virtual applications can be as simple or as complex as required. VIE provides you with the tools to
model your application to the level you require.



As we move through this training course, we will look at how we can create each of these types of stub,
starting from simple hardcoded stubs, moving towards more complex stubs that track data models and
behaviors.



3 VIE Architecture and Setup
3.1 Overview
In order to introduce VIE, we need to take a look at the different components that you may use while
working with it. These tools are Rational Integration Tester (RIT), Rational Test Control Panel (RTCP),
and the Agents. They will be used in the three stages of a stub’s lifecycle – development, publication,
and deployment.

Rational Integration Tester is the main tool that we will use for the creation of virtual services. It may
also be used for limited deployment of services. It allows us to create a model of the system under test,
record events from the system, as well as to create and execute stubs.
The Rational Test Control Panel is a separate tool that will allow us to manage virtual services within
your environment. Generally, after the development of a stub, it may be published from Rational
Integration Tester to RTCP. The stub is then stored within a repository on the server. From this
repository, each virtual service may be reconfigured, deployed and managed. The server is also used to
manage any agents within the environment.
Agents can run on a number of computers, providing the ability to handle different tasks for the VIE
system. Some agents will act as proxies, redirecting different events so that they may be recorded
within Rational Integration Tester, or handled by a virtual implementation. Other agents act as hosts
for virtual services, allowing them to be deployed to different locations within the network. Both types
of agents will be registered with the server, and will take instructions from it. They will also report
logging data back to the server.



Optionally, a project database may be used to record logging information from any virtual services that
are in place for later review. This is not necessary for services run from Rational Integration Tester,
but a database is required to review interactions with a stub if it has been deployed from RTCP. The
project database can be set up as a MySQL, MS SQL or Oracle database.
Depending on the task at hand (recording, virtualization, or both), the communications between these
components will be slightly different. We will look at how these components fit together in each
situation as we encounter them.

3.2 Domains and Environments
Stubs created in VIE will be organized into a structure using two properties: domains and
environments.
A domain represents a logical grouping of related systems that are part of a real business project and it
is the basic unit of management within VIE. It may be served by one or more Rational Integration
Tester or VIE projects, depending on how large or small the domain is, and how many Rational
Integration Tester/VIE users are working on it.
It is usual for a service or other endpoint to appear in more than one domain because it is reused by
different business projects in different contexts. Thus, a domain is used as a means to group and
manage assets in RTCP. For example, unique business groups within an organization may want to
manage stubs independently from each other.
While being developed and executed inside Rational Integration Tester, each stub uses the domain of
the Rational Integration Tester project. When they are published onto RTCP, they may be published
into that domain, or another domain. This allows us to control stubs within a given domain through
RTCP; we can also control any proxies or agents within the system so that they accept instructions only
from stubs running in particular domains.
After stubs have been published to RTCP, they may be started and stopped through the RTCP interface,
and the routing of messages (to stubs or live systems) can be controlled at domain level.
Each domain can contain one or more environments. In Rational Integration Tester and VIE, an
environment enables users to define both the infrastructure used by any messaging transports, as well
as a group of variables (called tags) that may be used by any tests or stubs running within that
environment.
Typically, environments are used to create configurations for different parts of a software product
development workflow, for example, development, quality assurance, user acceptance testing, and so
on.
Environments are not created directly within RTCP. Instead, they are created automatically when
stubs are published from Rational Integration Tester (because stubs are published into an
environment within a domain) or when a proxy or agent registers with RTCP specifying an
environment name.



Environments within each domain are independent from those in other domains – so if we have a
Performance environment in one domain, it does not need to exist in all other domains. Similarly, if
users inside one domain call a test environment Integration Testing, it does not mean that all other
domains need to use the same naming scheme.
When stubs are published into RTCP, they may be published into one or more environments. So within
a Shipping domain, we might have an Address lookup stub that is only used within a development
environment, while a Dispatch Order stub may exist within multiple environments within that domain.



4 Rational Integration Tester Project Setup
4.1 The Initial Screen
Once configuration of our system is complete, we’re ready to launch Rational Integration Tester and
create a new project. Launching Rational Integration Tester will bring up the following screen:

If you are running Rational Integration Tester on your local machine, you will need to make sure you
have a license at this stage – cloud instances should already have a license installed for you. For more
information on licensing, please ask your trainer, or view section 2.2 of the rit_ins.pdf installation guide.
Once licensing is sorted out, you have several options. From top to bottom:
 New Project – allows you to create a project.
 Clone Project – creates a copy of any Rational Integration Tester project.
 Fetch Project from Source Control – Check out a project from a source control system, and
open it. Note that you will need to configure Rational Integration Tester to communicate with
your source control system before doing this. See the rit_scm_ref.pdf plugin guide for more
information.
 Open Link – follows a link taken from the Test Lab to navigate to the results of a test or test
suite.



 Open an existing project – opens an existing project, either from the list of recent projects
shown by Rational Integration Tester, or by browsing to a .ghp file.

4.2 Creating a New Project
Creating a new project goes through 4 stages. These are:
1. Setting the project name and location
2. Connecting to external servers
3. Setting up user‐based permissions
4. Setting up change management integration
Only the first step is compulsory; the others are optional, but can be edited later from within the
project. If you need to edit any of these settings after the project has been created, you can do it
through the Project Settings dialog (found in the Project menu of Rational Integration Tester).
That said, filling out the server settings listed in the second stage of the project creation process will
normally be very useful, and we will be supplying that information for the examples used in this
course.
The first of these settings is for a project database, which we will be using during this training course.
The project database provides the ability to record and view historical test results – without this, you
will only be able to view results from the current session. It also provides the ability to record logging
data from any stubs that you use. Scripts are provided with Rational Integration Tester to help you set
up and configure a project database, which may be a MySQL, MS SQL, or Oracle database. Once it is set
up, the database may be shared across multiple users and multiple projects.
The other server settings available are for RTCP and the Results Server (legacy users only). RTCP
provides the ability to manage any proxies and agents used by the software; these capabilities can be
used while recording and stubbing. The Results Server setting is used to create links to the reports
held on the server, which should also be connected to your project database; this functionality is now
provided by RTCP, so the Results Server is no longer required, and will not be used in this project.
As we only have a single user for our example project, we will not configure user‐based permissions
for our project. It will be useful in other projects where it is necessary to restrict access to a project to
certain individuals, or to allow different access levels to the project for different users. In particular, it
will be helpful for projects that implement data masking – permissions will allow one user to set up
masks over certain message fields, so that other users cannot view the contents of those fields. We will
discuss this further in the section on data masking.
Finally, we can configure a connection to change management tools such as JIRA, HP’s Quality Center,
or any Open Services for Lifecycle Collaboration (OSLC) compliant change management system, such
as Rational Team Concert. This allows us to link directly into these tools, and raise defects directly
from a test or test suite.
At the end of the wizard, a new project folder will be created within your file system. This folder will
hold all resources – a model of the system under test, along with any tests, stubs or other resources
created for the project. Data files used by your project can also be stored here – this can help you make
your project more portable by including everything in one place. Alternatively, you might want to



include those data files in another location – Rational Integration Tester will be able to refer to them
either way.

4.3 Exercise: Creating the Training project
We will now create a brand new project, which we will continue to use for the duration of this course:
1. Launch Rational Integration Tester by double‐clicking the IBM Rational Integration Tester
shortcut on your desktop.
2. Rational Integration Tester will launch, displaying the initial screen. Create a new project by
selecting New Project and clicking OK.

3. We can now give our project a name, using the Project Name field. We’ll call our project
WWTravel Virtualization.



4. If desired, modify the Owner and Comments fields (these are saved with the project and can be
modified later).
5. In the Directory field, enter the full path to the directory where the project should be created,
or click Browse to locate the directory. The selected directory cannot contain an existing
Rational Integration Tester project.
6. When you are satisfied with the project details, click Next. If the selected directory does not
exist, you will be prompted to let Rational Integration Tester create it, or you can go back and
select a different directory.
7. The wizard will now display the Server Settings dialog. At the top of this dialog, there is a
Results Database section, where we can provide connection details for the project database,
which is used to store all of the test data collected by Rational Integration Tester. A valid
database and working connection are required to store or view any historical results in Rational
Integration Tester.
8. Rational Integration Tester will remember the database details that were used previously; if
you are using a cloud instance, this means that you should already have details entered for you.
Otherwise, you will need to enter the Database URL, User Name, and Password. If you need to
re‐enter them, the settings for the databases on the cloud instances are shown below.
Otherwise, ask your trainer.



Settings Value
Database URL jdbc:mysql://localhost:3306/projectdb
User Name root
Password root

9. Click on Test Connection. A window should pop up stating that the connection was successful.
10. Below the database settings, we can connect to the Results Server and RTCP. We will not be
using the Results Server, but RTCP will be needed later on. The default setting here should be
sufficient:

Settings Value
RTCP URL http://localhost:7819/RTCP
Domain Booking System



11. When you are satisfied with the details entered on this screen, click Finish. If user‐based
permissions or connections to change management tools were required, you would need to
choose Next, and then set them up on the following screens.
12. The new project will be opened in Rational Integration Tester. By default, it will display the
Logical View in the Architecture School perspective.



4.4 Rational Integration Tester layout

The main window of Rational Integration Tester is a workbench that contains several dockable
windows. These windows are organized in a logical way, providing an intuitive, easy‐to‐use central
workspace.
Information about your current project can be found in the title bar and status bar. At the top of the
screen, the title bar indicates the name of the current project, along with the current environment. At
the bottom of the screen, the status bar indicates the name of the current test cycle, the current user,
and the memory usage. For the purposes of this manual, we will not need to be concerned with the
information in the status bar, though you may find it useful to keep an eye on the title bar to check
which environment is currently active.



4.5 Rational Integration Tester Perspectives
In the center of the screen is the main workbench of Rational Integration Tester, showing the current
perspective view. The workbench can be viewed from one of six perspectives ,
selected from the Perspectives toolbar:
Perspective Icon Description

defines the architecture of the system under test, including
Architecture School
service components as well as logical and physical resources

creates requirements that will help other users to create
Requirements Library
tests and test data more quickly and more accurately

monitors systems and processes to record events that are
Recording Studio
captured by Rational Integration Tester

Test Factory creation of tests, test suites, stubs and test data sets

Test Lab executes resources that are created in the Test Factory

contains historical test data and lets users view various
Results Gallery reports for any stored test run, including performance,
errors, and coverage data

The initial layout of the workbench for each perspective is pre‐determined, and it can be restored at
any time by selecting Window > Reset Current Perspective from the main menu. Many aspects of the
workspace can be customized. Each window can be resized within the workbench by clicking and
dragging on its borders; it can be closed via the button in the top right hand corner and can be set to
automatically hide when not in use with or to remain constantly visible with .



5 Modeling the System
5.1 Perspective Overview
The Architecture School perspective is the default perspective loaded when Rational Integration Tester
is started. This perspective is used for modeling the system in a simple, graphical fashion. This model is
split into several parts. As the model is split into several parts, the Architecture School perspective is
also split into several different views. In addition to these views, we also use an Environment to bind
different parts of the model together.
The views are presented along the bottom of the screen:
 Logical View
 Physical View
 Synchronisation
 Schema Library
 Data Models
 Rule Cache
For the moment, we’re going to look at an example of a simple system, which will make use of the first
two views, along with Environments, which are used to tie the Logical and Physical views together.
We’ll then move to the Schema Library to set up message formats.

5.2 Working in Multiple Environments
As we move through the lifecycle of a project, testing may be carried out over multiple environments.
For example, we might have a development environment, using development data, and its own
infrastructure. As we move into a formal test phase, we might start to use different infrastructure
components, or different data. Finally, in production, a completely new set of infrastructure
components will be used, and real‐world data will be in use.

This is only a simple example, but it serves to illustrate the problem: if we’re not careful, we could
create tests or stubs that will need to be rebuilt as we move from environment to environment, or even
worse, resources that are not portable at all. Fortunately, Rational Integration Tester provides a
solution to this, by partitioning the model of the system under test. In order to move our resources
across different environments, we will set up the infrastructure of our system in three sections: Logical
View, Physical View, and the Environment.



The Logical View provides us with an abstract view of the system under test, but does not tie us to
using any particular infrastructure. As an example, it will state that a database is required by our
system, but it will not state any more than that – the database URL, connection details, and even the
type of database provider are not specified at this stage.
The Physical View then defines all of the implementation options – so, for our example, we may have 3
separate databases used across all different environments. All 3 databases would be listed in the
Physical View.
Finally, the Environment binds the logical and physical resources together. At any stage, Rational
Integration Tester can check which environment is being used, and if a reference is found to a logical
infrastructure element, it will use the environment to find the correct physical component. So, to finish
off our example, if we need to access a database within a test or a stub, Rational Integration Tester will
look up the environment to determine which of the 3 databases should be accessed. If we then move to
another environment, Rational Integration Tester will perform the lookup again, and select the
appropriate database.
Of course, this applies to any infrastructure – not just databases, but also web servers, Email servers,
Java Message Service (JMS), or any proprietary technologies.

5.3 Logical View
The Logical View provides an abstract model of the system that we are interacting with. We’re going to
build a simple model here to demonstrate how this works. This model will be made up of several
different elements:

The first object we’ll need to create is a Service Component. Service Components act as containers for
all other elements within the Logical View, and may contain other Service Components to build up
more complex structures.

In most cases, we’ll want to define Operations within a Service Component. Operations define the
functionality of the system. We will be able to create resources based upon the information provided
within each operation.



In order to communicate with the operations available within the system, we’ll also need a set of
Infrastructure Components. These are named components that can be bound to physical resources.
Remembering that Logical View does not contain any concrete details of these components, they will
serve to tell us that there is a JMS server, database, web server, etc., while the Physical View and
Environment will provide more exact information later on.
All of these elements – service components, operations, and infrastructure components ‐ may be
created by pressing Ctrl+N to create a new component, right clicking and using the context menu, or
from the toolbar at the top of the Logical View. In addition, you can use Ctrl+F to find resources after
they have been created.

Finally, we will use Dependencies to link operations to each other, or to infrastructure components.
Outgoing dependencies are displayed in lavender, and incoming dependencies are displayed in green.
Dependencies are only displayed for items in the diagram that are selected. In the example diagram
above, this lets us know that:
 Operation1 has a dependency on Operation2, meaning that Operation1 may call upon
Operation2 (though it might not do so in all circumstances).
 Operation2 has a dependency on the HTTP Connection. This will normally mean that either we
require this HTTP connection to act as the transport for the operation, or that the operation
may need to make use of the HTTP connection itself after it has received a message.
To create a dependency, we can either draw it using the Add a Dependency button in the toolbar,
or if we are setting up an infrastructure component as the transport, we can do this by opening up the
operation’s properties by double clicking on it, and editing the transport information within the
Message Exchange Pattern tab of the properties window that appears.



The toolbar contains a number of other useful tools, at the right hand side:
Add an External Resource: creates a new External Resource, or Synchronization Source,
within the Logical View, and optionally synchronizes with it. We will discuss

synchronization in detail later on.
Add a Dependency: allows you to draw a dependency between two operations, or from
an operation to an infrastructure component.
Edit Filters: filters determine which dependencies will be shown in the Logical View.
They may be necessary in larger, more complex systems.
Selection mode: puts the cursor into selection mode, where you can select and edit
elements of the model. This is the default cursor mode.
Zoom in: zooms into the diagram. This can also be done with Ctrl+MouseWheelUp.

Zoom out: zooms out of the diagram. This can also be done with
Ctrl+MouseWheelDown.
Zoom area: zooms to fit an area, drawn with the mouse, onto the screen.

Reset Zoom: sets the zoom back to the default level.

Fit to contents: zooms the screen to fit everything contained in the Logical View.

Pan mode: uses the cursor to pan around the screen.

Layout all nodes: automatically rearranges all elements contained in the Logical View, so
that nothing is obscured.
Grid: switches the grid on or off. The default setting is off.

We will now use the elements described above to start building a model of an example system. This
system will contain a single web service. We can use this same process to build a model of any service
oriented architecture. Later on, we will look at more efficient methods to build the model, though as
these are not available in all environments, we’ll look at building everything by hand for this first
example.

5.4 Exercise: Setting up the Logical View for a Simple System
1. Before starting, we’ll need to make sure that the web service we’re modeling is active. On the
Windows desktop, double click the AddNumbersServer.jar to execute it. You should see the
following window appear:



2. Press the Start Service button. The Add Numbers Server window should update so that the
Start Service button is no longer valid:

3. Minimize this window (do not close it), and return to Rational Integration Tester.
4. From the Architecture School perspective, make sure that you are in Logical View using the
tab at the bottom of the screen.
5. The middle of the screen will be blank, as there is currently nothing in our model. To add the
first component of a system, right click and select New > General > Service Component. When
asked for a name, call it AddNumbers. It should then appear in your workspace:

6. Select AddNumbers by clicking on it. The outline should change to orange, to indicate the
selection.
7. Right click on the AddNumbers component, and select New > General > Operation. Call the
operation Addition. Your service component should now look like the following:



8. Similarly, add an infrastructure component called AddNumbersPort, by right clicking and
selecting New > Web > HTTP Connection
9. The logical description of our basic system is nearly complete. We just need to define the
transport information for the Addition operation by tying it to the AddNumbersPort. Double
click on the Addition operation, and take a look at the Message Exchange Pattern tab.
10. Look for the Transport property, and press the Browse… button next to it to select a transport.
11. In the dialog that appears, select the AddNumbersPort we created earlier. Press OK to return to
the properties of the Addition operation.
12. The Binding section of the dialog will now have been updated to point towards the
AddNumbersPort. A set of HTTP settings will also be available now that we have specified a
HTTP transport. We’ll come back to these settings later – for now, press OK to close the
properties dialog.
13. You should now be able to see the dependency between the operation and the infrastructure
component. Select the Addition operation by clicking on it, and you should see a purple arrow
going from the operation to AddNumbersPort. This indicates that the Addition operation is
dependent on AddNumbersPort.

14. Try navigating around the logical view using the following controls:
o To navigate around the logical view you can use the horizontal and vertical scrollbars, or
press the Pan button and left click on the screen to drag it around.
o To adjust the zoom level you can use either the zoom buttons or hold down the
Ctrl key and use the mouse wheel.
o To move any of the services or components around, ensure the Select Cursor button
is selected, and left click on the service or component you wish to move, and drag it to
the desired location.
o If you ever want to reset the layout of the services and components, then the Layout All
Nodes button will organize them into an efficient layout.
o To set the zoom level so that the entire diagram fits inside the screen, use the Fit to
Contents button .

5.5 Physical View
On its own, the logical view that we’ve created is not enough to fully describe our system. As
mentioned previously, it doesn’t contain information about the address of the server we’re talking to,



or any connection settings that may be required. We’re going to specify this information separately, in
the Physical View.
This view displays available physical resources and their location within the enterprise. Each resource
listed within the Physical View represents a single configuration of an infrastructure component
described in the Logical View.
Resources in this view are organized by subnet and host. If a resource is not associated with a subnet
or host, it will be displayed under Unconnected Resources. We’re going to create the physical
resource for the AddNumbers web service – a simple web server.

5.6 Exercise: Setting up Physical View for a Simple System
1. Switch to Physical View using the tab at the bottom of the screen.
2. We’re going to add a new resource here. Along the top of the perspective, you’ll see a toolbar
containing options for adding new resources from different categories

3. Choose the Web category, and then choose the Web Server option .
4. The New Web Server dialog will appear. Set the Host setting to localhost using Port 8088.
5. Press Test Transport to make sure that you are able to connect properly to the web service.
Once you are satisfied that it is working properly, press OK to close the dialog and save the new
resource.

5.7 Environments
Once we have the logical data, which gives us an abstract model of what infrastructure is required by
our system, and the physical data, which specifies the different configurations available for each
infrastructure component, we then need to match these up. Remembering that this could change
between different stages of the lifecycle of the project, we can use a set of environments to coordinate
this process.
A new project starts without an environment, so we’ll create an initial environment in this exercise.
Other environments could be created subsequently as required. These will allow us to keep using the
same test resources, simply by switching to new environments as they become available.
Environments do not have their own view; instead, there are a number of options in the Project menu
which allow us to access and edit an environment: Create New Environment , Edit Environments
, and Switch to Environment . If you are using the default settings within Rational Integration
Tester, the Title Bar will also show the name of the current environment.

5.8 Exercise: Creating an Environment
1. Select Project > Create New Environment
2. Give the environment a name – for example, Local (most of the environment we’re working
with in this training course will be on the local host).



3. The Environments window will appear. On the left hand side, you can select the environment
to edit. On the right hand side, you can see how this environment is configured.
4. On the right hand side, you should be looking at the Properties tab, which will be empty at the
moment. The properties of an environment are expressed as tags, which will be covered later in
the course. For the moment, we’re not going to need to set up any properties ourselves.
5. Switch to the Bindings tab. You should see the AddNumbersPort listed here. Note that the
physical connection for it is currently listed as UNBOUND.
6. Click on the UNBOUND setting, and a drop down box should appear, containing the option to bind
the AddNumbersPort to the HTTP Client at localhost. Select the new physical resource to tell
Rational Integration Tester that any messages sent to the AddNumbersPort will be sent to
localhost.

7. Press OK to save your changes and exit the dialog. You should see that the environment name is
now displayed in the Title Bar.

Once an environment has been created, we can also view and edit environmental data directly from
the Logical View. To do this, you can right click on an infrastructure component in Logical View, and
select either Physical Resource, which will show the related physical resource in the current
environment, or select Set Binding In..., which will allow you to set the binding in any environment.
This information can also be seen by opening the infrastructure component by double clicking on it,
and going to the Bindings tab.

5.9 Exercise: Schema Library
We now have most of the information we would need to create a test or stub for this sample web
service. However, we’re still missing information about the format of the messages going to and from
the web service. Most of this information can be provided through the Schema Library.
1. Switch to the Schema Library using the tab at the bottom of the screen.



2. At the top of the perspective, there is a toolbar containing buttons for importing different types
of message schemas. Press the WSDL button. The New
WSDL window will appear.
3. Press Change… to enter the location of our schema definition. The Select Location dialog box
will appear.
4. Select the URL tab, and enter the following URL:
http://localhost:8088/addNumbers?wsdl – note that the URL is case‐sensitive. Press OK
to close the Select Location dialog, and again to close the New WSDL dialog.
5. You can also view the schema information used by the addNumbers service by going to the
same URL with your web browser.
6. Once the schemas have been imported, you can then view them in Rational Integration Tester.
Select WSDLs on the far left of the screen. You will then be able to see the addNumbers WSDL
displayed on the left hand side. Select this WSDL; the details of the schema should then be
shown on the right hand side. The Source tab will give the same schema information we saw in
our web browser.

Note: If you have mistyped the name of the WSDL, you should receive a warning, and the right
hand side of the screen will not show the message schemas. If you end up in this situation, you
can fix it in the following manner:
Amend the location of the WSDL by using the Change… button next to the WSDL Location at the
top of the screen. Following that, press the Rebuild button to rebuild the schema data.



7. Go to the Config tab to view each individual message type. You can select each message type
using the Operation drop down just under the tabs along the top of the screen. Use this to view
the three message types: addition__INPUT__addition,
addition__OUTPUT__additionResponse, and addition__FAULT__AdditionException.

5.10 Exercise: The Message Exchange Pattern (MEP)
The final stage of building our system model is to state how the operations will make use of the
message schemas that have been provided. We will do this by building up the Message Exchange
Pattern, or MEP, for each operation. The MEP contains information about the input and output
schemas for the operation, whether the messaging pattern is Request/Reply or Publish/Subscribe, and
how the messages will be sent. In order to create a dependency in the Logical View, we have already
set up the transport, stating how messages will be sent to and from our service. To complete the model
of the system under test, we still need to set the rest of the properties of the MEP.
As we will see later on, setting up the MEP correctly now will allow Rational Integration Tester to aid
us in automatically creating resources for each operation.
1. Return to the Logical View.
2. Double click on the Addition operation to edit it.
3. On the Message Exchange Pattern tab, make sure that the Pattern is set to Request/Reply.
4. We now need to select the message formats for the request and the reply. On the Request line,
press the Browse… button to select a message format.
5. The Select Schema dialog will appear. It is formatted in much the same way as the Schema
Library. Find and select the addition__INPUT__addition schema, then press Finish.
6. Do the same for the Reply message, selecting the addition__OUTPUT__additionResponse
schema.
7. You will also see tabs towards the bottom of the screen for HTTP Properties and HTTP
Headers. Under the HTTP Properties tab, set the Resource Name to /addNumbers .



8. Press OK to close the Addition operation.
We now have all the information we might need to work with a very simple web service. For more
complex systems, it would be preferable to analyze the system to derive some or all of this information
automatically. We can do this in two ways, depending on the technologies involved – by synchronizing
with the system, or by building a model of the system from recorded events.



6 The Demonstration Environment
Obviously, there is only so much we can do with a simple demo environment like addNumbers. The
Rational Integration Tester training courses use a more complex example, the Worldwide Travel
system. Your instructor may choose to use some or all of these sections during your training course.
So before we can go any further, we need to know how this example system under test fits together.
There are three main sections to the system that we’ll be dealing with: a flight booking system, a hotel
booking system, and a flight administration system.
All three parts of the system are presented to the user through their web browser; the interface is
generated by a Tomcat web server, which connects to the relevant parts of the system as required. In
the background, the following software has been deployed:
 Tomcat 7.0.26
 IBM WebSphere Application Server 8.
 IBM WebSphere MQ 7.
 IBM DB2 9.7 Express Edition.

6.1 Managing Flight Bookings
The Worldwide Travel system lets users book a flight on the fictional airline, Worldwide. Bookings can
also be managed through the interface, allowing users to find, update, and delete existing bookings.
The implementation for this is split into two parts – the set of services for making bookings, and the set
of services for managing bookings.

When a user makes a booking, Tomcat publishes a message onto a MQ queue, which is then retrieved
by the MakeBooking service running in WebSphere Application Server. This looks at the credit card
type, and posts a message onto a queue for that card type (Global, Multinational, or Worldwide). A
service for that card type, also running on WebSphere Application Server, will then pick up the
message, and process it. In order to process the booking, the service needs to know what reservation
numbers exist, create a new reservation number, and record it for future reference. All of this is done
by referring to a DB2 database which is used to hold booking information. The reservation number is
then passed back to MakeBooking, to Tomcat, and then the user.



When a user wants to manage a booking, Tomcat will be interacting with a set of web services
implemented by WebSphere Application Server. These services will allow the user to log into the
booking system, search existing bookings, update bookings, or delete them. Searching, updating, and
deleting will access the same database that was used previously for making bookings.

6.2 Finding and Booking Hotels
Following a flight booking, a user may require a hotel in that destination. The HotelFinder web service
allows the user to look up a list of hotels that are available in a particular city between a given pair of
dates. Tomcat can then provide this list to the user. The HotelFinder web service is hosted by Tomcat
itself, rather than running on WebSphere Application Server.

6.3 Flight Administration
On the day of a flight, users from the airline will need to check in passengers. The administration
services allow the user to first search through a list of flights, select a flight, and then select particular
booking on that flight. This is all done by Tomcat, directly accessing the DB2 database used when
creating and managing bookings.
When a passenger is checked in, the airline user will need to check their passport, and update records
accordingly. To do this once a booking has been selected, a message is posted to an MQ queue in
COBOL Copybook format. It is picked up by the flight confirmation service (running as its own
process), which then posts a reply back, also in Copybook format. Tomcat then uses the information in
this reply message to update the database.



7 Using System Data to Build a System Model
7.1 Overview
Obviously, if we wanted to build a larger system such as Worldwide Travel within Rational Integration
Tester by hand, as we did for addNumbers, it would take some time. Instead, depending on the
technologies in use within the system under test, there are two methods of automatically generating a
system model. We can either synchronize our system model with the system under test, or we may
record events within the system, and use these recorded events to build a system model.

7.2 Synchronisation Overview
The simpler option when building a model of the system under test is synchronisation. This process
analyses the services and infrastructure provided by the system, and replicates that within the
Architecture School. This will set up the logical and physical views, an environment, and any message
schemas used by the various services in the system.
In order to do this, Rational Integration Tester requires a valid synchronisation source to exist within
the system under test, so that it can request information on the system. Supported synchronisation
sources include:
 WSDL
 webMethods Integration Server
 TIBCO BusinessWorks Project/Design Time Library
 SAP System
 Oracle SCA Domain
Adding any of these to your project will give you the option to synchronise with the data held by that
external resource. To start the synchronization process, you can add any one of these infrastructure
components to the Logical View of Architecture School, or by switching to Synchronisation view and
adding it there. Either way, the process of adding a synchronization source will provide the option of
synchronising. Multiple synchronisation sources may be added to the project if required.

Post‐synchronisation, the system under test may change; as this will be recorded within the
synchronisation source, it is possible for Rational Integration Tester to update the project to reflect
these changes. To do this within the Synchronisation view, first press Check Synchronisation – this
will compare the system model within the Rational Integration Tester project against any
synchronisation sources, and display any differences between these. Following on from that, you can
press the Synchronise button, which will then update the Rational Integration Tester project to
resolve these differences.



7.3 Building a Model from Recorded Events
As you can see, while Rational Integration Tester supports a number of synchronization sources, not
all of these will exist in every system. If a system does not have any of the synchronization sources
mentioned above, then there is nothing to refer to when building a model of a system under test – for
example, a JMS‐based system may be able to provide information on the available queues and topics,
but it will not provide any information on the operations that access those resources, the dependencies
between operations, or the message schemas being used. In this case, we may be able to build a model
of the system from recorded data.
This is exactly the sort of situation we’re in with a system based around MQ and WebSphere
Application Server. We don’t have a single source of data that will provide us with information about
the system. Instead, we’ll record data from the transport to build the system. For the moment, we’ll set
up the transport, and import the necessary message schemas. When we move to the Recording Studio
perspective, we’ll record a set of events, and use this information to create a set of operations.

7.4 Recording MQ Messages
There are several different ways to record messages over the MQ transport – each has their own
advantages and disadvantages. The choices are as follows:
 Queue Browsing
 Proxy Queues
 Mirror Queues
 Dynamic Mirror Queues
 Queue Aliasing
Your choice will depend on several factors. Some methods, such as the use of proxy queues, require
changes to the system under test. Others are invisible to the system under test, but require access to
the MQ server in order to make modifications. Other factors will include determining if the system
under can be stopped temporarily, to ensure that no messages are missed, and connections can be set
up appropriately; and finally, the amount of effort required on the part of the user, and the impact on
the performance of the MQ server. For more information on the pros and cons of each method, please
refer to the Recording Settings section of the document rit_wmq_ref.pdf. In our example, we will be
using dynamic mirror queues, as this requires no modification to the system under test, and requires a
very small amount of setup on the part of the user
Regardless of the method that you have chosen, the recording setup should look quite similar to the
following:



The client application will communicate via request and reply queues with a given service. Rational
Integration Tester will read the request and response messages being posted to the queues within the
queue manager. While the queue manager may act slightly differently to its usual behavior – for
example, by copying each message to a mirror queue – the messages themselves will be untouched,
and the actions of the system under test should also be unchanged.
Note that we may choose to record just a given service, if we have an operation definition (and so
know which queues to monitor), or we may record all queues within the queue manager by recording
the MQ transport.

7.5 Exercise: Setting up the Transports
In order to record information about the system, we first need to provide some basic information
about the infrastructure of that system. We’ll build this in the Architecture School, in the same way
that we built the addNumbers system previously. It will be very simple at this stage – just a service
component and a few infrastructure components. We’ll then import some message schemas that we
can use within our operations later on.
1. Return to the Logical View of Architecture School, and create a new Service Component. Call
the new service component WWTravel.
2. Right click on the WWTravel service component, and select New > IBM > IBM WebSphere MQ
Queue Manager. Call it WWTravel_MQ.
3. As before, we’ll need to add a physical infrastructure component. We could do this by going to
the Physical View and creating one there, but we’ll take a different approach this time, which
will allow us to create the environmental binding at the same time. Right click on the
WWTravel_MQ infrastructure component, then choose Set Binding In > Local > Create New IBM
WebSphere Queue Manager.



4. As we’re using an MQ server on the local machine, enter localhost as the host. The port should
be 1414.
5. We then need to set up the Channel and Queue Manager. Set the Channel to wwtravelwebapp
and the Queue Manager to QM_wwtravel The settings for the transport should be as follows:

6. Press Test Transport to make sure everything is set up correctly so far. After Rational
Integration Tester has reported that it has successfully connected to the MQ server, which may
take a moment, switch to the Recording tab.



7. Under Queue Recording, set the Recording Mode to Dynamic Mirror Queues. All other
settings here can be left at their defaults.
8. Finally, switch to the Advanced tab. Here, set the number of QM Connections to 5. This will
allow us to manage more connections with the queue manager, in case we may be working on
multiple tasks at the same time (e.g., recording and stubbing).



9. Press OK to close the properties for the MQ Queue Manager.
10. As our services will be running on the Websphere Application Server, we’ll want to model that,
too. Also within the WWTravel service component, add a New > IBM > IBM Websphere
Application Server, and call it WWTravel_WAS.
11. As with the MQ Queue Manager, right click on WWTravel_WAS, and select Set Binding In > Local
> Create New IBM WebSphere Application Server.
12. Enter localhost as the Hostname, and 2809 for the Bootstrap Port. Press OK to close the
properties of the WebSphere Application Server.



13. Finally, we’ll add the booking database that will be used by several of the services in our system.
Again within the WWTravel service component, right click and select New > General >
Database Server. Call it WWTravel_DB.
14. Again, right click on the database, and select Set Binding In > Local > Create New Database.
15. We can now enter the physical properties for our database. First, we’ll need to select the Driver
– in this case, we’re using a DB2 database, so select the IBM DB2 (Universal) driver.
16. As for the other settings, the Maximum Number of Connections should be set to 1, the
Database URL should be jdbc:db2://localhost:50001/WWTRAVEL, the User Name
traveluser, and the Password Pi‐Ev‐G7, as seen below:

17. Press Test Connection to make sure that the database connection is up and running, then press
OK to close the dialog box.
18. Your Logical View should now show the WWTravel service component like so (in addition to the
AddNumbers service component created earlier):

19. Finally, open up the Environment Editor using Project > Edit Environments, and verify that all
of the logical and physical components have been bound correctly.



We have now modeled the basic infrastructure of the Worldwide Travel system. From this point, we
could move directly to recording events from the system, and modeling the operations from that. We’ll
make this a bit easier by importing some message schemas before we begin recording.

7.6 Exercise: Adding the Flight Booking Message Schemas
1. Return to the Schema Library. Here, we need to add three new XML schemas, so press the XSDs
button on the left hand side of the screen to show any available XSDs –
none should be shown at the moment.
2. We could use the XSD button in the Schema Library toolbar to add new XSDs to the project,
as we did with the addNumbers WSDL. However, as we’ve got a group of files, we’ll just drag
and drop them into the schema library. Find the XSD Schemas folder on your desktop, and drag
and drop it into the center panel of the Schema Library.
3. Rational Integration Tester should now show three new XSDs – BookFlightRequest,
BookFlightResponse, and Payment.

4. You can select each of these, and view the associated message schemas on the right hand side of
the screen.



8 Recording Events
8.1 The Recording Studio
Rational Integration Tester and the agents provide us with the capability to record events (messages
or database interactions) from the system under test. The Recording Studio allows us to control what
parts of the system we wish to record, whether it might be specific parts of the system infrastructure,
or specific services using that infrastructure. We do this by setting up Event Monitors that specify what
we wish to record.
Once we have decided what to record, we can then begin recording. As events are recorded, they are
displayed within the Events View. If desired, Event Monitors can be added or removed as we record.
We can also filter what events are shown in the Events View by selecting different monitors within the
Event Monitors panel. As events of interest are recorded, we can view more details for these events by
selecting them within the Events View – further details will then appear in the Event Details panel
below.

It is important to note that recording these events does not interfere with the operation of the system
under test. Events will still be dealt with in the same way that they usually would be – the only
difference is that those events will be accessible through Rational Integration Tester.



Following recording, events may be re‐used in a variety of ways. The simplest thing we can do is
export the recorded events to disk, so that they may be imported back into the Recording Studio at
another point in time. Otherwise, events can be used to build:
 Operations
 Triggers
 Requirements
 Data Sets
 Tests
 Stubs
If we do not have a complete model of the system under test, then events recorded from the transports
within the system may be used as a basis for building new operations within our system model.
Events may be re‐used in the form of Triggers; a trigger allows us to stimulate the system under test
directly from Rational Integration Tester. We can then record what happens in response – note that
this will not necessarily be the same as what happened when we originally created the trigger, and we
will not be performing any validation on any events recorded in response to the trigger. This means
that we can send events to the system without going through the GUI layer (or any other layer of the
system that we might prefer to bypass), allowing us to understand how the system reacts to various
inputs.
In other cases, we may wish to save a message for later on, without specifying how it will be used. It
may be saved in the form of a Requirement, giving us an example message that we can view in the
Requirements Library. Those requirements may later be imported into other resources.
We can also use recorded groups of events to create tests or stubs. The data within the events may be
hard‐coded into the test or stub; it may also be entered into a data set such as a CSV file, or a data
model, which maps the relationships between the data in the system.

8.2 Exercise: Recording Events from a Transport
We will now capture events for the MQ Queue Manager transport.
1. Before we get started, we will need to initialize a few components of the system, such as the GUI
layer, to make sure that they are running. To do this, use the Start WWTravel.bat shortcut on
your desktop.
2. Once this has completed (it will only take a few seconds), return to Rational Integration Tester,
and go to the Logical View of Architecture School.
3. Make sure you are in the Local environment (as shown in the Rational Integration Tester title
bar).
4. Select the WWTravel_MQ infrastructure component.
5. Right click on the WWTravel_MQ component, and select Record. The perspective will change to
the Recording Studio, and the WWTravel_MQ transport should be listed in the Event Monitors.
6. Click the Start Recording button in the Events View toolbar to start recording events.



7. In a browser window, open the Worldwide Travel booking site. For a cloud image, this will be
listed in the bookmarks menu of your web browser; otherwise, ask your trainer.

8. Click on the “Stansted to Barcelona” Book Now button. Here, you will have the opportunity to
book a flight and a hotel. For the moment, we’ll only worry about flights, so skip the hotel data
at the top of the form, and just enter passenger and payment details for a flight. Make sure that
you select Multinational as the credit card – the other details do not matter, as long as they are
filled in.
9. Click Proceed when finished and you should see a confirmation page with a reservation
number.



10. Return to Rational Integration Tester and you should see that 4 events have been recorded in
the Events View.
11. Click on the first message in the Events View. You should then see the message details appear
in the panel below, showing the message that was initially sent by Tomcat.
12. We still need information on how the system deals with requests for other credit card types, as
these will be posted to different queues, so return to your web browser, and make bookings for
Global and Worldwide credit cards. These should also be recorded in Rational Integration
Tester, giving you a total of 12 recorded events.

8.3 Exercise: Building Operations from Recorded Events
Now that we have recorded some events, we can use these for a number of different purposes. The first
thing we’ll do is to complete the model of the system.
1. Take a look at your set of recorded messages, in particular the description fields. There should
be 12 messages, and the descriptions will list the queues that were used while recording. This
should include wwtravel.booking, wwtravel.payment.multinational,
wwtravel.payment.global, wwtravel.payment.worldwide, along with their respective reply
queues. If you are missing any of the different credit card queues, go back and record a booking
using that particular type of card.
2. Pause the recording by pressing the Pause button.
3. Select all 12 messages, before pressing the Save button.



4. The Recorded Events wizard will appear, allowing us to choose what we will do with the
selected events. To build a model of the system under test, we need to create some operations,
so select that option, then press Next.

5. Rational Integration Tester will now display the 12 recorded messages, attempting to separate
them into distinct operations. It should look something like the following:



6. As the operation names are generated from the queue names used, we might like to change
them to something more useful. Select the first message belonging to the operation that is
currently named wwtravel.booking – wwtravel.booking.reply.
7. You will now be able to enter a new name below, so enter MakeBooking, and press Rename. You
will be asked if you want to apply this change to all other messages that were associated with
the same operation – answer Yes. You should then see the Operation column update
accordingly.



8. Next, we will add the message schemas for MakeBooking. To do this, select one of the request
messages for MakeBooking on the left hand side of the dialog (it will contain all of the data you
entered into the web form earlier). On the right hand side, select the second line of the message,
beginning text (String).

9. The Add Schema button should now be active. Press it, and the Select Schema dialog will
appear. On the left hand side, select XSDs, then the BookFlightRequest XSD. Press Finish to
apply the schema to this message. You should then see the namespace update within all fields of
the message:



10. Now select a response message for MakeBooking, and follow the same procedure, using the
BookFlightResponse XSD.
11. We’ll need to go through the same process for the other operations in our system. Select the two
messages that are associated with the wwtravel.payment.multinational queue, give them an
operation name of ProcessMultinational, and press Rename.
12. We also need to set up message schemas for ProcessMultinational, but this will be a little bit
simpler than for MakeBooking. If you take a look at the response message, you’ll see that it only
includes a single text field, so we won’t need to apply a schema there. Select the request
message for the ProcessMultinational operation, and apply the Payment XSD as the schema.
13. You can set up the last two operations for Global and Worldwide cards in exactly the same way
– call them ProcessGlobal and ProcessWorldwide; you can use the same message schemas as
for ProcessMultinational. Once you’re done, the dialog should look like the following:

14. Press Next. You will then be able to select where in the model of the system these operations
should be created. By default, WWTravel should be listed as the parent service component for all
of the operations we’re creating, as it is the parent service component for the infrastructure we
recorded earlier. As this is suitable, press Next.



15. You’ll now see a summary, letting you know that Rational Integration Tester will be creating 4
operations for you. Make sure that Open resource after finish is unchecked, then press Finish
to create all 4 operations. You can now switch back to the Architecture School to see what has
been created.

16. In the Logical View, you can now double click on each operation to view its properties. Do this
for one of the operations you created, and view the Message Exchange Pattern tab. This
should show you the message schemas you set earlier for request and reply messages; it should



also show you the transport information used by that operation, including the names of the
queues that it uses.

8.4 Exercise: Completing the System Model
1. Within the Logical View of Architecture School, we now need to add some extra dependency
information to give ourselves a complete system model. Firstly, the MakeBooking operation
should have a dependency on each of the credit card processing operations. For example, to add
a dependency from MakeBooking to ProcessMultinational, select the Add Dependency
button from the toolbar, click on the MakeBooking operation, and then on the
ProcessMultinational operation.
2. Follow the same process to create dependencies from MakeBooking to ProcessWorldwide and
ProcessGlobal.
3. Next, each of the credit card processing operations have dependencies on the WWTravel
database. Add a dependency from ProcessMultinational to the WWTravel_DB component in the
same way, and then do the same for ProcessGlobal and ProcessWorldwide.
4. Last, all of the operations are running on our WebSphere Application Server, so add a
dependency from each operation to the WWTravel_WAS component.
5. Note that dependencies only appear for items you have selected. However, you might notice
that if you select MakeBooking, for example, a lot of dependencies will be displayed, making the
diagram difficult to read. This is because default settings will display the dependencies all the
way through – if you just want to see a single level of dependencies, you can go to Project >
Preferences, and in the General panel, set Max dependencies shown to 1, then press OK. The
diagram should then become easier to read.



8.5 Exercise: Recording Events from an Operation
Now that we have a model of the system, we can choose to record events for particular operations,
rather than recording everything in the system. As we now have multiple sources of events, we can
also choose to filter events by source.
We will capture booking events again, but this time we will be recording events based on operations
rather than transports. We will see how we can filter these events. Later, we will see how we can re‐
use these events to build other resources within Rational Integration Tester.
1. Return to the Recording Studio perspective, and find the Event Monitors panel. This should
currently show that we are monitoring the WWTravel_MQ transport. We’ll stop monitoring this
for the moment, so select it, and press the Delete Event Monitor button to remove the event
monitor.
2. We’ll also clear the events we recorded in the previous exercise. To do this, press the Clear All
Events button in the Events View toolbar.
3. Press the Add Event Monitor button; this will allow us to select an operation to record.
Choose the MakeBooking operation we created in the previous exercise.

4. You will now be given the option to choose to record any of the dependencies of the
MakeBooking operation at the same time. You should see that the WWTravel_MQ transport is
available, as are the other three operations. This is because the default behaviour is to show
only items that MakeBooking has a direct dependency on (the WWTravel_WAS component is not
shown, as Rational Integration Tester cannot record directly from the WebSphere Application
Server). Switch the radio button at the top of the dialog from Direct Only to Indirect Only, and
you should see the WWTravel_DB component become available, while the other dependencies
are hidden; MakeBooking only has a dependency on WWTravel_DB through the other operations
in the project, rather than having a direct connection to it. Finally, switch to Both, and you
should see all recordable components that MakeBooking has a dependency upon.
5. Select the ProcessMultinational, ProcessWorldwide, and ProcessGlobal operations. Note
that if there were other operations had dependencies on the MakeBooking operation, we could
select those on the Parent References tab; as nothing depends on MakeBooking in our system,
this will not be necessary. Press OK to continue.



6. All 4 operations created in the previous exercise should now be listed in the Event Monitors
panel. If any of them are not listed, return to step 2, and add any missing operations.

7. Press the Start Recording button.
8. Switch to your web browser and submit another booking request, using a Multinational credit
card.
9. Return to Rational Integration Tester, where you should see 4 events recorded in the Events
View – 2 each for MakeBooking and ProcessMultinational.
10. You can filter recorded events to show only those events that were recorded for a given event
monitor by selecting the event monitor in the Event Monitors panel. For example, click on the
MakeBooking event monitor. You should now see just the MakeBooking events, with the events
recorded for ProcessMultinational filtered out.
11. Click in the empty space below the list of event monitors to clear the filter – you should see all 4
events again.
12. Record 2 new bookings, again using the Global and Worldwide options. You should now have 12
messages in total.



13. Again, you’ll be able to filter by source. Note that you can select multiple event monitors at the
same time when filtering, to show messages from multiple operations.



9 Creating and Executing a Basic Stub
We’re now ready to create our first virtualized service. For the moment, we just want to create the
simplest sort of stub possible – one that always returns the same response. It won’t do any
calculations, make any decisions, or lookup any data. We will look at stubs that carry out more complex
operations later on.
To this end, we will take a pair of messages recorded for MakeBooking, and create a simple stub. This
stub will always return the same reservation number, no matter what the request.
In order to do this, we’ll use the Save Recorded Messages wizard again. We’ll also see the stub editor
for the first time – for the moment, we’ll simply edit the message filtering to tell the stub to respond to
any message with the same structure, without worrying too much about the contents of the fields.
We’ll be returning to the stub editor later on, and looking at it in more depth.
We’ll then execute a stub from Rational Integration Tester, using the Test Lab perspective. Finally,
we’ll make a minor modification to the message that the stub will send, and see how Rational
Integration Tester will automatically replace a stub that is currently executing.

9.1 Exercise: Making a simple stub from recorded messages
1. Click on MakeBooking in the Event Monitors to filter out any messages from other sources.
2. Select a request message and the corresponding reply message in the Events View.
3. Press the Save button. This time, we will not be creating any operations – instead, we will
create a stub, so select stubs on the first page of the wizard, and press Next.
4. On the second page of the wizard, we have the option of creating several different types of stub.
As this first stub will be pretty simple, we’ll choose to Store data as hard coded values. Press
Next once you’ve done this.
5. The next page of the wizard simply asks for verification that all events have been sorted by the
correct operation. As we have already filtered messages by the MakeBooking operation, this
should show two messages from that operation. If so, press Next.
6. On the following page, the messages have been grouped into transactions. As there is only a
single pair of messages for the moment, these should both be listed as a single transaction.



7. On the final page, you will be able to specify a name for the stub. Set this to SimpleBookingStub,
and make sure that Open resource after finish is checked.
8. Press Finish to create the stub. Rational Integration Tester should then switch to the Test
Factory perspective.
9. We can now take a look at the stub we’ve created. In the Transitions section, we have a list of
the events that the stub will respond to. The stub we have created only knows how to respond
to events for MakeBooking.

10. Below this, we can see the messages we recorded previously, in the Input and Output tabs.
11. By default, the stub will attempt to filter out anything that doesn’t exactly match the default
message that we received. In those cases, it will not send a response message. For our example,
we’d like to respond to anything that matches the same message structure; it may or may not
have the same values within the message fields. This will make our stub a bit more versatile. To
get started, switch to the Input tab, and take a look at the message body. You will see that each
field has a small filter icon next to it:



12. We want to switch off any filtering that is checking for an exact field match. The Does Exist
filters won’t matter, as long as the basic message structure is the same. To do switch off filtering
for the exact matches, select all of the fields within the message (you may need to scroll down to
do this). With everything selected, right click and choose Contents > Field Actions > Filter >
Equality. This will toggle the equality checks off, and the message body should then appear
with fewer filter icons, like so:

13. Switch to the Output tab, and take note of the reservation number that will be sent by the stub.
You should see this again in the following exercise.
14. Save your stub – it’s now ready to be executed.



9.2 Exercise: Executing a stub from Rational Integration Tester
1. Before we start using our stub, let’s switch off the service in WebSphere Application Server, so
we’re certain that it is not processing any messages, but instead leaving them for the stub. To do
this, open up your web browser, and follow the link in your bookmarks to the Websphere
Integrated Solutions Console. When asked for login details, leave them blank, and press the Log
In button.
2. In the left hand pane select Applications>Application Types>Websphere Enterprise
Applications.
3. The list of applications that we’re using within WebSphere Application Server will then appear
on the right hand side. Check the box for com.wwtravel.booking.app – this handles booking
requests for us.
4. Above the list of applications, there is a Stop button. You can now press this to stop the booking
application – note that this will take a moment. You should then see that the application has
stopped successfully.

5. Return to Rational Integration Tester, and switch to the Test Lab perspective.
6. You’ll still see your stub in the tree on the left hand side of the screen. Run the stub, either by
double clicking on it, or by selecting it and pressing the Run button.
7. The stub will then appear in the Task Monitor. Some initial details will appear down below, in
the Console. This will be updated later on, as the stub receives incoming messages, and
responds to them.
8. As it stands, the stub will now wait until it receives some input, so let’s provide something for it
to work with. Return to your web browser, and make a new booking.
9. In the Test Lab of Rational Integration Tester, take a look at the console output for your stub.
You should now see that the stub has received a message, and sent a reply.



10. If you make another booking in your web browser, you should see that you are receiving the
same booking number every time. As we turned off the filtering of messages within the stub, it
shouldn’t make any difference what booking request we send to the stub; we just need to be
using the same message structure.

9.3 Exercise: Modifying the stub on the fly
A stub can be modified as it is being executed. Simply make your modifications, save the stub, and
Rational Integration Tester will automatically shut down the old version of the stub, and start up the
new version. As a simple example, we’ll now update our stub to send a different reservation number to
the user.
1. Within Rational Integration Tester, return to the Test Factory perspective.
2. Edit the SimpleBookingStub, and go to the Output tab.
3. Change the reservation number to something different – for example, A01234.
4. Save the stub. Rational Integration Tester will offer to update the running stub. Choose Yes.

5. Switch to the Test Lab perspective.
6. You should see in the Task Monitor that the stub has automatically been stopped, and started
again:

7. Make another booking in your web browser – it should now give you the new reservation
number you have entered.



8. As we’re now finished using this stub, we’ll switch back to the live system. Within the Test Lab
of Rational Integration Tester, select the currently running version of the stub in the Task
Monitor (it will be the one with a Status of Ready).
9. The Stop button in the Task Monitor toolbar will now be available – press it to stop the
stub.
10. We’ll now want to restart the booking service on WebSphere Application Server, so return to
your web browser, and go back to the console interface. If you closed the browser previously,
navigate back to the list of applications again.
11. Select the com.wwtravel.booking.app application by checking the box next to its name, and
Start it. All services should be running, as shown below:

12. If you make any further bookings, you should now notice that you are receiving new
reservation numbers again each time you make a request.



10 Publishing and Deploying Stubs
So far, the stubs that we’ve created have been located on our personal machines, using our own license
for Rational Integration Tester. This has a number of limitations – the owner of the machine is the only
person with control over the stub, and it cannot be used by other people. Other team members also
have very limited visibility over which stubs are currently in use, and which stubs are not. In addition,
stubs inside Rational Integration Tester may only run for a period of 5 minutes outside of a scenario in
a test suite.
In order to make our stubs more useful, we’ll publish them to RTCP. This makes the stubs available to
other team members, and also provides monitoring, versioning, and other technical capabilities.
We’ll first look at how we can publish stubs to the server, and deploy those stubs. We’ll then look at
how we can make use of some of the more advanced features of the server, such as managing multiple
versions of the same stub, and providing input data to stubs as required.

10.1 Exercise: Using RTCP
1. Before we publish or deploy any stubs, let’s take a look at the RTCP interface. To do this, open a
new tab in your web browser, and go to the RTCP bookmark. If asked for a login and password,
enter admin for both.

2. Once you’re logged in, you’ll be presented with 5 options – Scheduling, Agents, Results, VIE,
and Administration. We’ll be looking at some of these as we go through the different
publishing and deployment options that are available for the stubs that we have created. We’ll
start by looking at the Agents, so click on that option.



3. You should now be able to see the different types of available agents available through this
server. Some of these will be particular types of proxies that we’ll be using later in the course,
and a single one will be listed as an Engine. Agents that are providing engines – there may be
more than one – allow us to deploy stubs onto those engines, which will then run the stubs as
we were previously doing through Rational Integration Tester. Click on the magnifying glass for
the Agent that is providing an Engine.

4. We can now see where the engine is running, along with status information. Currently, this
should tell you that the engine is not running any stubs. Press the Close button.
5. For the moment, there is nothing else for us to do until we have published a stub to the server,
so minimize your web browser, and return to Rational Integration Tester.

10.2 Exercise: Publishing a Stub
1. In order to make a stub available to the server, we need to publish it from Rational Integration
Tester. To get ourselves started, we’ll publish the stub we created for the MakeBooking
operation. Within Rational Integration Tester, switch to the Test Factory perspective.
2. Right click on the MakeBooking operation, and select Publish Stubs… Note that this process
will publish all stubs that have been created for the operation. In our case, we’ve only created a
single stub so far.

3. A dialog will appear, letting us select a Version, Domain, and Environment for the stubs. You
will also see the server, pointing at the localhost – this has all been taken from our project
settings, so we can leave it all as‐is.
4. As this is our first publication, leave the Version as 1.0. You can manually set the version of
stubs as you publish them. Older versions of stubs will remain available on the server, so you
can easily backtrack to a particular version of the stub if required.
5. The Domain should be set to Booking System – below that, we can select which of the
environments used in our project should be used. We’ll use the Local environment that we



created at the beginning of the course. If we had created multiple environments within our
project, we could select which environments the stub should be available in.
6. Press Publish. Rational Integration Tester will then tell you that your stubs have been
published to the server.

10.3 Exercise: Deploying a stub
We’ll now check that our stub has been successfully published to the server, and deploy it onto an
agent.
1. Switch back to your web browser, and view the RTCP dashboard. If we want to view the
available stubs, we’ll need to follow the VIE link along the top of the dashboard, so click on that.
2. You should then see the available domains on the left hand side. Select the Booking System
domain, and a list of environments that can provide stubs for that domain will appear.

3. Choose the Local environment, then press View Dashboard to see more information.

4. You will now see a list of all of the parts of the system that may have stubs – at the moment, no
stubs should be running, and all requirements should be satisfied by the live system. You will
also notice that each row will either have a grey plus sign, or a green plus sign. A row with a
green plus sign indicates that a stub is available for that operation or component. Click on the
plus sign for the MakeBooking operation.



5. A dialog will appear, allowing you to select the stub to run, and to provide some configuration
options. For the moment, we’ll keep the configuration fairly simple. Select the
SimpleBookingStub.
6. You should then see information for each version that has been published – in our case, we’re
looking at the first version of our stub, so this is going to be pretty simple. We won’t be
worrying about most of the configuration options for this stub – we’ll cover configuration in
later examples – but we do need to make sure that we know where our stub will be running.
Click on the Agents link in the dialog to check this out.
7. If desired, you can now select which agents should run the stub. RTCP will choose one by
default, and since we only have a single agent in our training environment, this can be left alone
for now.
8. At the very bottom of the dialog, you can give this instance of the stub a label to identify it. Enter
FirstRun in here, and press Start Stub.
9. The dialog will close, and you will see that the MakeBooking operation is now satisfied by the
SimpleBookingStub. At first, the status will be listed as Deploying – wait for a moment, and
the status should update to Ready.
10. Switch back to the tab of your web browser that contains the booking interface, and make a
booking – you should receive the response that you coded into your stub earlier.
11. Back in the RTCP interface, Stop the stub, so that the live system will again be handling the
request messages.



11 Synchronization
11.1 A second test system – HotelFinder
We will now look a simulating a second part of our system, the HotelFinder search service. This is
implemented as a web service, so we have different options for recording and simulating this service.
In the provided interface, the HotelFinder service is provided as an option for users who have booked a
flight, giving them the ability to book a hotel at their chosen destination. The user supplies dates and a
destination; the search service then lets them know what hotels are available in that location, and
provides them with the ability to book one of those hotels for those dates. This may be done in parallel
with a flight booking, or subsequent to a booking.
The frontend, as with the flight booking service, has been implemented as a Tomcat web application,
while the backend is a simple web service. Currently, this service has only been implemented to the
point where it can respond with a small group of available hotels for Barcelona and Edinburgh. We will
use the virtualization capabilities of VIE to extend this, firstly editing the hotels presented to the user
within those cities, and then seeing how we can data drive a stub to allow us to present options from
other cities.

11.2 Synchronization
Before we can start simulating this service, we need to look at how we can get information about the
structure of the system we’re simulating. Previously, we recorded a transport, and modeled the system
based on the messages that we saw. We could do this for the HotelFinder web service as well –
Rational Integration Tester can record the HTTP transport, and then model web services based on that
data.
However, we can also use synchronization, as mentioned previously. This will allow us to interrogate
the WSDL provided by the web service, and automatically create a model of the system under test,
faster than we would have done it by hand, or from recorded messages. Some minor modifications may
still be required (for example, to present a database that is accessed by a web service, but not exposed
by the WSDL), but it will give us a fairly complete picture of the system with as little work as possible.

11.3 Exercise: Synchronizing with the HotelFinder WSDL
1. Within your web browser, you will have noticed a hotel booking option being displayed, with a
heading labeled Find a Hotel. Click this link, and you should see the WSDL for the HotelFinder
web service displayed on your screen. Skimming through the WSDL, you should be able to see
the schemas used by the web services described by the WSDL, along with the required
connection details.
2. We’ll import the WSDL into Rational Integration Tester. There are several ways to do this, but
in this case the easiest will be to simply copy the WSDL URL from our web browser. We can
then go to the Logical View of Architecture School, and paste it using Ctrl+V.
3. The Create a New External Resource dialog will appear, showing the Hotel Finder WSDL
listed for you. At this stage, we could add other WSDLs, but we’ll just stick with a single one for
this exercise.



4. Press Next to continue. You’ll be given the option to add the WSDL to one of the service
components created earlier, or to create a new service component. Choose to create a new
component called HotelFinder, and press Next.



5. The following screen will check which environment we will use when we create resources for
the HotelFinder services. We’ll keep using the Local environment we created earlier, so check
that this is selected, and press Next.



6. The final screen of the wizard lets us choose what to do once the WSDL has been added to our
project. Normally, we’d choose the last option – to synchronize without switching views, so we
can see what is created. For this example, though, we’ll go through the synchronization
manually, so select the second option, Open Synchronization View and let me choose which
items to synchronize.



7. Press Finish, and Rational Integration Tester will switch to the Synchronization View.
8. You should then see a short list of resources contained in the WSDL – the logical and physical
resources required for the HTTP connection, and the getHotels and bookHotel operations.
Press the Synchronize button in the toolbar to synchronize with the WSDL.

9. You should see the status of each item in the Synchronization View switch from No local copy
exists to In sync. If you now go through the Logical and Physical Views, along with the
environment, you should see that we now have a model describing the infrastructure of the
HotelFinder web services. Similarly, you will be able to see the message schemas used by this
service within the Schema Library.
10. In the Logical View of Architecture School, locate the getHotels operation – if you need to,
you can use Ctrl+F to find the operation. Once you have found it, double click it to open it.



11. Switch to the Message Exchange Pattern tab within the Properties window that appears. You
should see that this has been filled in for you already, letting us know that the getHotels
operation is Request/Reply, and specifying the request and reply messages, along with
transport information at the bottom of the window.

12. We don’t need to change any of this information, but the Message Exchange Pattern detailed
here – the MEP – will be important in the following exercise. Close the properties window.
13. Before we can use this information to create a stub, we’ll want to edit the physical properties of
the HTTP transport defined in the WSDL we synchronized with. As the web service described
in the WSDL is running on port 8089, a stub cannot run on the same port on the same machine.
We’ll provide a different port number, so switch to the Physical View to do this.
14. Open the HTTP resource for localhost:8089 by double clicking on it.
15. In the dialog that appears, switch to the Server tab.
16. Here, there is a setting in the Socket Server Overrides section labeled Port; this should be
blank by default, which tells Rational Integration Tester to use the same port as the normal
service. In most cases, this isn’t a problem, but when the stub and the live service are running
on the same machine, it will cause a problem, so set it to 8085.
17. Press the Test Transport button to verify that Rational Integration Tester can both talk to the
live service and listen on port 8085.
18. Press OK to close the dialog.



12 Creating a Stub from MEP
So far, we’ve considered stubs using the same messages that were provided when we recorded them.
In this chapter, we will look at manipulating the messages referenced within our stub. Firstly, we will
create a stub from scratch, without reference to recorded messages. We will then edit the reply
message by hand, including handling new requests and repeating elements within messages.

12.1 The Stub Editor
We’ve seen the stub editor on several occasions during the previous exercises, but we haven’t taken a
good look at how the different parts of the editor fit together. The editor is split into several different
tabs:
 Transitions. This is where we will determine how the stub will handle events, whether
internally or externally created.
 Behaviours. Behaviours allow us to add pre‐programmed intelligence to the stub. This could be
as simple as setting a timer, which will prompt an action after a period of time, or more
complex, such as simulating a market feed.
 Properties. This allows us to set up states for the stub, as well as input parameters that can
determine how the stub should act after it is executed.
 Logging. Logging settings determine how much information will be recorded as the stub is
executed.
 Documentation. The documentation tab allows the user to add extra information about the
stub. This is not compulsory, though it is advisable to do so, as it can serve as an explanation to
future users of the stub. Documentation will be published to the server along with the stub, so
that users of RTCP can choose an appropriate stub to use in each scenario.
For the moment, we’ll mainly be concerning ourselves with the Transitions tab. We’ll be looking at the
other tabs later on, as we progress through more complex examples.

12.2 Transitions

The Transitions tab contains a list of all of the transitions contained in the stub. These are named
transitions, as they can be used to switch the stub between different states. However, for our first few
simple examples, they may be thought of as event handlers.
When a stub receives an event, it will look through the list of transitions to find an appropriate
response. Starting from the top of the list seen in the Transitions panel, the stub will go down the list
until it finds a transition that has been specified to handle the event received. This may be due to filters
on messages being received, which may mean a transition might only handle a message if a particular



field or set of fields contain the correct data; it might be due to the current state of the stub; or it may
be due to the source of the current event (e.g., which operation is meant to be handed by the
transition).
Each transition has a set of properties listed next to in the top half of the screen. Some of these will be
useful to us now, while others will become relevant later on. The most important parts of each
transition are the Actor and the Event – the Actor lets us know where the event has originated, while
the Event specifies the type of event (e.g., the operation). For most transitions, the Actor will be set to
User – this means that it has originated from a user of the service; we’ll come across other settings
later on. Where the Actor has been set to the user, the Event will generally specify the operation being
handled.
The From and To columns specify the start and ending states for the transition – if these are left blank,
it is assumed that the transition will work for any state of the stub. As we will be looking at stateless
stubs for our first examples, these columns will be kept blank.
The Guard column lets us specify if an event will be handled, depending on the data received within
that event. We may choose to analyze the data held within the message on its own – for example, we
might like to respond differently to a message containing a start and end date when the end date
comes before the start date. We can also compare received data to data held within a data model –
we’ll look at an example of this later on, when we discuss data models in detail.

12.3 Exercise: Creating a stub from the MEP
For the hotel search service, we could easily use recorded messages to create a new stub, as we did
before. As with recording MQ messages, there is some setup to be done for recording HTTP messages –
we will see an example of this later on in the course.
For the moment, though, we will create a new stub from scratch, and fill it in with our own values.
1. Switch to the Test Factory perspective, and locate the getHotels operation in the Test Factory
Tree on the left hand side.
2. Right click on the operation, and select New > Stubs > Stub using MEP. This will create a stub
based on the Message Exchange Pattern we saw in the previous exercise.
3. Call the stub singleHotel, and press OK.
4. Your new stub will be open in this perspective, so let’s take a look at it. Similar to the first stubs
we created for the flight booking services, this has message data on the Input and Output tabs.
However, while the message schema has been correctly applied, you’ll notice that none of the
fields have been filled in for us, so we’ll need to take care of that ourselves.
5. Within the Input tab, locate the city Element – underneath that, there will be a (Text) node.
Double click on this to edit it.
6. Within this editor, we can choose what to do with this part of the message – we can use it to
filter incoming data, validate that the data is correct, or store that data for later use. For the
moment, we’ll filter based on the city name, so go to the Filter tab, and press New.



7. Check that the Action Type is set to Equality, and enter Barcelona for the value. Press OK to
return to the message, which should now look like the image below. Make sure that the
Barcelona value has been placed in the right location:

8. We’re now looking out for hotel searches in Barcelona; we don’t really care about the dates,
which would be set out in the from and to Text nodes. Switch to the Output tab, so we can
specify what details we will send back in response.
9. We have another message here, again with the correct schema, but empty fields. You can enter
all details if desired, but Tomcat only requires a response that includes the hotel name and the
rate.

10. Save the stub.

12.4 Using the HTTP Proxy
Earlier, when we ran a stub for MQ, we simply instructed the stub to take messages from the same
queue(s) that the real application was using. However, for HTTP, it’s a bit more complicated. Under
normal circumstances, the request message will be sent to a particular destination, which is where the
application is hosted on the network.



To give us the ability to interact with this HTTP traffic (which will give us the ability not only to stub,
but also to record traffic), the Rational Integration Tester Platform Pack provides a HTTP proxy. The
client application can then be configured to use this proxy – when Rational Integration Tester and any
stubs are inactive, traffic will simply pass through the proxy to reach its destination as usual.

However, if we were to start a stub – whether inside Rational Integration Tester, or deployed to an
agent, the traffic will be redirected. RTCP is used as the central control point for RIT and all related
tools, so the stub simply needs to notify the server that traffic should be redirected; any proxies in the
system will then be advised of this change by the server.

Similar interactions can be used when HTTP recording is needed. Rational Integration Tester advises
RTCP that it wants to record messages being sent to a particular destination (or for a particular
operation). The server instructs the proxy to send a copy of each message back to Rational Integration
Tester, where it can then be presented in the Recording Studio. Note that HTTP recording may also be
done by packet capture, requiring only Rational Integration Tester, but this method may not be able to
record all of the same traffic, so the proxy method is preferred.



12.5 Exercise: HTTP Stub Execution
1. In order to run our stub over HTTP, we’ll be using the HTTP Proxy provided with Rational
Integration Tester. Earlier, when we viewed the agents available in RTCP, you may have noticed
an agent for HTTP traffic. You might like to return to RTCP to verify that this is present.
2. The other thing that we need to do before attempting to stub using the HTTP Proxy is to make
sure that the application sending the request message is configured to go through the proxy. In
this case, it’s our Tomcat server, which has already been configured in this way. If you’re
curious, your instructor can point you towards the catalina.bat script for your Tomcat server,
where you can also verify this.
3. Right click on the singleHotel stub you created in the above exercise and click on Run. The
stub should start up without any errors as shown below:

4. In your web browser, go to the Worldwide Travel home page, and search for a hotel in
Barcelona.
5. You will notice that it displays only the single hotel provided in the previous exercise. You could
choose to book the hotel from here if desired.



6. Go to the Test Lab perspective in Rational Integration Tester. The console should show that the
stub has processed the hotel search as requested.

7. Stop the stub, and search for a hotel in Barcelona again. This time, the request will be processed
by the actual web service rather than the stub – three hotels will be returned by the service, as
shown below.

8. At the moment, you’ll notice that the web service only returns results for a few cities. For
example, you might want to search for hotels in London using the service. This currently
returns no results:

12.6 Exercise: Handling new request options
Currently, our stub can only handle requests for a single city. If any other requests are sent, they will
be ignored – no response will be sent at all. Let’s look at providing a way of handling requests for
another city, as well as a default response for any unrecognized cities.
1. Return to the Test Factory. At the top of the screen, we have a list of the transitions that will
handle incoming messages. Before we go any further, let’s add a description to the single
transaction that we currently have. Click in the Description field, and edit it to call it Barcelona
Hotels.
2. To add a new way of handling events, press the Add Transition button at the top of the
editor. A second empty transition will be added.



3. Select this new transition, and click in the Actor column to reveal a drop down menu. The only
option here for the moment will be User, so select that.
4. Similarly, in the Event column, select getHotels.
5. Finally, in the Description field, enter Edinburgh Hotels.
6. You will notice that the Input and Output tabs at the bottom of the screen have become
available. Go to the Input tab, and find the city Element again.
7. Double click on the (Text) node for the city, and use the Field Editor to add a new filter
looking for Edinburgh as the city, in the same way that we searched for Barcelona previously.
8. Once you’ve added Edinburgh here, go to the Output tab, and enter details for a hotel, again
following the same procedure as previously.
9. Our stub now knows how to respond to messages looking for hotels in Barcelona and
Edinburgh, but will not send back any response for other locations. We’ll now add a way of
handling those cases. Add another transition, setting the Actor to User and the Event to
getHotels once more. It should have a Description of Default. You should now have three
transitions, as shown below.

10. Select the Default case. This time, we won’t edit the Input message at all, so we won’t filter out
any particular response messages. Instead, we’ll just provide a response message for this
default case, so switch to the Output tab.
11. The message schema used here has a main getHotelsResponse, which may contain a list of
hotels – each hotel is contained in a child called getHotelsReturn. For the default case, we
won’t return any hotels, so right click on the getHotelsReturn element, and select Delete.
Rational Integration Tester will ask for confirmation – say Yes to this, and then save your stub.
12. Running this new version of the stub, you should now see that you receive replies for searches
on Barcelona and Edinburgh, each one having a single hotel. Other cities now receive a reply,
but no hotels will be shown.
13. In the default case, we’ve seen how we can remove elements from the message – let’s now look
at how we can add elements. In the case of Barcelona, we might like to supply more than one
hotel (which is already supported by the message schema used for the response messages).
Return to the Test Factory, and select the Barcelona transition.
14. Go to the Output tab for Barcelona, and you should see the hotel details you entered earlier for
that city. To add a second hotel, select the getHotelsReturn element, right click on it, and select
Copy. Then right click on the getHotelsReponse element above and select Paste.



15. You will now have two hotel entries that look exactly the same. Edit the hotel name and rate in
the second hotel (we won’t worry about any other details). If you want, you can add further
hotels in the same way.
16. Save the stub. If you were still running it, Rational Integration Tester will now be running the
new version of the stub; if not, start the stub yourself in the Test Lab.
17. Run a hotel search using Barcelona as the city – you should now see two hotels listed for you.
Before you go any further, Stop the stub, as we’ll be creating a different one in the following
exercise.



13 Storing and Manipulating Data
13.1 Tags and the Tag Data Store
Tags are variables internal to Rational Integration Tester that can be used to store and retrieve data.
There are 3 main types of tags that you may see within Rational Integration Tester:
 System tags: contain values that are provided by Rational Integration Tester, and cannot be
changed by the user. These include things like the time, the project name, and the host name of
the machine running Rational Integration Tester.
 Environment tags: contain user‐supplied data that can change from environment to
environment.
 Test tags: contain user‐supplied data that is local to a given test or stub.
In addition to these main types, you may see other types of tag. These are mainly treated as varieties of
Test tags. Some examples of these that you may encounter are:
 Global tags: a test tag that has had its scope set to cover all tests in a test suite. Global tags
may be used to pass values between multiple tests in a test suite, as long as the tag is defined in
both tests, and marked as global in both tests. Outside a test suite, the scope of the tag is limited
to the current test.
 Overridden Environment tags: it is possible to override an environment tag with a test tag.
These are marked to differentiate them from other tags; note that this is discouraged, but may
occasionally happen when creating environment tags for a project that already contains a set of
tests/stubs.

 Java Properties: by creating a test tag with the same name as a java property, it is possible to
access that Java property within a test or stub (for example, the Java property file.separator).
For the purposes of this module, we will focus on the 3 main types of tag – System tags, Environment
tags, and Test tags.
All tags that are available to a test or stub can be viewed from within the Tag Data Store; this dialog can
be accessed from the Tag Data Store button, or from the context menu anywhere within a test. The
image below illustrates a typical Tag Data Store. The tags are listed in alphabetical order.



You should notice that the values for environment tags reflect the currently active environment; if you
switch environments, these will update.
The tool tip for the tag under the mouse‐pointer displays the optional description field for the tag
You can create a logical hierarchy of tags by separating multiple name sections with the / character
(e.g., JMS/URL and JMS/User will be displayed together under the JMS section).

13.2 Creating Tags
Within Rational Integration Tester, you can create new Environment tags and Test tags. As System
Tags are managed by Rational Integration Tester, tags of that type cannot be created or edited.
Environment tags may be created and edited from the Environment Editor (Project > Edit
Environments). Within the Environment Editor, you will see a list of environments on the left hand
side, along with an item labeled Default Properties. Default Properties provides a value for any tags
which have undefined values within any environment. For this reason, it is advisable to create new
tags within the Default Properties, and edit them within any environment requiring different values.
To edit or create tags within an environment, select that environment on the left hand side, and verify
that you are looking at the Properties tab on the right hand side. Underneath this tab, you will see all
tags for the current environment.



From this tab, you can edit tags for the current environment:
 New… creates a new tag within the current environment, allowing you to set a value and
description within that environment. The tag is also created within all other environments, but
is not assigned a value or a description in any other environment.
 Edit… brings up a dialog which allows you to edit the value and description of the currently
selected tag within the current environment. Double clicking the tag will bring up the same
dialog.
 Clear resets the value and description of the tag within the current environment, leaving them
undefined.
 Delete removes the tag from all environments.
If a tag does not have a value or description within an environment, it will be listed in here as
#undefined?, and will take its value/description from the Default Properties, as discussed previously.
New test tags need to be created within individual tests or stubs. For the most part, they will be
created from the Tag Data Store, but can also be created within certain test actions:



 Create one manually by clicking on the icon within the Tag Data Store. In the Create Tag
dialog, enter the name, optional default value, and description for the new tag.
 Create multiple tags by pasting a list of tag names directly into the tag data store window. First
create a list of tag names in a text‐based file – the names may contain / characters to create a
hierarchy as mentioned above (e.g., MYTEST/Name). Next, copy the list of tag names and paste it
into the data store window (press Ctrl + V or click the paste icon ). Blank lines will be
ignored when pasting tags.
 Use the Quick Tag option within a test step to automatically create a tag with a name
corresponding to a particular message field.

13.3 Using Tags
As seen above, tags may be given values when they are created. Test tags may also be given new values
during the execution of a test or stub. This will usually be done on the Store tab of a test action; in that
case, the tag is referenced simply by its name.
To retrieve the value of a tag, you will need to surround the tag name with two percentage signs at
each end. This means that you can store a value in a tag called myTag simply by referring to its name,
myTag, but to retrieve the value of that tag, you will need to refer to it as %%myTag%%.
Some features of Rational Integration Tester use ECMA Script – within any of these scripts, tags can be
referenced by their name, unless that name clashes with a reserved word or variable. In that case, you
can reference the tag as tags["myTag"].

13.4 Exercise: Creating and using a tag
So far, every example we’ve looked has used static data. Let’s see how we can use dynamic data within
our own stubs by using tags. We’ll create a new stub that will return a hotel for any city, using that
city’s name.
1. Within the Test Factory, create a new stub by right clicking on the getHotels operation, and
selecting New > Stubs > Stub using MEP. Call the stub taggedCity.
2. We’ll only have the single transition for this stub. As before, make sure the Actor within this
transition is set to User, and the Event to getHotels.
3. In the Input tab find the city element, and select the Text node. Right click and choose
Contents ‐> Quick Tag. This will update the message body like so:

4. Notice the icon in next to the word city in the Action column. This lets us know that we’ll be
storing the value in the city field into a tag called city, which we can then re‐use later on.



5. Now select the Output tab and locate the name element within getHotelsReturn. The text field
for this is currently blank. We’ll edit this so that the user sees “cityname Hotel” here. To do this,
double click the text field so that you can edit it. Type in %%city%% Hotel . The percentage signs
tell Rational Integration Tester that we’re retrieving a value from a tag named city at this stage.
6. Fill out the other details in the output message by hand – most of them won’t matter that much
for our example, but you will need to check that you have a rate for the hotel in order for the
web interface to work.
7. Save the stub, and switch to the Test Lab. Check that you have stopped any other stubs that
might have been running previously.
8. Run the stub, and search for hotels in any city. You should always receive a response that the
local hotel has a room available.
9. Stop the stub once you are finished.

13.5 Guards
By tagging incoming data, we can also implement extra filtering on any incoming messages. Previously,
we’ve been able to filter incoming data by looking at a single field – for example, by looking for hotels
in Barcelona. We could also filter based on multiple fields, as long as the data in those fields is
independent – for example, we could filter for searches in Barcelona on the 23rd of January. However, if
we needed to look at the relationship of data between different fields (or between fields in the message
and a data model used by the stub), we would need to take a different approach.
A guard allows us to provide more complex filtering, rather than just looking at the values inside each
field one by one. It might filter data by executing a short script that performs comparisons and/or
calculations. It may also provide filtering by comparing incoming data to data held within a data model,
or even just marking the transition as the default to use if no other filters allow the incoming message
to pass.
So if we need to make sure that multiple fields in a message relate to each other correctly, we can tag
those fields in the input message of a transition, and add a short script that will verify that relationship.
For example, if we receive a message containing an order, it might be useful to check that the prices of
all items add up to the stated total, or that a field stating the amount of tax has been calculated
correctly. Depending on whether or not these conditions have been satisfied, we might treat incoming
data in different ways.

13.6 Exercise: Using Guards
In this exercise, we’ll extend the previous example so that we can send back one of two alternative
responses. If the user makes a request for a hotel in any city, we’ll send back the original response – as
long as the start date of the booking comes before the end date. If the request uses the right format, but
has invalid dates, we’ll simply send back a response with no hotels listed.
Note: This exercise uses dates in a day/month/year format. If you attempt the exercise using dates in
the form of month/day/year, you may encounter errors.
1. Make a copy of the taggedCity stub, and call it hotelGuards.
2. Within your new stub, select the single transition that is present. Press the Clone button to
make a copy of this transition.



3. Make sure you have selected the transition at the top of the list. Edit the Description field – it
should say Valid Input.
4. We’ll use the Valid Input transition one to cover the case where we have completely valid
input – a city, and a start date that comes before the end date. Within the Input tab for this
transition, tag each of the city, from, and to text fields.
5. Set the Guard for the transition to Other. The Input tab will now contain a Guard section.
6. Make sure the scripting language is set to ECMAScript, and enter the script:
formatDateUTC( from, "yyyy‐MM‐dd'T'HH:mm:ss.SSS'Z'" ) < formatDateUTC( to, "yyyy‐
MM‐dd'T'HH:mm:ss.SSS'Z'" )
This will convert the from and to tags to UTC, so that they can be easily represented
numerically, and compare them. If the from date is then less than the to date – ie, the from date
comes before the to date – then we’ll pass the guard, and so the filter, sending back a message
with a hotel.
7. In the second transition, enter a Description of Invalid Dates.
8. The Invalid Dates transition doesn’t need any guard, as we’ll fall straight through to it. We will
filter it somewhat, though – we’ll make sure that any incoming message has the correct message
structure.
9. Select all of the elements in the message body within the Input tab, then right click and select
Contents > Field Actions > Filter > Does Exist.
10. As we’ve got a valid message structure with invalid dates, we’ll simply send back a message
stating that there are no hotels available. Switch to the Output tab of this transition, and delete
the getHotelsReturn node from the message.
11. Execute the stub, and use the GUI to enter values that verify that the stub is responding
correctly. When the start date comes before the end date, we should see the same data that we
saw in the previous exercise. However, if you set the start and end dates to be the same, you
should see that no hotels are available.



14 Data Driven Stubs
Now that we’ve seen how we can store and use a single piece of data within a stub, let’s take it a step
further. When testing, it is standard practice to use an external data source to provide inputs or output
data. We can do this while virtualizing a service through the use of a Data Source. We’ll see how we can
interact with a data source, first by starting with a set of recorded messages, and then by starting again
using the MEP of an operation.

14.1 Data Sources
There are 4 types of data source supported by Rational Integration Tester. Each one is handled
separately within a project, to account for configuration settings that will vary from data source to data
source. The data sources are as follows:
 File Data Source – reads data from an individual file. This may be something like a CSV file, fixed
width, or other delimited file.
 Excel Data Source – reads data from a sheet in an Excel spreadsheet.
 Database Data Source – reads data from a table in a database, or the results of a query on a
database. The database must be set up in Architecture School before this data source may be
created.
 Directory Data Source – reads in a set of files (for example, a set of XML documents).

14.2 Exercise: Creating Parameterized Stubs from Recorded Messages
1. Go back to the Recording Studio perspective in Rational Integration Tester, and select
MakeBooking within the Event Monitors. This should filter out any other events, leaving you
with just the 6 MakeBooking requests and responses recorded during the previous exercises.
Check these to make sure that you have a request message for each of the three card types
allowed by the booking system. If not, you’ll need to record more interactions with the system.
If you’ve got too many, then delete any extras from the Events View.

2. Select all 6 events, and press the Save button.
3. Again, we’ll choose to save them as a stub in the first page of the wizard. Press Next once you’ve
done this.
4. On the second page of the wizard, choose to Store data in a simple data set. Press Next.



5. The third page checks that everything has been allocated to the correct operation. You should
see 6 events, all labeled as being related to the MakeBooking operation. If so, press Next. If not,
you’ll need to go back and make sure you’ve selected the right events.
6. The fourth page checks that the requests and replies have been grouped correctly. Again, this
should already be the case, but you can choose to change groupings here or restart if necessary.
Press Next once you’re satisfied that this is correct.

7. You’ll then get a preview of how the request messages will be mapped into our data set.
Rational Integration Tester will analyze the messages used in the recorded messages, and look
for differences between the messages. By default, it will record data that changes into columns
within the data set; data that appears to be static will not be included. Take a look at the request
message – fields that are going to be included in the data set have a status of New , while
those that are not going to be included are listed as Ignored .
8. Within the request message, we only care about the card type, so select each of the other fields,
and press the Ignore button. This should leave only the card type listed as New, and
everything else Ignored. Press Next to go to the response message for MakeBooking.
9. Here, we can see that the reservation number is also marked as New. In this case, we may also
decide that we are interested in the status field as well, even though it had the same value in
each of the recorded messages. Find the status row, which should be marked as Ignored. Select

it, and press the Column button.
10. A popup dialog will appear, allowing you to name the column that will be created for the status
within our data source – by default, it will be called status. This will be fine for our purposes, so
press OK. Both the reservation number and the status should now be marked as New.

11. Press Next again to go to the summary screen. This should inform you that a stub will be
created, along with a data source containing information about the card type, reservation
number, and status. If different fields are listed, you’ll want to hit back to return to the previous
steps, and make sure that each field is being added to the data set or ignored, as required.
12. Call the stub BookingsWithData, and go to the Test Factory to view what we’ve produced.



13. Under the MakeBooking operation, you should see two things with the name BookingsWithData.
We have a stub, as we’ve had every other time, but we also have a data source. Double click on
this within the Test Factory Tree to open it.

14. The first thing you might notice is that the file name contains a reference to the root directory of
a project, written in gold and surrounded by percentage signs. This is a system tag – a variable
internal to Rational Integration Tester, which we can’t edit directly. This allows us to refer to
the project folder, no matter where that might be located. If the project is moved to another
folder or another machine, the link to the CSV file that we’re using will still function.
15. Press the Refresh button at the bottom of the screen to view the data within the data source –
this should contain the three card types and reservation numbers we recorded previously,
along with a status column that states SUCCESS for each. There is also a grouping column
provided for us, in case we had recorded data with repeating elements (which would require
multiple lines of data). As our data is fairly simple, we don’t need to worry about this for now.
Close the data source.
16. Open the stub itself, and look at the Input tab. You should notice that the card type is being
stored into a tag.
17. Switch to the Output tab, and you’ll notice that no response is being sent here – in fact, no
response message appears to be present at all. This is because the stub that we have generated
will respond if it recognizes a familiar card type, but otherwise will ignore any incoming
messages. To see how we handle this, switch to the Business Logic tab.



18. The Business Logic tab allows us to specify our own custom logic to dictate how the stub will
respond to incoming messages. Here, you can see a Lookup Test Data action, which is followed
by two options – Found and Not Found. If the lookup is successful, it will send a reply. If not, it
will do nothing. Open the Lookup Test Data action by double clicking on it.

19. This has two tabs – the Config tab will open by default. As you should be able to see, we’re
trying to match the value that we stored into the cardType tag in the Input tab with the
cardType column in the data source.

20. Switching to the Store tab, you’ll be able to see that we’re going to save the data from the
columns in the data source into corresponding tags within the stub (with the exception of the
grouping tag). This will only happen if we find a match – otherwise, any values that may exist
within those tags will be left alone. Close the Lookup Test Data Action.
21. Open the Send Reply action. This will be used to send a reply if and only if we found a match
within the Lookup Test Data action.



22. Observe the message that is being sent back – this uses the values that were saved into the
status and newReservationNumber tags within the Lookup Test Data action, so these values
will be coming directly from our data source. Close the Send Reply action.
23. Run the stub, and send some requests to it. You should notice that each card type gets its own
reply, based on the data source.

14.3 Exercise: Creating a data source without recorded messages
Now that we’ve seen how we can data drive a stub from recorded messages, let’s look at how we can
create something similar ourselves. We’ll return to the HotelFinder example, and create a new stub
that will look up the city in a spreadsheet, and return an appropriate hotel. This will give us something
very similar to what was created for us automatically in the previous exercise. Later, we’ll extend this
to handle multiple results coming back from the lookup – in our case, this will mean multiple hotels
within the same city.
1. Create another new stub for getHotels using the MEP, and call it HotelWithData. As we did
earlier, store the city data into a tag on the Input tab.
2. As we will be sending back different messages depending on whether or not we find a hotel
within our data source, we can’t use the single message described in the Output tab. Uncheck
the box on that tab labeled Send Response.
3. We’ll be doing most of our work on the Business Logic tab, so switch to that, and set the Data
Model setting to Other. This tells Rational Integration Tester that, while we may or may not be
using a data model – more on these later – we do want to supply some of our own custom logic
for the stub.
4. Below that, the Test Steps will appear. As we’re going to look things up in a data source, press
the Edit or Create Test Data button.
5. The Create or Edit Test Data wizard will appear. Press Browse next to the Excel File setting.
This will open by default to the folder representing the getHotels operation. Type in a name for
the Excel file – e.g., HotelData1.xls – and press Select.
6. Press the button labeled Select Test Data Columns in order to select which tags will be used.
7. The Select Tags dialog box will appear, showing the city tag we created earlier. We’ll also want
to use tags for the hotel name and hotel rate. Press the New Tag button, and the Create Tag
dialog will appear. Call your new tag name – the rest of the settings can be left alone. Press OK to
return to the Select Tags dialog.
8. Create another tag in the same way – call it rate.
9. When you have returned to the Select Tags dialog, drag your mouse over all three tags to select
them.



10. Press Select to return to the main window of the wizard.
11. Finally, we’ll need to state how we’re going to use our data. We’ll use it in a new Lookup Test
Data action, and insert it after the Send Output action (this last part doesn’t really matter that
much in our case, as the Send Output test action has already been disabled).

12. Make sure that your dialog looks like the one above, then press Next.
13. On the second screen, you can select the mappings used in the Lookup action. We want to
match rows based on the city, so press the Edit Lookup Values button, and make sure that
the city tag is selected in the dialog box that appears. The other tags should be deselected.
14. Press Select to close this dialog box, then Finish to close the wizard.
15. The Excel spreadsheet should now appear on your machine. We’ll need to enter some data here.
You can use the following example data:
city Name rate
London Uptown 200
Paris Global 250



Madrid Superior 180
Barcelona Downtown 220

16. Note that the data has one hotel per city – we’ll look at how we can handle multiple hotels in the
following exercise. Save your spreadsheet, and close the editor.
17. Back in the Business Logic tab of the stub editor, you’ll now see a Lookup Test Data action
inside your stub. This will refer to your data source, attempt to lookup data based on the city
tag (as selected in the wizard), and retrieve the hotel and rate information for that city. Open
this up and take a look at its settings to acquaint yourself with what is happening inside this
step. Close the properties of the Lookup action once you’re done.

18. Underneath the Lookup action, you should see linked items labeled Found and Not Found.
These let us control what will happen, depending on whether or not we can find a match for the
city field included in the request message.
19. Right click on the Found item, and choose New > Messaging > Send Reply. This will create a
new action underneath the Found branch.
20. Double click to open the new Send Reply step.
21. You will see that the message is currently empty, and does not have a schema at the moment. To
fix this, find the text(String) in the message, right click and choose Schema.
22. The Select Schema dialog will appear. On the first page, select WSDLs on the left hand side,
then the HotelFinder WSDL in the middle. On the right hand side, you will then be able to select
the getHotels___OUTPUT___getHotelsResponse message schema. Press Next.
23. On the second page, make sure that Include optional fields is checked. Press Finish.
24. The message schema will now appear for you. Select the text nodes for the hotel name and rate;
right click, and then choose Contents > Quick Tag. This will insert the tag names for these two
fields here. All other fields may be left blank, as they will be ignored by the Tomcat application.
If you wanted to, you could quick tag some of the other fields, and make sure that you have
matching columns in your data source, in order to data drive those fields as well.



25. Press OK to close the Send Reply action.
26. Copy and Paste the Send Reply action, so that there is a second copy of it underneath the Not
Found branch. Double click to edit this new action.
27. As we did previously, we’re going to delete part of the message to show that no hotels were
found. Find the getHotelsReturn element, and delete it. This will also delete all of its child
nodes.
28. Close the Send Reply action. Your test should now look like the following:

29. Save the stub and run it.
30. Attempt to search for hotels in the cities referred to in your spreadsheet – you should now get
the same hotel that you had in your data source. Using cities that were not in the spreadsheet
should result in an empty list of hotels.

14.4 Exercise: Data Driving with Repeating Elements
Ideally, we’d like to be able to respond with more than one hotel per city. Doing this in the Excel
spreadsheet will be pretty simple – we just need to add more rows. But we’ll need to configure the
output message correctly in our stub to make sure it’s sending back the right data.
We’ll also take this opportunity to look at how you would import data from an already‐existing data
source. This means that we’ll need to do a few things manually that Rational Integration Tester was
doing for us in the previous exercise – for example, we’ll need to tell the software if our columns have



headings, and whether or not there are any blank lines before or after those headings. In the previous
exercise, Rational Integration Tester knew all of this information about the data source, as it had been
created in the same software, but here we won’t have that luxury.
1. On your desktop, you’ll have an Excel file called HotelsByCity.xlsx. Open this to take a look –
you should see hotels for London, Edinburgh, Barcelona, and Madrid. Close the file without
making any changes.
2. Go to the Test Factory, and create a new stub for getHotels using the MEP method. Call it
multipleHotels.
3. This stub will also have just the one transition. Set the Actor for this transition to User, and the
Event to getHotels.
4. In the Input tab, select the city Text node, right click, and select Contents > Quick Tag. As
before, this will store the incoming city name into a tag for us, so we can use it to look up the list
of hotels for that city.
5. In the Output tab, uncheck the box marked Send Response.
6. In the Business Logic tab, set the Data Model to Other.
7. You’ll then be able to add a new Lookup Test Data action to the stub by selecting it from the
toolbar that appears.
8. At this stage, the Lookup Test Data action will state that no test data set has been allocated.
Since we haven’t created one yet, we’ll now need to do that. Right click on getHotels in the Test
Factory Tree, and select New > Test Data > Excel Data Source. Call it hotelData.
9. The settings for the Excel data source will appear. First, we’ll need to specify the file name, so
find this field at the top of the settings, and press Browse to locate the HotelsByCity.xlsx file.
10. Below that, we can configure other settings – the defaults should work fine for this example.
Press the Refresh button at the bottom of the settings to view the file as Rational Integration
Tester understands it. You should see the same data that you saw in the Excel file, with the
column headings separated.

11. Press the button Copy column names to clipboard. This will allow us to create tags that match
our column names within the stub.
12. Save the Excel Data source and Close it.



13. Go back to the multipleHotels stub, and on the Business Logic tab, double click on the
Lookup Test Data action.
14. The properties of the Lookup action will appear. The first thing we need to do is select the data
set, so press the Browse button for this setting, and select the hotelData that you just created.
15. Once you’ve done this, a lookup setting will appear below. This allows us to set the criteria
we’re going to use for matching records in the data source to the incoming messages. By default,
Rational Integration Tester will select the first column as the column to use for the lookup. We
could change this, but as it’s exactly what we’re after, we’ll leave that setting alone.
16. That said, we do need to say what value we’ll be looking for in the city column. Double click on it
to edit the Lookup Value, and insert the city tag, either by typing %%city%%, or right clicking
and choosing Insert Tag > Test Scope > city.
17. Switch to the Store tab of the Lookup Test Data action’s properties. Here, we can say what
we’d like to do with any matching data.
18. The first setting allows us to choose whether we’d like to find all data that matches our chosen
city, or just a single line of data. We’d like everything, so select Store all matching rows into
lists.
19. Below that, we can see how the data in the data source will be mapped into our tags. Currently,
the city data will be mapped into our city tag, but the other two columns are listed as having No
Mapping.
20. Clicking in the Tag Name column will present you with a pair of icons on the row you click on.
Click on the Tag Name for the hotel name, and then click on the Edit button that appears.
21. The Select Tag dialog will appear. Press the Paste button at the top of the dialog to paste in
the column names we had in our data source. This will create tags with corresponding names.
22. Select the hotel name tag that was created in the previous step.
23. Edit the tag name for the rate, and Select the new rate tag.
24. Verify that the Store tab looks like the following, and press OK:

25. We now need to add the two messages that will be sent back, depending on whether or not a
match is found in the data source. Right click on the Found branch of the Lookup action, and
select New > Messaging > Send Reply. Double click on this new action to edit it.



26. Right click on the text (String), and select Schema. Choose the
getHotels___OUTPUT___getHotelsResponse schema from the HotelFinder WSDL, and press
Finish to close the Schema dialog.
27. In the text fields for the hotel’s name and rate, edit them and then right click and choose Insert
Tag > Test Scope, and then the appropriate tags.
28. As we may have more than one result, we need to tell Rational Integration Tester that this may
be the case. Right click on the getHotelsReturn element, and choose Mark As Repeating. The
element should turn green (you might need to select something else to see this). Press OK.
29. Copy and paste the Send Reply action so that it also appears under the Not Found branch.
30. Open up this second Send Reply, and delete the getHotelsReturn element from the message.
31. Save your stub and run it in the Test Lab. Now, when you search for hotels that are listed in the
data source, you should see multiple results returned.

14.5 Exercise: Input Tags
One other way we can supply data to a stub is to provide some configuration data when the stub is
executed by the server. This can be done through an input tag. An input tag is a test tag that has been
marked as one that can receive input. Generally, this should have a default value.
When we execute the stub from Rational Integration Tester, the default value for the tag will be used,
and the stub will execute as it normally does. If we publish the stub to the server, then we will be given
the option of using a different value when we deploy the stub.
1. Create a copy of the HotelWithData stub you created for getHotels. Call it HotelsWithInput.
2. Go to the Business Logic tab, and click the Tag Data Store icon (first on the left of the toolbar).
3. The Tag Data Store will appear. Press the New Tag button to create a new tag – call it
final_rate, and press OK.
4. Create a second new tag, and call it multiplier. When you create this, give it a default value of
1.0, and choose to Expose as Input. This will be our input tag. Press OK to create this second
tag.
5. Close the tag data store.
6. Add a new Function action before the Send Reply in the Found branch of the Lookup Test
Data, and edit it.
7. The Function action should be using ECMAScript – enter the following code:
final_rate = rate * multiplier
8. Press OK to close the action.
9. Open the Send Reply action in the Found branch. On the Config tab, you will see that the reply
was previously using the value of the rate tag. Change this to use the final_rate tag instead,
and close the Send Reply action.
10. Save the stub, and execute it in the Test Lab. You should notice that it still operates in the same
way it did previously.



11. Stop the stub, and return to the Test Factory.
12. Right click on the getHotels operation, and choose to Publish the stubs for that operation,
using the Booking System domain and Local environment.
13. In RTCP, choose to deploy the HotelsWithInput stub. As you do this, you should notice that
there are Configuration settings. Inside this section, you will see the multiplier tag, along
with its default value of 1.0.
14. Change the default value to 1.5 – we would expect this to raise all of the prices for the hotels,
possibly for a holiday season.
15. Start the stub from the server, and attempt to look for hotels from your web browser one more
time. This time, you should notice that the prices have gone up.
16. If you want, you can stop the stub in the server, then restart it with a multiplier of 0.5, giving us
half price hotel rooms. Stop the stub once you are finished.



15 Database Stubs
15.1 Introduction
While it is very useful to simulate message‐based systems, sometimes it would be useful to simulate a
database as well. VIE provides us with this capability – we can record an application’s use of a
database, and use this information to simulate that database invisibly to the application.
While doing this, we can choose to simulate that database in such a way that every time we start the
simulation database, it contains the same data set, or we may choose to persist changes made to the
simulation database over time.
In order to do this, new JDBC drivers need to be set up for the application(s) that will be accessing the
database. This allows VIE to intercept the database requests being made by the application. This setup
will vary from application to application. The example discussed in this chapter cover the use of a
generic Java program (Tomcat).

15.2 The RIT JDBC Driver
In order to use VIE’s capabilities to record database interactions and to create stubs, the application
that is accessing the database must be modified to use the RIT JDBC driver for database access. The
default behavior for the RIT JDBC driver is to pass through any JDBC calls to the real database driver,
whether that is DB2, Oracle, MySQL, or something else, allowing the application to behave normally.
This mode is Live mode, and may be used to record the data passing through the RIT JDBC Driver.



The second possible mode is Learn mode. This works in much the same way as Live mode, but we’ll
also be saving the data returned by any queries into our separate simulation database. Note that the
simulation database must be of the same type as the live database (DB2, MySQL, etc), but does not
need to be on the same machine. When the driver switches out of learn mode, all data is copied from
the simulation database into Rational Integration Tester’s internal storage.

The final mode is Simulation mode. This redirects any JDBC calls that would usually be sent to the
database to our simulation database instead. The simulation database will be repopulated with
whatever data is held by Rational Integration Tester at this time. When we exit simulation mode, we
may choose to again save the data held inside the simulation database, overwriting what was held
previously. This gives us the option of having persistent or transient data.



15.3 Exercise: Recording SQL
We’ll now look at how we can record the SQL queries being sent to the database through the Tomcat
webserver. For the moment, we won’t worry about creating a virtual database – we’ll just record the
SQL statements being used.
1. Switch to the Recording Studio of Rational Integration Tester, and clear any Event Monitors.
2. Choose to Add a new Event Monitor. In order to see the WWTravel database, you will need to
Show recordable resources .



3. Select WWTravel_DB, and press OK.
4. In the Events View, click on the Recording… button to start recording.
5. At this stage, Rational Integration Tester will inform you that a virtual database has not been set
up for the WWTravel database. This means that we won't be able to create a database stub just
yet, but we will be able to review any interactions with the database. As we just want to see the
queries that are being run against the database at this time, press Continue Recording to
proceed.

6. Within your web browser, go to the sign in page for the Worldwide Travel administration
services. You shouldn’t actually need a login here – you can just press the Submit button on the
form.
7. This will run a query, and return the various flights with bookings in your database. If you
switch to Rational Integration Tester, you should now see the query recorded for you there as



well. Note that simply recording the SQL like this does not record the results of the query – we’ll
be able to do this when we create a virtual database by observing the results of queries.
8. In your web browser, click on the link for a flight – this will give you information about the
bookings for that flight. In Rational Integration Tester, you should now see a second query
listed for you.
9. In this case, you won’t see the entire query in the Events View, as it’s too long to fit. Similarly, if
you select this event, you will see more of the query at the bottom of the screen, within the
event details, but you still will not see the entire query.
10. To view the complete query that was sent to the database, select the recorded event in the
Events View, then double click the query within the details at the bottom of the screen. A popup
window should appear, containing the complete query that was sent to the database. Close this
window after viewing the query.
11. Pause recording, and return to the initial sign in page in your web browser.

15.4 Exercise: Creating and executing a database stub
We’ll now record the same database again, but this time, we’ll record the results of our actions into a
virtual database. We will then be able to use this database as the basis for a stub that we will be able to
use for simulations.
1. Switch to the Physical View of Architecture School. You should see the physical resource that
you created earlier for the WWTravel database.
2. Double click on this resource to open up its properties.
3. Switch to the Stub Settings tab, and enter the following values (the password is Welcome01):



4. Press Test Stub Connection to verify that you have set up the connection correctly, then press
OK to close the properties of the physical resource.
5. Return to the Recording Studio perspective, and then start recording again. This time, you will
be asked what you want to do with the recorded events.

6. We could just record the SQL, as we did previously, but we’re also now presented with the
option to create a virtual database, using the stub settings entered in the Architecture School.
In the top of the dialog, choose this second option.
7. At the bottom of the dialog, choose to Create a database stub but don’t start it after finishing
recording. Call the stub WWTravel Virtual DB.



8. Press Start Recording, and then return to your web browser.
9. Log into the system again, and interact with it, allowing it to run multiple queries against the
database. At the very least, you should make sure that you view the list of passengers for both
flights – you can interact. You should see the queries appear within the Recording Studio of
Rational Integration Tester, as before.
10. Pause the recording within the Recording Studio.
11. A popup will appear, indicating that the database stub that we have created may not be edited
within the Recording Studio. Press OK to open the database stub within the Test Factory
perspective.

12. You will now see a summary of the information contained in the database stub, split into three
sections. The first section, Queries, tells us which queries were seen by the driver when
creating the virtual database. The second, Tables, lets us know which tables have been created,
and how many columns and rows are contained within the virtual database. The final section,
Sequences, allows us to see any sequences that were used by any of the recorded data. In our
case, this will be blank, as the example database does not contain any sequences.
13. Within this view, we are also able to view and edit the data held by the virtual database. For the
moment, though, we’ll simply execute the database stub, and interact with it. To do this, first
switch to the Test Lab perspective.
14. Within the Test Lab Tree, double click on the WWTravel Virtual DB stub. You should see that
it is running in the Task Monitor. Watch the console data below, as it may take a moment for
the stub to reach a status of Ready.



15. Once the stub is running, sign into the airport system again, to run a search for flights. You
should see the same flights as before. Similarly, if you click on one of the flights to see the
passenger list, you should see the same information that you recorded earlier.
16. We’ll edit the data in the simulation database, though, to prove that we’re not talking to the live
database. Select a passenger, and edit their API Comment data to say Checked In.
17. View the list of passengers for that flight again – the API Comment field will be updated to OK:
Checked In, as our data was sent to a separate service (the Flight Confirmation Server), before
being added to the database.
18. In Rational Integration Tester, Stop the stub.
19. Sign into the system again, and you should see that your changes have disappeared. In fact, even
if you were to restart the stub, you still wouldn’t see those changes. This is because Rational
Integration Tester’s default behavior is to reset the data in the simulation database each time
the database stub is started up. We’ll have a look at getting more control over the data in the
simulation database in the next exercise.

15.5 Exercise: Modifying the simulation database
We’ll now look at the various ways that we can modify the simulation database. We can edit the data in
a table using an Excel spreadsheet, or we can use whatever database tools are available. We can also
choose to keep changes to the simulation database between executions of the database stub, or to
discard any changes.
1. Make sure that you have stopped any execution of the database stub in the Test Lab.
2. Return to the Test Factory, and view your database stub.
3. Choose to Use a spreadsheet to edit this database stub .
4. The Edit Database Stub wizard will appear. On the first page, choose to Edit the contents of
specific tables, and press Next.
5. On the second page, there will be a single query listed – SELECT * FROM RESERVATION. Choose it,
and press Next again.
6. Your spreadsheet will then appear, ready to be edited.

7. Edit the details for reservation A00001: change the flight number to WW121, and the first name to
Mark.
8. Save the spreadsheet and close it.



9. Within Rational Integration Tester, the Edit Database Stub dialog will still be active, as it is
waiting for confirmation that you have finished editing the data. As we’ve now made our
changes to the spreadsheet, press Next to tell Rational Integration Tester to move on.
10. A summary will then appear. Press Finish to close the wizard.
11. Check the box marked Persistent at the top of the database stub editor. This will mean that any
changes we make to the simulation database while it is running will be saved for future
executions of the database stub.
12. Save the database stub, and Run it.
13. Return to your web browser, and the sign‐in page for the administration interface.
14. This time, as you go through the interface, you should see a third flight – WW121. This flight will
have a single reservation, for Mark Thomson.
15. Update the API Comment field for this entry, as we did in the previous exercise, and make sure
you can see the updated value on the passenger listing.
16. Stop the stub in Rational Integration Tester, and then Run it again.
17. This time, when you sign in and view the information for Mark Thomson, the changes that you
made earlier will still be visible.



16 Alternative Message Formats

So far, we’ve looked at XML‐based messaging formats. However, not all messages will be in this format.
We’ll look at examples of alternative formats, and see how they are dealt with by VIE. By the end of this
chapter, you should see that moving from one messaging format to another is fairly simple, and that
you will be able to apply the skills that you have learnt previously, with only minor adjustments.

16.1 Exercise: COBOL Copybook Messages
COBOL Copybook is a messaging format that may be encountered when dealing with older mainframe
systems. Copybook information may be stored within a file that can be imported into Rational
Integration Tester, and used to format fixed width text messages.
During this exercise, we will first import a copybook format into the Schema Library, record messages
using that format, and finally create a simple stub from the recorded messages.
1. Switch to the Architecture School of Rational Integration Tester, then to the Schema Library.
2. Press the New Copybook icon. A dialog will appear, asking you to supply the details for the
copybook that you’re importing.
3. Leave the Type as File. The Namespace, which would allow us to create a namespace within
our project for the fields contained in the copybook, may be left blank, as we’re only using a
single copybook in this example. The Start Column and End Column, which can be used to add
margins at the beginning and end of the fixed width text, may also be left blank.
4. Press the Change button to change the current location. You will then be able to Browse to the
file location – select the file API_INFO.CPY, found on your desktop.
5. You should then see the RESERVATION‐MSG message format that was contained within the
API_INFO copybook.
6. Switch to the Recording Studio, and remove any Event Monitors that might be in place.
7. Add an Event Monitor for the WWTravel_MQ transport, and Start Recording.
8. In your web browser, bring up the Worldwide Travel administration sign‐in page, and sign in.
9. Select a flight, and then a reservation on that flight.
10. While viewing this reservation, you will notice that the API Comment field is an editable field.
Enter Passport Seen in this field, and then press Check‐In.
11. You will be returned to the list of reservations for that flight. Find the reservation that you
edited in the previous step. You should see that the API Comment now says OK: Passport
seen.
12. Return to Rational Integration Tester, where you should see a pair of messages in the Events
View of Recording Studio.



13. Select the request message – you will notice that it is formatted as a single text string.
14. Right click on this string, and select Show As > COBOL Copybook > API_INFO >
RESERVATION‐MSG. A dialog will appear, allowing you to enter information about the text
encoding of the file, and to note any padding that may be present. We don’t need to worry about
either of these, so press OK.
15. A second dialog will appear, giving you a preview of the formatted message. Press OK to apply
the formatting.
16. Rational Integration Tester will then display the formatted message within the Message
Details section – you may need to expand the tree structure that has been applied in order to
see the entire message.
17. Switch to the response message – if Rational Integration Tester has recognized this as a
copybook message that it has encountered before, then it will be formatted for you
automatically. Otherwise, you will need to follow the same procedure as for the request
message.
18. Once both messages are properly formatted, we can create an operation and a stub using them.
Select the two messages, and press the Save button.
19. On the first screen of the wizard, choose to create stubs. An operation will be created for us at
the same time. Press Next.
20. On the second screen, choose to Store Data as hard‐coded values.
21. Next, you will be able to allocate the stub to an operation. As we don’t yet have a valid
operation, one will be created for us. The default name for the operation should be
wwtravel.checkin – wwtravel.checkin.reply. Rename this to Checkin. If Rational
Integration Tester asks whether you would like to apply the change to other unselected events
using the same operation name, say Yes.
22. Press Next after renaming the operation, and choose to Create all resources under the
WWTravel service component (this should already be selected for you anyway). Hit Next again.
23. We can then group the messages into transactions – as we only have two messages, and they’re
already grouped together, we can press Next to go to the summary page.
24. You should now see that we will be creating a single stub, under a brand new Checkin
operation. Press Finish to create the stub and the operation.
25. As with other recorded stubs, the stub that we’ve created will only work with a single request
message. We’ll edit it so that it’s more flexible – open the stub in the Test Factory, and view the
Input tab.
26. Currently, the stub is attempting to filter based on the message contents. We don’t want to do
this, so select all of the text fields within the message by using Ctrl+Click, then right click and
select Contents > Field Actions > Filter > Equality from the context menu.
27. With all of the same nodes selected, right click and select Contents > Quick Tag. The message
contents within the Input tab should then appear like so:



28. Most of this data will be used as‐is within the Output tab, so let’s switch to that tab now to set
this up. You should notice that nearly all of the data here is the same as what you initially would
have seen within the Input tab, with the exception of the COMMENT field, which has the text OK
added at the beginning.
29. To get things started, select all of the text nodes again using Ctrl+Click, then Quick Tag them
again.
30. Now, edit the COMMENT field. We could add OK at the beginning, as in the live system, but we’d
prefer to make sure the stub results can be easily distinguished. Instead, edit the COMMENT
field so that it says DONE: %%COMMENT%%.
31. Save the stub, and run it in the Test Lab.
32. You should now be able to check in customers using the web interface, and the comments
should be updated to include DONE at the beginning; stop the stub, and it should again say OK.



17 Data Masking

So far, we’ve recorded data and virtualized a service without worrying about the data that might be
exposed in that way. However, there may be times when we do not want all data within the system to
be visible. For example, the airline booking system passes a credit card number between different
services. If the system currently uses dummy data created by the development team, recording data
from the system will not be a problem. On the other hand, if we are recording production data, this
would be a problem. As we record messages from the system, we would be able to see customer credit
card data, which should be hidden from view.
In order to hide this data, we can add a data mask to particular fields. The data mask will replace the
field value completely whenever the field is encountered during recording. Any resources created
using that recorded data will then use the value supplied by the mask. Masks may be implemented in
three different ways:
 Fixed Value Substitution
 Data Source Substitution
 Automatic Value Creation
Fixed Value Substitution is the simplest data masking scheme. When setting it up, you will need to
enter a single value – that value will replace any data recorded for that field.
Data Source Substitution uses a data source such as an Excel or CSV file to supply a list of values that
can be used to replace recorded data. This method of substitution may be configured to allow a new
substitution each time, or to allow the same substitution for a given value each time the substitution is
performed.
Automatic Value Creation takes a regular expression, and creates new values matching that expression
– so to replace a credit card number, we may ask it to generate new 16 digit numbers for us. As with
data source substitution, it may be set up to maintain data integrity by making sure that the same
original values are always replaced with the same substitutions every time.

17.1 Exercise: Fixed Value Substitution
1. Within the Architecture School perspective, go to the Schema Library, and select the XSDs
tab on the left hand side.
2. In the list of XSDs, select the BookFlightRequest (XSD).
3. You will then be able to view this schema on the right hand side. Find the Text node of the
cardNumber element and select it, as shown:



4. In the Data Masking panel at the bottom, click on the Add button to add a data mask to the
card number.
5. Set the Masking Technique to Fixed Value Substitution and enter a value in the Fixed Value
field as shown. Finally, Save the mask. The mask icon ( ) will appear next to the field that is
being masked.

6. Go to the Recording Studio perspective and make sure that the MakeBooking operation is listed
within the Event Monitors.
7. Click on the Recording button to start recording the operation.
8. Return to your web browser, and make a flight booking using the Worldwide Travel interface.
Make sure that the credit card number that you enter here is not the same as the value used
when you created the mask.



9. Go back to the Recording Studio and view the recorded events. Select the request message for
MakeBooking, and find the credit card number field. You should see that the number you
entered in your web browser has been replaced by the value entered for the data mask.

17.2 Exercise: Data Source Substitution
1. Create an excel file with a series of fake credit card numbers, and save it as Data Masking.xls.

2. Go to the Test Factory and create an excel data source called CardNumberMask and select the
excel file created in the previous step. The other options in this screen may be left at their
defaults settings – just press Refresh to view a preview, and make sure that the data is being
imported correctly.

3. Save the data source and close it.
4. Go to the Schema Library tab in Architecture School and select the XSDs tab on the left hand
side.
5. Select the BookFlightRequest schema, and then the Text node of the cardNumber element, as
before.



6. In the Data Masking tab at the bottom, change the Masking Technique to Data Source
Substitution.
7. Choose the CardNumberMask as your Data Source, and the Data Mask as the Column.
8. Finally, you may choose to turn on or off the setting Enforce Data Integrity. Using this setting
will mean that the same data will always be masked by the same value. Using our example,
credit card numbers are used across multiple operations (MakeBooking, ProcessGlobal, etc),
and it would be useful to replace each credit card number in the same way for each operation.
Note that integrity is only preserved within a single recording session, so if you stop and start
recording, the replacement values may not be the same. You also have the option of looping
through the data to re‐use masks, or to use a fixed value if you run out of masks. We’ll switch on
the Enforce Data Integrity setting, and choose to Return to Start once we run out of data
masks.
9. Return to the Recording Studio, and record a new request for MakeBooking, as before.
10. You should see that the credit card number is now masked using values from your data source.
If you record further booking requests, you should also notice that the values displayed change
as you change credit card numbers.
11. Stop recording.

17.3 Exercise: Automatic Value Creation
1. Go to the Schema Library tab in Architecture School and select the XSDs tab on the left hand
side.
2. Select the BookFlightRequest schema, and then the Text node of the cardNumber element, as
before.

3. In the Data Masking tab at the bottom, change the Masking Technique to Automatic Value
Creation.
4. Enter d{16} as the Regex. You can then press the Test button to verify that this is supplying
you with 16 digit numbers.



5. Again, we’ll choose to Enforce Data Integrity. In this case, there is a second option – a Label.
Using the same label for a pair of data masks that use the same regex will allow them to enforce
data integrity across multiple fields. Enter CardNumbers as the Label.
6. Return to the Recording Studio, and again record the MakeBooking operation.
7. You should see that the credit card number is now masked using 16 digit numbers, as specified
within the data mask. If you record further booking requests, you should also notice that the
values displayed change as you change credit card numbers.



18 Data Model Stubs
So far, the message‐based stubs that we have dealt with have had a fairly simple way of dealing with
data. Each one has used the data that is provided when the stub is loaded into memory, either
hardcoded or through a data source, and will use that same data each time the stub is started.
However, more complex systems cannot be effectively simulated when data is treated in this way. We
may require persistent storage of data so that a stub can save information between operations. This
would allow, for example, a stub to react correctly when asked to list customers that had been created
via a different operation. In order to do this, we’ll need to support CRUD operations – Create, Read,
Update, and Delete. Between these 4 operations, we can perform any action that we’ll need on our
data. We’ll also need a way of storing the data.
A data model allows us to both understand the data held by the system that we want to simulate, and
to provide persistent storage. Data is held inside a set of entities, each with a set of attributes.
During the exercises for this chapter, we’ll be using the booking system again, though rather than
simply creating new bookings, we’ll also want to simulate finding bookings, updating bookings, and
deleting bookings. In order to do this, we’ll need to record the parts of the system that handles this
functionality. The system that we’re using will also have other messages that we won’t focus on for the
moment – these will deal with the user’s status (logged in or logged out). For the moment, our stub will
assume that the user is always logged in; in the following chapter, we’ll look at how we can deal with
state and user sessions.

18.1 Exercise: Recording a Web Service without a WSDL
In order to get started with the various services that deal with managing bookings, we’ll need to define
operations within the Architecture School. However, in this case, we don’t have a WSDL. We’ll look at
recording the HTTP traffic passing through our proxy; in the following exercise, we’ll use this traffic to
help put together our data model stub.
1. Return to the Logical View of the Architecture School.
2. Select the WWTravel service component, as we’ll be adding the booking amendment services
inside that. Right click, and select New > Web > HTTP Connection. Call this WWTravel_HTTP.
3. Right click on the WWTravel_HTTP component, and select Set Binding In > Local > Create New
Web Server.
4. You’ll then be able to set up the physical connection in our current environment. The server is
on the localhost, using port 9080, so enter those settings in the Settings tab.

5. On the Client tab, we should enter the settings for the HTTP Proxy. If we ever wanted to test
our stub out with Rational Integration Tester, this would let any tests know to use the proxy for
their traffic, rather than talking to the web service directly. Remember that just because we



have set the proxy up for Tomcat does not meant that it is set up for other client applications –
we need to set up each client application separately, and since Rational Integration Tester is
another client when it is running tests, then it is included in this category. Set the Proxy Host to
localhost, and the Proxy Port to 3128.

6. As with the HotelFinder example, we’ll need to supply a different port to use when running a
stub, since port 9080 is already in use by the live service. Switch to the Server tab, and set the
Port in the Socket Server Overrides section to 9085.
7. There are two methods to record traffic over a HTTP transport – recording by packet capture,
or by using the proxy provided by the Rational Integration Tester Platform Pack. We’ll be using
the proxy, so switch to the Recording tab, and set the Recording Mode to External Proxy
Server.

8. Press Test Transport to verify that the transport has been set up correctly, then press OK
twice to return to the Logical View.
9. Switch to Recording Studio, and delete any existing Event Monitors. You’ll also want to clear
any previous messages at this stage.
10. Add a new event monitor, and select the WWTravel_HTTP connection as the event monitor. Start
recording.
11. In your web browser, return to the main Worldwide Travel page. Press the Amend My Flight
Booking button. You’ll be presented with a login screen. You can just press the Login button
here, as no real details are required by our example system.
12. You’ll then be able to search for a booking. Enter A00002 as the booking number, and press
Find.
13. You should then be presented with the booking details for Shinichi Nishimoto. Enter a middle
name for this booking, and press Update Booking Details.
14. You can now search for a second booking – search for A00003 this time, and update the details
to change the last name. You should now have two examples of finding and updating bookings.
15. Use the interface to find and cancel bookings for A00004 and A00005.
16. If you want, you can also go back and search for two bookings that do not exist. In our case, it
won’t matter too much, as we’ll handle that case by hand later on.



17. Finally, choose the Logout option so that we have an example logout message that we can use
later on.
18. Return to Rational Integration Tester’s Recording Studio. You should now have a long list of
request/reply pairs, describing the interactions we’ve just been through.

18.2 Creating a Data Model Stub and associated Operations
Note: The steps you’ll need to carry out in this exercise may be different, depending on the order in
which you’ve recorded messages in the previous exercise. The first few steps will be the same, but the
steps dealing with building a data model from recorded messages may require you to deal with
different pages of the wizard in a different order.
1. If we look at the messages we’ve recorded, we’ve covered updating, deleting, and looking up
data. We haven’t got anything to do with creating new entries. You’ll recall that this is done
through the MakeBooking operation. Add that as an event monitor again, and continue
recording.
2. In your web browser, make a pair of new bookings (each with different details, using both a
Barcelona and an Edinburgh flight), then go back to Rational Integration Tester to make sure
that they’ve been recorded successfully. Stop recording now.
3. Now that we’ve covered all of the operations required for managing bookings, we can create a
data model stub. To start this process, make sure that you can see all recorded messages (ie,
nothing is filtered out), and select all messages.
4. Press Save to start the Save Recorded Events wizard. As with previous stubs, select stubs on
the first page of the wizard. On the second page, choose to Store data in a data model.
5. The third page will attempt to identify the operations that make up our recorded events. For
SOAP messages, this will be taken from the SOAP Action in the header if it’s present. In our



case, this will work just fine, so you should see new operations called
GetBookingByReservationNumber, UpdateBooking, and CancelBooking, in addition to the
existing MakeBooking. These will cover the operations that will be used by our data model. In
addition, you’ll also see the operations isLoggedOn, logon, and logoff, which are used to track
individual sessions. If this is the case, you can just press Next.

6. The next page will ask where the new operations should be created – we could choose the
WWTravel service component, but it would be preferable to group these operations separately.
Press Select to choose a different service component.
7. In the dialog that appears, you’ll see the service components that currently exist in the project –
we’ll create a new one underneath the WWTravel service component. To do this, select the
WWTravel service component, and press the New Service Component button. When
prompted, call the new service component BookingManagement, and press OK. It should then
appear below the WWTravel service component.



8. Press OK again, and you should return to the wizard. Press Next.
9. Next, events should be grouped into pairs of request/reply messages. In cases where Rational
Integration Tester is unable to recognize these groupings, you might need to select
corresponding pairs, and press the Group button to put them into their own groups. Once
you’re satisfied that each pair is inside its own group, press Next.
10. The next part of the wizard is fairly lengthy, but most pages are fairly similar. We’ll be selecting
the fields that are going to be used in our data model, and how they will be used. The first page
will probably be the request message for the CancelBooking operation. You’ll notice that this is
presented in a very similar fashion to the parameterized stubs we saw earlier.

11. You will notice that several of the text fields within the message have been assigned an Entity
and an Attribute within that Entity; the Status column for each of these is also listed as New, as
in the screenshot above. This has happened for any field where different data was detected
between messages. As we want to model the booking data, this is fine.
12. Press Next, and you’ll see the response message for the CancelBooking operation.
13. As in the response message, there is a reservation number. However, while it has also been
assigned to the same entity – BookingType – it has been given a different attribute. Select that



field, and press the Attribute button. This will allow you to assign this field to the
reservationNumber attribute that we created previously. This lets the wizard know that these
two fields represent the same data.
14. We will also want to mark the reservation number as a key field, so we can use it for lookups
later on. Tick the checkbox in the key column for that field – you should notice that the
format ^Ad{5}$ will be generated for you. This is done by looking at the reservation numbers,
and generating a regular expression that covers all of them.



15. Press Next, and you will be shown the request message for getting a booking. You should not
need to change anything here, as it should state that the reservation number is already
recognised within the data model.

16. Press Next again, and you’ll see the response message for this operation. You’ll notice that a
group of fields are assigned to new attributes – but we already have attributes for each of these.
Select each one, and press the Attribute button to assign them to the existing attributes. In the
case of the reservation number, the wizard should recognize this as a key field, and display the
appropriate format.



17. In addition, we have two new pieces of data here – the flight number, and the week number.

Select each one of these, and press the Entity button to assign them to the BookingType
entity. New attributes will be created automatically.



18. On the next screen, you will see the request message for the Makebooking operation. You will
notice that a lot of fields are being assigned to the PaymentType entity. As this is the only
message where payment details are used, we will not worry about these, so Ignore all of them.
Make sure you also choose to Ignore the row of the data that is assigned to the payment
attribute, as it would be linked to the PaymentType which we are not going to create.



19. The following screen is the response message for MakeBooking. There is only one piece of data
here that we are concerned with – the reservation number. As the field is called
newReservationNumber, this is not automatically matched with the existing reservationNumber
attribute. Select that row, and press the Attribute button to re‐assign it to the
reservationNumber attribute. As before, it should recognize that this is a key field.



20. After the MakeBooking messages, we should see the UpdateBooking request message. As before,
you will probably notice that several fields have been assigned to new attributes, when the
existing attributes could take care of this data for us. Assign this information (names, gender,
etc.) to the appropriate attributes.



21. The response message for UpdateBooking should not need any modifications; just check that
the reservation number has been assigned appropriately, and is a key field.

22. After this, the rest of the messaging screens will deal with the requests and responses for the
isLoggedOn, logoff, and logon messages. Make sure you that all fields have a status of Ignored
as you press Next through each message.
23. Eventually, you will reach the summary page. Check the information here. The summary should
report that a group of operations will be created, as well as a data model. The data model should
include a single entity – the BookingType entity. It will contain a number of attributes (all of
type String):
o reservationNumber
o firstName
o middleName
o lastName
o gender



o flightNumber
o weekNumber
o price
24. If there are extra elements listed in the data model, you will need to press the Back button
through the messages to find out why. If there is login information, this will probably be in the
login messages, and should be ignored when creating the data model stub. If there are
attributes that appear to duplicate other attributes, go back to find them, and set the attributes
to match up. Return to the summary page if you have left it to fix any issues.
25. Give the stub the name DMStub1, and call the data model BookingModel.

26. Press Finish to create the data model and the stub. We’ve now created a stub which can create,
read, update, and delete, using multiple operations and multiple transports. In the next exercise,
we’ll look at how we can make it a bit more intelligent before we attempt to use it.

18.3 Editing the Data Model Stub
1. Switch to the Test Factory, and open up DMStub1. You should see that there are 7 transitions
available to you – one for each operation.



2. Let’s look at these events one by one. We’ll start off with the MakeBooking event, so select that.
3. On the Input tab, the Guard is currently set to Record Exists. As we don’t care if a booking
already exists when we’re making a new one, set this to None.
4. On the Business Logic tab, set the Data Model to Create. This will create a brand new entry in
our data model that can be referred to by the other operations.
5. CancelBooking will need to have its Guard set to Record Exists, as we can’t delete something
that doesn’t exist. As this is the default, we can leave that setting as‐is, but we will need to go to
the Business Logic tab for that transition, and make sure that the Data Model is set to Delete.
6. Similarly, UpdateBooking requires a record to exist, so make sure that the guard is set to
Record Exists. Within the Business Logic tab, the Data Model for this transition should be set
to Update or Create.
7. Finally, we’ll need to look at the transition for the GetBookingByReservationNumber operation.
This one’s a little bit trickier, as it should work differently, depending on whether or not the
record for the given reservation number exists. To handle this, we’ll create a second transition
for this operation, to allow us to cover both cases – where it exists, and where it doesn’t exist.
Select the transition for GetBookingByReservationNumber, and press the Clone button in the
toolbar above.
8. Select one of these two transitions, and on the Input tab, set the Guard to Record Doesn’t
Exist. On the same transition, the Business Logic tab should state that the Data Model is set to
None. On the output tab, you’ll need to find the Details node, and delete it, since we can’t
return any reservation details for something that doesn’t exist.
9. The transition for GetBookingByReservationNumber with a Guard of Record Exists can be left
alone.
10. We still need to deal with the operations controlling logins and sessions – we don’t want to deal
with this yet, but we’ll need to figure out a way of dealing with this. For the moment, the simple
cheat will be to log on to the system before starting the stub, then having our stub state that we
are always logged on (we’ll need to log on first, so that tomcat has a session ID). To do this, edit
the transition for the isLoggedOn operation, and go to the Output message. Set the Text node
for the isLoggedOnReturn Element to 1.
11. We also want to make sure that there is no Guard for the login operations – these shouldn’t care
if records exist within the data model; in fact, as we ignored any data inside these messages as
far as the data model is concerned, we don’t even have anything to look up records with
anyway.



12. Check that your set of transitions now appears as in the image below, and Save the stub.

13. Return to your web browser, and make sure that you’ve logged into the system (so that we’ve
got a session id), then run DMStub1 in Rational Integration Tester.
14. Using the web interface, you should now be able to create new bookings, look up bookings, and
update bookings. The data inside the model will be limited to the interactions we recorded
earlier, so we’ll have a fairly small data set. Given this, while we could delete information from
the data model, we won’t do this at the moment, as we’ll be developing this stub further in the
following exercises.
15. Stop the stub once you’re done.



19 State and Sessions
Advanced stubs may require the ability to track their internal state – for example, a live system may
expect different inputs at different stages of a given business process, and any virtualization of that
should also act in the same way.
Similarly, a stub may need to act differently to different users, depending on the state of that user’s
interactions with the system. The simplest example of this, and the one we’ll be using in this module, is
tracking session information for a user who might be logged in or logged out.
To do this, we’ll create a session key when a user logs in. By storing the session key into a system tag
whenever the user sends a message to the system, Rational Integration Tester will automatically look
up the state of the user’s session, and act appropriately. We can then also assign states to the
transitions we’ve created, and add extra states that will act differently in different states.

19.1 Exercise: Tracking User Sessions
1. Within the DMStub1 that we’ve been using in the previous exercise, go to the Properties tab
(above the Transitions). In here, we can set up the available states for our stub.
2. Find the section of the screen dealing with sessions and states, and press the New State
button to add a new state. Call the first state LoggedIn, and press OK.
3. Create a second state in the same way, calling it LoggedOut.
4. Below these two, the Initial State should be set to LoggedOut.
5. We then need to create a Conversation Key – we can do this simply by typing in a name for the
tag that we’ll use to identify the current session. Call it sessionID (use the same case here, as
scripts in the following chapter are case sensitive, and make use of this).

6. Return to the Transitions tab of the stub, and find the logon transition. You should now be able
to edit the From and To columns here. Logging in will take us from the LoggedOut state to the
LoggedIn state.
7. This won’t be enough to track the state, though – for that, we’ll need to make use of the
conversation key that we just created. Go to the Business Logic tab for this transition, and set
the Data Model to Other.
8. Choose the Create Session action from the toolbar of actions, and double click it to edit it.
9. You should see the sessionID that we created earlier is listed here. Before we can generate a
value for this, we need to tell Rational Integration Tester what a sessionID looks like, using a
regular expression. In the Value Pattern column, enter the regular expression Sd{4}HAd{4}



10. Press Enter, and the Sample Value column should update to show you an example sessionID
based on the regular expression we’ve chosen. If this looks correct, then press OK.
11. By default, the Create Session action will have been added after the Send Output action. Since
we’ll need a sessionID to send in the output message, we don’t want to generate it after we
send the output. Swap the two actions around by dragging and dropping.
12. Go to the Output tab, and find the session ID that was being sent by this transition (at the very
end of the message). Edit the text, first by removing the old session key, then by right clicking in
the field and selecting Insert Tag > Built‐In > SESSION > KEY > sessionID.
13. Now, we’ll handle the logout operation. Set the From column to LoggedIn, and the To column to
LoggedOut.
14. In order to make sure we’re logging out the correct session, we need to check the sessionID. To
do this, go to the Input tab of this transition. At the very bottom of the message, there will be a
Text node holding a session ID, following the pattern we set up earlier. Edit the text in this field,
then right click and choose Insert Tag > Built‐In > SESSION > KEY > sessionID
15. The session ID should now be getting stored for you, as shown below:

16. This is all that we’ll need to do to match this logout action with the session created by the login
action. However, we still want to setup the isLoggedOn operation so that it responds
appropriately, depending on whether the user is logged in or not. To do this, it’ll need to cover
both possibilities – logged in and logged out. Let’s cover the logged in option first, so set the
From and To columns for the transition to LoggedIn.
17. In the Input tab, find the Text node for the session ID. As before, edit the field, right click, and
choose Insert Tag > Built‐In > SESSION > KEY > sessionID.
18. On the Output tab, note that the return value should be set to 1 (we did this in the previous
exercise to state that the user was always logged in).
19. Now Clone the transition for the isLoggedOn operation. In one of the copies, change the From
and To columns to the LoggedOut state. In this copy, you’ll also want to change the return value
on the Output tab to 0.
20. At this stage, we can optionally apply state to the other operations (with the exception of
MakeBooking, which did not track any session information). To do this, simply store the session
ID on the Input tab of the transition into the SESSION/KEY/sessionID tag again, and set both
the From and To columns for the transition to LoggedIn. The transition will then only work if
the session is currently logged in. Note: If you attempt to set the From state without storing a
value into the sessionID, the transition will no longer work; this is because it would be
attempting to look up an empty value for the sessionID, and will not find an empty sessionID
that is in the LoggedIn state.



21. Save the stub and run it.
22. From the web interface, you should now be able to log in and log out of the system, in addition
to managing bookings.
23. Stop the stub once you are done.



20 Behaviours
In this chapter, we’ll complete our booking management stub by adding behaviours to it. As we’ve
seen, we can already add custom logic to a stub; behaviours let us go beyond this by allowing us to add
custom logic that responds to events besides messages. This is how you can make stubs proactively
publish messages that are not just ‘responses’ to an incoming message.
Rational Integration Tester comes with two sample behaviours: the first is the Lifecycle behaviour,
which allows us to execute certain actions when the stub starts up or shuts down. This can be used to
set up and later clean up any resources that may be required by the stub. The second is the Timer
behaviour – this allows us to set a timer, and after a set period of time, the stub will receive an event,
which it can then respond to.
Other behaviours can be added to Rational Integration Tester, though these will require custom Java
code to be written. For example, a behaviour could be created to simulate a message feed of some sort,
sending data updates to the stub as appropriate.
In this exercise, we’ll add a timer behaviour to the stub we’ve been creating to manage bookings. This
will automatically log out the user after 30 seconds of inactivity.

20.1 Exercise: The Timer Behaviour
1. Switch to the Test Factory perspective. You should be looking at the data model stub that we’ve
been modifying during the past two modules.
2. Open the Behaviour tab. It will be nearly blank, so press the Add button to add a new
behaviour.
3. The Behaviour dialog will appear. Select the Timer behaviour in the top left to view details
about it.



4. In the bottom half of the dialog, we can see the four ways we can interact with the timer
behaviour. We have three functions that we can call within scripts – scheduleTimerEvent,
scheduleRepeatingTimerEvent, and cancelTimerEvent – indicated by arrows pointing to the
right. We also have a callback (indicated by the arrow pointing left) named onTimerEvent,
which will provide an event to our stub when a timer runs out. We’ll make use of most of these
later.
5. Our timer behaviour needs a name, in the Instance field. Call it logoutTimer, then press Add.
6. The logoutTimer then appears in the Behaviour tab. Note that there is a description of it to the
right hand side, while below there is an area for configuration of the behaviour. As the timer
behaviour does not have any settings, this is blank.



7. Return to the Transitions tab.
8. We can now set a timer. As we want to set a timer that will log the user out after a period of
time, the best place to start will be the logon transition, so select that.
9. To start a timer, we’ll need to add some of our own custom logic, so go to the Business Logic
tab of this transition, and set the Data Model to Other.
10. Add a new Function action by right clicking below the existing Send Output test action and
selecting New > General > Function.
11. Double click on the Function action to edit it. Make sure that you’re looking at the Function
tab, and that the drop down directly underneath is set to ECMAScript.
12. Type in the following code:
logoutTimer.scheduleTimerEvent("timerID", tags["SESSION/KEY/sessionID"], 30,
java.util.concurrent.TimeUnit.SECONDS)
13. Let’s analyze this, so we understand what we’re doing. The first parameter is the identifier that
we’re giving the timer, so that we can cancel it or reset it later on if required. Second, we’ve
used the sessionID tag. The second parameter will be given back to the stub when the timer
runs out – we’ve put the sessionID in here, so that we know which session to log out at that
time. The third and fourth parameters specify how long the timer should run for – in our case,
30 seconds.
14. You may have spotted a problem with this – the fact that we’ve hardcoded the identifier for the
timer means that we’re not going to be able to set timers for multiple users. If we reset the
timer using the same identifier when another user logs on, the current timer will be lost. Let’s
modify this so that we can use multiple timers, by using the sessionID as the identifier. This will
give you the following:
logoutTimer.scheduleTimerEvent(tags["SESSION/KEY/sessionID"],
tags["SESSION/KEY/sessionID"], 30, java.util.concurrent.TimeUnit.SECONDS)



15. Press OK to close the Function action. Within the Business Logic, drag the Function action so
that it is the middle action – it will need to be after the Create Session action, or else we won’t
have a sessionID to provide to the timer.

16. Next, we’ll need to have something to act on the timer. We’re going to add a new transition to
the stub to do this, so Add a new transition.
17. First, as we’re not acting on a message from the user, we’ll need to change the Actor column in
our new transition. Set it to the logoutTimer. The Event column will automatically be set for us,
to the onTimerEvent callback.
18. We’ll also need to set the From and To columns. As the timer should take us from the LoggedIn
state to the LoggedOut state, set the From column to LoggedIn, and the To column to
LoggedOut.

19. Finally, we’ll need to check which session we’re logging out. To do this, go to the Input tab of
the transition. You’ll notice that the onTimerEvent callback will generate a short message for us.
The parameter field in this message will hold the sessionID, as this is what we put into the
parameter field when we started the timer.
20. Double click on the parameter to bring up the Field Editor, and go to the Store tab of that
dialog.
21. Press New to add a new Store action, and set the tag to SESSION/KEY/sessionID. Press OK once
you’re done. The Input tab should now look like so:

22. We’ve now done the bare minimum in order to use the timer behaviour to automatically log out
a user, but we’ll develop this a bit further. If a user logs out, we should probably cancel the
timer. To do this, open up the logoff transition, and go to the Business Logic in there.



23. Add a new function action as we did before, with the following script:
logoutTimer.cancelTimerEvent(tags["SESSION/KEY/sessionID"])
24. Press OK to close the Function action. In this case, it shouldn’t matter too much if we cancel the
timer before or after we send the logout response message.
25. Currently, our timer will automatically log the user out after 30 seconds, no matter what they’re
doing. We should reset the timer if the user carries out any of the actions that require them to
be logged in (checking reservations, updating reservations, or deleting reservations). To do this,
all we need to do is to set the timer to 30 seconds again, using the same identifier (if we used a
different identifier, we’d be creating a second timer, and the original timer would still terminate
at the time set when it was first generated). The easiest way to do this is to copy and paste the
function action we used when we first set the timer up, so go back to the Business Logic tab of
the logon transition, and Copy the Function action used there.
26. Next, go into the Business Logic of each of the GetBookingByReservationNumber,
CancelBooking, and UpdateBooking transitions. Switch the Data Model here to Other – you’ll
notice some test actions here that manipulate the data model, but don’t get too worried about
these. Instead, simply Paste the Function action, and place it before the Send Output action.
27. Save your stub, and try it out. Note that you may find that, if you are automatically logged out,
the system times out. This is because a number of the operations only work if the current
session is logged in – if it is not logged in, they ignore the input message, and do not send back
any response. You do not need to be too concerned about this – it is a limitation of the test
environment, as it doesn’t provide a way for those operations to report a login failure.



21 Legal Notices
 The following paragraph does not apply to the United Kingdom or any other country where
such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES
CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON‐INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement may not apply to you.
 This information could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein; these changes will be incorporated in new editions
of the publication. IBM may make improvements and/or changes in the product(s) and/or the
program(s) described in this publication at any time without notice.
 If you are viewing this information in softcopy, the photographs and color illustrations may not
appear.
 Any references in this information to non‐IBM websites are provided for convenience only and
do not in any manner serve as an endorsement of those websites. The materials at those
websites are not part of the materials for this IBM product and use of those websites is at your
own risk.
 Any performance data contained herein was determined in a controlled environment.
Therefore, the results obtained in other operating environments may vary significantly. Some
measurements may have been made on development‐level systems and there is no guarantee
that these measurements will be the same on generally available systems. Furthermore, some
measurements may have been estimated through extrapolation. Actual results may vary. Users
of this document should verify the applicable data for their specific environment.
 Information concerning non‐IBM products was obtained from the suppliers of those products,
their published announcements or other publicly available sources. IBM has not tested those
products and cannot confirm the accuracy of performance, compatibility or any other claims
related to non‐IBM products. Questions on the capabilities of non‐IBM products should be
addressed to the suppliers of those products.
 All statements regarding IBM's future direction or intent are subject to change or withdrawal
without notice, and represent goals and objectives only.
 This information contains examples of data and reports used in daily business operations. To
illustrate them as completely as possible, the examples include the names of individuals,
companies, brands, and products. All of these names are fictitious and any similarity to the
names and addresses used by an actual business enterprise is entirely coincidental.
 This information contains sample application programs in source language, which illustrate
programming techniques on various operating platforms. You may copy, modify, and distribute
these sample programs in any form without payment to IBM, for the purposes of developing,
using, marketing or distributing application programs conforming to the application
programming interface for the operating platform for which the sample programs are written.
These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot
guarantee or imply reliability, serviceability, or function of these programs. The sample



programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any
damages arising out of your use of the sample programs.

Trademarks and service marks
 IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corp., registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the web at www.ibm.com/legal/copytrade.shtml.
 Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other
countries, or both.
 Java and all Java‐based trademarks and logos are trademarks or registered trademarks of
Oracle and/or its affiliates
 Other company, product, or service names may be trademarks or service marks of others.


2012 10 23_2649_rational_integration_tester_vi

More Related Content

Viewers also liked (7)

Similar to 2012 10 23_2649_rational_integration_tester_vi (20)

More from Darrel Rader (7)

2012 10 23_2649_rational_integration_tester_vi