#IoT2CRM: Alternatives for the gateway

In the #IoT2CRM: Time to get connected articles, I implemented a scenario in which I connected a Raspberry Pi to Dynamics CRM. The scenario was built on a tight budget and resulted in a custom scalable, extendable and secure gateway implemented in C# with just a couple of lines of code. In the final lines of the last article of that series “#IoT2CRM: Time to get connected – part 5: Rise of the devices!” I mentioned that I would love to replace my gateway by Microsoft BizTalk, the 500 Lbs. Gorilla.

I gave that thought some time and then it struck me, why only Biztalk? There are more integration products out there which deserve to be in the spotlight. One of my colleagues (thanks Erik) came with a fairly unknown product called Neuron ESB. Neuron ESB is an alternative for BizTalk, at least the website states that it is a preferred application integration and SOA platform for the Microsoft Stack…  At first sight the product looks exactly like BizTalk.

In the next couple of articles I’m going to implement a gateway using BizTalk and a gateway using Neuron ESB. In the past I’ve done a couple of BizTalk implementations. For the proof of concept I’ll use Biztalk Server 2013 Enterprise Edition and I’ll use Neuron ESB 3.5 (30 day evaluation version).

The scenario that I’m going to implement will be the same as the scenario in the “#IoT2CRM: Time to get connected”  series. As I’m familiar with the concepts and terminology of BizTalk, I’ll use those terms.


In the image above, we have on the left side the outside world where all those IoT devices are calling home (which is sending their messages to our servers). In the center we have either BizTalk or Neuron ESB. I’ll try to configure both to accept messages from out IoT devices (It might be necessary to change the implementation on the IoT side).
The task of the gateway is to collect, persist, transform and pump the messages into CRM, represented on the right side.

Upfront we don’t know how many incoming messages we can expect. Therefor it is important to have a scalable gateway. What we learned from the “ #IoT2CRM: Time to get connected”  series, is that CRM is not capable of handling a massive flooding of incoming messages.

We we look at a high level to the gateway we can distinct a couple of tasks:

  • Receive incoming messages
  • Persist incoming messages
  • Transform incoming messages
  • Send out new messages

In BizTalk terminology this could be resolved by declaring an incoming port, an outgoing port, a pipeline and a transformation component. Straight forward, nothing fancy one would say. However the devil could be in the details. I have some uncertaincies like:

How do I collect the incoming messages from the Internet?

How do I send out messages to CRM?

How do I transform the incoming message to a CRM entity?

Is there something like a standard CRM connector?

Can I build a no-code solution?

Schematically the gateway build by either BizTalk or Neuron ESB would look like this:


At the left side we have an incoming port. The incoming port is responsible for collecting the message. Once received, the message is handed over to the pipeline. The pipeline can be seen as a transport bus, responsible for transferring the message from A to B (and persisting it).
While being transported in the pipeline, the message passes a transformation point. After being translated the old message stops to exist and from that moment on we have a type of message that CRM understands.
Once the CRM type of message reach the outgoing port on the right side, the message is delivered to and stored in CRM.

In the next article I’ll dive in the implementation of the gateway, using BizTalk. Sounds like fun to me!

Leave a Reply

Your email address will not be published. Required fields are marked *