Rit 8.5.0 virtualization training student's guide

Virtualization with IBM Rational
Integration Tester

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

© Copyright IBM Corporation 2001, 2013.

VIRTUALIZATION WITH IBM RATIONAL INTEGRATION TESTER

1

INTRODUCTION ........................................................................................................................ 5

2

USING VIRTUALIZED APPLICATIONS FOR TESTING ........................................................................ 6
2.1
2.2

THE OLD WORLD AND THE NEW WORLD ................................................................................ 7

2.3

WHEN TO USE VIE............................................................................................................. 7

2.4

USING VIE STRATEGICALLY ................................................................................................ 7

2.5

SOLVING PROBLEMS WITH VIE ............................................................................................ 8

2.6
3

INTRODUCTION .................................................................................................................. 6

VIRTUAL APPLICATIONS: SIMPLE TO COMPLEX ...................................................................... 9

ARCHITECTURE AND SETUP .................................................................................................... 10
3.1
3.2

4

OVERVIEW ...................................................................................................................... 10
DOMAINS AND ENVIRONMENTS .......................................................................................... 11

PROJECT SETUP .................................................................................................................... 13
4.1
4.2

CREATING A NEW PROJECT............................................................................................... 14

4.3
5

THE INITIAL SCREEN ......................................................................................................... 13
EXERCISE: CREATING A NEW PROJECT .............................................................................. 15

COMPLEX ENVIRONMENTS ...................................................................................................... 18
5.1
5.2

MANAGING FLIGHT BOOKINGS ........................................................................................... 18

5.3

FINDING AND BOOKING HOTELS ......................................................................................... 19

5.4
6

INTRODUCTION ................................................................................................................ 18

FLIGHT ADMINISTRATION .................................................................................................. 20

SYNCHRONIZATION ................................................................................................................ 22
6.1
6.2

7

INTRODUCTION ................................................................................................................ 22
EXERCISE: SYNCHRONIZING WITH A WEBSPHERE APPLICATION SERVER ............................. 23

BUILDING A SYSTEM MODEL FROM RECORDED EVENTS .............................................................. 26
7.1
7.2

RECORDING MQ MESSAGES ............................................................................................. 26

7.3

EXERCISE: SETTING UP THE TRANSPORTS ......................................................................... 27

7.4

EXERCISE: ADDING THE FLIGHT BOOKING MESSAGE SCHEMAS ............................................. 28

7.5

EXERCISE: RECORDING EVENTS FROM A TRANSPORT ......................................................... 29

7.6

EXERCISE: BUILDING OPERATIONS FROM RECORDED EVENTS .............................................. 31

7.7
8

INTRODUCTION ................................................................................................................ 26

EXERCISE: COMPLETING THE SYSTEM MODEL .................................................................... 38

MANAGING RECORDED MESSAGES .......................................................................................... 41
8.1

INTRODUCTION ................................................................................................................ 41

8.2

EXERCISE: RECORDING EVENTS FROM AN OPERATION ........................................................ 41

Page 1 of 154 © IBM Corporation 2001, 2013


9

CREATING AND EXECUTING A BASIC STUB ................................................................................ 44
9.1

INTRODUCTION ................................................................................................................ 44

9.2

EXERCISE: MAKING A SIMPLE STUB FROM RECORDED MESSAGES......................................... 44

9.3

EXERCISE: EXECUTING A STUB FROM RATIONAL INTEGRATION TESTER ................................ 46

9.4

EXERCISE: MODIFYING THE STUB AS IT RUNS ..................................................................... 48

10

PUBLISHING AND DEPLOYING STUBS .................................................................................... 50

10.1

INTRODUCTION............................................................................................................. 50

10.2

EXERCISE: USING RATIONAL TEST CONTROL PANEL ....................................................... 50

10.3

EXERCISE: PUBLISHING A STUB ..................................................................................... 51

10.4

EXERCISE: DEPLOYING A STUB ...................................................................................... 52

11

WSDL SYNCHRONIZATION .................................................................................................. 55

11.1

A SECOND TEST SYSTEM: HOTELFINDER ........................................................................ 55

11.2

SYNCHRONIZATION ....................................................................................................... 55

11.3

EXERCISE: SYNCHRONIZING WITH THE HOTELFINDER WSDL .......................................... 55

12

CREATING A STUB FROM MEP ............................................................................................. 62

12.1

THE STUB EDITOR......................................................................................................... 62

12.2

EVENTS ....................................................................................................................... 62

12.3

EXERCISE: CREATING A STUB FROM THE MEP ................................................................ 63

12.4

USING THE HTTP PROXY .............................................................................................. 64

12.5

EXERCISE: HTTP STUB EXECUTION ............................................................................... 66

12.6

EXERCISE: HANDLING NEW REQUEST OPTIONS ............................................................... 68

12.7

EXERCISE: MESSAGE DIFFERENCING ............................................................................. 70

13

STORING AND MANIPULATING DATA ...................................................................................... 74

13.1

TAGS AND THE TAG DATA STORE .................................................................................. 74

13.2

CREATING TAGS ........................................................................................................... 75

13.3

USING TAGS ................................................................................................................ 77

13.4

EXERCISE: CREATING AND USING A TAG ......................................................................... 77

13.5

SCRIPTING................................................................................................................... 78

13.6

EXERCISE: STUBBING ADDNUMBERS.............................................................................. 78

13.7

GUARDS ...................................................................................................................... 79

13.8

EXERCISE: USING GUARDS............................................................................................ 80

14

DATA DRIVEN STUBS ........................................................................................................... 82

14.1

DATA SOURCES ............................................................................................................ 82

14.2

EXERCISE: CREATING PARAMETERIZED STUBS FROM RECORDED MESSAGES ..................... 82



14.3

EXERCISE: CREATING A DATA SOURCE WITHOUT RECORDED MESSAGES ........................... 88

14.4

EXERCISE: DATA DRIVING WITH REPEATING ELEMENTS .................................................... 93

15

SIFT AND PASS THROUGH .................................................................................................... 97

15.1

INTRODUCTION............................................................................................................. 97

15.2

EXERCISE: BASIC SIFT AND PASS THROUGH .................................................................... 98

15.3

THE PASS THROUGH ACTION ....................................................................................... 100

15.4

EXERCISE: SIFT AND PASS THROUGH WITH THE PASS THROUGH ACTION ......................... 100

16

STUB CONFIGURATION ...................................................................................................... 102

16.1

INTRODUCTION........................................................................................................... 102

16.2

EXERCISE: INPUT TAGS ............................................................................................... 103

16.3

SIFT AND PASS THROUGH ON RATIONAL TEST CONTROL PANEL ..................................... 105

16.4

EXERCISE: SIFT AND PASS THROUGH WITH INPUT TAGS ................................................. 105

17

MANAGING STUBS IN THEIR ENVIRONMENT .......................................................................... 108

17.1

SCENARIOS ............................................................................................................... 108

17.2

EXERCISE: CREATING AND USING A SCENARIO .............................................................. 108

17.3

LOCKING THE ENVIRONMENT ....................................................................................... 109

17.4

EXERCISE: LOCKING THE ENVIRONMENT ....................................................................... 109

18

DATABASE STUBS ............................................................................................................ 111

18.1

INTRODUCTION........................................................................................................... 111

18.2

THE RATIONAL INTEGRATION TESTER JDBC DRIVER ..................................................... 111

18.3

THE SIMULATION DATABASE ........................................................................................ 113

18.4

EXERCISE: RECORDING SQL ...................................................................................... 114

18.5

EXERCISE: CREATING AND EXECUTING A DATABASE STUB .............................................. 115

18.6

EXERCISE: MODIFYING THE SIMULATION DATABASE ....................................................... 118

19

ALTERNATIVE MESSAGE FORMATS ..................................................................................... 120

19.1

INTRODUCTION........................................................................................................... 120

19.2

EXERCISE: COBOL COPYBOOK MESSAGES ................................................................. 120

20

DATA MASKING................................................................................................................. 125

20.1

OVERVIEW ................................................................................................................. 125

20.2

EXERCISE: FIXED VALUE SUBSTITUTION........................................................................ 125

20.3

EXERCISE: DATA SOURCE SUBSTITUTION ..................................................................... 127

20.4

EXERCISE: AUTOMATIC VALUE CREATION ..................................................................... 128

21

DATA MODEL STUBS ......................................................................................................... 130

21.1

INTRODUCTION........................................................................................................... 130



21.2

EXERCISE: RECORDING MESSAGES FOR THE DATA MODEL STUB ..................................... 130

21.3

EXERCISE: CREATING A DATA MODEL STUB FROM RECORDED MESSAGES ........................ 132

21.4

EXERCISE: EDITING THE DATA MODEL STUB .................................................................. 140

22

STATE AND SESSIONS ....................................................................................................... 143

22.1

INTRODUCTION........................................................................................................... 143

22.2

EXERCISE: TRACKING USER SESSIONS ......................................................................... 143

23

BEHAVIOURS .................................................................................................................... 148

23.1

INTRODUCTION........................................................................................................... 148

23.2

EXERCISE: THE TIMER BEHAVIOUR ............................................................................... 148

24

LEGAL NOTICES ................................................................................................................ 153



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 Rational
Integration Tester and the Rational Test Virtualization Server, and how best to use them in testing
Message Oriented Middleware (MOM) applications. This course will cover the following topics:







Present the various perspectives in the design tool, Rational Integration Tester, describing
how and when they are used
Demonstrate how Rational Integration Tester and Rational Test Virtualization Server 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 use 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, 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 might find
that some components of the system are unavailable. This could be for a number of reasons. It could
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 might be in use by others and cannot
be shared, or might 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 might 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 might 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 might 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 might not be currently available. This can cause delays, due to
dependencies on the components in question.
The Virtual Integration Environment (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 might
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 might present a
GUI to a user, or it might 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 might already be familiar with the concept of a virtual machine (VM). Virtualization as
implemented with VIE is more granular than using virtualization with a VM. 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 might
want your virtual application to send in erroneous data for negative testing of your system.



2.2 The old world and the new 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
address this.
VIE moves testers into a new world where they build and maintain their own stubs. In fact, testers
can go even further and stubs can become virtual applications. VIE does not require any coding;
virtual applications are easily maintained and universally understood, ensuring maximum reuse.

2.3 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 puts a lot of strain on test teams and is
the reason that VIE exists. VIE helps in the following three 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 system under test by being in control of the services
(or more specifically, the responses from those services).
With these three things in mind, we can begin to think about the situations that VIE might be
applied.

2.4 Using VIE strategically
VIE is designed to be applied in all test phases from unit testing to UAT. A golden rule in testing is:
always test as completely as possible. We know that when we are unit testing individual operations
or services that we might 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.5 Solving problems with VIE
There are a number of problems that can be solved using VIE. A selection of these is described
below:


Your testing project might be heavily reliant on integration with third parties. This can be
immensely frustrating and costly. VIE can virtualize third 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 might 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 might not require access to production sized version of the application.
Additionally, you might 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 might be too expensive to build
that test environment. It might take too long to build it. It might be that the test environment
is being used by someone else for the duration of your project. VIE stands in to virtualize
applications.

2.6 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.
Stub Type

Description

Simple

Hard‐coded response returned for given input.

Nondeterministic

One of n hard‐coded responses.

Data driven

Input and/or output data specified in external data source (Excel,
file, database).

Model driven,
stateful

Input and/or output data kept in data model with complex
relationships. Supports CRUD and other stateful behaviour.

Behavioural

Provides prepackaged functionality, such as shopping baskets, real‐
time data feed, trading exchange, and order matching.

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 toward more complex stubs that track data
models and behaviors.



3 Architecture and setup
3.1 Overview
In order to introduce VIE, we need to take a look at the different components that you can use while
working with it. These tools are Rational Integration Tester, Rational Test Control Panel, 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
can 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 run stubs.
The Rational Test Control Panel is a separate tool that allows you to manage virtual services within
your environment. Generally, after the development of a stub, it will be published from Rational
Integration Tester to Rational Test Control Panel. The stub is then stored within a repository on the
server. From this repository, each virtual service can 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 can 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 can 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
Rational Test Control Panel. 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 might be served by one or more Rational
Integration Tester projects, depending on how large or small the domain is, and how many Rational
Integration Tester or Rational Test Virtualization Server 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 Rational Test Control Panel. For example, unique business groups within an
organization might want to manage stubs independently from each other.
While being developed and run inside Rational Integration Tester, each stub uses the domain of the
Rational Integration Tester project. When they are published onto Rational Test Control Panel, they
can be published into that domain, or another domain. This allows us to control stubs within a
given domain through Rational Test Control Panel; 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 Rational Test Control Panel, they can be started and stopped
through the Rational Test Control Panel 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 can 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 Rational Test Control Panel. 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 Rational
Test Control Panel 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 Rational Test Control Panel, they can 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 might exist within multiple
environments within that domain.



4 Project setup
4.1 The initial screen
Once configuration of our system is complete, we are 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.
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.



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 the following four 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, with the settings available to edit 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 window (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 results database, which we will be using during this training
course. The results 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 results database, which can be an IBM DB2 MySQL, MS
SQL, or Oracle database. Once it is set up, the database can be shared across multiple users and
multiple projects.
The other server settings available are for Rational Test Control Panel and the Results Server
(legacy users only). Rational Test Control Panel 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 results database; this functionality is now provided by Rational Test Control
Panel, 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.
Finally, we can configure a connection to change management tools such as JIRA, HP Quality Center,
or any Open Services for Lifecycle Collaboration (OSLC) compliant change management system,
such as IBM 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, including 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 a new project
You will now create a new project for the Vacation Booking project, and configure a few settings
that will be required later in the project.
1. From the initial screen of Rational Integration Project, choose New Project and click OK.

2. Call the project Vacation Booking Virtualization.



3. Click Next.

4. The wizard will now display the Server Settings dialog box. At the top of this dialog box, in
the Results Database section, you should see details that have already been filled in for the
Database URL, User Name, and Password fields. If you need to re‐enter them, the settings
for the databases on the cloud instances are shown below. For other environments, ask your
trainer.

Settings

Value

Database URL

jdbc:db2://localhost:50000/resultdb

User Name

db2inst1

Password

Gr33nhat

5. Click Test Connection. A window should pop up stating that the connection was successful.
6. Below the database settings, we can connect to the Results Server and Rational Test Control
Panel. We will not be using the Results Server, but Rational Test Control Panel will be
needed later on. Use the following settings to connect:

Settings

Value

RTCP URL

http://localhost:7819/RTCP

Domain

Booking System



7. When you are satisfied with the details entered on this screen, click Finish.
8. The new project will be opened in Rational Integration Tester.
9. Add a new environment using Project > Create New Environment. Give the environment
the name Local, and click OK.
10. The Environments editor will open; click OK again to close it. You should then see that the
Local environment is selected in the title bar.



5 Complex environments
5.1 Introduction
The Platform training modules used a simple web service to introduce you to the toolset. This set of
modules will use a more complex example, the Vacation Booking system, which has several
different subsystems. Your instructor will 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 will 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



IBM WebSphere Application Server



IBM WebSphere MQ



IBM DB2

In this module, you will see how the different parts of this system fit together. In the following
modules, you will see two different methods that can be used to build the model of the system
under test: using synchronization and recorded messages.

5.2 Managing flight bookings
The Vacation Booking system has three separate subsystems. The first of these lets users book a
flight on a fictional airline. 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.

5.3 Finding and booking hotels
Following a flight booking, a user might 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.



Vacation Booking
webapp

SOAP/HTTP

getHotels

bookHotel

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



6 Synchronization
6.1 Introduction
The simplest option when building a model of the system under test is synchronisation. This
process analyzes 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
synchronization sources include:


WSDL



UDDI (including WebSphere Service Registry and Repository)



WebSphere Message Broker



WebSphere Application Server



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 synchronisation 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 can be added to
the project if required.

After synchronisation, the system under test might 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 click 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 click the Synchronise button, which will then update the Rational Integration Tester project
to resolve these differences.



6.2 Exercise: Synchronizing with a WebSphere Application Server
1. You can start synchronization from either the Logical View or Synchronization View of the
Architecture School. The process is largely the same either way, but in this example, you
will use the Logical View, so switch to that view now.
2. Make sure that nothing is selected, so that the next item you create will go at the top level.
3. From the toolbar, add a new IBM WebSphere Application Server.
4. A dialog box will open to start the synchronization process. The first thing you will need to
do is to set up the connection details of the application server. To do this, click the New
button.
5. A second dialog box will open. Configure the server with the host localhost and the SOAP
Connector Port 8880. The security settings can be left blank. When you are done, click OK.

6. You will then return to the first dialog box. Now that you have entered details for an
application server, click Next.
7. On the next screen, choose to Create a New Component and click Next again.



8. When asked which environment to use, choose the Local environment you created
previously, and click Next again.
9. On the final screen of the wizard, select Open Synchronization View and perform the
synchronisation.

10. Click Finish. The view will switch to Synchronisation view, and it will take a moment to read
in details from the system under test and update your project. Once it is done, you should
see the following in Synchronisation View:



11. If you switch between the different views in Architecture School, you should be able to see
the same new elements added in Logical View, Physical View and Schema Library.



7 Building a system model from recorded events
7.1 Introduction
As you might have noticed, 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 WebSphere MQ‐based system is able to provide information
on the available queues and topics, while being unable to provide any information on the
operations that access those resources, the dependencies between operations, or the message
schemas being used. In this case, we might be able to build a model of the system from recorded
data.
This is similar to the situation we see with the WebSphere Application Server and WebSphere MQ.
The application server can tell us of the existence of the queue manager, but it does not give us
enough information to be able to build up the operations that use that queue manager, or the
dependencies between those operations. We could build these by hand to fill in the missing gaps,
but instead we will use recorded messages to help us build the operations, leaving us with only a
few dependencies to add manually.

7.2 Recording MQ messages
Before you start doing this, we will take a quick look at how you will be recording messages on the
MQ transport. There are several different ways to record messages over this 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, refer to the Rational Integration Tester Information Center. 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 might 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 might choose to record just a given service if we have an operation definition (and so
know which queues to monitor), or to record all queues within the queue manager by recording the
MQ transport.

7.3 Exercise: Setting up the transports
In the Vacation Booking system, you should now have a lot of information about the web services
included in the system. However, the WebSphere Application Server does not provide information
on the operations that run over MQ. This is because the applications installed on the application
server do not provide enough information themselves. As you will not be able to synchronize with
the server to get information about these, you will record the WebSphere MQ transport, and build
up the operations that way.
1. Before you can record the transport, you will need to select your recording method. Go to
the Physical View of Architecture School.
2. Find the MQ Queue Manager called QM_vbooking, and double‐click it to edit it.
3. A dialog box will open showing the physical settings for your queue manager. Switch to the
Recording tab.
4. Under Queue Recording, set the Recording Mode to Dynamic Mirror Queues. All other
settings here can be left at their defaults.



5. Click OK to close the properties for the MQ Queue Manager.

7.4 Exercise: Adding the flight booking message schemas
In order to make working with recorded messages easier, you will also need to add the message
schemas that will be used in those messages.
1. Return to the Schema Library. Here, we need to add three new XML schemas, so click the
XSDs button on the left side of the screen
to show any available XML
schema definition (XSD) files; none should be shown at the moment.
2. We could use the XSD button in the Schema Library toolbar to add new XSD files to the
project, as we did with the addNumbers WSDL. However, as we have got a group of files, we
will just drag them into the schema library. Find the XSD Schemas folder on your desktop,
and drag it into the center panel of the Schema Library.
3. Rational Integration Tester should now show three new XSD files: BookFlightRequest,
BookFlightResponse, and Payment.



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

7.5 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 Tomcat shortcut on
your desktop.
2. 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 QM_vbooking infrastructure component. Note that there will be two: one
representing the transport as a simple JMS system, the other as a WebSphere MQ queue
manager. Choose the WebSphere MQ queue manager

5. Right‐click the QM_vbooking component, and select Record. The perspective will change to
the Recording Studio, and the QM_vbooking transport should be listed in the Event Monitors
panel.
6. Click the Start Recording button in the Events View toolbar to start recording events.
7. In a browser window, open the Vacation Booking home page. For a cloud image, this will be
listed in the favorites menu of your web browser; otherwise, ask your trainer.



8. Click the “Stansted to Barcelona” Book Now button. Here, you will have the opportunity to
book a flight and a hotel. For the moment, we will 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. The
values do not matter too much, 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 four events have been
recorded in the Events View.
11. Click the first message in the Events View. You should then see the message details
displayed 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.

7.6 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 will 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 vbooking.booking, vbooking.payment.multinational,
vbooking.payment.global, vbooking.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 clicking the Pause button.
3. Select all 12 messages before clicking the Save button.

4. The Recorded Events wizard will open, 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, and then click 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. Because 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 vbooking.booking – vbooking.booking.reply.
7. You will now be able to enter a new name below, so enter MakeBooking, and click Rename.
You will be asked if you want to apply this change to all other messages that were associated
with the same operation; click 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 side of the window (it will contain all of the data you
entered into the web form earlier). On the right side, select the second line of the message,
beginning text (String).



9. The Add Schema button should now be active. Click it, and the Select Schema dialog box
will open. On the left side, select XSDs, and then the BookFlightRequest XSD. Click 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 will need to go through the same process for the other operations in our system. Select
the two messages that are associated with the vbooking.payment.multinational queue,
give them an operation name of ProcessMultinational, and click 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 will see
that it only includes a single text field, so we will not 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 are done, the dialog box should look like
the following screen capture:



14. Click Next. You will then be able to select where in the model of the system these operations
should be created. The wizard will suggest putting them under the IBM WebSphere
Application Server component. We will create a separate service component inside that
instead. Click the Select button.
15. A Select dialog box will open. Click the Create New Service Component button and give
the new service component a name of Flight Bookings. Make sure the new service
component is selected then click OK to return to the wizard.



16. You will now see a summary, letting you know that Rational Integration Tester will be
creating four operations for you. Make sure that Open resource after finish is cleared, and
then click Finish to create all four operations. You can now switch back to the Architecture
School to see what has been created.



17. In the Logical View, you can now double‐click 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.

7.7 Exercise: Completing the system model
You have now added a new group of operations to your model of the system under test. Each of
these should have their message exchange pattern configured, based on the schema information
you supplied while creating them. Each operation will also have a dependency on the WebSphere
MQ transport, as that is the transport used within their message exchange pattern. However, the
operations also have other dependencies. For example, the MakeBooking operation needs to use a
payment processor to complete a booking. Remember that adding a dependency does not indicate
an input/output relationship. In this example, when MakeBooking receives a booking that contains
information for a Global card, it will use the ProcessGlobal operation to check that the booking is
acceptable, and after it has received that response, it will then send back its own response.
1. Within the Logical View of Architecture School, we now need to add some extra
dependency information to give ourselves a complete system model. First, 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 the MakeBooking operation, and then click
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 should have a dependency on the
Vacation Booking database. Add a dependency from ProcessMultinational to the VBooking
XA Datasource component in the same way, and then do the same for ProcessGlobal and
ProcessWorldwide.
4. Note that dependencies are only shown for items you have selected. However, the entire
dependency tree will be seen using the default preferences. To see this, select MakeBooking;
you will then notice that a lot of dependencies will be displayed, making the diagram difficult
to read.

5. This is difficult to read, and will only get more difficult if we make the model of the system
more complex, so we will change the preference settings to show a single level of
dependencies. Go to Project > Preferences, and in the General panel, set Max
dependencies shown to 1, then click OK. The diagram should then become easier to read.



8 Managing recorded messages
8.1 Introduction
You have already used the Recording Studio to record messages from the system under test, and
turn those into both tests and operations.
In this module, you will manage and filter the messages that you have recorded. These messages
will be used in the following module to create a stub.

8.2 Exercise: Recording events from an operation
Now that we have a model of the Vacation Booking 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 QM_vbooking transport. We will stop
monitoring this for the moment, so select it and click the Delete Event Monitor button to
remove the event monitor.
2. We will also clear the events we recorded in the previous exercise. To do this, click the Clear
All Events button in the Events View toolbar.
3. Click the Add Event Monitor button; this will allow us to select an operation to record.
Choose the MakeBooking operation we created in the previous module.

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 QM_vbooking 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. Switch the radio button at the top
of the dialog box from Direct Only to Indirect Only, and you should see the VBooking XA
DataSource component become available, while the other dependencies are hidden;
MakeBooking only has a dependency on VBooking XA DataSource 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, ProcessGlobal, and ProcessWorldwide operations. Note
that if 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. Click OK to continue.

6. All four 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. Click 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 four events recorded in the
Events View: two 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 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
four events again.
12. Record two new bookings, again using the Global and Worldwide options. You should now
have 12 messages in total.

13. Again, you will 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.
14. We will save two of these example messages as requirements. With the first message for
MakeBooking selected, click the Save icon on the Events View toolbar to open the
Recorded Events Wizard.
15. Select the requirements option on the first screen, and click Next.
16. On the second screen, you will be asked how the data within the message should be stored.
You choose either hardcoded values, or to use a data source. We will look at using data
sources later in the course, so for now, choose to Store data as hard coded values, and
click Next.
17. Following this, Rational Integration Tester will confirm that the requirement is associated
with the correct operation. As we have recorded from an operation, this should state
MakeBooking as the operation. This is correct, so click Next again.
18. You will then see a Header Transformation screen. Click Next through this screen.
19. On the Summary screen, you will be asked to give the requirement a name. Call it
exampleRequest. Uncheck the box labeled Open Resource After Finish, and click Finish to
create the new requirement.
20. Do the same for the corresponding reply message, calling it exampleReply.
21. You can now switch to the Requirements Library to view the saved messages.



9 Creating and executing a basic stub
9.1 Introduction
We are 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 will not 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 will use the Save Recorded Messages wizard again. We will also see the
stub editor for the first time. For the moment, we will 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 will be returning to the stub editor later on, and looking at it in more
depth.
We will then run a stub from Rational Integration Tester, using the Test Lab perspective. Finally,
we will 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 running.

9.2 Exercise: Making a simple stub from recorded messages
1. Click MakeBooking in the Event Monitors panel to filter out any messages from other
sources.
2. Select a request message and the corresponding reply message in the Events View.
3. Click the Save button. Select stubs on the first page of the wizard, and click Next.
4. On the second page of the wizard, we have the option of creating several different types of
stub. As this stub will be pretty simple, we will choose to use the Store data as hard coded
values option. Click Next once you have 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, click 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.
Click Next again.
7. Following this, you will see the Header Transformation page. This will remove information
from the message headers that normally will not be relevant to your stub, such as the
timestamp of the recorded messages. Leave all checkboxes selected here, and click Next.
8. 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.
9. Click Finish to create the stub. Rational Integration Tester should then switch to the Test
Factory perspective.



10. We can now take a look at the stub we have created. In the Events 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.

11. Below this, we can see the messages we recorded previously, in the Input and Output tabs.
12. By default, the stub will attempt to filter out anything that does not exactly match the default
message that we received. In those cases, it will not send a response message; instead it will
discard the request message. In this example, we would like to be less strict, and respond to
anything. To get started, switch to the Input tab, and take a look at the message body. You
will see that each text field has a small filter icon next to it:

13. We want to switch off any filtering that is checking for an exact field match. To switch off
filtering for the exact matches, select all of the fields within the message (you might need to
scroll down to do this). With everything selected, right‐click to bring up the context menu,
and then click Contents > Field Actions > Filter > Equality. This will toggle the equality
checks off, and the message body should then be shown without the filter icons, like the
following screen capture:



14. 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.
15. Save your stub; it is now ready to run.

9.3 Exercise: Executing a stub from Rational Integration Tester
1. Before we start using our stub, we will switch off the service in WebSphere Application
Server, so we are 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 click the Log In button.
2. In the left pane, click Applications>Application Types>WebSphere Enterprise
Applications.
3. The list of applications that we are using within WebSphere Application Server will then
open on the right side. Select the box for vbooking.booking.app; this handles booking
requests for us.
4. Above the list of applications, there is a Stop button. You can now click 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 will still see your stub in the tree on the left side of the screen. Run the stub, either by
double‐clicking it, or by selecting it and clicking the Run button.
7. The stub will then be displayed in the Task Monitor. Some initial details will be shown
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 we will 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 should not make any difference what booking request we send to the stub; all messages
will receive the same response.



9.4 Exercise: Modifying the stub as it runs
A stub can be modified as it is running. 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 will 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. Click Yes.

5. Rational Integration Tester will switch to the Test Lab perspective. You should see in the
Task Monitor that the stub has automatically been stopped and started again:

6. Make another booking in your web browser. It should now give you the new reservation
number you have entered.

7. As we are now finished using this stub, we will 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 panel (it will be the one with a Status of Ready).
8. The Stop button on the Task Monitor toolbar will now be available. Click it to stop the
stub.
9. We will 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.



10. Select the vbooking.booking.app application by selecting the box next to its name, and then
click Start. All services should be running, as shown below:

11. 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
10.1 Introduction
So far, the stubs that we have 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 can 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 will publish them to Rational Test Control Panel. This
makes the stubs available to other team members, and it also provides monitoring, versioning, and
other technical capabilities.
We will first look at how we can publish stubs to the server, and deploy those stubs. We will 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.2 Exercise: Using Rational Test Control Panel
1. Before we publish or deploy any stubs, we will take a look at the Rational Test Control Panel
interface. To do this, open a new tab in your web browser, and go to the Rational Test
Control Panel bookmark. When asked for a login and password, on cloud instances use
admin and Gr33nhat; in other environments, ask your instructor for the login details.

2. Once you are logged in, you will be presented with five options: Scheduling, Agents,
Results, VIE, and Administration. We will 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. Click on Agents, as that will be the first thing we will look at.
3. You should now be able to see the different types of agents available through this server.
Some of these will be particular types of proxies that we will be using later in the course, and
a single one will be listed as an instance of RTVS. This is what you will be using to deploy a
stub in the following exercise. For now, click the magnifying glass for that instance of RTVS.

4. You can now see where RTVS is running, along with status information. Currently, this
should tell you that RTVS is not executing any stubs. Click 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.3 Exercise: Publishing a stub
1. In order to make a stub available to the server, you need to publish it from Rational
Integration Tester. To get started, you can publish the stub you created for the MakeBooking
operation. Within Rational Integration Tester, switch to the Test Factory perspective.
2. Right‐click the MakeBooking operation, and select Publish Stubs. Note that this process will
publish all stubs that have been created for the operation. In your case, this will not really
matter, as you have only created a single stub.

1. A dialog box will open, containing settings for the version, domain, and environment of the
stubs, along with the URL used by Rational Test Control Panel. As this is your first
publication, leave the Version field set to 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.



2. The Rational Test Control Panel URL is set to use the connection on localhost. This has
been taken from your project settings, and can be left as‐is.
3. The Domain should be set to Booking System; if not, select Booking System from that list.
4. Below the domain, you can select which of the environments used in your project should be
used. You can use the Local environment that you created at the beginning of the course. If
you had created multiple environments within our project, you could select which
environments the stub should be available in.
5. Click Publish. Rational Integration Tester will then tell you that your stubs have been
published to the server.

10.4 Exercise: Deploying a stub
We will 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 Rational Test Control Panel dashboard. If we
want to view the available stubs, we will need to follow the VIE link along the top of the
dashboard, so click that.
2. You should then see the available domains on the left side. Select the Booking System
domain, and a list of environments that can provide stubs for that domain will be displayed.

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

4. You will now see a list of all of the parts of the system that might 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 gray 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 the plus sign for the MakeBooking operation.

5. A dialog box will open, allowing you to select the stub to run, and to provide some
configuration options. For the moment, we will 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
are looking at the first version of our stub, so this is going to be pretty simple. We will not be
worrying about most of the configuration options for this stub; those will be covered in later
modules. For this exercise, we only need to make sure that we know where our stub will be
running. Click the Agents link in the dialog box to check this out.
7. If desired, you can now select which agents should run the stub. Rational Test Control Panel
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 box, you can give this instance of the stub a label to identify
it. Enter FirstRun in here, and click Start Stub.



9. The dialog box 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 Rational Test Control Panel interface, you will now see that the stub has handled
one event. Note that it might take a moment for the web page to update with this
information. Once this has happened, Stop the stub, so that the live system will again be
handling the request messages.



11 WSDL 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 can 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, first by 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 are 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. You have already used this to model system information
provided by a WebSphere Application Server. Here, you will do it for a web service, using its WSDL.
For a WSDL, it is quite possible that you will need to make modifications after the synchronization
because the WSDL will only present the same data that is provided to an end user. For example, a
backend database is unlikely to be described inside the WSDL. However, as with the
synchronization of the WebSphere Application Server, it will allow us to model this part of the
system under test much more quickly than we could have built it manually.

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 will 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 by pressing Ctrl+V.



3. The Create a New External Resource dialog box opens, showing the Hotel Finder WSDL
listed for you. At this stage, we could add other WSDLs, but we will just use a single one for
this exercise.

4. Click Next to continue. You will 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 click Next.



5. The following screen will check which environment we will use when we create resources
for the HotelFinder services. We will keep using the Local environment we created earlier,
so check that this is selected, and click 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 would choose the last option, to synchronize without switching
views, so we can see what is created. For this example, though, we will go through the
synchronization manually, so select the second option, Open Synchronization View and let
me choose which items to synchronize.



7. Click 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.
This has been provided by an analysis of the WSDL, but none of these resources exist in your
project yet. To get started, click the Synchronize button on the toolbar.
9. As you have two synchronization sources in your project (the WebSphere Application Server
and the WSDL), you will be offered the opportunity to synchronize with one or both of these.
Choose just the HotelFinder WSDL. There is no need to worry about the WebSphere
Application Server at this stage, as you have already synchronized with it, and it has not
been updated since. Click OK.


Rit 8.5.0 virtualization training student's guide

Rit 8.5.0 virtualization training student's guide

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (16)

Semelhante a Rit 8.5.0 virtualization training student's guide

Semelhante a Rit 8.5.0 virtualization training student's guide (20)

Mais de Darrel Rader

Mais de Darrel Rader (6)

Último

Último (20)

Rit 8.5.0 virtualization training student's guide