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.