Mind Over Messaging

Using AS2 Bridges in MABS (post August 2014 Update)

In my previous post about using the new EDI bridges in Microsoft Azure BizTalk Services (MABS), I promised to follow up with an example of using the AS2 bridge type – so here it is.

Applicability Statement 2 (AS2) is all about establishing security and reliability when transmitting B2B messages over HTTP/S. It provides for digital signing and encryption as well as acknowledgements via Message Disposition Notifications (MDN), which also leads to support for Non-Repudiation (NRR).

Like BizTalk Server, MABS provides support for AS2 with EDI transactions; in fact, the latest update has enhanced this experience with additional symmetric key encryptions including AES, DES3 and RC2 as well as MD5, SHA1 and SHA2 for MIC calculation. The main difference in this latest update, though, is that the AS2 bridge and the associated agreement are configured separately, just like the EDI bridges themselves now are. Understanding the sequencing of these bridges and how they connect is key, however, and may not be readily apparent from the current documentation – hence the reason for this article.

Scenario for Using AS2 Bridges

For the purposes of this post, I am going to expand on the demo used in the previous post by introducing AS2 bridges. I am not bothering to configure certificates, because this process has not changed since MABS was released, and it is well-documented on MSDN. Besides that, the focus of this article is on how the bridges connect, not so much about the implementation of encoding, etc. (But if you want to see how the certificates are used and the relationship of the public & private keys, I suggest having a look at this page which lays out the whole process in a very clear diagram.)

Let’s assume that Partner B requires the AS2 protocol for all B2B exchanges. The pattern in BizTalk Services therefore makes use of both EDI bridges and AS2 bridges, with separate agreements established for both:

Read more of this post

Creating EDI Bridges in MABS (post August 2014 Update)

In my last post, I talked about the new EDI features in the August 2014 release of Microsoft Azure BizTalk Services (MABS), particularly in regards to the separation of agreements and bridges. In this article, I’m going to discuss how you actually create & invoke these new bridges – especially since the experience wasn’t quite as intuitive as I would have expected and the documentation is still a bit light.

Prior to the August update, you used to create an agreement and this would automatically generate the send & receive bridges that hosted the agreement. Now that you create these artefacts independently, you can enjoy greater flexibility and reusability – but it also entails a few extra steps and requirements in order to establish it. Let’s walkthrough the process.

1. Create the Partner Profiles

You can’t really do anything without creating these. Nothing terribly significant has changed about this process in the latest update – except that you no longer have the option of creating an agreement template within a profile.

For this example, I’ve created two partner profiles with their respective “ZZ” identifiers:

Read more of this post

New EDI Features in BizTalk Services August 2014 Update

On August 12th, 2014, the BizTalk Product Team announced the release of the latest update to Microsoft Azure BizTalk Services (MABS), which includes the following enhancements:

• Ability to configure and manage agreements and bridges separately
• Ability to configure EDI delimiters at a Transaction Set level
• Enhanced digest and encryption algorithms for AS2
• Drummond Certification for AS2
• Support for advanced XML constructs in transforms

The enhancements to the mapper and the associated SDK certainly sound exciting, but this blog post will concentrate on the new EDI features. Support for B2B applications through Electronic Document Interchange (EDI) is one of the core capabilities and selling points of MABS, so Microsoft’s attention to this area is a well-placed investment.

Read more of this post