During the development stage of a large integration project we tend to focus more on the reusability factor which will extend our services to be used by the entire enterprise. The generic document handling/routing/mapping logic we write will will be used by various integrations implemented for various partners/applications belonging to different business segments.

This comes at a cost of having to do extensive regression testing(all the integrations) whenever we make any changes to the code.

We are trying to figure out a strategy/plan on how to do effective regression testing with limited effort.

Appreciate anyone’s help in this.

Regards,
Bala

We have this kind of discussion in our company, too.

Basically, you have to choose between two reuse strategies:

1. Reuse by reference : deploy the generic component once and use it for several integration applications (that’s what you plan to do)

Pros :

• That’s real reuse, you reduce redundancy of deployed code.

Cons :

• Whenever you deploy a new version of the generic component to an Integration Server, you have to migrate at the same time all integration applications using this component and running on the same Integration Server.
• Business owners might not be happy being affected by evolutions of the generic component, especially if these evolutions are due to other business owners’ needs only.

2. Reuse by copy : deploy a new copy of the generic component whenever you want to reuse it in a new integration project. So, each integration application gets its own copy of the component.

Pros :

• The new integration project can use the latest versions of the generic component, while existing integration applications may continue to use older versions.
• If you want to migrate existing integration applications to a new version of the generic component, you do not need to do this the big bang way. You can migrate one application at a time, choosing the most appropriate moment for each migration.

Cons :

• Overhead in ressource consumption (memory, …) because the same code is deployed more than once on the same Integration Server
• Naming conflicts : for each copy of the generic component you will need to rename all its packages and update references (yes, webMethods should really do something about namespaces on Integration Servers!)
• You need to set up a rigourous versionning policy for generic components. Otherwhise you might end with many different active versions of the generic component and maintaining these versions may become a headache.

Conclusions :

• Only very stable generic components should be reused by reference, the way you plan to do it.
• You might try to automate regression testing to some point.

Regards,
Timo