1. Managing EDI with SAP PI or SAP PO internally yourself
2. Installing a local EDI converter and connecting to SAP PI or SAP PO
3. Outsourcing to a fully managed EDI service provider

We will show you which EDI functionalities you can implement in your company with the respective solution and which questions decision-makers can use to help themselves in choosing the right solution.

EDI and B2B integration with SAP PI or SAP PO – What do I need to know?

SAP Process Integration (SAP PI) is a comprehensive software component that enables data exchange between the SAP system and internal and external systems. SAP PI uses various Java-based routing and integration mechanisms as well as various adapters that can be used to implement transport protocols and format conversions.

SAP Process Orchestration (PO) is an SAP PI installation variant (with different license models) that has been enhanced to include functionality in the area of “business process modeling and implementation”. In addition to the classic SAP PI capabilities of message routing, mapping and connectivity, PO also includes parts of SAP Business Process Management and SAP Business Rules Management.

In terms of EDI, the core technical functionalities of SAP PI and SAP PO are:

• Connectivity
• Mapping
• Routing

Under Connectivity, SAP PI offers a range of adapters that can be used to convert various message transport protocols. These include many protocols that are required for electronic message exchange with external partners, such as AS2, X.400, OFTP2, SFTP, RESTful Web Services, and so on. Mappings can be used to implement translations between SAP internal formats (for example, IDoc) and external EDI formats such as EDIFACT, XML, ANSI ASC X.12, and so on. Mappings can be converted using a graphical editor, based on XSLT, or using a Java program. Routing controls message delivery to different recipients based on information in the message.

All three solutions presented in the same way are based on these core functionalities of SAP PI or SAP PO, but differ essentially in the following factors in EDI operation or in the following questions that the decision-maker can ask himself:

• How much internal EDI capacity (i.e. personnel & EDI expertise) can I use for mapping, routing, 24/7 monitoring, troubleshooting and maintenance of the connections? Do I want to manage EDI completely internally or do I want to relieve my internal teams and outsource EDI?
• Which technical requirements does my EDI solution have to meet? Which document types, protocols, formats and legal requirements regarding electronic invoicing (e.g. XRechnung in Germany or FatturaPA in Italy) do I need for my B2B network?
• What EDI capabilities does my B2B network require? Do I need access to Value Added Networks (VANs)? Do I want or need to connect to Peppol? Do I have suppliers without EDI capabilities that I still want to connect to automated message exchange (with Web EDI?)
• How flexible or scalable do I want to design my EDI solution? Can I rely on a rigid implementation in the long term or do I want to become more resilient and future-proof with regard to the technical requirements?

If you know the answer to all these questions for your company, you will be able to make the right choice for your business. Keeping the questions in mind, we will now look at the three technical approaches for an EDI implementation in SAP PI and SAP PO.

1. Managing EDI with SAP PI or SAP PO internally

SAP PI and SAP PO are extremely complex and extensive software components that allow for internal implementation of some EDI functionalities. According to the point-to-point principle, automated EDI connections to individual partners can be established by appropriately qualified personnel.

However, one of the main challenges during implementation is precisely the complexity of the software. One does not get the proverbial hammer and nail in the hand, but a very extensive toolset. For the independent configuration and the ongoing operation of EDI connections via SAP PI or SAP PO, highly qualified employees with corresponding EDI expertise are therefore required. If smooth EDI operation is to be guaranteed 24/7, these employees must be available on a continuing basis.

Furthermore, not all required EDI functionalities (current and future) may be supported or require the use of additional solutions, as shown in the graphic:

SAP PI/PO handled in-house

If you want to implement EDI internally purely with SAP PI or SAP PO, you will therefore have to do without some functions (or implement them as a third-party solution), but you will also need highly qualified personnel, EDI know-how and sufficient resources to cope with:

1. Mapping and routing of all necessary connections
2. Ongoing maintenance of the connection parameters and regular renewal of certificates
3. Ongoing maintenance of mapping tables and industry internal practical knowledge about the implementation of special formats (e.g. VDA)
4. Ongoing coordination with the B2B partners and procurement of all necessary information (especially in the onboarding process)
5. 24/7 monitoring and troubleshooting

Incidentally, those who only want to work with SAP PI have to accept a major restriction – this only allows flat file formats via SFTP/SOAP/REST/HTTP protocols. If you want to use “classic” EDI formats (such as EDIFACT or ANSI ASC X12) and protocols (such as AS2 or X.400), you must have either a special package from a third-party manufacturer or the “B2B Add-on” from SAP – but this is only available with the SAP PO license (even if no other SAP PO functions are required).

The issue of X.400 costs should also be mentioned. If messages have to be transmitted to third-party networks that are subject to charges, these costs can be quite high. As an individual company, often only poor rates are available due to the relatively small amount of data being exchanged.

Internal implementation of EDI with SAP PI and SAP PO offers you a very high degree of functionality and flexibility. However, configuration, operation and maintenance also require the use of appropriate resources, which must be included in the total cost of ownership analysis. These costs must also be taken into account when using a local EDI converter, the option we present next…

2. Installing a local EDI converter and connecting to SAP PI or SAP PO

Another possibility is the acquisition and operation of a local EDI converter, which is connected to SAP PI or SAP PO. This is a software to be installed locally that converts documents from SAP internal IDoc format to partner format and vice versa.

Converter solutions are individually adaptable, but are potentially cost-intensive due to individually payable license costs for various functionalities, formats and upgrades in combination with long-term maintenance contracts. For example, support for protocols such as X.400 or services such as VAN connectivity must be purchased separately.

Local converter solutions must also be operated completely by internal teams, just as in the previous solution (implementing and operating EDI in SAP PI or SAP PO internally). This includes particularly time-consuming processes such as mapping, testing and 24/7 monitoring. This again requires appropriately trained employees.

SAP PI/PO with local EDI converter

It should also be considered that both the software itself and the individual mappings age. In other words, over time new releases of the converter will be published, which do not necessarily allow an upgrade from the existing version and mappings. This results in corresponding migration projects that have to be realised internally or with the help of an external consulting company.

3. Outsourcing to a fully managed EDI service provider

Fully managed EDI is a cloud-based EDI solution where a company is connected to a specialised EDI service provider via a single connection. This service provider then takes over all EDI functions and processes, depending on your company’s requirements.

If your company uses SAP PI or SAP PO, all you need for a successful connection to ecosio as your EDI service provider is the snap ecosio Bridge for SAP and its turnkey integration flows in SAP PI or SAP PO, which was especially created by SNAP Consulting.

Deep EDI Integration in SAP with snap ecosio Bridge for SAP and iFlow/ICO

In this solution the EDI service provider creates and ensures all technically desired EDI prerequisites, such as routing via various protocols, VANs and Peppol or conversion into all common and necessary formats, including legal requirements in the field of e-invoicing. Further, operation, 24/7 monitoring and partner onboarding (including partner communication) are also handled by the service provider.

The deep integration of the EDI functionalities into the SAP system also enables your business department to:

• Jump to the original EDI message for incoming messages, directly in SAP – without need for an extra login
• Jump to the generated EDI message for outgoing messages – again without extra login
• Track the EDI message status directly in SAP by changing the IDoc status of sent EDI messages to status 40 or 41 – depending on whether the recipient received the message or not
• Conduct a full text search of all messages and documents
• Benefit from automatic alerts/notification if messages are incorrect or could not be delivered

Updates, the ongoing certification of protocols and new SAP versions (such as SAP S/4HANA) are easily adopted and supported. Fully managed EDI offers companies the possibility to use all EDI functions without an expiration date – providing maximum EDI efficiency with minimum internal effort.

Summary

You now know the three possible technical approaches for implementing EDI on the basis of SAP PI or SAP PO and which criteria and questions you should use to select the most suitable one for your company. Essentially, you need to assess how much capacity you have internally to cope with implementing and operating an EDI solution.

Independent EDI implementation or the use of a local EDI converter enables a company to send and receive EDI messages, but requires a high level of internal effort, and highly qualified personnel. In addition, some functionalities may have to be purchased externally.

Outsourcing to a fully managed EDI service provider offers you all the EDI functionalities available with SAP PI and SAP PO but in a flexible and freely scalable way. The entire effort, from mapping and routing to monitoring and troubleshooting, is taken over by the EDI service provider, relieving internal teams.

Want more information?

Discover more about our updated product, ecosio.flow.

Do you still have questions about SAP PI data exchange or EDI with an SAP ERP system? Feel free to contact us, we would love to help you!

SAP ERP and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in several other countries.

Der Beitrag Alternative Solutions for EDI in SAP PI and SAP PO erschien zuerst auf ecosio.

• X.400 is a message transfer protocol similar to e-mail but over a dedicated network, often called a Value Added Network (VAN) in the B2B sector
• X.400 was adopted in 1984 by the CCITT (now ITU) and extended in 1988, with IPM84 networks remaining compatible with newer IPM88 networks
• X.400 has secured a niche in EDI message transmission, supported in Germany as BusinessMail X.400 and still used alongside protocols like AS2
• X.400 networks use mailboxes managed by message stores and transfer via message transfer agents, with structured addressing and improved security from a separate authenticated network

The simple answer to the question “What is X.400?” is that “it is a message transfer protocol – in principle very similar to e-mail, but over a dedicated network rather than the internet”.

Yes, although it is hard to imagine in this day and age, there are other networks that exist parallel to the Internet. In the B2B sector these networks are often called Value Added Networks (or VANs). Of these the X.400 network is probably the best known.

However, there is much more to X.400 than this, as we’ll explore in this article…

A quick review…

Before we go into the technical details, let’s turn back the clock a little: 30 years ago, in 1984, the Comité Consultatif International Téléphonique et Télégraphique (CCITT), now the International Telecommunication Union (ITU), first adopted X.400 as a standard. In 1988, the X.400 standard was extended. This distinction is still noticeable today, as some (sub)networks are still based on the old IPM84 (IPM stands for Interpersonal Messaging Standard, and 84 for the year 1984). Fortunately, however, these are largely compatible with the “newer” IPM88 networks.

The name IPM already indicates that X.400 should initially be positioned as a general mail or messaging system. At the same time, work on an e-mail system was already underway in the context of Internet protocols. The protocols SMTP, POP and IMAP – with the establishment of the Internet in our daily lives – then became established in the late 1990s as global standards for interpersonal messaging, i.e. e-mail. As we will see later, X.400 and Internet e-mail (i.e. SMTP/POP/IMAP) are relatively similar in their topology and mode of operation. However, X.400 is considered a much more complex protocol family, not least because of its additional functionalities.

While X.400 has been completely replaced by Internet e-mail in the interpersonal messaging sector, it has been able to secure a niche existence for the transmission of EDI messages. In Germany, access to the X.400 network is marketed by Deutsche Telekom under the name BusinessMail X.400 – formerly Telebox or Telebox400. Therefore the term Telebox is often still used today as a synonym for an X.400 mailbox. Besides AS2, X.400 is the most used protocol for the transmission of EDI messages today. While AS2 is not yet offered by every company for the transmission of EDI messages, the acceptance of X.400 for the exchange of EDI data can be described as very high.

Due to the not inconsiderable costs for the transmission of the messages – Deutsche Telekom still charges in kilobytes (!) – AS2 connections are increasingly in demand for medium to high message volumes. In order to save costs at low message volumes, it makes sense for SMEs and other supply chain organisations to enlist the help of an EDI provider. As providers purchase a higher volume of messages than individual supply chain businesses, they are able to achieve a better per-message cost. Suppliers can then pass these savings (as ecosio does) onto their customers. But this is a subject for another time. For now, let’s look further into the technical structure and functionality of X.400.

Structure of X.400 networks

As with Internet e-mail, communication takes place via mailboxes. An X.400 mailbox is managed by a Message Store (MS) and identified by a unique address. Messages are transmitted to a mailbox via so-called Message Transfer Systems (MTS) or Message Transfer Agents (MTA) Users access their X.400 mailbox via User Agents – i.e. client software. The following figure provides a simplified overview of the topology of X.400 networks.

X.400 Network Topology

X.400 has a two-tier domain structure: An ADMD is a so-called public service area. ADMDs are usually operated by telecommunications companies – such as Deutsche Telekom. Several ADMDs can exist in a country. A PRMD is a so-called private utility area and is managed independently by companies for better organization. The distinction between ADMDs and PRMDs is an interesting technical detail – but in practice it hardly plays a role any more. Today, a company usually operates a single X.400 mailbox for the exchange of EDI messages or a few if it is a large company and there is a functional separation (e.g. ordering and invoicing processes).

Addressing in the X.400 network

Each X.400 mailbox is identified by a unique address – just like Internet e-mail. X.400 addresses are semantically structured similar to SMTP e-mail addresses, but are somewhat more complex in notation and often longer. Let’s look at the following example to explain the attributes of an address and how to read them:

G=Max; S=sample man; O=sample company; OU=purchasing; A=X400EXAMPLE; C=AT

This example address would identify the X.400 mailbox of Max Mustermann, who works in purchasing at Musterfirma. The mailbox would be hosted directly in the Austrian ADMD X400EXAMPLE – without using a PRMD. The attributes used in this example

• C (Country name)
• ADMD (Administration Management Domain)
• O (Organisation name)
• OU (Organisational Unit Names)
• G (Given name)
• S (Surname)

are used very frequently in addresses. A more detailed overview of the use of addresses in networks is given in RFC 1685 or Harald T. Alvestrand’s X.400 Website (from 1995):

Deutsche Telekom also uses the attributes CN (Common Name) and n-id (User Agent Numeric ID) in its X.400 network (VIAT). Using these attributes can cause problems when addressing from/into an older IPM84 network (e.g. MARK400). The simplest workaround is to simply omit these attributes – the unique identification of the X.400 mailbox in the VIAT network can also be done without CN and n-id (if the parameters G and S are used).

Confirmation of message receipt

One feature – which is almost indispensable when transmitting EDI – is the notification of the sender that a message has been successfully received. X.400 knows two types of notifications.

• Delivery Notification (DN): is generated by the server that places the message in the mailbox of the recipient and transmits to the sender MTA. This means the confirmation is generated by the server (on which the X.400 mailbox is hosted) and transmitted to the sender. The negative counterpart of the DN is the so-called Non-delivery Notification (NDN) and is transmitted to the sender in case of an error.
• Receipt Notification (RN): can be generated by the recipient’s client software and is transmitted to the sender – in practice, the RN is hardly ever requested or supported in automated transmission. The negative counterpart of the RN is the Non-receipt notification (NRN).

The sequence is shown as an example in the following diagram.

X.400 Notifications

Although in practice the Receipt Notification (RN) has hardly any significance, with the receipt of the Delivery Notification (DN) it can already be assumed that the EDI system of the recipient has received the message – at least on a technical level. The sender is then usually informed of any processing problems with the message via e-mail or telephone.

Importance of X.400 for EDI today

The end of X.400 message transmission has often been predicted – not least because of the high costs. But it is still impossible to imagine the EDI sector without it. In addition to the principle (particularly prominent in EDI) “never touch a running system”, the security aspects are a major advantage: After all, it is a separate network, physically separated from the Internet. Every participant is authenticated, which reduces the potential for abuse compared to SMTP/email to a minimum.

If you want to use an X.400 mailbox for your EDI data exchange or would like to reduce your existing X.400 costs, contact us today. We are always happy to answer any questions!

Der Beitrag X.400 – What is it and Why is it Still Around? erschien zuerst auf ecosio.