ShoreTel Innovation Network members get access to several Software Development Kits (SDKs) that provide programmers with interfaces to various parts of the ShoreTel phone system. One of the core SDKs in the program is the ShoreTel Multi Line COM Object SDK known more simply as the COM SDK. The COM SDK allows the development of call and media control applications that work with the ShoreTel phone system.
One of the sample applications, “STMLBrowser,” is a useful tool for understanding what the ShoreTel phone system can do at a nuts and bolts level. As a very basic example of showing how the browser can be used we’ll look at a recent integration between ShoreTel Enterprise Contact Center and Salesforce.com call center adapter client, which I helped a customer navigate using the browser.
Our Salesforce client supports the display of Salesforce entities like contacts when an inbound call is received at a user’s phone. It does this by using out COM SDK to monitor for inbound calls and when one presents, uses the caller ID (ANI) to perform a lookup in the customers’ Salesforce.com database. Assuming it finds a match it displays the matching entity in the user’s web browser. This shows a typical screen pop in Salesforce:
Our client supports an alternative mechanism to determine which record it shows in response to a call. This involves the use of ShoreTel Call Properties. Call properties are named text strings that can be attached to calls by applications using the COM SDK or the lower level TAPI SDK. Our client looks for matches based on call properties whose names match a certain format. If the call property name starts with a certain prefix and matches a certain format then it and the associated value of the property are used to drive the Salesforce client’s screen pop.
Specifically, if the call has properties of this format:
This tells our adapter to search first in Salesforce for the “Field” in the “Entities” for those that match the “value” and only if that search comes up empty will the client fall back on a normal caller ID based search. For example, a call property like this:
would result in our client searching all of the Salesforce Cases for those where the CaseNumber field has a value of “00001001.” In order to integrate with ECC, we also support an alternative way of naming the property in this format:
Using this format, the above lookup would look like this:
You may now be thinking, “Great, I can get the ShoreTel Salesforce client to display a record I want by setting a certain call property but how would that call property get set?”
There are essentially two options: Write a server-based call-handing IVR using the COM SDK or configure an existing call-handling application that is capable of setting to ShoreTel call properties.
In this case, the customer was using the ShoreTel Enterprise Contact Center (ECC). ECC is capable of setting call properties but requires some fiddly configuration to make this happen. They configured ECC to solicit a case number from a calling party, attached it as a call property and then tested by having ECC send the call to an agent running the Salesforce client. They expected a screen pop based on the attached call property but instead got a screen pop based on the standard caller ID.
The core issue the belief that the call property was set correctly yet our Salesforce client wasn’t reacting as expected. Something appeared to be wrong with the call properties but how do you check call properties? This is where the browser test tool comes in.
When we got involved we had them run our browser on the same PC where the Salesforce client was running. This shows the main window of the browser when it is first started:
At the top it has a menu and toolbar. Under that are the three panes that comprise the main user interface of the browser. The left pane shows a tree of the lines (extensions) and any calls active on those extensions being monitored and possibly controlled using the browser. The top right pane shows details of the line or call select on the left and the bottom right is a log of events, request and responses. To initialize the browser, we click the green check mark or select the Initialize option off of the first menu item (MLControl.) When the browser is initialized on a PC where the ShoreTel TAPI interface has been installed (which happens when Communicator is installed) then it will show the single user’s line:
Note the various call details shown. Selecting the Call IDs tab would display the caller ID and other caller number fields including the call’s DNIS. Selecting the Call Data tab shows the call’s ShoreTel call properties in the bottom of the two panes:
Armed with the browser, the first thing we checked was what call properties were we receiving at the client when a call that passed through ECC and where the ECC script developer believed they were correctly setting the call property. Our first check revealed no call properties being set by ECC. With this knowledge they dug into the requirements for configuring ECC to correctly store the call properties.
Once the problem in ECC’s configuration was fixed we tested again with another call. It still didn’t work. We checked the call properties again and this time we got the properties shown here:
When we looked closely at the property names we found they were incorrectly formed. Instead of starting with “_ST_SF.” Or “_STCC_SF.” they started with “_STCC__ST_SF.” As a result, our Salesforce client ignored the call properties.
This time when we tested again it worked great. Our Salesforce client saw and processed the call properties and correctly screen popped the page selected by the caller when they interacted with ECC.