Business Process Integration

102
Studiengang: INFOTECH Betreuer: Dipl. Inf. Clemens Dorda Dipl. Inf. (FH) Tanja Schaettler (Hewlett Packard) Prüfer: Prof. Dr.-Ing. Habil. Bernhard Mitschang Beginn am: 30.Sep.2003 Beendet am: 30. Mar.2004 CR-Klassifikation: K.6.4 Diplomarbeit Nr. 2152 Business Process Integration Xu Li Fakultät Elektrotechnik, Informatik, Informationstechnik Universität Stuttgart Institut für Parallele und Vrteilte Systeme (IPVS) Abteilung Anwendersoftware (AS) Universitätsstr. 38 70569 Stuttgart

Transcript of Business Process Integration

Page 1: Business Process Integration

Studiengang: INFOTECH

Betreuer: Dipl. Inf. Clemens Dorda Dipl. Inf. (FH) Tanja Schaettler (Hewlett Packard) Prüfer: Prof. Dr.-Ing. Habil. Bernhard Mitschang

Beginn am: 30.Sep.2003

Beendet am: 30. Mar.2004

CR-Klassifikation: K.6.4

Diplomarbeit Nr. 2152

Business Process Integration

Xu Li

Fakultät Elektrotechnik, Informatik, Informationstechnik Universität Stuttgart Institut für Parallele und Vrteilte Systeme (IPVS) Abteilung Anwendersoftware (AS) Universitätsstr. 38 70569 Stuttgart

Page 2: Business Process Integration

Business Process Integration 2

Table of Contents Abstract & Key Concepts ……………………………………………………………….5 1 General Introduction................................................................................................ 6

1.1 Integration challenge........................................................................................... 6 1.2 Existing Styles of Integration.............................................................................. 6 1.3 Business Process Integration............................................................................... 7 1.4 Process Integration Challenge............................................................................. 8 1.5 Collaborated Business Process Integration......................................................... 8

2 Business Process Management (BPM).................................................................. 10 2.1 Business Process Reengineering and Management .......................................... 10 2.2 Business Process Modeling and Orchestrating ................................................. 11 2.3 BPM Benefits.................................................................................................... 13

3 Introduction of SAP Exchange Infrastructure..................................................... 14 3.1 General Introduction ......................................................................................... 14 3.2 Architecture Overview...................................................................................... 14 3.3 Message Handling Mechanism......................................................................... 16 3.4 Key Integration Principles ................................................................................ 17 3.5 BPM in SAP NetWeaver .................................................................................. 18

4 Process Integration Catalogue with XI ................................................................. 21 4.1 Collaborated Process Integration with SAP XI ................................................ 21 4.2 XI Connectivity Overview................................................................................ 22 4.3 New Adapter Framework in XI 3.0 .................................................................. 23 4.4 Integration Catalogue........................................................................................ 24

4.4.1 SAP-to-SAP integration............................................................................ 24 4.4.1.1 IDoc Adapter......................................................................................... 24 4.4.1.2 RFC Adapter ......................................................................................... 25 4.4.1.3 Proxy Framework.................................................................................. 26 4.4.1.4 HTTP between Integration Engines...................................................... 27 4.4.1.5 Web Service Framework....................................................................... 28 4.4.1.6 Conclusion ............................................................................................ 28

4.4.2 SAP – mySAP Business Suite Integration................................................ 31 4.4.2.1 SAP – mySAP CRM............................................................................. 31 4.4.2.2 SAP – mySAP SRM ............................................................................. 32 4.4.2.3 Master Data Management ..................................................................... 32 4.4.2.4 Conclusion ............................................................................................ 33

4.4.3 SAP – non SAP Integration ...................................................................... 34 4.4.3.1 File Adapter .......................................................................................... 34 4.4.3.2 Plain HTTP Adapter ............................................................................. 35 4.4.3.3 JDBC Adapter....................................................................................... 36 4.4.3.4 JMS Adapter ......................................................................................... 36 4.4.3.5 Proxy..................................................................................................... 37 4.4.3.6 SOAP Adapter ...................................................................................... 39 4.4.3.7 SMTP Adapter ...................................................................................... 40 4.4.3.8 Java Mapping ........................................................................................ 40 4.4.3.9 Conclusion ............................................................................................ 41

Page 3: Business Process Integration

Business Process Integration 3

4.4.4 B2B Integration......................................................................................... 42 4.4.4.1 Industry Standards Adapter................................................................... 42 4.4.4.2 Partner Connectivity Kit (PCK)............................................................ 43 4.4.4.3 Web Services and ebXML.................................................................... 44 4.4.4.4 Conclusion ............................................................................................ 44

4.4.5 XI and other EAI Interoperability............................................................. 45 5 Implementation of Process Integration................................................................. 47

5.1 Pricing Reference Server Scenario Description................................................ 47 5.2 PRS Scenario Requirement Analysis................................................................ 48 5.3 XI Solution Design ........................................................................................... 50

5.3.1 IDoc – plain HTTP Adapter...................................................................... 51 5.3.2 IDoc – Proxy (J2EE or ABAP)................................................................. 54 5.3.3 Web Services and Framework .................................................................. 57 5.3.4 General Publish / Subscribe Design via XI............................................... 58 5.3.5 Long-term Scenario Design Proposal ....................................................... 59

5.4 Gap Analysis..................................................................................................... 60 5.4.1 Message Referencing ................................................................................ 60 5.4.2 Same Mapping List ................................................................................... 60 5.4.3 Exactly Once in Order Message Delivery ................................................ 61 5.4.4 Queue Management .................................................................................. 62

5.5 PRS Scenario Summary.................................................................................... 63 6 Integration with BEA WebLogic Integration ...................................................... 65

6.1 Introduction of BEA WLI................................................................................. 65 6.2 WLI Integration Conception and Methods ....................................................... 67

6.2.1 Business Process Management ................................................................. 67 6.2.2 Message Broker ........................................................................................ 67 6.2.3 WebLogic Integration Controls ................................................................ 68 6.2.4 Web Services as Control........................................................................... 72 6.2.5 Data Transformation ................................................................................. 73 6.2.6 Application View and Adapter ................................................................. 73 6.2.7 Worklist..................................................................................................... 74

6.3 Application Integration with WLI .................................................................... 74 6.3.1 Integration through Controls and Message Broker................................... 74 6.3.2 Integration through Application Integration Framework.......................... 75

6.4 B2B Partner Integration with WLI ................................................................... 76 6.5 BPM in BEA WebLogic ................................................................................... 78 6.6 Comparison BEA WLI vs. SAP XI .................................................................. 79

6.6.1 General Positioning................................................................................... 79 6.6.2 Integration Features .................................................................................. 80 6.6.3 Enterprise Application Integration............................................................ 83 6.6.4 B2B Integration......................................................................................... 84

6.7 Summary ........................................................................................................... 85 7 General Process Integration Methodology ........................................................... 87

7.1 Communication Mechanism ............................................................................. 87 7.1.1 Publish and Subscribe ............................................................................... 87 7.1.2 Request and Reply .................................................................................... 88

Page 4: Business Process Integration

Business Process Integration 4

7.2 Connectivity Technology.................................................................................. 89 7.2.1 Adapters .................................................................................................... 89 7.2.2 Proxies....................................................................................................... 89 7.2.3 Web Services ............................................................................................ 90 7.2.4 Industry Standards .................................................................................... 90

7.3 Conclusion ........................................................................................................ 91 8 Outlook of Process Integration Tool ..................................................................... 92 Appendix A: List of Figures and Tables ……………………………………………...96 Appendix B: References ……………………………………………………………….98 Appendix C: Glossary ....………………………………………………………………99

Page 5: Business Process Integration

Business Process Integration 5

Abstract Business processes are on demand to be integrated in enterprises and among business partners. Standards are available to support integration, and both the business systems and integration products (EAI software) provide various ways and adapters for integration. It is challenging to look for a high-performance/low-cost manner for integrate business systems depending on concrete scenarios, and a general catalogue for integration method would be of interest. On the other hand, enterprises calls for business process management (BPM) to orchestrate and streamline their composite business processes. It is also within the concern of this paper that how BPM benefit. A detailed inside look and a prospective outlook of BPM is endeavored. The discussion within this paper mostly based on the integration broker Exchange Infrastructure (XI) from SAP and Web Logic Integration (WLI) from BEA. The two tools are studied and analyzed in this paper, to give a summarization of general process integration methodology and technology, and general requirements for such kind of integration tool.

Key Concepts The discussion in this paper mainly focuses in two parts: business process integration and business process management. Descriptions about the two concepts come first: Business Process Integration: controlled sharing of data and business processes among any connected applications and data sources within an enterprise and between business partners, without having to make sweeping changes to the corporations existing information assets. Introduction about business process integration comes at the first chapter General Introductions, and detailed study into business process integration comes with two parts in the paper: process integration catalogue with XI, and implementation of process integration. Business Process Management (BPM) enables organizations to automate, streamline and manage business processes, which including design, automate, execute, monitor, analyze and optimize business processes. BPM concept is explained in detail in the second chapter Business Process Management, and how BPM functions are described in XI and WLI respectively.

Page 6: Business Process Integration

Business Process Integration 6

1 General Introduction

1.1 Integration challenge Increasingly over the recent years, IT departments have focused less on building new applications. Instead they have devoted more effort to connecting existing applications. Mergers and acquisitions have increased, while corporations have found that they cannot continue to leverage their accumulated IT assets. New technologies and product releases often leave these business assets on orphaned, legacy infrastructure islands. Over the next decade, integration will continue to be the dominant challenge facing IT and corporate software development experts, and the ability to manage integration becomes the cornerstone of a corporation’s quick and proactive adaptation to the market change. Business document exchange

A corporate objective is to connect separate systems within an enterprise. For example, an enterprise might need to make a Customer Relationship Management (CRM) package and a financial application package such as Oracle Financials communicate with each other. More real-time message-based communication between systems is extremely demanding

Connecting internal applications Corporation needs to establish connectivity between internal applications within its own corporate environment. These applications have key corporate business functionalities implemented in relatively isolated technology islands.

Integrating with business partners Besides internal applications, corporation also needs to integrate their existing heterogeneous IT landscape and extend this integration to their business partners. They need a plug and play environments where systems and partners can be easily included or replaced without major efforts

1.2 Existing Styles of Integration Integration-based products can be categorized into a number of useful types, most common styles are:

Integration between applications within a business, often called Application to Application or A2A. When A2A is coupled with a process-oriented sequencing engine, it is often referred to as Enterprise Application Integration (EAI).

Integration between businesses, often called Business to Business, or B2B. E-Commerce Integration, an emerging new style of integration whereby

businesses establish and change collaborations in a highly dynamic and rapidly changing environment

A2A integration, or Application to application integration means following: translating data and commands from the format of one application into the format of another. It is essentially data and command conversion on an on-going basis between two or more

Page 7: Business Process Integration

Business Process Integration 7

incompatible systems. The other aspect of application integration is redesigning disparate information systems into one system that uses a common set of data structures and rules. Implementing application integration has traditionally been done by tedious programming, or occasionally one package might support the interfaces of one or two other packages. However, the trend today is to use message brokers, application servers and other specialized integration products that provide a common connecting point. Since the advent of the web, these prepackaged middleware solutions have become widely used to web enable the enterprise. EAI refers to application integration within a business, it is combination of processes, application and standards and hardware resulting in the seamless integration of two or more enterprise applications allowing them to operate as one. B2B integration refers to application integration between business partners, i.e. a company to integrate its internal enterprise application with those of its business partners. B2B integration occurs when systems of tow or more business exchange information that, directly or indirectly, results in a transaction. Typically, the exchange involves aggregating information form and/or distributing information to multiple organizations as part of a transaction. A transaction includes traditional purchases or other events such as fulfillment, bids, inventory replenishment etc. transactions themselves are typically real time, the aggregation and distribution of data across companies may or may not be real time, depending on the transaction requirements.

1.3 Business Process Integration Business process is a repetitive set of actions required to complete a specific task, such as a sales order confirmation or purchase order fulfillment. Business process defines how companies do business and how they create differentiable advantages against competitions. It makes financial sense to apply technology to automate critical business processes and remove costly human error, training and overhead, but these processes are typically complex and involve information, knowledge and interactions form multiple departments or entities. While EAI focuses on technical integration, business process integration focuses on integration on and support of processes that contains business logics and information needs. Business Process Integration uses visual, business process driven models to provide real time visibility and control of strategic business processes that across applications, data, people and companies. Business process integration usually provides functionalities of connectivity, process automation, visibility and decision support. Connectivity refers to establishing communication both within an enterprise and with external business partners such as suppliers and customers. It is a prerequisite for all integration in a distributed environment. Business process automation can be defined as the management and automatic transfer of information by software. Here human intervention is completely eliminated or reduced to the process steps where such intervention is a business requirement. Visibility is about access to aggregated and consolidated real time information within and across enterprise boundaries. Decision

Page 8: Business Process Integration

Business Process Integration 8

support involves the aggregation, synthesis and presentation of information to enhance human decision processes. Products that support business process integration usually contain engines that orchestrate the flow of data in a business process. The engine works as a master or meta application that decides when to invoke what applications, and controls data input to and output form underlying applications. Business process integration products also contain several pre-defined template sub-processes at the most granular level possible, i.e. prepackaged, extensible business process solutions. And business processes can be built up by combining sub-processes. They also embrace industry standards and deliver industry-specific business process solutions. Automating, integrating and deploying business processes is only the beginning. The true value comes when enterprises can continue to analyze and optimize automated business processes to ensure that they are efficient, achieving their business objective and adequately addressing the dynamic market conditions, i.e. manage business processes.

1.4 Process Integration Challenge As companies struggle to unify disparate business processes and applications, integration is one of the key corporate constrains on revenue growth, increased productivity and business performance visibility. Current integration in process is discrete, mostly there is individual, point-to-point integration, using whatever technology available to integrate applications. Therefore there may be different integration approach for each purpose: A2A or B2B integration. Such kind of integration results in patchwork of integration solution itself, and it lacks of centralized knowledge or management of integration available. The enterprise infrastructure is growing, but integration solutions are not adaptable, and the new infrastructure demands for new integration solution, therefore it is expensive to maintain as high cost is always associated with integration and upgrade of application components Therefore enterprise demands for new integration solutions that cover both A2A and B2B integration open and have wide interoperability, support open and industry standards, central integration rather than individual point to point integration. And business process management functionality is also very important to be included into process integration solutions.

1.5 Collaborated Business Process Integration To capture the next round of efficiency gains, corporations must deploy a new breed of collaborative business processes that cross enterprises or cross functions within an enterprise, as well as replace batch processing with real-time scenarios. These collaborative processes require a significantly more sophisticated integration infrastructure than traditional processes.

Today’s integration environment is characterized by mostly batch-oriented, file or message-based interfaces using point-to-point connections between systems. This

Page 9: Business Process Integration

Business Process Integration 9

approach becomes problematic, when corporation’s system landscape gets large and complex, while it generates an ad hoc picture filled with point-to-point connections.

Collaborated process integration eliminates the problems of direct connections by extracting shared collaboration knowledge. These shared business semantics ease the integration of both external and internal components. Instead of directly coding point-to-point interfaces for each new component, collaborated integration provides an infrastructure which allows instant plug-in of new components once per component, a collaborated repository describes all the metadata regarding business systems in landscape as well as all exchange information during the execution of a specific business process, and business process engine controls and tracks the state of a business process for process-centric integration.

.

Page 10: Business Process Integration

Business Process Integration 10

2 Business Process Management (BPM) Business process management plays an important role in business process integration. A primary study into business process management is carried out in this chapter: first a need for business process management is discussed, then methodology in business process modeling and orchestrating is discussed, how does business process management function in SAP NetWeaver and BEA WebLogic is studied, and BPM benefits are shown at last.

2.1 Business Process Reengineering and Management Enterprises information systems used to be functionality structured, each department may have their own legacy systems oriented for business operations within its own business functionality. This kind of structure has no integrated control on business process that is cross-functional. Business process reengineering happened around 1995, when it changes from functional structure into business process based structure. Enterprise information system are no longer functionality oriented, but oriented for business processes that usually cross functionality border and provides service for its business partners, e.g. customers. For example, an order processing process usually involves purchasing, production, marketing and sales functional departments. The change is illustrated in the graph below:

Figure 1 Business Process Reengineering

After business process reengineering, the demands for cross functional business process management arises. Business process management provides enterprises with following: Driving processes within and across different applications Design, automation, execution, monitoring, analysis, optimization of business

processes Moving process control from applications to a technology layer Allowing companies to automate, streamline, and manage processes Human interaction, planned or spontaneous is involved The right technology for integrating people, applications, internal and external

resources including workflows

Page 11: Business Process Integration

Business Process Integration 11

The concept of BPM is given by Ovum in Oct. 2002 like following: “Business process management (BPM) is a change management and system implementation methodology to aid the continuous comprehension and management of business processes that interact with people and systems, both within and across organizations.” The goal of BPM is provide enterprise with speed, efficiency, improvement and high ROI. BPM realizes this goal as it oils process by providing: Right information at the right time Proactive process engine, pushing work using deadline and exception handling Process transparency and accountability Process to process integration

From the description and definition about BPM, it can be predicted that the next generation of enterprise application will emerge to: Enable companies to build new cross-functional, cross-enterprise business

processes on top of existing investments in data and business logic Provide intelligence and transparency to coordinate business processes across an

extended network Enable Business Process Management for flexible process integration beyond

enterprise application integration SAP NetWeaver04 and BEA WebLogic 8.1 are both this kind of enterprise application platform that endeavor to realize above features, and how is their efforts look like in BPM is looked into if following subchapters.

2.2 Business Process Modeling and Orchestrating Before have a look into BPM, it is important to understand how business process is modeled and orchestrated. Usually following elements should be considered while designing a business process: Trigger

How a process should be triggered. A process can be triggered by a client request, by a message (the process might subscribe to a channel, and when any message arrives at the channel, the process will be triggered), and by a schedule (a process can be triggered on a scheduled time or event). And what kind of client request, message or schedule will trigger the process respectively Receive message and trigger process

How a process receives messages from other process or system, where and what to receive. Upon receiving the message, it may process on that message, and may trigger another business process Send message

How a process send message to other process or system, where to send to, and whether the process should get response or acknowledgement for the sent message, if yes what kind of response to receive. When multiple systems or processes are involved, there exists a synchronization issue on receive and send, some business process patterns like collect, serialization and multicast will be discussed below

Page 12: Business Process Integration

Business Process Integration 12

Transformation What kind of transformation is necessary inside the business process. It may include data transformation between received message format and the message format to send out. It may include message combination and split as well sometimes, for example, transform collected message to a new message like several invoices to one, or split a message into several other messages Receiver determination and conditions

How a process determines receivers for its outbound messages. A process may need to deliver messages to several systems, when to deliver which message to which system should be decided by clearly defined conditions Process flow elements

What kind of process flow elements should be included into process. Most common elements includes: switch, parallel, assign, wait, callback etc Deadline and deadline handlers

Where is necessary to define a deadline in the process, and if deadline reached, what kind of actions to take to handle it Exception and exception handlers

Where is necessary to catch exceptions and correspondent exception handlings Above is basic elements to consider while modeling and design, when orchestrating business processes where multiple senders or receiver are involved in the business process, following patterns may be adopted, and how to synchronize messages in each of these pattern should be determined: Collection

Collection mode should be considered when many systems send message to a process, the process should be able to decide how it collects messages when to end collection. There are two principle modes for collecting messages: push and poll. In push mode, a process collects messages until a certain condition is reach (e.g. a certain number of messages has been reach or a certain deadline reached), and then send messages out. In poll mode, the process keeps polling or collecting continuously, and when a certain event is triggered, the process sends all available messages out and keeps polling continuously. Collection ends upon certain condition has been reached, the condition could be: time restrictions (collects for a certain time), a sufficient number of messages was collected, or another message arrives. Serialization

Serialization is necessary when multiple senders send message to a certain receiver or multiple receivers, and the sequence that these messages arrive at the receiver should be synchronized, i.e. the messages must be submitted to the receiver in a certain order. The certain order can be guaranteed here by the following way: a process receives message from multiple senders, it sends message out according to a given order respecting the dependency of the receiver and waits for acknowledgment of the first message before sending the next. Multicast

Multicast refers to that a process needs to send messages to multiple receivers. A process receives message or creates a message, then it needs to determine the number of receivers

Page 13: Business Process Integration

Business Process Integration 13

and get the list of receivers, and sends message out via looping through the receivers list, it may send messages to receivers in sequence or in parallel, and then waits for response when necessary. Above is just a general description about basic elements should be considered in business process modeling and orchestrating. As the business processes in reality might be complicated, the business process design work is critical and requires more detailed consideration. From following, BPM functionality in SAP NetWeaver and BEA WebLogic are studied respectively, as the two tools both supports BPM functionality and ease users from the process design work with their available features.

2.3 BPM Benefits From the discussion above, it is clear that the benefits of Business Process Management is that it integrates business process design, modeling, orchestration, automation, execution, monitoring and optimization, it streamlines and expedites business process consequently, brings speed, efficiency and improvement to business process and brings higher ROI to enterprise eventually. Business process management is an important factor in business process integration. BPM usually manages business process that is cross functional, involves multiple business systems and software components, and could also be processes that involve business partner interaction. Both SAP NetWeaver and BEA WebLogic provides business process integration platform and supports business process management. They usually provide a graphical process modeling tool and adopt open standard for process design. NetWeaver supports BPM from ad-hoc workflow, business workflow and cross-component BPM levels, BPM is BPML (Business Process Modeling Language, see Appendix C) based, and equipped with a process engine to automate process execution. WebLogic support both workflow and business process management, it adopts Java in process design and use integration control to access resources, and execution is automated by deploy and run a process integration application. BPM is an emerging and valuable field for study, much more efforts are demanded to understand and develop.

Page 14: Business Process Integration

Business Process Integration 14

3 Introduction of SAP Exchange Infrastructure

3.1 General Introduction Exchange Infrastructure is an integration product from SAP, a platform for process integration based on the exchange of XML messages. It is a component of SAP NetWeaver, which is an open integration and application platform providing people, information and process integration.

Exchange Infrastructure is dedicated to Provide a technical infrastructure for XML-based message exchange in order to

connect SAP components with each other, as well as with non-SAP components Provide an integrated toolset for building new business scenarios by defining and

maintaining all integration-relevant information (“shared collaboration knowledge”)

The current version is 2.0, which is available since Dec. 02. The next version XI 3.0 is going to be released Mar. 04, which is part of the whole NetWeaver 04 package, lots of new functionalities are coming with the new version, including the business process management engine.

3.2 Architecture Overview Figure 1 shows a complete overview of the technical architecture implemented by exchange infrastructure. It consists of following parts:

Figure 2 XI 2.0 Component Overview

Page 15: Business Process Integration

Business Process Integration 15

Integration Server Central integration part for message processing. All messages sent to XI will be processed by the integration server, which contains an Integration Engine. According to configurations for each integration scenario, the integration server will perform receiver determination, mapping and routing on messages. Integration Repository Collaborated design knowledge repository, enables the management of business scenarios, message interfaces, mappings and other meta-data at design time. It contains also pre-delivered business knowledge for SAP solutions, such as IDocs and RFCs from SAP R/3 system. Business process definition will also be available in integration repository from XI 3.0 version. Integration Directory Collaborated configuration knowledge repository, enables the management of routing relations, routing conditions and executable mappings at configuration time. Integration scenarios are designed in integration directory and making use of designed objects from integration repository. System Landscape Directory Collaborated repository of system information in landscape, it enables the management of components and system landscape. All products, software components and business systems that will be used in integration scenarios should first be defined in the system landscape directory with their technical information. Once defined, the software components and business systems can be used in any integration scenario. Runtime Workbench Provide runtime monitoring for business systems. Integration Builder Graphic environment where users can access integration repository, directory, system landscape and runtime workbench. Via integration builder, users can edit components in integration repository and system landscape and integration scenarios in integration directory. Proxy Framework Enable the generation of platform-dependent proxies from XML-based interface descriptions in the Integration Repository for both ABAP and Java. The ABAP and Java proxy runtime is the underlying component to handle communication between proxies and integration server at runtime. Users can implement business logics based on proxies without having to taking care of underlying communication with integration server. Adapter Framework Contain adapters connecting the Integration Engine to SAP legacy systems, as well as to external systems. Following is the physical architecture overview of Exchange Infrastructure:

Page 16: Business Process Integration

Business Process Integration 16

Figure 3 XI 2.0 Architecture Overview

3.3 Message Handling Mechanism The following figure briefly describes how the Exchange Infrastructure proceeds an incoming message with the internal message flow. When XI receives a message, the adapter or proxy framework converts the message to a XML based object and forwards it to the integration server. The integration server then implements logical and physical routing, and mapping when necessary, and forwards the message to the receiver systems. Figure 4 Integration Server transferring a message (from XI white paper)

Page 17: Business Process Integration

Business Process Integration 17

3.4 Key Integration Principles As conclusion part of XI introduction, following key principles should be noted: Collaborated (Shared) integration knowledge

The main concept of XI is to enabling collaborated integration knowledge instead of point to point individual integrations. The concepts like integration repository, directory and systems landscape all work for the shared integration knowledge. Besides, pre-packed business integration contents with SAP solutions are delivered. It should be noted that XI provides collaborated integration knowledge that can be shared by all integration scenarios, but it is nature that in each integration scenario, point to point integrations should set up between sender and receiver systems, according to outbound and inbound message interface types. Openness

XI aims for openness as it adopts the open standards for integration, like XML, SOAP J2EE (Java 2 Enterprise Edition) etc. not only among SAP application integration, but also for integration with third-party systems and business partners. Flexibility

Integration scenarios are adopted by configuration in XI, user coding is minimized but users could also choose coding to enhance functionalities. For example, users can set up integration scenario by specifying sender and receiver business system and corresponding interfaces, no coding is necessary with these steps, but users can also choose coding while defining XSLT (XML Stylesheet Language Transformation, see Appendix C for details)or Java mappings, although XI provide a graphic tool for mapping design. And proxy framework, adapter framework and Web Service (see Appendix C for explanation) framework enable plug-in structure, where services and process can be easily and non-disruptively inserted or modified.

Page 18: Business Process Integration

Business Process Integration 18

3.5 BPM in SAP NetWeaver SAP NetWeaver supports BPM on different level, below is the whole picture of BPM in NetWeaver:

Figure 5 Business Process Management in SAP NetWeaver

There are three different kinds of workflow and business process management defined in NetWeaver: Ad-hoc workflow

Ad-hoc workflow refers to workflow that demands pure user interaction, and rather informal, non-repeatable and disorganized in its structure. It is usually triggered by a Universal Work List item in business workflow or cross-component BPM. For example, a purchase order is issued by a business process, but before the PO can be processed further, it needs approval from responsible user, a process or business workflow may issue a universal work list item to the responsible user for approval. Ad-hoc workflow is managed by Enterprise Portal, which provide human interaction collaboration. In EP users have a central access to universal work list items, and process it. Users can also issue a work request, have an overview of all opening and completed items. After a user processed a work list item, certain response will be send to the process or workflow or user that requested the work list item, and the process or workflow can go ahead. Business workflow

Business workflow refers to normal SAP workflows that running on mySAP ERP, CRM, SRM and other third-party systems, there are usually specific workflow modeler in these applications. This kind of workflow runs only within the application itself, it does not

Page 19: Business Process Integration

Business Process Integration 19

require integration with other applications or business process in other applications, but it can involve user interaction by issuing universal work list items. This kind of workflow is managed by SAP Web Application Server, which provides workflow builder where users can build their workflow up and manage it. Cross-Component BPM

Business workflow provides intra-application process automation, while cross-component BPM provides inter-application process automation. Cross-component BPM manages business process that involves multiple rather than single business system, and even business partner, and might user integration as well. This kind of process is quite usual, for example a sales order process: the process starts from customer process who issues the purchase order, then the supplier CRM system is used to create a sale order, and ERP system is used to create and release deliver request and triggers execution, and BW system may be used to update supplier inventory database. A single process involves multiple software components and business partners, and it needs a cross-component BPM tool to manage it. Exchange Infrastructure provides cross-component BPM functionality from 3.0 version, the picture below shows the whole picture where cross-component BPM functionality is supported in XI.

Figure 6 Cross-component BPM in XI

XI provides business process management functionality from its integration repository, integration directory and business process engine.

Page 20: Business Process Integration

Business Process Integration 20

Integration Repository XI provides a graphical process builder, where users can easily build business processes. And XI generates BPML specification automatically for business processes, which can be exported. Business process object is incorporated in a namespace with a name and maintained as an object in integration repository. Integration Directory

For business process objects, there is a reference in integration directory to its originating process in integration repository. So business processes can only be deployed not created in integration directory, and there is no process definition in integration directory (process definition exists in integration repository). Routing and Mapping

Business processes can be addressed as a source or target in any integration scenario, and processes can be addressed in the same way like any business system. There is a business process engine on integration engine to automate and execute business process adhering to standards, and the actual business process management runtime extends business workflow runtime, which is available on SAP Web Application Servers. The business process engine and runtime is an integral part of integration server. Generally BPM functionality in XI can be summarized as following: XI enables design, execution and monitoring of automated processes across applications and systems, and provides process control in the central technology layer. XI contains a graphical process modeler; users can build up business process by simple drag and drop of process nodes and implement or configure the nodes afterwards. Business process integration is an integral part of XI, the BPM runtime is embedded in the integration server runtime, and when modeling a business process, users can directly link to other design objects in integration repository like interfaces, mappings etc. Business process management in XI adheres to standards. XI supports open standard BPML4WS in process design, and process definitions can be imported and exported. In case of B2B process integrations, industry standards are supported, like RosettaNet (see Appendix C for explanation) for high tech industry. From monitoring point of view, technical process monitoring is integrated with XI monitoring, i.e. process can be monitored via integration engine monitoring. There is also graphical process monitoring supported by XI.

Page 21: Business Process Integration

Business Process Integration 21

4 Process Integration Catalogue with XI

4.1 Collaborated Process Integration with SAP XI As introduced in the first chapter, companies are adopting collaborated business processes, which enable users and heterogeneous systems to interact across organizational boundaries to achieve a common goal. To implement collaborative business processes, companies need to integrate their existing IT landscape and extend this integration to their heterogeneous partners, therefore an open integration infrastructure supporting intra- and inter-enterprise business processes is necessary. As described above, XI provides openness and flexibility for collaborated business process integration. It supports lots of possibilities to integrate SAP and non-SAP applications, third party systems and business partners. In the discussion below, XI is considered as the integration broker, i.e. the integration catalogue given below is based on XI. Since XI has many integration possibilities, a first look into XI connectivity is given below. It describes all the possible means to connect to XI. Then some new connectivity features in XI 3.0 are introduced, as the adapter framework. The new adapter framework introduces some future integration possibilities, which are quite interesting for the discussion of integration catalogue. The focus of this chapter is to give a high-performance/low-cost integration catalogue according to concrete scenarios, where XI is always considered as the fundamental integration infrastructure. As there are many options to integrate, to achieve the best competitive advantage, performance and efficiency becomes the focus of integration, e.g. which option achieves best according both technical and business point of view. In the subchapter ‘Integration Catalogue’, different integration scenarios are discussed, and personal recommendations are given for such purpose.

Page 22: Business Process Integration

Business Process Integration 22

4.2 XI Connectivity Overview Following figure depicts all the connectivity possibilities to XI. Basically XI can integrate business systems via its following component:

Adapter Framework IDoc, RFC, File, DB, Messaging, HTTP, third party adapter, Partner Connectivity

Proxy Framework ABAP and Java proxies

Web Service Framework (in XI 3.0) SOAP connectivity

SAP System <6.20 SAP System >=6.20

ABAP J2EENon SAPSystem

Non SAP System SAPSystem

ABAP

ABAPApplication

JavaApplication

JavaApplication ApplicationApplication

EDI / IDocApplication Market

SetIntegration

EngineJava-Proxy

RuntimeJava-Proxy

Runtime

MMLvia

HTTP(S)or

SonicMQ

Msgqueue

XMLHTTP

XMLHTTP

XMLHTTP

Database

SOAPIDoc IDoc RFC IDoc RFC HTTP File

JDBC MarketSet

Adapter

JMSFileAdapter

SOAPAdapter

Exchange Infrastructure JDBCAdapter

JMSAdapter

RFCAdapter

Integration BuilderIDoc

AdapterRFC

AdapterplainHTTPIntegration

RepositoryIntegrationDirectory

Message Exchangeinternal XML based message representationSLD

System LandscapeDirectory

ISIntegration Server

Figure 7 Adapter Framework

Generally speaking, IDoc and RFC adapter are used for XI to connect to SAP R/3 system, file adapter is used to access file systems, JDBC adapter to database systems, JMS adapter to JMS (Java Messaging System, see appendix C) based messaging systems, SOAP adapter to web service clients or web application servers, HTTP adapter to connect systems via HTTP connectivity, eco-partner adapters to other ERP systems besides SAP, Proxy framework to connect to web application server and Java/J2EE applications via ABAP and Java/J2EE proxies, Web service framework as replacement of SOAP (Simple Object Access Protocol, see Appendix C) adapters for web service connectivity, and partner connectivity kit to connect to business partner applications. Details about the connectivity above are discussed according to their application in different integration scenarios in following sub chapters.

Page 23: Business Process Integration

Business Process Integration 23

4.3 New Adapter Framework in XI 3.0 In the coming 3.0 version of XI, the adapter framework is optimized, as shown in the following architecture overview. The new integration features of XI3.0 are also discussed in the integration catalogue below.

The new adapter framework is JCA (J2EE Connector Architecture, see appendix C) based. It has a central adapter engine located on the integration server. Meanwhile discrete adapter engines can also be installed on other hosts. Other third-party adapters can be connected to the framework as well, which provides possibility to integration more third-party systems or EAI tools. The J2SE (Java 2 Enterprise Edition) adapter engine from XI2.0 is still supported, and a partner connectivity kit is available to integrate with business partners. The framework provides a central point to configure and trace of all adapter engines installed, and a database for message persistence.

In the new adapter framework, there are following different kinds of adapters:

SAP Native Adapters IDoc and RFC connectors to integrate SAP R/3 legacy systems

Technical Resource Adapters File, Database, HTTP and JMS adapters as exist in XI2.0

Third-Party Adapters JCA based adapter framework enables adapters from third party systems to plug into the framework and integrate with XI, e.g. iWay adapters

B2B Adapters The partner connectivity kit consists of B2B adapters supporting different industry standards, e.g. RosettaNet

Partner ConnectivityKitJ2SE

Adapter Engine XI 2.0

Adapter

Integration Repository / Integration Directory / System Landscape DirectoryIntegration Repository / Integration Directory / System Landscape Directory

Integration ServerIntegration Server

SAPSystem

SAPSystem

RFC

/IDoc

Adapter

Business Process Engine

Integration Engine

Central Adapter Engine

Adapter FrameworkMessagingQueuing

Security Handling

Optional Decentral Adapter Engine

Adapter FWMessagingQueuing

Security Handling

Resource

Adapter

Adapter FWMessagingQueuing

Security Handling

FileDB

JMS

FileDB

JMS

Resource

Adapter

Resource

Adapter

PCK Configurationand Monitoring

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSSAP SystemFile/DB/JMSSAP System

Content (e. g. Mapping, Adapter Metadata)

Partner ConnectivityKitJ2SE

Adapter Engine XI 2.0

Adapter

J2SEAdapter Engine XI 2.0

Adapter

Integration Repository / Integration Directory / System Landscape DirectoryIntegration Repository / Integration Directory / System Landscape Directory

Integration ServerIntegration Server

SAPSystem

SAPSystem

RFC

/IDoc

Adapter

Business Process Engine

Integration Engine

Central Adapter Engine

Adapter FrameworkMessagingQueuing

Security Handling

Optional Decentral Adapter Engine

Adapter FWMessagingQueuing

Security Handling

Resource

Adapter

Resource

Adapter

Adapter FWMessagingQueuing

Security Handling

FileDB

JMS

FileDB

JMS

Resource

Adapter

Resource

Adapter

PCK Configurationand Monitoring

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSMarketplace 3rd Party Sys.

File/DB/JMSSAP SystemFile/DB/JMSSAP System

Content (e. g. Mapping, Adapter Metadata)

Figure 8 Adapter Framework of XI3.0

Page 24: Business Process Integration

Business Process Integration 24

4.4 Integration Catalogue In the following sub-chapters, a catalogue describing how to integrate different business systems are discussed. Different integration scenarios are studied, including:

SAP-SAP (Integrate between SAP R/3 systems) SAP-mySAP Business Suite SAP- non SAP (SAP R/3 and Third-Party system integration) B2B integration (among business partners) XI and other EAI interoperability

In each scenario, possible means of integration using XI are analyzed and elaborated in detail, e.g. characteristics, performance, suitable application environments, advantages. As conclusion, comparison and recommendations are given. It should be noted that in each catalogue connectivities that apply to the catalogue are listed, but it does not mean that the listed connectivities are only limited this catalogue, as it may also be used in other catalogues and will be elaborated again there.

The details about configuration are not included in this part, but it can be found in documentation about XI. What is more, in the next chapter ‘Implementation Process Integration’, a practice prototype project is implemented and certain related configuration details are documented.

4.4.1 SAP-to-SAP integration

4.4.1.1 IDoc Adapter

The IDoc Adapter enables the exchange of IDoc messages with connected SAP applications via the RFC protocol. Within the Integration Server, IDocs are converted to XML messages or transferred as native IDocs, depending on whether or not the IDoc should be delivered to receiver(s) as is. IDoc adapters are built in on the integration engine, although to make use of IDoc adapters, there are some general configurations on the integration server side, users do not have to configure the IDoc adapters themselves for each individual scenario. The only configuration work to do is at the sender business side, i.e. to route IDocs to the integration server. IDoc adapter suites for asynchronous bi-directional communication between R/3 systems and Web application server as well, deliver Exactly Once in Order service. IDoc interface is native to SAP applications, and the benefit of adopting IDoc adapters are:

Easy to configure without breaking the existing business scenarios. When

there is existing business scenario for communication between SAP systems, it is quite simple to re-implement the scenario via XI. Only break up existing

Page 25: Business Process Integration

Business Process Integration 25

and working IDoc communication scenarios (ALE scenarios, for example) and reroute the corresponding IDoc traffic using the Integration Server.

Monitoring and tracing functionality of IDocs in R/3 system can be made use of to strengthen XI monitoring

Saves resources to redesign message interfaces. Since IDocs are built in business contents which can be loaded into XI, therefore unlike other message interfaces which users have to define and set up themselves in integration builder (with XI 3.0 it is also possible to load XSD definition as data types), IDocs can be imported directly from R/3 systems available in system landscape, and results in an express out-of-box scenario set up.

IDoc adapter enables exposing of IDoc data sent from R/3 systems available to additional receivers in the form of XML messages, using other outbound adapter, and additional mappings could be applied in order to adjust the IDoc format acceptable to receiver system

IDoc adapter also enables IDocs to be sent in batch mode. The IDoc adapter is capable of splitting IDocs sent in batch into individual IDocs and forward IDoc messages for integration server processing.

4.4.1.2 RFC Adapter

Remote Function Call is another communication method native to SAP applications. When receiving an RFC call from the business system, the RFC adapter transforms the RFC data into an XML message for further processing by the Integration Engine. To send message data to a receiving business system using the RFC interface, the RFC adapter accepts an XML message from the Integration Engine, transforms it into an RFC call, and executes the RFC call. Unlike IDoc adapters (both inbound and outbound adapter are on integration engine), outbound RFC adapter is located on the adapter engine, not in integration engine, i.e. the sender system who triggers RFC calls need to be registered in the RFC adapter configuration on the adapter engine. The inbound RFC adapter is located on the integration engine, it is not compulsory to register the receiving system in RFC adapter, since the receiver system can be determined by routing at runtime, but pre-allocated target system can also be configured in the RFC adapter (outbound) for better performance. For the monitoring of messages sent by RFC adapter, besides the XI monitoring tool on integration server, the outbound RFC adapter on integration engine has its log file, where people can monitoring the status and logs of the technical adapter itself. RFC adapter supports both synchronous and asynchronous communication between SAP R/3 systems and web application servers. In case of synchronous RFC communication Best Efforts service is delivered, while with asynchronous communication (bi-directional) Exactly Once service is guaranteed.

Page 26: Business Process Integration

Business Process Integration 26

The advantages or characteristic features of RFC adapter are:

Besides communication between R/3 systems, RFC adapter could also be used to integrate other mySAP components like mySAP CRM, SRM and Business Warehouse to R/3 applications.

RFC adapter is also applicable to communication between R/3 and web application servers.

4.4.1.3 Proxy Framework

Proxy Framework in SAP integration enables SAP applications to communicate via generated proxies. Proxy generation is new for SAP Web Application Servers, i.e. it is not available on SAP R/3 legacy systems. There is also Java proxy framework which enables XI to communication with Java or J2EE applications and this is discussed in another catalogue. SAP- non SAP integration. SAP systems based on SAP Web AS 6.20 are able to communicate using XML messages and HTTP. The systems use the proxy interface to connect to the Integration Engine. When receiving an XML message from the business system using a corresponding outbound proxy, the Integration Engine processes that XML message further. When receiving an XML message from the Integration Engine, the corresponding inbound proxy on the receiving component system accepts this message and calls the ABAP class that implements the corresponding inbound interface. ABAP Proxies are actually value-added ABAP programs which will be called to execute by the integration engine at runtime, in addition to the messaging functionality between integration engines, the proxies can do other value-added jobs like write information into the backend database table or updating etc. Proxies are recommended for synchronous and asynchronous communication between SAP applications based on Web AS 6.20 and above. It could also be used to connect the cross-platform XML interfaces manually created in the Integration Repository.

In line with outside-in approach. Considering the outside-in approach SAP

and other technology companies are adopting now, the integration of applications will be more and more based on open standards like Java, XML and even industry standards, e.g. RosettaNet instead of application dependent methods like IDoc or RFC. As more and more future SAP applications will be based on Web Application Server as well, therefore it is a future-oriented approach

Using open standards like HTTP and XML makes it easy to communicate with non-SAP systems, e.g. Java applications

Page 27: Business Process Integration

Business Process Integration 27

Proxies could be located at the inbound and outbound system, or both as well. While the other end of the communication could make use of IDoc or RFC adapters

Simplified programming interface. The proxy framework provides users with the proxy interface, which includes the outbound and/or inbound interface data structure. User only needs to program the implementation method based on the data structures provided. And since connection or communication details are handled by the proxy interfaces, users do not need to program for that, i.e. the programming work is simplified

Proxies provide more possibilities than pure messaging, as the ABAP proxies can handle other jobs in addition to communication between integration engines

Monitoring and tracing are possible at the monitoring tool of both the integration server and the integration engine on Web AS. Monitoring of integration server can tell the status of the whole message flow, while the monitoring of inbound integration engine can tell the message flow after the inbound message arrived, i.e. the execution of inbound proxy. Vice versa, the integration monitoring at outbound system tells the status of outbound proxy

4.4.1.4 HTTP between Integration Engines In case that either end of communication is based on Web AS, it is also possible to make use of the HTTP communication between integration engines. Since XI integration server is based on Web AS itself, and integration engine is available on Web AS 620 and above, therefore Web AS can send message to integration server via HTTP, and after the integration server gets message from the sending system, it can always talk to the receiving Web AS via HTTP as well. XI can also communicate with other HTTP applications via HTTP adapter, and this is discussed in later category. When the sender system is based on Web AS, it can use BAPI program or function and proxy to send message to integration server. When the receiver system is based on Web AS, the endpoint in integration builder configuration can be defined as integration engine by HTTP URL or HTTP RFC destination. In case RFC destination is set as the endpoint, inbound proxy will be triggered at the receiver side if available. In case HTTP URL is set as the endpoint, certain user implemented BSP can be referenced to, as a result like proxies, some functionality can be implemented here. HTTP connection between integration engines is also recommended like proxy framework, as more and more SAP applications will be based on Web AS, since it uses open standard HTTP. From XI point of view, this internal communication between integration engines is more secured and delivers guaranteed service, and from the user point of view, it is also easy to configure. It can be used in asynchronous and synchronous scenarios.

Page 28: Business Process Integration

Business Process Integration 28

4.4.1.5 Web Service Framework

With the new XI 3.0, there will be another possibility to connect Web Application Servers, i.e. point-to-point communication is also via web service framework. But that has the following prerequisites: Synchronous ABAP proxy with same outbound and inbound interface, i.e. no mapping or routing in between. That means, if no integration server service like mapping or routing is required, and then web application server can communicate directly via point to point web service framework without involving XI in between. But the communication can still make use of interface definitions in integration repository. The point to point short cut provides better efficiency as there is no middleware in between.

Figure 9 Point-to-Point Web Service Optimization

4.4.1.6 Conclusion Above discussion or SAP-to-SAP integration is summarized. SAP systems has the possibility to communicate with other systems via BAPI Functions or programs, ALE/IDoc or Proxy (WebAS 620 or above)

Page 29: Business Process Integration

Business Process Integration 29

SAP XI

SASAP SAP Func Func.

RFC

ALE ALE

IDo IDo

Prog. Prog. HTTP HTTP

ProxyProxy

Figure 10 SAP system connectivity methods

And the involving technology or protocol behind is RFC, IDoc, and HTTP (SOAP) correspondingly. In the scenarios that both ends of communication are SAP systems, XI has the following possibilities to connect to the SAP systems:

IDoc Adapter RFC Adapter Proxy Framework HTTP between Integration Engine Web Service Framework

According to the different scenario requirement, the integration mechanism can be classified as following:

IDoc RFC Proxy HTTP Web Service Platform Supported R/3 or WebAS R/3 or WebAS WebAS only WebAS only WebAS only

Asynchronous Yes. Yes. Yes. Yes. Yes.

Synchronous No. Yes. Yes and recommended Yes Yes and

recommended Bi-directional Yes. Yes. Yes. Yes. Yes.

Service of Delivery

Exactly Once and EOIO

Synchronous: BE Asynchronous: EO or EOIO?

Synchronous: BE Asynchronous: EO or EOIO

Synchronous: BE Asynchronous: EO or EOIO

Synchronous: BE Asynchronous: EO or EOIO

Usability/Configuration

Easy Configuration not breaking current scenario

Only outbound RFC adapter to be configured

Simplified programming, interfaces generated

Easy endpoint definition n.a.

Monitoring/Tracing

Additional IDoc monitoring in R/3 and XI

Integration engine monitoring, R/3, XI and

Integration engine monitoring, proxy log file

Integration engine monitoring

Integration engine monitoring, adapter engine

Page 30: Business Process Integration

Business Process Integration 30

adapter log

Open Standards Based No. SAP specific No. SAP specific

Yes. Open standards like HTTP and XML

Yes. Open standards HTTP

Yes. Open standards SOAP

Value-added No. No. Yes. Proxy class implementation method

Yes. Proxy method or BSP at URL

Yes. Mapping, routing and business process Mgmt.

Table 1 SAP Connectivity Analysis in XI

Following are recommendations for integrating SAP applications:

In case the SAP systems involved in integration are all R/3 systems, not Web AS, then IDoc and RFC adapter are recommended, as they are SAP native, delivers guaranteed service and speedy performance. In asynchronous scenarios both IDoc and RFC adapters can be applied, in synchronous case, only RFC adapter applies

In case either end of communication system is based on Web AS, proxy framework, web service framework and HTTP connection between integration engines can be applied. They are all open standards based and provides value-added services, and can be used to transfer SAP information to various formats and applications. Exactly which technology to choose depends on the scenario requirements, the inbound and outbound format requirement

Page 31: Business Process Integration

Business Process Integration 31

4.4.2 SAP – mySAP Business Suite Integration

4.4.2.1 SAP – mySAP CRM MySAP CRM can communicate with SAP R/3 and other legacy systems via its CRM Middleware component. What is more, it is also possible to integrate with other systems via XI. IDoc and RFC adapter can always be used in this context, since they are

native to both R/3 applications and CRM system. mySAP CRM4.0 is based on Web AS, therefore it can connect to XI

integration server via ABAP proxy, or directly via XML HTTP connection between the integration engine on mySAP CRM, from both inbound and outbound point of view

mySAP CRM has a XIF adapter, which provides SOAP interface. It was originally developed for message exchange between CRM and external non-SAP system. But the XIF adapter can be treated as web service client, and talk to the SOAP adapter of XI integration server, from both inbound and outbound point of view

in future SAP will provide out of ox connectivity between CRM and XI including pre-delivered integration knowledge, e.g. mappings

AdapterAP

Adapter

CRM 4.0SAP< WAS 620J2EEABAPABAP

ABAPApplication

ABAPApplication

JavaApplication

IDoc

XIFJava-Proxy

RuntimeIntegration

EngineAdapter

XML HTTP XML

HTTPSOAPRFC RFCIDoc

SOAPSO Exchange Infrastructure RFC RFC Adapter Adapter

Integration Builder IDocAdapter

IDocAdapter

RFC RFCIntegrationRepository

IntegrationDirectory

Adapter Adapter

Message Exchange & Mappinginternal XML based message representation

SLDSystem Landscape

DirectoryIS

Integration Server

Page 32: Business Process Integration

Business Process Integration 32

Figure 11 SAP- mySAP CRM connectivity

4.4.2.2 SAP – mySAP SRM SRM is the first mySAP solution making use of XI. It is used for component to component and supplier communication. Based on the business scenario XI (with Supplier Self Service) is mandatory, optional (upgrade customers) or not required. The new mapping functionality will only be available for XI.

Figure 12 SRM using XI

4.4.2.3 Master Data Management SAP Master Data Management (MDM) is one software component enables data management and integration between SAP applications. Details about MDM can be found under SAP help portal site: http://help.sap.com. Together with MDM, XI provides a non-intrusive approach to reference data management in a heterogeneous environment and enables comprehensive data harmonization across IT landscape. With MDM, the master data will be distributed using XI and MDM adapters. The receiving systems can be SAP R/3 or mySAP solutions, or non-SAP systems, as shown in following figure 11 Master Data Management and XI. MDM helps to define the business network environment based on generic and industry specific business elements and related attributes – called master data, e.g. business partner information, product masters, product structures, or technical asset information. MDM enables the sharing of harmonized master data, formerly trapped in multiple systems, and ensures cross system data consistency. It helps to align master data by providing services that recognize identical master data objects, and keep them consistent. In addition, it enables the federation of business processes, by providing consistent distribution mechanisms of master data objects into other systems, within the company, and across company boundaries.

Page 33: Business Process Integration

Business Process Integration 33

Figure 13 Master Data Management and XI

4.4.2.4 Conclusion Up to now, only limited mySAP component oriented at integration with XI, like CRM, SRM, SCM and MDM. In future there will be more and more components which can be integrated with XI according to the XI and NetWeaver positioning. Interesting integration mechanism would be the proxy framework and web service framework provided, since these technologies use open standards, making XI always able to talk to web application servers, that means communicate with applications based on web application server. For example, using the proxy framework available, XI can integrate with SAP Business Warehouse or cFolders, which bases on Web AS 6.20 or above. To conclude, not only XI but also the other mySAP components are going to be more and more Web AS based, providing an open environment. Consequently to integrate in such an open environment, open standard based technology will work. Proxy framework and web service framework are the open solutions of XI, therefore they are interesting for integrating with Web AS based mySAP applications.

Page 34: Business Process Integration

Business Process Integration 34

4.4.3 SAP – non SAP Integration In case of integrating SAP business system with non-SAP business systems, the method to integrate on the SAP business system side should always be IDoc, RFC or Proxy, while the method on non-SAP business system could be various depending on the concrete scenarios. The figure below shows all possible SAP – non SAP integration scenarios from connectivity perspective.

Figure 14 SAP – non SAP Connectivity Overview

All the adapters mentioned below are configured and maintained on the Adapter Engine. Adapter engine is a central java based application, it is automatically installed on the integration server of exchange infrastructure. Meanwhile, the adapter engine can also be installed on other hosts, e.g. where the non-SAP business system is located, giving that Java VM is available on the hosts, since the adapter engine is itself a J2SE standalone application. Therefore the adapter engine provides a flexible way to integrate non-SAP business systems. 4.4.3.1 File Adapter

Many third-party business systems provide file interface, file adapter could be used to connect these systems to XI integration server. A third-party (or legacy) system is connected to an Integration Engine using file adapter, which exchanges text files with the third-party system. When reading a file from the third-party file system, the file adapter transforms this file into an XML message for further processing by the integration engine. To send message data to a receiving third-party system, the file adapter accepts an XML message from the integration engine, transforms it into a text file and writes it to the third-party file system. File adapters could be used in asynchronous scenarios, bi-directional as well, support XML, text or binary format and deliver guaranteed Exactly Once service. From inbound system point of view, the file adapter could always serves as a backup measure. In order to confirm or investigate the data that has been communicated, file

Page 35: Business Process Integration

Business Process Integration 35

adapter could always be used as outbound adapter, and reload the transmitted data to a file, which could be saved for further usage. Easy configuration and installation is an advantage. As the file adapter provides a central point for configuration, and the adapter can be installed on any system with Java platform. And with the XI3.0 version, where the adapter engine is J2EE based, the adapter has a even wider application as it is a J2EE application and can be installed on any J2EE environment. To send a file to the integration server, only need to configure a inbound file adapter located on the integration server. To receive a file from the integration server, only to configure a outbound adapter on the receiving end. The file adapter gives user a various options to get around with the business scenarios. With the inbound file adapter, a polling interval is defined, and the adapter will check the file under certain directory at the defined interval, sending any new found file to the integration server. With the outbound file adapter, there is also the possibility to decide which actions take after the receiver gets the message from integration server. It can be archived, append contents to an existing file or write to a new file. Current file adapter can only handle flat and no segmented files. For text files, although the integration engine can only process files in UTF-8 codepage, the file adapter is able to convert any codepage into UTF-8 to be processed by the integration server, and can convert any codepage sent from integration server into any codepage to be recognized by the receiver. The 3.0 version can also handle flexible record types in the file.

4.4.3.2 Plain HTTP Adapter Many third-party systems can communicate via HTTP. Plain HTTP adapter can be used to connect such business systems to integration server of XI. Normally the plain HTTP adapter works with XML messages, i.e. internally integration server converts the received XML message to a SOAP format with header information, and send XML message via HTTP to the endpoint without SOAP envelop. If the format from sender or the required format of receiver is not in XML, some enhancement can be implemented by mapping. Plain HTTP adapter could be used in asynchronous and synchronous (bi-directional) communications supports Best Efforts of message delivery. Since HTTP is an open standard, plain HTTP adapter has a widely use, it makes it possible for XI to talk to any other HTTP server. Especially if the SAP system is based on Web AS, it can also be used to integrate SAP system, as mentioned above in Proxy Framework. The configuration of plain HTTP adapter is quite simple, i.e. direct end-point specification in routing. (With configuration in integration builder), as plain HTTP adapter is located in the integration engine of XI.

Page 36: Business Process Integration

Business Process Integration 36

The plain HTTP adapter supports HTTPS as well.

4.4.3.3 JDBC Adapter JDBC adapter is used to connect XI integration server to third-party systems on the database level, the adapter accesses database content using JDBC, so that the database content can be converted to XML message and vice versa. The adapter also converts the sent document into XML format for the processing of integration sever, and if the receiver system is using JDBC adapter, it will transform the XML document from integration server back to the acceptable database format. There is a specific XML format specified that allows SQL- INSERT, UPDATE, SELECT, DELETE or stored procedure statement to be processed, therefore the document sent to integration server should comply with the specific format. Any number of statements may be grouped together in one message, and the content of a message is always retrieved or stored inside one database transaction. JDBC adapter can be used in asynchronous scenarios, and it guarantees exactly once delivery of data. If it is used as inbound adapter, it will read the specified source database content at a regular interval as configured in the adapter settings. If it is used as outbound adapter, it could be used to insert data into several database tables at the same time, besides updates and deletes are also possible. The current version of JDBC adapter supports only SQL statements addressed to one table in the database for outbound processing, JDBC adapter is also located on the adapter engine, and can be easily installed on business systems. It is also available in the new XI3.0 version adapter framework, which is J2EE based and contains a central database for persisting message contents.

4.4.3.4 JMS Adapter There are many legacy systems connected by message systems like IBM MQSeries or SonicMQ, JMS adapter can be used to integrate these message systems with SAP XI, therefore integrate the legacy systems which are connected by the messaging systems. JMS adapter works by exchanging JMS messages with the messaging system. Like JDBC and other adapters, the message communicated between JMS adapter and XI integration server is assumed to be in XML format. In case the document sent from the source system is not in XML format, the format transformation could be implemented in Java mapping, the details are described below. JMS adapter supports bi-directional communication, delivers exactly once service for messages, it is also located on adapter engine. It can be widely used in integration SAP application with legacy systems which has already interfaces with JMS or message providers like MQSeries or Sonic MQ.

Page 37: Business Process Integration

Business Process Integration 37

Configuration of JMS adapter is quite simple as well, the adapter located on the adapter engine as well. Basically standard settings for JMS processing like FactoryImpClassname, host, channel and queue name are required to be configured in the adapter. Messaging systems send JMS message to the integration server via inbound JMS adapter, the URL of the integration engine is to be maintained in the inbound adapter. The integration server uses outbound JMS adapter to send JMS message to receiving messaging systems, the URL configured in the outbound adapter as the adapter address should be maintained in integration directory as well using XI Connectivity type. With the XI 3.0 version, there is also the possibility for the JMS adapter to talk to a message driven bean. That is to say, besides messaging systems, the JMS adapter can also communicate with J2EE application or web services which contains message driven bean.

4.4.3.5 Proxy Similar to the ABAP proxy used in SAP- SAP integration, Java proxy is used to integrate Java applications with XI integration server. XI can generate Java or J2EE proxies based on message interface in the integration repository. The proxy provides an encapsulated interface to talk to Java or J2EE applications. The interface includes the data type, message type defined in the message interface and depending on the message interface is inbound or outbound, synchronous or asynchronous, corresponding methods are included to send data to or receive data from the integration server. For J2EE proxies, the interface also includes the EJB bean and its home and remote interface to enable the communication between J2EE applications and the integration server. Java proxies can only be generated for outbound synchronous scenarios, while J2EE proxies can be generated for outbound and inbound, asynchronous or synchronous scenarios. For synchronous outbound Java proxy, users need to develop a java client, which make use of the proxy interface, to send request and receive response from the integration sever. For the same type J2EE proxy, besides the java client, some web component like JSP or Servlet may be necessary as well. The whole package includes EJB bean and web component should be deployed to a web application server, afterwards, the J2EE application can talk to the integration server. As shown below, the J2EE application deployed on J2EE engine will call the outbound bean, which calls the generated outbound proxy class, and then through the Java Proxy Runtime library and the messaging system to talk to XI integration server via HTTP.

Page 38: Business Process Integration

Business Process Integration 38

Figure 15 Working mechanism of outbound J2EE proxy

For the inbound asynchronous J2EE proxy, web component is not necessary, while the J2EE application only gets message from integration server, no input is necessary here. The integration server sends message to the proxy runtime, which will then call the corresponding user implemented J2EE application based on proxy interface already. Before that the J2EE application needs to be deployed on a web application server as well. The flow is shown below: Upon receiving messages, integration engine of the receiver system will call the messaging system via HTTP, which will call the Java proxy runtime and look into jpf.registry to identify which inbound bean should be called based on the inbound interface name, then the inbound bean is activated, and then call the corresponding proxy interface and then the user implemented application class.

Page 39: Business Process Integration

Business Process Integration 39

Figure 16 Working mechanism of inbound J2EE proxy

The proxy framework enables XI to talk to Java and J2EE applications, and the J2EE Application can be further exposed as web service. All these are based on open standards, it enriches a lot of the XI interoperability. Although currently the J2EE proxy does not seem to be working perfectly, considering the deploy tool of J2EE applications, and some additional installation is necessary for proxy runtime and its messaging system, it is seen to be a major trend in further which be elaborated and widely used.

4.4.3.6 SOAP Adapter Current version of XI has SOAP adapter to communicate with Web Service server or any other systems which uses SOAP to exchange messages, like the XIF adapter of mySAP CRM. Configuration of the SOAP adapter is quite easy as well, and the adapter is also located on the adapter engine. Inbound and outbound configurations are contained in one file, the address information like URL, business system name and interface name of targets are essential to the SOAP adapter. In XI3.0 version, SOAP adapter still exists, but the functionality is included in the Web Service Framework of Web Application Server, which takes more encryption and security perspectives into consideration for XI to communicate with Web Services.

Figure 17 Value-added Web Service

Page 40: Business Process Integration

Business Process Integration 40

XI can talk with Web AS and web service client via SOAP, and if integrated through XI and web service framework, the integration repository can manage the web service definition and content, mapping, routing and business process management functionality can be added to the basic web service, and non-web service based senders and receivers can be involved, i.e. managed and value-added web service is offered.

This mechanism can be widely used to synchronous scenarios. With the open web service framework, it provides not only the possibility of communication through web application server based R/3 applications, but also to any other non-SAP web service clients.

4.4.3.7 SMTP Adapter

In the XI3.0 version, there will be SMTP adapter for XI to talk to Email clients. As Email is a common type of business document, and in XI3.0 there will be business process automation and management functionality available, which will frequently involves email message type, SMTP adapter is surely necessary for communication with Email clients.

4.4.3.8 Java Mapping From the discussion above with the adapters and proxy framework, it can be found that the messages sent to XI integration server are supposed to be in XML format (besides IDoc and RFC), so that the integration server can proceed further, e.g. implement mapping and forward the XML format document to the receiver. But in the actual integration environment, there are scenarios that the sender or receiver business systems (third-party or legacy systems) does not provide XML interface, but rather provide text or character interface. In order to integrate this kind of systems, there must be the possibility to interpret the characters or byte steams and then convert them into XML format. XI made it possible by including user-implemented java classes in the JAR file, imported to XI using Java mapping. In the user-implemented java classes, users can implement the source format interpreting functionality, together with the implementation of TransformStream interface, which is required for Java mapping and realize the format or context mapping, the source document can be transformed to the target interface with XML format. Besides document format interpretation and mapping, more complicated implementation is also possible, depending on the real needs of integration. A scenario is implemented together with HP Contivo Analyst and SAP XI. Contivo Analyst is mapping repository with graphic mapping design tool. It can transform the mapping generated by its graphic tool into Java and XSLT files. But

Page 41: Business Process Integration

Business Process Integration 41

currently the Java mapping generated by Contivo is only specialized for WebMethods, and it becomes interesting whether this Java mapping can be adapted by XI. In the actual implementation, a main java class which based on the original java mapping from Contivo and implements the TransformStream interface as required by XI for all Java mappings, and the all Contivo runtime class are included in the JAR file imported to XI for Java mapping. And it proves that the mapping can be successfully executed by XI. In this scenario, the actual mapping code does not need to be re-implemented, but comes directly from Contivo, which uses classes and methods from Contivo runtime. On the other hand, as the java mapping can successful access and execute class and methods from Contivo runtime, the scenario proves that more complicated functionality can be implemented in java mapping simply by including user specific java class. To conclude, this feature can be well utilized to fulfill some special requirement in integration scenarios, and makes it possible to integrate with some other interfaces which can not be managed by adapters, that is why it is mentioned here in this context.

4.4.3.9 Conclusion The discussion above proved that there are many options for a third-party system to talk to SAP XI, exactly which one of them should be used, depending on what kind of interface the third-party system provides. An overview and characteristic summary of all the option is given below. All the adapters have in common that they are easy to configure, as the adapter engine provides a central place for configuration of the adapters, i.e. users only need to configure the adapter in one center point, and design the routing in integration directly then the settings are done. And the adapter engine has the advantage that it can be easily installed on any host with JDK1.3.1. Meanwhile, currently all the adapters have a configuration file, i.e. it is hard coded and can not be automatically adjusted during runtime, accordingly, this affects the flexibility. Almost all adapters and framework are using open standard like HTTP, JMS, XML, Java etc, provides an open platform and a variety to integrate with other application systems.

Page 42: Business Process Integration

Business Process Integration 42

4.4.4 B2B Integration To achieve new competitive advantages, companies are adopting collaborative business. Collaborative business enables users and heterogeneous systems to interact across organizational boundaries to achieve a common goal. To implement collaborative business, companies need to integrate their existing IT landscape and extend this integration to their partners.

4.4.4.1 Industry Standards Adapter Integration between business partners has requirements of velocity and agility as information is currency in business collaboration. There are different industry standards which enables communication between business partners in different industries, e.g. RosettaNet for HighTech industry and CIDX. eStandards for chemistry industry. These standards reduce barriers to capture the value of electronic business transactions and provide connectivity with key trading partners.

With implementation of these standards business partners do not need to worry about the difference between the backend and legacy systems, as all the business transactions between business partners are preceded through sending and receiving standard interface messages. And industry standard process definition transferred by the standard interface messages will be mapped to the specific interface of the legacy systems at the partner’s side. As shown in the graph below how XI works with RNIF adapter for supporting of RosettaNet.

Figure 18 XI works with RNIF adapter

Page 43: Business Process Integration

Business Process Integration 43

XI supports some industry standards mentioned above like RosettaNet and CIDX, in the new adapter framework of XI3.0, there are SAP industry adapters for RosettaNet (RNIF adapter) and CIDX. Using these adapters XI can to talk directly to application of business partners who is adopting the RosettaNet and CIDX standards.

Besides the industry standards adapter, XI supports the industry standards also in the way that it supports collaborated shared knowledge for these standards. Take RosettaNet as example again, besides the RNIF adapter at run time, in the integration repository, the RosettaNet PIP (see Appendix C for explanation) as business scenarios, application to PIP mappings as mappings, and RosettaNet business document schema as message interfaces can all be included as collaborated knowledge. At configuration time, RosettaNet business partner can be included as collaboration profile. That is the industry standards support within the whole design, configuration and run time phases.

SAP is also developing business packages based on RosettaNet and CIDX and powered by the NetWeaver besides the industry adapters to achieve application enhancement and better enabling of complicated business transactions and business process management.

4.4.4.2 Partner Connectivity Kit (PCK) Besides the industry standards for major industries mentioned above, XI3.0 also provides a partner connectivity kit for integration with other small and medium sized business partners. These business partners may not be using the industry standards like RosettaNet, instead, they have their own legacy systems and interfaces. The partner connectivity kit enables communication between XI and these legacy systems at business partner’s side.

The partner connectivity kit enables small companies to exchange XML document with their business partner’s XI system, and therefore set up a reliable data exchange with their partners. It can convert business documents received from business partner’s XI system for updating file, database, messaging or SAP system, and vice versa, convert business document from file, database, messaging or SAP system to XI messaging format to be handover to business partner’s XI system. It is J2EE based, and currently contains File, JDBC, JMS, SOAP and RFC adapter, how does the PCK work is shown below:

Figure 19 Partner Connectivity Kit work with smaller business partners

Page 44: Business Process Integration

Business Process Integration 44

4.4.4.3 Web Services and ebXML Another possibility to integrate business partner is through web services or making use of the ebXML (Electronic Business XML, see Appendix C for details) standards.

The web service framework of the Web AS of Netweaver04 enables web service clients to communicate with Web AS, and even the point to point shortcut between Web AS via web service, and XI3.0 provides value-added web services by managing web service definition and contents in integration repository and adding mapping, routing, and business process management functionality. And with the new NetWeaver Develop Studio, it is convenient for users to develop J2EE applications based on the J2EE proxies generated by XI, and the J2EE applications can be deployed and exposed as web services. The whole package facilitates the development of and communication via web services. As web services can be requested over internet, it would be an interesting method for integration between business partners in the future. The other emerging technology is the ebXML standard, it is a business protocol enables enterprises to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes. The current support of ebXML in XI is limited, but it is already well supported in other EAI solutions like BEA WebLogic Integration, which are introduced in more detail below. 4.4.4.4 Conclusion

Integration between business partners can be implemented through industry standard adapters, web services, ebXML standards, or through the partner connectivity kit of XI. Industry standard adapters or oriented for certain industries, e.g. RosettaNet for high-tech industry and CIDX for chemistry industry. While adopting these standards, all business transactions between partners are preceded though standard message types and interfaces. XI provides adapters to talk to these industry standard complied business partners, besides specific business package adds value to the communication by managing objects in integration repository, directory and business process management functionalities. Web services can also be used in integration of business partners as it can be requested via internet. The new web service framework provides value added web services by providing mapping, routing and business process management. ebXML is a new protocol enabling business transactions over internet, but current support of ebXML in XI is limited. The partner connectivity kit provides the functionality for smaller companies to communicate with the XI system of their larger business partners.

Page 45: Business Process Integration

Business Process Integration 45

4.4.5 XI and other EAI Interoperability In case there are already EAI products other than SAP XI in enterprise’s system landscape, there is the possibility to integrate SAP XI with these EAI products. Discussed as following:

Figure 20 XI and other EAI/ERP interoperability

Meta data exchange

Since XI is based on open standards like XML, it is easy to import and export collaborated knowledge in XI repository to other EAI products. Meta data, for example data types (in XSD or DTD), interfaces (in WSDL) or business processes (in BPML) can be exchanged as an option to interoperate with other EAI products. JMS adapter

JMS adapter can connect XI to all JMS enabled messaging systems or runtime server with native JMS capability. It provides secure asynchronous delivery, and guaranteed service of Exactly Once or Exactly Once in Order quality, and the message transfer can be bi-directional (from or to XI). SOAP adapter

SOAP adapter allows XI connectivity to other EAI products via SOAP protocol. It provides secure asynchronous and synchronous delivery, guaranteed service of Best Effort and Exactly Once quality, and the message transfer can be bi-directional. HTTP(S) adapter

HTTP(S) adapter allows XI connectivity to other EAI products via HTTP(S) protocol. It provides secure asynchronous and synchronous delivery, guaranteed service of Best Effort and Exactly Once quality, and the message transfer can be bi-directional. What is more, it allows possibility of sending HTML format payload via HTTP post instead of XML payload in SOAP envelope. The HTML format is enhanced correspondingly.

Page 46: Business Process Integration

Business Process Integration 46

Eco-Partner adapter There is also the possibility for XI to talk to other EAI products via some third-party adapters. For example, XI can use webMethods adapter to connect to PeopleSoft, JDE, Siebel and Oracle applications. And some third-party adapters can be utilized to connect industry standard compliance like iWay adapter for UCCNet, and SEEBURGER adapter for other industry specific standards.

Page 47: Business Process Integration

Business Process Integration 47

5 Implementation of Process Integration Based on summarized discussion above about integration methods with SAP XI, following is a concrete implementation example with XI. The project requirements are analyzed, implementation design with XI is proposed, general implementation procedure is summarized, and finally conclusion and analysis result is given.

5.1 Pricing Reference Server Scenario Description The SAP R/3 4.6c based Pricing Referencing Server (PRS) system needs to publish price information periodically via IDocs, and many subscribing system will subscribe to the published price information. The subscribers including internal system like eComat and resellers within the firewall, and in recent future, SAP Business Warehouse systems will also be included as subscribers, the total numbers of the subscribers can amount to 1000. Generally, a middleware is considered to handle the messages from the publisher and the subscribers can pick the messages up from the middleware. In general, the data flow of the PRS system can be shown as the following graph:

Subscriber (eCOMCAT)

Subscriber (…)

PERMANENT BW Subscriber (All Messages)

Subscriber (…)

Subscriber (Reseller)

WW “C er

Facing” Reference

S

ustomPRS Middleware

StandardizedPrice

Message (List / Net) SAP R/3

xRS System

Figure 21 PRS scenario data flow

The subscribers currently receive an extract file from the PRS on a daily basis. The objective of this prototype will be a proof of concept of a subscription service out of the PRS, and with the Reseller team to be able to send similar kind of information via this service in a more real-time basis to eventually replace their current feed. In the prototype the subscribers include a test internal subscriber and the Resellers, they all provide HTTP interface to be connected to the middleware, and the inbound message format of the subscribers is XML. But in future, the message format required by subscribers may be various including IDoc, flat file, EDI etc. .

Page 48: Business Process Integration

Business Process Integration 48

The published price information includes two types of IDocs: one is LIST price, which is a basis price, and the other is NET price, a price without taxes. Consequently two IDoc types are involved. PRS will publish these price information periodically once the price changes, and routing is required here for different types of messages to be sent to different subscribers, in between content based mapping or data transformation is also required as the message format and content required by the subscribers may be different from that the PRS published. The sequence of messages should be guaranteed, i.e. the message should arrive at the subscriber in the order they sent, to be more exactly in time order. The newer price information should not arrive at the subscriber earlier than older ones. Therefore exactly once in order delivery should be guaranteed. And the middleware should be able to hold the message when any subscribes are not available so that the subscribers can pick the message up when they are up again. Although the single message size may be small, the volume of messages is high, as a message is sent once the price information changes, and the number of subscribers is large. The PRS system should be flexible at adding or removing subscribers, and criteria can be defined by the way that which kind of message should be sent to which subscriber, i.e. routing rules.

5.2 PRS Scenario Requirement Analysis Understanding the scenario description above, a prototype is going to be implemented providing the basic connectivity but only involving test subscribers, but all the performance, throughput and availabilities factors should be considered. After analysis, the prototype scenario requirements can be given from following perspectives: Message Types and Formats: 1) PRS system should be able to send IDoc types for LIST and NET price

Two IDoc types are involved in the scenario: LIST and NET price. And there is a message code field in each IDoc type which determines its detailed message type, e.g. it could be price create or price change type etc. for LIST or NET price. This message code is important for subscribes as the same IDoc type with the same message code should arrive at its subscriber is time sequence

2) Inbound message type for middleware is IDoc or IDoc XML IDocs are collected at PRS system and published in a batch mode to middleware periodically, the middleware should be able to split IDocs sent in batch mode into individual IDocs and process them separately, and the IDocs with the same type should still arrive at subscribers in time sequence

3) Outbound message type from middleware is currently XML, in future flat file, IDoc and EDI are also required In prototype XML message is the format received by subscribers, but the middleware should be able to handle other outbound message types like flat file, IDoc and EDI for various subscriber systems

Message Transmission: 1) Publish/subscribe mechanism is required for the middleware

Page 49: Business Process Integration

Business Process Integration 49

The PRS system publishes price information via middleware, where the subscribers can subscribe to, i.e. pick message up from middleware. The subscription to price information is not required at runtime, but at the design and configuration time, i.e. subscription rules are set up at configuration or implementation period not at run time. In this scenario, only one publisher – the PRS system and multiple subscribers are involved.

2) Middleware should be able to handle large message volume (up to 1000 subscribers, 500 000 IDocs per day) with small message size (<10k) effectively with availability and performance Considering the price information changes rapidly and the number of subscribers are numerous, the middle should have the capability to handle large message volume as described. As price is quite critical information and has high demand for real time requirements, the middleware should have high availability for message transmission Because the message volume is high, the middleware should have multiple queues to handle inbound messages for high performance. And as the amount of subscribers is large, the middleware should avoid unnecessary replicating of messages and mapping operations.

3) Middleware should have message persistence, and the message retention period should be able to be defined by users. In case that any subscribers are temporally down, the middleware should hold the message so that the subscribers can pick up again once they are up again. Messages should be persisted for the number of days defined by detailed requirements, so the price information can be tracked when necessary or achieved.

4) Exactly Once In Order (EOIO) message delivery should be guaranteed The messages should be delivered exactly once in order. The price information is published in time order, the same order should be guaranteed at the subscribers side, i.e. old messages should not arrive at subscribers later than new ones. A message code in the published price information determines its message type, messages with the same IDoc type and message code should arrive at subscribes in time order, i.e. if EOIO is to be implemented through the middleware, then the EOIO queues in the middleware should be determined not only by IDoc type but also by the message code in IDoc.

5) Middleware should be able to handle content based mapping or data transformation Mapping is required as the different subscriber may require different acceptable message format, and some value mapping are also necessary.

6) Middleware should have content based routing functionality Middleware should provide content based routing as different message types go to different subscribers, and the middleware should allow users to define rules for routing, i.e. users can define subscription criteria that determines what kind of message that each subscriber subscribes to, and the criteria is always determined by contents of the messages.

7) Middleware should be flexible at adjusting subscribers, i.e. scalability required The middleware should be flexible at including new subscribers to or removing current subscribers from current scenarios. While adding and removing subscribers, routing rules and mappings could always be enabled.

Page 50: Business Process Integration

Business Process Integration 50

8) Middleware should have provide monitoring of messages The published messages should be monitored, in case that problems occurs, the middleware can trace and identify it.

9) Middleware use HTTP to connect to subscribers in prototype, but other connectivity is also required in future In the prototype only a test subscriber and a Reseller’s subscriber are involved, they both provide HTTP interface to be connected to the middleware. In real scenarios, there are much more and various types of subscribers, for example, SAP Business Warehouse system is necessary to be connected to middleware, therefore the design should also take other connectivity possibilities into consideration

The minimum message handling functionalities within the middleware should look like the following:

Figure 22 PRS Minimum message handling functionality requirement

OutboundQueue (s)

OutboundData

Transmission

rs

Subscriber Evaluation (C

riteria Verification)

Once Per Subscriber Various A

dapteMessage

Translation

Data

Mapping

Inbound Queue

Middleware

5.3 XI Solution Design After analysis of requirement, first of all, basically the scenario can be implemented via SAP XI according to understanding about XI, following are main reasons: Message Types and Formats:

XI provides various possibilities for application integration, and with the mentioned integration interface and message format IDoc, IDoc XML, flat file etc. XI all supports

Message Transmission

XI can provide store/forward mechanism as asynchronous scenario and publish/subscribe can be imitated but no self subscription; XI has content based routing, mapping and monitoring functionalities; XI also has persistence of messages; XI can guarantee EOIO message delivery; XI can talk via IDoc adapter to R/3 system, and HTTP adapter to HTTP interfaces, and also has other possibilities to connect to BW, file or other legacy systems.

Based on different types of subscribers systems, the following designs are proposed from connectivity point of view:

Page 51: Business Process Integration

Business Process Integration 51

5.3.1 IDoc – plain HTTP Adapter

Figure 23 PRS IDoc-plain HTTP Connectivity Design

XI Inbound Connectivity IDoc adapter.

Since PRS is SAP R/3 4.6c system, and it publishes price information in IDoc format, XI provides inbound IDoc adapter which accepts IDoc sent by R/3 system and converts it to IDoc XML format for further processing, e.g. mapping and routing.

XI Outbound Connectivity Plain HTTP adapter

Both subscriber involved in the scenario are based on HTTP sever and can accept XML messages via HTTP protocol. XI provides the plain HTTP adapter which can talk to business systems via HTTP, and send XML messages to the receivers. Therefore plain HTTP adapter is adopted here, the HTTP addresses of subscribers need to be defined as the endpoint of the adapter

Implementation in PRS In order to connect to XI, the integration server, some configuration is necessary in PRS Set up a R/3 type RFC destination to the integration server In the distribution model add IDoc types to be sent to integrations server Set up a tRFC port which directs to the RFC destination of integration server Set up a logical system partner type using the defined tRFC port, define IDoc types to

be sent to integration server in outbound parameter

Implementation in XI The scenario needs to be set up in XI, following are major steps: System Landscape Directory (SLD)

Page 52: Business Process Integration

Business Process Integration 52

- A product and software component need to be created in SLD, the software component belongs to the product, all further configurations are done within the software component

- Set up business system for PRS, test and Reseller subscriber. On all these business systems, the product created above should be installed

XI SAP GUI - define a R/3 RFC destination to the sender system - Set up a port for inbound IDocs from PRS using IDX1 transaction - Using IDX2 to check that the metadata of PRS system and its IDoc types are

available - Adjust number of queues when necessary for large message volume to meet the

requirements. 30 inbound queues are set up for all messages coming to integration server, and 5 outbound queues are set up for each subscriber independently. The queue settings are shown in Figure 24

Integration Repository - Update SLD cache - Import the software component created in SLD - Set up a new namespace - Import the IDoc structure to imported IDoc and RFC under software component - Define new interface type and create mappings when necessary. In the prototype

this is not involved as no content based mapping is required Integration Directory

- Set up two scenarios separately for each inbound message type: IDoc Z9PRILST and Z9PRINET, in each scenario

- In each scenario the inbound IDoc message type in SAP IDoc namespace is to be delivered to both the test and Reseller subscriber

- In each scenario define the outbound interface to be the same as IDoc message type name but in the namespace defined under software component in integration repository

- In each scenario define the endpoint using HTTP connectivity and specify the URL of the subscribers

- Add the XPath (XML Path, see details in Appendix C) criteria for condition to be route to Reseller

Integration directory settings are shown in Figure 25 below. Summary Using the IDoc-HTTP connectivity, the connection between PRS and subscribers can be successfully set up with the required IDoc inbound interface and outbound XML message type. Content based mapping and routing functionality is available with XI. Short term message persistence period can be configured in XI, and for long term message archiving is possible. EOIO message delivery is guarantee here, as the published messages are subscribed by both subscribers, and there is one EOIO queue set up for each receiver, therefore EOIO is guaranteed, but the message code is not considered here. The number of inbound and outbound queues can be adjusted to adapt to larger message volume

Page 53: Business Process Integration

Business Process Integration 53

Figure 24 Tuning setting for PRS queue management

Figure 25 PRS Integration Directory Settings

Page 54: Business Process Integration

Business Process Integration 54

5.3.2 IDoc – Proxy (J2EE or ABAP)

Figure 26 PRS IDoc – Proxy Design

As list in the requirement analysis, although currently there are only two subscribers and only HTTP interface is required to be connected to the middleware, there are going to be much more and various subscribers and interfaces. Considering the most frequently used interfaces and the inevitably involved subscribers, the above design with J2EE or ABAP proxy connectivity is given. XI Outbound Interface For connection with J2EE applications, XI provides J2EE proxies. In this scenario

inbound asynchronous J2EE proxy applies. As discussed in the previous chapters, XI can generate J2EE proxy interface and users need only to develop an implementation class with demanded business logic. After XI integration server gets the inbound message, it will call the implementation class via its Java Proxy Runtime. When the subscribers adopt J2EE proxy, besides the basic message transfer functionality, they can also proceed further based on the inbound message.

In case the subscribers are based on SAP Web Application Server or Business Warehouse, ABAP proxy applies. In this scenario inbound asynchronous ABAP proxy. ABAP proxy is recommended for connection with SAP Web AS, as it is a ABAP program triggered by the integration engine, easy to use and native to web application server. ABAP proxy is also recommended for connection with SAP BW, as BW is also web application based, and BW is usually the center point for data processing like extraction, transformation and loading. Using extractors BW pulls information from systems, ABAP proxy is used to set up the connection here, i.e. for BW to receive message from XI, and then move data to BW queues for processing.

Page 55: Business Process Integration

Business Process Integration 55

ABAP proxy connection to BW is also recommended by SAP itself, and it has already been applied to production scenarios.

XI Implementation The basic implementation is already described in the design above, following is some special configurations related with proxies. Integration Repository

- For J2EE proxy, it should be generated via a tool in integration repository. First of all, XI needs to create a message interface based on the XSD of the IDoc, the XSD can be imported as data type, and a message type and asynchronous inbound message interface can be created based on the data type, then the J2EE proxy can be generated based on the message interface, the java proxy generation UI is shown below

Figure 27 Java Proxy Generation

Page 56: Business Process Integration

Business Process Integration 56

- For ABAP proxy, still a message interface should be created based on IDoc XSD, but proxy generation and activation is to be done on the receiving Web AS, the proxy creation interface is shown in figure below:

Figure 28 ABAP Proxy Generation

Integration Directory - For J2EE proxy, the endpoint should be defined using XI connectivity,

and then specify the URL of the deployed J2EE application - For ABAP proxy, the endpoint is defined as integration engine, and using

a HTTP RFC destination defined in integration server for the receiving Web AS as the endpoint address

Implementation - For J2EE proxy, an application class need to be implemented based on the

generated proxy interface using Java, and the whole J2EE application need to be deployed on a J2EE engine

- For ABAP proxy, the same implementation using ABAP is necessary but via a certain transaction in Web AS (SPROXY)

Web AS Implementation For ABAP proxy, the receiving Web Application Server need to generate and

activate the inbound asynchronous proxy based on the inbound message interface using the transaction SPROXY

Page 57: Business Process Integration

Business Process Integration 57

A implementation class and method will be created automatically based on the proxy interface, and the users need to implement this method and then activate the proxy

Summary Considering scalability, J2EE and ABAP proxy should be frequently used connection to XI as they can involve J2EE application or Web AS based subscribers into the scenario J2EE proxy can be used to connect J2EE applications, and the new NetWeaver Develop Studio facilitates the development and deployment work of J2EE applications. ABAP proxy is recommended to connect to SAP Web AS and BW system, especially useful for connection with BW in providing data services

5.3.3 Web Services and Framework Besides the previous publish and subscribe design base on the requirement analysis, other out looking or future upgrading design is also considered, for example with the following request and reply design implemented with web services via XI. It is assumed here that PRS will be upgrade to Web AS 620 or above, not current R/3 4.6c.

Figure 29 PRS design with web service request and reply

XI Inbound Interface Web Service and SOAP Adapter

Web Service Client can talk directly to XI using the SOAP adapter. The clients request price information via web service to XI, which will then forward the request to PRS system through it outbound interface. The advantage of adopting web services via XI lie in that XI provides managed web service with routing, mapping and business process management functionality. And XI provide more connectivity possibilities, i.e. the request come to XI via SOAP, but XI can reply to the clients via other interface like file or database.

XI Outbound Interface Synchronous ABAP Proxy or SOAP

Page 58: Business Process Integration

Business Process Integration 58

As PRS is considered to be web application server based, synchronous ABAP proxy can be applied here to forward the web service request to PRS, and trigger ABAP proxy, after execution of the proxy, the requested price information is returned to XI. XI can also use SOAP to talk to PRS, as both XI and PRS are Web AS based, and the web service framework of web application server enables direct SOAP communication between them. SOAP or File, JDBC Adapter

With the request and reply mode, it is now a synchronous scenario, and XI should send reply from PRS back to the service request client. XI can use SOAP adapter here again to forward the reply to the web service client, in addition, it can also adopt other interface like file or database to send the price information it gets from PRS back to the request client.

Summary Once the PRS system is upgraded to Web Application Server 620 or above, more integration possibilities are included. E.g. when the subscriber is a web service client, it can send web service request to XI via SOAP, and the web service framework or proxy framework on the receiving integration engine can proceed the request and send reply to the client via XI again. When the subscriber and PRS are both based on Web AS 640 or above, the web service framework also enable direct communication between them without XI involved, i.e. the point to point web service shortcut described in previously. 5.3.4 General Publish / Subscribe Design via XI Considering all the XI connectivity and possible subscriber types, following publish / Subscribe design can be given involving current and potential subscriber connectivity.

Figure 30 PRS general Publish / Subscribe design via XI

Summary

Page 59: Business Process Integration

Business Process Integration 59

Besides the connectivity described in previous design, consider other subscribe type, XI can also be used to connect following subscriber types: Via IDoc adapter to SAP R/3 or WAS based subscribers in IDoc format Via File, JDBC or JMS adapter to other legacy systems Via Eco-partner adapters like iWay or WebMethods to other ERP systems like

Oracle or PeopleSoft Via HTTP adapter to Enterprise Service Bus, which connects many other business

systems in enterprise Via HTTP adapter to B2B Gateways, which connects to external business partners

All the connectivity in this graph are already possible with XI2.0 version, and the coming XI3.0 version is more mature and provide more connectivities including: Web Service Framework in design 4.3.2 Partner Connectivity Kit to business partners Adapter Development Kit for self developed adapters

5.3.5 Long-term Scenario Design Proposal Above are all proposals about current applicable design, nevertheless there are still more sophisticated and long term oriented proposals as below: Self-Service subscription or Business Process Management

The subscribers can subscribe to the price information in a self-service mode. E.g. if the subscribers adopt industry standard RosettaNet to subscribe to price information and define certain PIP for subscription process, then when any subscriber need any price information, no matter is price creation or change, it will subscribe automatically to PRS system via sending standard RosettaNet messages, and PRS will the feed the information back to subscriber also in standard RosettaNet messages. When the subscriber gets the information and currently no need for further price information, it can unsubscribe automatically and re-subscribe again when necessary. The other Self – Service subscription possibility is through business process management. On the subscriber side, a process definition for subscribing to PRS for price information is defined and published, whenever the subscriber process run to the point that it needs price information from PRS, it will send request to PRS and then get reply, or directly pick the message up in a certain channel pre-defined for PRS connection, and then proceed further with the price information it gets. Master Data Management

The other standard way to handle this kind large data service like PRS would be through SAP Master Data Management (MDM), as the data publisher PRS is SAP R/3 based, and as in the discussion of previous chapter, XI together with MDM integration can provide a integral solution for managing data in SAP R/3 as well as other mySAP components like CRM, SRM etc. Therefore XI and MDM integration can be considered as long term solution for handling price information to be exchanged among PRS and its subscribers. Summary

Page 60: Business Process Integration

Business Process Integration 60

The proposals in this section are all long-term oriented, and basically they can already be implemented on current software version like XI 3.0 or MDM, but can lead to amount of work as the whole architecture need to be changed. Still, from long term point of view, Self-Service, Business Process Management and MDM are going to bring a new wave for application integration and data management service, and further investigation would be interesting.

5.4 Gap Analysis Although XI meets most requirements of the PRS scenario, after detailed analysis, still there are some gaps between what XI offers and what PRS requires, details is discussed below: 5.4.1 Message Referencing As described in requirement analysis 2) message transmission, the PRS scenario demands large message volume (500 000 IDocs per day) with large number of subscribers (up to 1000), therefore in this case unnecessary replication of messages should be avoided. Since the message published from PRS is same for all its subscribers, but almost 1000 subscribers will subscribe to the same published message, the ideal way would be that the middle provides a referencing to the published message, so each subscribe could just pick the right message up themselves from the queue of the middleware, and once all the subscribers have picked up the message, then the source message is processed completely. What XI currently does is after getting a message from the publisher, it performs message splitting, during the time it copies the message payload for each subscriber and send the message to the outbound queue of each subscriber. This results in unnecessary replication of messages, since the same message will be copied as many times as the number of subscribers, when the number of subscribers amount to 1000 in PRS scenario, this mechanism will result in massive message replications and inevitably affect the performance. The proposal to solve this problem has to change the message handling design of XI. It has to introducing the message referencing mechanism instead of message copy for each subscriber, for example a subscribers list can be created for all the subscribers subscribed to same message, and the same mapping is performed. So every subscriber in this list will pick the message up themselves from the XI queue according the message reference, and until all the subscribers have got the message, the original message has been processed successfully. 5.4.2 Same Mapping List The same problem occurs at mapping. As PRS demands large number of subscribers, the same mapping maybe required by many subscribers while others require for other mapping. What XI currently does is that after integration server receives inbound message, it performs message splitting according to routing rules, and it copies message payload during message splitting to the outbound queue of each subscriber, and then

Page 61: Business Process Integration

Business Process Integration 61

mapping is performed at the outbound queue of each subscriber. That is to say, mapping operation will be performed as many times as the number of subscribers even if the mapping operations may be same for many subscribers, unnecessary wasting of processing resources occurs again here. What XI can currently do to avoid this is to adjust the sequence of mapping and routing. As normally it performs routing first, i.e. message splitting and then mapping at each outbound queue. It can be adjusted that mapping is performed first and then routing, this is troublesome as it may not be that all subscribers require same mapping operation but rather different, therefore there should be coordination in between. So the proposal to improve is to create a same mapping list, for the subscribers that demand same mapping operating and same routing condition. This has to be considered together with the previous gap and to give a more reasonable design. The proposal is shown in the graph below:

Figure 31 PRS Message referencing and mapping design proposal for XI

With this design, mapping is performed according to the same mapping list, so that one mapping operation applied to multiple subscribers will only be executed exactly once; Different message copies are generated after different mapping operation and routing is then performed according to the subscriber list, the message copies after mapping are then referenced but no more copied for each subscriber in the same subscriber list; Multiple subscribers in the same subscriber list pick message up in XI queue according to the reference ID, when all the subscribers get the message, the original message is successfully processed

5.4.3 Exactly Once in Order Message Delivery The other gap between XI design and PRS requirement is Exactly Once in Order (EOIO) message delivery. Although XI can guarantee EOIO message delivery, but the PRS requirement is more detailed. Currently XI has only one EOIO queue for each sender-receiver channel, and the EOIO queue can be defined according to IDoc type, e.g. different IDoc types published by PRS can go to different EOIO queue, it is not necessary for IDocs with different type to be kept in sequential order, but IDocs with the same type

Page 62: Business Process Integration

Business Process Integration 62

should be kept in order. But PRS requires more detailed as described in requirement analysis. There is one message code field in each of the IDoc type, which identifies the exact type of each message, for PRS it is required that the messages with the same IDoc type and the same message code should be delivered in time order. That is, the EOIO queue should be set up according to the combination of the IDoc type and the message code field content in IDoc. EOIO according to IDoc type together with message code within the IDoc is currently not possible with XI, since at the queue definition time, only the IDoc type can be specified to differentiate queues, the content within the IDoc can not be read and specified for differentiation. The possible proposals could be: Implement EOIO on application level

EOIO is not necessarily to be guaranteed only through middleware, but it can also be guaranteed on application level. For example, a time stamp can be included at the IDoc creation time in PRS, so every IDoc has a timestamp indicating its creation time, middleware delivers message exactly once, and at the subscriber side, after get the message, it should check the timestamp first together with the message code, if it get a message with a older time stamp than previous messages with the same message code, it will just discard the message. In this way real EOIO can be guaranteed, as when the subscribe judges at timestamp, it can be sure to keep message in sequential order. While if implemented on middleware level, even if the middleware guarantees EOIO delivery, it can not be guaranteed that the IDocs are published exactly in order, i.e. IDocs are sent exactly in the order that they are created. So the timestamp solution has the advantage that it can secure EOIO, but the disadvantage is that the subscribers have to check the timestamp each time they get the message, and this put more workload to subscribers.

Implement EOIO on middleware level

If EOIO is still to be implemented within XI, then XI needs some enhancement on its current queuing system: Allow more EOIO queue between one Sender/Receiver channel based on message interface. This gives the possibility to set up multiple EOIO queues according to the transferred IDoc type; Not only the message interface, but also the content based EOIO queue should be possible. Something like XPath is necessary here so that the message code within the IDoc message can be specified for EOIO queue differentiation or division 5.4.4 Queue Management For exactly once in order scenario in XI, the number of inbound queues can be adjusted, but they are used by all integration scenarios, although the outbound queues can be differentiated according to receivers. There is no exclusive queue set for each individual integration scenario. Time critical low volume scenarios may be impacted by high volume scenarios. XI30 will provide priority queues, but it is still not possible to set up exclusive queues for each individual integration scenario.

Page 63: Business Process Integration

Business Process Integration 63

5.5 PRS Scenario Summary The following table summarizes how XI meets the PRS scenario requirements.

PRS Requirements Does XI Meet Requirements XI Support Feature

Functionality

Message type IDoc and XML IDoc Yes IDoc adapter accept IDocs and transform to IDoc XML for processing

SAP Connectivity Yes IDoc adapter to connect to SAP R/3

HTTP Outbound Yes HTTP adapter, support HTTP1.0

Content based Routing and Mapping Yes

Integration server performs content based routing and mapping, routing rules can be defined, mappings can

be designed or imported

Message Persistence Yes

XI allows user to define message retention period for short term, and messages can be archived for long

term

Publish/Subscribe not real Publish/Subscribe

XI behaves rather like store/forward than publish/subscribe, but in this scenario no runtime subscription

required, therefore XI can implement publish and subscribe like scenario by configuration and define subscription

rules

Exactly Once in Order delivery only one EOIO per subscriber

there is only one EOIO queue for each receiver system in XI, it is not possible to determine EOIO queue

according to IDoc type and message code within IDoc

Supportability

Large Volume Message Handling replicating messages

Currently XI copies message payload rather than referencing for each

subscriber and results in message replicating

Monitoring Yes XI provides integration engine

monitoring, and messages can be viewed in monitoring

Tuning Yes

XI can adjust the number of inbound and outbound queues to adapt to

large volume message. But inbound queues are shared by all integration scenarios. Outbound queues can be

adjusted for each subscriber

Scalability Yes XI can easily add or remove

subscribers by configuration in integration directory

Page 64: Business Process Integration

Business Process Integration 64

Table 2 PRS Scenario Requirement Analysis

After investigation with PRS scenario, the following conclusion about XI as middleware in application integration can be drawn as below: XI meets most requirements of PRS scenario, especially considering its connectivity possibilities and integration with SAP R/3 or other SAP components. As a middleware for application integration, XI has the advantage in its various connectivity with SAP R/3, mySAP components and third party systems. Either technical adapter for third party system, or IDoc, RFC for R/3 systems, Web Service Framework and Proxy Framework for Web Application Server or J2EE applications, or industry standard adapters for business partners, XI all provides connectivity. XI has another advantage as the IDoc adapter can proceed IDocs sent in a batch mode, without putting all IDocs into one big message, it can proceed IDocs sent in batch individually. XI is still not mature with its 2.0 version for production scenarios. Considering the large amount of subscriber requirements of PRS, XI does not fit well as it copies message for each subscriber instead of referencing and impacts its performance, so improvement is still to be made to adapt itself better to production scenarios. The coming XI 3.0 version provides more important functionality like business process management and JCA based adapter framework, and also improvements in availability and performance perspectives, e.g. message lifecycle handling and queuing, use Change Management Service for managing change and transport. It is considered to meet the business needs better and more mature for production scenarios. In general XI is worthwhile to be considered as the Enterprise Service Bus which interconnects other legacy systems within the enterprise and the B2B gateway to business partners, giving the various connectivity it provides. Especially in enterprise that SAP systems play an important role, as XI is always the first recommendation for integration with SAP R/3 or other SAP components.

Page 65: Business Process Integration

Business Process Integration 65

6 Integration with BEA WebLogic Integration In this chapter, BEA WebLogic Integration 8.1 is studied, and how BEA WLI can be used for business process integration is discussed, then a comparison between SAP XI and BEA WLI is given. As this thesis work is cooperated with Hewlett-Packard GmbH, and SAP XI and BEA WebLogic Integration are the two major process integration platforms that are promoted within HP, therefore they are studied and compared here.

6.1 Introduction of BEA WLI BEA WebLogic Integration 8.1 is a new unified solution to integrating business systems within an enterprise. WebLogic Integration provides a development and run-time framework that unifies all the components of business integration including business process management, data transformation, trading partner integration, connectivity, message brokering, application monitoring, and user interaction into a single flexible environment. WebLogic Integration combines the divergent pieces of the business integration picture, including ERP, CRM, legacy applications, business users, supply chains, and trading partners, by providing a versatile development environment for delivering rapid business integration with simplified production and management. WebLogic Integration is the integration component of the WebLogic Platform that provides functionality for businesses to use to develop new applications, integrate them with existing systems, streamline business processes, and extend e-business infrastructure through portal gateways. The whole picture of WebLogic Platform is shown below:

Figure 32 BEA WebLogic Platform

BEA WebLogic Server is a J2EE application server provides the critical infrastructure needed to develop integrated solutions, including security, transaction management, fault

Page 66: Business Process Integration

Business Process Integration 66

tolerance, persistence, and clustering. WebLogic Portal integrates user interaction into the whole integration picture. Leveraging WebLogic Server as the underlying deployment environment, WebLogic Integration uses Web services to integrate distributed systems inside and outside an organization and utilizes the BEA WebLogic Workshop framework to simplify application development. WebLogic Workshop is the integrated development environment, provides graphical tools to edit business processes, controls, Web services, and portal-building tools in the same application environment. As shown in Figure 32 below, Application panel shows the application structure and components it contains, Process Nodes are nodes that can be included into process modeling and design, Design and Source view are used for process design as well, Control panel shows available controls that can be used in process design, and the Data Palette shows prosperities of controls or nodes in the process flowchart.

Figure 33 BEA WebLogic Workshop

From WebLogic Workshop, the WebLogic Administration Console and WLI Administration Console can be accessed. WebLogic Administration Console allows centralized configuration, maintenance, and monitoring of integrated resources, including

Page 67: Business Process Integration

Business Process Integration 67

audit trails as well as associated security and role information, extensible with JMX interfaces to third-party tools. The WebLogic Integration Administration Console is designed for the applications administrator, who needs an integration-focused view of business processes, messaging activity, and monitoring of deployed applications.

6.2 WLI Integration Conception and Methods WebLogic Integration introduces several concepts or feature for implementing business process integration. They are discussed in the following subchapters. 6.2.1 Business Process Management With WebLogic Integration BPM, users can model and execute business processes that span multiple internal systems, external resources, and users. From the BPM perspective, the enterprise is a set of business services that are accessed through Controls and can be orchestrated to model a business process. WebLogic Integration supports synchronous and asynchronous communications, and stateless and stateful processes. The business process designed in WebLogic Workshop in Design View generates automatically a business process definition file in source view called JPD file, users who want to write the Java code can go directly to the Source View and modify code there. Details about business process management will be discussed in next chapter, but with WLI 8.1 business process management is already available, and the workshop provides a powerful environment to model and design business process. Process integration is always accompanied by process design and management in WLI. 6.2.2 Message Broker WebLogic Integration implements a Message Broker that provides business processes with a channels-based publish and subscribe communication mechanism. This enables business processes to communicate in a loosely-coupled, anonymous manner using a business-naming paradigm. For example, a Purchase Order routing process can subscribe to the New Order Entered channel and as each new order message is published to that channel, the process is activated. Each business process can specify the channels to which it publishes and subscribes. Publishers can broadcast messages without knowing who is going to receive these messages. The consumers of these messages can be any one of a couple of different types of listeners. Consumers, such as business processes and other back end resources, can subscribe to Message Broker channels. When a process needs to subscribe or publish to a certain channel, it only needs to add an instance of Message broker control into its process flow, and specify the channel that it subscribes to or publish to in the control. In this way, the Message Broker facilitates a loosely coupled interface. At run time, new publishers and new subscribers can be added. A Publish/Subscribe scenario, PRS is already implemented in the previous chapter via SAP XI, the same mechanism is adopted by the Message Broker here, but a named Message Broker Channel is set up in WLI, and the subscribers only need to subscribe to the channel to pick up the messages.

Page 68: Business Process Integration

Business Process Integration 68

Message Brokers are usually created by instantiating message broker control in WL Workshop, and then it can be maintained in WebLogic Integration Administration Console, where users can configure, and monitoring details of message brokers. If a message broker publishes messages to a new channel, then the channel has to be defined manually with a channel definition file, there is a standard XML format for defining channel file. The Message Broker supports Event Generators that can publish events from external sources to Message Broker channels. WebLogic Integration supports File, JMS, Email, and Timer Event Generators, i.e. Event generators publish messages to Message Broker channels in response to system events (for example, files arriving in a directory, or messages arriving in an email account or JMS queue).WebLogic Integration adapters, hosted in the Application Integration framework, publish events from packaged applications to channels. Event generators can be created from the WebLogic Integration Administration Console with the following types: File type for polling files from file system (directory or ftp server) and publish to message broker channel, Email type for polling messages in email account and publish, JMS type for polling messages in JMS queue and publish, and Timer event generator to create event at user defined time and publish the event to message broker channel. Once created, the event generator is packaged and deployed as an EJB, and it can be suspended, resumed or added additional channel rules under user request. Along with the Event Generator, Message Broker and Channel can be used to implement event driven publish and subscribe communication. 6.2.3 WebLogic Integration Controls The WebLogic Workshop framework provides a consistent mechanism for interacting with resources across all Workshop, Integration, and Portal components. WebLogic Integration is a highly object oriented tool using encapsulation, everything designed in WebLogic Workshop can be published as a control, and be used by other processes, this means a control definition JCX file is generated after a control is created and implemented with certain methods or property, this control object can later be instantiated by adding a new control into the process chart. And it has also many out of the box controls enables integration with a portfolio of resources like file, database and JMS controls etc, the users also have the option to add any of these integration controls directly to the process flow and then customize or configure them. These Controls are server-side components managed by the Workshop framework. They encapsulate external resources and business logic for use in Workshop applications. In other words, controls represent the interfaces between business process and other resources. The underlying control implementation takes care of most of the details of the interaction. Controls expose Java interfaces that may be invoked directly from business process by adding an instance of a control to project and then invoking its methods.

Page 69: Business Process Integration

Business Process Integration 69

All these controls can be customized and then included to the process flow, for the process to interact external resources like files, database, messaging systems etc. When a process need to access external resource, a corresponding instance of a certain control needs to be added as a node of process, according to the interface to access the resource, and the this control instance needs to be configured for accessing. The next figure gives an example how integration controls can be used by business processes.

Figure 34 an example control implementation in WLI

The figure shows a database control CorpAcctgProcessingImpl, which defines some operation on certain database. It implements two methods: processOdDoc and processPoDoc, the methods define exactly what kind of operations to be performed on database. The methods of the control CorpAcctgProcessingImpl could also make use of other controls and their methods, e.g. corpAcctgPoItemsDB, corpAcctgPoDeliveryDB and their methods are used here. The figure below then shows how this database control is used by a business process. An instance of the control CorpAcctgProcessingImpl is added with the name corpAcctgProcessing. And the business process CorpAccgProcessingPD make use of the two methods of the control corpAcctgProcessing: processPoDoc and processOdDoc respectively. The methods are inserted into the business process as two nodes, users can then configure the send and receive parameters for the two nodes.

Page 70: Business Process Integration

Business Process Integration 70

Figure 35 A business process utilizing integration controls

Following are descriptions about most commonly used controls and how they can be used to access external resources: File Control

File control is used for a business process to read, write or append to a file in a file system. The file can be in Xml, RawData (binary) or String format. File event generator publishes unsolicited file event to message broker channel. Like file adapter in XI, file control and event generator can integrate business process with external file systems, file event generator can be used as inbound adapter to publish file to a business process, and file control can be used as either inbound or outbound adapter to read files or write a file in file system. Database Control

Database control enables business process to read or write database contents via SQL Statements. The controls use JDBC for accessing database, but users need to do is to define connectivity parameters for accessing database, implement a method to execute SQL statements against database. Any SQL statements for retrieving data, insert, update or deletes can be implemented.

Page 71: Business Process Integration

Business Process Integration 71

Database controls belongs to WLI built-in Java controls. WLI also provides RDBMS adapter for more complicated database operations like structure change, but the adapter is included in an independent adapter set. JMS Control

JMS Control enables business process to interact with messaging systems that provide a JMS implementation. A specific JMS control is associated with particular facilities of the messaging system. There are two types of JMS control available in WL Workshop, built in JMS control and WLI JMS control under integration control directory, WLI JMS control is an extension of the JMS control, providing additional features such as RawData message type support, dynamic property configuration, and the ability to control whether to start a new transaction or remain within the calling transaction. The following scenarios are supported by WLI JMS control: send message to a queue, and synchronous messaging with queues, i.e. a business process can send messages to a queue and receive reply message on another queue. It does not support the scenario to receive message from a queue only, but this can be implemented through JMS Event Generator, which polls for and consume messages produced by the WLI JMS control. Email Control

Email control enables business process to send email to a specific destination, while with the email event generator, emails can be received. Message Broker Control

As discussed in previous subchapter, message broker controls can be added to the process flow for publish or subscribe to message broker channel, together with message filtering capability. MB Publish and Subscribe control are used for publish and subscribe purpose correspondingly. EJB Control

Once an EJB control is created, a web service or page flow can use the control to access the EJB's business methods directly. It relieves the preparing work for accessing EJB capabilities like look up in JNDI, obtain home interface and EJB instance, and then revokes the method of its remote interface, the EJB control manages all these work. In short, EJB controls provide an alternative approach that makes it easy to use an existing, developed and deployed EJB from within an application. Before an EJB control is created, a certain EJB instance should exist already, i.e. the EJB's local or remote interfaces must be known in the application. If the EJB is not part of the application, it can be made available by adding the EJB's JAR file to WebLogic Workshop application. The only classes actually required are the EJB's home and remote interface classes and any other classes used externally by the EJB. EJB control supports interaction with session beans and entity beans, it does not support direct communication with message-driven EJBs.

Page 72: Business Process Integration

Business Process Integration 72

Process Control The Process control is used to send requests to and receive callbacks from another business process using Java RMI. The Process control is typically used to call a subprocess from a parent process. Any process can be packaged and be reused by another process as a instance of process control. Web Service Control

Like EJBs, Web Services can also be used as a control in WLI, and web service control is also a built-in Java control which can be used in business process, and a business process can be published as a web service control as well, detailed description follows. ebXML & RosettaNet Control

ebXML and RosettaNet Control enable business process to exchange business messages with business partners via ebXML or RosettaNet standards correspondingly. Details about business partner integration or B2B integration follows below. Trading Partner Management Control

Used in business partner integration. The TPM control provides business processes and Web services with query (read-only) access to trading partner and service information stored in the TPM repository. Details are discussed in B2B partner integration below. Data Transformation Control

Besides EJB, process and web services, Data Transformation can also be packaged as an object after created for reuse in across multiple business processes and applications. Details about data transformation follow below. With such a portfolio of integration controls, WebLogic Integration provides business process versatile interfaces to interact with external resources, EJB or Web Services and other business process within the same application. And all the implemented control can be packaged to be reused by other business processes. 6.2.4 Web Services as Control WebLogic Integration leverages Web services, asynchronous communication, and XML messaging at the platform level. At this level, these services can be used across internal and external integrations, giving application developers the tools to simplify development and integration of loosely coupled and asynchronous applications. WebLogic Integration features native support for Web services including Web service security and reliable messaging. Web services can be invoked from within a WebLogic Integration business process by add a web service control instance and business processes can be exposed as a Web Service and made available as resources to other applications and application components.

Page 73: Business Process Integration

Business Process Integration 73

6.2.5 Data Transformation Data transformation provides actually mapping functionality enables translating between XML, non-XML, and Java data, it allows integration of heterogeneous applications regardless of the format used to represent data. In WebLogic Workshop business processes, XML data can be transformed using either XQuery expressions or XSLT. While WebLogic Integration provides functionality for executing existing XSLTs in business processes, it also offers a new and easier path to data transformation through XQuery, a standards-based query language with the familiar simplicity of SQL-like expressions and a easy-to-use data mapping tool. WebLogic Integration features a visual data mapping tool, the XQuery Transformation Mapper, which provides the functionality to generate complex transformations easily with a drag-and-drop simplicity. 6.2.6 Application View and Adapter WebLogic Integration uses application view together adapter for application integration. An adapter in WLI is a software component that acts as a connector between an EIS and a J2EE application server (such as BEA WebLogic Server). Each adapter provides bi-directional, request-response integration with a specific application or technology. Adapters are JCA cased. Application integration uses adapters and associated application views to integrate applications in enterprise. Once an adapter is deployed for an EIS, other components and applications can use that adapter to access data on the EIS. An application view is a business oriented interface to objects and operations within an EIS, it include the information needed to communicate with the EIS as well as configurations for services and events. It includes communication configuration with EIS including connection settings, login and so on, service invocation including the information that the EIS requires for the request, and the service request and response schemas associated with the service, as well as event notification including the information that the EIS publishes and the event schema that EIS requires for inbound messages. Application view act as an abstraction layer between the adapter and the EIS functions that exposed by the adapter. Usually an application view is only configured for a single business process in EIS, therefore an EIS can have several application views associated to it according different business purpose. After an adapter is created, application views can be defined using WebLogic Integration Administration Console to associate with the adapter and to describe certain service or events that provided by the adapter connected EIS. After an application view is created, it can be instantiated by adding an Application View Control into the business process flow. Details about how to make use of application view and adapter to integrate applications are discussed below.

Page 74: Business Process Integration

Business Process Integration 74

6.2.7 Worklist WebLogic Integration integrates with business users through the Worklist system. The Worklist system supports capabilities to manage users, groups, and roles and manage the routing of tasks to the people in an enterprise. It enables people to collaborate in business processes including assigning tasks, tracking the status of tasks, handling approvals, and so on. Integral to the flow of work are actions such as receiving, approving, modifying, and routing documents. The documents that often accompany work activities provide the background required for people to complete tasks, which are the central component of all Worklist systems. Worklist can be integrated into business process through worklist control.

6.3 Application Integration with WLI Application integration is always implement through business process integration in WLI, i.e. business process centric, there are two kinds of possibilities for a business process to interact with other applications: through integration controls and message brokers with standard type like file, JMS, database or Email to integrate with application or legacy systems; or through resource adapter and application view to integrate with EIS system like SAP, Oracle or Siebel. 6.3.1 Integration through Controls and Message Broker As introduced above, WLI enables a portfolio of out-of-box controls for a business process to interact with external application and resources, this includes: File control and event generator for inbound and outbound interaction with file

system Database control for retrieve and update database systems JMS control and event generator for asynchronous and synchronous message

exchange with message systems Email control and event generator for sending and receiving Emails EJB and Web Service control for integrating with J2EE application or web service

clients

To make use of these controls following steps are to be followed: 1. Create a new control first within the application, the control is name and associated

with a JCX file 2. Configure the control properties or implement methods for the control 3. Add an instance of configured control into business process design

For file, database, JMS and Email controls, they can also be added to business process directly without pre-configuration, but for EJB and Web Service controls, before a control can be created, the EJB or Web Service should exist already or imported and deployed, so that the control can refer to. A business process can also be package as a process control type, or be exposed as web service and reused later as web service control in other business processes. Message broker provides publish and subscribe communication mechanism between applications. A business process can publish messages to a define message broker

Page 75: Business Process Integration

Business Process Integration 75

channel through a message broker publish control, the channel can be subscribed by many other applications or business processes. Event generator enables event triggered publication, when a file, message or email is polled, it will then be published to specified message channel. There are also data transformation and worklist controls integrate mapping and user into application integration. With these integration controls and message broke, it is possible to implement both asynchronous and synchronous business process integration, involving the most common used application interface. So business process integration within legacy systems or with other EAI systems can be implemented in this way, for integration with EIS systems, most of them have their own specific communication interface, the application view and adapter is recommended.

6.3.2 Integration through Application Integration Framework For integration with Enterprise Information Systems like SAP, Oracle or Siebel, application integration framework is recommended. Application integration framework in WLI is comprised of the Application View control in the Workshop environment, the Application Integration Design Console, and support for pre-built BEA and custom adapters. The application integration framework links existing systems and new applications using standards-based architecture to host JCA based adapters. The adapters provide connectivity with EIS systems, including packaged business applications from major vendors. Adapters for RDBMS, Peoplesoft, SAP, Siebel, Oracle Applications, and MQ Series are pre-built for integration with leading enterprise .In addition, it supports the development of J2EE CA-based custom adapters using an Adapter Development Kit. The adapters work together with application views, which provide an abstract interface layer between the adapter and the EIS functionalities exposed by the adapter. An application views often reflects certain business functionality of EIS system, i.e. a single business process. It defines service and events that this business process provides, and is associated with the adapter that connects to the EIS system. Other application system can invoke the certain business functionality through the application view and the adapter behind it, i.e. the business functionality is exposed by the application view and adapter to other applications. One EIS system can have several application views associated to it, as one application view can represents one business purpose, and application views can easily be created or deleted according to business requirements. Application View control is used in WebLogic Workshop to instantiate an application view object. Application vie control can invoke application view services both synchronously and asynchronously, and start a new business process when an EIS event occurs. In both the service and event cases, developer uses XML and mapping tools to interact with the Application View control, so the developer need not understand the particular protocol or client API for the enterprise application.

Page 76: Business Process Integration

Business Process Integration 76

The Application Design Console allows integration specialists to configure adapters without coding, including application introspection, abstracting application logic, and inputs and outputs through Application Views. The whole application integration framework includes application design console for adapter configuration, WebLogic integration administration console for creating and publishing application views to associate with the adapter, and WebLogic Workshop to add application view control to business process and invoke its service. Here is the full lifecycle of application integration design in WebLogic Integration: 1. Define the overall integration solution. This includes defining what EIS and adapters are used and what services and events are implemented. 2. Install and deploy the required adapters. 3. Create a WebLogic Workshop application that implements the required business processes for the integration solution. 4. Define an application view that addresses a specific business purpose. This step includes defining the required services and events and testing the application view. 5. Publish the application view to the WebLogic Workshop application. 6. Define an Application View control that provides access to application view services. 7. Integrate the Application View control into business process. 8. Deploy the integration solution. 9. Manage integration solution using the WebLogic Integration Administration Console. In general, application integration in WLI is business process oriented, i.e. integration solutions are usually designed for a business process to interact with other applications or enterprise information systems. Integration control and message broker already provide business process the capability to access most often used application interfaces. For a business process to access service and events in a enterprise information system, the application integration framework fits the purpose.

6.4 B2B Partner Integration with WLI WebLogic Integration supports also integration between business partners, to streamline their business process with customers, suppliers, distributors or any other partners. This is implemented through the WebLogic Workshop as well, which provides the graphical business process modeling and design functionality. B2B integration supports leading industry standard RosettaNet and ebXML. The interaction in one business process with its business partners can be implemented through three kinds of controls: RosettaNet, ebXML and Web Service Control. WebLogic Integration provides also Trading Partner Management capabilities through the unified WebLogic Integration Administration Console. This console enables administrators to easily manage a central repository of business partner profile information, including protocol bindings used for secure message exchanges between trading partners, services representing public processes, security, and bulk import and export capabilities. At the deploy time for B2B solutions, the trading partner information has to be maintained in trading partner management repository. After business partner profile is available in the repository, the TPM (Trading Partner Management) controls

Page 77: Business Process Integration

Business Process Integration 77

can be added to business process, which helps to get business partner information from the central repository. Authorized business processes and Web services can dynamically access business partner information via easily implemented controls. From security perspective, WebLogic Integration ensures the private, secure, and reliable business message exchanges among trading partners using transport level security with SSL and message level security with digital signature and encryption. ebXML Solution

For business transactions between business partners, there are always one initiator business process which initiates business transaction between the partners and one or more participant business process which receives request from the initiator and then response when necessary. When using ebXML controls, participating process should be design and implemented first using the ebXML participant process type. And then initiator process is designed as the normal process type, ebXML control instances will then be added into the initiator process flow, with the ebXML-service-name property referring to the participant process. Afterwards, business transaction can be conducted by requests and responses between the partner processes. One initiator can also select participant among the many in its process. At Deploy time, the trading partner information has to be maintained into the trading partner management repository through the WebLogic Integration Administration Console, and ebXML bindings (1.0 or 2.0 version) has to be specified, service and service profiles which referring to the business processes offered by the trading partner are to be maintained as well. RosettaNet Solution

In WebLogic Integration, initiator business processes use a RosettaNet control to enable business processes to exchange business messages and data with business partners via RosettaNet. RosettaNet controls are used only in initiator business processes to manage the exchange of RosettaNet business messages with participants. The RosettaNet control provides methods for sending business messages, acknowledgements, and errors, and it provides callbacks to handle response from participants. RosettaNet participant business process can be created using a WebLogic Workshop template (the RosettaNet participant business process file). This template provides a head start for building public participant business processes for RosettaNet message exchanges. Before design of RosettaNet business process, the PIP distribution and all necessary DTD should be downloaded from RosettaNet for the PIP schemas to be imported into business process, and then customize the business process accordingly. At Deploy time, the trading partner information has to be maintained into the trading partner management repository through the WebLogic Integration Administration Console, and RosettaNet bindings (1.1 or 2.0 version) has to be specified, service and service profiles which referring to the business processes offered by the trading partner are to be maintained as well.

Page 78: Business Process Integration

Business Process Integration 78

Web Service Solution Business process can also use Web Service Controls to exchange with their business partners, as web services can be requested through internet and it is up to the initiator process to call the web service via invoking the methods of web service control. Still, the trading partner information should be maintained in the trading partner management repository, and TPM controls can be used to get trading partner information in business process. In general, B2B partner integration in WLI can be implemented through ebXML, RosettaNet or Web Service controls, and the solution design work is carried out by business process modeling in WebLogic Workshop. WLI also has a central trading partner management repository for maintaining trading partner profile information. Security and auditing is also provided at both transportation and message level. WLI also works with Business Connect, a BEA lightweight B2B server for business partner integration, but it support also interoperability with a wide range of B2B server from other vendors.

6.5 BPM in BEA WebLogic BPM functionality in BEA WebLogic has already been discussed in previous chapter. WebLogic Integration is a business process integration tool, with business process integration, it enables business process management. The BPM functionality in WLI can be summarized as below: Graphical business process editing tool

WebLogic Workshop provides a graphical tool for editing business process. A process has a design view and a source view in workshop. In design view, users can implements process modeling by ease drag and drop operation of implemented controls and process flow node control (including switch, parallel, exception handler etc.), and in the source view, users can modify the java code directly, as each process in WLI is a JPD file generated automatically and java implemented.

Unified access to resources through controls WLI has a variety of integration controls to access resources. With the concept of integration control, business activities is viewed as services, and controls provides interface to access services, and business process is modeled by orchestrating the controls

Support for java code in business process WLI is J2EE based; both the controls and processes are java coded and open to users. Java coding is just one click away to users

Simplified and structured business process design WLI adopts open standard to simplify and structure business process design. Besides java support mentioned above, it also uses XML to model flow in business process, and it enables a special Perform mode in process design, by which users can implement Java methods directly

Process implementation optimized for performance WLI supports all of following process: stateless synchronous business process, stateless asynchronous process, stateful asynchronous business process

Page 79: Business Process Integration

Business Process Integration 79

6.6 Comparison BEA WLI vs. SAP XI Up to now, two business process integration tools have been studied into detail: SAP Exchange Infrastructure and BEA WebLogic Integration. In this chapter, a comparison against these two tools is given, this is helpful to identify the possible positioning for these tools, and will give clue to summarize a general integration methodology, which is endeavored in next chapter. The comparison is conducted from following perspectives: general positioning, integration features, enterprise application integration and B2B integration. Commons and differences are described from each perspective. 6.6.1 General Positioning WebLogic Integration 8.1 is seen as rather a Business Process Integration tool, which combines the functionality of business process modeling, management and integration. WLI is process and integration centric. In WLI, an integration solution is an application, the major component inside the application is business processes, and controls which can be integrated into business processes. Application integration is implemented through the business process to interact with other applications, or business process within other applications. The interaction can be realized through its integration controls or application integration framework. WLI provides a graphical process design and modeling tool with node controls that facilitate business process design and management. Through business process design and management, WLI integrates user interactions, legacy systems, enterprise information system and business partners together, and streamlines business processes. While the up to now SAP Exchange Infrastructure version is a connectivity oriented application integration tool. Of course, starting from the 3.0 version, business process management will definitely play an important role. For the current XI version, it aims mainly for application integration. In XI, application integration is implemented through defining the integration scenario with sender, receiver business systems and interfaces, and defining routing and mapping rules in between. Therefore, XI is rather for application integration with connectivity centric. XI provides versatile connectivity to legacy systems, J2EE applications, SAP R/3 and Web Application Servers, mySAP component, business partners and other EAI systems like Oracle, PeopleSoft, via its adapter framework, proxy framework, and web service framework. But the future XI versions starts from 3.0 are also seen as business process integration centric, as it involves business process design and management functionality as well. For conclusion, WLI is process and integration centric, it provides business process modeling and management functionality and it is already a business process integration tool. XI is currently emphasis on application integration and provides versatile connectivity to business systems within or outside enterprise, and it is going to be also a process integration centric coming up with 3.0 version and business process management functionality.

Page 80: Business Process Integration

Business Process Integration 80

From connectivity point of view, XI delivers more than WLI. As XI is from SAP and it provides various and express options to integrate with SAP products, like R/3, Web AS, CRM, SRM etc. which have been widely used already in enterprises, and are the major systems to be integrated. SAP is also going to provide out of box integration of mySAP components mentioned above with XI, so users need not pay additionally for XI as the process integration tool. In contrast, if users choose other process integration tool to integrate SAP components, then they have to pay additionally for the process integration tool. Compared with XI, BEA is rather weak at the point, as it has to use external adapters to integrate this kind of systems (users need to pay additionally for the external adapters), connectivity possibility is limited and the interoperability with mySAP components like SAP CRM or SRM is still to be discovered. 6.6.2 Integration Features Both WLI and XI have its own integration features, and some of them are common. The discussion below tries to summarize common and specific integration features of the two tools. Common Features: Process integration component of a whole cooperate application framework or

platform. The whole framework usually includes a web application server as the backbone application platform, a integration tool for process and application integration and a portal to integrate user interaction. The SAP NetWeaver package includes Web Application Server as the platform, XI for process integration, Enterprise Portal for user integration, and besides Business Warehouse and MDM for information integration. The BEA integration framework includes WebLogic Server as platform, WLI for process integration, WebLogic Portal for user integration, and WebLogic Workshop as the central development environment. It is seen as a trend for integration solution providers to deliver such kind of whole cooperate application platform, which includes a web application server and components to integration process, information and user.

Open standards based Both WLI and XI are based on open or web standards. Java is usually used for development, J2EE is usually the standard for their web application servers, and JCA is used for adapters. Especially WLI is a totally J2EE based tool, a integration solution application in WLI is actually a J2EE application, business process and controls are all java coded, and the whole application will be deployed on its WebLogic Server. XSD and XSLT or XQuery are used in data structure definition and transformation, XML is used as the standard message format, RosettaNet and ebXML are used for business partner integration, HTTP, SOAP and Web Service are used in communication as well. All of them are open standards, allows easy integration with other applications, and also for import and export of designed components within the middleware.

Page 81: Business Process Integration

Business Process Integration 81

Collaborated knowledge Sharing Both XI and WLI adopts collaborated knowledge sharing, but to different extent. XI is totally aimed at collaborated knowledge: it has system landscape where all products, software components and business systems information is managed and maintained; integration repository where all the design time knowledge like metadata, data types, message and interface types, business processes and mappings etc are maintained; integration directory where all the configuration or runtime information is maintained, like business scenario, routing. These central repositories enable knowledge and information to be shared within different business systems and be used repeatedly without redesign in each integration scenario. WLI also adopts the concept as it also has a trading partner management repository to maintain trading partner profiles. And implemented control objects in one WLI application can always be reused by adding a control instance into business processes within the application. But knowledge in WLI is not completely collaborated, as it still has the application limit, controls in one application can not be used in another application (the application here refers to WebLogic integration solution application), and it does not have a central repository to maintain designed controls in all application except the trading partner management repository

Component based Both WLI and XI are highly object oriented and component based. In XI integration repository, everything is treated as an object, and can be used by other objects. For example, data type objects can be used by message types, and message types used by interface types, mapping objects can be used in business scenario directly. WLI is also a component based tool. It provides many controls for integration in its workshop, and the controls can be implemented and then instantiated to be used by business processes, imported EJB and Web Service can be published as a control as well to be used repeatedly. The most important is that the modeling of business process is component based. A business process is built up by adding components to the process flowchart, this is true in both XI and WLI. It is obvious that process integration tool should be object oriented and component based in order to have an open integration solution.

Business Process Design and Management WLI provides already business process design and management functionality in its WebLogic Workshop, where business process can be design and implemented under a graphic environment. The nodes and controls implemented in business process realize business process management functionality. In WLI process integration starts with the design of business process, i.e. process design is a must step for integration, as WLI implements integration on process level. XI involves BPM functionality also from the coming 3.0 version (it is to be evaluated), and Business Activity Monitoring functionality in its future versions. But in XI integration can be implemented on both application and process level, it is not a must to design process for integration purpose, as the integration can also implemented on application level. It can be concluded that a business process integration tool will inevitable supports BPM functionality.

Page 82: Business Process Integration

Business Process Integration 82

Enable User interaction via workflow While providing business process management functionality, it is inevitable to involving user interaction. Both WLI and XI support this. XI is integrated with Enterprise Portal to enable user interaction with business process, and Enterprise Portal can also manage Ad-hoc workflow. WLI uses worklist control to enable definition of user interaction in business process, and Worklist Console to enable users to interact with or involve in business actions.

Data Transformation and Routing XI has a graphical mapping tool for designing of data transformations between source and destination interfaces, besides XSLT and Java mappings can also be imported, and multiple mapping steps are allowed within mapping. Routing is a compulsory step in XI for application integration, and XPath rules can defined for routing criteria. In WLI, data transformation is implemented through data transformation control, it uses XQuery (XML Query, details see Appendix C) to map source and destination data format, and it provides a graphical tool for data transformation design as well. Routing is always possible by implement through business process design, and there is also path selection functionality through certain kind of node in business process design.

Transportation and Runtime Monitoring For business process integration tools, transportation and runtime monitoring is always necessary. In case there is problem with message communication, it is always possible to monitor and track the source of the problem. XI has monitoring for integration engine, runtime branch, and for adapter framework work, and makes use of CCMS as well. WLI uses WebLogic Administration Console for monitoring, e.g. for message brokers.

Special Features: Message Broker in WLI

WLI has special integration feature Message Broker, which enables pure publish and subscribe communication. It enables business process to publish message to a certain message broker channel, and this channel can be subscribed by one or multiple business process, which can pick the message up themselves in a self service mode. Event Generator is always associated with message brokers which enable event triggered message publication. It continuously polling under certain path or channel, once an event happens, it publishes polled file, email or JMS message to message broker channel. It works similarly like the inbound adapter of XI.

XI web service and proxy framework Compared to WLI, XI has special integration features of Web Service Framework and the Proxy Framework. Web service framework actually is a web application server functionality, as XI is based on Web AS, therefore the framework is available on XI. Web Service Framework enables web service clients to communicate with

Page 83: Business Process Integration

Business Process Integration 83

web application servers via XI, the web service is value-added, as XI provides routing, mapping and business process management functionality in between. There is also possibility to implement a point to point Web AS communication short cut via web services. Proxy framework is also unique to XI. It enables XI to communicate easily with Java/J2EE applications and web application server via Java or ABAP proxy. The proxy interfaces are generated by XI, they provides users with a interface to implementing without caring about the details of communication with XI.

From above summarization, some general characteristics can be found with business process integration tools. And the typical integrated methods possessed by WLI and XI correspondingly are also featured. Starting blow, the comparison is detailed further from enterprise application integration and B2B integration perspectives. Both WLI and XI support enterprise application and B2B integration, but they have different ways to implement the integration. 6.6.3 Enterprise Application Integration Enterprise Application Integration is implemented differently in XI and WLI. XI uses its adapter framework, web service framework and proxy framework for enterprise application integration. Inside its adapter framework, there are IDoc and RFC adapter to integrate with SAP R/3 systems; File, JDBC, JMS adapter to integrate with legacy or other application systems like file system, database or messaging system; there is also Eco-partner adapter to integrate with other enterprise information systems like Oracle or PeopleSoft, Siebel. Web service framework integrates XI with web services clients, SAP Web Application Server. Proxy framework enables XI to integrate with Java or J2EE based applications, and SAP Web AS based components as well, like Business Warehouse or mySAP components like CRM, SRM. With these frameworks XI has the connectivity to almost all the common used application interfaces, and also to SAP R/3, Web AS and mySAP components, and other leading ERP or EAI systems. No matter which framework it uses, integration scenario is always implemented via Integration Builder. Specifying the sender and receiver business systems, defining mapping and routing rules, and decide the endpoint using the connectivity provided by the frameworks are the steps to implement integration solution in integration builder. Therefore it is connectivity oriented, one integration solution is decided by the route from the sender to receiver business system. WLI does it differently. It implements enterprise application integration through its integration control and message broker, or through application integration framework via adapter and application view. Integration controls provide also the connectivity to legacy systems and applications like file, database, Email and messaging systems, also with web services and J2EE applications. Message broker enables publish and subscribe communication and event generator strengthens integration with file, email and messaging systems. With application integration framework, WLI integrates with leading EIS providers like SAP, Oracle or Siebel.

Page 84: Business Process Integration

Business Process Integration 84

WLI also has a wide connectivity range in enterprise application integration. And it is implementing business process integration. Integration solutions are always process centric, business processes and controls that to be included into business process are the main elements of a integration solution application, and integration among applications are realized through business process interaction within the involved applications. XI and WLI have common in enterprise application integration in that they both provides to common application interfaces like file, JDBC and JMS, also to leading ERP providers, and both utilize web services for integration. WLI utilize integration controls while XI uses adapters to integrate common application interfaces. The advantage of using controls is that it is object oriented and open source, the controls in WLI is java coded, and the source code is available to users through source view, therefore users have the option to edit the java code directly to implement the control. While the adapters in current version is not object oriented but hard coded, therefore it is not so flexible as controls in WLI, although an adapter can also be copied and reused as a template for other adapters. But the adapter framework in XI 3.0 will be JCA based as well. From connectivity point of view, XI is more powerful especially in connection with SAP R/3 and mySAP components, which is rather weak with WLI. And WLI has the advantage in implementing integration on business process level rather than application level, which results in business process management functionality and a business need focused integration solution. XI is will also involves BPM from 3.0 version and focuses on business process integration. 6.6.4 B2B Integration B2B integration is supported both in XI and WLI. WLI implements B2B integration through its RosettaNet and ebXML controls. An initiator process makes use of RosettaNet or ebXML controls to initiate business transaction with its trading partner, which has a participant process provides service for B2B control in the initiator process using RosettaNet or ebXML standards. Both asynchronous and synchronous communication is supported. Web Service control can also be used for B2B purpose. WLI also has a trading partner management repository which maintains trading partner information and services they provide. The trading partner information in repository can also be access and utilized through a TPM type of control in business process. XI enables B2B integration through its industry standard adapters, and Partner Connectivity Kit. Industry standard adapters include adapter for RosettaNet (RNIF adapter) and CIDX for chemical industry and support these standards correspondingly. Besides the adapter, RosettaNet related information like PIP will also be maintained in integration repository. Partner connectivity kit enables small businesses to integrate with the XI system of their larger business partners via File, JDBC or JMS adapter. XI also maintains business partner profile in its repository, e.g. collaboration profile and agreement for business partner is maintained in integration repository.

Page 85: Business Process Integration

Business Process Integration 85

Both XI and WLI support industry standard RosettaNet for business partner integration, and maintain business partner profile in their repository. WLI supports ebXML standards and web service for B2B in addition, while XI provides its own partner connectivity kit for integration with smaller business partners.

6.7 Summary In this chapter, BEA WebLogic Integration is studied and compared with SAP Exchange Infrastructure. Following are major differences between WLI and XI after comparison: WLI is a business process integration tool. It implements integration on business process level while the current XI version implements integration on application level. Things are going to be change from XI 3.0 version with BPM functionality. WLI provides Message Broker for explicit publish and subscribe communication. With message broker, there is an explicit and exclusive channel between the publisher and subscriber system. While publish and subscribe in XI is rather implicit, XI provides inbound queues to receive messages from all senders system, and forward messages to correspondent receiver outbound queue according to routing. There is no single exclusive queue between one sender-receiver scenarios. WLI implements application integration through its integration controls, while XI through adapters. Integration controls in WLI has advantage over XI adapters in that it is object oriented and open source, while the XI adapters is not object oriented but hard coded. XI implements collaborated knowledge sharing and pre-delivered integration content. It provides system landscape to manage and maintain all system and software components, integration repository and directory to maintain design and configuration time information. These are all object oriented repositories and resources within repository can be easily used by any integration scenarios. XI also brings metadata of SAP components into its integration repository. While in WLI it is rather weak, as resource can not be used across integration solution application. XI has much better connectivity over WLI especially to SAP products. XI has many options to integrate with SAP R/3, Web AS and mySAP components, while this connectivity in WLI is rather limited. No doubt that in integration scenarios that SAP systems play an important role, XI is the first choice for integration. XI provides unique Web Service Framework and Proxy Framework. Web service framework provides more integration possibility with SAP Web Application Server. Especially the proxy framework generates proxy interfaces for users, and simplifies implementation work for integration with Java/J2EE applications and Web Application Servers. As WLI is ready business process integration tool, the detailed look into it and comparison with XI helps to give a clearer picture about what a business process integration tool should do and how should it work. This will be made use of in the last chapter, to draft a general process integration methodology and general characteristic of process integration tool. Following table gives a complete view of XI vs. WLI.

Page 86: Business Process Integration

Business Process Integration 86

Features SAP XI BEA WLI Application or Process Integration

Integration on application or process level Integration on process level

A2A Integration Integrate applications through adapters or proxies

Integrate through integration controls or resource adapters

B2B Integration Integrate through industry standard adapters or partner connectivity kit

Integrate through RosettaNet or ebXML control, also Web Services

Business Process Design and Mgmt

Business process design and management available on 3.0 version, process supports BPML standard

Provide graphic process modeling tool and support for java code in process, unified resource access through integration controls

Openness and Flexibility

Support open standards, adapters are JCA based, mappings in Java or XSLT, data type in XSD, message in XML format, also support web services

Support open standards, adapters are JCA based, mapping design using XQuery, process design supporting Java, web flow design supporting XML

Collaborated Knowledge Sharing

Integrate through collaborated knowledge sharing, provide system landscape directory as repository of business systems, integration repository and directory as design and configuration time repository

Support collaborated knowledge sharing. Provide trading partner profile repository, technical information including frequently used message formats are maintained in repository

Component based

Yes, objects in integration repository are treated as components and can be used to build up business processes

Yes, integration controls are treated as components which built the business process up

User integration

Allowed, through universal worklist, and user integration is managed through enterprise portal

Allowed through worklist control and worklist console to manage user interaction

Data Transformation/Mapping

Enabled through mapping design or importation, graphic mapping tool provided

Enabled through data transformation control, graphic design tool provided

Transportation and Monitoring

Supported through integration engine monitoring

Supported, monitoring in administration console

Other integration features

Web Service and Proxy Framework for integration with web service clients, Web AS and Java/J2EE applications

Message Broker, with channel and event generator enabling explicit publish/subscribe communication

Table 3 Comparison XI vs. WLI

Page 87: Business Process Integration

Business Process Integration 87

7 General Process Integration Methodology After a inside study into process integration in SAP Exchange Infrastructure and BEA WebLogic Integration, also with some practice implementation of process integration with these tools, and understanding of business process management, it should be enough to give some summary and outlook on all the discussion above. In this chapter, some general process integration methodology used in XI and WLI is summarized, which is seen by the author as the most common ways for process integration. And the next chapter summarizes on general requirements for future process integration platform.

7.1 Communication Mechanism 7.1.1 Publish and Subscribe One or multiple process may publish message to a certain channel or queue, where one or multiple other processes are subscribing to, once a message is published to the channel or queue, subscribers will pick it up. Publish and subscribe mechanism usually implements asynchronous communication. With the awareness of its subscribers there could be two possible mechanisms: the publishing process broadcasting messages without knowing, how many and which processes are subscribing to the message it publishes, and the subscribers can decide what and where to subscribe to at runtime or design time; or the publishing process knows who is going to subscribe to the messages it publishes, and until all subscribers get the message the publishing progress is not finished. The first mode enables business processes to communicate in a loosely-coupled, anonymous manner using a business-naming paradigm when the channel or queue name is specified. The second mode ensures that all subscribers will get the message that the publisher publishes. WLI supports publish and subscribe communication. WLI takes the first mode, it uses message broker for a process to publish messages, and a named message broker channel is specified where to publish to. Consumer process subscribes to the channel, once a message is published to the channel, it will get the message from the channel, consequently the consumer process will be triggered to start if it is triggered by subscription to the message broker channel, or it will continue processing if subscription is a node within the process body. When a process is to publish message through message broker, it has to set up a new message broker channel or make us of available channel, channels are named, and the type of the channel determines message type that it can pass. Message brokers are usually associated with event generators, which enables event triggering message publishing. Event generator publishes event from external resource to message broker channel. With this mode, usually asynchronous communication is implemented. Because each channel has its name, therefore the publisher process broadcast messages through a certain channel, if the subscribers want to send acknowledgement or response back to the publisher, they have to use other channels. What XI does is not true publish and subscribe, but rather store and forward. But publish and subscribe can be implemented at certain sense providing that no runtime self subscription is required, but the subscription rules can be defined at the configuration

Page 88: Business Process Integration

Business Process Integration 88

time. Then XI can make use of the second mode. In XI each integration scenario involves sender and receiver system names and their interface names, there are inbound queues in integration server to receive messages from the publisher, and after mapping and routing, messages are forward to the corresponding outbound queue in integration server for each individual subscriber. Therefore in XI, the integration engine cares about which subscribers subscribe to a certain message and it will ensure that a published message arrives at all of its subscribers. But in XI, there is no named channel. The publisher process is not publishing message to an explicit channel or queue where the subscribers can explicitly subscribes to, instead, the integration server takes care of all the intermediate procedure. Concrete implementation of publish and subscribe communication may be various. But publish and subscribe communication is very useful asynchronous broadcasting or multicasting communication. 7.1.2 Request and Reply Publish and subscribe is used for asynchronous communication, then request and reply is used for synchronous communication. A process sends a request message to another process, which proceeds the request and send response message back to the sender. Both the sender and receivers systems are aware of the request and response message format or interface type. There could always be mappings in between the request message format sent by the requestor and the one accepted by the receiver, and the response message format sent by the receiver and that accepted by the sender. XI implements request and reply always by synchronous message communication. In XI when defining a message interface, it has always to be defined as synchronous or asynchronous. If it is synchronous, then the message type that it sends out and expects to receive should be specified. At runtime, a sender system sends request message to integration server, which performs mapping and routes the request to receiver. While the respect receiver gets a synchronous message type, there must be certain program to handle the request, like ABAP or Java proxies or whatever, which processes the request and generates a response back to the integration server. The integration server will then probably perform mapping again and sends the response back to the sender system. There are many means to support request and reply communication in XI, for example, RFC, Proxy, Web Service etc. WLI supports request and reply communication usually be its integration controls. As discussed in the paper, there is a portfolio of integration controls for WLI to integration with other application systems. Users can implement methods upon these controls, which defines the request type it gets, the operation on the request and then the response type it sends out. These controls can then be instantiated and used in business processes. Therefore request and response is implemented in the following way: one sender process sends request out via certain integration control, where the request type and expected response type is specified. The receiver process receives request, and process it via invoking certain methods of an integration control instance described above, and then

Page 89: Business Process Integration

Business Process Integration 89

sends the output of method processing to the requestor. And many control types like web service, EJB support this kind of synchronous communication Publish and subscribe mechanism and request and reply mechanisms are most common used communication mechanism for asynchronous and synchronous communication respectively.

7.2 Connectivity Technology Above the communication mechanism is the connectivity used to integration, processes application systems or external resources in business process integration. 7.2.1 Adapters Adapters here refer to the kind of interface that process integration tool used to connect to business systems or external resources. Users only need to specify certain parameters and options to connect to the target resource and operations to perform on the resource, while the adapters care for the actual communication behind. The adapters usually handle connectivity to most common application interfaces or resources like file, email, database or messaging systems, therefore the usual adapters includes file, SMTP to emails, JDBC to database, and JMS to messaging systems. When considering SAP systems, IDoc and RFC adapter apply. Implementation for adapters can be various, for example XI uses outbound and inbound adapters. XI has outbound adapter to send message out to business system or resources, and perform operations on them when necessary. And inbound adapter is used to poll and receive message from business system or resources. Users can configure adapter settings in a browse based tool and adapters can be copied as template for other adapters. While in WLI adapters are implemented through integration controls, similar like outbound and inbound adapters in XI, integration controls allow user to specify connection parameter and options to target resource, and define methods to be executed on the resources as well. Some type of controls can not poll information from source information, but this can be implemented through event generators instead, and the configuration is easy at same extent. The integration controls have the advantage in that they are object oriented and open source. They can be easily plugged into a business process and be reused by drag and drop, and the source of controls can be modified by users in source view. WLI also provides resource adapters together with its application view for integration with enterprise application system, and the mechanism is similar like adapters in XI. Adapters save users lots of developing work as it takes over the underlying communication with target business systems or resources. 7.2.2 Proxies Proxy is another technology for process integration tool to connect with application systems, it is also a kind of interface that provides connectivity to application systems, and users only need to focus on implementation of business logic. Proxies are generated based on the message interface, which indicates the information of: the mechanism of the

Page 90: Business Process Integration

Business Process Integration 90

interface, i.e. it is synchronous or asynchronous, and in each case, what is the outbound and inbound message type, the message type contains the data structure of the message to be exchanged of course. Proxy interfaces are generated for users, which contains information above, and provides underlying communication with target application. What users need to implement is business logics. XI support Java/J2EE proxy and ABAP proxy, which can be used to connect with Java/J2EE applications and SAP Web Application Servers respectively. For java, only synchronous outbound proxies are possible, and with J2EE proxies, both synchronous outbound and asynchronous inbound proxies are available. For ABAP proxy, it is also available for both synchronous and asynchronous scenarios. Take J2EE proxy for example, most common case to use would be: a J2EE application sends a request to XI via J2EE proxy, which forward request to a target system, and the receiver sends response back to XI, which forwards the response to the J2EE application, in this case synchronous outbound proxy is utilized. The other case would be a J2EE application or Web Application Server receives message from XI through J2EE or ABAP proxy, and asynchronous inbound proxy applies here. 7.2.3 Web Services Web service is another widely used technology by process integration tools to communicate with application systems, in this case, web service clients or web application servers. Web services implement certain business logic, and it can be exposed on internet, and be requested by any consumer who needs the service, the communication in between make use of SOAP as the protocol. The process integration tool usually simplifies the work to invoke a web service or provides value added web service to consumers. As web services can be requested through internet, it can be used for integration with business partners as well. WLI utilizes web service control to expose web services. The web service control simplifies the work to invoke web service, and web services can be imported into WLI as a web service control. A business process in WLI can also be packaged and exposed as web service to be used by other processes. Web service can be used within enterprise and also between trading partners in WLI. In XI, there is SOAP adapters which can talk to web service clients and servers. And from the XI3.0 version, there is a more complicated web service framework, which provides value-added web service for web service clients. XI adds mapping, routing and business process management functionality to basic web services. And the web service framework also provides a point to point shortcut between web application servers without XI in between. In XI, both asynchronous and synchronous web services are supported. 7.2.4 Industry Standards Industry standards are often used for B2B integrations in process integration tools. Industry standards provide a standard way for business transactions among business partners, i.e. process is standardized and messages exchanged are in standard format as well. Typical industry standards include RosettaNet for business transactions in high tech industry, CIDX for chemistry industry.

Page 91: Business Process Integration

Business Process Integration 91

Both XI and WLI adopt industry standards for B2B integration. In XI, RosettaNet and CIDX are supported, and XI has RNIF adapter to support 1.1 and 2.0 version of RosettaNet. In WLI RosettaNet is supported through its RosettaNet control. Besides WLI also provides ebXML control for business partners to exchange business messages using ebXML protocol, another emerging industry standard.

7.3 Conclusion In this chapter, common methodology and technology used in business process integration is summarized. From methodology point of view, publish and subscribe is most often used in asynchronous communications, especially in scenarios like broadcast or multicast. Request and reply is the most common used mechanism for synchronous scenarios. From connectivity technology point of view, adapters, proxies, web services and industry standards are most frequently used technologies. Adapters and proxies all provide connectivity to application interfaces and simplify development of users by taking care of underlying communication, and allow users to concentrate on business logic only. They usually cover connectivity to most common applications like file, email, database and messaging systems. Web service provide an alterative to spread service through internet, they are always utilized for communication between web service clients and web application servers. And industry standards provide business partners standard way to conduct business transactions through standard business message exchange. This chapter concludes this paper through process integration technology perspective, the next chapter concludes on requirements for future process integration platform.

Page 92: Business Process Integration

Business Process Integration 92

8 Outlook of Process Integration Tool As a conclusion of this paper, an outlook or requirements for future process integration platform is discussed. This outlook is based on the discussion above about process integration challenge and summarization of characteristics of XI and WLI. Below are requirements or outlook for future process integration platform. Combines integration of people, information and process

The future process integration platform should integrate people, information and process together. As business process usually involves human interaction and exchange of information, process integration inevitable involves people and information integration. Therefore, process integration tool tends to combine people, information and process integration into one single application platform. People integration is usually supported by portal, where users can process with worklist items issued by process integration tool. Information integration can be supported by data warehouse tool, which provides data mining, extraction, transformation and loading, and the data warehouse tool can be integration with process integration tool seamlessly. So the whole process integration platform usually provides a loosely coupled integration of people, information and business process. Covers both A2A and B2B integration

Instead of individual integration solution for enterprise application integration and business partner integration, the process integration platform provides unified integration solution for both A2A and B2B integration. Through adapters, A2A and B2B integration can be implemented in the same manner. File, database and JMS or enterprise specific adapter types can be used for A2A integration, while industry standard adapters like RosettaNet and ebXML can be used for B2B integration. A business process may involve business activity within enterprise and with business partners, therefore, business process integration platform should cover both A2A and B2B integration. Provides Business Process Management

Business process management supports design, automation, execution, monitoring, analysis and optimization of business processes, and allows companies to automate, streamline and manage their business processes. BPM is a critical functionality to be provided by the upcoming process integration platform. The process integration tool should usually provide a graphic process editing tool, and facilitate it with node control type which covers business patterns to be used in business processes. It should allow the process to interoperate with external resources and business systems of course, and power the automation and execution of business processes with monitoring. Collaborated process integration with knowledge sharing

Process integration platform may implement collaborated process integration with knowledge sharing to meet the process integration challenge. As point to point integration is rigid and expensive to adapt to change of enterprise infrastructure, collaborated process integration with knowledge sharing can solve the problem. It implements central repository for all software components and business systems within the enterprise landscape, repository for all metadata from business systems and repository

Page 93: Business Process Integration

Business Process Integration 93

for designs and configurations in available integration solutions. When the enterprise infrastructure grows and demands for integration with available infrastructure, the process integration platform can meet the demand by less work and lower cost, as it already contains integration knowledge of available infrastructure, and only need to be updated for new components. Collaborated knowledge sharing enables easy adoption of available integration knowledge in new integration scenarios, and provides central repositories to maintain and manage integration knowledge. There could also be some pre-delivered integration contents inside the repositories, for example, integration metadata for SAP solutions. Object Oriented

When utilizing collaborated knowledge sharing, the process integration platform will be object oriented consequently. The contents within the integration repositories should be maintained as objects, so that they can be utilized by integration scenarios in an easy manner. It should also be object oriented at the business process design time; controls are implemented as objects that can be instantiated by business processes. Even the adapters can be implemented as controls, which are objects. Users can define own methods on these controls, and implemented controls can also be directly used by business processes. Object oriented process integration tools provide users with structured and simplified design on business processes, and bring the benefits of easy interoperability. Openness and interoperability

Upcoming process integration platform should be open and have wide interoperability with existing enterprise applications. They usually leverage open standards like Java or XML for design work, and provide interoperability to most common used application interfaces like file, JDBC and JMS. Use WLI for example, it is a J2EE based application framework, integration solutions are J2EE applications that can be deployed on application server, and all objects and process designed in WLI is coded in Java, users can view and edit the source code of process and objects by just one click. And to enable integration with various internal and external applications, process integration platform should be ready with connectivity to all these application interfaces, at least the leading application interfaces like mentioned above. As enterprise information systems are backbone of enterprise applications, it is critical to provide connectivity to these systems like SAP, Oracle or Siebel. Eco partner adapters can be utilized here to provide connectivity. Process integration platform can also provide adapter development kit, which allows users to develop their own adapters in order to meet additional need. Leverage of open and industry standard

It is very important for process integration platform to leverage open standards, as it provides more interoperability. Some standards are usually used in integration, like XML for message format, XSD for data type definition, XSLT or XQuery for data transformation, these open standards allow users to easily import objects to and export from process integration tools, and brings more interoperability consequently. Industry standards offer a standard way for business partners to conduct business transactions, and they have been widely used in B2B integration. Process integration platform usually adopts these standards to implement B2B integration, for example

Page 94: Business Process Integration

Business Process Integration 94

RosettaNet for high tech industry and the emerging ebXML standard. Therefore there should be corresponding adapters provided by process integration tool to support communication via these industry standards. Legacy integration at connectivity, monitoring and metadata level

Many systems involved in process integration are legacy systems. Process integration tool should integrate these systems at connectivity, monitoring and metadata level. Connectivity is the prerequisite for integration, metadata provides contents to be integrated, and monitoring helps to monitor and track integration performance. Monitoring is especially helpful, as analysis based on monitoring results always gives clue about bottleneck in process integration, and optimization on current business process. Powerful monitoring at runtime, for adapters and business processes usually helps. Complete integration on all the connectivity, metadata and monitoring levels are recommended for future process integration platform. Message Persistence

In order for users to be able to track messages flowed in process integration platform, it is important to provide message persistence. It would ideal that users can define the retention period of persisted messages, and decide on operations to be performed on over dated messages, e.g. delete from database, archiving etc. Data transformation

As business documents exchanged in process integration usually have various formats, and it is quite often that mappings are demanded between source and destination message format, data transformation is a must for process integration tools. They usually provide a graphic mapping tool, which allow users to define mapping rule by simple operations like drag and connection. For much complicated mapping, it is also suggested that process integration platform to support import of mapping definitions, or integrate with dedicated mapping tools so that mappings from that tool can be utilized in process integration directly. Content based routing

Process integration tool should provide content based routing, i.e. it should be able to decide the receiving business process according to the contents of the message sent from sender business process or application. Some standards like XPath can be adopted here to for users to specify rules of receiver determination. It could also be implemented through a selection node in business process, where methods are implemented to decide the receiver of messages. Quality of Service

Process integration platform should guarantee delivery service of messages. Best effort, exactly once and exactly once in order are usual service quality levels. For asynchronous scenarios, at least exactly once is required, and in some scenarios exactly once in order is demanded where the sequence of messages matters. For synchronous scenarios, usually Best Effort service should be guaranteed.

Page 95: Business Process Integration

Business Process Integration 95

Availability, Performance and Scalability Other factors for process integration tool to care about are availability, performance and scalability. High availability should be guaranteed as information flow is critical to enterprises, so process integration tool should have high availability in order to guarantee service. Performance is also demanded to reflect the advantage of process integration tool and its capabilities. And it should be scalable as well, so that it could easily adapt to changes in enterprise infrastructure. Above is outlook or requirements for future business process integration platform. The conclusion in this paper is based on study and practice on process integration platform Exchange Infrastructure from SAP and WebLogic Integration from BEA. In this paper, challenge in process integration is discussed, and two process integration tool that endeavor to solve integration problems are looked inside. An integration catalogue for integration with SAP Exchange Infrastructure is given. Also it is compared with BEA WebLogic Integration in order to get general design concept for process integration tools, including the technology they use and features they provide. Business process management is also studied as a relevant interesting topic. Although technologies and standards are already available in the process integration field, much more efforts are still to be made on it. For example, supply of more out of box integration scenario to save user implementation work.

Page 96: Business Process Integration

Business Process Integration 96

Appendix A List of Figures: Figure 1 Business Process Reengineering ........................................................................ 10 Figure 2 XI 2.0 Component Overview ............................................................................. 14 Figure 3 XI 2.0 Architecture Overview ............................................................................ 16 Figure 4 Integration Server transferring a message (from XI white paper)...................... 16 Figure 5 Business Process Management in SAP NetWeaver ........................................... 18 Figure 6 Cross-component BPM in XI ............................................................................. 19 Figure 7 Adapter Framework............................................................................................ 22 Figure 8 Adapter Framework of XI3.0 ............................................................................. 23 Figure 9 Point-to-Point Web Service Optimization.......................................................... 28 Figure 10 SAP system connectivity methods ................................................................... 29 Figure 11 SAP- mySAP CRM connectivity ..................................................................... 32 Figure 12 SRM using XI................................................................................................... 32 Figure 13 Master Data Management and XI..................................................................... 33 Figure 14 SAP – non SAP Connectivity Overview.......................................................... 34 Figure 15 Working mechanism of outbound J2EE proxy ................................................ 38 Figure 16 Working mechanism of inbound J2EE proxy .................................................. 39 Figure 17 Value-added Web Service ................................................................................ 39 Figure 18 XI works with RNIF adapter ............................................................................ 42 Figure 19 Partner Connectivity Kit work with smaller business partners ........................ 43 Figure 20 XI and other EAI/ERP interoperability ............................................................ 45 Figure 21 PRS scenario data flow..................................................................................... 47 Figure 22 PRS Minimum message handling functionality requirement........................... 50 Figure 23 PRS IDoc-plain HTTP Connectivity Design.................................................... 51 Figure 24 Tuning setting for PRS queue management ..................................................... 53 Figure 25 PRS Integration Directory Settings .................................................................. 53 Figure 26 PRS IDoc – Proxy Design ................................................................................ 54 Figure 27 Java Proxy Generation...................................................................................... 55 Figure 28 ABAP Proxy Generation .................................................................................. 56 Figure 29 PRS design with web service request and reply............................................... 57 Figure 30 PRS general Publish / Subscribe design via XI................................................ 58 Figure 31 PRS Message referencing and mapping design proposal for XI...................... 61 Figure 32 BEA WebLogic Platform ................................................................................. 65 Figure 33 BEA WebLogic Workshop............................................................................... 66 Figure 34 an example control implementation in WLI..................................................... 69 Figure 35 A business process utilizing integration controls ............................................. 70 Note: Figure 1-9, 12-13, 15-19 are quoted from SAP Presentations, see References. Figure 28 is quoted from BEA Documentation in References.

Page 97: Business Process Integration

Business Process Integration 97

List of Tables Table 1 SAP Connectivity Analysis in XI ........................................................................ 30 Table 2 PRS Scenario Requirement Analysis................................................................... 64 Table 3 Comparison XI vs. WLI....................................................................................... 86

Page 98: Business Process Integration

Business Process Integration 98

Appendix B Reference: SAP XI Help Portal http://help.sap.com/xi SAP Presentations SAP XI2.0 Whitepaper, SAP AG New Features of XI3.0, Wolfgang Fassnacht, SAP AG XI Architecture and Operational Aspects, SAP AG SAP XI – Process Centric Integration, Thomas Volmering, SAP AG XI Java Proxy Runtime and J2EE Integration, Andreas Herrmann, SAP AG B2B and Industry Standard Support, SAP AG SAP Interoperability with EAI Products, SAP AG Cross Component Business Process Integration, SAP AG Business Process Management, Thomas Volmering, SAP AG Business Process Management in SAP NetWeaver, Alan Rickayzen, SAP AG BEA Online Documentation WebLogic Workshop 8.1 http://e-docs.bea.com/workshop/docs81/index.html WebLogic Integration 8.1 http://e-docs.bea.com/wli/docs81/index.html BEA Documentation Introducing BEA WebLogic Integration, BEA Systems, Inc Introducing Application Integration, BEA Systems, Inc Introducing Trading Partner Integration, BEA Systems, Inc Tutorial Building Your First Business Process, BEA Systems, Inc

Page 99: Business Process Integration

Business Process Integration 99

Appendix C Glossary Business Process Integration: controlled sharing of data and business processes among any connected applications and data sources within an enterprise and between business partners, without having to make sweeping changes to the corporations existing information assets. Business Process Management (BPM): a change management and system implementation methodology to aid the continuous comprehension and management of business processes that interact with people and systems, both within and across organizations. It enables organizations to automate, streamline and manage business processes, which including design, automate, execute, monitor, analyze and optimize business processes. A2A integration: Application to application integration means following: translating data and commands from the format of one application into the format of another. It is essentially data and command conversion on an on-going basis between two or more incompatible systems. The other aspect of application integration is redesigning disparate information systems into one system that uses a common set of data structures and rules. Enterprise Application Integration (EAI): application integration within a business, it is combination of processes, application and standards and hardware resulting in the seamless integration of two or more enterprise applications allowing them to operate as one. B2B integration: application integration between business partners, i.e. a company to integrate its internal enterprise application with those of its business partners. B2B integration occurs when systems of tow or more business exchange information that, directly or indirectly, results in a transaction. J2EE Connector Architecture (JCA): defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. The JCA consists of two parts: an EIS-specific resource adapter and an application server that the resource adapters plug into and providing connectivity between the EIS, the application server, and the enterprise application. The JCA defines a set of contracts, such as transactions, security, and connection management, which a resource adapter must support in order to plug in to an application server. Details under: http://java.sun.com/j2ee/connector/ Resource Adapter: To achieve standard system-level plug ability between application servers and EISs, the J2EE Connector architecture defines a standard set of system-level

Page 100: Business Process Integration

Business Process Integration 100

contracts between an application server and EIS. The resource adapter implements the EIS-side of these system-level contracts. A resource adapter is a system-level software driver used by an application server or an application client to connect to an EIS. By plugging into an application server, the resource adapter collaborates with the server to provide the underlying mechanisms, the transactions, security, and connection pooling mechanisms. A resource adapter is used within the address space of the application server. Java Message Service (JMS): By combining Java technology with enterprise messaging, the JMS API provides a new, powerful tool for solving enterprise computing problems via enterprise messaging. Enterprise messaging provides a reliable, flexible service for the asynchronous exchange of critical business data and events throughout an enterprise. The JMS API adds to this a common API and provider framework that enables the development of portable, message based applications in the Java programming language. Details under: http://java.sun.com/products/jms/index.jsp JDBC: JDBC technology is an API (included in both J2SE and J2EE releases) that provides cross-DBMS connectivity to a wide range of SQL databases and access to other tabular data sources, such as spreadsheets or flat files. The JDBC API is the industry standard for database-independent connectivity between the Java programming language and a wide range of databases. The JDBC API provides a call-level API for SQL-based database access. JDBC technology allows using of Java programming language to exploit "Write Once, Run Anywhere" capabilities for applications that require access to enterprise data. Details under: http://java.sun.com/products/jdbc/index.jsp XML: Extensible Markup Language. A simple, very flexible text format derived from SGML. Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web. Brief features are: Enables internationalized media-independent electronic publishing; a single format for a wide range of uses; provides the underpinnings of the Semantic Web, enabling a whole new level of interoperability and information interchange;Encourages industries to define platform-independent protocols for the exchange of data, including electronic commerce;Allows people to display information the way they want it, under style sheet control;Enables long-term reuse of data, with no lock-in to proprietary tools or undocumented formats. Details under: http://www.w3.org/XML/ XML Schemas: express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents. XSD is XML Schema definition language. Details under: http://www.w3.org/XML/Schema

Page 101: Business Process Integration

Business Process Integration 101

XSL: XML Stylesheet language, a family of recommendations for defining XML document transformation and presentation. It consists of three parts: XSLT, XPath and XSL Formatting Objects. XSLT: XSL Transformation, XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary. Details under: http://www.w3.org/TR/xslt XPath: a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. XPath is the result of an effort to provide a common syntax and semantics for functionality shared between XSLT and XPointer. The primary purpose of XPath is to address parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document. Details under: http://www.w3.org/TR/xpath XQuery: XML Query. The mission of the XML Query project is to provide flexible query facilities to extract data from real and virtual documents on the World Wide Web, therefore finally providing the needed interaction between the web world and the database world. Ultimately, collections of XML files will be accessed like databases. Details under: http://www.w3.org/XML/Query SOAP: Simple Object Access Protocol. A message-based protocol based on XML for accessing services on the Web. SOAP is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. Basiclly SOAP makes use of HTTP protocol to convey XML type messages. SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message. Details under: http://www.w3.org/2000/xp/Group/ Web Services: Web-based applications that dynamically interact with other Web applications using open standards that include XML, UDDI and SOAP. Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically

Page 102: Business Process Integration

Business Process Integration 102

conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Details under: http://www.w3.org/2002/ws/ RosettaNet: A non-profit subsidiary of the Uniform Code Council (UCC) that is devoted to standardizing interfaces for electronic commerce between supply chain partners. With B2B standards and integration as their common goal, RosettaNet's membership focuses on the high tech sector, while the UCC works with multiple industries, largely retail and grocery. RosettaNet has developed a conceptual model for defining the layers of XML standards required to support B2B integration between trading partners across supply chains. PIP: RosettaNet Partner Interface Processes. Defines business process between trading partners. PIPs fit into seven clusters or groups of core business processes, which represent the backbone of trading network. Each Cluster is broken down into Segments - cross-enterprise processes involving more than one type of trading partner. Within each Segment are individual PIPs. PIPs are specialized system-to-system XML-based dialogs. Each PIP specification includes a business document with the vocabulary, and a business process with the choreography of the message dialog. Details under: http://www.rosettanet.org/ ebXML: Electronic Business XML. An XML-based set of definitions for electronic transactions and business collaboration. Based on work done by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), ebXML provides descriptors for modeling business processes that includes the definition of software components. ebXML is designed for global interoperability and to facilitate the transition from older electronic data interchange (EDI) formats to the Internet. The ebXML specifications are jointly sponsored by OASIS and UN/CEFACT. Details under: http://www.ebxml.org BPML: Business Process Modeling Language. A modeling language for business processes from the Business Process Management Initiative. Unlike ebXML, which is geared to public interfaces, BPML is designed to model private processes. BPQL (Business Process Query Language) is a language designed to interrogate a business process management system (BPMS) for process information. Details under: http://www.bpmi.org