Test the Bridges - Post messages – 3 easy tools for the developers
1. BizTalk Service Explorer
This is easy to use yet very powerful tool (VS Server Explorer Plug-in) especially for the developers. If you don't have it installed yet, right now download it from here or follow this TechNet Wiki "Azure BizTalk Service Explorer" to add it from Visual Studio Gallery within VS.
Though this tool has lot of other useful features (which we will explore in other respective topics) here we are looking at how to post the message.
For that, from this TechNet Wiki "Azure BizTalk Service Explorer", see the section “Test and Debug bridges”
2. Message Sender
This tool came as a part of Windows Azure BizTalk Services SDK Samples - Windows Azure BizTalk Services EAI Sample Tools - Message Sender.
This is stand-alone executable – after downloading the sample you can compile the project and use the following command line syntax to push messages.
MessageSender.exe <ACSNamespace> <IssuerName> <Issuerkey> <RuntimeAddress> <MessageFilepath> <ContentType>
Note that there are no “-“ for the parameters. The exe recognizes parameters based on the position. For MessageFilePath, if sample message is in the same folder as the exe, then you can simply provide the file name – otherwise provide the entire file path. If file path contains spaces, put quotes around it.
The first three parameters you can get from the Azure Management Portal by selecting your BizTalk Service and then clicking on “Connection Information”.
All the parameters are explained on the tool’s download page.
You can extend this tool and develop your own applications as per the business requirements to work with the MABS.
3. Using on premise BizTalk Server
I agree, this is not the “most common” tool, but still there are a lot of users who work simultaneously on the BizTalk Server. Following information will help to test as well as integrate the on premise BizTalk Server with MABS.
Open BizTalk Admin Console and under the “Send Ports” section create a new WCF-WebHttp Send Port.
Click on Configure. On General tab, provide the bridge URI.
On the Security tab, check the check box “Use ACS service identity” and click on Edit and then provide ACS information.
Click on “OK”s to complete the send port configuration. Now either use content based routing or orchestration to send the message using this send port.
Note:
If you get error like
System.IdentityModel.Tokens.SecurityTokenException: The token provider was unable to provide a security token while accessing 'https://servicename3900-bts.accesscontrol.windows.net/WRAPv0.9/'. Token provider returned message: 'Error:Code:401:SubCode:T0:Detail:ACS50009: SWT token is invalid.:TraceID:b6a7b26c-b490-46a4-91c9-0764f98dd860:TimeStamp:2014-10-17 05:24:12Z'. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Microsoft.BizTalk.Adapter.Wcf.Config.SharedSecretTokenHelper.GetAccessTokenCore(Uri requestUri, String appliesTo, String requestToken, String simpleAuthAssertionFormat, TimeSpan timeout) --- End of inner exception stack trace ---
and you are sure that the ACS credentials are correct, then try using Symmetric Key instead of the password in the “Issuer Key” Field.
For this, go to the main Azure Management Portal and go to the ACTIVE DIRECTORY – ACCESS CONTROL NAMESPACES and then select respective ACS Namespace.- click on Manage.
On the left side select Service Settings – Service identities. Then select the identity – owner – Symmetric Key
Considerations for the EDI / AS2 Bridges
You may use above methods to send messages to EDI / AS2 bridges as well. However, post Aug 2014 release, Agreements and bridges are decoupled. If you have not redeployed the agreement after the Aug 2014 release, then still old EDI / AS2 bridges will work as they were working before. With the new agreements (or if you have redeployed the agreement), when sending the message to EDI / AS2 bridge, the agreement resolution happens based on Agreement ID / Combination of agreement name and partners / The identities in the agreement / AS2-To and AS2-From values. For more information see the article How do bridges resolve to agreements at runtime?
For Message Sender
You can modify the below code to add appropriate HTTP headers as per your requirements.
private static string SendMessageToBridge(string address, byte[] messageBytes, string token, string contentType)
{
string response;
WebClient webClient = new WebClient();
webClient.Headers[HttpRequestHeader.Authorization] = "WRAP access_token=\"" + HttpUtility.UrlDecode(token) + "\"";
webClient.Headers["Content-Type"] = contentType;
byte[] uploadData = webClient.UploadData(address, "POST", messageBytes);
LogTrackingId(webClient.ResponseHeaders);
response = Encoding.UTF8.GetString(uploadData);
return response;
}
For on premise BizTalk Server Send Port
For the previous send port, click on configure and go the Message Tab. Here add appropriate HTTP headers as per your requirements.
Note:
The “colon” + “space” is the separator for “Header Name” and “Header Value”. If you need multiple headers, make sure to have carriage return after at the end of the previous header value – as shown here.
EDI Receive and Send bridge
The names Receive and Send are w.r.t. MABS. So when you want to post the message on EDI Receive Bridge, make sure that you are posting EDI message – that is text message. The EDI Receive Bridge will disassemble it to XML message and send it to the destination.
Similarly, when you are posting the message on EDI Send Bridge, make sure you are posting XML message. The EDI Send Bridge will assemble it to EDI message and send it to the destination.
Make sure to put proper Content Type
If proper content type is not provided, the messages delivery can fail. Here are a few forum posts that will help to make a choice of the correct Content Type based on the method that you use to post the message.