Receiving a RNIF exception: PIP name specified does not match the PIP specification (error number 2005).
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 availability to help to improve the product documentation. Nevertheless, there are still some topics that the existing the documentation is obsolete, scarce or simply non-existent. 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 developer by Microsoft that compose 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 and why this is happening. The full error message in the event log was:
Source module:
PublicResponderProcessCorrelation 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 with a DTD that is common across 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 the routing of messages 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
- The delivery header is new in RNIF 2.0 and facilitates the routing of messages through hubs. It contains the following attributes:
<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 with a DTD that is common across all messages. A separate DTD and/or XML schema for each message validates the body of the messages.
- 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 could change based on the variance 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 that are described by means of individual DTDs or schema.
- The payload part of a RosettaNet Business Message—that is, the actual business content—is a message in XML format.
For this problem, the things you need to know about the PublicResponderProcess orchestration is that:
- It will call a method “GetRuntimeConfig” on the “GetRNConfig” shape that will get the process/agreement configuration;
rnConfig = Microsoft.Solutions.BTARN.ConfigurationManager.RuntimeConfigGenerator.GetRuntimeConfig
(destinationPartyID, sourcePartyID, pipCode, pipVersion,
false, true
);
- And it will call a method “IsActionMessageValid” on the “ValidateMessage” shape that will validate if the message received a match to any process/agreement active in the system
rnConfig.IsActionMessageValid( inRNIFMessage, out exceptionInfo );
-
- This last method calls an additional method call “ValidateActionServiceHeader”, here a piece of the code:
...
if (propertyValue != base.GetPIPConfigValue("PIP_Name"))
{
str = str + StringResources.GetString(StringResourceIDNames.rtcV11InvalidPipName);
}
...
-
-
- “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
