This blog will describe how we can publish a message using Biztalk server and the Apache ActiveMQ Rest API. In previous blog I wrote about consuming a message from a AMQ and in this article show how to do it the other way.
To begin with we tried to use a BizTalk WCF-WebHTTP adapter to POST a message to the AMQ with a request URL like http://servername:8161/api/message/MISC.MAX.DATA?type=queue&clientId=misc_data_biztalk&message_type=7222&message_version=2. We were pleased to see the message added to the queue with the correct properties. Unfortunately we got a transmission failure like “System.ServiceModel.ProtocolException: An HTTP Content-Type header is required for SOAP messaging and none was found” in the BizTalk group hub even though the message was added to the queue successfully. If we tried the request using fiddler it showed that the response does not contain a Content-Type in the header as well.
Getting a transmission failure each time BizTalk posts a message is not acceptable and we searched for a solution. We created a custom behaviour to add this a Content type to the header of the response but the WCF-WebHTTP adapter transmission failure occurs before the message gets to that point. Next we tried to configure the AMQ to add a content type but could not find the correct “config” to edit.
Finally we decided to choose BizTalk HTTP adapter instead of the WCF-WebHTTP adapter to POST the message to the AMQ. The HTTP adapter is a very old adapter and I reasoned that it might not be as picky about what is in the header of the response. It was pleasing to find that the HTTP adapter did POST a message to the AMQ without a transmission failure. This is a good example of where the HTTP adapter can do something that the modern WCF-WebHTTP adapter cannot do. Thanks to Deepa Kamalanathan for proving all this.
In summary we have now shown that you can consume messages from a Apache AMQ with the BizTalk WebHTTP adapter and that you can publish messages to the AMQ with the HTTP adapter. One question remains and that is what throughput can be achieved using these adapters.
The BizTalk Documenter has been compiled and refactored for .Net 4.6 and BizTalk 2016 Tap release.
This will only work for BizTalk 2016.
We followed Mohamed M Malek and used the WCF-WebHTTP adapter to integrate with the Apache ActiveMQ Rest API. Initially we used a HTTP GET to consume the message but discovered that after a while the central message broker ran out of memory. Researching the Apache documentation we discovered that you can consume messages by browsing to the subscription but you must then DELETE the message when you have finished processing it, to acknowledge a particular message.
We tried to acknowledge our HTTP GET with a subsequent HTTP DELETE but could not DELETE the message from the queue. It had already been removed from our subscription.
In the end we changed from using a HTTP GET to a HTTP DELETE. The Apache documentation says you can use either a HTTP DELETE or GET to consume the message. We found that response was identical whether we used GET or DELETE. What was more pleasing was that the memory no longer increased on the central message broker and this solved our issue. Thanks to Deepa Kamalanathan for working all this out.
Colin Dijkgraaf and I presented this on Integration Monday today. In this session we showed why the WCF-WebHTTP adapter requires some workarounds. We used BizTalk 2016 Tap release to demonstrate these workarounds. The presentation and PowerPoint presentation can be downloaded from here.
The Service Bus Preview does not display Azure Service Bus Relays in my hands.
The Service bus is in preview in the new Azure Portal and I used it to create this service bus. I created a Azure Service bus relay but could not find it anywhere in the new portal. Without this it is not easy to check whether you have created the relay or not.
Thankfully when I checked the old portal I can still see the Azure Service Bus Relay that I created.
I hope the Microsoft team fix this before it comes out of preview.
I really like this logic app pattern.
The NZ Post parcel events application (https://www.nzpost.co.nz/business/developer-centre/tracking-notification-api/watch-method) will not repeat an event. I decided to expose http endpoint in an azure Logic App and send these to a Azure Service Bus. I then I retrieve the message using a BizTalk SB-Messaging adapter, whenever I am ready and then do all the heavy lifting.
This was a brilliant experience with a customer in front of me. All done in less than 15 minutes!
I got this error.
Checking the event log I saw a BAM Web Service Error like
System.Web.Services.Protocols.SoapException: There are instances with duplicate ID ‘\\MyServer\customer-b2c-dw_wsl_delta201604131734004.xml’ in activity ‘GenericCountOfTrackedMessages’. The duplicates must be removed from the database to fix this problem.
Running the following query showed the duplicates in two of the partitions.
SELECT * FROM [BAMPrimaryImport].[dbo].[bam_GenericCountOfTrackedMessages_20ED6B1B_734C_4980_B213_792B16DF734B] where ActivityID IN (SELECT ActivityID FROM dbo.bam_GenericCountOfTrackedMessages_00C024D3_BCC3_4E02_A428_3358E482BF4F)
I decided to delete these duplicates from one of the partitions with
FROM [BAMPrimaryImport].[dbo].[bam_GenericCountOfTrackedMessages_20ED6B1B_734C_4980_B213_792B16DF734B] where ActivityID IN (SELECT ActivityID FROM dbo.bam_GenericCountOfTrackedMessages_00C024D3_BCC3_4E02_A428_3358E482BF4F)
This worked and the query of this BAM activity now works without the above error.
It is a miserable rainy Saturday morning in Auckland and I decided to have look BizTalk 2016 CTP1. I had set up two SQL servers, many Always on instances and then configured a BizTalk server. Before going further to set up the SQL Always On availability groups I wanted to check that i had configured everything correctly. Thus I configured the BHM from the Support tools folder that comes with BizTalk 2016 CTP1 in the same way that Sandro has previously described for BizTalk 2013R2. I discovered that the BHM that comes with BizTalk 2016 CTP1 is a very old version.
This showed me that everything was Ok but I had not set up the back up job for the databases.
I thought it would be interesting to see if the latest version of the BHM v3.2 could be run on BizTalk 2016 CTP1. I suspected I might get an amusing critical error and I did as shown below. BHM v3.2 installed without error and the latest repository update downloaded easily. All the functionality BHM v.3.2 seemed to work but I have not tried to run terminator yet. This is pleasing because I think that the BHM is a very useful tool for support analysts to use.
In summary the latest version of the BHM seems to work with BizTalk 2016 CTP1. The .Net version warning made me laugh but it is understandable that the repository update does not know about BizTalk 2016 CTP1 yet. I hope that the final version of the BHM ships with v 3.2 + instead of the original version and that the repository update starts to know about BizTalk 2016.