IVR and Routing Interfaces

What a busy month January was!

Following on from my previous post we now have GVP 8 running and configured to use Nuance ASR and TTS resources. We have started to prototype the speech recognition IVR applications for release 2 in Composer 8.0.2.

The release 2 IVR applications will need to interface to both SAP CRM and a third party payment service provider. Given the requirement to take payments the method of integration will obviously fall under PCI scrutiny.

To support the IVR integration work I have been developing a prototype which provides a generic interface between IVR applications and/or optionally Genesys Routing strategies and SAP CRM data services.

The prototype interface is implemented as a Window Communication Foundation (WCF) service host which can be deployed standalone as a Windows service or hosted under Microsoft Internet Information Services (IIS). The advantage of deploying the interface as a standalone Windows service is that we can create a Third Party Server application in CME and monitor the interface through SCI.

The primary function of the interface is to abstract the data services provided by SAP subsystems and to expose a simplified view of these services to the IVR applications and/or Genesys routing strategies. At the core of the interface is an object cache which manages the fetching and storage of SAP data entities in order to reduce any delays in providing responses back to the calling applications.

Security Considerations

The advantage of building the interface using WCF is that WCF implements many security standards and has a wide range of features available. One of the most important aspects of security is authentication. WCF can be configured to use many authentication methods:

  • Anonymous caller
  • User name and password
  • Certificate
  • Windows

The method of authentication is specified in Endpoint bindings. Therefore, the prototype interface can be configured to specify the required authentication method.

However, it is assumed that to meet PCI requirements the endpoints exposed by the interface will be configured in a message-based authentication mode with the use of mutual X.509 Digital Certificates.

Once certificates are setup and configured, the message exchange from the client to the interface service is digitally signed first by the client’s X.509 Digital Certificate (private-key) and then encrypted for the interface service with the service’s certificate (public-key). The interface is able to decrypt the message with its own private key and then validate that the message from the client is not tampered with via the client’s public key installed in its Trusted People certificate store. The message response from the interface to the client is then correspondingly signed first by the service and then encrypted for the client only by the public key found on the client’s X.509 Digital Certificate.

IVR Clients

For IVR applications developed in Genesys Composer the logical choice would be to expose the interface service by configuring a WCF endpoint using a standard Web HTTP Binding and to call it through either a Web Service Block or a Web Request Block.

The problem with this approach is that on the standard composer web blocks the Authentication Type property can only be set to anonymous or basic authentication (username and password). E.g. there is not support for certificate based authentication. In addition:

  • The Web Service block won’t work if the Web Service parameters are named double since URS considers it a reserved keyword
  • There are limitations on the WSDL definitions supported

Another big problem relates to being able to process Web Service results. When the “Map output values to variables” property is set to true, the Output Result property maps the Web Service response keys to AppState variables. If Map Output Values to Variables is set to false, the entire Web Service response will be assigned to a variable.

Therefore, it the web service result contains complex types we would end up with either lots of AppState variables to process or a variable containing the whole response to parse.

The alternative is the ECMAScript block which can be used to invoke JavaScript. This seems to be a better option. E.g. write a WCF client and instantiate it as a .NET object since we can then implement our choice of authentication and encryption.

Another advantage of this approach is that the WCF client if required can convert .NET objects in the response into a JavaScript Object Notation (JSON) string using standard .NET Framework 3.5 classes. JSON is the standard format used by Composer e.g. the data returned by the Web Service block is converted to JSON format.

Routing Clients

As I mentioned above the prototype interface provides services to both IVR applications and Genesys routing strategies.

We could use the same approach as above to access the interface from routing strategies (both for older strategies developed in IRD and for newer URS workflows developed in Composer).

However, Genesys provide an alterative approach using a custom server which implements the Genesys External Service Protocol (ESP). ESP is a mechanism by which you can extend the functionality available in routing strategies.

The Platform SDK provides the tools you need to write your own server component to listen for and respond to ESP requests. Therefore, in addition to supporting a routing interface via WCF e.g. HTTP bindings, my prototype interface also implements the functionality of an ESP server which allows the services exposed to be consumed via External Service blocks within a standard Genesys strategy.

I’ll cover off how this is done in a separate post.


Leave a Reply