What a surprise today finding out that Microsoft has decided to brand it’s next version of BizTalk Server as BizTalk Server 2013. Even better, they’ve already thrown a beta version at the general public which is a whole lot more full-fledged in terms of new features compared to some earlier builds made available to a select audience.
While its early days and features are bound to evolve between now and the release date, I’m sure many are curious to find out quite how Microsoft has decided to implement some of the promised features.
In today’s blog post which is the first in a series focusing on the new features in BizTalk Server 2013, I will focus on the much awaited dependency modelling feature that has been added to the administration console. Such a feature has been sorely lacking in previous versions of BizTalk, making it very difficult for operations staff to get an idea of how BizTalk artifacts relate to each other. Freeware tools such as BizTalk Documenter have filled this role reasonably well but there hasn’t really been a live view on dependencies available without peeking into the source code.
There is now a new option in the “Action” pane in the Administration Console called “View Dependencies” which can also be seen if you right-click on a supported artifact type. This option exposes the new functionality by filling in the dependency details in the “Dependency Statistics” section at the bottom of the console. Neither the View Dependencies option nor the Dependency Statistics section of the screen will be seen when browsing to artifact types that don’t support dependency modelling.
Well, I’ve built and deployed my first BizTalk Server 2013 application with the goal towards getting an initial understanding of how dependency modelling has been implemented. The application consists of the below :
- Four schemas (two external schemas and two internal schemas)
- Three maps
- From the first external schema to the first internal schema
- From the first internal schema to the second internal schema
- From the second internal schema to the second external schema
- Two orchestrations – each of these orchestrations receive a message of internal schema one, map it to internal schema two, exercise a very simple BRE (Business Rules Engine) policy, and send the message out
- The first orchestration contains logical ports with a specify later binding, bound to the receive and send ports mentioned below
- The second orchestration contains logical ports with direct binding, not making use of any filter expressions. Just for funsies this orchestration exercises the XMLTransmit pipeline on the outbound message before it is sent out
- The aforementioned BRE policy
- A one-way receive port which is bound to the first orchestration and a corresponding file receive location. The receive port uses the XMLReceive pipeline and exercises the map that transforms the first external schema to the first internal schema
- A one-way file send port which is bound to the first orchestration and also contains a filter so that it subscribes to messages with a message type of the second internal schema
I kept my schemas, maps, and orchestrations in separate BizTalk projects so I could see if there was any cross assembly dependency tracking. I was a bit disappointed to find out that there is no visibility of cross assembly dependencies, at least not at this stage.
Let’s start with receive ports. If we right-click on the receive port that I created and choose view dependencies then we see the below.
So interestingly we now see that this receive port has listings in the Used by (other artifacts are dependent on) section as well as the Using section. Clicking on any of these numbers will give you a handy consolidated list of all the artifacts of that type which depend on or are dependents for this receive port. Only the specify later bound orchestration is listed as dependant on this receive port whereas the one that uses direct binding is not listed. This makes good sense because the direct bound orchestration has a loose subscription based purely on message context whereas the specify later binding orchestration is bound to the receive port. The inbound map that is exercised by this receive port is listed in the using section since the receive port is dependant on it. The receive location is also listed here. I think that being able to see a list of all the receive locations for a given receive port will be well received by BizTalk Operators.
Next up lets inspect the dependencies for the receive location. As one might have guessed, the receive location is used by it’s parent receive port. The pipeline that it makes use of is listed as an artifact that the receive location is dependent on which is quite handy.
If we try to inspect the dependencies for the XMLReceive pipeline we see that the receive location that makes use of it is listed as dependent on the pipeline. This provides some really fantastic information for those planning deployments which involve new versions of pipelines.
I was disappointed to find that when I tried to view dependencies on the XMLTransmit pipeline there was no information listed even though it was used by our second orchestration. It looks like dependencies between pipelines and orchestrations aren’t quite catered for.
Next up let’s take a look at the dependencies for the map that is used on our receive port which transforms the first external message to the first internal message. As seen below the schemas which make up the map are listed as dependents, and the receive port that makes use of this map is listed in the used by section.
On inspection of the map that transforms the first internal message to the second internal message and is used in the two orchestrations I found once more that the dependency between the maps and the orchestrations were not listed.
Viewing the dependencies on the second internal schema showed that it is used by two maps, the link to the orchestration is once more ignored.
On to the orchestrations. Viewing dependencies on the specify later bound orchestration shows a dependency on the receive and send port that the orchestration is bound to but no mention of schemas and maps.
Viewing dependencies on the direct bound orchestration displays an empty Dependency Statistics screen, even ignoring the XMLTransmit pipeline that was exercised in this orchestration.
It became quickly apparent that there is no support for dependency modelling on the BRE policy, which once more is a bit disappointing but of course these are early days.
And finally viewing the send port shows that the orchestration with specify later binding is dependent on this send port, and that this send port is dependant on the map and pipeline which it exercises.
So while I have used the word disappointing quite a few times in this blog post, I am actually fairly happy with this implementation. It is a big leap forward compared to what was previously available and one can only hope that Microsoft chooses to flesh out this feature even more. It should make planning for deployments and everyday administration a whole lot easier and reduce the amount of detective work that is required to prepare for deployments.
If I’ve made a mistake or if I’ve left out a type of artifact that you are interested in and want me to explore further do let me know and I’ll update this post.
Good review! Thank you!
Seems it is the helpful feature. Right now I’m upgrading a big BizTalk installation from 2006 to 2010. There is a lot of BizTalk applications without any documentation and without any BizTalk person on the board.
This feature will save me a quite bit of time when I’m investigating the BizTalk artifacts.
LikeLike
Leonid, you may have already tried it but I’d like to recommend BizTalk Server 2010 Documenter if you have lots of applications that you need to document. It’s biztalk2010autodc on codeplex. I am exploring its use as part of potential change management artifacts to use in our organization.
LikeLike
Hi really a nice feature and well demoed as well thanks for that.
is it the only new feature in BizTalk 2013?
LikeLike
Hi Parashu, far from it. There are many new features such as RESTful support, more cloud integration, better handling of ordered delivery, improved selection of hosts for dynamic ports, and the list goes on. Do visit Microsoft’s help page for BizTalk Server 2013 Beta for a brief overview of all the new features and do download the beta for yourself as well.
LikeLike
Hi,
This is the feature I am waiting for, but not quite sure how it will help me. Let me explain my reservations below:
The idea was to future proof the solutions (in expectation of the use of WF instead of Orchestration engine – not yet happening) by extracting the business rules for the purpose of processing the message and identifying the target systems.
The implementation prefers the messaging based (ESB itinerary) solution over the usual process based (orchestration ) aproach.
We have a limited number orchestrations, relying heavily on policies to select the itinerary (context based) for deciding steps required to process a message and associated configurations of the dynamic send ports. Further, to allow for independent upgrade of such components, without affecting others, I have grouped them into separate applications running under their own host instances.
Note: The use of default host instance and dynamic ports per application is another consideration.
Most of the changes – when coded as per guidelines – can be deployed “hot” without an outage to any services.
So, as you can see, if the inter application dependency is not analysed, then it will be hard pressed to do any of the ESB solution analysis. I know that the ESB is not part of the BizTalk install, but still seems like a distant poor cousin.
I understand, that any inclusion of such capability may help a small number ESB solution architects and may not gain enough traction to extend this features – but it would be of great help, because there is no tool for such analysis.
Regards
Bibhakar Saran
LikeLike