Friday, January 3, 2014

Implementing a Cisco GED-145 Gateway with Node.js

Summary
Cisco's GED-145 is an API + protocol definition for integrating their enterprise-grade contact center product with 3rd-party systems.    This document discusses using JavaScript with node.js to implement a GED-145 application gateway.

Background
Cisco's enterprise-grade call routing engine is called Intelligent Contact Management (ICM).  ICM is a suite of software components that provide ACD, CTI, and reporting for large-scale contact centers (thousands of agents).

The ICM routing script editor interface provides drag/drop functionality for creating call routing scripts.  Those scripts can employ of wide variety of out-of-box routing logic to deliver a call to the appropriate agent target - such as time of day, longest available agent, most appropriately skilled agent, etc.  ICM provides a mechanism to extend that routing logic using the GED-145 API.  I believe 'GED' is an acronym for 'Geotel Engineering Document'.  Geotel was the company that created ICM.  Cisco acquired Geotel way back in 1999, but some of the Geotel naming conventions clearly still exist.

GED-145 is a TCP socket-based API that provides the ability to query 3rd party systems for routing information from within an ICM routing script.  A middleware application, called an 'Application Gateway', can be developed to act as a server to the ICM routing engine and client to the 3rd party system being queried.  Figure 1 depicts the overall GED-145 architecture with a web server as the 3rd party system.


GED-145 defines a low-level byte format for messaging between the ICM Router and Application Gateway.  Figure 2 depicts the byte format for GED-145 messages.



In addition to message formats, GED-145 defines the messaging protocol between the Router and Application Gateway.  The protocol is of a simple Request/Response type.  Figure 3 shows message format and protocol for one of the simplest message and exchange types - the Heartbeat.  The Heartbeat request/response protocol provides application-level keep-alive functionality.

Implementation

Figure 4 below depicts my overall approach for this application.
  • Application Gateway - node.js TCP server application.  It acts a server to the ICM router and speaks GED-145 in that direction.  It also acts as a client to a web server and speaks REST in that direction.
  • ICM Router Simulator - node.js  TCP client application, simulating an ICM Router.  Provides a mechanism to test the GED-145 protocol and apply load to the Application Gateway.
  • Web/Rest Simulator - node.js/express.js web server providing a contrived REST interface.
  • App Logger - winston.js logging implementation.  Provides debug and error-level log messages to console and log files.
  • Message Handler - miscellaneous node.js functions to manage creation and parsing of GED-145 messages.
  • Rest Client - node.js client that is utilized within the Application Gateway.  Provides a HTTP client to the REST simulator.
  • Test Runner - node.js interface to the Router Simulator.  Implements test suites for speed testing, TCP socket error injection, and load testing.

Performance
The Application Gateway code was deployed on a Centos 6.4 VM with 1 vCPU and 1 GB vRAM.  Below are the results of the following test sets.  
  • Speed Test:  tests the latency of a series of simple Heartbeat Requests and Responses
  • Error Test:  series of Open/Close/Query/Param/Heartbeat messages that are artificially broken up during socket writes to simulate the streaming nature of TCP.  Additionally, nonsensical messages are injected.
  • Load Test:  similar message set to the Error Test, but with no invalid messages nor artificial message breaks.
2014-01-03 07:49:20.257 - Starting Raw Speed Test
Speed Test Completed
Number of Transactions: 10
Elapsed Time: 13 ms
Average Elapsed Time per transaction: 1.3 ms

2014-01-03 07:49:20.399 - Starting Error Test
2014-01-03 07:50:20.405 - Error Test Completed
Random Synthetic Message Fragmentation:0-4
Transaction Count:2569
Induced Error Count:428
Caught Error Count:428
Elapsed Time:1 min
Average number of transactions/sec: 42.812

2014-01-03 07:50:20.406 - Starting Load Test
2014-01-03 08:50:20.447 Load Test Completed
Synthetic Message Fragmentation:none
Transaction Count:233756
Error Count:0
Elapsed Time:60.001 min
Average number of transactions/sec: 64.931

RAM/CPU Usage

Pidstat was utilized to log resource usage of the app gateway process during execution.  CPU usage ranged from 1-13%.  RSS memory usage ranged from 82 - 104 MB.  V8 garbage collection kicked in at 104 MB and reduced RSS down to 84 MB.   Below is the pidstat output reflecting the high-water marks on CPU and RSS usage.

Max CPU
#      Time       PID    %usr %system  %guest    %CPU   CPU  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
 1388756055     16289   12.35    1.21    0.00   13.56     0    143.72      0.00 1059116  82060   8.04  node

Max RSS
#      Time       PID    %usr %system  %guest    %CPU   CPU  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
 1388763210     16289    6.61    1.20    0.00    7.82     0     15.03      0.00 1076988 104292  10.22  node

No comments:

Post a Comment