2012 10 23_3115_rational_integration_tester_tr

Rational Integration Tester
Training Guide

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

© Copyright IBM Corporation 2001, 2012.

RATIONAL INTEGRATION TESTER TRAINING GUIDE

1 INTRODUCTION ........................................................................................................................ 4
2 CONFIGURING RATIONAL INTEGRATION TESTER ........................................................................ 5
2.1 PRE-REQUISITES............................................................................................................... 5
2.2 THE LIBRARY MANAGER .................................................................................................... 5
2.3 CONFIGURING THE LIBRARY MANAGER FOR WEBSPHERE APPLICATION SERVER AND MQ ...... 6
2.4 ADDING THE INTERCEPT DLL ............................................................................................. 7
3 RATIONAL INTEGRATION TESTER PROJECT SETUP .................................................................... 8
3.1 THE INITIAL SCREEN ......................................................................................................... 8
3.2 CREATING A NEW PROJECT ............................................................................................... 9
3.3 EXERCISE: CREATING THE TRAINING PROJECT .................................................................. 10
3.4 RATIONAL INTEGRATION TESTER LAYOUT .......................................................................... 14
3.5 RATIONAL INTEGRATION TESTER PERSPECTIVES ............................................................... 15
4 MODELING THE SYSTEM......................................................................................................... 16
4.1 PERSPECTIVE OVERVIEW ................................................................................................ 16
4.2 WORKING IN MULTIPLE ENVIRONMENTS ............................................................................ 16
4.3 LOGICAL VIEW ................................................................................................................ 17
4.4 EXERCISE: SETTING UP THE LOGICAL VIEW FOR A SIMPLE SYSTEM ..................................... 19
4.5 PHYSICAL VIEW .............................................................................................................. 22
4.6 EXERCISE: SETTING UP PHYSICAL VIEW FOR A SIMPLE SYSTEM ......................................... 22
4.7 ENVIRONMENTS .............................................................................................................. 22
4.8 EXERCISE: CREATING AN ENVIRONMENT ........................................................................... 22
4.9 EXERCISE: SCHEMA LIBRARY ........................................................................................... 24
4.10 EXERCISE: THE MESSAGE EXCHANGE PATTERN (MEP) ................................................. 25
5 THE DEMONSTRATION ENVIRONMENT ..................................................................................... 27
5.1 MANAGING FLIGHT BOOKINGS.......................................................................................... 27
5.2 FINDING AND BOOKING HOTELS ....................................................................................... 28
5.3 FLIGHT ADMINISTRATION ................................................................................................. 28
6 USING SYSTEM DATA TO BUILD A SYSTEM MODEL .................................................................. 30
6.1 OVERVIEW ..................................................................................................................... 30
6.2 SYNCHRONISATION OVERVIEW ......................................................................................... 30
6.3 BUILDING A MODEL FROM RECORDED EVENTS .................................................................. 31
6.4 RECORDING MQ MESSAGES............................................................................................ 31
6.5 EXERCISE: SETTING UP THE TRANSPORTS ........................................................................ 32
6.6 EXERCISE: ADDING THE FLIGHT BOOKING MESSAGE SCHEMAS .......................................... 37

Page 1 of 133 © IBM Corporation 2001, 2012


7 REQUIREMENTS LIBRARY ....................................................................................................... 38
7.1 OVERVIEW ..................................................................................................................... 38
7.2 THE MESSAGE EDITOR .................................................................................................... 38
7.3 EXERCISE: IMPORTING MESSAGES ................................................................................... 39
7.4 CREATING MESSAGES FROM A SCHEMA ............................................................................ 40
8 RECORDING EVENTS ............................................................................................................. 43
8.1 THE RECORDING STUDIO................................................................................................. 43
8.2 EXERCISE: RECORDING EVENTS FROM A TRANSPORT ........................................................ 44
8.3 EXERCISE: BUILDING OPERATIONS FROM RECORDED EVENTS ............................................ 46
8.4 EXERCISE: COMPLETING THE SYSTEM MODEL ................................................................... 52
8.5 EXERCISE: RECORDING EVENTS FROM AN OPERATION ...................................................... 53
8.6 EXERCISE: CREATING AND RUNNING TRIGGERS ................................................................ 56
9 CREATING AND EDITING TESTS .............................................................................................. 58
9.1 TEST STRUCTURE ........................................................................................................... 58
9.2 BUSINESS VIEW AND TECHNICAL VIEW ............................................................................. 59
9.3 EXERCISE: CREATING TESTS FROM RECORDED EVENTS .................................................... 59
9.4 THE MEP WIZARD .......................................................................................................... 64
9.5 EXERCISE: CREATING TESTS WITH THE MEP WIZARD........................................................ 65
9.6 COPYING AND LINKING REQUIREMENTS ............................................................................ 68
9.7 TEST TEMPLATES ........................................................................................................... 69
9.8 EXERCISE: CREATING A TEST FROM A TEMPLATE .............................................................. 69
10 TEST EXECUTION ............................................................................................................... 71
10.1 THE TEST LAB ............................................................................................................. 71
10.2 EXERCISE: RUNNING A TEST ........................................................................................ 71
10.3 EXERCISE: REPAIRING TESTS ....................................................................................... 72
10.4 EXERCISE: THE RULE CACHE ....................................................................................... 75
11 CREATING AND RUNNING A STUB ........................................................................................ 77
11.1 EXERCISE: CREATING A STUB FROM RECORDED EVENTS ................................................. 77
11.2 EXERCISE: EXECUTING A STUB FROM RATIONAL INTEGRATION TESTER ............................ 79
11.3 EXERCISE: MODIFYING THE STUB ON THE FLY................................................................. 80
12 TEST AUTOMATION ............................................................................................................ 83
12.1 TEST SUITES ............................................................................................................... 83
12.2 EXERCISE: CREATING AND EXECUTING A TEST SUITE ..................................................... 83
12.3 RESULTS GALLERY ...................................................................................................... 85



12.4 EXERCISE: VIEWING RESULTS ...................................................................................... 86
13 STORING AND MANIPULATING DATA .................................................................................... 88
13.1 TAGS AND THE TAG DATA STORE .................................................................................. 88
13.2 CREATING TAGS .......................................................................................................... 89
13.3 USING TAGS................................................................................................................ 91
13.4 EXERCISE: TESTING WITH TAGS .................................................................................... 91
13.5 DATA SOURCES........................................................................................................... 92
13.6 EXERCISE: DATA DRIVEN TESTING ................................................................................ 92
14 REPEATING ELEMENTS ....................................................................................................... 97
14.1 OVERVIEW .................................................................................................................. 97
14.2 EXERCISE: PUBLISHING A SET OF ORDERS .................................................................... 99
15 TEST ACTIONS ................................................................................................................. 104
15.1 TEST ACTION SUMMARY............................................................................................. 104
15.2 EXERCISE: RUN COMMAND ........................................................................................ 107
15.3 EXERCISE: LOG ......................................................................................................... 108
15.4 EXERCISE: LOOKUP TEST DATA .................................................................................. 109
15.5 FAILURE PATH AND PASS/FAIL .................................................................................... 111
15.6 EXERCISE: USING FAILURE PATHS .............................................................................. 112
16 INTERACTING WITH DATABASES ........................................................................................ 115
16.1 EXERCISE: CREATING A DATABASE COMPONENT MANUALLY .......................................... 115
16.2 EXERCISE: SQL COMMAND ........................................................................................ 117
16.3 EXERCISE: COLUMN AND CELL VALIDATIONS ............................................................... 117
17 RUN TEST ....................................................................................................................... 120
17.1 INTRODUCTION .......................................................................................................... 120
17.2 EXERCISE: CREATING THE CHILD TEST......................................................................... 120
17.3 EXERCISE: CREATING THE PARENT TEST..................................................................... 121
17.4 EXERCISE: PASSING DATA BETWEEN THE TESTS .......................................................... 122
18 MONITORING LOG FILES ................................................................................................... 124
18.1 OVERVIEW ................................................................................................................ 124
18.2 EXERCISE: LOOKING FOR ERROR MESSAGES............................................................... 124
19 ADVANCED STUBS ........................................................................................................... 127
19.1 EXERCISE: PARAMETERIZED STUBS ............................................................................ 127
20 LEGAL NOTICES............................................................................................................... 132



1 Introduction

This document serves as a training manual to help familiarize the user with the functionality
present in IBM® Rational® Integration Tester. Most of the training exercises make use of a variety
of technologies, including IBM WebSphere® Application Server, IBM 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 how best to use them in testing Message Oriented Middleware applications.
In this course we will:

 Walk you through the installation of Rational Integration Tester on your PC
 Present the various perspectives in Rational Integration Tester and how and when they are
used
 Demonstrate how Rational Integration Tester can facilitate testing of services in a message
oriented middleware architecture by
o Providing a graphical interfaces for the display and creation of messages
o Automatically comparing a received response with a pre‐programmed one to ensure
they match
o Allowing the running of a test to be repeated over and over with little manual
intervention
o Exposing the details of the process to provide better information from the test team
to the development team, enabling test failures to be examined in detail
 Create and run automated tests and test suites
 Illustrate the ease of message data manipulation to facilitate testing by using various test
actions
 Build stubs and triggers, which are a vital part of integration projects
 Produce detailed reports on test suites

Before we dive into this training course, please make sure you have all the correct files in place.
 If you are using a cloud instance, the training files should be located on the desktop
 Otherwise, your instructor will let you know where to find any required files.



2 Configuring Rational Integration Tester
2.1 Pre‐requisites
If you are using a cloud instance, skip to section 2.3.
If you need to install Rational Integration Tester, please make sure that the following prerequisites
are in place:
 Rational Integration Tester project database – note that this can be shared between multiple
people. The database can be set up using one of the following:
o MySQL 5.0.1 or higher and MySQL 5.1.x
o Oracle 9.2i, 10g, or 11g
o MS SQL Server 2005
 Java 7
o The IBM JRE is included and installed with the Rational Integration Tester. The JRE is
installed in the Rational Integration Tester installation directory and is used only
when Rational Integration Tester is executed. The JRE does not affect the registry or
any other programs on the system.
 Microsoft Excel 2003 or newer (or equivalent)

2.2 The Library Manager
The Library Manager is the main configuration tool for Rational Integration Tester. It provides the
necessary tools to set up connections to the wide variety of technologies supported by Rational
Integration Tester, and set up other configuration options as required.
Rational Integration Tester supports a number of technologies out of the box – web services, email,
and a number of databases. However, connections to a number of other proprietary technologies
will require external Java libraries, which are normally supplied within the installation files of that
software.
If that software is installed on the same machine as Rational Integration Tester, then the Library
Manager may be used to point Rational Integration Tester towards the installed location of the
required libraries. Otherwise, those libraries can be copied across to the local machine, and the
Library Manager used to locate the local copies of those files. If you do not go through this
procedure, you will find that Rational Integration Tester will generate errors when you attempt to
connect using any technologies that have not been set up correctly.
Regardless of the technologies that you plan to test with Rational Integration Tester, you will need
to run the Library Manager once on any machine that has a copy of Rational Integration Tester. This
will allow the Library Manager to perform extra setup tasks, such as creating Rational Integration
Tester’s home directory.



Any changes made in the Library Manager will not take effect until the next time you start Rational
Integration Tester. This means that if you are running Rational Integration Tester while making
changes in the Library Manager, you will need to restart Rational Integration Tester.
We will now look at an example use of the Library Manager – setting up connections to Java
libraries for the IBM WebSphere Application Server and WebSphere MQ tools.

2.3 Configuring the Library Manager for WebSphere Application Server and MQ
Depending on the version of WebSphere Application Server and MQ, specific product libraries are
required. Please make sure that you have configured Library Manager with the right libraries. This
has already been set up for any cloud instances.
1. In the Library Manager, click on the IBM WebSphere Application Server item on the left
hand side. You will now see a list of providers, for each supported version of the Websphere
Application Server.

2. In the Providers section on the right hand side, select version 8.0 of WebSphere Application
Server.
3. Go down to the Settings section, and make sure that each of the necessary .jars has been
found. If not, select each one in turn, pressing the Edit button to locate the .jars. If necessary,
your instructor will be able to provide you with a copy of each file.
4. Next, you will need to do the same for IBM WebSphere MQ 7.0.



2.4 Adding the Intercept DLL
There are several ways that we can set up recording for WebSphere MQ. During this training
course, we will be using the intercept dll provided by Rational Integration Tester. This will allow us
to view and record messages sent to any queue on the MQ server. If you are using a cloud instance,
this has already been done for you.
Please view section 6 of the rit_wmq_ref.pdf plugin guide for instructions on how to configure this.



3 Rational Integration Tester Project Setup
3.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.

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

3.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 Testing.



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



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



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



4 Modeling the System
4.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 perspective:
 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.

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

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

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



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

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

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

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



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

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



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

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

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

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



6 Using System Data to Build a System Model
6.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.

6.2 Synchronisation Overview
The simpler option when building a model of the system under test is synchronization. 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
synchronization 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 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 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.

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

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

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



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

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



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



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



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

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

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



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

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

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


2012 10 23_3115_rational_integration_tester_tr

2012 10 23_3115_rational_integration_tester_tr

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (16)

Similaire à 2012 10 23_3115_rational_integration_tester_tr

Similaire à 2012 10 23_3115_rational_integration_tester_tr (20)

Plus de Darrel Rader

Plus de Darrel Rader (6)

2012 10 23_3115_rational_integration_tester_tr