Recently, we were tasked to update our client's BizTalk 2013 application to use AssureSign. One of the main steps is to enhance BizTalk to receive a notification from AssureSign once the document is signed. This blog is part of a 3-part series to accomplish integration between AssureSign and BizTalk utilizing Azure Services like Logic Apps to facilitate the transaction.
- Part 1 - AssureSign - Integration between AssureSign DocumentTRAK and Azure Logic App, as well as Service Bus
- Part 2 - AssureSign - Integration between Azure Service Bus and BizTalk Server
- Part 3 - AssureSign - API Management
With the Classic Azure portal, we know that we can create an ACS Service Bus external endpoint to receive the notification. However, our client is moving away from Classic Azure portal. Therefore, we've decided to use a Logic App request action to create an external endpoint. We also created a SAS Service Bus endpoint with a queue to hold the message for BizTalk to consume.
High-level Architecture
In this part 2, we focus on the integration between Azure Service Bus and BizTalk Server
Create a Service Bus with queue
In part 1 we created a Azure Service Bus queue.
Exception error occurred
In BizTalk, we configured the receive location (configuration steps are below) to use WCF-custom adapter with netMessagingTransport under customBinding.
However, the below exception occurred when the Service Bus message reached BizTalk Server.
The adapter "WCF-Custom" raised an error message. Details "System.Xml.XmlException: The input source is not correctly formatted.
at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3)
After research, with limited solutions, but with help from the following:
We enabled the message logging option in BizTalk and learned that the incoming message was a stream (xml string) format and WCF-Custom adapter does not support it. Therefore, We decided to build the customTextMessageEncoder component to convert the stream message to an acceptable WCF message.
NOTE: The above error only occurs on the BizTalk Server 2013 environment. The issue is handled in BizTalk Server 2013 R2 and later.
Create customTextMessageEncoder
First, we downloaded the WF_WCF_Samples.exe file from https://www.microsoft.com/en-us/download/details.aspx?id=21459 and installed it on a development machine. We located the message encoder sample code in the install folder <InstallDrive>:\WF_WCF_Samples\WCF\Extensibility\MessageEncoder\Text\CS\library
Then we copied the sample CustomTextMessageEncoder project to our project folder, created a strong key, and compiled it. We had to add a couple missing reference objects (ex: latest version of Microsoft.ServiceBus).
Second, we updated the ReadMessage method in the CustomTextMessageEncoder.cs class to convert the incoming stream to a WCF message. The below sample code was the modification of the original code block in ServiceHelperClass.cs of the Service Bus Explorer (created by Paolo Salvatori https://code.msdn.microsoft.com/windowsapps/Service-Bus-Explorer-f2abca5a#content).
public override Message ReadMessage(Stream stream, int maxSizeOfHeaders, string contentType)
{
Message message = null; //Read stream and convert to string and encoding
string messageText;
using (var reader = new StreamReader(stream, Encoding.UTF8))
{
messageText = reader.ReadToEnd();
} try
{
//Check to see if message string has welform xml format
var isXml = XmlHelper.IsXml(messageText); //Reconstruct message
if (isXml)
{
var stringReader = new StringReader(messageText);
var xmlReader = XmlReader.Create(stringReader);
var dictionaryReader = XmlDictionaryReader.CreateDictionaryReader(xmlReader); message = Message.CreateMessage(MessageVersion.Default, "*", dictionaryReader);
message.Headers.To = new Uri("sb://dummyuri.servicebus.windows.net/inboundqueue1"); // Fake Uri
message.Headers.Action = "*";
} }
catch (Exception ex)
{
throw ex;
} return message;
} |
Third, we added the new configuration line for the customTextMessageEncoding component to the <bindingElementExtensions> node of machine.config files (both x32 and 64).
<add name="customTextMessageEncoding" type="Phidiax.ServiceBus.Configuration.CustomTextMessageEncoder.CustomTextMessageEncodingElement, Phidiax.ServiceBus.Configuration.CustomTextMessageEncoder, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fc29058fd5eeac71" />
Additional information about the custTextMessageEncoder sample is available at https://msdn.microsoft.com/en-us/library/ms751486(v=vs.110).aspx
Create and configure receive location
We created the new receive location using WCF-Custom adapter.
|
Click Configure button to open the configuration properties. Copy and paste the Service Bus address into the Address URI box under General tab. 
|
Navigate to Binding tab and select customBinding under Binding Type dropdown box. Add customTextMessageEncoding and netMessingTransport under CustomBindingElement in the same order as seen below 
In some case, netMessageTransport option was not available in customBinding. Please follow the instruction in below blog to add the missing binding options https://code.msdn.microsoft.com/windowsapps/How-to-integrate-BizTalk-07fada58 |
Switch to Behavior tab and add transportClientEndPointBehavior under EndPointBehavior. Select the SharedAccessSignature tree node and provide key and keyName configuration properties. 
|
Testing
Use the Service Bus Explorer tool to send test message to the Service Bus queue
Use Postman to simulate the incoming message from AssureSign Notification. The path is as follows: Postman to the Logic App, and then routed to Service Bus, to BizTalk for processing.
In the next part of this blog series, we will integrate Azure API Management.
- Part 1 - AssureSign - Integration between AssureSign DocumentTRAK and Azure Logic App, as well as Service Bus
- Part 2 - AssureSign - Integration between Azure Service Bus and BizTalk Server
- Part 3 - AssureSign - API Management
2009-2017 Phidiax, LLC - All Rights Reserved