Recently I’ve been playing around with creating my own web services to consume in a relatively new product of ours called Interaction Process Automation. Our group has also been exploring the use of web services in our newly developed web administration for 4.0 and we’ve created a few for some newly developed mobile applications. So recently I’ve had web services on the brain and it seemed like a good topic for my first post on the Tech Lounge.
I’ve had many questions in the past about our plans to expose API’s to Customer Interaction Center in the form of Web Services. Web services are some of the most easily consumable API’s and when they conform to standards can be used by many languages across a variety of platforms. While the desire for an API such as this is understood, these requests were not given serious consideration until recently. Here were a couple excuses I’ve given in the past on why we weren’t pursuing more web services:
1.) Most of our API’s have never been intended to be transactional. They do a lot of client side caching, managing state, and most deal with real time events. If you would like to understand this better you could read my previous posts on Session Manager and IceLib.
2.) Authentication mechanisms and and the handling of events would be different based on the intended use. Some uses would require end users to provide credentials and for the service to maintain the users session. Others may rely on a service account to perform actions on behalf of end users. Some use cases would need to rely on a polling mechanism to receive events and others could take advantage of dual bindings. It would be difficult to anticipate the needs of all consumers and create a one size fits all web service.
3.) Internally we did not consume very many web services in our products as most of our client applications run on the Windows desktop. Creating web services just did not align well with other initiatives we had.
4.) Another (somewhat naive) reason I always held was how easy it was to create a Web Service. My thinking was “Geesh we’re giving you a .Net API, just wrap the thing in a web service. It’s not that hard.” Well it turns out creating the actual web service is easy but managing the first two issues mentioned does take a bit more thought.
All the reasons listed above really boil down to the fact that at least until recently it has been inconvenient for us to provide public web services. The amount of work to produce, the expertise needed, and alignment with other initiatives just didn’t exist. Well that is changing due to the uptake in our CaaS offering and our deeper exploration into mobile.
The good news is, until we start exposing public web services, you have a very solid API in IceLib and many web service solutions can be pretty straight forward to implement. For those of you that haven’t already attempted this feat, I’ll take the rest of this post to explain how to create a simple web service to Customer Interaction Center in 10 steps.
For this example I’ll assume that our web service will maintain a single connection to Session Manager and all requests will be made through this single IceLib session. We will not require authentication to call the web service and we’ll also assume IC 3.0.
1.) Create a WCF Service Application in Visual Studio. For this example I used VC10 and I called the service IceLibService and the interface for this service was IICService and the implementation class was ICService but of course you can call them whatever you want.
2.) Add ININ.IceLib as a reference to your project. The preferred way would be to install the IceLibSDK and reference drive>Program FIles (x86)Interactive IntelligenceIceLibSDKININ.IceLib , or if you have a client installed you could also reference the assembly installed in <drive>Program FIles (x86)Interactive IntelligenceICUserApps.
3.) Next, in the project properties (right click the project and select properties). Change the framework to .Net 3.5, 3.0 or 2.0. In CIC 3.0 IceLib was compiled using .Net 3.0. It will not work to reference this from a 4.0 assembly. It’s easy to forget and you may beat yourself up a little as I have if you miss this step.
4.) In the IICService interface define a web service method named GetSessionManagerVersion(). This is the one method we will expose.
5.) Unlike a database connection we want to avoid re-establishing authenticated connections to IC for each call into the web service. The next couple steps deal with this requirement. The image below shows how to specify the service behavior, create a dictionary to hold our sessions and initialize the dictionary in our default constructor.
It is especially important to note the service behavior. We want to reuse each session so we are going to set up the service such that each method calls into a single instance of this web service as opposed to starting a new process for each method call which would defeat the whole purpose of a map to maintain the session. Also with concurrency set to “single” we are saying that we want this to be single threaded. I do this here for simplicity to avoid the extra few lines that would be required to make this example thread safe. If your service has larger scalability requirements you may want to use multiple and make sure to manage concurrency using appropriate methods.
6.) Next implement two methods “GetSession” and “ConnectSession”. These two methods will attempt to reuse the IceLib session whenever possible or establish a new session in the case of a lost connection or if the session was not previously created.
7.) Implement the GetSessionManagerVersion web service call
8.) Add a service account to your IC Server. This is as simple as adding a user in Interaction Administrator. You’ll normally want to exclude the user from the company directory. Note: If you are using an IC user as a service account for your web service, then that IC user account will need permissions to perform any action taken by the web service. For the purposes of this example no additional permissions are necessary.
9.) Specify the service account credentials in your web.config file. Note: A better way to accomplish this would be to associate an NT account to the User in CIC and use NT auth in the IceLib connection. This would prevent you from having to save passwords in clear text on your hosting machine.
10.) Make sure your IC Server has an IceLibSDK license. This is required for any 3rd party connection to the IC server.
That’s it. I implemented something very similar to this to launch IPA processes for users spread across multiple IC servers. You can modify it to update a users status or any multitude of IC capabilities exposed by IceLib. What I’ve tried to demonstrate is that creating a web service to interact with IC is simple with the key aspect being how you maintain your IceLib sessions.
I hope you found this post useful. If you have something in particular you would like me to blog about I’d be glad to hear it. I certainly wont have time to address every topic, but I have a lot of great resources around me and can probably address a relatively wide range of issues with my sweet spot being our core CIC client applications and API’s (see my bio).
– Todd Zerbe