In the previous issue of the “Envoy® Updates” article ( Building a “Better” Soft Phone, Part Four ) covering the Envoy® Soft Phone (ESP) advanced features I had stated “…as a teaser, consider that ESP communicates with Envoy® Server and that one of the plugins available among standard plugins is the Envoy® Reporting plugin …”. Well, I was just teasing, forget about it. Today, let’s talk about the possum that is as big as a cat that I keep finding in my garage. Ok, ok, I will cover the reporting plugin – guess I kind of set myself up for that one – but you are missing a good story. So what does the Envoy® Reporting plugin do? It allows a developer to track virtually any piece of data or event occurrence within an application and it captures the data points real-time. So how is that different than going in and providing database write operations throughout your application? I am glad you asked – let’s explore that in more depth.
Abstraction, Connectivity and Resource Management – So, if you went into your application and sprinkled database write operations throughout the code to capture key data points, you would get the data you wanted in your database. However, the code would be for a specific database vendor (e.g. SQL Server, Oracle, DB2, Sybase) so it would not be portable to another database. Wait, you did your homework and used an abstraction layer to communicate with the database – you used ODBC or ADO / OLEDB so you can use more than one database – good decision! But what if your application was running within an enterprise server such as a web service or an IVR platform – now every single instance of the application needs a database connection – that could be a terrible performance hit on your database server. I guess you could “fix” that issue and just task your development team with writing a dynamic database connection management layer – and triple the time, money, and expertise needed for your original reporting project. But then again, you may need the same logic for web service connection resource management later. Envoy® Server is built to efficiently scale to a very large set of client connections (agent desktop soft phones, enterprise applications, embedded clients in 3rd party tools, etc) and Envoy® Server is also built to effectively manage resources so that all those client connections have access to all the backend systems and data stores. In other words, Envoy® Server manages a configurable number of connections to your backend systems (in this case your database) for you and takes care of sharing those connections with all the clients that connect – allowing your developers to capture data and not worry about managing connection resource pools. Furthermore, Envoy® Server can be configured to dynamically grow the connections for an unexpected “heavy” traffic period (such as your peak calling hour) and then shrink the connections back to the normal operating limits. The database connections managed by Envoy® Server are also capable not only of communicating to different database types, but also in parallel if needed – so mirroring of data can occur to multiple data stores of different types – all without writing any additional database code! You can read more about Envoy® Server here: Envoy® Server Multi-Client Endpoints, Envoy® Server Resource Management, and The Power of Envoy® Server, the Dexterity of .NET.
Application Programming Interface (API) – The Envoy® Reporting plugin is built based upon the same principles of the other Envoy® plugins – to consume XML messages. It is really that simple – all the powerful functionality is accomplished using a very simple, standards based, easy to read message set built purely upon XML. VEXIS “ate our own cooking” by using our Envoy® Client and a simple XML client side API to build out the reporting interface – no proprietary technology hidden under the covers. I am sure you noticed the previous sentence mentioned “Envoy® Client” – but that is not a “catch” – you are free to use any client program you want to use to talk to the Envoy® Server because it understands multiple message framing protocols. But you may actually want to use Envoy® Client so that you take advantage of the easy XML syntax and the fact that the API is exposed as a C/C++, COM, and .NET API. The same easy API is callable from virtually any programming language such as the latest .NET (C#, VB.NET, ASP.NET) technologies to low level C code and even legacy Visual Basic applications – allowing your developers to use the programming language with which they are most comfortable – or the ones they are forced to use to integrate with legacy code. There is even a special version of the API used to allow enterprise class applications, such as an Interactive Voice Response (IVR) system to make use of the client in a network optimized manner. You can read more about the API here: Envoy® Client Software Development Kit (SDK).
Network Efficiency – The Envoy® Reporting plugin is part of the Envoy® Framework that encapsulates components that operate together as an event driven system. What does that mean? Well, we really only care about certain “events” (caller transferred to agent for example) that occur in our enterprise – not every single tick of the second hand on the clock. So make your enterprise applications track and report only the important events, not everything! Consider a call center that has 500 agent desktops – each one running a softphone application in a “pull” model – so each desktop would ask (poll) the server “is there a telephony event for me”? The server would have to reply to each desktop application – with 500 hundred separate replies – and maybe only half of those desktops have an actual event they need to be notified of from the server. To make matters worse, the “poll interval” – how often the clients ask for “anything new” – could be configured such that it occurs every second, or even more frequently. This “pull” model makes the server work hard and the network full of unnecessary traffic. With the “push” model, the clients tell the server to send events to them only when they occur and then the clients do not bother the server again; the server notifies the client when the specific event they want to know about happens –the server pushes the event to the client. The “push” model is more efficient because the server only sends messages when they are necessary and network traffic is considerably less “chatty”. So now consider that if you want your softphone or other agent desktop application to write data to the database – it would have to “poll” (pull model) your CTI server for that data at designated intervals – and all you really want is to capture certain data points as they occur on the telephony switch, not clog up your network. The Envoy® Framework operates in the push model and only concentrates on the events you configure it to capture or act upon. The Envoy® Client used in conjunction with the Envoy® Reporting plugin will allow your applications to only capture relevant data based upon important events that occur throughout your enterprise instead of just “logging everything”.
Data Availability and Usability – So now you have the data in your database. Whether you used the pre-built high efficiency components of the Envoy® Framework or opted to use your own code implementation, you now have to get all that data into a useable user interface for end user consumption. That word “usable” is a big one! Not everyone wants data displayed in the same format. And not every individual has the same ability to grasp the importance of the data based upon one single visual representation of the data – so get to cooking on that user interface that does multiple data views, supports multiple data export formats and can dimension the data based upon various date ranges as well a real time views. Or, just let the pre-built ERA-Envoy® Reporting and Analytics do all that work for you.
There are still many more advanced features of the Envoy® Reporting plugin not listed here that your enterprise can put to use immediately; please make sure and check out some of the related articles.
Richard Wolff, Director of Software R&D