It almost sounds like a new Terminator movie. 2015–02–24 is the day the devices came alive…. They started the broadcast…
Hmmz… It’s is not that dramatic, but last night I managed to get the whole train running. In this final article I’ll describe the setup and my thoughts about the proof of concept I built.
On the left hand we have the Raspberry Pi 2, connecting to the Gateway in the middle, processing messages in CRM on the right.
In one of my previous articles I described the concepts of the gateway; which can be considered as an abstraction layer that can be used to hook up any device, using any language to send data to CRM.
To proof this bold statement, I decided to use Python on the Raspberry Pi as my weapon of choice. Frankly, I was really impressed by the ease of building the application (I don’t have any knowledge of the Python language) and I was really impressed by the speed of the interpreted language. In a couple of lines I wrote the program below using the Idle Python editor on the Raspberry Pi:
import urllib import urllib2 def sender(): for a in range(1000): url="http://192.168.2.8/Gateway/api/device/RegisterMalfunction/?deviceId=rpi" + str(a) + "&deviceType=RaspberryPi2&errorCode=002&errorMessage=someerrormessage" print("sending " + str(a)) urllib2.urlopen(url,"") sender()
I made a small shortcut; instead of using a domain name in the URL, I used the IP address of the Gateway server (this was due to a small DNS problem in my network, thanks to the @#!* router provided by my ISP).
On the Raspberry, the process was triggered by calling the sender() function. This resulted in the following output.
On the foreground you see a python shell window running. At a great pace 1000 records were sent to the gateway. The gateway server (hosted on the laptop), responded immediately, resulting in the following screenshot.
What you see on the screenshot, is the Web API controller, represented by a test page hosted on IIS. On the foreground you see a console application processing files. The files are picked up at a high speed, every 50 (or so) files the process gets a little hick up. On the right side you see the list in CRM hosted on the Hyper-V virtual machine (also hosted on the laptop).
Within 2 minutes, 1000 incoming messages were stored in CRM. It has to be noted that I only used one thread. Resulting in a processing capacity of about 30.000 messages per hour. The handling speed can be improved by at least a factor 5 to 10 running on the same set up. It would take a little redesign in the Web API controller, by distributing the incoming messages over multiple folders and having the dispatcher to use multiple threads to monitor multiple folders.
What this proof of concept learned me was the following:
The gateway I designed and implemented is really robust. I can interrupt the process, restart it and the messages continue to process.
The gateway is capable of handling a flooding of messages. Messages are stored once received.
It is easy to hook up any device, using any language. The abstraction will take care of the processing.
- On a tight budget you can build with a couple of lines of code an Enterprise class solution, allowing safe and scalable communications between the IoT world out there and CRM within the organisation.
What I intend to do is to build a similar scenario using BizTalk instead of the Gateway. I’ll tweak the gateway in the meanwhile. I want to find out if the home made gateway can beat the 500Lbs. gorilla BizTalk.
Stay tuned for more fun to come!