Sepasoft Help Documentation
Knowledge Base Articles
Training Videos
Online Training
Sepasoft Support
Module Updates
Ignition User Manual
Knowledge Base Articles
Inductive University
Forum
IA Support
[MES Enterprise Platform 2.1]
MES Platform 3.0
MES Platform 2.0
MES Platform 1.0
The Interface for SAP ERP module is an add-on for the Business Connector. It enables the Business Connector to connect to SAP and provides built-in templates for common data exchange scenarios.
This section describes the setup procedure for configuring the Interface for SAP ERP module, as well as the additional functionality added to the Business Connector when the Interface for SAP ERP module is installed.
t enables the Business Connector to connect to SAP and provides built-in templates for common data exchange scenarios.
Companies rely on many types of software to run their businesses. Whereas SCADA and MES systems typically provide functionality to control and manage the production process at the site level, Enterprise Resource Planning (ERP) systems provide company-wide functionality for business planning and logistics. For large enterprises, ERP systems typically provide a large collection of business management functions, which often include order management, accounting, Supply Chain Management (SCM), Customer Relationship Management (CRM), Human Capital Management (HCM), in addition to more production-focused activities like high-level production scheduling and operational management.
The ISA-95 standard defines five levels (0 through 4) to categorize activities in the production process. The standard includes the Functional Hierarchy Model, shown in the figure below. As the model illustrates, ERP systems typically encompass activities defined at Level 4, which are distinct from—and complementary to—those defined for an MES system.
To give some more concrete examples, an ERP system will typically perform the following:
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.
By a wide margin, the most popular ERP vendor, by install base, is SAP SE.
Colloquially speaking, "SAP" may refer to one of the following:
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
SAP SE's ERP offerings and technology have grown and evolved—both through development, as well as through acquisition—over the past 40+ years.
The classic SAP R/3 product, which launched in 1992, was replaced by ECC 5.0 in 2004 followed by ECC 6.0 in 2005. The majority of SAP users are still using SAP ECC 6.0, or one of its Enhancement Packages (EHP) 1 through 7, released between 2006 and 2013.
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:
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 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:
| Functional Module | Description |
|---|---|
| PP | Production Planning |
| PP-PI | Production Planning for Process Industries |
| MM | Material Management |
| QM | Quality Management |
| PM | Plant Maintenance |
| WM | Warehouse Management |
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.
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.
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).
BAPIs and Function Modules are called via the Remote Function Call (RFC) protocol. SAP allows for three (3) different calling types.
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.
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.
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.