EAI Integration-A Case Study
Figure 4 gives a comprehensive picture of the process-flow through the integration model.
Figure 4: Process Flow
Whenever a Royal Wallace employee needs to procure something, she logs on to an intranet application. The workflow in this application is managed by the SAP-based purchasing order (PO) system. The PO system, in turn, places the order with the vendor on behalf of the employee. The vendor acknowledges the receipt of the order to the PO system and delivers the goods to the concerned legacy system. Once the goods are delivered, the vendor sends an invoice for the same to the SAP PO system. The PO system, in turn, sends this invoice to the appropriate legacy system which then makes the necessary payment to the vendor. The legacy system also sends back a 'payment done' kind of acknowledge back to the PO system. This scenario is replicated for all the other legacy systems, too.
The EAI solution (Seebeyond eGate) is responsible for all the communication between the SAP PO system and the legacy systems. Various interfaces were developed as part of this solution to enable bi-directional flow of data. All the information pertaining to the various legacy systems and the SAP-based PO system (source and target) were captured as part of the functional specifications. These specifications covered the following topics:
- The platforms, databases, and operating systems for the source and target
- The various applications constituting these systems and the way they interacted with each other
- The input and output data formats for the source and target (EBCDIC, ASCII, Binary, and so forth)
- Frequency of data transfer and outage periods
- System connectivity details such as FTP drop zones
- The file structures that were being processed, if applicable
The technical specifications covered the following topics:
- Detailed technical design and architecture of the project
- All database-related details including the various servers, IP details, and the like
- Detailed configuration details of the various Seebeyond integration components, including connectors
- Detailed description of the error flow, including the codes
- Detailed description of the logging mechanism
- Input and output data structures and the transformations involved, if any
Common Data Format (CDF)
The various systems at Royal Wallace company that were to be incorporated into the integration model were based on different platforms. And, the applications that were running on these systems used to exchange data in various different formats with the outside world. Most of these were proprietary formats that each of these applications had created as per their own requirements over the years; there was no single standard approach that had been followed. Some of them had fixed-length records, others were delimited; some followed ASCII character encoding, others were EBCDIC; and so on. And above all, as most of these formats were in existence over the past several years, the system owners were very reluctant to replace them for a common standard format/template.
So one of the major challenges was to come up with a solution that could somehow transform and translate these multiple data formats passing through the integration model, thereby enabling the various systems to communicate with the SAP-based PO system. Moreover, the solution had to be scalable enough to incorporate any new data formats in the future with minimal changes to the existing scenario.
The solution was to make use of the Common Data Format (CDF), as shown in Figure 5.
Figure 5: Common Data Format
The Common Data Format (CDF) was an event structure that was generated within the Seebeyond eGate environment. Because the various applications deployed on the legacy systems used the integration model to procure goods from vendors, the incoming data to the EAI environment from the various applications had some common data elements irrespective of the data formats that these applications used. For example, all the procurement requests had information about type and quantity of the goods to be procured. All these common elements were captured under multiple nodes in the CDF event structure in Seebeyond. This proved useful in several ways:
- The entire data structure for the whole integration model was defined using a single event definition in Seebeyond. Now, all the incoming data into EAI could be parsed and then mapped to the CDF event structure.
- Once the data was available in the CDF, it was very easy to create the event structure as per the target system requirement and then simply map the CDF data into that structure.
Page 2 of 3