Simulating multiple environments for SOAP and REST Services

Configuring multiple Talend Runtime containers on a single server

Sometimes, you may need to deploy, run and test multiple versions of a SOAP service on a single server for short term development and testing needs.

In cases like this, you can deploy multiple Talend Runtime containers on a single server, to simulate multiple environments, such as Development, Staging, System Integration Test, UAT1, UTA2, etc. Those additional environments are generally temporary. They are created to accelerate development and testing and are cleaned up after the release is done.

Warning: This example shows how to deal with multiple environments on one server for a short period of time. This approach is not recommended in a Production environment. Conflicts can occur when sharing resources with this kind of configuration.

Multiple environment Runtime

Talend Runtime can be installed multiple times on the same server. Since there are many ports used by a Talend Runtime instance, you need to change all of them to avoid conflicts.

Talend provides Karaf configuration scripts which can automate the deployment of multiple containers on the same server with different set of non-conflicting ports and parameters. These scripts are executed within the Talend Runtime container and thus are supported by all platforms compatible with Talend Runtime.

Deploying multiple Talend Runtime containers

In this example, the Talend Runtime container will be running on different ports and the environments are replicated end-to-end, there will be different databases for each environment.

To have multiple environments on a single server, make sure:

There are no shared resources between the environments other than Nexus, Git or SVN.
There is no ActiveMQ or JMS communication with the services.
There are no ESB infrastructure services used (since these are temporary environments).

Do not run the default container. If you have already started it, stop it and delete the data directory.
Copy-paste the container and name it, once per environment.
Start the first Runtime (container).
Run the configuration script in each container, after starting, to set the ports.
Scripts for different configurations are provided in the scripts folder of the ESB distribution.
- source scripts/configureC1.sh for the first container copy,
- source scripts/configureC2.sh for the second container copy,
- source scripts/configureC3.sh for the third container copy.
Restart each container after having run the script on the Karaf console.
Configure all new servers in Talend Administration Center.

You have now three Talend Runtime containers, each one for simulating a different environment and ready to be used on a single server.

Deploying on different environments

Deployment and testing of SOAP and REST services into the various containers are now transparent, even though the three environments, that is to say the three Talend Runtimes, are on the same physical or virtual server. You can deploy artefacts from Nexus to any environment.

To make services more configurable, you can design them to include context variables in their endpoints. In this example, you have the server, port and version defined as context variables.

In the Contexts view in your Studio, define context variables for the server, port and version of the services endpoints.

You can use the version variable to define different versions or to reflect several environments for easy reference.
In the Endpoint field of the basic settings of the cCXFRS component, set the service endpoint URL using the context variables.

The cCXFRS component is renamed to cREST starting from the 6.4 Studio version.
Deploy the different versions of the services on different environments.

The services automatically acquire the IP address and port of the server if you use a relative URL for the endpoint.

The same service is deployed here in different environments with different URL patterns.