EAI Integration-A Case Study
2. Project Build, Test, and Deployment
After an elaborate design an architecture phase, the project entered the build phase. It is during this period that the various integration components were developed by making use of the Seebeyond eGate software.
As seen in Figure 6, three different environments were used for this purpose.
Figure 6: Different Environments for Various Phases of the Project
- Development Environment: The entire integration model in Seebeyond was developed here. This included the various adapters to connect to external applications, JMS-based messaging queues for persistent storage of data, configuring various connectors to connect to FTP drop zones and databases, and so forth. Once the development was completed, unit testing of the individual components was also performed on the development environment itself.
- Test Environment: Once the unit testing phase was over, the project model was migrated from the development environment to the test environment. The integration testing of the project model was performed in this environment. The test environment is a replica of the real production environment. Exhaustive testing of the model was performed here, along with the load testing wherein real-time data was fed to the model and the actual results that were received were captured against the expected results. In case of any issues, the model was moved back to the development environment, fixed for any outstanding issues, unit tested, and then moved back to the test environment. This whole cycle was repeated until the desired performance was reached and expected results achieved.
- Production Environment: It is this environment where the run-time instance of the model is deployed after rigorous testing is done and user acceptance achieved.
Seebeyond Transaction Flow Diagram
Figure 7 below shows the various Seebeyond components that were developed to enable the flow of data from the source to the target. Please note that because there is bi-directional flow of data between the SAP-based PO system and the legacy systems at the Royal Wallace company, the keywords 'source' and 'target' are used interchangeably for both ends.
Figure 7: Transaction Flow Diagram
The input files to the integration model were made available on the multiple FTP servers by the legacy systems at Royal Wallace as well as the SAP-based PO system. After the data in the file had been processed by Seebeyond, an output file was generated and transferred to the particular FTP location corresponding to each legacy system. Figure 7 shows the transaction flow for one such integration scenario.
Once the input file becomes available in the designated directory on the FTP server (source), it is picked up by eWay 1 (Seebeyond adapter) which is constantly pooling this directory. This eWay also performs any necessary validation checks on the structure of the file as well as the data content within it. It then publishes the data into JMS based IQ 1 (intelligent queue). eWay 2, which subscribes to JMS IQ 1, receives this data. It is in this eWay that the transformation of the data from the application-specific format to the independent Common Data Format (CDF) takes place.
Furthermore, any database-related logic that is required by the integration model is taken care of in this eWay. eWay 2 then publishes the CDF data event to the JMS IQ 2. eWay 3, subscribing to JMS IQ 2, receives this data. It takes care of transforming the data from the independent CDF format to the target application-specific message format. A few minor business validations in the input data are also done in this eWay on behalf of the target application. eWay 3 then publishes the data to the designated directory on the target FTP server in the form of a file. All the common services, such as exception handling and logging requirements, are provided by a separate schema that subscribes to a JMS-based IQ from this integration model.
The transaction flow explained above is applicable to all the interfaces that were designed as part of the integration model to enable bi-directional communication between the SAP based PO system and the legacy systems of the Royal Wallace company.
The EAI solution implemented at Royal Wallace addressed all the integration requirements of the company. It provided for an automated procurement process in place of a manual one and seamlessly integrated all the legacy applications at the company with minimum fuss. The changes required in the existing scenario were kept to a minimum. Moreover, because the Common Data Format (CDF) provides a lot of flexibility to the model, any new application can be easily incorporated with a plug-and-play kind of adaptability.
White Papers are posted at the following locations:
About the Author
Tarun Gupta is an EAI Consultant at Covansys India Pvt. Ltd. He is a post graduate from the Indian Institute of Information Technology, Bangalore.
Tarun has more than five years of experience in the integration domain. He has used various tools such as WebMethods, Seebeyond, Vitria, and TIBCO to provide solutions in manufacturing and telecomm domains. He can be contacted at email@example.com.
Page 3 of 3