skip to Main Content
SAP
Softzoll EDI solutions in interaction with SAP’s standard EDI functionality

The text below intentionally does not deal with theoretical implementations of SAP’s EDI interface technology; these are found both on the appropriate original SAP web pages on EDI and in the many derived products by the relevant suppliers. Instead, the focus here is on practical considerations for the introduction of the Softzoll EDI solutions with the standard EDI functionality and SAP ERP interfaces.

Fundamentally, two basic technologies that are suitable to connect EDI subsystems in carrying out EDI projects can be identified in the SAP cosmos. This fact allows an initial broad classification of SAP’s EDI interface technology into two varieties. Moreover, there are still other SAP components that come into consideration for interchanging external EDI-generated data; these are, however, very requirement-specific and are only used in exceptional cases for special solution scenarios (e.g., BAPI).

SAP EDI integration by RFC (asynchronous pairing)

This SAP component (RFC = Remote Function Call) has already been used for a long time to integrate EDI connections. Although already in use for years, this alternative may today still be the method of choice in quite a number of companies to import and export data for problem-free data interchange with third-party systems. Consequently, the RFC interface offers a proven possibility to interchange business process-relevant data with an upstream EDI system. If you can sweep aside all smoke screens and focus on core functionality rather than on all marketing buzzwords, the design of SAP’s RFC interface is transparent for application in EDI data interchange and is therefore, as is often the case, easy to implement and robust in daily use.

To put it simply, the upstream EDI system receives any type of external EDI data streams in different formats (EDIFACT, ANSI X.12, other IDoc versions, etc.) and syntactic variations and consolidates them to provide a uniform data structure in the standardized SAP IDoc format for import to the downstream SAP system. When forwarding data to an external EDI partner, SAP generates a uniform IDoc structure for each business process and provides it for import to the EDI subsystem. This then takes care of preparation for individual partners and forwarding via a defined communication path (AS2, OFTP2, FTP/sFTP, e-mail, etc.).

Generally, these EDI interchanges are carried out asynchronously, i.e., data are received, converted, and provided to the SAP system in an appropriate way over a defined communication channel through an intermediate stop (normally an EDI system or another integration component), or the process happens vice versa. In the type of delivery or reception of data between SAP and EDI systems, however, there is the possibility of establishing a synchronous data transmission with SAP (see below).

The RFC alternative of the SAP connection comes essentially from an asynchronous data interchange, i.e., normally the EDI system files the converted IDoc in a defined directory structure, so that SAP can import it from this structure; conversely, SAP files IDoc files there so that they can be received from the EDI system. The data transport can be organized over a mapped and authorized network folder, or an asynchronous communication protocol such as FTP or sFTP is used (appropriate connectors are generally part of the SAP standard applications). In connection with RFC Connect, mainly flat files or ASCII IDocs are used.

SAP EDI integration by tRFC (synchronous pairing)

The tRFC connection of an SAP system occurs, in contrast to this, over a synchronous communication protocol, normally via HTTPS. The advantage of this method is in that there is a sort of handshake between SAP and the EDI subsystem. The EDI system receives EDI data over the different external communication channels, generates the IDocs resulting from it, and triggers the appropriate tRFC components in SAP via HTTPS. In the subsequent delivery process, a unique message ID is generated per IDoc and sent to the SAP system during the process. The advantage of this procedure is that in case of failure, a failed delivery of an IDoc can be identified quickly and easily using the delivery ID. When sending messages from the SAP interface, the process functions in reverse sequence.

The tRFC connection is normally carried out on the basis of SAP XML IDocs. Another advantage of using XML IDocs is based on the fact that relevant XML schemas (*.xsd files) are provided by SAP for all planned business processes in the interface. They can be imported by a corresponding feature in the Softzoll solutions and deliver a blueprint of the maximum value of a business process defined by SAP. Even for parametered IDoc interfaces (additionally Z segments), there is a command in SAP to issue these adapted interfaces via XSD.

Practical Softzoll components for connecting SAP systems

The Softzoll solution range offers a series of options for requirement-specific implementation:

Connection via RFC
  • In most in-house systems, IDocs are exchanged via a defined index structure that can be supplied internally by a mechanism of choice.
  • For data processing center operations, Softzoll provides a free client (using an expanded FTP with transaction security, via VPN where required) that selects or completes the relevant indexes and is responsible for the automated data exchange with the data processing center. Alternatively, users can opt for a communication tool of their choice and complete the data exchange using their preferred communication channel (FTP, AS2, SMTP, OFTP2, etc.).
Connection via tRFC
  • All edibus in-house systems include an integrated module to connect to SAP via tRFC at no extra charge. The Softzoll data center client can also include a tRFC module on request.
  • The Softzoll data center client can also include a tRFC module on request. In this case, the client communicates with SAP synchronously via tRFC, whilst the connection to the data processing center is asynchronous via a secure FTP, and via VPN on request.
  • Many hosted SAP systems prohibit the installation of third-party systems—to connect to an external EDI system—in the respective data processing centers. In such cases, the Softzoll data processing center in Berlin implements a direct https connection in order to control the tRFC components in the SAP system without the aid of third-party components. In order to ensure that the transmission of IDocs meets even the most exacting security demands, a VPN tunnel can also be used for https transmission.
Back To Top