Few Thoughts on the ESB Toolkit and an Error – “The ‘ServiceType’ property value should not be empty or null”
I have recently been experimenting with the ESB Toolkit (version 2.2 that ships with BizTalk 2013) and I think it is a good way to expedite loosely coupled BizTalk solutions, dynamically configurable at runtime using the Business Rules Engine (BRE).
At a high level, the ESB Toolkit itinerary model is an implementation of the routing slip pattern.
My immediate impression is that development using the Itinerary Designer is tightly coupled to the runtime environment, more so than “standard” BizTalk development. By “runtime environment”, I mean artefacts/configuration viewable via the BizTalk admin console (e.g. applications, send port filters etc.) and also policies created via the BRE Composer. Basically the target application needs to be setup before starting work building the solution using Visual Studio. Any changes to the solution setup (changing a send port name, for example) would likely require firing up Visual Studio and propagating these changes to the itinerary, then importing into the itinerary database.
It’s also occurred to me that the itinerary pattern is in my mind an easier way to implement a message type agnostic solution, compared to using the standard BizTalk toolset. I have recently been wrestling with a series of orchestrations processing messages in a non typed fashion, routing to/from the MessageBox purely using context properties: this is a powerful enabler of achieving a “service first” approach (instead of a “message first” approach) permitting heavy reuse of processing logic without caring about the underlying message type. Yes, I’m thinking about SOA principles here. However it’s been quite a mission to implement this routing using non typed messages in orchestration.
To illustrate this tight coupling of the development and runtime environments mentioned previously (and to demonstrate my noob status regarding the ESB Tookit :-)), whilst trying to export a model via Visual Studio, I was stumped with these errors:
It was obvious clicking on my off ramp that these three properties were not configured but they looked to be read only – so how could I add values?!:
After a bit of head scratching and a web search it soon became clear that these properties referred to filter properties on my send port – it would have been useful if the property name made it obvious what these properties referred to.
So in my BizTalk application, I created the following filters on my dynamic send port:
I then re-selected the send port in the off ramp and the required properties were then populated from the BizTalk databases:
I hope this post helps out other ESB Toolkit “greenhorns”.