Overview

The IBM App Connect Enterprise and IBM Integration Bus plugins for MidVision RapidDeploy follow a simple guiding principle. Your integration node in Development is an accurate representation of your Production integration node with the only differences being those that depend on the environment connectivity and capacity in which you are working. This principle is reflected in all intermediate integration nodes on your "route to live" between Development and Production.

Your current working practices may not agree with this guiding principle, however it has been arrived at from experience within the industry.

• Why does my code pass testing in development and QA and then fail when we move to production?
• Why are my messages being processed in test environments but not when we move to production?
• How can I get an environment representitive of production?

These are the questions we strive to answer with the IBM App Connect Enterprise and IBM Integration Bus plugins.

Implementation

The IBM App Connect Enterprise and IBM Integration Bus plugins are designed to work from a single template Integration Node XML file that is the the "model" of the production integration node but with anything that might differe (e.g. queue manager, integration servers to deploy to, ports, etc...) parameterised (or sometimes referred to as tokenized). By convention we adopt the following form of a parameter within a RapidDeploy Integration Node template: @@PARAMETER_NAME@@.

This is very powerful, this single Integration Node template can then be used along with an appropriate dictionary (a key-value file that maps parameters/tokens to their real values) to create and deploy to any integration node between DEV and PROD. This ensures that the basic structure of your integration node is identical in each level through to production.

Flexibility

You are not restricted to using this template approach as suggested here. The plugin can be used to treat every single integration node as an individually configured entity. You could in theory represent all of your integration nodes as objects within RapidDeploy. You would have to manage your source through very strict control processes to achieve the same result. What falls naturally from using a single tokenized template is very error prone in the alternate approach. However you would still benefit from a single set of tasks being run in the same sequence for every deployment, so you still benefit from automation of deployment which reduces human error in those steps.

We think that the template approach though is very scaleable, and still works well if you have differing topologies (e.g. multiple integration servers in Production versus a single execution group in Development can be controlled by a single dictionary variable). It is very powerful.