I have a BizTalk application which is setup to receive HL7v2 messages on an MLLP receive location.
I've setup parties in order to resolve based on the Sending Application (MSH.3) and apply our local schema to the incoming message type which is ORU_R03_23_GLO_DEF.
So the party is SUPPOSED to be converting the schema from
http://microsoft.com/HealthCare/HL7/2X#ORU_R03_23_GLO_DEF
To
http://mynamespace/HL7/2X#ORU_R03_23_GLO_DEF
However, whenever a message hits the port, it almost seems like the party is not being resolved because we receive an error as such
Error happened in body during parsing
Error # 1
Alternate Error Number: 301
Alternate Error Description: Schema http://microsoft.com/HealthCare/HL7/2X#ORU_R03_23_GLO_DEF not found
Alternate Encoding System: HL7-BTA
followed by another error:
The Messaging engine failed to process a message submitted by adapter:MLLP Source URL:0.0.0.0:11001. Details:The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.
The second error is somewhat expected based on the first, since no, there aren't ports subscribed to look for messages of type http://microsoft.com/HealthCare/HL7/2X#ORU_R03_23_GLO_DEF
There are ports subscribed to http://mynamespace/HL7/2X#ORU_R03_23_GLO_DEF
Is there anyway to check for sure if the Party is actually reading the incoming messages?
Has anyone encountered this happening with BizTalk Parties? If so, how was it resolved?
Lesson learned. Search for Hotfixes BEFORE doing anything else.
http://support.microsoft.com/kb/2892599
I installed both CU1 and CU2 for BizTalk 2013 and suddenly the parties are resolving as expected. In reading what is all included in the fixes, I'm unable to tell which of the fixes would have actually helped. In fact, it sort of makes me wonder if it was coincidence, seeing as with an OS wipe and fresh BizTalk 2013 install, everything worked fine.
Microsoft very briefly describes the process for resolving the schema of an inbound HL7 V2.X message here. So double-check that:
However, if your MSH.3 field only includes value for 3.1 and not also 3.2 and 3.3, then you also need to enable a setting on the BizTalk v2X pipeline components for partial name resolution:
Enable Partial Name Resolution For Sending Application
.As I mentioned in another answer, older versions of BizTalk (2006 R2 and 2009) require a hotfix for the issue described in KB article 977120 to make that setting appear/work properly.