Rosettanet/RNIF & XI/PI - Breaking the Code

[Shabarish_Nair]

Before I start with what really is the intention of the weblog, lets do a background study of Rosettanet and what it means to a XI developer. Our interest as a XI/PI consultant will focus on

- What really is the significance of Rosettanet?

- Where, Why and How can it be used?

The Significance, Where and Why? -  RosettaNet and the role of RNIF in XI

The PIP family - Read This

Now that we have a basic understanding of Rosettanet and what really does a PIP mean, lets address the question and the main intention of this blog - HOW?

As of today SAP has provided standard content or pre-delivered content for the Order to Cash/Order to Invoice cycle, so if your implementation is based on that, I'd say 'Lucky you' because from the PIP structures to Integration Scenarios, Message interfaces to mappings, SAP provides it all. Even the RNIF adapter configuration for the scenarios are available in the form of Communication channel templates.

So lets focus on the less unfortunate ones, shouldnt we?

As any XI developer does, we import the DTD of the particular PIP into the specific SWCV under a namespace and then we ... - STOP !!! Well that's not how it works in this case my friend.

The 'HOW' demystified, step by step;

The following will try to document as to what really is different while implementing RNIF scenarios compared to other scenarios in day to day XI transactions.

1. Namespace - Rosettanet in XI requires the namespace to be in a particular convention

a. http://sap.com/xi/RosettaNet/ PIP <PIP Code>_<PIP Version Identifier> OR

b. http://sap.com/xi/RosettaNet/<PIP Version Identifier>

2. Message Interface - The message interface name is nothing but the Business Action Code(BAV) but without spaces.

3. Business services under Party - They follow a norm of to be named as, PIPNote: To know more about the role of the parties involved in a message enxchange particular to a scenario, refer the Rosettanet implementaion guide for the particular PIP.

4. The Communication Channel Parameters -

a) Requesting Action - The BAV or your Message Interface name with spaces 🙂

b) Current Role - Your role ie the SAP systems role

c) Partner Role - The role of the system of the partner (non-SAP) who communicate via PIPs

d) Document schema specification - The exact name of the DTD document from Rosettanet which is the underlying base of your Message Interface. Eg. 2A12_MS_V01_03_ProductMasterNotification.dtd

e) Current and Partner business service code - The role suffix with Service i.e if role is Receiver, the business service code is Receiver Service

The above comes from what I can remember from past implmentation and R&D involving Rosettanet scenarios . In case any relevant points have not found their place here, I will make sure it is updated.

Further reference -

RSTK - 'Close Encounters' with the Rosettanet STK