Trigger redirects vs. subroutines

[Kleid Gjataj]

Are there any downsides to using Trigger Redirects in scripts vs calling a subroutine?

Example:

Call comes in App1- MainMenu

Caller presses option 1 for CS queue.

At this point I can either call a subroutine that has the CS logic/schedule or I can do redirect to the trigger of APP2- CS_Queue?

Besides the Parameter exposure and the easiness of debugging that the trigger redirect provides are there any other reasons to use this method?

Does the Trigger redirects use  2 CTI ports back to CUCM?

Thanks in advance.

-kleid

[Arundeep Nagaraj]

Hi Kleid,

Is there a reason for using a separate trigger for the CS_Queue App?

I would recommended implementing the logic of the script associated to APP2 to the same main script:

Main script:

Menu

Option 1

Go To CS_Queue (which is a label)

..

Option 2

..

..

CS_Queue (label)

Logic of the CS_Queue

Trigger Redirect will cause the call to be transferred to the trigger and it will use the same logic of REDIRECT to a CTI port that is selected by the UCCX under the Call Control Group associated to the trigger.

Regards,

Arundeep

[Kleid Gjataj]

The main reason is to keep the scripts modular . The example I provided is over simplified.
I just need to better understand the impact that trigger redirects have on CTI port usage

Sent from Cisco Technical Support iPhone App

[Arundeep Nagaraj]

There is no impact on CTI port usage. The call that is held on CTI port 1, will be redirected to the new trigger X and the CTI port 1 becomes available again to process the next call.

Once the call leg is on X, it redirects to a CTI port 2 which is selected from the Call Control Group of the trigger X and this will be in use.

You can make a test and monitor the port status using the in-built port monitor tool of the RTMT.

Regards,

Arundeep

[Jonathan Schulenberg]

Besides the Parameter exposure and the easiness of debugging that the trigger redirect provides are there any other reasons to use this method?

Reporting. Some customers want to know what percentage of caller chose option 1 vs. 2 for example. There is no native way to accomplish this and one of the more common is to have a bunch of Triggers on the same applicatiion with Call Redirects at the various menu choices to other triggers. The beginning of the script has a Switch statement allowing the script to jump forward to where it left off (or some other way to continue on). The Application Summary report then shows how many contacts hit the various triggers.

The rule of thumb I use is this: if it's roughly a function (programming term) where I can pass in a few variables, have it do a thing, and then get a result AND it will be used across multiple scripts AND it's a fair amount of code (i.e. not three steps), then I use a subflow. ELSE I put it in the original script or do a redirect to another trigger. Subflows are a PITA to troubleshoot though. You *will* lose some hair before realizing that your subflow is why something isn't working.

Please remember to rate helpful responses and identify helpful or correct answers.