Implementing and Administering WebSphere Business Integration Server V4.2.2

Chapter 9. Handling deployment and change 349

Figure 9-15 Find object references

Assuming that you worked out or cleared all possible conflicts between the

deployed solutions and the to-be-deployed solution, you can plan for the

activation of the new solution. Remember that adding or updating connectors to

an existing InterChange Server results in restarting the InterChange Server

before the changes become effective. Even more, components that have an

active state, such as maps, collaborations, and connectors, can only be updated

if these objects have been stopped before the deployment. This means that

performing the deployment and activating the new solution must be planned

carefully. A full impact analysis is required to avoid any disruption to existing

integration solutions. An impact analysis should be performed with the idea that

you have only one opportunity to do it right.

9.2 Managing runtime-specific changes

Today’s business environment is changing at an ever-increasing pace. This is

partly a consequence of more integration among the different actors in a

business process. A few years ago, a bank customer wanted to know account

balances likely had to visit a branch or make a phone call to the customer service

department. Nowadays, this same bank customer has plenty of facilities to

interact directly with the bank’s IT infrastructure to perform more than simply

350 Implementing and Administering WebSphere Business Integration Server V4.2.2

learn an account balance. Customers have become accustomed to these kinds

of features, which are possible only because there is an integration infrastructure

in place. Customer expectations can change rapidly, so the integration

infrastructure must be ready for change. But also, the administrators of the

integration infrastructure must be prepared for managing changes and they must

understand what it means to perform changes in any component of a complex

integration solution. In this section, we discuss changes that are limited to one

runtime component. That is, we do not consider changes to the interfaces

between components, which we discuss in the next section.

9.2.1 Changes to WebSphere MQ Workflow process model

A process instance in WebSphere MQ Workflow can have a lifespan from

seconds to years. One of the design principles of WebSphere MQ Workflow is

that after a process instance is created, it will follow the process model at time of

creation. In other words, it will save all of the steps that it must follow with the

data, so that a change in process model will not affect running instances.

This design principle has several consequences. First, implementing a new

version of a process model does not have any impact on existing and running

process instances. For example, if you have deployed a credit approval process

that typically runs for a few days between the initial request and the final

approval, a change to the process model will only effect new credit requests.

Another consequence is to find out what process model is in use for a given

running process instance. Consider a situation in which a process instance runs

for a few months. (An example is a complex insurance claim.) If several changes

are made to the process model during the lifetime of an active instance, it might

become difficult to track down the source version of that running process

instance. The WebSphere MQ Workflow administrator can track the identifier of

a given process instance back to its original process model. This makes it easy

for someone on a help desk to correlate a user inquiry with the corresponding

version of the process flow.

Given that a process instance is tight to its original process model for as long as

it is active, some modeling best-practices have been created to provide a way to

implement new functionality that is also picked up by existing process instances.

This technique recommends using a very simple top-level process in which all

activities are subprocesses. The top-level process cannot be changed for the

duration of the process, but changes to the subprocess will be picked up. As

such, you create a process model that is flexible for changes as well as resilient.