Reschedule to New chain not dialed (updated status)

[cavagnaro]

Hi All.

I have an issue here:

I'm adding a new chain to my record on OCS, then rescheduling to this new record, it reschedules ok but at the end both are updated as record_status = Updated and the reschedule dial is never done.

Here are the Events i do for Reschedule and Record Processed.

Any idea?

Reschedule Event:

09:23:49.262 Trc 04541 RequestDistributeUserEvent received from 676 (03a1 DesktopToolkitX)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeThisDN '5061'
AttributeUserData [233] 00 07 00 00..
'GSW_DATE_TIME' '3/19/2007 09:50'
'GSW_CALLBACK_TYPE' 'Campaign'
'GSW_RECORD_HANDLE' 21599
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_TREATMENT' 'RecordTreatPersonal'
'GSW_APPLICATION_ID' 115
'GSW_AGENT_REQ_TYPE' 'RecordReschedule'

RecordProcessed:

@09:23:53.4130 [0] 7.2.001.02 distribute_user_event: message EventUserEvent
AttributeEventSequenceNumber 0000000000138061
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 413000
AttributeTimeinSecs 1174314233 (09:23:53)
AttributeUserData [360] 00 0C 01 00..
'GSW_CALL_RESULT' 33
'' ''
'PegAGtest_alcatel' '1'
'RTargetRequested' 'test_alcatel'
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
'codigo_usuario' '20332'
'daily_till' '79200'
'GSW_RECORD_HANDLE' 21598
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_APPLICATION_ID' 115
'GSW_AGENT_REQ_TYPE' 'RecordProcessed'
AttributeThisDN '5061'

[victor]

Hi, Cavagnaro,

several things that are driving me nuts looking at this log:

1. you should have RecordRescheduleAcknowledge for your RequestDistributeUserEvent
2. in your RecordRescheduleAcknowledge it should tell you GSW_DATE_TIME
3. you are getting RequestDistributeUserEvent from OCS 4 seconds after issuing a request - a lot of things happened in between. I guess you have withheld Ack from the post right?

4. GSW_TREATMENT'  'RecordTreatPersonal' -- it should not be in RecordReschedule to my knowledge
5. RecordProcessed only comes from Desktop and not from OCS.
6. 'GSW_CALL_RESULT'  33 <--- it means the call was answered!
7. GSW_RECORD_HANDLE'  21598 and 215999 -  we are looking at two different records, right? 


Genesys manual states the following fields have to be there for Request:
[attachimg=1]

GSW_DATE_TIME is a tricky one because it has to be within acceptable limits of your campaign.

Can you pleasepost the lost from TServer and OCS for that call? I am curious why it was not working, because we will be doing this pretty soon.

Best regards,
Vic

[cavagnaro]

Sorry, what i ment is that on my SoftPhone I'm adding this functions so OCS reschedules the call to this new phone.

Here i post the logs of TServer and OCS, agent was 6060 and phone number dialed initially was 3197207125061, then i added the same number (no matter) and took its RecordHandle doing a ChainedRecords Request.

Alcatel has raised this to level 3 (?) i don't think i'm the only one who developed such function right?

The flow is as follows:

OCS dials client number
Client says Hello
Agent receives the call and asks for John Doe
John Doe is not here contact him at his office his number is 7125061
Agent add this number to the list (AddRecord)
Agent then populates all clients numbers (ChainedRecords)
Agent selects the new number (capture RecordHandle)
Agent reschedules over this RecordHandle and not the one of the actual call.
Agent hangs up
Agent send a RecordProcessesed
OCS should dial the new added number but doesn't do it as both are marked as Updated.

Thanks Vic, any help will be appreciated, then i may help you on the coding as it's really a pain in the ass to get a correct flow.

[victor]

Ok, here is my take on what I see:

message RequestMakePredictiveCall
AttributeThisDN '64006'
AttributeOtherDN '3197207125061'
AttributeTimeout 120
AttributeUserData [342] 00 0C 00 00..
'GSW_PHONE' '3197207125061'
'daily_till' 79200
'GSW_TZ_OFFSET' -18000
'GSW_CHAIN_ID' 1
'codigo_usuario' '20332'
'GSW_RECORD_HANDLE' 21598
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_APPLICATION_ID' 115
'GSW_ATTEMPTS' 4
'GSW_CALL_RESULT' 28
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
AttributeExtensions [2] 00 00..
AttributeReferenceID 31914
09:22:50.334 Int 04543 Interaction message "RequestMakePredictiveCall" received from 392 ("OutboundContactServer")


you are adding a new record with chain id


09:23:17.558 Trc 04541 RequestDistributeUserEvent received from 676 (03a1 DesktopToolkitX)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeThisDN '5061'
AttributeUserData [399] 00 0E 00 00..
'' ''
'PegAGtest_alcatel' '1'
'RTargetRequested' 'test_alcatel'
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
'codigo_usuario' '20332'
'daily_till' '79200'
'GSW_RECORD_HANDLE' 21598
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_APPLICATION_ID' 115
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_CHAIN_ID' 1
'GSW_PHONE' '3197207125061'
'GSW_TZ_NAME' 'LIM'
'GSW_AGENT_REQ_TYPE' 'AddRecord'


'GSW_RECORD_HANDLE' 21598 --- not necessary

and here is the reply

09:23:17.840 Trc 04541 RequestDistributeUserEvent received from 392 (01da OutboundContactServer)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeUserData [425] 00 0F 00 00..
'' ''
'PegAGtest_alcatel' '1'
'RTargetRequested' 'test_alcatel'
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
'codigo_usuario' '20332'
'daily_till' '79200'
'GSW_RECORD_HANDLE' 21598
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_PHONE' '3197207125061'
'GSW_TZ_NAME' 'LIM'
'GSW_CHAIN_ID' 1
'GSW_CHAIN_N' 1
'GSW_USER_EVENT' 'AddRecordAcknowledge'
'GSW_APPLICATION_ID' 115

You have added a new sub_chain (1) to the current record. So far, so good!

Then, you are asking for a follow up record:

09:23:29.901 Trc 04541 RequestDistributeUserEvent received from 676 (03a1 DesktopToolkitX)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeThisDN '5061'
AttributeUserData [134] 00 04 01 00..
'GSW_RECORD_HANDLE' 21598
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_APPLICATION_ID' 115
'GSW_AGENT_REQ_TYPE' 'ChainedRecordRequest'

And here is the new record:
09:23:29.901 Trc 04541 RequestDistributeUserEvent received from 392 (01da OutboundContactServer)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeUserData [374] 00 0D 00 00..
'GSW_PHONE' '3197207125061'
'daily_till' 79200
'GSW_TZ_OFFSET' -18000
'codigo_usuario' '20332'
'GSW_RECORD_HANDLE' 21599
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_CHAIN_ID' 1
'GSW_ATTEMPTS' 0
'GSW_CALL_RESULT' 28
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
'GSW_USER_EVENT' 'ChainedRecord'
'GSW_APPLICATION_ID' 115

essage RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeUserData [183] 00 06 01 00..
'GSW_RECORD_HANDLE' 21598
'GSW_CHAIN_ID' 1
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_USER_EVENT' 'ChainedRecordsDataEnd'
'GSW_APPLICATION_ID' 115

Here you are asking for rescheduling of record 21599 (which is 21598 chain_n = 1, right? )

9:23:49.262 Trc 04541 RequestDistributeUserEvent received from 676 (03a1 DesktopToolkitX)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeThisDN '5061'
AttributeUserData [233] 00 07 00 00..
'GSW_DATE_TIME' '3/19/2007 09:50'
'GSW_CALLBACK_TYPE' 'Campaign'
'GSW_RECORD_HANDLE' 21599
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_TREATMENT' 'RecordTreatPersonal'
'GSW_APPLICATION_ID' 115
'GSW_AGENT_REQ_TYPE' 'RecordReschedule'

and OCS happily obliges to reschedule on 3/19/2007 at 09:50

09:23:49.278 Trc 04541 RequestDistributeUserEvent received from 392 (01da OutboundContactServer)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeUserData [271] 00 08 00 00..
'GSW_DATE_TIME' '3/19/2007 09:50'
'GSW_CALLBACK_TYPE' 'Campaign'
'GSW_RECORD_HANDLE' 21599
'GSW_TREATMENT' 'RecordTreatPersonal'
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_USER_EVENT' 'RecordRescheduleAcknowledge'
'GSW_APPLICATION_ID' 115

After you hang up the original call, your phone updates the record once again:

09:23:53.413 Trc 04541 RequestDistributeUserEvent received from 676 (03a1 DesktopToolkitX)
message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeThisDN '5061'
AttributeUserData [360] 00 0C 01 00..
'GSW_CALL_RESULT' 33
'' ''
'PegAGtest_alcatel' '1'
'RTargetRequested' 'test_alcatel'
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
'codigo_usuario' '20332'
'daily_till' '79200'
'GSW_RECORD_HANDLE' 21598
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_APPLICATION_ID' 115
'GSW_AGENT_REQ_TYPE' 'RecordProcessed'

GSW_CALL_RESULT = 33 means ANSWERED

And the acknowledgment!

@09:23:53.4290 [0] 7.2.001.02 distribute_user_event: message EventUserEvent
AttributeEventSequenceNumber 0000000000138067
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 429000
AttributeTimeinSecs 1174314233 (09:23:53)
AttributeUserData [366] 00 0C 01 00..
'GSW_CALL_RESULT' 33
'' ''
'PegAGtest_alcatel' '1'
'RTargetRequested' 'test_alcatel'
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
'codigo_usuario' '20332'
'daily_till' '79200'
'GSW_RECORD_HANDLE' 21598
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_USER_EVENT' 'RecordProcessedAcknowledge'
'GSW_APPLICATION_ID' 115
AttributeThisDN '5061'


I looked at your log, and I could not find 09:50 part.
You have schedule your HANDLE_ID 21599 call to be called at 09:50.
Judging from the logs, you did not wait until 09:50.

Also, I am a little bit curious about CALL_RESULT 33 -- ANSWERED --- I wonder if there is a better way.
So, the call did no come at 09:50?

[Fra]

Hi guys,

here I am after much time 

Cavagnaro, I totally agree with Vic in all but one thing:

[quote]Here you are asking for rescheduling of record 21599 (which is 21598 chain_n = 1, right? )

9:23:49.262 Trc 04541 RequestDistributeUserEvent received from 676 (03a1 DesktopToolkitX)
message RequestDistributeUserEvent
  AttributeCommunicationDN  '5061'
  AttributeThisDN  '5061'
  AttributeUserData  [233] 00 07 00 00..
      'GSW_DATE_TIME'  '3/19/2007 09:50'
      'GSW_CALLBACK_TYPE'  'Campaign'
      'GSW_RECORD_HANDLE'  21599
      'GSW_CAMPAIGN_NAME'  'test_alcatel'
      'GSW_TREATMENT'  'RecordTreatPersonal'
      'GSW_APPLICATION_ID'  115
      'GSW_AGENT_REQ_TYPE'  'RecordReschedule'

and OCS happily obliges to reschedule on 3/19/2007 at 09:50[/quote]

In my humble opinion OCS acts stupid here, cause it acks the request without waiting for a successfull confirmation by DB; in fact few lines below we can see:
[size=8pt]
09:23:49.293> CM_DBCallList(102-102-110): DBServer 'OutboundContactServerDBServer' MSG_ERROR [ReqID=414748], General SQL Server error: Check messages from the SQL Server. [b]Invalid column name 'treatments'.[/b]
09:23:49.293> CM_DBCallList(102-102-110): Error-causing SQL: update test_alcatel set treatments = NULL where chain_id = 1 and record_status = 2
09:23:49.293> CM_DBCallList(102-102-110): DBServer 'OutboundContactServerDBServer' MSG_SQLEXECUTED(DBM_SUCCESS) [ReqID=414749]
09:23:49.293> CM_DBCallList(102-102-110): DBServer 'OutboundContactServerDBServer' MSG_ERROR [ReqID=414750], General SQL Server error: Check messages from the SQL Server. Invalid column name 'treatments'.
09:23:49.293> CM_DBCallList(102-102-110): Error-causing SQL: update test_alcatel set treatments = NULL where chain_id = 1 and record_status = 2
09:23:49.293> CM_DBCallList(102-102-110): DBServer 'OutboundContactServerDBServer' MSG_ERROR [ReqID=414751], General SQL Server error: Check messages from the SQL Server. Invalid column name 'treatments'.
09:23:49.293> CM_DBCallList(102-102-110): Error-causing SQL: update test_alcatel set treatments = NULL where chain_id = 1 and record_status = 2
09:23:49.293> CM_DBCallList(102-102-110): RecordUpdateError[/size]

This is the reason why in my humble opinion this record will not be redialed..
Looking in the Genesys KB,  it seems that this is caused by the fact that a new field "Treatments" has been added to Outbound Contact 7.2 and that your calling list underlying format actually does not have it; have you recently upgraded from 7.x to 7.2? In this case check Genesys 7 Migration Guide chapter 20-21.

Vic, yeah, you are right, that CallResult=33 is not real nice; but in a couple of our customers we have, we issue the same message: if we update the single record of a chain with this call result and the other records differently, it all works fine.

p.s. : Cavagnaro, not much important actually, but do you attach an empty KV pair on the AddRecord request?

[quote]message RequestDistributeUserEvent
AttributeCommunicationDN '5061'
AttributeThisDN '5061'
AttributeUserData [399] 00 0E 00 00..
'' ''                          [b]<----------------[/b]
'PegAGtest_alcatel' '1'
'RTargetRequested' 'test_alcatel'
'GSW_CALL_ATTEMPT_GUID' '67E6E011-B45E-46F0-A4F6-6F9187BFC96F'
'codigo_usuario' '20332'
'daily_till' '79200'
'GSW_RECORD_HANDLE' 21598
'GSW_CAMPAIGN_NAME' 'test_alcatel'
'GSW_APPLICATION_ID' 115
'GSW_CALLING_LIST' 'test_alcatel'
'GSW_CHAIN_ID' 1
'GSW_PHONE' '3197207125061'
'GSW_TZ_NAME' 'LIM'
'GSW_AGENT_REQ_TYPE' 'AddRecord'[/quote]

Let us know

[cavagnaro]

Yes using OCS 7.2, will downgrade as this is a lab and my customer has another version.
But will test also on 7.2 later
About the empty KV well will check where it comes from.

Vic i didn't wait until 9:50 because on OCM i saw both records as updated and in that way they are never dialed.

Will test again and let you know guys  Thanks a lot for the help

[cavagnaro]

Ok,
Still on 7.2 as the treatment field had no effect.
Here is the OCS Logs from start

[Fra]

Cavagnaro,

in this last log you have provided @11:41:21 the record is correctly rescheduled on 11:52, the update to db is successfully done. But the log does not cover the time when OCS should redial it, last message in it is @11:41:39.305 

[Fra]

Aah,

as Vic said on his first post, your agent desktop still issues a strange RecordReschedule:

received from 65200(TServerA4400)genesys1:3100(fd=348) message EventUserEvent
AttributeThisDN '5061'
AttributeUserData [233] 00 07 00 00..
AttributeTimeinSecs 1174408881 (11:41:21)
AttributeTimeinuSecs 557000
AttributeCustomerID 'Resources'
AttributeEventSequenceNumber 0000000000143a58
GSW_DATE_TIME '3/20/2007 11:52'
GSW_CALLBACK_TYPE 'Campaign'
GSW_RECORD_HANDLE 2
GSW_CAMPAIGN_NAME 'test_alcatel'
GSW_TREATMENT 'RecordTreatPersonal'  <---------
GSW_APPLICATION_ID 115
GSW_AGENT_REQ_TYPE 'RecordReschedule'

Attribute GSW_TREATMENT should not appear in this request, but just in some cases in RecordProcessed message. Drop it and test again! 

[cavagnaro]

Ok will do 

Will also leave the logs until the reschedule hour should occur (when nothing happens)

Thanks you all

[cavagnaro]

Ok guys this is what i did:

1. Created a new calling list based on format 7.0 which has all new fields.
2. Removed the GSW_TREATMENT from Reschedule event.

Still nothing

Logs covers the time when the call was scheduled to dial.

Thanks a lot, can you believe you are helping more than Alcatel support? They said, field missing, case closed. wtf.

[Fra]

Cavagnaro,
I'm analysing your log, the problem is that, when OCS receives the RecordProcessed, a record_status=3 (Updated) instead than 1 (Ready) is issued against the db for your rescheduled record so that it will never get dialed. Could you please post also the corresponding TServer log?

[cavagnaro]

Hi Fra,
Here is the TServer log.
What i have done else is to add a treatment of WrongParty > NextInChain I then update the record as WrongParty and it dials the added chain in the record, the problem is that it's dialed inmediatly and does not respect the scheduled event. So doesn't work.

Thanks a lot

PS.- I'm sending a ZIP file, so, change the extension from "TXT" to "ZIP" 

[victor]

Cavagnaro,

I tried opening the zip file, but it said invalid format. (And yes, I did change from .txt to .zip)
So, can you please upload it again? (I made forum support .zip uploads)

Also, take a look at OCS log, because probably there is an error or two there. They keyword is "Rescheduled": you should be looking for some sort of time when OCS decided to redial it.

Vic

[cavagnaro]

Ok here it is
Will check the OCS log