2
votes

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?

2
Can you check that you only have a single copy of the http://microsoft.com/HealthCare/HL7/2X#ORU_R03_23_GLO_DEF schema in BizTalk? It can fail to find a schema if there are multiple candidates that satisfy the namespace and root node.Sir Crispalot
I've checked that many times over, wiped and redeployed as well. Deleted and recreated the Parties as well.Bensonius
What version of BizTalk was it? Was it an in-place upgrade from BizTalk 2010 to BizTalk 2013? If so there are some know issues with that. See my response to this issue stackoverflow.com/questions/19869939/…Dijkgraaf

2 Answers

1
votes

Microsoft very briefly describes the process for resolving the schema of an inbound HL7 V2.X message here. So double-check that:

  1. Your party name matches the value in MSH.3
  2. The schema namespace under the Validation tab of the BTAHL7 Configuration Explorer exactly matches the schema deployed to BizTalk

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.

1
votes

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.