UCCX 11.6 - Pass Local Variables from script to SubFlow scrpt

[lleweyiss]

I want to pass a local variable from a script to SubFlow script.

Do I have to create ECC variable in script in order to pass it to the SubFlow scipt , and use the SET Enterprise Call Info step in the SubFlow script ?

I did set Local variable in SubFlow script, same name and value (String "")

Did add step in SubFlow script to SET the variable. But did not work

[Sean Lynch]

Use the Input Mapping and Output Mapping tabs on the Subflow editor window.

Input Mapping tab to send a local variable into the subflow:

Output Mapping to receive a return variable from the subflow:

The drop-down options in the modifier windows will let you select a previously configured Local variable in your script.  Variable type will have to match the defined type in your subflow.  You will have to type in the subflow variable as it is not known by the local script--and it has to match exactly--spelling, case, etc.

Hope this helps.

-Sean

[lleweyiss]

Hi Sean,  sorry for late reply - another project required me to set this aside for a bit.

I took your advice and reviewed the Output & Input Mappings.  They look correct. 
Not sure if helps ... but - call comes into a Main Menu - then calls a subscript to authenticate the caller  (prompt them to enter contact ID an a pin)  - it does a DB Read & DB Get to verify the entry.   As we are moving over a period of time to another system that contains the customer contact information,  I added a subflow step to the initial subflow script to go check the new system if the contact ID and Pin were not found in the initial system. 

Here is where I am trying to pass the local variables for the digits gathered  in the 1st subflow script to the 2nd subflow script.

Looking at the MIVR logs - it does not show any digits entered (maybe passing the variable - will not show in the MIVR log) - but it does return as a the caller is not authenticated (contact ID and Pin not found).

Not sure if any of that helps , but hoping as I have tried several (probably not logical) changes to try and get the digits passed. I did try the setting the local variable to an ECC variable and used the SET Enterprise Call info ,  but did not produce the desired result.

I do not want to ask the caller to enter them again.

[Adam Pawlowski]

I'm pretty weak on CCX but I can try.

As was stated you can take variables into or out of a subflow by mapping, assuming the variable is set the way you want and the data types are going to make sense between the two. Subflows are hard to debug with the editor on step through.

I wrote a subflow to handle a Oracle DB read because the driver included with CCX was out of date and it didn't support a more recent one. We collect digits in the application's script and put it through the subflow, which does work.

I have no idea what happens when you try and call a subflow from a subflow, but I've found that the gumball editor doesn't seem to expect anything too complicated. I think I had something in the back of my head that it just doesn't execute nesting it like this?  If it were me, I'd either add it to the existing subflow, or restructure this around the main script, like

int_userid = get_digits
int_code = get_digits
bool_authenticated, bool_auth_handled = call_subflow[new_system.aef](int_userid, int_code)
switch(bool_auth_handled)
 - false:
   bool_authenticated, bool_auth_handled = call_subflow[old_system.aef](int_userid, int_code)
  switch(bool_auth_handled)
  - false:
    goto(handle error)
  - true: 
      goto (something about you did or didn't auth)
 - true:
  goto (something about you did or didn't auth)

Probably could be cleaned up logically and its not actual code but if you're in the weeds of MIVR logs then maybe a more basic block angle will get you what you need

[Sean Lynch]

I don't see why what you are attempting to do is a problem.  Just a couple suggestions:

1.  Use *Comments* often in your scripts and subflows to help keep track of your call flow--so when you are reviewing the MIVR logs you can better follow what has happened.

2.  Increase your MIVR logging level when you are debugging.

3.  Use the 'Task ID" to filter your MIVR logs.  (These show up as "Executed step of Task ID:"). 

4.  Nesting subflows shouldn't be a problem.  Just remember, the local variables you want to use in a subflow will need to be passed using Input and Output Mapping--one level at a time.  

5.  A String is not an Integer. ...an Integer is not a String. Datatypes have to be precise.  This includes sending data(types) to database queries...     

6.  Your subflow will crash if the data types do not match, or you attempt to evaluate a variable that doesn't exist.

7.  Yes, the MIVR log will show you when a variable is changed--but not in the executed step of the task/subflow/script.  They appear as lists in the logs.  (Perhaps I'm used to this because I have increased my logging level already, when debugging...?).   

I could probably put together a simple example of using nested subflow... Let me know.  And yes, I agree--I don't want a call contact to have to re-enter their data again after they've already done it, especially if it is for authentication purposes.  

Hope this helps.

-Sean

[lleweyiss · Accepted solution]

Sean,  all that was great information.  

I do use Comments,  and a local variable  called "CallState"  where I set some info to help keep track as well. 

I had already increased my MIVR logs,  but maybe not enough  

I do find the call and in Notepad++  I find the Task ID  and then do a 'find all in current doc'  to get all the steps - hugely helpful !

I reviewed the Datatypes as you suggested , to make sure I am keeping it 'same '  'same' ....... But this review made me do a more focused review of those DB steps.  Went back to the Reactive Debug ,  it was getting past the DB Read step - and then on the DB Get step it always went to the "No Data" branch. Which is why I thought the Contact ID and Pin were not being passed.

BUT   Discovered when I copied these DB steps from the original script   (this new one was checking the 2 different systems)  -  I noticed that my Contact ID was missing a % in front -  which is needed for the SQL query  (a debug of the production script - and this one - screen shot the local variables as they changed  and found this).

Then I found a step I had missed to set the Contact ID  as %ContactID  so the DB Get could use it in the SQL stmt .....  once those were done , the ContactID and Pin get passed to the 2nd sublfow  !!