Navigating the maze of integration

[Former Member]

O.K.  So you want to integrate your application with SAP solutions.  You look around, see lots of unfamiliar terms.  NetWeaver, Web AS, XI, EP, RFC, RFM, BAPI, IDoc, JCo, NCo, SAPBC.  And you are a little confused.  “Where shall I start?”  You ask.

In this very first web log of mine, I will try to explain some of the basics of integrating an external application with SAP solutions.

First, you will need to figure out what SAP software product you are trying to integrate with.

SAP offers many business solutions, such as mySAP Customer Relationship Management (CRM), mySAP Supply Chain Management (SCM), mySAP Product Lifecycle Management (PLM), mySAP ERP.  One SAP solution may consists of one, and sometimes more than one, SAP software component(s) (or in other words, SAP software products).  For example, mySAP ERP solution mainly consists of SAP R/3 Enterprise – the successor of SAP R/3.  The easiest way to figure out what SAP software product you need to integrate with is to ask the folks who are running the SAP systems in your organization.

After finding out what SAP software product you need to integrate with, you will need to find out what version of the underlying technology layer the application software product runs on.  Every SAP application runs on a technology layer, which provides the application OS-independence, DB-independence, and handles the external communication.  This technology layer used to be called SAP BASIS.  Now, it’s called SAP Web Application Server (Web AS).  The versions of SAP BASIS/Web AS that are used by various SAP applications include:

- SAP BASIS 4.6D or earlier

- SAP Web AS 6.10

- SAP Web AS 6.20

- SAP Web AS 6.40, which is going to be generally available this autumn.

Why does this SAP BASIS/Web AS matter to you?  Because the version of the SAP BASIS/WebAS dictates the communication protocols that can be used.

SAP BASIS 4.6D or earlier consists of the SAP proprietary ABAP technology stack.  It only supports two SAP proprietary communication protocols:

- DIAG: for communication between SAPGUI front-end and the SAP application server

- RFC: Remote Function Call; conceptually similar to RPC, RFC is SAP’s protocol for cross-system communication.  It can be used for communication between SAP systems as well as between SAP system and non-SAP system.

 
The next version of the technology layer after SAP BASIS 4.6D is SAP Web AS 6.10.  It consists of a web-enabled ABAP stack.  In addition to the DIAG and RFC protocols, Web AS 6.10 natively supports Internet communication protocols such as HTTP, HTTPS, and SMTP.

Web AS 6.20 further enhanced the Internet support of the ABAP stack.  In addition, in Web AS 6.20, SAP integrated its J2EE application server (which had been a standalone product) into the Web AS.  So, since 6.20, Web AS has dual stacks:  the ABAP stack and the J2EE stack.  The J2EE stack is compliant with J2EE specification 1.2.

The SAP Web AS 6.40, as part of the SAP NetWeaver 04, is going to be generally released this autumn.  It contains numerous updates to both the ABAP and J2EE stacks, and will be competitive in the general application server market.  You can already find many information about it on SDN.

O.K.  Now we understand the history of SAP BASIS/Web AS.  What interface technologies does a particular SAP software product support?

Since currently the majority of the SAP solutions’ business logics are implemented in the ABAP stack, and it’s the integration with business logic that interests most people, so we will focus on the interface technologies offered by the ABAP stack.

The ABAP stack in all versions of the SAP BASIS/SAP WebAS supports the following interface technologies:

RFM: RFC-enabled Function Module

A RFM is an ABAP function module (similar to function or subroutine in other languages) that can be remotely invoked.  An RFM takes some parameters as input, and after execution, returns some output parameters.  You can view a RFM in the SAP system via transaction SE37.

BAPI: Business Application Programming Interface

A BAPI is a method of a business object defined in the Business Object Repository (BOR).  For example, in the BOR, you can find a business object called SalesOrder, which conceptually represents a sales order in the system.  A business object typically has several methods that can be used to read, create, modify a particular instance of the business object, or list instances of the business object matching certain selection criteria.  These methods are BAPIs.  Technically, a BAPI is implemented using a RFM.  But, unlike the non-BAPI RFMs, a BAPI is usually well documented, has nicer parameter names, and is supported by SAP for several SAP software releases.  You can browse Business objects and BAPIs in the SAP system using transaction BAPI.

RFM and BAPI are typically invoked synchronously.  The caller initiates the RFM/BAPI call, the called system (typically a SAP system) executes the RFM/BAPI, and returns the results back to the caller.  The SAP RFC protocol is used for RFM/BAPI invocation.

IDoc: Intermediate Document

The IDoc technology was invented by SAP in early 90s to enable asynchronous messaging-like communication between SAP systems, and between an SAP system and an external system. An IDoc instance can be logically seen as a data container that carries a set of related and somewhat self-contained business data to be exchanged between different SAP / non-SAP systems. An IDoc consists of a single control record, a number of data records which contain the actual business data, and some status records which indicate its processing status.  An IDoc data record contains the data of an IDoc segment. An IDoc consists of many data segments.  A data segment not only contains its own data fields, it may also contain nested children data segments. Together, all the data segments of an IDoc form a tree-like structure (a segment tree).  You can use SAP transaction WE60 to view the segment tree definition of a particular IDoc type.

Conceptually, the IDocs are exchanged between systems asynchronously.  The sending system composes the IDoc and transmits it to the receiving system (typically through a special flavor of the RFC protocol called tRFC).  As soon as the transmission is finished successfully, the sending system considers its job finished.  Upon receiving the transmitted IDoc, the receiving system should parse and process the IDoc accordingly, and handle any problems that may occur during the processing.

“O.K.  That’s interesting.  But, how can I use these interface technologies?  What programming language, what library or toolkit shall I use?”

The answer is that you have many choices.  The fore-mentioned interface technologies are not programming language or platform-dependent.  You can use these interface technologies from diverse programming languages and platforms, by choosing the appropriate integration toolkit.

SAP offers a range of integration toolkits (a.k.a connectors) for various environments.  SAP customers and partners can download these toolkits for free at the SAP service marketplace (http://service.sap.com/connectors).

For Microsoft environment, SAP provides the SAP .NET Connector (NCo).  Using NCo, you can easily invoke any SAP BAPI/RFM from any .NET languages.  NCo also provides support of submitting and receiving IDocs (but you will have to compose or parse the IDocs yourself).

With the release of the SAP .NET Connector, the SAP DCOM Connector, which had been offered by SAP, will be set end-of-life. There will be no further development of SAP DCOM Connector. Support and maintenance for the SAP DCOM Connector will be ceased by the end of 2004.

For Java environment, SAP provides the SAP Java Connector (JCo).  Using JCo, you can invoke any SAP BAPI/RFM from your Java code.  In addition, by using an JCo add-on called SAP Java IDoc Class Library (JCoIDoc), you can also easily compose, parse, send, and receive IDocs.

SAP also plans (please note, as any other plan, this is subject to change) to offer a J2EE Connector Architecture 1.0-compliant resource adapter in the upcoming WebAS 6.40 release.  Once it’s available, J2EE applications deployed on SAP WebAS will be able to use the standard JCA CCI API to invoke RFMs/BAPIs in the SAP system.

For C/C++ developers, SAP provides a C programming language-based RFC-SDK for all the platforms supported by SAP.  The SDK contains C header files and library.  With the RFC-SDK, C/C++ developers can write programs to invoke SAP RFMs/BAPIs, send and receive IDocs (RFC-SDK provides no support of composing or parsing IDoc).  Of course since it’s C, you developer needs to manage memory allocation and the other fun or boring details (depends on how you look at it 🙂 

SAP had offered a C++ based RFC/IDoc library in the past.  However, this product has long been discontinued.  So, please don’t use it anymore!

SAP Business Connector (SAPBC) was originally provided by SAP to enable B2B communication over Internet, but overtime some folks also use SAPBC for integration purpose.  On one side, SAPBC use JCo to communicate with SAP system and support RFM/BAPI/IDoc interface technologies; on the other hand, SAPBC support Internet protocols such as HTTP, HTTPS, FTP, SMTP.  SAPBC also has strong XML and mapping capabilities.  So, SAPBC can be used to expose RFM/BAPI/IDoc in a pre-WebAS SAP system as XML resources, or even Web Services. 

Please note that although SAPBC will continually be supported by SAP well into 2006, since many of its functionalities are or will soon be offered by SAP NetWeaver components (such as SAP WebAS and SAP Exchange Infrastructure – SAP XI), there will be no new functionality development for SAPBC.

SOAP Processor

Web AS 6.20 ABAP stack also natively contains a SOAP processor.  It supports browsing and generation of WSDL 1.1-compatible descriptions for the RFMs/BAPIs in the system.  It also supports synchronous calls of the SAP RFMs/BAPIs from external SOAP client using SOAP 1.1.  Please note that calling of stateful BAPI/RFM and exchanging of IDoc are not supported.

In WebAS 6.40, SAP will offer comprehensive Web Services frameworks in both the ABAP and the J2EE stacks.
 
“Good.  Glad to know that I have options.  Now, tell me what SAP NetWeaver is?”

SAP NetWeaver is the brand-name of the comprehensive integration and application platform offered by SAP.  SAP NetWeaver is or will soon be the technical foundation of all the SAP solutions.  SAP is also promoting NetWeaver to the ISV community and establishing NetWeaver as a viable platform option.  SAP offers Powered By NetWeaver (PBNW) certification to 3rd party ISVs who port their application to or develop their application on the NetWeaver platform.  More information about PBNW can be found at https://www.sdn.sap.com/sdn/icc.sdn?page=powered_by_netweaver.htm

“Sounds good.  But what are included in NetWeaver?  When will it be available?”

SAP NetWeaver includes several components, such as:

SAP Web AS – the application server platform (both J2EE and ABAP stacks)

SAP XI – for process integration

SAP Business Intelligence (BI), SAP Knowledge Management (KM), and SAP Master Data Management (MDM) - for information integration

SAP Enterprise Portal (EP, including collaboration) and SAP Mobile Infrastructure (MI) – for people integration

Many of the components of NetWeaver have already been available for some time.  The first syndicated release of NetWeaver – NetWeaver 04, which includes WebAS 6.40, EP 6 on WebAS 6.40, XI 3.0, BI 3.5, MI 2.5, MDM 2.0 –has already entered restricted shipment to select customers at end of Q1 ‘04, and is planned to be generally available at end of Q3 this year.  BTW, you can already download preview versions of SAP WebAS 6.40 and EP6 on WebAS 6.40 at the SDN download area.

“So, can I use XI for my integration project?”

Certainly you can. 

As an important component of SAP NetWeaver, SAP XI is SAP's central enterprise-scale platform for process integration based on the exchange of XML messages using flexible and open communications.  XI provides a technical infrastructure for XML-based message exchange to connect SAP components with each other, as well as with non-SAP components.  XI also delivers business-process and integration knowledge to the customer, in the form of SAP’s predefined business scenarios.  In addition, XI provides an integrated toolset for building new business scenarios by defining and maintaining integration-relevant information.

SAP XI 2.0 has been around for a while and has been shipped to customers.  SAP XI 3.0 is well on its way to general availability.  So, if you can get your hands on an XI system (unfortunately there is no free download available for XI at the moment.  It has to be licensed from SAP,) you should surely take advantage of the great integration capabilities offered by XI.

However, as you might already know, since XI is still a fairly new product, not all SAP customers have it.  In addition, because of the relative heavy footprint of XI, it might be an overkill for some not-so-complex integration scenarios.  In other words, although central hub-based integration using XI is certainly the future direction, point-to-point integration using the fore-mentioned integration toolkits probably still dominates at the moment, and will likely continue to do so in the near-term future.