#IoT2CRM: Time to get connected – part 3: The gateway awakes

It has been a quite hectic week, the CRM project I’m working on is consuming almost all of my time. In the meanwhile I’ve been working on the IoT gateway and it is coming along :)

As I mentioned in my previous post, the gateway is going to be divided into two parts, the Web API controller and the Dispatcher (see image below). Together the Web API controller and the Dispatcher provide the secure gateway functionality that I need in order to expose my CRM environment to the internet.


The design goals of the gateway are:

  • Scalable
  • Secure
  • Lightweight
  • Persistent

All these goals need to be met on a tight budget.

Web API Controller

At the moment I’ve implemented the Web API controller (red square in the image).  The Web API controller is offering two public interfaces:

  • RegisterMalfunction(deviceId, deviceType, errorCode, errorMessage)
    Register the malfunction the device is sending.
  • RegisterUsage(deviceId, deviceType, usageData)
    Register usage data the device is sending.

Once the message is received by the Web API controller, the message is written to a temporary folder (one folder is containing error messages, the other folder is containing usage data) on disc where it waits to be processed by one of the dispatchers.

The code itself is actually not rocket science. I implemented the Web API controller using a MVC Web API project in Visual Studio. Besides the routing table defined in the global.asax and the folderpath stored in the web.config,  the project is containing an ApiController class (the public REST interface) and a Model class (in which the data is represented).

The methods on the Controller class look typically like this:

public void RegisterMalfunction(string deviceId, string deviceType, string errorCode, string errorMessage)
// collect data
Device device = new Device();
device.DeviceId = deviceId;
device.DeviceType = deviceType;
device.ErrorCode = errorCode;
device.Data = errorMessage;

// store data

As you can see, all the methods do on the controller, is to gather the data and instruct to save it. The model class is responsible for saving it to a proper location.

I didn’t implement error handling, decryption or validation for the sake of simplicity. When you consider to take this code into production, you might need to add this functionality.  Once the dispatcher has been built, I’ll put up the entire solution for download (under the MIT license).

More to follow in the next couple of days. Stay tuned!