Skip to Content

Rosettanet/RNIF & XI/PI – Breaking the Code

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 familyRead 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. PIP <PIP Code>_<PIP Version Identifier> OR

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

You must be Logged on to comment or reply to a post.
  • Hi Shabarish,

       Great blog! Thanks for the information you’ve placed here. This was useful when I was configuring my objects in PI.

       However, according to the receiver system contact, the RosettaNet message PI is sending has some lacking parameters. For example, it’s missing the following parameters below somewhere in the Service Header:





    Without these parameters, their system is unable to validate the RosettaNet message sent by PI, hence the error “UNP.SHDR.VALERR: Error validating message standard expected: PIDX received: null.”

    Any insights whether these are indeed required parameters and if not, why is the receiving system looking for this? I am clueless why PI is not generating these parameters (as I also cannot map them out from the Communication Channel details I’ve created).

    Thanks in advance for your support.


    • Hi Shabarish,

      I just found out that there’s  OSS note 870270 to fix this issue but only available for SP14 onwards. Basically, there are module attributes that must be added in the communication channel to generate the missing parameters.