B2B Integration Using Seeburger AS2 Adapter with PI 7.1 Ehp1 Applies to: SAP NetWeaver Process Integration 7.1x, Seeburger 2.1x Summary This article is about preliminary design & configuration aspects for B2B integration, while using Seeburger AS2 adapter with PI, after upgrade from SAP NetWeaver PI 7.0 to 7.1 Ehp1. Author: Anoop Garg Company: Infosys Technologies Limited. Created on: 10 July 2010 Author Bio Anoop Garg has 4+ years of experience as a SAP NetWeaver Technical Consultant with expertise in integration space using PI/XI, Seeburger & esoa implementation. 2010 SAP AG 1
Table of Contents Background Information... 3 Brief Overview... 3 Message Types... 3 Business Scenario... 4 Configuration... 4 Communication Channel... 4 Receiver determination... 5 Interface Determination... 6 Sender Agreement... 6 Receiver Agreement... 6 Issues faced... 7 Proposed Solution... 8 Sender Agreement... 9 Communication Channel... 9 Related Content... 10 Disclaimer and Liability Notice... 11 2010 SAP AG 2
Background Information This guide provides information for B2B integration done using Seeburger AS2 adapter with SAP NetWeaver PI 7.11. Here, instead of detailed technical discussion on AS2 adapter, guide majorly focuses only on design changes required during development of interfaces after SAP NetWeaver PI upgrade from 7.0 to 7.1 Ehp1. Also, where information is available otherwise, the guide will refer to the same rather than to repeat it. Brief Overview AS2 is a protocol which defines about how to transport data securely and reliably over the public Internet across different trading partners & customers in a B2B landscape. Using this protocol, adapters have been developed & delivered by various product vendors like Seeburger, Advantco etc. These adapters are based on the Adapter Framework and is executed by the SAP J2EE Adapter Engine, which facilitates with direct plug-in for SAP NetWeaver PI. Thus, it enables us to use AS2 protocol which can t be used with standard adapters provided by SAP. AS2 protocol is based on HTTP and SMIME & provides signing, encryption and MDN (Message Disposition Notification) conventions for data transfer (primarily EDI). Message Types AS2 uses two different message types: the actual payload message and the Message Delivery Notification (MDN). The payload message actually encapsulates an EDI file, thus it can be transmitted via HTTP. These messages being transmitted over HTTP can optionally be signed and encrypted by the sender. With the delivery of actual data, message may optionally request a MDN. The purpose of the MDN is to acknowledge the receipt of a payload message along with successful signature validations & decryption of data and hence ensure message has been transferred without modifications. An MDN can be optionally signed, so that the recipient can authenticate the sender of the MDN and check its integrity. Hence, it will confirm original sender that recipient got the actual message. For more details, please refer Standard Seeburger manuals for AS2 adapter. 2010 SAP AG 3
Business Scenario Here, for illustration, product activity bulk notification data for a particular trading partner has been created in backend application system. Now, same information needs to be sending across various trading partners over public internet. This integration between backend application system & trading partners has been done using SAP NetWeaver PI. Since, trading partners are located outside customer landscape, for transferring data securely & reliably over internet, receiver Seeburger AS2 adapter has been used with PI. For prototype, this business case has been made a just file transfer here to trading partner through Seeburger AS2 adapter. Note: I presume, readers are aware of AS2 configuration parameters & have gone through standard Seeburger manuals which provide detailed explanation on subject to understand things better. Configuration Now, to meet business requirements, following objects have been created in PI to integrate backend application system with trading partner and enable transfer of product activity data across partners. Communication Channel 2010 SAP AG 4
Receiver determination 2010 SAP AG 5
Interface Determination Sender Agreement N/A Receiver Agreement Now, for this channel used in receiver agreement, MDN mode has been set No MDN. With this mode & above configuration objects messages have been processed successfully in PI and delivered successfully to trading partner. 2010 SAP AG 6
Issues faced 1. Here, comes focus point, which reflects changes being done in configuration of B2B interfaces with AS2 adapter for PI 7.11 along with Seeburger Upgrade. For transmission of data, if we change MDN mode from No MDN to either synchronous/asynchronous, there is a failure of message at communication channel monitoring with below error message Message-Verarbeitung fehlgeschlagen. Grund: javax.resource.resourceexception: Fatal exception: javax.resource.resourceexception: SEEBURGER AS2: AS2 Adapter failure # Outbound configuration error: Failed to get configuration from DTREQUEST and DATABASE.., SEEBURGER AS2: AS2 Adapter failure # Outbound configuration error: Failed to get configuration from DTREQUEST and DATABASE.. Note: This error only comes when integration has been done using PI 7.1x & Seeburger 2.1x. With PI 7.0, making only change for communication channel in MDN mode, will not result in this issue or error. 2. Issue with signed MDN - A receiver AS2 Adapter has been configured with option sign MDN below. 2010 SAP AG 7
While using sign MDN with PI 7.1x & Seeburger 2.1x, it results in below error which states - MDN not authenticated Error while loading authentication certificate: java.lang.exception: Authentication certificate alias is empty. However, with earlier versions of PI & Seeburger, messages have been processed successfully without any issues. Proposed Solution 1. Analyzing it over period of time, we finally arrived at a concluding point which solves this issue with PI 7.1, after product upgrade. This requires creation of extra configuration objects A sender AS2 communication channel with protocol as reports A sender agreement using above communication channel. These objects are responsible for sending back MDN from trading partners to sender system & ensuring smooth data flow with use of MDN after PI upgrade. 2010 SAP AG 8
Sender Agreement Communication Channel AS2 Sender channel with message protocol Reports has been used for sending back MDN. Note: 1. The sender MDN channel should be created under the same party and communication component which is used in the receiver agreement of the receiver AS2 channel. 2. Any virtual party and communication component of the sender agreement for the MDN Report channel must be same as that of object details provided in header mapping of main receiver agreement. 2010 SAP AG 9
3. If same set of sender and receiver party pair found in more than two sender agreements of MDN AS2 Reports communication channel, it will still shows same error with main receiver AS2 communication channel. 4. If AS2 reports channel is in stop mode at communication channel monitoring, it will again show same error for main receiver AS2 communication channel, even though report channel exists now. 5. There should be a generic virtual party and component, if used throughout the integration with multiple trading partners across IT landscape. 2. To handle issue with signed MDN while using Seeburger 2.1x, we need to change the Handle Received MDN parameter within channel from No Action to Refer MDN to XI System which reflects change in configuration of parameters after upgrade. Ref SAP Note 1442196. Related Content SEEBURGER Adapters on SDN 2010 SAP AG 10
Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document. 2010 SAP AG 11