#IoT2CRM: Alternatives for the gateway – Dive into BizTalk – part 1

BizTalk is up and running, CRM is in place, the Raspberry Pi is waiting to get in action. I’m finding my way back in BizTalk. This week I spend a great amount of my time on reading about BizTalk. In my previous article  I described what I intended to build in the first place, the BizTalk variant of the Web API Controller. I found some great articles about setting up such gateway using BizTalk.

The previous gateway was based on REST services that could be accessed anonimously by IoT devices. It turns out that BizTalk 2013 can offer the same functionality without having to write code, it’s a matter of configuration. Ironically the most easy way of writing a good set of configuration files for SharePoint is by using Visual Studio 2012 combined with the BizTalk SDK and toolkit.

In this special birthday edition, I’ll do a crash course BizTalk development. *Fasten your seat belts!*

Personal rant: Why don’t the BizTalk 2013 and CRM 2013 SDK’s support Visual Studio 2013 out of the box? For CRM I had to do some hacking (see: Getting the CRM 2013 SDK to work with Visual Studio 2013). For BizTalk I chose the easy route: doing a side-by-side installation of Visual Studio 2012 and rerun the BizTalk 2013 Setup to add SDK support.

Crash course BizTalk

In CRM we are used to work with Solutions. In our solution we build the application experience we want to offer to our customers. The solution can be easily exported and imported at our customer’s CRM environment. BizTalk works with a similar mechanism. Instead of Solutions, BizTalk works with Applications.

In the screenshot below, I show an explorer view of all the artifacts in a BizTalk environment (screenshot is taken from the BizTalk Administration Console).

BizTalk Administration 2

Under the Applications node, a list of all installed BizTalk applications is show, per application (e.g. IoT2CRM) all artifacts are shown. In order to implement our gateway, we need the following components:

  • Send Ports
  • Receive Ports
  • Receive Locations
  • Schemas
  • Maps
  • Pipelines

BizTalk is all about XML, all data flowing through the system (called: messages) is internally represented in XML. This is where schemas come in place. The maps describe the transformation between messages.

As a matter of fact the entire configuration of BizTalk is done in the form of complex XML. This is where Visual Studio comes to the rescue.
After having installed the BizTalk SDK on your system, you will notice (if you’ve met all prerequisites) that Visual Studio suddenly has a BizTalk project type. Choose an empty BizTalk project and you are ready to go.

Visual Studio is also the way to deploy our application to BizTalk. In order to enable deployment to BizTalk from within Visual Studio, you need to edit the project properties of your Visual Studio BizTalk Poject.
After opening the project properties, navigate to the tab “Deployment”.


On this tab, you have to specify the Application Name, you want to use in BizTalk. If the application does not exist, Visual Studio will create it  . You can leave the other settings as is. If you choose to install the Visual Studio assembly into the Global Assembly Cache, you need to sign your project.
After saving the settings, you can deploy the project to BizTalk using the context menu when right clicking the project.

Now we have the development tools in place, it is time to get back to where we left off.

The gateway we built before, had REST POST methods defined on the Web API Controller. For now I’ll focus on one method only: the registration of the malfunction.


The method has four parameters. In order to get these parameters into BizTalk, we have to define a PropertySchema in the Visual Studio project. Filling in the Property Schema is pretty straight forward and will eventually look like this


When we build and deploy the project to BizTalk, we will find the Property Schema under the Schema node of our application.

We fire up the BizTalk WCF Service Publishing Wizard from the Start Menu. This Wizard will guide us in the process of creating a new Receive Port, Receive location and will take care of the registration of a WCF service hosted on our Internet Information Server.


In the wizard we have to specify the transport type (adapter). We choose. WCF-WebHttp. We specify the BizTalk application name to create the receive location. And we click Next… Next…


We choose to create a One-Way receive port. Our IoT devices are working via the fire-and-forget philosophy. Then we click Next.


We specify the name of our virtual directory on IIS and allow anonymous access (important!). Clicking Next results in the generation of the receive location and the receive port.

Now we have the basic receive port and location in place, we need to some configuration on it in order to enable message reception. We open up BizTalk Administration console, navigate to the location we just created and open it’s properties.


In this section we need to replace the HTTP method and URL mapping with our method:

<Operation Name='RegisterMalfunction' Method='POST' Url='/?deviceId={deviceId}&amp;deviceType={deviceType}&amp;errorCode={errorCode}&amp;errorMessage={errorMessage}' />

Finally we can map the incoming variables to variables BizTalk will understand. BizTalk always needs namespaces, therefor I copied the namespace from the property schema file in Visual Studio.


At this moment the initial configuration is done, and BizTalk should be able to receive messages sent through a REST POST.

In the next Article I’ll test if the configuration works and if we are capable of receiving messages.