Skip to Content

This is part 2 of my RosettaNet blog series.

Part 1 can be found here  (RNIF RosettaNet Adapter: Collected Experiences,  Traps and Hints Part 1).

 

Technical Structure of a RosettaNet message

The RosettaNet standard does not just define the structure of the BusinessContent (e.g. eInvoice) it also defines a technical framework how and in what form a message needs to be transmitted.

The actual business message is called “service content”. Besides this, a complete RosettaNet message consists of a Preamble, Delivery Header and Service Header.

All 4 parts together make up the actual RosettaNet message and are grouped together in a Content-Type = multipart/related message.

This multipart message is the payload that PI will transfer by the available transport protocols HTTP and HTTPS

More information on this can be found on the [RosettaNet | http://www.rosettanet.org/Standards/RosettaNetStandards/RosettaNetImplementationFramework/tabid/478/Default.aspx] Homepage.

 

This is an example of a typical message:


=_Part_125_1075081148.1239028714999Content-Type: multipart/related;      boundary=”–=_Part_124_1250133875.1239028714990″;      type=”application/xml”=_Part_124_1250133875.1239028714990Content-Type: application/xmlContent-Transfer-Encoding: binaryContent-Location: RN-PreambleContent-ID: RN-Preamble.9bbd60e022b811de81c600144fe5682c@sap.com<?xml version=”1.0″ encoding=”UTF-8″?><!DOCTYPE Preamble SYSTEM “Preamble_MS_V02_00.dtd”><Preamble><standardName><GlobalAdministeringAuthorityCode>RosettaNet</GlobalAdministeringAuthorityCode></standardName><standardVersion><VersionIdentifier>V02.00</VersionIdentifier></standardVersion></Preamble>=_Part_124_1250133875.1239028714990Content-Type: application/xmlContent-Transfer-Encoding: binaryContent-Location: RN-Delivery-HeaderContent-ID: RN-Delivery-Header.9bbd87f022b811de9a5b00144fe5682c@sap.com<?xml version=”1.0″ encoding=”UTF-8″?><!DOCTYPE DeliveryHeader SYSTEM “DeliveryHeader_MS_V02_00.dtd”><DeliveryHeader><isSecureTransportRequired>    <AffirmationIndicator>Yes</AffirmationIndicator>  </isSecureTransportRequired>  <messageDateTime>    <DateTimeStamp>20090731T050919.955Z</DateTimeStamp>  </messageDateTime>  <messageReceiverIdentification>    <PartnerIdentification>      <domain>        <FreeFormText xml:lang=”EN”>DUNS</FreeFormText>      </domain>      <GlobalBusinessIdentifier>314750852</GlobalBusinessIdentifier>    </PartnerIdentification>  </messageReceiverIdentification>  <messageSenderIdentification>    <PartnerIdentification>      <domain>        <FreeFormText xml:lang=”EN”>DUNS</FreeFormText>      </domain>      <GlobalBusinessIdentifier>968787285</GlobalBusinessIdentifier>    </PartnerIdentification>  </messageSenderIdentification>  <messageTrackingID>    <InstanceIdentifier>0afa02a3f70d00d10002k4f6</InstanceIdentifier>  </messageTrackingID></DeliveryHeader>=_Part_124_1250133875.1239028714990Content-Type: application/xmlContent-Transfer-Encoding: binaryContent-Location: RN-Service-HeaderContent-ID: RN-Service-Header.9bbd87f122b811deac6600144fe5682c@sap.com<?xml version=”1.0″ encoding=”UTF-8″?><!DOCTYPE ServiceHeader SYSTEM “ServiceHeader_MS_V02_00.dtd”><ServiceHeader><ProcessControl>    <ActivityControl>      <BusinessActivityIdentifier>Notify of Threshold Release Forecast</BusinessActivityIdentifier>      <MessageControl>        <fromRole>          <GlobalPartnerRoleClassificationCode>Forecast Owner</GlobalPartnerRoleClassificationCode>        </fromRole>        <fromService>          <GlobalBusinessServiceCode>Forecast Owner Service</GlobalBusinessServiceCode>        </fromService>        <Manifest>          <numberOfAttachments>            <CountableAmount>0</CountableAmount>          </numberOfAttachments>          <ServiceContentControl>            <ActionIdentity>              <GlobalBusinessActionCode>Threshold Release Forecast Notification Action</GlobalBusinessActionCode>              <standardVersion>                <VersionIdentifier>V02.01</VersionIdentifier>              </standardVersion>            </ActionIdentity>          </ServiceContentControl>        </Manifest>        <toRole>          <GlobalPartnerRoleClassificationCode>Forecast Recipient</GlobalPartnerRoleClassificationCode>        </toRole>        <toService>          <GlobalBusinessServiceCode>Forecast Recipient Service</GlobalBusinessServiceCode>        </toService>      </MessageControl>    </ActivityControl>    <GlobalUsageCode>Production</GlobalUsageCode>    <pipCode>      <GlobalProcessIndicatorCode>4A3</GlobalProcessIndicatorCode>    </pipCode>    <pipInstanceId>      <InstanceIdentifier>0afa02a3f70d00ae0002k3e2</InstanceIdentifier>    </pipInstanceId>    <pipVersion>      <VersionIdentifier>V02.01</VersionIdentifier>    </pipVersion>    <KnownInitiatingPartner>      <PartnerIdentification>        <domain>          <FreeFormText xml:lang=”EN”>DUNS</FreeFormText>        </domain>        <GlobalBusinessIdentifier>768787285</GlobalBusinessIdentifier>      </PartnerIdentification>    </KnownInitiatingPartner></ProcessControl></ServiceHeader>=_Part_124_1250133875.1239028714990Content-Type: application/xmlContent-Transfer-Encoding: binaryContent-Location: RN-Service-ContentContent-ID: RN-Service-Content.9bbd87f222b811dea8a700144fe5682c@sap.com<?xml version=”1.0″ encoding=”UTF-8″?><!DOCTYPE Pip4A3ThresholdReleaseForecastNotification SYSTEM “4A3_MS_V02_01_ThresholdReleaseForecastNotification.dtd”><Pip4A3ThresholdReleaseForecastNotification>  <fromRole>    <PartnerRoleDescription>      <ContactInformation>        <contactName>          <FreeFormText>Mickey Mouse</FreeFormText>        </contactName>        <EmailAddress>mickey@mouse.com</EmailAddress>        <telephoneNumber>          <CommunicationsNumber>+1234567890</CommunicationsNumber>        </telephoneNumber>      </ContactInformation>      <GlobalPartnerRoleClassificationCode>Forecast Owner</GlobalPartnerRoleClassificationCode>      <PartnerDescription>        <BusinessDescription>          <GlobalBusinessIdentifier>768787345</GlobalBusinessIdentifier>          <GlobalSupplyChainCode>Electronic Components</GlobalSupplyChainCode>        </BusinessDescription>        <GlobalPartnerClassificationCode>End User</GlobalPartnerClassificationCode>      </PartnerDescription>    </PartnerRoleDescription>  </fromRole>  <GlobalDocumentFunctionCode>Request</GlobalDocumentFunctionCode>  <thisDocumentGenerationDateTime>    <DateTimeStamp>20090527T030915.142Z</DateTimeStamp>  </thisDocumentGenerationDateTime>  <thisDocumentIdentifier>    <ProprietaryDocumentIdentifier>DocID73TO20090527001</ProprietaryDocumentIdentifier>  </thisDocumentIdentifier>  <ThresholdReleaseForecast>    <forecastGenerationDateTime>      <DateTimeStamp>20090527T050100.000Z</DateTimeStamp>    </forecastGenerationDateTime>    <GlobalTransportEventCode>Ship</GlobalTransportEventCode>    <isFinalForecast>      <AffirmationIndicator>Yes</AffirmationIndicator>    </isFinalForecast>    <PartnerProductForecast>      <ForecastPartner>        <GlobalPartnerReferenceTypeCode>Sold to</GlobalPartnerReferenceTypeCode>        <PartnerDescription>          <BusinessDescription>            <GlobalBusinessIdentifier>761237285</GlobalBusinessIdentifier>            <PartnerBusinessIdentification>              <ProprietaryBusinessIdentifier>7300</ProprietaryBusinessIdentifier>              <ProprietaryDomainIdentifier>Company Code</ProprietaryDomainIdentifier>              <ProprietaryIdentifierAuthority>Corporate Purchasing</ProprietaryIdentifierAuthority>            </PartnerBusinessIdentification>          </BusinessDescription>          <GlobalPartnerClassificationCode>End User</GlobalPartnerClassificationCode>        </PartnerDescription>      </ForecastPartner>      <ForecastPartner>        <GlobalPartnerReferenceTypeCode>Supplied by</GlobalPartnerReferenceTypeCode>        <PartnerDescription>          <BusinessDescription>            <GlobalBusinessIdentifier>314123852</GlobalBusinessIdentifier>            <GlobalSupplyChainCode>Electronic Components</GlobalSupplyChainCode>            <PartnerBusinessIdentification>              <ProprietaryBusinessIdentifier>C0WC600</ProprietaryBusinessIdentifier>              <ProprietaryDomainIdentifier>Vendor Code</ProprietaryDomainIdentifier>              <ProprietaryIdentifierAuthority>Corporate Purchasing</ProprietaryIdentifierAuthority>            </PartnerBusinessIdentification>          </BusinessDescription>          <GlobalPartnerClassificationCode>Manufacturer</GlobalPartnerClassificationCode>        </PartnerDescription>    (…)    </PartnerProductForecast>  </ThresholdReleaseForecast>  <toRole>    <PartnerRoleDescription>      <GlobalPartnerRoleClassificationCode>Forecast Recipient</GlobalPartnerRoleClassificationCode>      <PartnerDescription>        <BusinessDescription>          <GlobalBusinessIdentifier>314123852</GlobalBusinessIdentifier>          <GlobalSupplyChainCode>Electronic Components</GlobalSupplyChainCode>        </BusinessDescription>        <GlobalPartnerClassificationCode>Manufacturer</GlobalPartnerClassificationCode>      </PartnerDescription>    </PartnerRoleDescription>  </toRole></Pip4A3ThresholdReleaseForecastNotification>=_Part_124_1250133875.1239028714990


=_Part_125_1075081148.1239028714999–

Things to remember:

    • The PI adapter will take care on Service Header, Delivery Header and Preamble and assembling this in a multipart message

    • Service Header, Delivery Header and Preamble are created based on information that you enter in the communication channel

    • When receiving RosettaNet messages, the adapter will get the sender and receiver party, interface and namespace from the service and delivery header (this is the reason why naming those objects is so important)

 

*Receiving a RosettaNet Message *

To report this post you need to login first.

12 Comments

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

  1. Sreemannarayana Eamani
    I have been woking with RNIF reciever adapter on PIP details.I had provided PIP details for Invoice(P21)on communication channel provided by partner team.But am getting warning message in CC Monitoring as “Channel correctly configured with the following: Receiver Agreement: |*|Tibco|TIBCODV00|* Service: TIBCODV00
    WARNING: Service and channel PIP do not match”

    and no audit log display..
    Your Input’s are appreciated.
    Thanks in Advance.

    (0) 
    1. Markus Sehr Post author
      Hi,
      did you check the values for Receiver Party and Receiver Service are the same in Receiver Channel and Receiver agreement?
      If not, this might be the reason for the warning.
      I think technically it should not be an issue when the do not match. This might be applicable when you use a wildcard in your objects.
      Best regards,
      Markus
      (0) 
    2. Sreemannarayana Eamani
      Hi Markus,

               Actually scenario is SAP–>PI–>Tibco, from PI to Tibco am using RNIF Receiver adapter.In Rx channel PIP details i have provided Invoice(PIDX-P21 is standard code)and version 1.0 is used,hence the error in CC monitoring.Can you provide the ex PIP details configured for your requirement.
      Or Contact details of you..So I can contact you directly..

      Regards,
      Narayana.

      (0) 
      1. Markus Sehr Post author
        Hi Narayana,
        did you compare receiver agreement and channel.
        Party in agreement must excactly match Party in channel and the same for Service.

        Should you use a star in any of them but not in the other, this might be the problem.

        best regards,
        Markus

        (0) 
  2. Madina Shiela Andres
    Hi Markus,

       I must say this is a very great blog! Thanks for putting all the necessary information which I used to configure PI with. PI is now generating the RosettaNet message which is crucial to my project.

       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:


    PIDX


    1.0

    AND

    PIDX

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

    I checked the typical Rosettanet message you quoted above and it also does not have these parameters. 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.

    Regards,
    Madz

    (0) 
    1. Markus Sehr Post author
      Hi Madz,

      I am afraid you will have your problems with using the RNIF adapter in this case.
      The two fields you are referring to are not part of the RosettaNet Standard.
      As you can from the Tags this is a “FreeFormText” and “ProprietaryReferenceIdentifier” (i.e. something propietary)

      What your partner is using here is not RosettaNet but PIDX.

      When you check in the adapters, you see that SAP has RNIF adapters and CIDX adapter. The CIDX adapter is a RNIF like standard of the chemical industry. It only differs in certain fields – similar to your case.

      Your case is PIDX – a RosettaNet like standard of the petroleum industry (as far as I found out)

      I would suggest to search SDN/google for a PIDX adapter. Unfortunately I also don’t see much hope in adding a customized module in the adapter module chain that would solve your problem.

      Sorry that I don’t have better news.

      Best regards,
      Markus

      (0) 
      1. Madina Shiela Andres
        Hi Markus,

          Thanks so much for the advice. It gave much clarity on the issue. I 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. Thanks for the help!

        Regards,
        Madz

        (0) 
      2. Madina Shiela Andres
        Hi Markus,

          Thanks so much for the advice. It gave much clarity on the issue. I 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. Thanks for the help!

        Regards,
        Madz

        (0) 
    1. Markus Sehr Post author
      Hi Madz,

      please refer to note 870270 Question 4.
      You have to option to solve this:
      1) Follow the note above
      This has the disadvantage that you always need to remember to do this change when you patch PI because this would overwrite the change that is described in the note
      2) Work with Certificate Authentication
      You could setup Client Authentication with Certificates, i.e. the Client will sent a certificate that is mapped to a user in the target system
      However, if you do not have a knowledge on Certificate  Based Client Authentication in SAP, this way is more complicated than option 1

      Best regards,
      Markus

      (0) 
      1. Madina Shiela Andres
        Hi Markus,

          Thank you so much! I did not expect that the RNIF adapter would need so many patches. 🙂 I hope this is my last hurdle in the solution. How can I award you points? Thanks.

        Regards,
        Madz

        (0) 

Leave a Reply