Introduction
Migration of EAI solution has become inevitable because of the new features coming in and badly designed products and solutions in the past.
Migration must be taken as an opportunity to redesign the existing solution by making use of the latest technological developments. It is necessary to ensure the business functionality is not lost and is adapted as-is from the existing legacy system.
Extensive testing of the To-Be-Migrated application and the Migrated application is very important to make sure there is no gap/missing functionality during the entire Migration process.
Problem Statement
For migration projects, testing involves running test cases in the to-be-migrated system, in the migrated system and finally comparison of the results to ensure as-is migration.
Overheads involved in Migration Testing
- Prior knowledge on both the to-be migrated system and the migrated system.
- Execution of the same test cases twice.
- Archiving, Data collection and Tracking of test results twice.
- Triaging of lost/missing test data in case of error scenarios.
Suggested Solution
The above mentioned overheads can be greatly avoided/reduced by using the Proxy mechanism for end-end testing.
Let’s take the example of eGate to IIB migration to better explain the concept.
Proxy Services
Proxy services are reusable intermediate services designed in IIB to ensure easy and effective testing of both eGate and IIB systems.
Taking example of Pub-Sub integration which needs to be migrated, we will need 3 proxy flows namely PubIn proxy, PubOut proxy and SubOut proxy.
PubIn Proxy
PubIn proxy is the starting point of the testing framework.
- Acts as a single point of input and takes user test data via a MQ Input.
- Routes the inbound message downstream to both the eGate and IIB Publisher services.
- Writes the inbound message to a File destination for tracking of the inbound test message which can also be used to retry in case of any error.
- Necessary logging and error handling involved.
PubOut Proxy
PubOut proxy is introduced after the Publisher processing in both eGate and IIB.
- Additional subscriptions are created to the Publisher services from both eGate and IIB to provide input to the PubOut Proxy service.
- MQ Input takes the Publisher Outbound message as input from eGate and IIB system.
- Writes the inbound message to a File destination for tracking of the Publisher Outbound data which aids in the comparison of both the system’s Pub Out results.
- Necessary logging and error handling involved.
SubOut Proxy
This forms the last point of the proxy framework and is placed at the end of Subscriber processing.
- After the Subscriber processing, the outbound messages from the eGate and IIB Subscribers are placed on the respective MQ input of SubOut proxy flow.
- An IIB_Active flag is set to true if the downstream service is available in IIB and set to false if the downstream service is available in eGate.
When IIB_Active = True:
o Data Capture is done using the eGate Subscriber’s Outbound Data.
o Routing to the External Target is done using the IIB Subscriber Outbound Data.
When IIB_Active = False:
o Routing to the external target is done using the eGate Subscriber Outbound Data.
o Data Capture is done using the IIB Subscriber Outbound Data. - Data Capture involves writing the message to a File destination for tracking of the Subscriber Outbound data which aids in comparison of both the system’s Sub Out results.
- Necessary logging and error handling involved.
Common to all Services
- Sufficient logging to ensure the throughput of the message.
- Error handling via posting of failed message on error queue.
- File directories maintained with consistency to ease the comparison.
- MQ names and File directories are promoted so that the proxies can be reused at Bar level.
- Archiving on a daily basis so that new files are created for daily testing.
