Overview

The IBM MQ plugin for MidVision RapidDeploy follows a simple guiding principle. Your queue manager in Development is an accurate representation of your Production queue manager 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 queue managers 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 MQ plugin.

Implementation

The IBM MQ plugin is designed to work from a single template MQSC file that is the the full script to build the production queue manager but with anything that might differe (e.g. log file sizes, queue depths, channel names, host names, ports, etc...) parameterised (or sometimes referred to as tokenized). By convention we adopt the following form of a parameter within a RapidDeploy MQ template: @@PARAMETER_NAME@@.

This is very powerful, this single MQSC template script 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 queue manager between DEV and PROD. This ensures that the basic structure of your queue manager is identical in each level through to production.

Flexibility

We recognise that this concept may not fit your design or intention in your organisation. The plugin is very flexible however, and will not restrict your use. Therefore if you wish to manage all of your queue managers individually with their own MQSC script you can do so. You will still benefit from a source controlled basis for a queue manager along with an automated deployment that ensures the same process is used to create every queue manager in your estate. You will still benefit from reduction in human error. You will however have to maintain far more objects and we would recommend that the process around this is very carefully managed. But in this instance, that is no different to what you are doing today, so you should be comfortable.

If you are undecided which approach suits you, try the templating approach first and see if it meets your needs when managing your MQ estate.