Receiving a RNIF exception: PIP name specified does not match the PIP specification (error number 2005).

The PIP name specified does not match the PIP specification. This is the last RosettaNet error that tries to make my life a little bit difficult.

Fortunately, to date, Microsoft documentation has significantly improved, moving to DOCS was a good approach, and community members now have the ability to help to improve the product documentation. Nevertheless, some topics still have obsolete, scarce, or nonexistent documentation. One of these topics is Microsoft BizTalk Accelerator for RosettaNet.

I was receiving this error on the PublicResponderProcess orchestration. For those who are not familiar with Microsoft BizTalk Accelerator for RosettaNet (BTARN), this is a default artifact developed by Microsoft that composes a BizTalk Solution that handles PIP messages:

• When a responder receives a request message, BTARN routes the request message from the public-process orchestration to the private-process orchestration to the line-of-business (LOB) program. The responder requires the response service content from the LOB program to generate a RosettaNet response message back to the initiator. Many of the elements in the response message are populated using the values from the request message. As a result, you can incorporate a map in the responder private-process orchestration to help the LOB program generate the response service-content message in the required format.

The difficult part is to “debug”/track these errors to understand what is happening and why. The full error message in the event log was:

Source module:
PublicResponderProcess

Correlation information:
PIP Code : 3C4
PIP Version : V01.00
PIP InstanceID : 922731_20180912T050751
SourcePartnerName :
DestinationPartnerName:

Description:
Public Responder could not send an Async exception signal due to internal errors bellow:
RNIF Exception detail:-
Error code:UNP.SHDR.VALERR
Error Number:2005
Description: PIP name specified does not match the PIP specification.

Note: this same error can occur in previous or new versions of BizTalk Server.

Cause

Again, it was difficult to understand all the internal behaviors developed by Microsoft for BTARN, but basically, when you receive a PIP message, you will end up receiving 4 parts:

• The Preamble:
  • All RosettaNet messages must have a Preamble. It is specified by a DTD common to all messages.
  • The Preamble section of the MIME message contains elements that are global to the RosettaNet service and others that are common to the Service Header and Service Content; for example, the message standard and version used in the message.

<Preamble xmlns="http://schemas.microsoft.com/biztalk/btarn/2004/Preamble_MS_V02_00.dtd">
    <standardName>
        <GlobalAdministeringAuthorityCode>
            RosettaNet
        </GlobalAdministeringAuthorityCode>
    </standardName>
    <standardVersion>
        <VersionIdentifier>
            V02.00
        </VersionIdentifier>
    </standardVersion>
</Preamble>

• The Delivery Header
  • The delivery header is new in RNIF 2.0 and facilitates message routing through hubs. It contains the following attributes:
    • Elements for the sending and receiving of trading partner identities.
    • Message date and time stamp.
    • Globally unique tracking ID.

<DeliveryHeader xmlns="http://schemas.microsoft.com/biztalk/btarn/2004/DeliveryHeader_MS_V02_00.dtd">
    <isSecureTransportRequired>
        <AffirmationIndicator>
            Yes
        </AffirmationIndicator>
    </isSecureTransportRequired>
    <messageDateTime>
        <DateTimeStamp>
            20180912T050743.000Z
        </DateTimeStamp>
    </messageDateTime>
    <messageReceiverIdentification>
        <PartnerIdentification>
            <GlobalBusinessIdentifier>
                xxxx
            </GlobalBusinessIdentifier>
        </PartnerIdentification>
    </messageReceiverIdentification>
    <messageSenderIdentification>
        <PartnerIdentification>
            <GlobalBusinessIdentifier>
                yyyyy
            </GlobalBusinessIdentifier>
        </PartnerIdentification>
    </messageSenderIdentification>
    <messageTrackingID>
        <InstanceIdentifier>
            922730_20180912T050744**00**
        </InstanceIdentifier>
    </messageTrackingID>
</DeliveryHeader>

• The Service Header is specified by a DTD common to all messages. A separate DTD and/or XML schema for each message validates the message body.
• The Service Header helps identify the following items:
  • The PIP
  • The activity and the action to which the message belongs
  • The PIP instance
  • Information about the sender of the message
  • Information about the recipient of the message
  • The date and time at which the message was sent
  • Whether the message is a Test message or a Production message
  • Whether the sender is to be treated as an “unknown partner.”
• The Service Header format is fixed and independent of the specifics of the message contained in the payload. However, the Service Content may change based on variations in the business content.

<ServiceHeader xmlns="http://schemas.microsoft.com/biztalk/btarn/2004/ServiceHeader_MS_V02_00.dtd">
    <ProcessControl>
        <ActivityControl>
            <BusinessActivityIdentifier>
                Notify Of Invoice Reject
            </BusinessActivityIdentifier>
            <MessageControl>
                <fromRole>
                    <GlobalPartnerRoleClassificationCode>
                        Invoice Reject Provider
                    </GlobalPartnerRoleClassificationCode>
                </fromRole>
                <fromService>
                    <GlobalBusinessServiceCode>
                        Invoice Reject Provider Service
                    </GlobalBusinessServiceCode>
                </fromService>
                <Manifest>
                    <numberOfAttachments>
                        <CountableAmount>
                            0
                        </CountableAmount>
                    </numberOfAttachments>
                    <ServiceContentControl>
                        <ActionIdentity>
                            <GlobalBusinessActionCode>
                                Invoice Reject Notification Action
                            </GlobalBusinessActionCode>
                        </ActionIdentity>
                    </ServiceContentControl>
                </Manifest>
                <toRole>
                    <GlobalPartnerRoleClassificationCode>
                        Invoice Reject Receiver
                    </GlobalPartnerRoleClassificationCode>
                </toRole>
                <toService>
                    <GlobalBusinessServiceCode>
                        Invoice Reject Receiver Service
                    </GlobalBusinessServiceCode>
                </toService>
            </MessageControl>
        </ActivityControl>
        <GlobalUsageCode>
            Test
        </GlobalUsageCode>
        <pipCode>
            <GlobalProcessIndicatorCode>
                3C4
            </GlobalProcessIndicatorCode>
        </pipCode>
        <pipInstanceId>
            <InstanceIdentifier>
                922730_20180912T050744
            </InstanceIdentifier>
        </pipInstanceId>
        <pipVersion>
            <VersionIdentifier>
                V01.00
            </VersionIdentifier>
        </pipVersion>
        <KnownInitiatingPartner>
            <PartnerIdentification>
                <GlobalBusinessIdentifier>
                    XXXXXX
                </GlobalBusinessIdentifier>
            </PartnerIdentification>
        </KnownInitiatingPartner>
    </ProcessControl>
</ServiceHeader>

• And the Service Content:
  • Service Content is specified in individual PIPs. Each PIP has one or more business actions described by individual DTDs or schemas.
  • The payload of a RosettaNet Business Message—that is, the actual business content—is an XML message.

For this problem, the things you need to know about the PublicResponderProcess orchestration are:

• It will call the GetRuntimeConfig method on the GetRNConfig shape to retrieve the process/agreement configuration.

rnConfig = Microsoft.Solutions.BTARN.ConfigurationManager.RuntimeConfigGenerator.GetRuntimeConfig
  (destinationPartyID, sourcePartyID, pipCode, pipVersion,
    false, true
 );

• And it will call the IsActionMessageValid method on the ValidateMessage shape to validate whether the message matches any process or agreement active in the system.

rnConfig.IsActionMessageValid( inRNIFMessage, out exceptionInfo );

• This last method calls an additional method called ValidateActionServiceHeader. Here is a piece of the code:

...
if (propertyValue != base.GetPIPConfigValue("PIP_Name"))
{
   str = str + StringResources.GetString(StringResourceIDNames.rtcV11InvalidPipName);
}
...

• The GetPIPConfigValue(“PIP_Name”) comes from the RosettaNet process.

• The other comes from the Service Header message part in the BusinessActivityIdentifier element
• Both need to be equal – case sensitive!

My problem was that:

• The RosettaNet process name was: Notify of Invoice Reject
• and the Service Header was: Notify Of Invoice Reject

Solution

To solve this issue, you must.

• Ensure that the process name is equal to the BusinessActivityIdentifier element in the Service Header message part

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son. 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira