Org. A has made a conscious decision to go forward the XI3.0 route. It was essential to identify and align the integration priorities of the organization with the strategic objectives of preparing the IT infrastructure for building efficient solutions to realize lower cost of operation and better information integration. Phew! Haven’t we heard this speel before? But in order to achieve this need, solutions that make new levels of collaboration and connectivity possible to the applications and systems available within and outside the enterprise boundaries and across the entire value chain need to be much more than just EAI solutions. This needs significant capability from the middleware to better leverage the existing legacy applications in the technical landscape without compromising on the non functional aspects like better message handling throughput, reliable delivery mechanisms etc. and Org. A has chosen the Integration path of XI 3.0 over other middleware solutions.
Agreed, SAP XI is an integration platform, part of the SAP NetWeaver suite which provides extensive web services capability, prebuilt integration content, support for open standards like XML, SOAP, JMS and industry protocols like RNIF, CIDX but what makes it truly remarkable is when a Solution Architect views XI 3.0 not from an EAI standpoint alone, but as the pivot of any organization’s ESA initiatives.
Being a part of NetWeaver platform, the SAP XI becomes central in design and configuration by reducing integration and maintenance costs of IT systems by providing a common, central repository for interfaces with support for cross-component business process management (ccBPM), a key component of SAP XI, which closes the gap between business process modeling, process execution and process monitoring, based on BPEL(Business Process Execution Language), an industry standard for modeling processes. With an integrated tool set to help organizations build their own integration scenarios by defining the appropriate messaging interfaces, mappings, and routing rules, XI 3.0 now dons the mantle of being the pivot of an ESA roadmap that renders other EAI applications incomparable in the larger scheme of things. A wise move by SAP.
Appreciation for the need for an XI System in Org. A :
Taking the standard SAP drone, Org. A decided that it needed an EAI solution (not just an EAI solution) that would provide an open integration technology that enables process-centric collaboration among SAP and non-SAP components, both within and beyond the enterprise boundaries. With Org. A being an SAP shop, it made sense to move ahead with initiatives that would align with the SAP NetWeaver scheme of things to have a middleware component that would support a wide variety of business scenarios and processes, ranging from industry-specific business scenarios (e.g. Rosetta Net, CIDX), unstructured and flexible collaborative workflows to highly structured long running transactions across multiple systems owned by different business partners namely Org. B, Org. C and Org. D as part of our storyboard. And most importantly, XI fitted in well as the key component in SAP’s product offerings like mySAP SRM, MDM etc., further solidifying the decision.
What Org. A needed was extensive support to web services standards like XML and SOAP to make it a readily viable option in the movement of integration focus to standards based communication between enterprise level services with its core ECC 5.0 component and movement to the SAP business Suite across the board with various business consolidation initiatives within Org. A. The readymade adapters like File adapter for communication with legacy mainframe applications, JDBC adapter for communicating with databases like SQL, Oracle and Sybase, JMS adapter for communicating with other JMS based server queues, SOAP adapter for invoking web services through a WSDL interface provided Org. A with enough incentive to go forward and with SAP’s direction packaged applications like Oracle 11i, Siebel CRM (Oracle again?) and other 3rd party applications, it made sense with the ISV approach for a list of SAP partners provide who these adapters for connecting such applications to these packaged applications within Org. A’s landscape. Given the current technical landscape and the rapidly changing landscape within Org. A, the adapters supporting specific industry protocols like Rosettanet for Hitech & others fitted into the larger scheme of things. Apples to oranges comparison with other EAI tools was always ruled out. Given that for collaborating SAP applications sitting on WAS 6.2 and above, SAP XI provides for using Proxies as an effective alternative of communication between SAP systems instead of ALE IDocs/BAPIs bypassing use of standard RFC/IDOC adapters for communicating with the SAP system the approach adopted by Org. A was a proxy driven one and in leveraging in-house ABAP capabilities to build ABAP objects and workflows to be used within BPM. With this logic, Org. A decided to move ahead with XI 3.0.
Making a business case with Xi 3.0 :
Creating the business case now became simpler for Org. A with the key business drivers for a case becoming:
a. Lower total cost of ownership : Use SAP Exchange Infrastructure to reduce the cost of integration and enables the reuse of existing components that may be currently in use by the existing middleware application. It protects Org. A’s investments by seamlessly integrating components from both SAP and third-party vendors with pre-built adapters to reduce implementation timelines.
b. Easy integration of existing processes : SAP Exchange Infrastructure allowing Org. A to integrate processes within and across organizational and technical boundaries for internal application collaboration and business partners like Org. B, Org. C and Org. D. The integration model using the business process approach and the need to capture and share collaborative knowledge during the entire software life cycle made it the right candidate for designing and extended organization-wide collaborative process model.
c. Easy assembly of new processes: With one end of the Interfaces being built always being an SAP system, it becomes easier for Org. A to use the Exchange Infrastructure offers an integrated tool set to help you assemble existing software in a new way to support new business processes. This becomes easier with the definitions of the business and technical systems on the WAS 6.40 existing to capture the landscape. Coming down from an ARIS process modeling standpoint, It now becomes logical to develop the messaging interfaces, mappings, and routing rules needed to connect application components or create collaborative processes for Org. A.
d. Improved process management, automation, and execution : SAP Exchange Infrastructure can orchestrate the message flow individually for each business process. What started with the business process design at the ARIS level, becomes a lot logical for Org. A to now use to automate these processes according to the identified needs across the heterogeneous landscape within and beyond the boundaries for a true collaboration model. The same can be extended with other applications of the mySAP business suite per the way forward for Org. A
d. Flexibility to embrace new industry standards: The has built-in flexibility to support future standards through connectors and providing a standard framework for development of custom connectors using interoperable development platforms like Java makes this a viable option as, strategically, Org. A has decided to slowly move away from the business connectors and the existing EAI solution that exists as a standalone tool today demanding a specialized set of middleware skills with no SAP knowledge existing in this resource pool – a fact that has been troubling Org. A till date.
e. Pre-delivered Integration Content: Aligning with the changing landscape for Org. A, XI 3.0 seems to fit the bill by providing integration metadata for all mySAP solution like CRM, SRM, SCM and xApps – a fact that radically differentiates it from the likes of other EAI tools. Org. A sees the extension of the Integration repository as a key to the ESA roadmap. This can provide the necessary kick start in the implementation and in significantly reducing time lines to go live with added advantage of upgrades, versioning and transport management.
f. A consistent approach to all integration tasks : With Org. A’s application landscape being Sap-centric, XI 3.0 is to be the single tool set to integrate the myriad of applications within and to manage business processes that span various application components and business partners.
Org. A’s “Landmark” XI Project – UK:
The “Landmark” project in Org. A consists of multiple business systems with the Roll out consisting of around 80 XI interfaces in the UK, 24 interfaces in North America and 23 interfaces in Germany, which had to be integrated with the “Landmark” SAP IS-U system. The connectivity with the external systems was to be through adapters for sending and receiving messages. Adapters to send messages to the Integration engine which the integration engine then applied predefined routing and mapping rules on the incoming message objects to obtain the outgoing messages.
After determining the target application system the outgoing message object is then passed through an adapter (primarily IDOC and file) required to convert the messages to the target system messages and data format. The collaboration definition stored the information on how inbound and outbound interfaces are assigned and mapping rules to be executed. The integration engine is to also provide the necessary message queuing mechanism to ensure asynchronous communication and guaranteed message delivery.
The adapters used in the Landmark project to integrate the participating business application systems are as below.
– FTP – To enable the exchange of files between Integration engine and the FTP servers.
– IDOC – To enables exchange of IDOCs between Integration engine and SAP systems and one side was always an SAP system.
– POP3 – To enable communication with mail servers to receive e-mails
– EDI – To enable sending and receiving messages with Org. A’s partner systems by using the ANSI X-12 and EDIFACT standards.
The non-SAP Systems in Org. A’s landscape contains different types of applications, predominantly file based, few JMS based applications, and an application sitting on a Oracle Database and integrations between them is not to be done with XI 3.0, which is more of a political than a technically sound decision.
The Integration approach for Landmark: The objective of using SAP XI 3.0 as the middleware for integration in Landmark, was to make the systems loosely coupled as well as highly scalable and to provide guaranteed flow of information across applications in near real time. The design is expected to be one that is robust yet simple with the middleware product suite using of out-of-box connectors that provide connectivity to external systems like SAP, FTP servers, JMS and with comprehensive error and alerting mechanism for an automated environment and the integration scenarios primarily consist of inbound and outbound interfaces. Maybe XI 3.0 would not fully scale unto Org. A’s needs today, but the ESA roadmap is in perspective.
Thumb rule Inbound Process : In the inbound process, the XI File adapter is to pick up files from a predefined directory on a remote machine (file based) or subscribe to messages (message based) from a messaging system and de-aggregates the files into SAP IDOC’s to be posted into the SAP. XI is to validate the file structure according to pre-defined rules before de-aggregating them into SAP IDOC’s. The following lays down the thumb rule approach for the integration of the input flat files with the Landmark SAP ISU system.
– The input data files are FTP’d from the source location.
– Based on file type the files are de-aggregated to SAP IDOC’s.
– The data is extracted from these files and converted into a custom middleware event.
– Number of validations and manipulations are then performed on the data based on the predefined rules with a clear design recommendation of making BPM do what it is supposed to do with certain validations being done at the ABAP layer with custom objects designed for this purpose to increase performance. These also include structural validations (data type validations and record sequence validations) using Java functions.
– Based on the result of these validations the data file is to be sent to the SAP system for further processing, and all incoming files are also to be archived into appropriate remote folders.
– Any error or exception is tracked and handled appropriately.
Thumb rule Outbound Process : In the outbound process, Org. A’s R/3 system will generate the IDOCs. XI is to process and aggregate the IDOC’s and would need to merge them into file(s) based on the file-type and routed to different target locations. The following explains the thumb rule approach for the outbound process within Org. A.
– The data will be received from SAP in the form of IDOCs.
– The data is to be converted into custom middleware event.
– The data from these events is to be aggregated and converted into files and to be stored in a temporary directory
– The Header and trailer information is to be added to these files.
– These files are then to be FTP-ed to different directories or sent as e-mail attachments based on the business requirements.
Org. A’s “Landmark” XI Project – NA: Landmark is a business process re-engineering and business transformation program which includes the design, development, delivery and implementation of the customer care and billing solution to replace the existing legacy billing and information systems. The Solution involves an SAP ISU, CRM and BW applications with over 8 non SAP systems including billing applications. The integration layer to be SAP XI, with the system being rolled out to over 900 users across locations in North America. This includes an integration with the pricing engine of Org. A and SAP FI-CO.
As stated earlier in this blog, XI 3.0 is to be used to interface close to 150 interfaces, mostly File and IDOC, including a number of interfacing points to Java applications across financial, and billing. Though most of the interface use IDoc and File adapters for connection end points, the integration scenarios will also need to find the use for Java and ABAP proxies.
Org. A’s “Landmark” XI Project – Rest of EUR : This Pilot project for Landmark is to be a case analysis of how SAP XI could be used in Org. A’s “Landmark” project to integrate SAP applications to non SAP applications in a predominantly SAP applications landscape. For the pilot 6 critical business interfaces were chosen, namely Expense authorization, Invoice, GL , Vendor Master, Vendor Payment Interface and Purchase Order – some inbound, others mostly outbound.
The end system is a file based interface connecting to Org. A’s Mainframe application. Primarily using File Adapter, RFC adapter, ABAP Proxies and JDBC adapter, the integration scenarios are to involve the extensive use of Java mappings for content conversion owing to high complexity in file structure hierarchies and structural validations using ccBPM tool for data validations which have to be processed on the header-child records. The challenge here is huge as none of the data files available from the Org. A’s key business partners are pre-validated for data accuracy today and hence the onus of validating the same now has to be that of XI 3.0 before pushing the same to the SAP system. Another significant feature is the use of ABAP proxies in Synchronous outbound interfacing scenario to expose Payment data from SAP system to the mainframe application. Performance is key here.
The key point here is – the conviction around XI 3.0 usage stems not only by the usage of the same in an SAP dominant environment, but it is the recognition of the fact that XI will be the hub for Enterprise services in the future will what determine the direction a Solution Architect needs to consider. What started off as the innocuous SE80, moved ahead with the WAS 6.40 UDDI server will now move ahead with the Enterprise Services Repository as the design-time repository of service objects for Enterprise Services Architecture. The Enterprise Services Repository is to contain the description of the interface of the enterprise service as the WSDL file. Once in the repository, all services will be available for reuse. As the Enterprise Service Builder has been identified by SAP as the tool for creating and editing service objects, models, and interfaces contained in the Enterprise Services Repository, this finds a home in SAP XI Integration builder searchable for users within Org. A and others. And Org. A now knows it made the right decision on the path to ESA…..knowingly or unknowingly.
And therein starts the differentiation of XI making the comparison with other EAI tools, meaningless, for an SAP shop. XI now evolves into the ESA hub for the Solution Architect of Org. A. And we have led Org. A down the ESA path without getting into esoteric discussions…Your feedback would be greatly appreciated.