MQSeries.net :: View topic - Maintaining/deploying many versions of a message flow/set?

Sandman · Posted: Wed Oct 29, 2008 8:57 am Post subject:

Hi,

I've searched the forum and the manuals but to no avail. Hoping you might provide some direction on how to manage this when the goal is reuse.

During our first few years of broker development (which focuses on CICS integration), our normal design was to create a new message flow and message set for each new integration. This strategy provided no definition or code reuse though.

So on our last big project, we created a message set in which we defined many "objects" that are reusable across message flows. We also have a message flow project that contains corresponding ESQL files that provide transformation procs between XML and COBOL formats. Many of our message flows then use these defs/procs to build and process messages.

We're now experiencing some of the maintenance and administration pains of this approach as new projects come along and wondering if we're maybe doing something a bit unorthodox.

If we need to make changes to either the common message set or procedure project, if all of the current integrations that use these are not willing/able/ready to digest the changes, we need to be able to support multiple runtime versions of them. This is less of an issue w/ the common procedure message flow project (vs. the message set) - presuming we can keep track of which versions of each ESQL file each integration uses - because the code from that common project is compiled into each flow. [We did this project in v.6.0, and I believe the new versioning features are part of 6.1?]

At any rate, our crude "versioning" tactic under tight timelines was to simply make copies of the procs in the common ESQL project and rename them for use by the new integrations. We knew this was a temporary solution though and now we've gone back and updated this project by renaming the new procs (to the old names) and regression testing the original flows.

We did the same thing for the message SET, in which we created new copies of its definitions and added a suffix to them to make them unique, so as to not disturb existing message flow projects (seeing all message flows share the same defs in the one-and-only running copy of the message set in the exec group).

I'd like to know how others manage this? Even though we might sometimes be able to get all existing users of a message flow or set to agree to absorb changes, we realize that sometimes we will not, and we'll have to maintain/deploy multiple versions of these.

If the broker only allows each like-named message flow or message set to be deployed once per execution group, how do you support the need for multiple runtime versions of these? Do you put different versions in their own execution groups? (To date, we've deployed everything to one big exec group. Is that a bad strategy?) Or do you copy the flow/set under a new name (i.e. include a version # in it)? If so, then you have multiple "logical" copies of the same flow in the repository, but by different "physical" names? (This would seem confusing.)

Lastly (thanks for bearing w/ me on this

)... in addition to the runtime concerns above, how do you manage the design time artifact relationships? For instance, version 1 of message flow MF1 uses version 5 of the common procedure message flow project MF2 and version 3 of message set MS1. But version 2 of MF1 uses version 6 of MF2 and version 4 of MS1. How does one manage these relationships - both in the toolkit workspace(s) and in the repository?

Also, do others employ this type of reuse strategy - a common message set that contains the most commonly-used "objects" in our integrations, combined w/ a common message flow project that contains ESQL procs for transforming between XML and COBOL?

Thank you for any guidance you can provide, esp. on the runtime versioning; and regarding the code versioning, even if it's just to point me to the appropriate reading.