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).

I1.png

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

I2.png

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.

I3.png

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.I4.png

   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).I5.png

   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.

I6.png

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.

I7.png

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

I8.png

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.


I9.png

   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.

I10.png

     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.

I11.png

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.

I12.png

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.


I13.png


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.


To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Lavanya L

    Hi Kanes,

    Thank you for this document. I am trying the first scenario and in the SOAP tool i am getting an error message stating that “<MDNText>An error occured during the AS2 message processing: Sender AS2 id XXXXXX is unknown.</MDNText>”

    I am not sure what needs to be maintained in ownAS2Name and own email-address. I have created the scenario in our test server.

    Regards,

    Lavanya

    (0) 
    1. Kanes I Post author

      Hey Lavanya,

      First you need to decide an AS2 name for the client for which you are trying to build the B2B Scenario with an external business partner. This can be a free text something like AS2_<Client name>.

      Similarly maintain a valid Email Id for the client Something like the administrator Email Id in the ownEmailAddress field.

      Just ensure to pass on these parameters to the external business partner in the real time scenario so that they can authenticate the incoming message based on these parameters from your client.

      Hope it helps.

      Cheers

      Kanes

      (0) 
      1. Lavanya L

        For the test purpose, i have maintained a ownAS2name like XXX_AS2 and have also maintained a valid e-mail addresss. But when i send the test message from SOAP UI tool, am still getting an error message in MDN text.

        Also in PI, i am getting this error message.

        Untitled.png

        (0) 
  2. Bibin VS

    Hi,

    Nice blog. From where can we get the DTD for the External definition, ED_MovementRequest? (Receiver AS2 side)

    Regards,

    Bibin

    (0) 
  3. Raju Rayapalli

    HI Kanes,

    Please provide the details what we need to maintain in Moudle tab to understand the non xml data received from recipient

    Regards

    Raju..

    (0) 
  4. Raj Kumar

    Hello Kanes,

    For inbound synchronous interface .. I am not able to keep External definition “.dtd” and MT_MDN ┬áboth. It is giving error while checking the interface:

    The screenshot of ESR SI Configuration:

    Please suggest.

    Thanks,

    Raj Kumar

    (0) 
    1. Manoj K

      Raj,

      This is just a warning , test it end to end it should work.

      The warning is because if you are using this service interface for proxy generation that wont work because you have different combinations.However you would never use this for proxy generations asthis related to MDN so you may ignore the warning.

      br,

      Manoj

      (0) 

Leave a Reply