Creating a near real-time streaming interface for Dynamics CRM with Node.js – part 2

This is the second post in my four-part series about creating a near real-time streaming interface for Microsoft Dynamics CRM using Node.js and Socket.IO. In my last post I presented an overview of how a near real-time streaming interface can be used with Dynamics CRM, and I discussed the solution approach. In today’s post I will show how to create the Node.js component of the solution to process messages received from Dynamics CRM and send notifications to connected clients.

In this solution, the Node.js application does two things. First, it listens for messages from Dynamics CRM. Second, it relays those messages via Socket.IO to clients that are listening for notifications.

Preparing the Node.js workspace

If you haven’t worked with Node.js before, you can download an installer package here: The installer package includes everything you need to develop and run Node.js applications. The Windows package includes a Node.js server, the npm Node.js package manager and a Node.js command prompt shortcut.

I’d be remiss to not mention that there is an IIS module called iisnode that allows you to run Node.js applications directly inside IIS, but the code I will be showing in this post did not completely work when I tried to run it on Microsoft’s Azure website using iisnode. The application seemed to run OK at first, and I was able to connect to with a Socket.IO client running in a web page, but I was unable to connect to it from a .Net console application Socket.IO client. This problem didn’t occur when I ran the Node.js application on a Windows virtual machine using the standard Node.js server that comes in the installer.

Once your development environment is ready to go, you’ll need to create an empty text file to hold the code. You can name it anything you want, but I call mine app.js. After you’ve created the code file, you need to install the Socket.IO module using npm. The command for that is “npm install”

Writing the application

Here is the complete source code of Node.js application. I’ll explain the relevant parts in more detail below.

var app = require('http').createServer(handler)
var io = require('')(app);
var fs = require('fs');
function handler (request, response) {
	switch(request.url) {
		case '/':
			response.writeHeader(200, {"Content-Type": "text/plain"});
		case '/post_endpoint':
			response.writeHeader(200, {"Content-Type": "text/plain"});
			if (request.method == 'POST') {
				request.on('data', function(chunk) {
  console.log('message received: ' + chunk.toString());
var port = process.env.PORT || 3000;
app.listen(port, function(){
  console.log('listening on *:' + port);

The first three lines do the following:

  1. Create an HTTP server that processes requests using the a function named “handler”
  2. Create a Socket.IO server bound to the HTTP server from step 1
  3. Load the Node.js “fs” module so the application can read files from the filesystem

Next we have the “handler” function that processes all requests. Using the case statement for the HTTP request URL, this function allows the application to serve two different pages. First, the application sends simple “Hello” text response to requests for the root URL. This will let us quickly determine the application is running. Second, for HTTP POST requests to the “/post_endpoint” URL, the application sends the data to all connected Socket.IO clients using the Socket.IO “emit” method. For this solution, only the “/post_endpoint” route is actually necessary.

Then the application checks whether the correct port number on which the HTTP server should listen has already been set in an environment variable. If not, it defaults to port 3000. Finally the application starts the HTTP server and begins listening for requests.

A comment about security

You may be asking yourself at this point how the Node.js application authenticates and authorizes clients to either post messages or connect as Socket.IO clients. The answer is that the code here doesn’t. I’ll discuss security in more detail in the fourth post in this series, but for now you’ll just have to trust me that it is possible to secure the Node.js application.

Wrapping up

That’s it for now. In my next post I’ll show how to write a plug-in to send messages to the Node.js application when events occur in Dynamics CRM.

Until then, have you tried Node.js yet? Do you think it’s ready for use in the enterprise? Let us know in the comments!

A version of this post was originally published on the HP Enterprise Services Application Services blog.

comments powered by Disqus