I’ve been developing a Windows application that consumes Broadsoft XSI events. Broadsoft has a “comprehensive range of VoIP Applications in a Single Platform” and XSI is a way to consume data produced by their platform, allowing integration of a modern switchboard service with other types of applications.

The Broadsoft XSI API is designed for the web. You can interact with their web service using a callback URL or an event channel. You use a callback URL in a web application and an event channel when the application you’re developing is not available over an URL. An event channel boils down to a streaming HTTP connection. This post is about what I learned developing the application using an event channel.

Broadsoft has a sandbox for application developers. There’s a simple procedure to request one and it is very well supported, both during setup and when you need maintenance, like a password reset. You can use this environment to check your code without possibly disrupting the live environment.

The Broadsoft API uses XML or JSON for data exchange. You’ll find yourself inspecting messages and I installed tooling which easens that task. I’ve been using JSON Viewer and XML Notepad 2007 on Windows to inspect data produced by the Broadsoft XSI API and I installed Fiddler2 to get an idea of what data is being transmitted. The application I developed uses log4net for logging and I used Log Expert for live logfile tracing. You should definitely install tools like those when you start developing.

XSI Events work on an event channel, which is essentially an HTTP connection that’s not closed. The – remote – HTTP server uses it to publish messages intended for the client that initiated the connection. I was not able to find too much examples of streaming HTTP in a Windows application, and this one pointed me into the right direction. The event channel is kept alive when there’s a heartbeat: a message once every 30 seconds, depending on the configuration in use by the Service Provider. I’m on the safe side with a 20 second interval. Be sure to start the heartbeat right after channel creation as you’ll find yourself dealing with channel termination messages in about half a minute after initially creating the channel. In case you’re wondering, yes – it’s in the documentation, but there were more questions about this subject. The remote server uses the event channel to publish events. An event is an XML document. Almost every event needs a confirmation message and the remote server will close the channel when the event is not responded to.

The application stopped every now and then due to an System.Net.Sockets.SocketException. It wasn’t obvious when those occurred – which made it hard to debug – until I stumbled upon this post. It appears the CLI enforces limits on the number of parallel connections to the same host. By default, you can create 2 parallel connections to the same host and you’ll find the SocketException as soon as you try to create the next connection. I finally used the configuration to make sure the number of parallel connections to a web application is set to a number close to 10 because the HTTP connection consumes 1 connection, the heartbeat consumes a connection every 20 seconds and you may be processing an event or two which need confirmation. I think you get the idea 😉

I found some errors every now and then while processing events. It appeared that my application received partial XML documents. These partial documents were not well-formed. It appeared that the remainder of the event was in the next transfer. An XSI event is serialized into an XML document, and I was able to process the event once I concatenated these transfers. One must keep the original order in mind, which should be obvious.

I hope this post will save you some time and frustrations. Let me know if you encountered something I did not cover here and I’ll be more than happy to add it.