Building Blocks of Windows Azure BizTalk Services

By Nick Hauenstein

This post is the twenty-second in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

Since the last BizTalk Summit, there has been a lot of coverage within the greater BizTalk Community of Windows Azure BizTalk Services – the Azure-backed offering that brings pieces of the core BizTalk Server functionality to the cloud. This is something that QuickLearn had early opportunity to get hands-on with, and also something for which we were able to create labs (even before public availability). At the same time, it’s something that we haven’t really written about until now.

This week, rather than going through specific how-to guidance for pieces of the offering, I instead want to take a step back and look at the offering as a whole, so that we all understand the pieces that are there (and can see the forest through the trees). If you want to follow along, go ahead and download the Windows Azure BizTalk Services Preview SDK.

Once installed, you’ll find that Visual Studio has been juiced up with two additional project templates found under the BizTalk Services heading:

image

The first project type BizTalk Service allows you to define Itineraries (not in the ESB sense, though they do display a complete message flow, much like ESB), and the configuration for Bridges (much like a BizTalk Pipeline).

The second project type BizTalk Service Artifacts allows you to define schemas and maps (.trfm files, though you can convert your existing .btm files with some limitations using a tool provided at the SDK download link). The mapper is something I’m not going to be discussing any further, and as a result I will instead recommend this excellent blog post on the subject by Glenn Colpaert, and then also the official documentation on the conversion process/limitations.

So we can create these Itineraries, configure these Bridges, and deal with Schemas and Maps, but how does this all fit together within the context of Windows Azure BizTalk Services? To understand the answer to that, we have to first address the three things that Windows Azure BizTalk Services is trying to do:

  • Rich Messaging Endpoints (Itineraries + Bridges + Maps)
  • BizTalk Adapter Service (Service Bus Relay + Local Helper Service + BIzTalk Adapter Pack)
  • Business to Business Messaging (EDI Schemas + All of the Above)

Rich Messaging Endpoints

image

I’m going to start with the weirdest of the bunch – Rich Messaging Endpoints. The developer experience of this is similar (to a point) to defining an ESB Toolkit itinerary, but only inasmuch as you’re seeing the entire message flow within a single diagram. Here you can define certain sources (FTP/SFTP) for messages, and have them routed through Bridges (similar to Pipelines), and then routed out to certain destinations (for which CBR can be used to route the messages to one or multiple destinations).

In order to specify the settings necessary to connect to those destinations, you often find yourself within a configuration file defining WCF related binding settings directly:

image

Double-clicking on a bridge within the itinerary will bring up a semi-clone of the Pipeline Designer with a fixed set of components in place (as well as a location to specify maps to execute directly as part of the pipeline):

image

In terms of integration patterns, the bridges here are giving us a subset of the VETRO pattern (namely the VETR part of it): Validate, Enrich, Transform and Route. Where is the Route part of the equation you might ask? Well, you’ll actually find it in the Properties window for the bridge, by clicking the button in the Route Ordering Table property:

image

Here, we can do context-based routing that helps determine the destination for each message coming from the destination (though here, I have only connected a single destination endpoint).

BizTalk Adapter Service

image

What happens if the list of destinations doesn’t suit me? What if I want to take information from an SFTP drop, transform it into something that I could use to generate a record within a table in SQL, and then directly insert that record into my on-premise system? In that case, I’ll find myself reaching to the BizTalk Adapter Service feature.

This one has a nice list of dependencies that need to be in place before you can even use it (e.g., Windows Server AppFabric, BizTalk Server Adapter Pack), but once you have those, it’s fairly straight-forward to setup.

What it’s really providing is a single WCF endpoint that is exposed over a Service Bus Relay endpoint (and thus accessible from anywhere in the world – even if hosted behind a fairly strict firewall). This single endpoint can be passed messages destined for any number of internal systems that you can setup through the Server Explorer interface within Visual Studio. The BizTalk Team Blog actually had a pretty decent article on the topic back in June that sadly generated 0 comments.

Essentially, this is allowing you to bring your LOB systems into the mix to play along with everything else already mentioned (assuming those LOB systems have WCF adapters included in the BizTalk Adapter Pack).

Business to Business Messaging

The final capability that WABS is bringing to the table is B2B messaging (i.e., EDI). We have the ability through a special portal (still in preview) within the Windows Azure Management interface to create Parties and Agreements a la BizTalk Server on-prem. In fact, the same exact schemas are used to define the X12 messages, so if you’ve already had to do some schema customizations on a per-partner basis for in-house integrations, those same changes can now be brought to the cloud.

Pulling it All Together

Is this replacing BizTalk Server on-premise as we know it? Not quite. We have a lot of the same pieces: Transport (Limited)/Translation (Limited)/Transformation and Context-based Routing (Content-based Routing when using the Enrich stage of the Bridge). We are missing more complete process orchestration with exception handling / transactions / compensation (Orchestrations). We are missing rule-driven injectable logic (Business Rule Engine), among other things (though I’m stopping the list here to avoid debate about similar (but not quite) functionality in Azure in general).

So what do we do with this? Use it to solve integration problems that use a hybrid between cloud-based and on-premise resources (e.g., http://msdn.microsoft.com/en-us/library/windowsazure/hh859742.aspx). Use it when an on-premise BizTalk installation would be overkill for the task, but it can be done happily using the tools available in WABS. Use it to take over the most taxing parts of your B2B processing, leaving BizTalk Server on-premise to do those things it’s great at.

Ultimately, it’s up to you. BizTalk Server 2013 and Windows Azure BizTalk Services together give you the power to decide how to break up your integration work, and how you approach the integration challenges that are thrown your way.

If you haven’t yet given the SDK a download yet, go do it. Though the service is still in preview, the SDK has been available for quite some time now, and great things are right around the corner – so keep your skills sharp.

That’s all for now!

BizTalk Server 2013: Eliminating the Dependency on SQL Server 2005 Notification Services

By Nick Hauenstein

This post is the twenty-first in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

Over the last few years, I’ve had my fair share of times describing to people the installation/configuration process for BizTalk Server and more specifically the Business Activity Monitoring component. During those discussions, the oddball requirement for SQL Server 2005 Notification Services comes up and sparks a mild level of controversy: “Why would I need a component from an older version of SQL Server to use BAM Alerts?” Thankfully, with BizTalk Server 2013, I won’t be having that discussion as frequently.

It Looks Like You’re Writing a Letter, Do You Want Some Help?

BizTalk Server 2013 is now able to take advantage of SQL Server 2012’s Database Mail feature to send BAM Alerts. It’s pretty straight-forward to get all setup. You start by taking a trip over to SQL Server Management Studio, and choosing Configure Database Mail on the item of the same name under the Management folder in Object Explorer:

image

From there, you walk through a fairly straight-forward wizard to create a new profile and specify the SMTP server / credentials to use to send email:

image

While we specify the account here as bam@quicklearn.com – that’s ultimately NOT the address the alert will be delivered FROM (which instead will be bam@microsoft.com):

image

As a quick test (of both the settings entered throughout the remainder of the wizard, and the local SMTP server), I used the Send Test E-Mail feature to ensure all was happy with the setup (but this step isn’t 100% necessary):

image

And this email was the result:

image

What Does the BAM Side of Configuration Look Like?

Assuming you’ve already gone through the standard BizTalk Server Configuration wizard and enabled/configured all of the BAM related functionality, it becomes a matter of deploying the activity/views you’re interested in, and then enabling alerts for those views:

image

From there, the BAM Portal will expose the alert options within the UI. As an example, I created a quick BAM View that incorporated the concept of processing time – with the idea that if even a single item took too long to process, an alert would be triggered.

For an alert like this, the activity search page is a fine place to configure the parameters. Here we start with a query as if we are searching for an item where the processing time is greater than 5 seconds, but instead of executing the query directly, you can click Set Alert to use the query criteria as the basis for an alert:

image

After you click the button, it directs you to a page where you can define what the message looks like, and then after that is setup, to add subscribers for the alert. The subscribers can be either email boxes that will receive the notification, or a file share:

image

Prove That This Works

In order to follow through all the way (without SQL Server 2005 Notification Services), I quickly threw together some code to populate the activity with some data that should satisfy the alert condition, and cause the alert to fire:

image

After executing the code, I found this beauty sitting in the drop folder ready for delivery:

image

BAM!

So what are the limitations here (because there’s always a catch right)? Well, you can take this approach provided that you are using SQL Server 2012 along with BizTalk Server 2013. If you’re using SQL Server 2008 R2, then we still have to have that awkward discussion, where I link you over to the download page for the Feature Pack for SQL Server 2005 SP4 and then die a little inside.

BizTalk Server 2013 is trying to do things right, and make some of these stories cleaner, and more logical. There will be 3 more posts in this series to finish driving that home, and complete the grand tour of the new functionality. From there, we will look to development / course development battle stories, and also vNext functionality as information becomes available.

Until then, stay tuned!