Possible to Debug the BaseLineHoliday.aef CCX Script?

[Matthew Martin]

Hello All,

UCCX Version: 8.5.1.11004-25

I was wondering if there is anyway to run a Reactive Debug on the BaseLineHoliday.aef CCX Script. I was able to open the script file from the UCCX Script Repository, but since the BaseLineHoliday has no trigger I couldn't figure out if it was possible now to run the reactive debug...

I was able to just start a simple Debugging of the Script, but when it gets to the point where it wants to create an XML Document whose path is in XMLHolidaysDocument var and save it to the variable called XMLHolidays, the debug fails saying "Source document variable "XMLHolidaysDocument" has null value". Which is when debugging fails/stops...

So is there anyway to debug this script at all? Could I maybe set some of the variables manually prior to running the debug in which the Calling Script would normally send to it, or something along those lines?

Any thoughts or suggestions would be greatly appreciated!

Thanks in Advance,
Matt

[Aaron Harrison]

Hi

As you say, you need to ensure that the variables have sensible values. Typically with my own scripts I would make any such variables parameters so that you can assign the script to an application then configure them all.

The other method would be to put a breakpoint at the top of the script in the editor, then do your debug. This allows you to step through and set variables as it goes to appropriate values... but that requires you to configure them all each execution/debug, rather than just once on the application.

Aaron

[Matthew Martin]

Hey Aaron, thanks for the reply!

I believe the BaseLineHoliday.aef script is a default/generic script that most systems use, correct? If so do you know what variables/parameters/arguments does BaseLineHoliday "take-in" when it gets run?

I see there is a switch object that lists each of our CSQs, and the variable inside the switch is a String var called "Application". Would the Application variable be set to whatever the name of the calling Application/CSQ is called? So for example, if the Application calling BaseLineHoliday is called "MyTest", would the Application String be equal to "MyTest"?

Then, inside whichever branch of the Switch statement that gets executed, the Document Variable "XMLHolidaysDocument" gets set to that Application's XML Document, in this case it gets set to DOC[Holidays_MyTest.xml].

Then, immediately following that switch statement is a Create XML Document step, which uses the variable set inside the switch, which says:
     XMLHolidays = Create XML Document (XMLHolidaysDocument)
This is where the debugging fails, saying:
     Source document variable "XMLHolidaysDocument" has null value.
Which it should not be null since the variable was already set inside the switch statement. So do you think that document var is being set to null because I'm debugging the script on my local PC and the document cannot be found so it sets it to null by default?

Any ideas? Thanks again for your reply, much appreciated!

Thanks Again,
Matt

[Aaron Harrison]

Hi Matthew

I don't see it in production often, so I would say not - it's an example of how you might do things.

I have my own the at I use... so I'm not particularly familiar with this one.

Are you just 'running' the script, or are you assign it to an application and doing a reactive debug?

Aaron

[Matthew Martin]

Hey Aaron, thanks again for the reply.

No, I was basically just running it. But, I think I'll just test it through my CSQ/Application's Script when it gets called. I know I read that you can't debug Call-Sub flows, which is how it gets run I believe... But, no worries.

Thanks again for the replies, much appreciated.

Thanks,
Matt

[Aaron Harrison · Accepted solution]

Hi Matt

Basically you can't debug a script that is launched as a subflow, but you can call it from an application as if it was called as a subflow by setting up the context (i.e. variables) the same way it would be set up when called as a subflow.

When debugging the calling script you will just see it step over the 'subflow' step and see the resulting changes to variables set up in the output mappings.

If you set up an application that calls the script directly and sets the params (or default values for the variables) and then trigger the script directly, you can debug it.

Aaron

[Matthew Martin]

Hey Aaron, thanks again for the reply.

Ok, cool. I'll give that a shot.

-Matt

[Matthew Martin]

Here's something I just realized... Duhh...

I just checked the Properties of the Call Subflow that executes the BaseLineHoliday.aef script, and I just realized there is an Input Mappings tab. Must not have noticed this tab before... I'm sure you know this already Aaron, but for those who don't...

The Input Mappings tab is where you include ANY variables from your Calling Script that you want to share, or map to variables in the Call Subflow script. And in this case the Input Mappings tab contain the "Application" string variable that is set to the Application name of the calling Script/CSQ.

So that makes much more sense now. I WAS thinking that maybe the Main Script and the Subflow script shared variables. But it doesn't, so you need to specify which variables you want to pass to it as Arguments, and then they get Mapped to existing variables in the Subflow script. And, in order to Map a variable from the Main to the Subflow the variable must first be defined/created in the Subflow script and the variables MUST be of the same type...

Hope that helps someone.

-Matt