I placed an English version of this presentation on this site. Don’t hesitate to contact me if you have questions or remarks. Click here.
Cheers Gerben
I placed an English version of this presentation on this site. Don’t hesitate to contact me if you have questions or remarks. Click here.
Cheers Gerben
Last week I gave a presentation at the BTUG (NL), and I really enjoyed it. The presentation can be found here (note: it is Dutch). If you need more information or in English then please contact me.
Mijn artikel over BizTalk Accelerators en met name over de HL7 Accelerator in de zorg is verschenen in de Software Release Magazine (een IT blad in Nederland). Het artikel kunt u hier vinden. Wilt u meer weten, dan kunt u natuurlijk altijd contact met me opnemen.
(ENGLISH)
My article about BizTalk Accelerators and especially about HL7 Accelerator in the Healthcare appeared in the Software Release Magazine (an IT magazine in the Netherlands). You can find the article over here. Note: it is a Dutch article. Let me know if you are interested in BizTalk Server Accelerators and HL7.
Cheers Gerben
In my last post I blogged about this message. After fixing the input files, I still received this message. After some digging I noticed that the MessageType was empty (from ‘http://schemas.microsoft.com/BizTalk/2003/system-properties’). This field is used by the pipeline component BTAHL7 2.X Assembler. This field is not promoted because I’m using a generic Orchestration for routing HL7 messages via the ESB Itinerary to the MLLP Adapter (see earlier post about using a static port in an ESB Itinerary). In this Orchestration I’m receiving and sending System.Xml.XmlDocument for the message header, body and z-segment (MultiPart message). It is also not possible to write in this MessageType property, because it is read-only (in an Orchestration).
After the Orchestration the message is routed to a send pipeline and there I found another context property I can use: DocSpecType in ‘http://HL7Schemas.HeaderPropertySchema’:
I created a custom pipeline component for setting the MessageType property and setting this value:
This component is used as early as possible:
By creating the properties I can reuse this component in the future.
When you are working with HL7 schemas and you receive this message, then you should have a look at your incoming message. Probably it doesn’t match your Xsd. In my case it had to do with elements which don’t match the enumeration defined in the tablevalues_25.xsd (my input elements were empty). The BTAHL7 2.X Assembler is using the schemas for creating the Xml file, but also for validating. It really has nothing to do with your schema if it is deployed or not (in my case).
There was a failure executing the send pipeline: "BTAHL72XPipelines.BTAHL72XSendPipeline, BTAHL72XPipelines, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "BTAHL7 2.X Assembler" Send Port: "SendPortMLLP" URI: "ip-address:port" Reason: Body schema is missing
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I receive a flatfile HL7 message with the next records: MSH, EVN, PID and PV1. This message goes thru the pipeline component BTAHL7 2.X Disassembler. After the disassembler the BizTalk message contains 3 message parts: MSHSegment, BodySegments and ZSegments (which is empty in my case).
To use this message in an Orchestration you have to define a message as a multi-part message with these three parts. If you don’t do any processing in your Orchestration then you can use System.Xml.XmlDocument as message part type (it is only a reference).
You have to define these parts in the right order, so MSHSegment, BodySegments (with “Message Body Part” set to True) and ZSegments. If you don’t define these in the right order, you will receive an xlang/s error in the EventLog:
xlang/s engine event log entry: Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘MyCompany.MyOrchestration(da177201-2c29-4fbd-56f9-ad118705a27b)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 233a2806-2f36-46f2-9204-f8bfb2fc5403
Shape name: Receive_1
ShapeId: 160d728f-0375-4445-b21c-6e56d665eccc
Exception thrown from: segment 1, progress 3
Inner exception: Multi-part message ‘InboundMsg’ has body part ‘BodySegments’, expected body part ‘MSHSegment’.
Exception type: WrongBodyPartException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void ReadMessageState(Microsoft.XLANGs.Core.Envelope, Microsoft.XLANGs.BaseTypes.XLANGMessage)
The following is a stack trace that identifies the location where the exception occuredat Microsoft.BizTalk.XLANGs.BTXEngine.BTXXlangStore.ReadMessageState(Envelope env, XLANGMessage msg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.ReceiveMessage(Int32 iOperation, Envelope env, XLANGMessage msg, Correlation[] initCorrelations, Context cxt, Segment s)
at ‘MyCompany.MyOrchestration.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
You can find some more information here.
I received the next message in the EventLog:
The itinerary header could not be found.
Source: Microsoft.Practices.ESB.PipelineComponents.Dispatcher
Method: Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext, Microsoft.BizTalk.Message.Interop.IBaseMessage)
Error Source: Microsoft.Practices.ESB.Itinerary
Error TargetSite: Microsoft.Practices.ESB.Itinerary.IItinerary Create(Microsoft.BizTalk.Message.Interop.IBaseMessage)
Error StackTrace: at Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(IBaseMessage msg)
at Microsoft.Practices.ESB.PipelineComponents.Dispatcher.Execute(IPipelineContext context, IBaseMessage msg)For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I’m using the ESB Toolkit 2.0 (BizTalk Server). I’ve created a custom pipeline which uses the pipeline components:
The error occurs in the ESB Dispatcher. If I look at the context properties then the ItineraryHeader is available and filled with the Itinerary defined in the ESB Itinerary Selector. Why do I get this error? Another strange thing what I see is that the message (body) is my HL7 flatfile (so it is not disassembled to Xml yet).
The solution for my scenario is to not use the pipeline component ESB Dispatcher (or disable it). Then my scenario works fine. In other scenarios I’m using the default pipeline ItinerarySelectReceivePasshrough (or ItinerarySelectReceivePassThrough) and just Xml files as input and these work fine with the ESB Dispatcher.
Is this a problem of the BTAHL7 2.X Disassembler or ESB Dispatcher or a combination of?
I’m using MllpSend for simulating my HL7 ADT system. When I use this tool and wait for an ACK (which I don’t get in a particular test scenario), then my BizTalk Server 2009 Administration Console gives no response (except for this message box
:
I’m using the command:
“C:\Program Files\Microsoft BizTalk 2009 Accelerator for HL7\SDK\MLLP Utilities\MllpSend.exe" /I 127.0.0.1 /P 11001 /TWOWAY /F "C:\temp\BizTalk\validHL7Message.txt" /sb 11 /eb 28 /cr 13
Probably it has to do with the Mllp adapter, because the MllpSend is just listening to a socket.
Do you have any idea?
I have an HL7 scenario where an ADT-system stub is transmitting a non-valid HL7 message into BizTalk. In BizTalk this message is transformed to a valid HL7 message. The MessageHeader is created as message part in an Orchestration. This MSH looks like:
In the first place this looks fine, but my flatfile (created by the pipeline component BTAHL7 2.X Assembler) doesn’t look very well:
A new row is created with four spaces. When validating the MSH (Xml variant) against the schema MSH_25_GLO_DEF.xsd I received the message:
error BEC2004: The ‘MSH.13_SequenceNumber’ element is invalid – The value ‘
‘ is invalid according to its datatype ‘http://microsoft.com/HealthCare/HL7/2X:NM’ – The Pattern constraint failed.
That makes sense (except for the four spaces
). I didn’t receive any warning or error message in the EventLog, so the header is not validated against the schema in the pipeline component. To fix this, I had to enter a valid number for the sequence number and the output looks like:
That’s better.
In an Enterprise Service Bus you have several services which are loosely connected via several transport mechanisms. The Healthcare uses the standard HL7 for communication between systems, hardware and software. Most of the time MLLP (Minimal Lower Layer Protocol) is used for transport. Because in an ESB architecture systems are loosely coupled, some challenges can arise when messages must be processed sequentially.
For example: consider the next 3 ADT messages: with A01 (patient admit), A02 (patient transfer) and A03 (patient discharge). This is also the sequence/order the messages must be delivered to other systems. You can’t discharge (A03) a patient if the patient is not admitted (A01).
In an Spoke and Hub or Enterprise Application Integration architecture you can connect the systems with each other and make the process sequential. BizTalk Server works asynchronous, so messages are dropped in the MessageBox and processed by a subscriber, which can be an Orchestration or Send port. Example: if the Send port process the second message (A03) faster as the first message (A01) which is used in an Orchestration, then the backend system will return an error (BizTalk processing is also known as: first-in, fastest out). To make this process synchronously BizTalk Server and the MLLP adapter offers some techniques which can be used:
But how to solve this in an ESB architecture? How to solve this with BizTalk Server ESB Toolkit 2.0?
My answer to this question in the title is: yes it can. How? The ESB Toolkit makes use of BizTalk Server, and is therefore based on rules prescribed by BizTalk. The Itinerary will become just a context property on a message for routing thru the BizTalk system. So you can still make the process synchronously. The Orchestration must use a “request” / “response” mechanism to send the message to the backend system, and wait for an ACK before processing the next message. Some blogs from my this month can help to make this happen, also for a generic solution.
Let me know how you think about this or if you have already experience with HL7, MLLP and the ESB Toolkit.