Different types of SAP communication
In another post we showed how basic configuration helps You to integrate with SAP R/3 system using IDOC document. However, there are several ways that we can communicate with SAP. In this article, We will shed some light on different types of communication schemes You may want to use in Your integration.
Basic settings of every SAP connection
First of all, We will try to explain some of basics terms You need to understand, if You want to create well-functioning integration with SAP.
- Application Server host – a host where SAP application is installed. It’s Your SAP server.
- Client – Client is defined as a “self-contained commercial, organizational, and technical unit within SAP system”. This is separation unit; data from one client cannot be seen by other clients. There are predefined clients when SAP installation is finished and SAP administrators can create new clients as well.
- Sap System number – or Sap instance number. It’s a two-digit number that identifies an administrative unit. This groups SAP components together.
- Gateway host – host where SAP Gateway (also called NetWeaver) is installed. Gateway is a development framework that allows communication between SAP system and external systems among other features. If there are no specific host for SAP GW, it’s Your application server host.
- Program ID – entity that helps SAP to route RFC call to external program to identify IP of the host, which should serve as a RFC server for this integration scenario. In other words: it helps SAP to find a server (IP address) hosting RFC interfaces. Once a given RFC or IDOC has given Program ID associated in SAP configuration, SAP will send these RFC calls or IDOCs to the server, which registered mentioned Program ID.
Interfaces for accessing data
Let’s focus now with high level overview what R/3 offers when it comes to data exchange. If You want to access SAP from external system, You have several ways that this can be achieved:
- BAPI (Business Application Programming Interface) – this is basically a method for manipulating SAP business objects or performing business tasks. BAPIs are stored as function modules. They are RFC-capable meaning that You will be able to access them, either through RFC or IDOC/ALE interface.
- RFC (Remote Function Call) – standard SAP interface used for SAP-SAP, SAP-legacy communication. There are several types of RFC types among which synchronous, asynchronous, transactional are the most popular and commonly used.
- IDOC (Intermediate Document) – this interface can also be used to exchange business data with external systems. From our perspective, the basic purpose of this is to carry out electronic data exchange with other systems (EDI IDOC type). In this case, IDOCs have EDI segment implemented containing business specific data. ALE IDOC is often used to exchange data between distributed SAP systems, eg. accounting, HR run on instance in HQ whereas material management,production is handled by instance located in manufacturing facility. In general, EDI is used for business-to-business scenarios whilst ALE is used in application-to-application scenarios.
How to connect
In order to access any of above interfaces Integration platforms such as Tibco, Mule, WSO2 use SAP Java Connector (or simply JCO). If You read previous SAP post on this blog, You already know that Mule expects few files to be downloaded and put to Your on-premise/cloud installation. The same applies to Tibco and WSO2. The architecture of JCO archive:
Microsoft BizTalk, on the other hand, uses Unicode RFC library that is shipped as librfc32u.dll file and some of supporting libraries (icu*.dll files). Both of above archive/library files provides Us a way to access SAP’s CPI-C interface and CPI-C is the real entry gate for SAP data.
So, depending on integration platform You use, the typical way to access and exchange data with SAP is to have supporting libraries (Microsoft BizTalk) or archives (WSO2, Mule, Tibco). It allows You to access CPI-C interface, and CPI-C allows you to access RFC, IDOC and… there You go!
You are ready to exchange data. Well, almost ready. R/3 has built-in security mechanisms that prevents external systems to execute RFC. There are several steps needed to be taken in order Your username will be able to execute RFC in SAP and send data to SAP or register its own RFC in SAP and receive data from SAP. Contact Your Basis team, if You have problems at this point.
Fortunately, both JCO and DLL files for MS based integration platforms allows You to turn on RFC tracing. It allows You to see underlying operations handled by Your access archive/lib, which happens to be the most powerful way of finding culprit while setting up integration environment.
Types of communication
When exchanging data with SAP, there are many ways to divide communication based on its type. The basic division is by direction of messages: Inbound and Outbound. You are reading article about integration with SAP written by integration developer, so from Our (integration platform) perspective messages are received (inbound) and sent (outbound). However, it’s very common to call Inbound and
Outbound interfaces from SAP perspective, so Inbound will be something coming from integration platform and Outbound will be something coming from SAP to Integration Platform. Have a look at the picture below, which shows this concept:
It may sound a bit strange at the beginning, but the more You talk with SAP people the more natural this will be for You.
- Inbound:
When We send data to SAP, We almost always do it in a synchronous way. Synchronous means, that We send data to SAP and expect an answer from SAP with business data. It’s standard synchronous communication, that You should know from web services, when You use GET option or querying database. You write select statement and database returns rows, that match Your query.
- Inbound Transactional:
As You learned, some of SAP interfaces are transactional. It means, that for some specific BAPIs, RFC, and IDOCs You have to confirm or commit the operation, which You started with calling RFC/BAPI/IDOC.
In the case of BAPI, it’s often generic BAPI called BAPI_TRANSACTION_COMMIT. This BAPI however, can “simulate” synchronous and asynchronous function based on WAIT parameter, that You set when calling it. In any way, You will use it and Your application will still receive an answer from SAP, the only difference will be visible in SAP.
In case of IDOCs, the whole process of creating IDOC in SAP is also transactional. First, IDOC is sent to SAP, Transaction ID (TID) is being generated and provided to a caller and, if there is no error returned by SAP, an IDOC is being confirmed.
It’s worth to mention, that during this process document data is not being created. Data is being created in second part of SAP workflow and this can be risky in some “data demanding” scenarios of integration. This “potential issue” and the usage of TID will be explained in another article, stay tuned!
- Outbound:
When it comes to outbound, things are a bit complicated as we need to use Program ID, and Program DI must be consistent on both sides of integration. Let’s consider following situation:
We have SAP instance, that needs to publish many types of IDOCs or other RFCs to different partners. The word “partners” is used to refer to Our integration platform and also other software that can actually receive some data from this instance of SAP.
If there are more than one partners, and this is common scenario in large organizations, how SAP should determine where it should send BATMAS type IDOC and where it should send MATMAS type? Same problem exists when only one type of data is about to be sent to external system. Have a look on picture below illustrating this:
There has to be mechanism to store that information inside SAP and this is what usually Program ID is used for.
If You want to receive anything from SAP, You have to do it with Program ID. No matter You receive an IDOC of registering an RFC in SAP You have to have Program ID set in Your configuration that is the same, as Program ID set on SAP side in order to properly receive data from SAP.
In case of RFC/BAPI, based communication Program ID is registered when Your application is started and connection to SAP is established. SAP routes RFC invocation requests, it receives internally to this connection and your application receives a data for the RFC it registered in SAP. In most cases, response to SAP is required and depending on the platform You use, there is a different way to provide it (eg. Payload/Vars in Mule, activity in Tibco, etc.)
- Outbound Transactional:
If it is an IDOC, You can have a Program ID called IDOC_Outbound_BATMAS03 set on SAP and on Your side. Once You Start, Your application developed to receive BATMAS03 from SAP new connection is established with SAP, and the IDOC_Outbound_BATMAS03 program ID gets registered by your application.
Now, SAP simply checks program ID set on its side and routes the IDOC to connection associated with this Program ID. Transaction is being generated and IDOC is then sent by SAP to Your application. If everything is fine with data transaction, gets first committed and then confirmed.
Conclusion
This article shows some of basic information, that You will need to establish simple communication with SAP systems over RFC based interface. The intention of this article was to explain it in a simple way for integration platform developers, who haven’t been familiar with concepts of SAP architecture.
