Get trigger info step in default script

[Henrik Larsen]

Hi

UCCX 12.0

I have made a very basic script and use this as default script for an application. I try to use the get trigger info step to get the reason for application exception which should be possible according to description for get trigger info step.
I have created a variable of object type, but I get no information in this variable when default script is activated - In same step I do get the application name, so probably I'm doing something wrong here.

Any inputs to how this is supposed to work or any sample would be appreciated

[Elliot Dierksen]

What is it you are trying to accomplish? I don't understand what you mean by 'default script for an application'. Here is an example of using that step to get some information.

I am using it there to get the info about the contact. If you wanted other information from the available options, you would assign a defined variable to each of the options.

[Henrik Larsen]

Hi Elliot

Thanks for responding on this.

I'm creating a basic script which is being assigned to application as default script, so instead of getting standard mesage "I'm sorry, we are..." in case application fails for some reason, I want to capture the call in my own script. This works fine, in case ex. application is inactive calls are answered in new script - so far so good.

I try to use the get trigger info step to get the aborting reason for application exception which should be possible according to description for get trigger info step, but I don't get any value in parameter. I do get application name, so some date is available.

Reason for this is that I need to store reason for why application failing in variable som I'm able to report on it. From step description this should be possible as I understand it, but I can't make it work.

[Elliot Dierksen]

I have never tried that, but I suspect you might need to go at this a different way. You may need to trap the abort with an 'on exception' in the main script. Then perhaps you could get the trigger information and abort reason. I suspect you might also be able to get that abort detail out of the ContactCallDetail table in the CCX database. I am just guessing on this since I haven't done it before.

[Henrik Larsen]

Yeah, but case is that call is never getting to the main script as the application is disabled, so I don't see how I could capture this information. Help in editor states:
"When the Get Trigger Info step is in a default script, specifying an Aborted Reason variable lets you access the exception reason generated when the normal script aborted. The exception reason can provide valuable information about why there was a script failure. For example, the value com.cisco.app.ApplicationFailoverException indicates that the Cisco Unified CCX Engine where the main script was running stepped down as the Master. Knowing this, you can then restructure your normal script to compensate for this happening in the future by transferring the call back to the DN where it was received so it can be automatically transferred to the new Cisco Unified CCX Engine master.

Note     The Aborted Reason variable must be of the same type as the expected exception or a base class.

So I found that variable for storing Exception must be of type com.cisco.app.ApplicationException, but I still don't get any information in this value, when default script is triggered. 

Perhaps I need to do a TAC case for this, as it does not seem to be working ad designed

[Elliot Dierksen]

Do you have a variable of that type defined? You can certainly try TAC, but they may very well fall back on the 'we don't provide scripting support'.

[Elliot Dierksen]

Yes, that info does appear to be in that table.

admin:run uccx sql db_cra select dispositionReason from ContactCallDetail  where contactDisposition = 4
DISPOSITIONREASON
-----------------
ABLISHED]->HELD; nested exception is:
        com.cisco.jtapi.PlatformExceptionImpl: Cti request timed out
ABLISHED]->HELD; nested exception is:
        com.cisco.jtapi.PlatformExceptionImpl: Cti request timed out
ABLISHED]->HELD; nested exception is:
        com.cisco.jtapi.PlatformExceptionImpl: Cti request timed out
17506/2 Task:31000590626 hold fails because call already dropped, but we haven't received Dropped ev

 I was looking at an older version of the schema, but I highly doubt this has changed.

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_6/reference/guide/dbschema.pdf 

[Henrik Larsen]

Hi Elliot - Update on this
We have found that this only relays information on exception reason in main script, so in case of inactive application or too many calls (main script not activated), there is no information to get from Get Trigger Info step.