Target Audience

This document will be useful for the all PI developers, who are going to build B2B Integration Scenario using AS2 adapters provided by Netweaver B2B Toolkit 1.0.

Scenario Introduction

It is very common for SAP customers worldwide to communicate with their business partners frequently using B2B integration. There are many third party vendors in the market such as Seeburger which provide a standardized platform for B2B integration. Understanding the emphasis of B2B integration and looking at the important role SAP PI is playing in the market as the Integration broker; SAP Netweaver has also joined the bandwagon and has recently launched one single platform to centrally manage the design, configuration, and execution of business processes running within and beyond the company’s boundaries.

This document is a technical know-how of configuring an AS2 adapter by using synchronous / asynchronous interface examples while sending data in RosettaNet format.

Note: The assumption while communicating with Business Partners in below mentioned B2B Scenario is that the Business partners must have the capability to accept as well as transmit the RosettaNet message in XML format using AS2 adapter.

Different Solutions

The XML message in RosettaNet format can be sent or received by PI over AS2 adapter by using any third party vendor AS2 adapter. But with SAP launching the B2B Toolkit 1.0 recently, it has become much easier to integrate the AS2 adapters in SAP PI as compared to importing some of the other third party vendor adapters earlier. Also with SAP providing the support for the tool in the long term, the option of using AS2 adapters using B2B Toolkit has become the automatic and the most preferred choice.

Use Case

The Integration Scenarios using AS2 Adapters can be configured either in Synchronous or in Asynchronous manner. Also the XML message passing through AS2 Adapter can either be outbound / inbound to PI. Keeping these scenarios in perspective, this document looks at 3 interface scenarios to cover the AS2 concept more clearly.

1. SOAP Adapter to AS2 Adapter  (Receiver) – Synchronous Scenario

2. IDOC to AS2 Adapter (Receiver) – Asynchronous Scenario

3. AS2 Adapter (Sender) to SOAP Adapter – Asynchronous Scenario

Prerequisite:

The prerequisite to use the AS2 adapter provided by B2B toolkit 1.0 is to have it available in PI. To achieve this, the corresponding SWCV (Software Component Version) for B2B Toolkit is imported from Service Marketplace and once imported successfully; the corresponding SWCV appears in ESR (Enterprise Service Repository).

Once the SWCV is available in ESR, corresponding adapters can be used during runtime in ECLIPSE / ID.

Scenario 1:  SOAP Adapter to AS2 Adapter (Receiver) – Synchronous Scenario

i. Import the dtd (data type definition) in the RosettaNet format as an External definition which will work as the Data Type and Message Type for Receiver Side.

ii. Create other ESR objects for the sender and Receiver sides.

1. DT (Sender)
2. MT (Sender)

     Note: Apart from the Sender DT & MT, Create Separate DT and MT for MDN (Message Delivery Notification). Here a MDN structure is created with a single      field which receives the plain text of MDN in XML format.

   c. Sync SI (Sender & Receiver)

     Note: The Sender and Receiver SI response use the common MDN structure.

     Note: The Interface pattern for both Sender and Receiver SI has to be Stateless (XI30 Compatible).

   d. MM

   e. OM

     Note: As the sender and receiver interface use the same response structure i.e. MT_MDN hence no message mapping between response structures has      been created.

iii. Create an Iflow in a usual way while configuring SOAP Channel on the sender side.

(The multiple recipient list or the branching appearing in the Iflow below can be ignored. This was specifically done to achieve the client requirement).

Note: The Iflow has to be a Non Specific Operation.

iv.General: Define a specific Channel name for AS2 Receiver Channel and choose following on the General tab.

1. Adapter Type:                           AS2 from B2B Toolkit 1.0
2. Transport Protocol:                 HTTP
3. Message Protocol:                  AS2

v.Adapter-Specific: Go to the Adapter Specific tab and within General tab, Specify following.

1. Recipient URL: The target AS2 Server URL of Business Partner for connectivity.
2. Provide basic HTTP authentication (User Id and Password) if required. It’s just like setting up any other HTTP authentication.
3. Configure the Proxy server details if required if the outgoing message needs to be routed through any Proxy server.
4. File Name: This parameter is nothing but specifies the AS2 message name. To uniquely identifying a particular type of message, RNIF PIP codes such as 3B12, 3A4 can be specified as File name.

   e. MessageID left / MessageID right: These parameter help build the unique Message Id to each incoming / outgoing message. AS2 message has a unique          structure and normally has “@” in the middle. Segments to the left and right of “@” are known as MessageID left and MessageID right respectively.

   f.Own AS2 Name / Recipient’s AS2 name: Each business partner involved in B2B communication is identified by a unique AS2 name. Own stands for the    Sender’s name while the Recipient’s corresponds to that of Receiver’s AS2 name.

     g. Own Email Address: This is the Sender Email Id on which MDN receipt is transmitted.

     h.Message Subject: This is one of the more important parameter used by the receiver to determine the post processing of the received Message. To      uniquely identify an interface subject, something like the RNIF PIP code such as 3A4, 3B12 can be used.

     i.Content Type: This specifies the content type of the message and generally is application/edi-x12.

     j.Charset Conversion: If checked, this parameter has to specify the Source and Target encoding algorithm.

     k.Dynamic Configuration: If checked, this parameter allows the AS2 channel to be dynamically overwritten by the dynamic parameters.

vi.Signature and Encryption: Now go to the Signature and encryption tab. This tab defines the outgoing message properties from size and security point of      view.

1. Compress message: If checked, this parameter compresses the AS2 message.
2. Signature: If checked, this parameters digitally signs the outgoing AS2 message. Security certificates are uploaded in Netweaver Administrator Key Store and used to sign the AS2 message.  Message can be signed with the sender’s Public key and the receiver can be asked to verify the AS2 message with this signature before it accpets the message into it’s system.
3. Encrypt Message: If checked then the outgoing AS2 message can be encrypted using one of the algorithm such as AES128 and with Recipient’s encryption method. To do so, receiver’s security certificates need to be imported in Netweaver Administrator Key Store. Receiver can use the same corresponding decoding certificates to decode the incoming AS2 message.

vii. MDN: Now go to the MDN tab. MDN is a Message Delivery Notification. This is basically a Technical delivery notification initiated by the Receiver and as per      the B2B Toolkit, it can be processed in following ways.

1. Asynchrnous: MDN is directed to a host asynchronously
2. Synchrnous: MDN is directed to the originating host synchronously.
3. NONE: MDN is not requested by PI and hence it is suppressed.

       In this scenario, MDN processing is kept as Synchronous and it is redirected to the sender host synchronously.

viii. Modules: Now go to the Modules Tab. The MDN returned from the business partner comes back to PI in a plain text format. As the PI can’t understand the message in a non XML format, hence it errors out during MDN Processing though the message is delivered to the business partner successfully.