This is the final 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 showed how to write the plug-in code to send messages from CRM to the Node.js application. In today’s post I will show how to configure a client to receive and process notifications from the Node.js application, and I’ll also discuss some general considerations related to this solution.
My first post in this series included a video that showed two clients connected to the Node.js application via Socket.IO. One was a web page that displayed notifications using JavaScript, and the other was a simple C# console application. You can find the code for both of the clients from the video in the “client-src” directory in the solution on GitHub.
Web pages
Creating a web page to display notifications received from the Node.js application is incredibly simple. For the web page I demonstrated in the introductory video I first load JavaScript libraries for Socket.IO and JQuery:
<script src="https://cdn.socket.io/socket.io-1.2.0.js"></script>
<script src="http://code.jquery.com/jquery-1.11.1.js"></script>Then I connect to the Socket.IO endpoint and register a callback function to append the notification text to an element on the page with JQuery:
var socket = io("http://lucas-ajax.cloudapp.net:3000");
socket.on('message', function(msg){
var obj = jQuery.parseJSON( msg );
$('#records').append($('<li>').text(msg));
});Of course you’re not limited to displaying just raw text. Once you parse the JSON message, it’s a fully-fledged object that you can work with as you like. For example you can create a web page client that lists case updates by displaying the case numbers hyperlinked to the record in Dynamics CRM.
The code for this is only marginally more complicated than the raw stream example above.
var socket = io("http://lucas-ajax.cloudapp.net:3000");
socket.on('message', function(msg){
var obj = jQuery.parseJSON( msg );
if(obj.entity==="incident"){
$('#records').append($('<li>'+obj.operation + ' - <a href="https://lucas-ajax.cloudapp.net/Lucas01/main
}
});As before, first the page creates a connection to the Socket.IO endpoint, and then it registers a callback function. This time, however, the callback function includes a check for incident entities, and the append step creates a hyperlinked case number. The code for this example and another one for contact updates is included in the solution source code on GitHub.
Other clients
The C# console application I showed in the introductory video was also incredibly simple to create. First I needed a way to communicate with the Socket.IO endpoint. I used the Socket.IO Client Library for .Net (also available from Nuget -> Install-Package SocketIoClientDotNet). Once I included the library in the project, the code ended up looking a lot like the JavaScript examples above.
var socket = IO.Socket("http://lucas-ajax.cloudapp.net:3000/");
socket.On(Socket.EVENT_CONNECT, () =>
{
socket.On("message", (data) =>
{
Console.WriteLine(data);
//socket.Disconnect();
});
});In addition to C#, you can create Socket.IO clients in other languages, too. The Socket.IO FAQ has links to client libraries for Java and iOS clients.
Security considerations
As I mentioned in the second post in this series, this solution lacks any mechanism for authenticating or authorizing clients, but I said it was possible. There are two typical approaches to securing Socket.IO interfaces, cookie-based and token-based. This article on "Token-based authentication with Socket.IO" gives a good overview of the problems with the cookie-based approach and goes into some detail about how to implement token-based authentication. In addition to securing the Socket.IO endpoint, you’d also want to consider securing the endpoint where Dynamics CRM posts notifications. You could use the same token-based approach for that, too.
I would also suggest that depending on how you’ve deployed Dynamics CRM and how you need to grant client access, you might not need to worry about security at all. For example, in the case notification example above the only information exposed via the interface is the case number and whether it was created or updated. To see anything else, the end user actually has to open the record, and regular Dynamics CRM security will do the rest.
Wrapping up
I hope you’ve enjoyed this series, and I hope I’ve given you some ideas about how you could implement and use a near real-time streaming API for Dynamics CRM in your own projects. If you have any questions or want to continue the discussion, please share your thoughts in the comments.
A version of this post was originally published on the HP Enterprise Services Application Services blog.