Implementing XML-based Common Objects to Enable Enterprisewide
Application Integration (A case study detailing the EAI implementation of a High-Tech
Manufacturing/Retail Vendor using XML standards.)
ABSTRACT
Successful implementations of EAI solutions have come to favor loosely-coupled integration architectures over more traditional point-to-point integration. To facilitate both application isolation and extensibility to many applications in an enterprise, well-designed EAI solutions also increasingly make use of common data objects as a central feature. This design results in "dual transformation" integrations, where data from any given source application is mapped or transformed first to a common format, and then transformed again from the common object into one or more target formats. Enterprises implementing this type of solution can look to standards bodies and industry consortia to provide guidance for the structure of the common data objects themselves. To the extent these data structures are described in XML, incorporating them into solutions on-site can provide significant savings in implementation time and effort.
The implementation experience of a leading high technology manufacturing and retail vendor provides an exemplary case study of the benefits of this integration design. The company in question not only selected a leading commercially available EAI tool, but also chose to implement several specifications within the interoperability standards as described and published by the Open Applications Group (OAG). The common objects were used for an enterprise integration project that included integration of products, orders, and customer data maintenance across packaged applications including BroadVision and SAP R/3 as well as custom and legacy systems. The integration design prepared and implemented for this project serves to highlight the key architectural features, benefits, and considerations around using common XML data standards. The emphasis of this session will be to explain the rationale behind the solution design, the company's development and implementation experience, and the choices made and lessons learned throughout the project. The discussion is not intended to focus around the evaluation and selection of any particular technologies or the products of any particular vendor, but rather will present architectural and design features that should apply to a broad set of integration initiatives.
Table of Contents
1. Project Overview
The client is a global high-technology industry manufacturer that sells products online directly to consumers and small businesses. Prior to this initiative, the existing process for handling online transactions was slow, lacked key functionality, and was built on an infrastructure that couldn't scale to support growing numbers of customers accessing the company's order process via the Web. Key technologies in place included three instances of SAP R/3, e-commerce applications from BroadVision and ClearCommerce, Oracle as the RDBMS standard supporting these applications, and a mix of third party and custom applications for product data, reporting, administration and monitoring, and data exchange with fulfillment partners. The completed solution implemented SeeBeyond e*Gate Integrator as an enterprisewide integration platform.
The project team implemented a common integration layer primarily between the BroadVision storefront and multiple instances of SAP (modules in use included MM, Retail, FI, and SD), but also among third party provider systems and XML-based systems. The integrated solution supports order-to-cash, procure-to-pay, post sales, and financial processes with a total of 27 interfaces. The solution as delivered enables the client to rapidly respond to customer requests, provides improved status visibility, and enables new applications to be quickly incorporated.
2. The Role of XML
With multiple points of integration, the architectural design employed a dual-transformation methodology, wherein data originating from one application is first transformed to a common object representation, and then transformed a second time into the data format appropriate for each target system receiving the data. This design feature is not unusual when integration broker solutions are implemented, as it provides a loosely-coupled integration model supporting one-to-many and many-to-many process flows, and minimizes the impact of changes made to any one integrated application. Consistent with the dual-transformation model, many EAI products (including e*Gate) permit the use of both proprietary and standards-based common data formats.
The client in this case chose to use XML as a standard for its intermediate data representation, with a specific schemas based upon several specifications from the Open Application Group (OAG). Using existing XML specifications saved data modeling and development time, and facilitated the construction of the appropriate event type definitions within the middleware environment. Furthermore, while much of the transformation and routing logic and data mapping built into the integration is not fully middleware-independent, by defining a common object structure in XML, the data structures can be used or incorporated by virtually any EAI tool that reads XML (which includes the vast majority of products currently on the market).
The decision to use XML as a standard internal format was considered along with an alternative to employ a hybrid approach which would make use of both XML and data formats native to the middleware. This alternative provided some performance advantages in several test case scenarios, where the processing required to map data both into and out of the standard XML format introduced noticeable latency in high-transaction flow integrations. The hybrid approach also involved a greater development effort and in some ways limited the ability of the client to expand the solution easily to include new trading partners. Ultimately, with some tuning of the middleware deployment, the client preferred the flexibility for future modifications offered by the XML-only standard, coupled with their desire to minimize barriers to participation for partners and third party providers.