Biztalk 消息不可知的编排

Question

After moving away from Biztalk since BT2006, we're looking at bringing it back into the organization. One of the frustrations I had early on was when dealing wht HL7 and orchestrations, we needed to have a seperate orchestration for each ADT message type, even though the schema for each type is essentially the same, and each orchestration did exactly the same thing. Moving forward into the world of BizTalk 2010, has anything improved here? Is there a pattern I can utilize to use a single orchestration for all ADT types?

Answer 1

As I see it you have two possibilities here.

1. Treat the message as anonymous. This means your message is "un-typed" (you declare it as a System.Xml.XmlDocument type). Then your orchestration can interrogate the message to decide what type it is.
2. Create an envelope message whose body can be all of your possible message types (using the xsd choice group selector). Your orchestration then handles the envelope message type. With this approach you can declare the type contained in the body of the envelope by setting a value in the envelope header.

I would prefer the second one; while it is certainly more work (you need to wrap all your inbound messages in an envelope) it allows you to understand the what the message is by just looking at the envelope header. This means you can still route by message type if you need to.

Answer 2

HL7 messaging in BizTalk has remained roughly unchanged since the 2006 release. Because BizTalk defines a schema for each message and event type (eg ADT^A01, ADT^A03, ADT^A08) and not just for each message type (eg ADT, BAR, MDM), your mapping and orchestrations quickly become a mess.

Here is what I have done in the past to get around this limitation:

1. Allow messages to come in untyped to the orchestration. That is set the MessageType = System.Xml.XmlDocument. I found that generally, I am only interested in parsing out or updating a few elements, so I would just write a helper library with a few generic linq statements to get to the data that I needed. This way, I could write a linq statement that gets to PID-3 (Patient Id Number) and I would be able to use it consistently over any message or event type because PID remains the same. Likewise, I would use the same technique to update the message as well. This technique does not work great if there are large structural differences in the fields that you are looking to update or if you are looking to read/update a large amount of data.
2. Create master/canonical HL7 message type schemas. This takes a bit more work, but depending on how many message types you are looking to process, this can really pay off and is more consistent with how healthcare organizations think of their HL7 interfaces. In order to do this, you would need to define a new schema for a message type and include all possible segments for this message. So, instead of having multiple ADT types defined, you would roll all the possible variations for A01, A03, A04, etc. under one master schema. This will allow you greatly reduce the amount of mapping and parsing logic needed. Unfortunately, since this is not the HL7 accelerator's default behavior and will require some custom pipelines and orchestration logic to achieve. Basically, you will need to modify some properties to get the Accelerator to think that your new master message is valid.

For mostly pass-through interfaces, I would recommend technique #1. Otherwise, if you will be generating or needing to consume basically any message event in a canonical fashion, technique #2 can pay off in the long run.