Context

This feature has a lot of potential and will be a real productivity boost for developers. This blog post is a variation of the same demo in the context of BizTalk Server. It will cover remote debugging of a pipeline component that is deployed in a BizTalk Server running in Azure Virtual Machine.

Pre-requisites

Azure subscription

If you want to follow along with the contents of this blog post, you need a Microsoft Azure subscription. You can sign up for a free one-month trial here.

BizTalk environment setup

For the purposes of this blog post, it is assumed that you have a BizTalk Server environment setup in Azure Virtual Machines. To know more, you can refer to my previous blog post on getting started with BizTalk Server in Azure Virtual Machines.

BizTalk Server and Windows Azure SDK

In the development machine, install Azure SDK for .Net 2.3 and BizTalk Server 2013 SDK. BizTalk Server SDK can be installed from BizTalk Service media. If you don’t have easy access, you can always try installing SDK from BizTalk Server 2013 evaluation edition.

Recap: BizTalk Server environment is setup in Azure Virtual Machine and Visual Studio is running locally in my development machine.

Setup

Archive component

I wanted to debug a custom pipeline component. Instead of creating one myself, I wanted to re-use something that the BizTalk community had created. I landed upon a TechNet wiki that lists down the various custom pipeline components available. It is a great collection. Kudos to the TechNet wiki contributors for compiling the list, and to the BizTalk community for authoring and sharing these components.

I decided to make use of an archiving component. This component is created by Steef-Jan Wiggers, one of the product MVPs. The pipeline component does what the name suggests – archive the message to a file share.

BizTalk setup

The BizTalk setup is a very straight forward one. It is a message in, message out scenario. In the receive pipeline, the archive component is used.

Enabling remote debugging

Enabling remote debugging in Azure Virtual Machines is very easy. In your Visual Studio’s Server Explorer, you can sign in to your subscription and list down the Virtual Machines.

In this case, my BizTalk environment is present in btsdevvm.

Enabling remote debugging is as simple as right clicking the VM, selecting “Enable debugging” and click OK.

Remote debugging

Once debugging is enabled on the VM, I can right click the VM and attach a debugger.

I can then view all the processes in the remote VM and attach to it!

Note that I can view the BizTalk host processes (BTSNTSvc) in the remote machine. I can select the host process to which I want to attach the debugger to, and start debugging.

And when a message is dropped to the location of the receive port in the remote BizTalk machine, you see the debugger hit in your developer machine!

You can now continue to debug as if you are debugging locally. I believe this feature would be extremely useful and productive to developers who want to debug and troubleshoot their applications remotely.

Hopefully, this gives an overview of leveraging the cool new “remote debug in Azure Virtual Machines” feature in the context of BizTalk Server. I have used pipeline component as an example.

Invoke ReSTful Web Services with BizTalk Server 2010 is a very good wiki explaining the steps involved to invoke a REST service using BizTalk Server 2010. Apart from creating the BizTalk artifacts, it includes creating a message inspector, an endpoint behavior and a behavior extension element. If you are well versed with WCF, this might be a breeze. If you are not and/or you are creating it for the first time, it could be quite intimidating.

You can still do it in BizTalk Server 2013. However, it is a lot simpler now thanks to the new WCF-WebHttp adapter. Think of it as the REST adapter. Apart from creating the BizTalk artifacts, it includes configuring your send port, providing the REST service endpoint and specifying the authentication. The key difference here is that all this is done via configuration in send port, and the implementation details are handled by the WCF-WebHttp adapter.

Lets take a look at what it takes to connect to a REST service using BizTalk Server 2013

Connectivity to Windows Azure Marketplace

Almost all cloud services that are out there today expose their operations via REST. To start with, lets take a look at how we can consume a data feed from Windows Azure Marketplace. Windows Azure Marketplace is an online market for buying and selling finished SaaS applications and premium data.

Some of these datasets are free and one can subscribe to it via Windows Live Id. One such dataset is US Air Carrier Flight Delays. It exposes one operation called On_Time_Performance. The Details tab in the same page lists down the REST API details

REST API : https://api.datamarket.azure.com/oakleaf/US_Air_Carrier_Flight_Delays_Incr/v1/
Operation : On_Time_Performance

The service is authenticated with an account key and customer ID which is associated with the Windows Live Id.

Here are the configuration settings in BizTalk Server to connect to that REST service end point.

Send Port

The send port makes use of the new WCF-WebHttp adapter to invoke the REST API call.

Send Port configuration

General tab

Address (URI) : https://api.datamarket.azure.com/oakleaf/US_Air_Carrier_Flight_Delays_Incr/v1/On_Time_Performance
HTTP Method and URL Mapping : GET

Address is set to the REST API to be invoked. In this case, HTTP Method is GET. If you are using any other HTTP Method such as PUT, POST, DELETE, PATCH, HEAD, etc. it is supported as well.

In this case, we are invoking only one REST API operation and hence we have provided the full URI in the Address box and we haven't specified any URL mapping in HTTP Method and URL Mapping. The specifics of URL mapping is covered later in this blog post

Security tab

Security mode : Transport
Transport client credential type : Basic

Security mode is set to transport since the REST API endpoint makes use of https. Transport credential type is set to basic since the Windows Azure Marketplace dataset is authenticated using username and password.

Username and password is set in the Username credentials settings.

Messages tab

Suppress Body for Verbs :  GET

While performing a GET operation, the message body is usually suppressed and it is the case here as well. To ensure that the outgoing GET API call doesn’t contain a message body, the Suppress Body for Verbs is set to GET.

While making a PUT/POST API call, a message body is usually required. Hence if you are making GET, PUT and DELETE operations, and GET/DELETE do not require message body while POST operation does then you need to set Suppress Body for Verbs to GET, DELETE.

To recap, the configurations that were set in the send port were related to the REST API end point, the HTTP method, authentication details and a setting to suppress message body.

With this config driven approach, connectivity to Windows Azure Marketplace dataset is now established.

Connectivity to Windows Azure Storage

Another example of a cloud service that exposes REST API is Windows Azure Storage. You can store files in Windows Azure Blob Storage and as you can expect, one can perform basic operations such as

• List containers in a storage account [GET]
• List files in a container [GET]
• Get the content of a specific file in a container [GET]
• Create a new file [PUT]
• Delete an existing file [DELETE]

The config driven experience is pretty much the same as the one outlined for Connectivity to Windows Azure Marketplace. One key difference in this scenario is that we can now perform more than one operation in the REST endpoint. We can create 5 different endpoints each capable of performing one operation, or we can create one send port which can perform one of the 5 operations.

Here are some interesting settings to take a note of

Send Port Adapter Configuration

General tab

Address (URI) : https://btstecheddemostorage.blob.core.windows.net
HTTP Method and URL Mapping :

<BtsHttpUrlMapping>
    <Operation Name="ListContainers" Method="GET" Url="/?comp=list" />
    <Operation Name="ListFiles" Method="GET" Url="/{mycontainer}?restype=container&amp;comp=list" />
    <Operation Name="GetContent" Method="GET" Url="/{mycontainer}/{myblob}" />
    <Operation Name="CreateFile" Method="PUT" Url="/{mycontainer}/{myblob}" />
    <Operation Name="DeleteFile" Method="DELETE" Url="/{mycontainer}/{myblob}" />
</BtsHttpUrlMapping>

In the previous example of Connecting to Windows Azure Marketplace, only one operation was involved. Hence, the address was set to the actual REST API end point and HTTP Method and Url Mapping was set to the HTTP method, namely GET.

Here, the intent is to perform more than one operation. Hence, the Address is set to the base address of the REST API. HTTP Method and URL Mapping contains the list of operations that can be invoked. Note that each operations contains its HTTP method and the relative URL of the REST API.

Variable mapping

If you look at the relative URL closely, you will notice that it contains placeholders, {mycontainer} or {myblob} as opposed to actual value. This is a new concept in BizTalk Server 2013 and it is referred to as variable mapping. Lets take a moment to understand what it means.

In most business flows, you want to invoke an operation (REST API call) based on the business context. For example, get the products associated with a particular opportunity. In this case, opportunity ID will be present in the context of the runtime message and not a hardcoded value. Since we are making outbound REST API calls, the intent is to make sure that we enable such API calls based on the business context as well, if required.

Lets take ListFiles operation as an example. Its relative URL is defined as
“/{mycontainer}?restype=container&comp=list”. Here {mycontainer} is a placeholder and its value is associated at runtime from the message context. This mapping of the placeholder/variable to the property in the message context is known as variable mapping.

The exact mapping can be set in the Variable Mapping Edit section.

Note that the variables/placeholders namely myblob and mycontainer are now mapped to properties BlobName and ContainerName from property namespace https://ConnectToAzureStorage.PropSchemaAzureStorage

The property schema is part of BizTalk artifacts and created outside the scope of this send port configuration.

Understanding the role of BTS.Operation

When a message comes into BizTalk and is routed to the send port, any one of the five operations can be invoked.

However, we need to specify which operation to invoke. This is achieved by setting the BTS.Operation context property in the incoming message. This property is present as part of a system property schema.

Property schema : BTS.bts_system_properties
Target namespace : https://schemas.microsoft.com/BizTalk/2003/system-properties
Property (element name) : Operation

This can be set as part of property promotion in disassembly stage, custom pipeline component, or in orchestration. As long as it is set before it reaches the send port, BizTalk Server will know which operation to invoke.

Behavior tab

Another key difference here is the authentication mode for Windows Azure Storage. Unlike Windows Azure Marketplace, it is not basic authentication. Instead, it has its own authentication mode.

BizTalk Server 2013 supports authentication mode for Windows Azure Storage out-of-the-box. This is achieved through an end point behavior.

In the behavior tab, right click EndPointBehavior and click Add Extension

Notice the azureStorageBehavior. Select it and provide the azure storage connection properties

Note that all the new WCF adapters in BizTalk Server 2013 provides ACS authentication support. So, if your service end point is authenticated via ACS, you can configure the ACS settings in the Security tab.

On the other hand, there are also services which do not make use of ACS and have their own custom authentication. In these cases, it is really simple to create a custom end point behavior and use it in a way similar to the one shown above for Windows Azure Storage.

Conclusion

Hopefully this blog post provided an overview of the possibilities to connect to REST services using BizTalk Server 2013.

As part of this event, we launched the public preview of Windows Azure BizTalk Services – the new Platform as a Service (PaaS) offering in Windows Azure. To know more about it, refer to our team blog post and get started. We had a whole range of sessions covering everything that we have released both on premise as well as in the cloud. We had sessions on BizTalk Server 2013, BizTalk Server 2013 in Windows Azure Virtual Machines and the new Windows Azure BizTalk Services.

All the sessions are now live in Channel9 for on-demand viewing. I have compiled all the BizTalk sessions here for reference. I will publish follow up blog posts about the new features and the scenarios we have enabled.

Introduction to Windows Azure BizTalk Services

Microsoft Integration Vision and Roadmap

B2B collaboration on Windows Azure

Microsoft BizTalk Server 2013 in Windows Azure IaaS

Special note: This session was delivered by our MVP, Stephen Thomas.

Developing hybrid solutions with Microsoft BizTalk Server 2013 and Windows Azure

Extending Windows Azure BizTalk Services

Introducing Microsoft BizTalk Server 2013

When you launch the  Windows Azure portal, there are a few things which are interesting to note

Virtual Machine is no longer in preview mode

When you click on New and the UI pane shows up, you will notice that the Virtual Machine option does not have a preview tag associated with it.

BizTalk Server 2013 images are available in the platform gallery

There are two modes to create a virtual machine through the portal: quick create and from gallery. When you click on creating an image from the gallery option, you will be provided with a set of platform images which are available.

There are three images of BizTalk Server 2013 that are now available in the gallery

• BizTalk Server 2013 Enterprise
• BizTalk Server 2013 Evaluation
• BizTalk Server 2013 Standard

I will cover each of these images in more detail in future posts.

The licensing options are mentioned in the BizTalk team’s announcement blog post. There are two  modes of licensing options: license mobility and per-hour licensing. You can also learn more about the per-hour pricing here.

Getting started – Portal experience

Lets first create a BizTalk Virtual Machine through the Windows Azure portal. Once you log into the portal, you can click on New, select Virtual Machines and then the “From Gallery” option. You will be presented with a set of images available in the platform gallery. The screenshots for both of these steps are present above. Select  BizTalk Server 2013 Evaluation image and then click next.

In the Virtual Machine configuration pane, there are a few interesting points to note

• You are now prompted to enter an explicit user name instead of the default “Administrator” user name.
• You will notice some new options for the Virtual Machine size options

After you have provided the values in this pane, click next

In the Virtual Machine Mode pane, you can enter details such as DNS name, the storage account in which the virtual machine’s VHD will be persisted and finally the region in which the Virtual Machine will be deployed.

Here, I have used standalone virtual machine mode, set the option to automatically generate a storage account while provisioning the VM and also set the VM to be deployed in West US region. You can choose to change it as per requirements. Once you are done setting the values, click next.

In the Virtual Machines options pane, leave the settings as-is.

You can choose an availability set, for this getting started experience I am going to skip it. Click Finish.

You will notice a status in the portal stating “Creating the virtual machine…”

Once the VM is created and is being provisioned, you can see an entry in the portal as well.

It takes about five to seven minutes for the BizTalk VM to be created and available for access.

You can then connect to the machine using the connect option in the portal and RDP into the machine.

Within a few minutes, you are now ready to get started with your BizTalk applications. Once you connect to the machine, BizTalk Server is already installed in it. You can then configure BizTalk Server before using your BizTalk environment.

Getting started – PowerShell experience

Windows Azure provides a really rich PowerShell experience, which allows us to script and automate the tasks done through the portal. While it is easy and fun to create a new Virtual Machine through portal, it becomes repetitive if you want to create 10 different VMs. Instead, you can automate the whole process. There are many more use cases for automating these tasks, and I will cover it in more posts in the future.

You can download Windows Azure PowerShell from here. Windows Azure team has some really good documentation around getting started with PowerShell. To set your subscription details, please refer to the documentation titled Get Started with Windows Azure Cmdlets.

Once you have set your Azure subscription, you can now create a new BizTalk Virtual Machine in your subscription. One of the details that you require to create the virtual machine is to get the name of the image based on which you want to create the Virtual Machine. There are many images in the gallery and you can additionally have more custom images as well. Here, we want to grab a BizTalk image. Launch the Windows Azure PowerShell window, or any other PowerShell console and import the Azure PowerShell module. You can make use of the following script to list BizTalk specific images.

Similar to the portal experience, we will create a BizTalk Server Evaluation image. Make a note of the Evaluation image name. We will use it soon.

Lets now create another BizTalk Server Evaluation VM. The only difference this time around is to create it programmatically.

Here, we are creating a VM based out of a specific image, assigning admin user name and password, and also setting the cloud service and the location of the data center. One new option is the –WaitForBoot option. This signals the script to wait for the VM to be fully provisioned and running before executing other tasks. I re-used the script from Michael Washam’s blog post. He is a Senior Program Manager in the Windows Azure team. His blog has a lot more exciting posts on all things related to Windows Azure Powershell.

Note that the portal also reflects the new BizTalk Server Evaluation VM that was created through the PowerShell script. Also, Remote PowerShell is enabled by default on all virtual machines created through the latest Windows Azure PowerShell cmdlets. This is secure and really useful for automation.

Hopefully this gives a really high level overview to get started using BizTalk Server 2013 in Windows Azure Infrastructure Services.

This release of BizTalk Server contains a whole set of new capabilities, including new adapters, performance improvements, support for latest standards etc. Watch out the BizTalk Server team blog for more updates. I will keep posting some of the interesting features/details of BizTalk, summarize useful information and then link to the team blog for announcements.

One of the easiest ways to get started is to use the Evaluation edition. You can download BizTalk Server 2013 Evaluation edition from Microsoft Download Center. There are a bunch of new features which are worth checking out, including but not limited to

• REST Connectivity
• Service Bus Connectivity
• ESB Toolkit Integration
• Dependency tracking
• New Adapters - SFTP
• Simplified Sharepoint integration
• Dynamic Send Port improvements, etc.

I will blog about some of these interesting features in more detail in the future.

Did you know that we also provided a set of updates to BizTalk Server 2013 already? You can read more about it here. The unique aspect to note here is that these updates are now available via Microsoft Update as well. The following fixes are part of this update

• FIX: User cannot perform certain database-related operations in BizTalk Server 2013
• FIX: BAM tools cannot be configured in a multi-node BizTalk Server 2013 environment
• FIX: The vertical scroll bar on the target schema does not work correctly when you use Visual Studio to design a BizTalk Server 2013 map

More details about the fixes are available here.

With BizTalk Server 2013, we have also moved from a processor based model to a per-core licensing model. You can learn more about it here.

You can find the MSDN documentation for BizTalk Server 2013 here. Nitin from our team recently did a fantastic post on the documentation release strategy. Follow his blog for more updates.

 Lets get started with BizTalk!