SAP Connectivity

Interface for SAP ERP Module Overview

t enables the Business Connector to connect to SAP and provides built-in templates for common data exchange scenarios.

SAP Overview

SAP installations tend to consist of complex, multi-server architectures that require dedicated teams to manage and support. Uptime of an SAP system is of critical importance, as ERP systems are instrumental to the execution of business processes across the entire enterprise, from orders and scheduling to sales and HR.

The purpose of this section is not to be a comprehensive overview of SAP but rather to provide selected background knowledge relevant to deploying the Sepasoft Interface for SAP ERP Module.

Colloquially speaking, "SAP" may refer to one of the following: SAP SE – A large, multinational software company who distributes enterprise software One of a number of ERP products within SAP SE's software portfolio For purposes of this documentation, we will use "SAP SE" when referring to the company, and just "SAP" when referencing one of its ERP products

The latest enhancement pack, 8, was released in 2016 but requires a migration over to a new database backend called HANA, as described below.

More recently, SAP SE has been focusing on the development of its newer HANA technology.

Like the term "SAP" itself, "SAP HANA" may refer to one of the following: SAP HANA – SAP SE's new column-store database SAP Business Suite powered by SAP HANA – SAP SE's legacy ERP system migrated to run on the SAP HANA database SAP S/4HANA On Premise – A new ERP system that preserves existing ECC 6.0 functionality and interfaces but is built on top of the SAP HANA database SAP Business Suite 4 SAP HANA – The full name of SAP S/4HANA On Premise SAP S/4HANA Cloud – A new, more feature-limited ERP system built from the ground up on top of the SAP HANA database that supports OData and SOAP APIs

SAP Modules

Functionality within an SAP system is provided by modules. Broadly speaking, there are two types of Modules in an SAP system – Functional and Technical.

Functional Modules

Functional Modules are associated with business processes within an organization. Different organizations will install or use different combinations of Functional Modules, depending on their industry and how much functionality they want their ERP system to provide. Common SAP Functional Modules include the following:

Technical Modules

Technical Modules implement core SAP functionality that supports Functional Modules.

Examples of Technical Modules include ABAP, the programming language of SAP, and NetWeaver, the technology platform on which modern SAP installations is built.

There are many different ways of interfacing with an SAP system. Some require additional middleware and others require extensive configuration or setup. For platforms like Ignition that are built on Java, SAP provides a library called the Java Connector ("JCo") to enable bidirectional communication to an SAP system.

Function Modules

Not to be confused with Functional Modules, Function Modules are encapsulated ABAP code. They have documented interfaces for inputs and outputs, similar to a function signature. Typical SAP installations come bundled with hundreds of Function Modules, and developers can also create their own.

Function Modules can be configured to be "Remote-Enabled," which means they can be accessed from external applications via the Remote Functional Call (RFC) protocol.

Note to programmers: Function Modules can be thought of as SAP's version of a function. Similarly, Function Groups are akin to Python modules or Java packages. Designating a Function Module as "Remote-Enabled" is like declaring a Java function as Public.

BAPIs

Business Application Programming Interfaces ("Business APIs" or most commonly "BAPIs") are another form of encapsulated ABAP code. Whereas Function Modules are organized into Function Groups, all BAPIs are organized by and associated to a corresponding Business Object. BAPIs are standardized by SAP; unlike Function Modules, BAPIs tend to be consistent between versions, which tends to make them a safer interface technology than Function Modules.

Unlike Function Modules, BAPIs are always "remote-enabled," as they are intended to be called from external systems by design. Developers can also create their own BAPIs (typically called "ZBAPIs").

Note to programmers: BAPIs can be thought of as SAP's version of a method. Some BAPIs are like constructors or static methods in that they are associated with a class, while others are akin to instance methods, in that they are associated with an instance of a class (i.e., an object).

RFC Protocol

BAPIs and Function Modules are called via the Remote Function Call (RFC) protocol. SAP allows for three (3) different calling types.

sRFC

Synchronous RFCs (sRFCs) immediately return a response. These are ideal for requesting data (e.g., get production orders), as the data will be the most up-to-date and there is no risk of calling the RFC multiple times.

If an sRFC fails, the calling program will know right away, after which it can parse out the error message and either retry the call or pass it into a queue for manual reconciliation.

tRFC

Transaction RFCs (tRFCS) are processed asynchronously and include a unique Transaction ID. If an RFC is called with the same Transaction ID multiple times, SAP will ignore subsequent calls while still returning an “OK” status. tRFCs should be used for submitting data (e.g., posting a production order confirmation) where it is important that a call is not duplicated.

The calling program will not immediately know when a tRFC has been processed, only whether or not it has been received by the SAP system. Similarly, if a tRFC fails, the calling program will not be notified. Instead, the calling program may manually query the tRFC status by reading from the ARFCSSTATE table using the RFC_READ_TABLE function module.

qRFC

Similar to tRFCs, queued RFCs (qRFCs) are processed asynchronously and require a Transaction ID. They are built on top of tRFCs and have the added protection of ensuring that messages are processed in the correct order. This is important for executing sequences where order matters (e.g., posting a Goods Receipt prior to marking a Production Order as Technically Complete (TECO)).

As with tRFCs, the calling program will not immediately know when a qRFC has been processed, only whether or not it has been received by the SAP system. Similarly, if a qRFC fails, the calling program will not be notified. Instead, the calling program may manually query the qRFC status using a function module like TRFC_GET_QIN_INFO. Once the transaction has left the queue, its status may be queried like any other tRFC – i.e., by reading from the ARFCSSTATE table using the RFC_READ_TABLE function module.