Process Integration (PI)

Purpose
With the usage type PI, you can integrate applications from one or multiple systems. SAP NetWeaver differentiates between the following areas:
Cross-system application integration, which does not focus on individual end-user actions. Applications can be company-internal, cross-company, SAP or non-SAP applications. The SAP NetWeaver usage type PI incorporates all functions that were previously a part of SAP Exchange Infrastructure (SAP XI). The modeling, administration, and automation of user-driven processes within SAP systems. From a technical viewpoint, a core function of the runtime is that you can save the state of a previously-modeled process and call it up at a later stage, if the process is to be continued as a result of a particular action or event. Since the execution of processes can be useful when integrating applications across system boundaries (without user actions), relevant functions within SAP NetWeaver are reused for this purpose. Together, the functions referred to here are known as Business Process Management.

Design Internal Company and Cross-Company Application Integration

Applications in a heterogeneous system landscape run on a variety of different systems and platforms.In the long run, it is not cost-effective to integrate all these systems by using point-to-point connections because developers and consultants would need to analyze the implementation in each individual system to get a clear overview of the entire process. As a result, the architecture for application integration in SAP NetWeaver focuses on storing the relevant application integration information centrally. The following figure provides an overview of how to integrate applications with SAP NetWeaver.

113318782.doc

Page 1 of 20

The knowledge required to integrate applications is known as collaboration knowledge. To develop and configure this knowledge centrally, developers and consultants work with the Integration Builder. Developers use this tool to define the design of cross-system applications in the Integration Repository. At a later stage, consultants configure this content in the Integration Directory, tailoring it to the particular system landscape of the customer. The System Landscape Directory acts as a central information database, from which the relevant products and systems of the system landscape can be queried for development and configuration purposes, and at runtime. At runtime, the Integration Server analyzes the data from the Integration Directory and the System Landscape Directory to process and forward messages from senders. In this way, you can develop applications that integrate SAP applications, external applications, marketplace applications, and middleware components from third-party suppliers. The architecture supports the integration of both internal company and crosscompany applications. For more information about architecture, see Overview.( see next section: BASICS)

Business Process Management

Along with functions from other usage types, Business Process Management covers the modeling, administration, and automation of both more complex cross-system (unbounded) processes and processes embedded in an SAP application within a system. SAP NetWeaver uses the same BPM runtime to execute both unbounded and embedded processes: In the context of unbounded processes, it is known as the Business Process Engine, in the context of embedded processes, it is known as the Workflow Engine.

113318782.doc

Page 2 of 20

Unbounded Processes
In the case of complex cross-system processes, stateless processing of messages with the Integration Server is sometimes not sufficient. Developers create integration processes in the Integration Repository to be able to correlate messages and execute more complex processes by means of loops. At runtime, the Integration Server executes these processes on the Business Process Engine and stores information about processes that have already been started and those that are not yet complete.

To send messages from an integration process, the Business Process Engine works closely with the Integration Engine of the Integration Server. When the Integration Server sends messages using an adapter, the Integration Engine works closely with the Adapter Engine. For more information, see Integration Processes (ccBPM).

Embedded Processes
Using workflows in SAP NetWeaver, you can define user-driven processes and connect existing SAP applications to each other. A simple example of a workflow is the automated processing of a leave request: An employee creates a leave request which is then sent to the relevant manager. If the manager approves the request, the employee receives a corresponding notification and the leave is recorded in the system. The manager can also reject the leave request. You model the process flow and subsequent steps of user actions by using a model, which the Workflow Engine processes at runtime. Unlike unbounded processes, processes defined by using workflows are embedded in an SAP system.

113318782.doc

Page 3 of 20

Integration
The usage types Application Server ABAP (AS ABAP) and Java (AS Java) are prerequisites for the usage type PI. The following tables provide overviews of other usage types used in conjunction with the usage type PI.
Development Infrastructure (DI)

Area Application Integration

Uses To connect J2EE applications to the Integration Server. To transport objects from the Integration Repository or the Integration Directory by using the Change Management Service (CMS). Uses To define and execute collaborative tasks in the portal. Collaborative tasks are less complicated than workflows and they are designed to meet the needs of employees who do not have a technical background but who want to simplify their day-to-day procedures. For applications that are not used on a regular basis, you can apply guided procedures, which guide the end user through the necessary actions step-by-step. The universal worklist in the Portal provides you with an overview of processes and enables you to track the status of workflows, collaborative tasks, and guided procedures.

Enterprise Portal (EP)

Area Business Task Management

113318782.doc

Page 4 of 20

Basics
Design, Configuration, and Runtime
The implementation of a collaborative process is split into three phases: During the design phase, you document the entire collaborative process and determine which interfaces are required. You can either define new system-independent interfaces to implement at a later point in time (outside-in development) or work with functions that already exist in the systems (inside-out development). In this phase you design the logical collaborative process by describing in a specific role the message exchange between the application components. This description is still not specific to any particular installed system (see also: Design Time). During the configuration phase, you configure your collaborative process for a specific system landscape. For example, you define conditions for the message flow and select design objects that meet your requirements. (See also: Configuration Time)

The configuration data is evaluated at runtime and controls communication. You can monitor the message flow by using a central monitoring. This three-stage process is reflected in the architecture:

Design time and configuration time each have a central data storage point providing an overview of all data that is relevant to the cross-component process: the Integration Repository and the Integration Directory respectively. To edit this data, you use a single tool, the Integration Builder. The content of the Integration Repository and Integration Directory is known as collaboration knowledge.

The Integration Server is the central distribution engine for messages at runtime. All systems that use the Integration Server to communicate with each other use this server to exchange messages. These systems are referred to as business systems at a logical level; within a specific system landscape they are called technical systems or communication parties. Using the configuration data from the Integration Directory, the Integration Server decides to which receiver or receivers it must send the message and whether a mapping needs to be executed beforehand. The Connectivity section describes the options available for connecting systems to the Integration Server.

113318782.doc

Page 5 of 20

Integration Server and System Landscape Directory

In the Integration Server, you save design-time objects in the Integration Repository and configuration-time objects in the Integration Directory. The System Landscape Directory (SLD) is an SAP product that enables you to describe products, software components, logical systems, and technical systems. The Integration Server accesses this information at design time, configuration time, and runtime. Relationship Between SLD and Integration Repository/Integration Directory Phase Design Time (Integration Repository) Configuration Time (Integration Directory) Objects Used in System Landscape Directory Products and software components as installable shipment entities Technical systems (for example, an SAP system), in other words components installed in a system landscape

The differentiation the Integration Builder makes between objects from a logical collaborative process and the installed system landscape is also made in the SLD. However, this distinction is not reflected in the product names (System Landscape Directory). See also: SAP System Landscape Directory in Exchange Infrastructure

113318782.doc

Page 6 of 20

Design Time
Communication in SAP Exchange Infrastructure is interface-based. That is, messages are generally created by calling an interface. SAP Exchange Infrastructure supports two approaches for implementing a cross-system process: Outside-In: You create the relevant interfaces for the cross-system process in the Integration Builder. These message interfaces are a programming language-independent description in XML. You use these message interfaces to generate callable interfaces (proxies) in target systems.

Inside-Out: The functions that are to be called using SAP Exchange Infrastructure already exist in the application systems. To be able to use an interface description of these functions in the design process, you import specific interface descriptions to the Integration Repository by using the Integration Builder (see External Programs and Descriptions at the end of this section). See also: Interface-Based Message Processing. You can also combine the two approaches. Regardless of the interfaces that you require for your cross-system process, you have to work simultaneously in the following development environments during design time: You use the Integration Builder to design and define all objects affecting message exchange (see below). In some cases you can use external tools and import objects to the Integration Repository. You implement message processing in your application program by using the development environment of your application systems.

Design Objects in the Integration Builder

The following graphic provides an overview of the design objects that developers can create in the Integration Repository by using the Integration Builder.

The Integration Builder allows you to edit the following objects by using the corresponding graphical editors (shown on the left-hand side of the graphic): Integration scenarios describe the communication between application components on a higher level of abstraction. Integration processes are executable processes on the Integration Server. See: Implementing Collaborative Processes.

113318782.doc

Page 7 of 20

Mappings are used to define structure or value mappings between messages that are exchanged between interfaces. You can define these mappings as graphical message mappings or you can import them into the Integration Repository as XSLT or Java archives. Context objects mask access to elements or attributes in the payload. For example, you can specify elements in a deeply nested message structure in conditions by using the short name of a context object, thus sparing you the long hierarchy path.

Data types and message types describe the structure of messages that are to be exchanged using message interfaces. Developers use message interfaces to generate proxies in application systems (the graphic only shows outside-in development). The entire content of the Integration Repository can be shipped. Together, these objects are referred to as Process Integration Content, abbreviated to XI content. Using a software component version from the System Landscape Directory you define the smallest possible shipment unit for a number of objects that belong together in the Integration Repository. SAP software component versions are also the basis for shipment units from application objects in SAP systems so that XI content and application content can be assigned to a joint software component version in the SAP system. See also: Software Logistics.

External Programs and Descriptions

SAP XI uses various XML standards (see also: Messages). The advantage of this is that you can reuse external programs and schema definitions. The following graphic gives an overview of the formats that you can import to and export from the Integration Repository.

You can import externally-defined integration processes as BPEL documents (Business Process Execution Language). As an alternative to graphical message mappings (which the Integration Builder uses to generate Java programs), you can also import externally-defined XSLT mappings or Java mappings to the Integration Repository, to execute at runtime (see: XSLT and Java Mappings). It is also possible to combine different mapping program types with each other (see: References Between Mapping Programs). You can import interface descriptions for IDocs and RFCs (see Importing IDocs and RFCs). You can import external definitions (DTD, XSD, and WSDL) and reuse message schemas from these documents within the Integration Builder.

113318782.doc

Page 8 of 20

Configuration Time
At configuration time you configure the cross-system processes for an existing system landscape. The configuration describes how the Integration Server is to process inbound messages and to which receiver or receivers messages must be sent. Various engines are involved in message processing on the Integration Server: The Integration Engine is the central runtime component; the Adapter Engine is the runtime component for adapter communication; the Business Process Engine is the runtime component for the execution of integration processes on the Integration Server. The Integration Server provides the following different services: The Adapter Engine and the Integration Engine both have inbound and outbound processing. For example, when a message is received, a check is performed to determine whether the sender is authorized to send to the Integration Server. The Integration Engine determines receivers in two steps: Logical receivers are determined by logical routing. Technical receiver information is defined by technical routing. In this way, the logical receiver is separated from the technical receiver, which simplifies the exchange of technical addresses (of an application server, for example) without affecting the logically defined superordinate collaborative process. Using the configuration, the Integration Engine determines whether a mapping needs to be executed. If a mapping does need to be executed, it determines it and calls the mapping program.

The Business Process Engine can execute integration processes. It communicates with the Integration Engine to execute mappings and to send and receive messages. The following graphic provides an overview of the execution of these services on the Integration Server and shows the information that is required from the Integration Directory: To keep the graphic simple, only the most important services are shown. Also, the graphic only shows the logical process flow of message processing. For example, the directory data is not actually read directly from the Integration Directory, but from a cache. Engine Configuration in the Integration Directory on the Integration Server

113318782.doc

Page 9 of 20

Since different customers have different requirements in an integration scenario, Integration Directory content is not shipped. It is the task of consultants and administrators to configure the data in the Integration Directory at the customer site. During configuration, you reference objects from design time in the Integration Repository (Integration Directory services that are required here are underlined): Scenarios group configuration objects together in the Integration Builder. You can also reuse the objects that you create for a particular scenario in other scenarios. To generate configuration objects automatically for a scenario, you can use an integration scenario from the Integration Repository as a template. To keep configuration open to as many different scenarios as possible and to support reusability, define the type of communication and the communication parties involved in two steps: You define the technical options of senders and receivers, as well as how they are identified, in the collaboration profiles. A profile comprises the following information: Particularly in the B2B environment, senders or receivers are identified by different methods (for example, by using a DUNS number or an EAN number). In SAP XI, you specify all the ways to identify a sender or receiver by using the communication party object. This means that later on in the configuration, you do not need to work with various different identifiers. Instead, you simply use the communication party you have created, since it contains all the ways of identifying a sender or receiver. This procedure is known as sender or receiver normalization. To describe on a logical level which address types communicate with each other, use services. A service can be a business system or an integration process, for example. You can assign multiple services to a communication party or configure a service without a specific communication party. The service does not yet specify any technical details regarding the message exchange. Depending on the type of service, you reference interfaces and one or more communication channels. The latter defines how you can address a communication party technically, for example, which adapters are required. This means that you can call all technical options and public sender and receiver interfaces in a collaboration profile. In collaboration agreements, you define the options described in the collaboration profile that are to be valid at runtime for a selection of senders and receivers. For this purpose

113318782.doc

Page 10 of 20

you select, for instance, for technical routing the communication channel, which is to be active for a group of interfaces (for example, a channel that is intended for all IDoc messages). Collaboration agreements control inbound and outbound processing. Logical routing works on services and is determined by using routing rules: In receiver determinations, you determine the service to which the message is to be sent. You can also define conditions that must be fulfilled for the message to be forwarded. In interface determinations, you assign a receiver interface to a sender interface.

The interface determination determines which sender interface belongs to which receiver interface. If a mapping is to be executed for this interface pair, you can select the mapping from the Integration Repository and assign it during interface determination. You load the actual mapping program from the Integration Repository before runtime and save it on the Integration Server. Together, the collaboration agreements and the receiver and interface determinations determine the receiver of a message, and whether a mapping needs to be executed.

Communication Parties and the System Landscape Directory

The System Landscape Directory (SLD) describes a system landscape. A system landscape comprises the following different types of system: Business systems, which name the logical receiver independently of technical properties. For example, a business system might be a client of an SAP system.

Technical systems with which the hardware of the system is specified in more detail (server data, and so on). Before a customer who uses SAP XI can begin configuration, he must first enter all the business systems and assigned technical systems in the SLD. Since the SLD just refers to the customers system landscape, he does not need to enter any business partner systems in the SLD in a cross-company scenario. The following table provides an overview of how you can use the communication party, service, and communication channel objects in the Integration Builder during configuration to identify the sender and receiver, and describe their technical possibilities. Collaboration Profile Objects and Their Use Object type Communication Party Use Identifies a company entity, which can later be configured as a sender or receiver. B2B communication builds on the identifiers specified here. The communication party is optional. Service for cross-company message exchange. You can specify interfaces and communication channels for integration services independently of a system. Service for exchanging messages with an integration process. Service for exchanging messages with a business system. The business system, the corresponding technical system, and the assignment between the two must be entered in the SLD. Defines the runtime component used to send and receive messages. The adapter type XI stands for proxy communication using the Integration Engine. All other adapter types stand for adapter communication using the Adapter Engine. SLD Entry? no

Service of Type Integration Service Service of Type Integration Process Service Service of Type Business System Service

no

no yes

Communication Channel

no

113318782.doc

Page 11 of 20

113318782.doc

Page 12 of 20

Implementing Collaborative Processes

Every type of business software is based on a real integration process, which is automated to accelerate integration processes and reduce costs. SAP XI concentrates on processes involving the exchange of messages between different systems. Examples of such processes and tasks are:
Order processing involving different systems Providing products on internet marketplaces Implementing B2B processes with a business partner by using the internet Setting up a new software system that needs to exchange data with existing systems

Processes of this kind that have not yet been automated are referred to in this documentation as collaborative or cross-system processes. SAP XI enables both topdown and bottom-up implementation of such processes.

Integration Scenarios
A total solution generally implements several cross-system processes, which you can handle separately. SAP XI allows you to document a cross-system process graphically, in the form of an integration scenario. The elements of an integration scenario reference the design objects (integration processes (see below), interfaces, and mappings) required for the collaborative process directly. However, this graphical description does not merely serve as a point of entry for the cross-system process. The associations described in the integration scenario are also used to generate and check configuration objects automatically in the Integration Directory. See also: Designing Integration Scenarios

Integration Processes
You can define integration processes graphically in the Integration Builder, in the same way as integration scenarios. They can be executed on the Integration Server and can handle the following tasks, among others:
Executing a central process involving multiple systems on the Integration Server Forwarding a message to a receiver following receipt or confirmation of other messages Collecting several messages to send to a receiver as one message

An integration process can receive asynchronous messages and send them (a)synchronously, in the same way as an application system. You can control this process by using logical conditions. The most important difference from normal message exchange is that the integration process status stays the same until the integration process is complete (in other words, integration processes are stateful). See also: Cross-Component Business Process Management.

113318782.doc

Page 13 of 20

Interface-Based Message Processing

SAP Exchange Infrastructure messages are based on XML. How can an application send a message of this type to a receiver? The idea is similar to a Remote Function Call (RFC): Communication with another system is encapsulated in an interface; the parameters of this interface are converted into a message. However, the significant difference between SAP XI and RFCs is that former always requires two interfaces for communication: One on the sender side and one on the receiver side. This has the advantage that the sender and receiver interfaces do not need to match exactly (loose coupling). The following graphic illustrates schematically how a message is sent to a receiver using a sender interface:
Multiple receivers can exist, the principle remains the same.

The graphic illustrates that for an interface A in a sender system, there is an interface B in the receiver system:
Interface B describes the inbound interface of an application. Interface A describes the outbound interface of an application.

At runtime, inbound interfaces give you access to a service that finds and returns customer data for an order. Outbound interfaces are used to call a service by means of the Integration Server.

Separation Using Outbound and Inbound Interfaces

To send a message, simply call the outbound interface (in the graphic: interface A) to which you want to transfer parameters for the request message. Furthermore, on the receiver side, you must implement receiver processing for the inbound interface (in the graphic: interface B). As indicated by the broken arrows, communication can only 113318782.doc Page 14 of 20

comprise the transfer of one message, depending on whether the communication is synchronous or asynchronous (also see: Communication Parameters). Outbound and inbound interfaces are used to separate (potential) senders and receivers. The interface parameters do not have to match for a message exchange to be possible (but a mapping is required at runtime if they do not). This enables various different senders and receivers to communicate with each other. In particular, this loose coupling also enables you to assign interfaces to each other when one side of the communication must not, or cannot be changed. For example, an outbound interface can be a message interface for calling an RFC in a 4.6C SAP system. In this call, the RFC has the role of an inbound interface. You assign outbound and inbound interfaces to each other at configuration time by means of an interface determination.

Interface Types and Runtime Components

The application does not need to perform any implementation to convert the parameters to or from a message. Depending on the type of interface, this task is performed by the following runtime component (see also: Connectivity):
In the simplified graphic, the XI runtime component is shown as part of the application system. This applies for proxy runtime, but depends on the adapter type in the case of adapters. Interface Type (Interface A or B or both) Proxy (from message interfaces) XI Runtime Component Proxy Runtime Programming Model

Proxies are executable interfaces in the application system. You can only create them in the system from message interfaces using the proxy generation functions. There are ABAP and Java proxies.
You can connect all interfaces that are already available in the system to the Integration Engine by using adapters. The adapters map between the XI message protocol and the relevant interface type. Where adapters do not call an interface (for example, if the message data originates from a database or file), you must configure an interface yourself.

IDoc RFCs, BAPIs Interfaces from external systems

IDoc Adapter An adapter from the Adapter Engine

If you use message interfaces, this is the outside-in approach; for any other interfaces, this is the inside-out approach (see: Design Time). In both cases, the Integration Builder supports the storage of the interface description in the Integration Repository. You create message interfaces there directly. You can import RFCs, BAPIs, and IDocs into the Integration Repository, and for external systems you have the option of loading message schemas in WSDL, XSD, or DTD into the Integration Repository. The interface description in the Integration Repository is decoupled from the implementation and this has the following advantages:
You can access the information about the message structure centrally. You can use the interface description for the design of integration scenarios, integration processes, and mappings at the same time as application development in the systems.

See also: Communication Parties (Case Examples).

113318782.doc

Page 15 of 20

113318782.doc

Page 16 of 20

Messages
The SAP Exchange Infrastructure message format is based on XML. Since a message in SAP XI can also have binary attachments, this documentation refers predominantly to messages in general and not specifically to XML messages.

XML Properties
XML (eXtensible Markup Language) enables you to describe data in a highly intelligible form. An XML schema definition specifies which elements can be used, which attributes these elements have, and how they are structured. More than one instance (a document that matches an XML schema definition) can exist for each schema. The following example of an instance illustrates that the elements in a schema are ordered hierarchically: <PurchaseOrder no="1811"> <ShipToParty> <Name>Rodney Washington</Name> <Address>200 S Wacker Drive Chicago IL 60606</Address> </ShipToParty> <Item> Bass Guitar No.14 </Item> <Status>Confirmed</Status> </PurchaseOrder>
These elements (for example, <Item>) are also known as tags in HTML.

You can describe the structure of a schema by using an XML schema. As well as the description of the structure of an XML document (elements, attributes, hierarchy), this language allows you to define simple and complex data types. Note the following difference:
XML schema language provides a series of language constructs that you can use to describe an XML schema. XML schema definition describes exactly one XML schema and is defined using the XML schema language. More than one schema instance can exist for an XML schema. A schema instance is an XML document; its structure and values are defined using a corresponding XML schema definition. The process whereby the system checks whether an XML document matches a schema definition is called validation. The terms XML instance or schema instance are often used instead of XML document. Whereas the term XML document is normally used to refer to a document on a file system, the storage medium is less important in the other two terms.

The W3C recommendation for XML schema dated May 2, 2001 comprises three parts: XML Schema Part 0: Primer, XML Schema Part 1: Structures and XML Schema Part 2: Data Types.

XI Message Protocol
The XI message protocol of SAP Exchange Infrastructure is based on the W3C note SOAP Messages with Attachments (for more information, see:

113318782.doc

Page 17 of 20

www.w3.org/TR/SOAP-attachments). The Integration Server expects a message that has the following structure:

The SOAP header of a message contains all the important information that the Integration Server requires to forward the message, while the payload contains the actual business data (such as <PurchaseOrder> in the example above). You can also append an unlimited number of attachments to the message before it is sent. Attachments typically comprise non-XML data, for example, pictures, text documents, or binary data. The information in the message header must have the correct format for the message to be processed on the Integration Server. The payload is not touched unless a mapping needs to be executed.

Discussion
Using XML technology has, among others, the following advantages:
XML is the standard exchange format in the Internet. Before this standard was created, there were practically no open exchange formats, which made communication in heterogeneous system landscapes very difficult. Further standards and tools now exist that make working with XML even easier, examples being XML Schema, XSLT and XPath. XSLT (eXtensible Stylesheet Language for Transformations), for example, enables you to define mappings for messages with different structures. XPath expressions enable conditions to be evaluated depending on values in the payload. Evaluations of this type are required for receiver determination in logical routing. As a standardized format, XML also enables you to connect to external systems. Once data from an external system has been converted to XML using an adapter, then it is a simple step to convert the data to other XML formats for other receivers.

113318782.doc

Page 18 of 20

Integration Server Engines

The Integration Server is the SAP Exchange Infrastructure runtime component for receiving messages and controlling how these messages are forwarded. During configuration of the XI system landscape, an SAP Web AS client is assigned the role of Integration Server. The following two engines work together in this client to control the message flow:
The Integration Engine is responsible for central Integration Server services, for example, routing and mapping. The Business Process Engine is responsible for executing and persisting integration processes.

Furthermore, the majority of the adapters run on the central Adapter Engine, which is installed on the J2EE Engine of the SAP Web AS, and which can take over inbound and outbound processing on the Integration Server from the Integration Engine. In this way, the central services of the Adapter Engine (for example, persistence), can be used by all adapters. See also: Connectivity.

Special Features of the Integration Engine

The Integration Engine can be deployed in various roles in different business systems. It comprises the following parts:
A messaging logic, which implements the XI message protocol. The messaging logic receives messages and forwards them on. In the process, it ensures that the services that are defined by the protocol, such as quality of service and status management, also apply to messages (including processing of acknowledgments). An integration logic, which is used to describe the central services of the Integration Engine: Logical routing, technical routing, mapping, and adapters.

The application logic in the application systems should be kept separate from these components of the Integration Engine. Application logic includes the selection of application-specific data or the updating of requests in a business system, for example. For example, the application program can use proxies to exchange messages by means of SAP Exchange Infrastructure in a cross-system process. Proxy objects belong to the application logic. You can only use the integration logic of the Integration Engine if you have assigned the role of central Integration Server to the Integration Engine in exactly one client. The following is an example of proxy communication by using the Integration Server:
You do not have to configure the Integration Engine as the Integration Server in client 010. This is just an example.

113318782.doc

Page 19 of 20

In other clients, you can configure the Integration Engine in such a way that its task is simply to send and receive messages. If no other client of the SAP Web AS sends or receives messages, the entire SAP Web AS is seen as the Integration Server, although technically speaking only the engines of a client actually take on this role.
The messaging logic for proxy communication is part of the SAP Web AS on either the sender or receiver business system. In adapter communication with the Integration Server, messaging is part of the Adapter Engine.

113318782.doc

Page 20 of 20