The Rational Integration Tester HTTP Proxy: What is it?

Over the next few weeks, I will be devoting a series of blog postings to the concept of a message “interceptor” and in particular to the Rational Integration Tester HTTP Proxy.  In order to effectively use Rational Integration Tester to create and run integration tests or stubs, it is critical that you understand the role of the HTTP proxy, how to install it, how to configure your environment and how to troubleshoot issues deploying it.  This series of blogs will start with the basic concepts but hopefully even seasoned Rational Integration Tester users will find value as we move along.

The Interceptor Concept

The proxy is really just one specific instance of a general concept called the Interceptor.  In general, the interceptor has two basic functions:

  1. Listen in on conversations between a client and a service to record message traffic that can later by transformed into automated tests or stubs.
  2. Act as a router to cause messages to be redirected from a client to a stub rather than the live service.

The details of how an interceptor works and the roles it fulfills will vary depending on the messaging technology being used.  For example, the interceptor for JDBC traffic is implemented as a JDBC library.  For IBM WebSphere MQ, the interceptor is a set of user exit libraries that are hooked into the MQ Queue Manager.  The collection of all these interceptors is known as the Rational Integration Tester Platform Pack.  I’m sure I will have opportunities in the future to dive deeper into those interceptors as well as others, but for this series, I’ll focus in on the HTTP Proxy used for HTTP, HTTPS and TCP messaging.

What is the HTTP/TCP Proxy?

I will just refer to it as “the proxy” from here on out, but the full name is really the HTTP/TCP Proxy.  As mentioned above, the proxy is the interceptor for HTTP, HTTPS and TCP messages.  Web proxies are pretty much a mainstay of networking these days.  Wikipedia has a pretty decent discussion on proxies (  This diagram represents a proxy in its simplest form.

The Proxy Concept

The Rational Integration Tester proxy sits between a service which uses the HTTP, HTTPS or TCP protocols such as a SOAP web service, REST services, etc. and the client that consumes the service.

Proxy Architecture

Proxy Architecture

Once the proxy is in place and running, the client and the service are unaware of its presence for the most part.  I say “for the most part” because there are some security considerations in an HTTPS environment that we will examine in an upcoming blog post.

The first function of the proxy is to listen in on the conversation between the client and the live service so that messages can be recorded.  The proxy doesn’t do this all by itself.  The proxy is really just the workhorse for the Rational Integration Tester workbench.  What basically happens is that an instance of Rational Integration Tester workbench tells the proxy that it should make a copy of the request coming from the client destined for the service.  The proxy sends that copy to the Rational Integration Tester workbench but it also sends the original request – unmodified – to the live service.  So the service thinks the request came from the client and responds.  The proxy makes a copy of the reply, sends the copy to RIT and sends the reply on to the client.

Proxy used for Recording

Proxy used for Recording

The second function of the proxy is to route request messages from the client to the live service or to a stub, depending on what messages your stub is supposed to handle.  Again, this is managed by the Rational Integration Tester workbench inserting “rules” into the proxy.  As a request message comes into the proxy, it evaluates it against the rules that have been registered with the proxy and acts accordingly.  For example, a rule might say that requests to the operation getHotels on myHotelServer:8089 should be routed to a stub instead of the live service.


Proxy used for Stubbing

Those of you with more Rational Integration Tester experience have probably already noticed that proxy rules are not normally set directly by Rational Integration Tester.  To be precise, Rational Integration Tester tells the Rational Test Control Panel which in turn sets the rule in the proxy.  That distinction will become more important later, but for now, let’s leave RTCP out of the picture.  We will dive into the details in a later post.


As was mentioned earlier, the HTTP/TCP Proxy is part of the IBM Rational Integration Tester Platform Pack.  It is installed using the IBM Installation Manager.

Installing the Proxy

Installing the Proxy

Running as a service

There are two options available when installing on Windows: Install Service and Start on Boot, which are both selected by default.  Install Service installs a Windows Service that will enable you to run the proxy as a background service without a visible command shell.  This is recommended for most all situations.

The Windows Service

The Windows Service

If you deselect the Start on Boot option, the Windows service will be installed but set to a Manual startup type.  In most all situations, I would recommend that you select Start on Boot.  Remember that if a System Under Test client has been configured to use a proxy and that proxy is not running, the SUT client will not be able to communicate to the service.  It is therefore advisable to do what you can to ensure the proxy is running at all times.  By installing the service and having the service start automatically, the proxy will fire up immediately upon reboot, which is generally a good thing.

Running from the command line

It is possible to run the proxy from the command line.  This can actually be advantageous when you are debugging message routing issues since the proxy will scroll logging messages in the command window where it was launched.  The same logging information is captured in log files when run as a service, but scrolling back through the command window is sometimes easier than repeatedly opening log files.

If you are not running the Windows service, open a command prompt, navigate to the proxy installation directory (by default, C:\Program Files\IBM\RIT-Platform\httptcp) and run startup.bat (or on Linux).

Network Considerations

Keep in mind that any non-trivial Rational Integration Tester installation will involve components installed across multiple machines.  It is quite possible your proxy is installed on a different machine from your SUT client, the live service or the Rational Integration Tester workbench.  You must have network connections between all of these machines and ports used to communicate between them must be open.  Depending on your company policies, you may need to adjust firewalls to enable such communications.

The best way to figure out what holes you need in the firewalls on the various machines is to trace the flow of messages through a block diagram like those above.  Keep in mind that firewalls can control message flow both out of and into a host.  So let’s look at this example.  The ports necessary to allow the client to communicate with the live service are already open.  We need the following additional paths to be opened to allow the proxy to relay the request and reply back and forth:

  • CLIENT_HOST OUTPUT New request to destination port 3128
  • RITPP_HOST INPUT New request on destination port 3128
  • RITPP_HOST OUTPUT New request to destination port 8089
  • RITPP_HOST INPUT response on Existing connection from source port 8089
  • RITPP_HOST OUTPUT response on Existing connection from source port 3128

There may be additional ports that need to be opened to allow communication between the Rational Integration Tester workbench and the proxy as well.

In the next blog post in this series (The Rational Integration Tester HTTP Proxy: Recording HTTP), I look in detail at using the proxy to record HTTP messages.  After that, we will take a look at what additional considerations there are for recording secure communications using HTTPS.  I’ll also blog about using the proxy to route messages to stubs.  That’s my short list for now.  It’s likely that additional topics will come to mind as I work through these so don’t be surprised if that short list gets a little longer.

No Nonsense – No, I really mean it

You may have noticed the new “No Nonsense Tech Talk” logo on the right side of my blog page and wondered what that is all about.  My Emerging Technologies team has decided to “brand” ourselves.  Well, I certainly hope it isn’t as formal or stuffy as that might sound.  In fact, it is quite the opposite.  We really have two motives for doing this and I hope you will see the benefits.

Our primary goal is to make IBM’s clients successful in developing, testing and deploying software.  Now I’m sure there is no secret who we all work for.  Yes, we work for IBM.  We do believe IBM has some of the best solutions in the software development market and we want to make sure you get every bit of value out of those solutions. But to be clear, our Emerging Technologies team is focused on client success, not IBM sales.  With emerging technologies, you are working on the bleeding edge and sometimes applying our software to problems that weren’t envisioned when we built the stuff.  In those cases, you don’t need another IBM sales pitch.  You need someone with clear technical advice that helps you get your job done.  Sometimes that might mean advising you to do things differently than the documentation says.  It might even mean advising you to use open source or competitive offerings to close gaps in our solutions.  So “No Nonsense” means we are going to be straight with you, even if it isn’t flattering to our employer.

Secondly, we figure that if you are an innovator and using one of our emerging technology solutions, it’s likely you may be struggling with challenges in other emerging technologies.  So take a look at my No Nonsense Tech Talk Community widget on the right side of this page.  You’ll see links to blogs of experts in several other areas we cover.  Check ’em out if you are looking for no-nonsense advice in DevOps, RTCz or one of the other technologies.

New Mobile Testing videos

I am one of those people that has a hard time just sitting around to relax when I know I have things on my to-do list.  I find it more relaxing to just get them done and off my plate.  So while I was supposed to be off line relaxing over the Christmas break, I slipped into the home office a couple times to create two videos I have been wanting to do for a while.  These videos show some additional variations of performing mobile application test automation with IBM Rational Test Workbench to the videos I already had out on YouTube.  Here is a list of all those I have done.

Mobile App Testing on iOS Physical Devices with Rational Test Workbench
This is a demonstration video of how Rational Test Workbench can be used to test native and hybrid apps on a physical iOS device.

Mobile Web App Testing with Rational Test Workbench
This is a demonstration of how Rational Test Workbench can be used to test mobile web applications from both iOS and Android platforms.

Android Mobile App Testing in Rational Test Workbench v8.5

This video shows how Rational Test Workbench can be used to test Android hybrid or native apps from an Android physical device.

iOS Mobile App Testing with IBM Rational Test Workbench

Here I show how Rational Test Workbench can be used to test an iOS app using the iOS Simulator that is part of the Apple Xcode development environment.

Final two videos in the Test Case Execution Records series

Dan has finished the final two videos in his series on Test Case Execution Records.  You can find them on YouTube following the links below:

Test Case Execution Records Part 5:
Generating Test Case Execution Records: Variations
Generating Test Case Execution Records: Variations examines generating test case execution records without specifying iterations, test environments, and a test plan.

Test Case Execution Records Part 6:
Running Test Case Execution Records and Generating Test Results
Running Test Case Execution Records and Generating Test Results shows how to:

  • Run tests using generated test case execution records and completing their test scripts.
  • Generate multiple test results in bulk without executing test scripts.
  • Find all execution records for a single iteration that have failed, passed, or not been run.
  • Work with test case execution records in a test plan as well as in a test case.

This series of videos is an excellent resource for anyone adopting Rational Quality Manager.