Domains, Environment and Projects – Administration

This is a follow-up to my previous post Domains, Environments and Projects – making sense of it all.

Now that we understand the purpose of Domains and their related artifacts in the Rational Test Control Panel, let’s take a look at how we can make use of them.


Again, as described in the KnowledgeCenter, 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 IBM Rational Test Virtualization Server.  In the last post, I mapped each organizational division to a domain.  This will enable JKE to organize which stubs are published and visible in which domains.  That will help us make only relevant stubs visible to the various teams.

Security Access

Domain-level security is disabled by default.  As an administrator, go into the Administration > Security tab of Rational Test Control Panel and enable it.

Enable Domain-level security

Enable Domain-level security

Once enabled, any user that is not specifically added to a domain will not have access to anything in that domain.

No domains for unauthorized user

No domains for unauthorized user

Users are added to domains in the Administration > Domains and environments area by selecting the domain and then the Users sub-menu and clicking the green add icon.  Users can be given three levels of access: Domain administrator, User and API User.

Add a user to a domain

Add a user to a domain

Now that user will see any available domains in the domain selection box at the upper-right of RTCP.

Domains available to a user appear in the domain selection list

Domains available to a user appear in the domain selection list

With this in place, you not only provide visibility constraints, but also access constraints.  But, access constraints apply not only to users, but to proxies and agents as well.  Since we have not yet configured any proxies or agents for domain-level security, they cannot register to domains or environments within those domains.  If our domain user looks at the Environments tab (was VIE tab prior to v8.6), he will see this message:

No agents registered for this domain

No agents registered for this environment

This brings us to our third use for domains – controlling access to services.

Proxy/Agent access control

Proxy and Agent access control is implemented with security tokens.  An administrator creates a security token which is used by the proxy or agent to authenticate to RTCP.  The security token’s permissions determine which domains the proxy or agent can register with.  The security token is associated to a user when it is created.  The proxy or agent therefore gets the access of the user who corresponds to the security token being presented.

As an administrator user, create a token in the Administration > Security tab.  Select the user to which the security token will be bound and enter a description for the token.

Create user security token

Create user security token

Now provide the security token to the proxy or agent configuration settings.  For proxies, this is done by pasting the security token string into the security-token attribute of the server element of the registration.xml file for the proxy.

Adding the security token to the proxy registration.xml file

Adding the security token to the proxy registration.xml file

For agents, this is done by pasting the security token string into the security-token attribute of the rtcpURL element of the Agent.config file for the agent.

Adding the security token to the Agent.config file

Adding the security token to the Agent.config file

Restart any proxies or agents you have modified.  The proxies and agents started using this security token will be visible in all domains and environments, but they can only be used in domains where the user associated with the security key has permissions to work.

Proxy/Agent visibility

A proxy or agent’s visibility can be restricted as well.  This is done by the domains element in the proxy’s registration.xml or the agent’s Agent.config file.  For example, to cause my proxy and agent to only be visible to the Mobile Banking domain, I would add the following:

Restricting proxies or stubs to a specific domain

Restricting proxies or stubs to a specific domain

You can further restrict a proxy or agent’s access to only given environments within a domain.

Restricting proxies or stubs to a specific environment within a domain

Restricting proxies or stubs to a specific environment within a domain

Wrapping it all up

Now this becomes really powerful.  So consider again our multiple JKE teams all trying to build client applications that leverage the same payment calculator service.  Each team wants to use a stub for the payment calculator service, but they each want their own variant of that service.  The domain architecture of Rational Test Control Panel and the
ability to control which domains the proxies and agents can register into would enable each team to have their own personal proxy/agent pair visible only in their domain.  The members of each team would have permissions to their own domain.  Each team would publish and run their own Payments Calculator stub to their own domain.  Now, without changing the endpoints of any of the client applications, each team’s proxy will route requests from their client to their stub.  There are all sorts of options where multiple domains could share proxies and agents, thereby enabling them to use a common stub.  This could be part of a strategy to use incremental integration testing at an enterprise level.

Domains with separate and shared proxies

Domains with separate and shared proxies


Domains, Environments and Projects – making sense of it all

I was recently supporting an opportunity that involved multiple test teams supporting multiple products that all needed to virtualize common dependent services. It’s not that difficult to visualize how to create, publish and use virtual services in a small, well-contained project, but when you start looking at this from an enterprise perspective, it can turn into a large hairball quickly.

A fictional example

The Auto Loan application in the Personal Banking division of JKE Bank had a need for computing loan payments. It’s a pretty simple operation – you provide the loan amount, term of the loan and interest rate. In return, you get a value for the monthly payment amount. So the Personal Banking Auto Loan team encapsulated that capability in a web service, published it to the JKE world and built the Auto Loan application to leverage it.

Pretty soon, the Personal Banking division software architects decided it didn’t make sense to duplicate this functionality across all the applications in their portfolio, so they decreed that all Personal Banking apps that need to calculate payments must use the common Payment Calculator service. The two applications delivered by the Personal Banking team leveraged a common, consistent payment calculator.

At an executive golf outing, the VP of Personal Banking was bragging to the other VPs how efficient and cost effective his software team was as demonstrated by the common payments calculator service. Not to be outdone, the VP of Corporate Banking wanted in on this action and demanded that his peer share the payment calculator with his group. Just after another round of beers and just before a brawl broke out on the 12th hole, they agreed to allow the VP of Core Services to take ownership of the Payment Calculator service and deliver it as a common service across JKE. By the end of the round, The VPs of Billing, On-Line Banking and Mobile Banking were also all committed to leveraging this new, awesome common service.

Back in the office the following week, everyone realized the Payment Calculator was designed for auto loans with a maximum of five years so enhancements needed to be added to support longer loan terms. The Auto Loan team had to redo a bunch of integration testing to verify the changes didn’t break the Auto Loan application – which they did – and had to coordinate getting the regressions fixed – which they did. The Corporate Banking team required the addition of provisions for semi-annual payments instead of monthly payments. The Billing team wanted the service to return the total amount of interest that would be paid across the term of the loan. The On-Line team wanted the ability to deduct down payment values. The Mobile team wanted all values to be converted to local currencies. Each of the respective test teams realized they each had Dev, Test, Performance and UAT environments for each application. They just shook their heads asking “How are we ever going to test our applications while all these changes are going into the service we depend on?”

Projects and Environments dependent on a common service

Projects and Environments dependent on a common service

Hopefully you now see the problem. Today’s software systems are interconnected webs of loosely coupled applications; yet stable versions are required to complete integration testing. We have established how stubs or virtualized services can help, but how do you coordinate all this across so many teams and applications?

 Rational Integration Tester and Rational Test Control Panel Concepts

Let’s take a quick look at several Rational Integration Tester concepts that help us manage this challenge.

The Project

I can’t think of any other word in IT that is more overloaded and overused that “Project”, but nonetheless, it is a fundamental concept of Rational Integration Tester. The project is a physical disk location that contains files. From the Rational Integration Tester Workbench user’s perspective, the project is the container that holds all of your development artifacts including tests, stubs, datasets and other things. Let’s leave it at that – the Rational Integration Tester project is the disk location where you store the development artifacts related to the tests and stubs you are creating with the Workbench.

There is no Project concept in Rational Test Control Panel. You typically have a small number (maybe one) of Rational Test Control Panel instances, even in a large deployment where you may have many RIT projects. So the relationship between RIT project and RTCP instance is a many-to-one relationship.

The Environment

Every software project – err – “undertaking” must go through multiple stages in its journey to production delivery such as Dev, Test, Performance, UAT and Prod. There is hardware and software devoted to testing in each of these stages which is generally called an Environment. So although we are talking about one system, the implementation may vary considerably between, say, a Dev environment on very simple systems like Tomcat to HA WAS deployment in UAT or Prod. Rational Integration Tester captures the physical details in its own Environment artifact in the Rational Integration Tester project. The reason for this is that we need to know the implementation details of each environment to know how to apply tests and/or stubs to those environments.

The RIT environment maps directly to the environment in RTCP. Stubs, for example, can be created once in RIT and then applied to any or all environments. You can think of it this way: When a stub is deployed into RTCP, it carries along with it the environment details such as hostnames, IP addresses and port numbers. Stubs that have been deployed into RTCP are specific to the environment(s) into which it is deployed.

The Domain

The domain is a bit more of an obscure concept. A domain is an Rational Test Control Panel artifact that represents a logical grouping of related systems that are part of a real business project. It may be served by one or more IBM Rational Integration Tester projects, depending on how large or small the domain is, and how many Rational Integration Tester users are working on it. A domain can contain one or more environments.

The domain is much more loosely coupled to Rational Integration Tester. There is no domain artifact in RIT – you simply choose the domain into which you want to publish your stubs when you publish to RTCP.

Fictional example meets Rational Integration Tester

So let’s look at how our fictional JKE organization might apply RIT and RTCP to support their efforts to virtualize their common Payment Calculator. Keep in mind this is not the only way to implement a solution but one way.

Each of these application teams wants to create a stub that will represent the “to be” status of the Payment Calculator service that implements the new functionality they require. The Personal Banking Home Loans application team needs to virtualize the service supporting longer term loans. The Corporate Banking teams need to virtualize a service calculating semi-annual payments. The Billing team wants to virtualize the Total Interest Paid response value and so on.

So each team creates their own Rational Integration Tester project and implements their own stubs within their separate project. They each define their individual Environments within their projects.

Each of the application teams is mapped to a Domain in Rational Test Control Panel. This enables logical separation between the teams. The structure in the Environments page of RTCP will look something like this:

Domains and Environments in RTCP

Domains and Environments in RTCP

There is one area we could debate heavily on this proposal and that is the decision to have each team maintain their own separate stub in their own separate RIT projects. You may believe it would be better to have a single stub within a single project. I can definitely see why that would appear to be desirable. Rational Integration Tester does provide SCM integrations for version control. However, my perception is that these teams are all working on very different tasks in parallel. SCM is good for keeping track of sequential versions of artifacts like stubs but it isn’t so good at keeping track of parallel development efforts. RIT’s SCM integration definitely has no capabilities for merging changes together later. So my reasoning for keeping separate projects is based on my perception that these fictional teams want to keep their distance from each other and will for the foreseeable future. Again, this point could be debated and there are many other factors to consider.

So we have a scenario to build upon. In my next blog, I will look at how you can control permissions and access to domains and environments for both people and services such as Agents and Proxies.

What’s New?

I’m finally recovering enough from last week’s IBM Innovate conference to jot down a few notes on exciting stuff I saw in the testing space at the show.

Rational Test Workbench Mobile Test Edition V8.5.1

Support for testing mobile applications – native, hybrid and web – has been in Rational Test Workbench for a while now.  For those organizations that are looking for a complete package that includes mobile UI test automation, performance testing, service virtualization, integration testing and even UI test automation for desktop applications, Rational Test Workbench provides it all in one package.  RTW has been a compelling offering for enterprise clients for that reason.

However, if you only need a hammer, you don’t want to buy the whole tool chest. So as of now, you can buy just the mobile UI test automation capability in a lower cost offering.  This not only gives customers what they want, but it also makes the Rational offering more price competitive for mobile test automation.

Rational Test Workbench V8.6

There are some really exciting updates to the service virtualization and integration testing capabilities in Rational Test Workbench as well.  I would categorize the improvements in the following:

  • SAP support improvements
  • Support for MQ Telemetry Transport (MQTT)
  • Topology Discovery
  • Mainframe support enhancments
  • Other stuff

SAP support improvements

SAP support has been enhanced to include support for SAP XI 3.0 and SAP PI 7.31 and above for both integration testing and service virtualization.

Support for MQ Telemetry Transport (MQTT)

MQTT is at the heart of the Internet of Things.  It is a lightweight TCP protocol that is quite prevalent in smart appliances, vehicles and, well, “things”.  The Dev team had a pretty clever demo in the Expo Center where they could inject MQTT messages into a a traffic simulation and verify the expected behavior of other vehicles.  For example, send a message from one vehicle indicating it had stalled, blocking a street and verify other vehicles rerouted to avoid the incident.  Smart vehicles and self-driving cars are not just futuristic fiction anymore.  Testing these systems to ensure safety and reliability will require advanced testing techniques and tools.

Topology Discovery

Rational Integration Tester (RIT) can be a very powerful tool in the hands of a tester.  But what if the tester is just handed a complex system and told “test this”?  It is quite common when working with a client on a proof of concept that we end up discovering component relationships that the tester didn’t even know existed.  That “discovery” process can be extremely time consuming.  With Topology Discovery, you let Rational Integration Tester do the work for you.  In discovery mode, you tell RIT to monitor the system to determine which components are accessed by your component under test.  RIT will monitor the interactions and build a visual model for you, including capturing the message schemas and formats.  This can really help get you started much faster when faced with testing a new or unknown application.

Mainframe support enhancements

Ok, I will be the first to admit I am not a mainframe guy.  A lot of the new stuff I have seen is alphabet soup to me.  But for those of you that can make sense of it, RIT now supports executing tests against CICS programs directly using IPIC without the need for the CICS transaction gateway.  There have also been enhancements to System Z synchronization of WAS to create the IMS and CICS models.

Other stuff

  • The stub editor and message editors have seen some really nice UI enhancements making it easier to edit and manage stubs and test messages.
  • Enhanced TIBCO support.
  • Enhanced ability to publish and start stubs through automation in DevOps scenarios.

I also expect to hear about more advances in the near future as well and will pass them along when I do.