REST calls from Genesys Routing Strategies

Summary

This article is a continuation of my previous discussion regarding web service access from Genesys strategies.  In that article, I described how to access traditional/SOAP-based web services from Genesys Interaction Routing Designer(IRD)-created routing strategies.  For this article, I show how to access REST-ful web service implementations with IRD strategies.

HTTP Post Implementation

Figure 1 depicts a simplistic/non-production ready strategy that executes a HTTP POST call with a JSON parameter.  The web service returns a phone number that the strategy subsequently uses as a transfer target.

Figure 1

In Figure 2 I'm using a Multi-assign object to build up a JSON-formatted string that will be used as an input parameter to the POST call.  The resultant string looks like this:

{ "value" : '12345678', "ani" : '<the actual ANI of the inbound call to this strategy>' }

That string is assigned to a Genesys variable named 'json'.

Figure 2

Figure 3 shows the General Tab of the IRD web service object.  Here I'm setting up a HTTP POST call to a SSL-based REST service.  I explained how to configure Universal Routing Server (URS) for SSL access in this post.  The input parameter of this HTTP call will be sent as an application/json content type in the request body.

Figure 3

The Security tab of the web service object is depicted in Figure 4.  This tab sets up HTTP Basic Authentication for this POST call.  In this type of authentication credentials are passed in clear text, hence, by itself, basic authentication is inherently insecure.   However, combining basic auth with HTTPS does provide a fairly secure interface.  The authentication credentials are encrypted in TLS.

Figure 4

Finally, Figure 5 shows the Result tab of this web service object.  As was discussed in my previous post, Genesys URS will return the results of a web service call into an IRD List object.

Figure 5

In Figure 6, I pull the first item off this List object and assign it to an IRD variable called 'transferTarget'.  This web service call returns a JSON object with 3 properties.  The value of the first property of this JSON object is a phone number.  That phone number (now in the 'transferTarget' variable) is passed to a TRoute function which initiates a transfer.

Figure 6

As an aside - This strategy is loaded against a Genesys SIP Server (SIPS) route point.  You'll notice I have a "Silence" treatment object as the first object in this strategy.  That object is there to cause an 'answer' of the inbound call.  By answering the call (with either Genesys Media Server or Stream Manager), this subsequent transfer is implemented by SIPS as a SIP REFER.  If the call is never answered in the strategy (meaning no voice treatment of any sort), the transfer from the strategy is implemented as a re-INVITE, which keeps SIPS in the signalling path for the duration of the call - or - a 302 Moved, which is rejected by my SIP trunk service provider.  A REFER transfer takes SIPS out of the signalling path.  Whether a Re-INVITE or REFER/302 is initiated on the transfer is determined by how the oosp-transfer-enabled and refer-enable options are set on the Genesys trunk object used for the outbound transfer.

HTTP Delete Implementation

Figure 7 depicts a simple IRD strategy for illustrating a REST Delete operation.  This strategy accepts a call transferred from 3rd Party IVR, CTI framework, etc.  Based on ANI and DNIS, the strategy performs a fetch of the data associated with the call that was stored by the 3rd Party system.  The fetch is implemented as an HTTP Delete.  The Delete returns the data associated with the call and clears that data item from storage.

Figure 7

The first IRD object in this strategy (Multi-Assign) is depicted in Figure 8.  Here I'm building up a URL to the REST interface using string concats of the DNIS and ANI values of the inbound call.

Figure 8

The IRD Web Service object is shown in Figure 9.  The 'Web Service URL' parameter is set to the URL I built up in the previous step.  The 'Method' is set to DELETE.  Otherwise, this object is configured identically to the previous (Figure 3).

Figure 9

The remainder of this strategy is straight-forward.  The value fetched from the REST call is attached and then the call is routed to a skill.  The agent receives a screen-pop with that attached data item. Copyright ©1993-2024 Joey E Whelan, All rights reserved.