Communication Using the Integration
Server
General
The interfaces that are used to exchange messages between two applications play a central role in enhanced communication using the Integration Server. The signature of these interfaces is required during the design and configuration of cross-application communication, in mapping, for instance, or the configuration of logical routing. Instead of having to search for the signature of these interfaces in the application systems involved in the communication, it is ideal if you can find all the necessary information in the Enterprise Services Repository. You use the Enterprise Services Builder to create this information directly or import it from the application system. You call the interface description (that is, attributes for the interface and its structure) in the Enterprise Services Repository, not the implementation.
In the context of the SAP NetWeaver usage type Process Integration, we often refer only to interfaces (for example, service interfaces or imported interfaces) and not to interface descriptions.
You always need two interfaces for message exchange: an inbound interface on the provider side and an outbound interface on the consumer side (see also: Interface-Based Message Processing). The following cases exist for this interface pair:
● Both interfaces are based on the same technology.
● The interfaces are based on different interface technologies.
● One side of the communication does not work with interfaces (communication using the file adapter, for example).
Depending on the
interface technology, there are different procedures for design,
implementation, and configuration. A general characteristic is the difference
between outside-in and inside-out (see also:
Introduction to
Service Development). The following overview of different interface
technologies is based around this difference.
Outside-In Development
In pure outside-in development, you work with service interfaces only (outbound and inbound), which you create directly in the ES Repository. Service interfaces are language-independent and based on the WSDL standard (WSDL: Web Service Description Language), an XML schema for describing network services. Using this description, you can generate language-specific proxies in Java or ABAP, which you can then use to implement the actual message exchange. The generated proxies are part of the application and forward calls to the Web service runtime that executes the message exchange with the Integration Server.
Proxies can also be used for point-to-point communication. However, point-to-point communication does not support all the protocol variants that are supported in enhanced communication, and the other way round.
As regards the various development phases, proxy generation is the transition from design time to implementation. The graphic outlines how a message is sent from an ABAP application to the Integration Server, using a consumer proxy. The message is processed according to the settings in the Integration Directory and is then forwarded to a runtime component at the receiver. From there, the message is forwarded to an ABAP application by using the provider proxy.
The graphic only shows one direction of communication, which is the case with synchronous communication, for example. The service interfaces in the ES Repository have corresponding attributes that indicate how they are used (for example, whether they are synchronous or asynchronous interfaces).
Inside-Out Development
In inside-out development, you import interface and message descriptions, or both, from already implemented functions in the ES Repository. You could also implement these first in the application system, but we recommend using service interfaces for new developments (see above).
Importing Interfaces from SAP Systems
A system often already contains functions that are to use the Integration Server to exchange messages with other applications. The ES Builder enables you to import interface descriptions in XML format for BAPI, RFC, and IDoc interfaces from SAP systems for this purpose. This has the advantage that you can access the signature and structures of the imported interface centrally. Furthermore, you can access the technical names of the imported interfaces using the input help (for example, in mapping or logical routing).
You can use RFCs, BAPIs, or IDocs to send messages to and receive messages from the Integration Server. Although the import function is only available as of release 4.0, you can use the RFC or IDoc adapter for application systems as of release 3.1I.
Importing External Definitions
In interface technologies from third-party vendors or for adapter types that are not based on interfaces, you can import message schemas to the ES Repository as external definitions. The message schemas can then be used to define mappings or service interfaces.
Combining Approaches
To communicate using the Integration Server, you need an interface for the outbound side and one for the inbound side. Many classic interface technologies do not make this distinction. If you want to call such a function in a current SAP system, you often work with an outbound service interface. If you have imported the message definition of the inbound side to the ES Repository, you assign the message definition to an operation of the outbound service interface. You can then generate a proxy for the consumer from this outbound service interface. Such cases combine the two development approaches.
In the example shown in the figure below, multiple receiver systems need to communicate asynchronously with one sender system:
● In this example, an SAP system does not allow proxy generation on the receiver side and there is already an RFC to be called. To be able to access the names (and schema description) of this RFC later during logical routing and mapping, you must import an XML description into the ES Repository.
● However, you can generate a proxy for the ABAP sender and the Java receiver. To do so, create two service interfaces in the ES Repository. The operations of the service interfaces each reference a request part of the imported RFC.
In this way, an outbound service interface can use the Integration Server to exchange messages with different receiver interfaces.