SAP XI Adapters Cental and Local ABAP

Central AE is installed by default.

Any number of local AEs can be installed. The local AE needs its own instance of the J2EE engine. The local AE can reside on any remote hosts, and several local AEs can even coexist on the same host (even on the Integration Server host).

Many factors come into play when making a decision to use the central or local AE The primary reason for using a local AE is the proximity to the business system. This may be by choice (in order to optimize the performance) or because of miscellaneous technical / networking issues (e.g. Operating system dependencies or Firewalls).

Even when the AE is deployed locally, the configuration and monitoring is done centrally via the Integration Directory and Runtime Workbench, respectively. (as explained in one of the previous slides).

Technical benefits of using one or several local adapter engines:

mitigate the risks of having a single point of failure (SPOF). Indeed if the central AE is used exclusively, it becomes a SPOF (so is the Integration Server – J2EE stack).

Distribute the load of the adapters

All R/3 systems 4.6C and under can communicate using RFC and IDoc only. Therefore the RFC/IDoc adapter is necessary to integrate these systems with XI Even SAP systems based on WebAS 6.20 and above, still rely heavily on RFC/IDoc interfaces and therefore the adapter is necessary The RFC adapter enables you to use the functions of the Integration Engine in existing SAP system landscapes. It is used by SAP systems to connect to the Integration Engine by using the RFC interface. It supports SAP systems as of version 3.1x.

Many Mainframe applications interface via flat files over FTP or at the OS level. Some rely on a messaging tool such as IBM MQSeries (WebSphereMQ), based on JMS.

The file/FTP adapter enables you to exchange data with the Integration Server by means of a file interface or an FTP server.

The JDBC adapter enables you to connect database systems to the Integration Server. The adapter converts database content to XML messages and the other way around.

Database content can be read with any SQL statement. A special XML format is defined for content coming from the Integration Engine. This format enables SQL INSERT, UPDATE, SELECT, DELETE, or stored procedure statements to be processed. A message is always processed in exactly one database transaction.

The JDBC adapter connects to databases directly by handling SQL statements or procedures. Therefore it is not appropriate let’s say to connect to the database underlying an R/3 systemThe JMS adapter enables you to connect messaging systems to the Integration Engine.

JMS adapter is typically used to connect to a JMS provider such as IBM WebSphere MQ (MQSeries) or Sonic MQ.

The SOAP adapter enables you to exchange SOAP messages between remote clients or Web service servers and the Integration Server .Any interface which is exposed as a web service can be accessed via the SOAP adapter You use the marketplace adapter to connect the Integration Server to marketplaces. It enables messages to be exchanged by converting the XI message format to the marketplace format MarketSet Markup Language (MML) and the other way around.

The RNIF (RosettaNet Implementation Framework) Adapter supports RosettaNet, a standard used for data communication in the High-Tech industry.

The RNIF Adapter is based on the RosettaNet Implementation Framework (RNIF) version 2.0. SMTP (simple mail transfer protocol) is used to interface with most mail servers by sending and receiving emails.

The SAPBC adapter enables the coexistence of the SAP Business Connector and SAP XI The IDoc adapter comprises two parts, namely an adapter at the Integration Server inbound channel, and an adapter at the Integration Server outbound channel.

The plain HTTP adapter gives application systems the option of communicating with the Integration Engine and exchanging business data using a plain HTTP connection. Depending on the receiver system, outbound messages can be enhanced with certain information.
Their configuration is done centrally in the ID (as for all adapters) but the monitoring does not go through the RWB. There are specific ABAP transactions to monitor these adapters.
Regarding the connectivity to SAP systems please note that the RFC adapter is hosted by the J2EE adapter engine, while the IDoc adapter is hosted by the ABAP stack of the Integration Server.

It is important to understand that proxies and adapters are the 2 alternatives for connecting XI to an application system.

Typically for an existing system (any external system or even ‘traditional’ SAP systems that only communicate via RFC and IDoc), the interface semantics cannot be changed. Also in many cases a specific, proprietary wire protocol must be used. This is exactly the scope of adapters. This is also the premise of ‘outside-in’ integration or ‘a posteriori’ integration (cf next slide) .In the case of new SAP applications (ABAP or Java) the interface development process has changed. The interface is designed centrally in the Integration Repository. From the interface definition a proxy is generated in ABAP or Java. The proxy is deployed on the application system, and the business application is built around it. This is the premise of inside-out integration (integration by design).
A proxy is a fragment of code in ABAP or Java which serves 2 purposes:

Convert the data structures (ABAP or Java) into XML messages and vice-versa Establish connectivity with the XI Integration Server A proxy hides such technical details from the application developer.

It is important to note that for proxy communication, no specific adapter configuration is required.

However from the technical aspect, the proxy runtime itself resides on the adapter framework. The point is that there is no protocol conversion necessary for communicating with XI using proxies.