Following up from our last post, we will start off by creating a WSDL file for our service. WSDL files describe our web service by defining what operations are permitted and what our input and output data should look like. In our case, we will create a web service that will receive a queue name and return some stats such as estimated wait time, available agents and how many calls are waiting in the queue. We can then consume this web service in any other applications that require this data.
Let give our webservice a name ‘GetQueueStats’ and proceed to define our input and output parameters
The input will accept a single parameter called ‘QueueName’ and the output will return three values ‘EstimatedWaitTime’, ‘AvailableAgentsCount’ and ‘CallWaitingCount’. If we receive any stats, we will package the data with our 200/OK response and if there are any issues, a 500/Fault message will be sent.
Once our WSDL is defined we can create a sub folder in the BIN folder called WSDL and place our file in there. Once placed in the WSDL folder, it becomes accessible to anyone who wants to consume the web service. We need to now define our filter. The filter will define what we do with the request when the web service action is called. In our I3SOAPISAPIConfig.xml file, go the rules section and add a rule there for our web service. It is a good idea to explicitly set the rules so that any other requests can be rejected as a security precaution.
<Rule soapAction= “http://acme.com/SoapListener/GetQueueStats”>
<ForwardRequest server=”default_server” soapAction=”GetQueueStats” includeTransportInfo=”1″ clientName=”I3WebAction_GetQueueStats”/>
The xml file is well documented so it is fairly easy to understand what each parameter means. We should be now ready to write our handler which will accept the soap request. The basic building block for the handler is going to be:
Once we validate the request, we can use the ‘ACD Statistics (Queue)’ tool step to get our stats and package it as a response.
A quick test should give us the following request and response messages.
That’s all we needed to do to get our web service operational and with the powerful tools available within Interaction Designer, we can get it to do all sorts of interesting things. The handler and WSDL from this post are attached at the end of the post so you can have a go at creating your own web service. As always, let me know if you have questions about anything we talked about so far or any other topics you would like me to post about. I would also be keen to know how other people are using soap listener to meet their day to day requirements.