For quite some time, BizTalk was not getting the love it deserved. Sure, we got our platform alignment, and sometimes a new or updated adapter, but all in all, there were not many exciting new features. That changes now, with the just released Feature Pack 1 BizTalk 2016. In this feature pack, we are seeing more new features than we have in a long time, and shows that the product team, with our very own Tord at the helm, really is caring about the product once again. If you look at the user-voice page for BizTalk, you will notice a lot of suggestions are being made by the community, and this feature pack shows that we are actually being listened to as well! In this post, I will go into the new features being introduced.
Last week I attended Integrate 2016 in London, the biggest Microsoft integration event this year, organized by BizTalk360. The outcome was almost 400 attendees, and there were sessions from the Microsoft Product Group, industry leaders and MVP’s.
The major take-away I have from the event, is that Microsoft now has a great vision on the future of integration, which I felt was missing the last couple of years. Now though, they recognize that even though the cloud is a great asset, on premise is not going away for a long time. Also Microsoft has now officially announced that their on-premise integration solution will be BizTalk, which has not been getting a lot of love lately.
A while ago I created a post on using the BizTalk Deployment Framework for automated build and deployment. Since then I have worked this out to be more easy and maintainable using PowerShell, which I will show in this post. BizTalk Deployment Framework is one of those pearls for BizTalk developers, allowing complex BizTalk solutions to be deployed easily, having all our artifacts and dependencies together in one MSI. The code with this post can be downloaded from here.
Using PowerShell we will make scripts which will handle all steps of the build and deployment process for us. This will make sure our applications are always deployed in the correct order, using the right versions, and with minimal effort. We have some general helper functions, which will help us clear log files, wait for user input, iterate through directories, etc. We assume you have are using some of the BTDF best practices for these scripts, where it comes to naming conventions and folder structure. Of course, in case anything differs in your environment, you can easily adjust the scripts to meet your requirements.
Everyone who has been working with BizTalk knows how powerful this product can be. It will allow you to tackle a lot of integration scenarios out of the box, but sometimes you will run into a requirement which can not be handled using just the standard BizTalk components. Luckily BizTalk can be extended on many points, giving you the power to handle all your scenarios. Some of these extensibility points are:
- Ports (Custom behaviors and adapters)
- Pipelines (Pipeline components)
- Mappings (XSLT, Functoids, XPATH)
- Orchestration (XPATH, Helper classes)
- Configuration (SSO Helper)
- Deployment (Deployment Framework)
- Testing (BizUnit, Visual Studio Test, Custom clients)
- Monitoring (BAM, BizTalk assemblies)
- Rules (BRE)
Often you will have to get some content from your messages, and use this to set the filename of your outgoing files, in our case we needed to use a sequencenumber. I will show a way to do this using a pipeline component in a streaming matter.
Xpath is a very nice way to retrieve values from BizTalk messages, especially when you can not use distinguished fields, for example in looping records. It can however be quite a complicated task as well, to find out how to retrieve a certain value. To that end, I have created a list of xpath filter expressions I commonly use. In these examples I will be using the following XML.
<root> <delivery> <deliverytype>Home</deliverytype> <boxinfo> <boxid>22</boxid> </boxinfo> </delivery> <delivery> <deliverytype>Work</deliverytype> <boxinfo> <boxid>35</boxid> </boxinfo> </delivery> <delivery> <deliverytype>Home</deliverytype> <boxinfo> <boxid>12</boxid> <boxid>87</boxid> </boxinfo> </delivery> <boxes> <box material="cardboard"> <id>12</id> <contents>Envelopes</contents> </box> <box material="cardboard"> <id>22</id> <contents>Surface Pro 2</contents> </box> <box material="plastic"> <id>35</id> <contents>Stickers</contents> </box> <box material="cardboard"> <id>87</id> <contents>Stamps</contents> </box> </boxes> </root>
- Filter on index
Get the third delivery node.
Get the deliverytype node of the second delivery.
- Filter on subnode text
Get all delivery nodes, which have a deliverytype of Home.
Get the deliverytype node of the delivery for BoxID 87.
Get the deliverytype node, of the box which contains the stickers.
Often when you want to create a message in an orchestration, the option of using an XMLDocument is chosen for this. However, this option can be a serious performance hit, as your entire message will be loaded into memory, and can become as large as 10 times it’s original size. To avoid these performance hits, I have created 2 small helper methods, which allow you to instead use BizTalk’s native messages instead of an XMLDocument, and create the message in a streaming way. Using these, you can simply create a message from a string (and the other way around).
In one of our projects, we hadto do an xpath expression in an orchestration to find a value from a nodes subnode, where another subnode has a specific value.
So our input is like this:
<Root> <Delivery> <DeliveryType>Home</DeliveryType> <BoxInfo> <BoxID>22</BoxID> </BoxInfo> </Delivery> <Delivery> <DeliveryType>Work</DeliveryType> <BoxInfo> <BoxID>35</BoxID> </BoxInfo> </Delivery> <Delivery> <DeliveryType>Home</DeliveryType> <BoxInfo> <BoxID>12</BoxID> <BoxID>87</BoxID> </BoxInfo> </Delivery> <Boxes> <Box> <ID>12</ID> <Contents>Envelopes</Contents> </Box> <Box> <ID>22</ID> <Contents>Surface Pro 2</Contents> </Box> <Box> <ID>35</ID> <Contents>Stickers</Contents> </Box> <Box> <ID>87</ID> <Contents>Stamps</Contents> </Box> </Boxes> </Root>
Now what we wanted to do, is to have the ID’s of the boxes, where the delivery type was Home.
In my current project we are using UBL as our internal format. UBL, or Universal Business Language, is an effort to define a library of standard electronic XML business documents such as purchase orders and invoices. The plusside of using UBL is you have a industry standard, and there are various components and resources to easily integrate it in your solutions. The downside,from a BizTalk perspective is, the schema’s are very large, and have lot of schema references, which again have there own references, which can go up to 8 levels deep.
In my previous post I talked about how we are using Service Bus as our queueing mechanic, from which we read messages using BizTalk. When using Paulo Salvatori’s test client we could read these messages in BizTalk, however when we were publishing messages from our own .NET applications, we weren’t able to receive them in BizTalk. These were the errors we got in the event log:
The adapter “WCF-Custom” raised an error message. Details “System.ServiceModel.CommunicationException: Unrecognized message version.
The adapter “WCF-Custom” raised an error message. Details “System.FormatException: Input string was not in a correct format.
After some research, I found out this is due to the way the messages are being deserialized by the BizTalk WCF adapter. To solve this, when placing the messages on Service Bus, we have to publish them as WCF messages, instead of using the Service Bus SDK.