Improved monitoring of B2B scenarios running on SAP NetWeaver Process Orchestration – part 1: business scenario

If you use the business‑to‑business add-on of SAP NetWeaver Process Integration / SAP NetWeaver Process Orchestration in order to connect to your business partners and networks, you may benefit from the latest enhancements that we have shipped with SP02 of the B2B add-on, see announcement in blog B2B Add-on SP2 released. Also refer to SAP note 1911897 and B2B Release Notes SP2 on help.sap.com.

In the current blog series, I would like to focus on the improvements that we have introduced helping you to better monitor and track your B2B business transactions. Besides new capabilities that have been shipped within the local monitors of PI, we have introduced a new central monitor with SAP Solution Manager 1.0 SP10, the so called Message Flow Monitoring, which provides you an end-to-end insight into the correct closure of your A2A and B2B conversations.

The blog series is divided into three parts:

1. I will introduce the new features along a typical B2B scenario. In the first part which is covered in this blog, I will describe the business scenario. I won’t go in detail, I will only describe that much that is required to understand the monitoring features that I will introduce in the other two parts of the blog series.
2. In part 2 of the blog series, I will show you how to monitor the scenario by means of the local monitoring tools.
3. In part 3 of the blog series, I will show you what value the new Message Flow Monitoring of SAP Solution Manager will add.

Order to Invoice B2B Scenario

A trading partner sends you an EDI bulk message containing multiple EDI 850 Purchase Orders. You have agreed with the partner to use the AS2 protocol. Within your PI system you split the bulk message into individual orders, and forward them to your backend system. Once you have processed the orders in your backend system, you send corresponding EDI 810 Invoices to the partner.

For all messages that you exchange with your partner, the AS2 protocol mandates to return a Message Disposition Notification (MDN). The MDN is a technical acknowledgment indicating that the message has been successfully received by the receiving party, and that the receiving party has verified the integrity of the data exchanged.

To confirm the receipt of the EDI 850 and that the order was syntactically correct, you return an EDI 997 Functional Acknowledgment to your trading partner. The same applies to the EDI 810 that you send to your trading partner. Here you expect that your trading partner confirms the receipt via an EDI 997. See also blog about 997 FA (Functional Acknowledgement) Status Reporting in SAP PI 7.31 B2B add-on.

The sequence diagram in figure 1 below shows how this scenario is implemented in PI

Figure 1: Business scenario as sequence diagram

We have configured the following Integration Flows in the Process Integration Designer perspective in the SAP NetWeaver Developer Studio:

Figure 2: List of all Integration Flows

Integration Flow #1 (see figure 3) receives the bulk message via AS2 protocol, and routes the original message to the EDI separator adapter on PI outbound (receiver channel). Upon successful receipt of the 850 bulk message, the AS2 sender adapter signs the MDN and returns the same to the trading partner. The EDI separator receiver adapter creates a 997 FA and routes it to the EDI separator adapter on PI inbound (sender channel) of Integration Flow #3 (see figure 5). Furthermore, it splits the 850 bulk into individual 850 purchase orders, and routes them to the EDI separator adapter on PI inbound of Integration Flow #2 (see figure 4).

Figure 3: Integration Flow #1 – receiving bulk 850 message

Integration Flow #2 (see figure 4) receives the individual 850 orders. In the EDI separator sender adapter, the EDI 850 order is transformed into an XML representation of the 850. Depending on a routing condition, the message is sent to different backend systems. In our case, the lower path is taken. The message is mapped to the respective inbound interface and routed to the backend system via ABAP proxy.

Figure 4: Integration Flow #2 – routing the single orders to the backend system

Integration Flow #3 (see figure 5) routes the 997 to the trading partner via AS2 protocol. The trading partner confirms the receipt of the 997 with returning an MDN.

Figure 5: Integration Flow #3 – routing the 997 FA to the partner

Once the order has been processed in the backend system and a corresponding invoice has been created, the invoice is sent via ABAP proxy to PI. Integration Flow #4 (see figure 6) maps the invoice to 810 XML, and routes it to the trading partner. In the AS2 adapter, the 810 XML is transformed into EDI 810. The trading partner confirms the receipt of the 810 with returning an MDN.

Figure 6: Integration Flow #4 – routing the invoice to the partner

Integration Flow #5 sends the MDN from the partner to a file share (optional, not captured in swim lane).

Integration Flow #6 sends the 997 from the partner to a file share (optional).

Now that we have understood the business scenario and how it has been implemented in PI, let’s continue with part 2 of the blog series where I show how to monitor the scenario within the local monitoring of PI.