Virtualization with IBM Rational Integration Tester

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.


Virtualization with IBM Rational Integration Tester

Virtualization with IBM Rational Integration Tester

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (7)

Similaire à Virtualization with IBM Rational Integration Tester

Similaire à Virtualization with IBM Rational Integration Tester (20)

Plus de Darrel Rader

Plus de Darrel Rader (7)

Virtualization with IBM Rational Integration Tester