Publishing a WCF Service via Service Bus Relay in BizTalk Server 2013 (Part 2)

By Nick Hauenstein

This post is the eighth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013. It is also the second part of a two-part series on the Service Bus Relay features in BizTalk Server 2013 (Click here for part 1).

Last week, we examined how BizTalk Server 2013 (and even 2010 in that case) can use the Windows Azure Service Bus Relay to make a service endpoint available in the cloud without otherwise directly exposing the machine, and while being able to take advantage of the claims-based authentication and authorization framework provided by the Access Control Service. This was done in such a way that the service was hosted in IIS rather than within an In Process BizTalk Host Instance. This week, we are going to look at the other side – a service endpoint that is ultimately hosted in IIS.

In this case, we have been provided with a few new adapters to help us along the way (although, if we were really adventurous, WCF-Custom could have still done the trick for us in the past). These two adapters are the WCF-BasicHttpRelay adapter and the WCF-NetTcpRelay adapter:

ServiceBusRelayInProc

Last week, we published a NetTcpRelay endpoint that required some additional work on the client to authenticate with the service. This week, we’re going to go to the other extreme, and publish a WCF-BasicHttpRelay endpoint that will be more or less transparent to the client.

Starting the Game of Telephone

We’re going to start out with the BizTalk version of Hello World, a simple (technically unnecessary, but convenient for illustrative purposes) orchestration. This orchestration receives a simple single node XML message (the single node containing the text “Hello”), and returns a simple single node XML message (containing the word “World”) as the response:

HelloOrch

The Setup

With this, we’re going to go through the typical process of creating an in-process receive location, and then walk through the BizTalk WCF Service Publishing wizard to publish the service. Then we’re going to consume the service as it sits. Once that is complete, we will change up the end point so that it is listening over a Service Bus Relay, and see that the client can still call the service.

We’ll start with the Receive Location. In order to keep this in-process, we’re actually using the WCF-Custom adapter (since WCF-BasicHttp will force us to an Isolated Host):

BasicHttpEP

Now that we have an endpoint to receive messages, we need to create an endpoint that informs clients what messages we’re even interested in – our MEX endpoint. For that, we will go back to the BizTalk WCF Service Publishing wizard, and select the second option – the path less traveled:

MEXPublish_Step1

We will walk through this wizard, ignoring everything that mentions Service Bus publishing for now. Ultimately, what we will end up with is a local endpoint that is exposing the WSDL necessary to consume the service. We can use the svcutil.exe utility to download and share this metadata offline, or even generate proxy classes for re-use later if we’d like. In this case, we will be consuming it in place, and generating a client that can be used to call the service no matter where it lives.

Since we started with an orchestration, and that will define the shape of the incoming/outgoing data, we will select the Publish BizTalk orchestrations as WCF service option. Do note the plural orchestrations in that sentence, I see way too many single operation services out there. Winking smile

MEXPublish_Step3

After browsing for and selecting an orchestration, you should be presented with a list of all public port types within the assembly containing the orchestration. If they Type Modifier property on the Port Type is not set to public, it will not be listed, and you will be sad:

selectport

After you click through a few more screens, you will be prompted for the location where you would like this metadata hosted. In this case, it will be hosted within IIS on the local machine:

MEXPublish_Location

A few more clicks through the wizard, and the MEX endpoint is created and hosted in IIS – though the service endpoint itself is still hosted in-process.

A visit to IIS manage demonstrates that the MEX endpoint is now:

http://localhost/IOServiceMEX/WcfService_QuickLearn_BizTalk_Process.svc?wsdl

Consuming the Service

So far, we haven’t really done anything earth shattering, so consuming the service is equally simple. In this case, I just fired up Visual Studio, used the Add Service Reference context menu option in Solution Explorer, and then provided the MEX endpoint to the wizard. With the (local, not relayed) Service Reference in place, I added the following code to my console app:

[sourcecode language=”csharp”]using System;

namespace QuickLearn.WCF.Client
{
class Program
{
static void Main(string[] args)
{
var client = new IOServiceReference.WcfService_QuickLearn_BizTalk_ProcessClient("BasicHttpBinding_ITwoWayAsync",
"http://localhost:81/Sample/IOService.svc");

var response = client.ProcessMessage(new IOServiceReference.InOutRequest()
{
Contents = "Hello"
});

Console.WriteLine(response.Contents);
Console.ReadLine();
}
}
}[/sourcecode]

 

In the code above, the only moderately odd thing that I did was to use an overload of the client constructor that included an endpoint address. The reason for that was so I could more easily demonstrate the only change necessary as we switch to the WCF-BasicHttpRelay adapter.

To the Cloud

Since my client code is currently working and happy, I am ready to move this to the cloud. I am actually going to maintain my local endpoint (Receive Location) as well and simply add another Receive Location that will open the relay. The configuration of this one will be a little bit different, and certainly more involved.

NOTE: Before you continue, please be sure that you have read part 1.

I’m going to re-use my Azure Service Bus namespace from last week (though I have a new key for this week). I will start by creating a new receive location, selecting the WCF-BasicHttpRelay adapter, and then opening the adapter configuration. The first thing I am prompted for is the listen URI for the endpoint. This URI must incorporate my Service Bus Namespace, and should also add some identifier for the service after:

RelayEP_Config

The only other page of the configuration that I must visit is the Security page. This is where I get to determine if the client needs to provide some sort of authentication information in order to invoke the service, if the existence of the service is going to be discoverable by hitting the root of the namespace, and this is also where I set the authentication details for the access control service – so that BizTalk can prove to Azure that it can listen at that address and receive messages.

Since we don’t want to make changes to our client (other than the endpoint address), we will set the client authentication type to None. Then we need to click Edit under Access Control Service to bring up this dialog:

acs_credentials

In this dialog, we need to re-iterate our namespace (leaving the –sb suffix in-tact), and then then we also need to provide our super secret key which we can look up through the Azure Management Portal (see the previous post for details).

Once that is all in place, we’re set to Enable our Receive Location and then update the client to point to the relay.

Updating the Client

I mentioned before that we really only want to update the endpoint in the client. While this is true, the change of endpoint does (in this case) require a single simple change in configuration. The reason has nothing to do with the Service Bus Relay itself, but instead the change of scheme from http to https. An http address does not imply any security added in by the transport, it is just clear text over the wire. An https address, on the other hand, implies transport level security, as a result we need this small tweak to the otherwise auto-generated config file:

TransportSecurity

And then an update to our endpoint in code (everything else remains):

[sourcecode language=”csharp”]using System;

namespace QuickLearn.WCF.Client
{
class Program
{
static void Main(string[] args)
{
var client = new IOServiceReference.WcfService_QuickLearn_BizTalk_ProcessClient("BasicHttpBinding_ITwoWayAsync",
"https://uniquename.servicebus.windows.net/IOService/");

var response = client.ProcessMessage(new IOServiceReference.InOutRequest()
{
Contents = "Hello"
});

Console.WriteLine(response.Contents);
Console.ReadLine();
}
}
}[/sourcecode]

This gives us the very happy result:

consoleapp_result

Clearly this is one of the most robust, secure, and complex ways to write the word “World” out to the console.

The Take-away

The take-away here for the last two posts is that BizTalk Server 2013 gives you some new options for exposing select endpoints over the internet without touching firewall configuration, without involving IIS (if you don’t want to involve it), and without exposing the whole box out to the internet. All the while giving you the ability to work with clients that are aware of the setup (in the case of the NetTcpRelay) or are blissfully ignorant of the magic behind the scenes (in the case of the BasicHttpRelay).

SharePoint Integration without Cheating in BizTalk 2013

By Nick Hauenstein

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

In the Support for new Adapters section of the new features list for BizTalk Server 2013, you will find a very brief note without much explanation about the SharePoint adapter in BizTalk Server 2013:

BizTalk Server 2013 also provides updates to SharePoint adapter that gives users the option of choosing between using the client-side or server-side object model for connecting to a SharePoint server.

While this is nicely succinct1 and technically accurate, it really does not do a great job at explaining the implications. In order to uncover that, we actually have to look to the past – all the way to the year 2010.

A Brief History of Recent Time

In BizTalk Server 2010 (or more specifically, all versions including the WSS adapter), when we wanted to allow a BizTalk process to interface with SharePoint, we had to install a special web service that ran on the SharePoint server. This web service was installed by BizTalk and interacted with the server-side object model of SharePoint to provide access to data within SharePoint document libraries.

In a sense, to do a SharePoint integration, we had to cheat. We had to modify the target system to help adjust it to BizTalk – as opposed to leaving that system alone and integrating with it in a purely native way. Now one can easily argue that this is a slight exaggeration (since BizTalk did use an established interface in the form of the server-side object model), however it was still fairly inconvenient to have to install that adapter web service in each SharePoint environment with which I wanted to enable integration.

At around the same time that BizTalk Server 2010 was released, SharePoint 2010 was also released, and sported a brand new method (actually a few brand new methods) for accessing data – specifically the client-side object model. The client-side object model operates through a special service that SharePoint already exposes itself. This service is able to process bulk requests and the interaction with this service can be accomplished using proxy classes implemented in .NET, Silverlight, and JavaScript code – all of which more or less conform to the same naming and patterns for use.

With this client-side object model exposed starting in SharePoint 2010, the BizTalk team was able to take full advantage of it in the 2013 release of BizTalk Server. As a result, we now find this delightful option within the adapter configuration:

csom

Also, without having to install anything specific on the SharePoint server to support communication with BizTalk Server 2013, it opens up the door for the updated WSS adapter to access SharePoint Online with only a few minor tweaks for a different authentication method – and indeed the team made those investments as well:

sponline

The Little Things

Sometimes, its the seemingly little things that will make all of the difference. If you’re trying to tackle a SharePoint integration, and you’re on BizTalk Server 2010, consider the move up. Not only will it make you feel good to do things in a pure way that will satisfy those that hold tightly to the enterprise integration dogma, but it will also be less of a headache at installation time.

If you would like to learn more about the enhancements to the SharePoint Adapter, check out one of our upcoming BizTalk Server 2013 Deep Dive classes.

1 I say “nicely” succinct due to one of my college professors constantly saying of essays written by Freshmen: “Brevity is a virtue”.