Test of the Scenario:

i. Trigger an Idoc from the corresponding ECC system manually using Tcode WE19 and ensure that it’s triggerred succesfully.

ii. Go to the Message Monitor and one successful messages can be seen that corresponds to the outbound request.

iii. The Message Log remains exactly the same as in the scenario 1. It’s just that MDN isn’t received from the partner this time around.

iv. Now go to the B2B Acknowledgements and the MDN status should be Success with the status ACK_NOT_SOLICITED which means that acknowledgement is not pending from partner.

Scenario 3:  AS2 Adapter (Sender) to SOAP Adapter – Asynchronous 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 Sender Side.

ii. Import the WSDL provided by the Client system which will work as the DT and MT for the receiver side.

iii. Create Async SI (for both sender & receiver)

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

iv. Create MM & OM.

v.  Create an Iflow in a usual way while configuring SOAP Channel on the receiver side.

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

vi. General: Define a specific Channel name for AS2 Sender 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

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

1. Expected URL-Path : One expected URL path is configured for one business partner. All interfaces Receiver Channels  from one partner use the common expected URL. This is basically the URL of the sender partner.

This can be in the format  auth/<Partner name>

1. Expected Message Id Left
2. Expected Message Id Right
3. Expected Sender’s AS2 name
4. Expected Own AS2 name
5. Expected subject

The parameters from a to f are all mandatory and need to be specified while configuring the Receiver AS2 channel from B2B Toolkit 1.0. These parameters have already been explained in the Scenario 1 and the literal meaning remain the same.

When any incoming message from any partner hits the PI box using AS2 gateway, it contains the expected URL and all the parameters listed from b to f. These details are used combindly to find the correct Receiver channel.

Incoming AS2 Message Details

1. Ambivalent Configuration: If checked then this parameter ensures that multiple channels have not been configured with exactly the same details so that an alert is sent whenever one AS2 incoming message is passed onto multiple AS2 receiver channels.
2. Duplicate Handling: If checked then the parameter ensures that an alert is sent based on the configuration whenever a duplicate message is processed.
3. Quality of Service: This parameter makes sure the processing mode of the message. In this scenario, keep it as Exactly Once (asynchronous).

The possible values are

• Exactly once
• Exactly once in order
• Best Effort

viii. Signature and Encryption: Now go to the Signature and encryption tab. Here the security of the incoming AS2 message is evaluated.

1. Verify Signature: If the incoming AS2 message is signed by the partner then it’s signature is verified using the partner’s public key certificates. These security certificates are uploaded in the Netweaver administrator Key Store.
2. Decrypt: If the incoming AS2 message is encrypted by the partner then it needs to be decrypted using client’s (self) private decryption algorithm. These security certificates are again uploaded in the Netweaver administrator Key Store.

ix.  MDN: Now go to the MDN tab. In this scenario, MDN is sent back to the partner by SAP PI. There is an option of signing this MDN with client’s security certificates to ensure the integrity of the message.

1. Send Option for MDN: In this scenario MDN is always sent asynchronously with respect to the original interface. If the send option is kept as “Immediate” It’s sent as soon as the message is received by a Receiver AS2 channel.

The other Send option is on “Application Acknowledgement”

While sending back the MDN following parameters can also be configured.

• Override URL for MDN: Whether MDN needs to be sent to some host other than the originator partner URL.
• Basic HTTP authentication: Whether the receiving partner has configured an authentication HTTP mechanism for receiving all incoming message (User Id and Password)
• Proxy server: Whether the MDN will be routed through any proxy server.

x. Modules: Now go to the Modules tab where only a standard module for entry appears.

xi. Save, activate and deploy the Iflow.

Test of the Scenario:

i.  Get a file triggerred by the partner which will pass through the AS2 adapter in PI system. Ensure that the partner uses the correct details of PI host and also uses the correct authentication details for logging onto the PI system.

ii.  After the successful connectivity test with the partner, when the AS2 message from partner enters the PI box, it can be monitored in the channel independent             logs in the monitoring home.

iii. Click on the AS2 adapter and see the logs below.

iv.   The entered message can be seen in below format with all the required parameters which would help it to find the correct AS2 sender channel.

v.    If the sender AS2 channel is found, the message is routed through it otherwise an error occurs that “No Channel matches incoming request”

vi.   Once the AS2 message passes through the correct channel, it can be seen in the Message monitoring.

vii.  On going through the message log, it is observed that the AS2 message passes through all the security, transformation and delivery steps.

viii.  Go to the B2B Acknowledgements and MDN status is seen with the status Success and status code as SENT_SYNC_POS which means Sent Synchronous and positive MDN.