SAP Integration Guide

Document created by Adam Arrowsmith Employee on Apr 21, 2016Last modified by Adam Arrowsmith Employee on Dec 14, 2016
Version 7Show Document
  • View in full screen mode

This article provides a thorough overview for integration with SAP R/3/SAP ECC. SAP has a variety of products including newer cloud applications. This article pertains specifically to the on-premises SAP application. SAP is a complex ERP and with many integration options, local environment considerations, and SAP application customization to deal with. General SAP knowledge and customer-specific deployment expertise is required for a successful implementation because there are a number of setup items within SAP to enable connectivity. This knowledge is usually spread across a combination of roles, individuals, and teams: functional lead, application developer, and basis administrator (core system admin).



User Guide Articles

Here are some links to our user Guide, which you may find useful while using and configuring the SAP connector.



  • IDoc - IDoc is a popular data structure by SAP which is primarily used to exchange business/transaction data between SAP and external systems electronically (Official Documentation - IDoc Interface/ALE - SAP Library)
  • BAPI/Remote-enabled Function Module -  Interfaces developed with in SAP which can be triggered from a external system or with in SAP
  • (Official Documentation - SAP Library , RFC Interface - Connectivity - SAP Library)
  • SAPRouter - SAProuter is an SAP program that acts as an intermediate station (proxy) in a network connection between SAP systems, or between SAP systems and external networks (Official Documentation - What is SAProuter? - SAProuter - SAP Library )
  • SAP NetWeaver - SAP Netweaver refers to open technology platform that offers a comprehensive set of technologies for running mission-critical business applications and integrating people, processes, and information (More details -
  • SAP Netweaver Gateway - SAP Gateway is a framework that connects business users to SAP systems using consumer technologies, groupware, and mobile devices and is based on open standards (such as the Atom Publishing Protocol and OData) that offer simple services based on the REST principle (Official Documentation - SAP Gateway 2.0 – SAP Help Portal Page )


Understanding SAP Integration Options

There are several options for integration with SAP system. IDoc, BAPI/RFM, file extracts, and SOAP web services are some of the most common technologies widely used for interfacing with SAP. A recent addition, SAP Netweaver Gateway, can make your SAP business data accessible as RESTful resources. Based upon REST and OData principles, the SAP Netweaver Gateway exposes a uniform, stateless interface to any software system that can communicate using HTTP(S) and XML or JSON payloads. This approach is highly adopted in the B2C space.


While the integration use case requirements certainly factor into selecting the connectivity approach, the customer’s preference plays a huge part. Often customers will have policies or at least preferred approaches for integration with their SAP instance, as well as skills/knowledge in a particular connectivity option. For example, a customer may be an “IDoc shop” vs. a “BAPI shop”, or have decided to perform all integrations via a web services gateway.


StyleDescriptionTimingAtomSphere Approach and Considerations
Send IDoc to SAP via IDoc framework
  • “Intermediate Document”
  • Standard or extended (customized) formats
  • Exchange directly through SAP framework
  • Use SAP Connector
  • XML profiles
  • Submit IDoc directly to SAP IDoc importer
  • Atom must have direct connectivity to SAP (local install)
Receive outbound IDocs from SAP
  • “Intermediate Document”
  • Standard or extended (customized) formats
  • Exchange directly through SAP framework
  • Use SAP Connector
  • XML profiles
  • Receive IDocs from SAP real time/event based
  • Single listener process
  • Atom must have direct connectivity to SAP (local install)
IDoc import/export via file
  • Same as above but IDocs are communicated as standalone files
  • Scheduled SAP jobs export/import files
  • Use file-based connector such as Disk or FTP Connector
  • User Defined EDI profiles (can be difficult/tedious to configure by hand)
  • Atom may be local or remote depending on file location
  • “Business API” or “Remote-enabled Function Module”
  • Call SAP native API functions directly
  • Function may get or send data from SAP
  • Use SAP Connector
  • XML profiles
  • Can connect to BAPIs and public RFMs
  • It is common to create custom functions (a.k.a. “Z functions”) to augment/wrap standard functions to meet specific integration requirements
  • Atom must have direct connectivity to SAP (local install)
Web Services

SAP Gateway

  • REST, OData
  • HTTP Client / OData Connector
  • SAP NW Gateway Installation and Configuration (SAP)
  • Content development and publishing (SAP ABAP Development)
  • Network considerations applicable as for other webserservices
Web Services
  • Web service gateway
  • Often just exposing BAPI/RFM as web service endpoint- Synchronous request/reply
  • For SOAP, use Web Services SOAP Connector
  • For REST or XML-over-HTTP, use HTTP Client Connector
  • XML profiles
  • Atom may be local or remote depending on web service accessibility
  • SOAMANAGER configuration (SAP)
DatabaseDirect integration to the SAP database.N/A
  • This approach should not be used.


Selecting an Approach

There may be number of factors  for e.g. Customer's integration strategy, business requirements like security, performance, volume, ordered delivery, custom development & SAP shipped content etc which influence or determines an integration approach. Often customers will have policies or preferred approach matrix for integration with their SAP instance. In some cases skills/knowledge in particular connectivity mechanism also influence integration approach. For example, a customer may be an “IDoc shop” vs. a “BAPI shop”, or have decided to perform all integrations via a web services gateway. In recent years there has been inclination towards a web service (SOAP/REST) based approach for integration 


Architectural Considerations


BAPI and IDocs

The SAP connector supports connectivity via BAPI/RFM and IDocs. The connector uses the SAP JCo (Java Connectivity) and Java IDoc Class libraries, setup details are explained in depth here How to Configure SAP R/3 for IDoc and BAPI/RFM Connectivity.


A local atom is generally required because of following reasons:

  • SAP ERP is mostly locked behind customer's network and firewalls. Direct connection from outside is not allowed.
  • Transaction ID management for IDoc Listener which requires a local database for acknowledgment tracking.
  • There is no provision to install the prerequisite SAP library jars on the Dell Boomi Atom Cloud.


SAP Local Atom Reference Architecture


Outbound IDoc SAP Reference Architecture


Note that some customers may use SAProuter which acts as application level gateway, allowing connection from external systems in controlled and secured way. The SAP Connector can route requests to SAProuter.


Web Services (SOAP/REST OData)

A SOAP enabled web service may be exposed using existing BAPI/Functional modules or modeled and generated natively. For more information, please search for SAP Enterprise Services and SOAManager on SAP Help Portal – The central place for SAP documentation.


SAP Gateway is a framework that enables and exposes REST and OData based services which connects business users to SAP systems using consumer technologies, groupware, and mobile devices. SAP Gateway is offered as a separate add on which can be installed on either existing SAP business suite or separately as SAP Gateway Hub system - SAP Gateway 2.0 – SAP Help Portal Page 


Generally web service endpoints are exposed to outside world via reverse proxy or gateway. Since this approach does not requires specific jars, there a is no technical requirements of using a local atom. However such decisions are subjective to company's network and system security guidelines


SAP Connector Overview

The SAP Connector connects directly to your SAP NetWeaver-based application exchange data via BAPIs, Remote-enabled Function Modules (RFMs), and IDocs. You can browse the list of available BAPI/RFMs and IDocs available in your SAP system and auto-generate the request and response profiles to use in AtomSphere processes and maps.


The SAP Connector supports three types of actions:

  • GET - Used for BAPI/Remote Function Module (RFC type communication)
  • SEND - Used for Inbound IDoc processing
  • LISTEN - Used for Outbound IDoc processing or receiving IDoc


Additional notes:

  • The connector uses the SAP Java Connector (sapjco) library to communicate with SAP via the CPI-C protocol
  • The connector is SAP Certified
  • The connector requires an enterprise connection license to deploy
  • User Guide documentation: SAP Connector



There are a number of environmental and SAP application configurations required to perform the integration, including local Atom and SAP specific configurations. SAP configurations steps will require an SAP admin.


For complete details see How to Configure SAP R/3 for IDoc and BAPI/RFM Connectivity.


Common Integration Patterns




Sending an IDoc to SAP (SEND)


Receiving/Listening an IDoc from SAP (LISTEN)

  1. SAP configuration details are explained here:  How to Configure SAP R/3 for IDoc and BAPI/RFM Connectivity 
    •  IMPORTANT: Because there can be only one listener for a given Program ID, this means you must use a single “global” listener process to receive ALL IDoc types and then route accordingly within the process flow.
  2. The connector listener identifies itself to SAP using a unique “Program ID” value.
  3. The connector listens for outbound IDoc messages from SAP by registering itself as a client with the SAP IDoc framework.
  4. Upon receiving an outbound IDoc message, the connector sends an acknowledgment back to SAP.
    •  IMPORTANT: The connector immediately acknowledges the IDoc upon successfully receiving the IDoc message, not upon successful completion of the process execution. This means the process should be designed to be resilient in the event of any process errors because the IDoc event will not be resent by SAP.
  5. The connector checks the status of inbound IDoc in the table. If there is an entry for same Transaction ID (TID) with a "COMMITED" (success) status, then the IDoc is ignored to avoid processing duplicates.
    • A local database is required to maintain a table to track Transaction ID and status.
  6. The connector immediately executes the process with the IDoc document.
  7. The connector automatically sets a document property called SAP Connector > IDoc Type that you should be used to route the different types to specific maps or subprocesses.
    • Note that the Operation in the global listener process will still reference a specific IDoc Type but this is arbitrary. The Operation’s IDoc Type is not relevant for the listener and is only configured as such to generate the XML profile for use with mapping.



More details about the TID database are covered in How to Configure SAP R/3 for IDoc and BAPI/RFM Connectivity.




Executing a BAPI (GET)

  1. This method involves SAP connector executing a BAPI over RFC protocol.
  2. For every request sent, connector expects a response back from SAP.
  3. The method utilizes SAP JCo libraries which enables Java application to connect and communicate with SAP system and invoke Remote Function Modules.
  4. SAP JCo architecture is explained here - SAP JCo Architecture (Standalone Version) - Components of SAP Communication Technology - SAP Library.


Calling an SAP Web Service (SOAP/REST)

As explained in architectural consideration, a SOAP or REST web service could be easily exposed or developed on SAP system. The steps involved are out of scope of this article, however there are plenty of resources on SAP community and


8 people found this helpful