Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
SimonZeacomSimonZeacom 

CTI Toolkit call related searches

I have successfully got my CTI adapter running and talking to our CTI system and everything is working well. The one thing I am having difficulty with however is searching based on attached call data.

What I want to be able to do is specify which field I wish to be matching on within Salesforce and then match the data I specify (which we obtain in out CTI system when we receive an incoming call).

I can't figure out how I need to specify the search data in the mapAttachedData that is passed into the CCTIUserInterface::OnCallRinging function.

I have been reading the developers guide on page 47, Displaying Call-Related Records, but this doesn't really show how exactly to do it in code. The Demo code only searches based on ANI (which does work fine in my app).

Can someone please show me a code example of how you set up the key value pairs please?

Also what is the easiest way to find out what the object and field names are? Are they the same as you see if you look at App Setup, Customize, (object), Fields in the web interface?

Thanks.

Simon

werewolfwerewolf
Actually, the demo adapter also includes a search using related data.  Try hitting Winkey-Shift-X.  It'll search on Case.CaseNumber=1001.

If you want to specify data to search on, make a key-value pair in your mapAttachedData parameter where the key is a Salesforce object name, a period, and a Salesforce field name, and the value is the value you want to search.  For example:

Key: "Account.AccountNumber"
Value: "12345"

Provided you actually have an account with that AccountNumber, and Account is in your Inbound softphone layout (this one is a common source of errors), the Account will pop instead of whatever came of the ANI.  If that search returns no results, it automatically falls back on the ANI search.

The easiest way to find out the object and field names is to use Force.com Explorer: http://wiki.apexdevnet.com/index.php/Apex_Explorer
SimonZeacomSimonZeacom
Ah yes, thanks I have found that code in the demo now. My code was pretty close and with some tweaking I now see this in the logs:

04/03/2008 02:10:47 p.m.: CCTIAppExchangeSearchThread::ThreadSearch: Error running IVR query:
Title,Name,Id From CONTACT Where Description=''
                                 ^
ERROR at Row:1:Column:41
field 'Description' can not be filtered in query call.
04/03/2008 02:10:48 p.m.: CCTIAppExchangeSearchThread::ThreadSearch: Error running IVR query:
Title,Name,Id From CONTACT Where Description=''
                                 ^
ERROR at Row:1:Column:41
field 'Description' can not be filtered in query call.

I think I now need to work out the soft phone layout to include the fields I need. Hopefully I can figure that out from the demo code.

Thanks for directing me to the Apex Explorer too. That is VERY handy!

Thanks!

Simon

Oops, I do actually have a valid description value in my code. I pasted the wrong bit of the log file above.



Message Edited by SimonZeacom on 04-02-2008 06:57 PM
HardhatHardhat
If Description is a long text field, you won't ever be able to filter on it -- those are never filterable.
SimonZeacomSimonZeacom
The Apex Explorer gives the type as 'text area'. I changed my code to search on case number and that worked!

Thanks for the tip. I don't actually want to search on Description. I just chose that at random as a field to test my screen popping with.

Simon
werewolfwerewolf
Right, "text area" = "long text field", so that explains that.  Glad to hear it's working now!
SimonZeacomSimonZeacom
Yep, it's working quite well now. I like how you can search multiple fields and it displays them in the soft phone.

The one problem I still have though is it is displaying it all twice! So I make an inbound call and I see:

Caller ID89634
Duration00:06
AccountUnited Oil & Ga…
Case00001026
Caller ID89634
AccountUnited Oil & Ga…
Case00001026

Once I get that one worked out I think I am there.

Simon
werewolfwerewolf
Whoa!  That's really bizarre, I've never seen that before.  What are you searching on that's causing it to show up twice?
SimonZeacomSimonZeacom
Sorry for posting a large chunk of logs but it's probably the easiest way to show what I am doing! The CallInfoChange and PhoneStatusChange events are form our CTI system. I simply made a call in and currently have two hard coded searches:

mapAttachedData[L"Case.CaseNumber"] = L"00001026";                                                               
mapAttachedData[L"Account.AccountNumber"] = L"CD355119-A";

I don't think it is specific to my searches anyway since it was doing it for CallerID when I wasn't doing the custom searches as well.

04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::OnEventFiringObjectInvoke. Event: OnCallInfoChange
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Call Reference >13577<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Phone Status >Ring<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Call State >0x2<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::LogCallState: Call State: LINECALLSTATE_OFFERING
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. CLI >89634<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Call type >Direct<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. CalledID >49104<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. CallerID >(null)<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Queue >(null)<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Pilot >(null)<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Query >(null)<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. DNIS >(null)<
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Switching on call state: 0x2
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Calling is offering
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::PopOrNot.
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::PopOrNot. Direct call. Pop on direct calls is true. Popping!
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::GetCallInfo. Calling OnCallRinging.....
04/04/2008 08:44:04 a.m.: CZeacomSfAdapterUI::OnCallRinging
04/04/2008 08:44:04 a.m.: CCTIUserInterface::OnCallRinging: Call ID 13577, line 1.
04/04/2008 08:44:04 a.m.: CCTIUserInterface::CreateParty: Party already exists.  Using existing party.
04/04/2008 08:44:04 a.m.: CCTIUserInterface::OnCallRinging: Performing search.
04/04/2008 08:44:04 a.m.: Generated query Select Type,AccountNumber,Name,Id From ACCOUNT Where AccountNumber='CD355119-A'.
04/04/2008 08:44:04 a.m.: Generated query Select CaseNumber,Status,Priority,Id From CASE Where CaseNumber='00001026'.
04/04/2008 08:44:04 a.m.: Generated query FIND {89634} IN PHONE FIELDS RETURNING ACCOUNT(Type,AccountNumber,Name,Id),CASE(CaseNumber,Status,Priority,Id),CONTACT(Title,Name,Id),LEAD(Company,Title,LeadSource,Name,Id).
04/04/2008 08:44:04 a.m.: CCTIUserInterface::OnAgentStateChange: BUSY.
04/04/2008 08:44:05 a.m.: CCTIAppExchange::PopulateQueryResults: ANI query found 1 results.
04/04/2008 08:44:06 a.m.: CCTIAppExchange::PopulateQueryResults: ANI query found 1 results.
04/04/2008 08:44:06 a.m.: CCTIAppExchangeSearchThread::ThreadSearch: Asynchronous search complete.
04/04/2008 08:44:06 a.m.: CCTIAppExchangeSearchThread::ThreadSearch: Asynchronous search started.
04/04/2008 08:44:06 a.m.: CCTIUserInterface::GetLineByCallId: Call ID 13577 is on line 1.
04/04/2008 08:44:06 a.m.: CCTICallLog::AddRelatedObjects: There are more related objects than can be associated with this call log.  Leaving call log blank.
04/04/2008 08:44:06 a.m.: CCTIAppExchange::PopulateQueryResults: ANI query found 1 results.
04/04/2008 08:44:06 a.m.: CCTIAppExchange::PopulateQueryResults: ANI query found 1 results.
04/04/2008 08:44:06 a.m.: CCTIAppExchangeSearchThread::ThreadSearch: Asynchronous search complete.
04/04/2008 08:44:06 a.m.: CCTIUserInterface::GetLineByCallId: Call ID 13577 is on line 1.
04/04/2008 08:44:06 a.m.: CCTICallLog::AddRelatedObjects: There are more related objects than can be associated with this call log.  Leaving call log blank.
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::UIHandleMessage(). Message: ANSWER
04/04/2008 08:44:09 a.m.: CCTIUserInterface::UIHandleMessage: Message received: ANSWER.
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::CallAnswer
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::CallAnswer: Answer succeeded!
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::OnEventFiringObjectInvoke. Event: OnPhoneStatusChange
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Call Reference >13577<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Phone Status >OffHook<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Call State >0x100<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::LogCallState: Call State: LINECALLSTATE_CONNECTED
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. CLI >89634<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Call type >Direct<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. CalledID >49104<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. CallerID >(null)<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Queue >(null)<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Pilot >(null)<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Query >(null)<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. DNIS >(null)<
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::GetCallInfo. Switching on call state: 0x100
04/04/2008 08:44:09 a.m.: CZeacomSfAdapterUI::OnCallEstablished
04/04/2008 08:44:09 a.m.: CCTIUserInterface::OnCallEstablished: Call ID 13577.
04/04/2008 08:44:09 a.m.: CCTIUserInterface::GetLineByCallId: Call ID 13577 is on line 1.
HardhatHardhat
Hmm.  Seems like it might be running the ANI query (or one of the queries anyway) twice.  That might be a bug...
SimonZeacomSimonZeacom
Let me know if there is anything you want me to try to help diagnose it. I don't think it is doing anything twice in my code but I haven't looked into what it's doing in the CTIAdapterLib yet.

Simon
werewolfwerewolf
Simon,

Did you ever figure this out?  I still think the search thread is somehow returning its information twice, although I can't imagine what might cause that.
SimonZeacomSimonZeacom
Hi, I have been distracted on other work this week but am back on my Salesforce integration project today so I should be looking into this soon. At the moment since I know it generally works I am concentrating on other aspects of interfacing with our system. I should have some time to look into it in the next day or two hopefully.

Simon
SimonZeacomSimonZeacom
Ah, I think it was my fault! I think I was basically handling the incoming call twice by mistake. I need to do more testing but I seem to have it fixed now. I realised my mistake when I noticed that simulated calls only showed one set of data and it was only my real calls showing up twice.

Simon
SimonZeacomSimonZeacom
Yes, was definitely me. In mapping our systems call events through to the Salesforce events I wasn't making sure I only called things once. Our system you may generate the same event several times. For example on an outbound call we generate several ringing messages. I map these through to the Salesforce CCTIUserInterface::OnCallDialing() messages. Each of my events was calling that when it should only be called once per outbound call. The result was seeing the multiple instances of data in the Salesforce soft phone.

Simon