Brian Loesgen created a great demo on the Azure platform AppFabric Service Bus. This demo showed also some features (combinations) of Business Rule Engine, ESB Toolkit, InfoPath and SharePoint.
You can find the video here.
Tag Archives: ESB
“The itinerary header could not be found”
I still receive this message. I also dropped it in the Microsoft BizTalk ESB Toolkit forum. I got response and it pointed me to the tracing possibilities. I’m using the ESB Toolkit for a while now, but didn’t use this feature. If you really get stuck with problem solving, then this is a nice feature to use. Dwight Goins blogged about this. (note: it didn’t gave me the information I needed, but I think it still will help me in the near future).
“Body schema is missing” (2)
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.
“The itinerary header could not be found”
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:
- ESB Itinerary Selector (Decode)
- BTAHL7 2.X Disassembler (Disassemble)
- ESB Dispatcher (ResolveParty)
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?
Can the Healthcare take benefits of an ESB?
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:
- Ordered Delivery on the receive port.
- Listen-shape in an Orchestration together with a correlation set based on the Patient ID.
- Make use of guaranteed delivery.
- Wait for ACK/NACK response from the backend, before continuing to the next message.
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.
Cannot create a custom ESB Adapter for MLLP
As you have noticed I’m working on HL7 and the ESB Toolkit. It is possible to extend the ESB Adapters with your own adapters by using the BaseAdapterProvider in Microsoft.Practices.ESB.Adapter. To use this it must be possible to dynamically configure your ‘normal’ BizTalk adapter (e.g.: by editing the properties in the propertyschema in an orchestration). The MLLP Adapter for HL7 messaging doesn’t support dynamically configuring from the send port. This is a real pity, because now I’ve to use the MLLP Adapter in a static way. (note: there is no property schema for MLLP on the system, and it is mentioned once on this site).
It would be nice if this will be a feature in the next release (or update) from the HL7 Accelerator.
Why changing the ESB.Config for adding Orchestrations?
Last week I was working with a colleague on a scenario in the Itinerary. In this scenario we are using an Orchestration. To use this Orchestration in the Itinerary we had to add the Orchestration to the ESB.Config,
so it can be selected in the Itinerary:
(note: it is not necessary that this Orchestration is deployed, it is not validating)
After exporting the model, the Itinerary contains the next line:
I still can’t think of a reason why this Orchestration should be added to the ESB.Config, because it can be resolved dynamically like the send ports from an application. Now all the developers must change their ESB.Config, and also the production version must be changed (the full name is not stored in the Itinerary, just a Guid or just a string as you wish). Why not store the full assembly name in the Itinerary?
Do you know the answer? Will this be a feature for the next release?
Visual Studio error when selecting a Service from the ESB.Config
Whenever you get the next message in Visual Studio when you select an Orchestration from an Itinerary Service:
"The type initializer for ‘Microsoft.Practices.ESB.Configuration.ConfigHelper’ threw an exception"
make sure your ESB.Config is not messed up. For eg.: when you added an Orchestration to the Itinerary Service.
UDDI Configuration – an easier way
Yesterday I blogged about my second scenario and how to configure a service in UDDI. Because my send ports are dynamic I couldn’t register it in the ESB Management Portal as a service, so I did it the hard way 
. Another possibility and an easier way is to create a temporarily send port in the BizTalk Administration Console and configure it for your needs (WCF, FILE, etc):
After that you can register this port in UDDI via the ESB Management Portal. Click on Registry and New Registry Entry. Select your application. Find your temporarily port and click publish:
On the next screen you can change the settings for your need. When you are finished, then click publish:
Open the UDDI portal and navigate to publish:
As you can see your service is now available in UDDI and all settings are made for you. If you want you can clean up the categories of your binding (but always leave one in place, doesn’t matter which one). In the BizTalk Administration Console you can delete the port physically. Change your itinerary to use the new UDDI service. Note: the name of the send port is used as binding key, so choose your name wisely 
BizTalk ESB Itinerary: second scenario, use of UDDI
in my last blog about the ESB Itinerary I had a static solution. Now I created a more dynamic solution by resolving the WebService location from UDDI. So, how to manage this?
First, create an entry in UDDI (note: it is also possible to register ports in UDDI via the ESB Management Portal, but not for dynamic ports which I used in my first scenario.
NOTE: the instance details is the information you also entered in the static version. So it is not repeated here.
NOTE: enter your own key! This UDDI key is used in your itinerary, so a logic name will make maintenance easier.
Don’t forget to enter the categories. In the ESB demos there were other categorization schemes entered. The next one worked for me:
After that I copied my itinerary to a new version. And changed the WebService resolver, like:
After Exporting the Itinerary to the database I was able to test my Itinerary and it is working just fine. In the next scenario I’m going to integrate a mapping and after that I’m going to integrate the HL7 Accelerator. Nice stuff !!!
