Migration Scripts fail

[Hieronymous Merkin]

So in the process of migrating Version 7 to Version 9 on both CUCM and UCCX.   Upgrade went fine and systems are up and running.  After importing the scripts, documents, prompts from old to new, they will not run.   They pass validation and load as an application without error, but calling results in going straight to system default message.   Active debug does not work as it fails before Triggering Contact?   The script has no C:\ reference relics from old, so I am wondering what the issue is.    How best to trouble shoot?  These are relatively simple scripts so I guess I could just rewrite them.  I note the partial service of the UCCX Engine, but dont know how to locate the cause.  Might be something related to script failure?  Any input?  A;

Also how do I make sure the default language and prompt files are being used.  I am thinking that maybe the scripts cant find the prompts?  The old system did not use language and the new one does.   Duh...           

[Anthony Holloway]

Hieronymous Merkin wrote:
Active debug does not work as it fails before Triggering Contact?

Did you mean Reactive debugging?  Because generally speaking you cannot Active debug a script that references the Triggering Contact.  Also, by "Triggering Contact" did you mean that the script fails before the Accept step?  If so, then does that mean that you are able to debug the script up until the Accept step?  This could be a codec/media resource issue.

Hieronymous Merkin wrote:
How best to trouble shoot?

Sounds like you've already done some work.  I.e., You've reviewed your scripts for improper references to the C:\.  You have validate your scripts.  Etc.  The next thing would be to review MIVR logs.

Hieronymous Merkin wrote:
These are relatively simple scripts so I guess I could just rewrite them.

That is a possibility, but if the problem is not actually with the script, you'll be fighting a losing battle.

Hieronymous Merkin wrote:
I note the partial service of the UCCX Engine, but dont know how to locate the cause.  Might be something related to script failure?  Any input?  A;

You find out in the MIVR logs.  But I would also recommend you pulling CUCM logs as well, as like I said before, if it's the Accept step where the script fails, then it's probably a codec/media resource issue, which will only be seen in CUCM logs.

Hieronymous Merkin wrote:
Also how do I make sure the default language and prompt files are being used.  I am thinking that maybe the scripts cant find the prompts?  The old system did not use language and the new one does.

Look at the system default language.  Look at the language on your triggers.  Look at the MIVR logs to see which prompt files are being loaded (it gives the full path in the log file).

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Hieronymous Merkin]

Anthony - 

The script never pops in ReActive Debug, so I dont ever get to accept step.  I did add a Set Contact info step to set the language after Accept to assure it pointed to the default language. I even moved prompts to root just to see if that was an issue. No change.  (I have never had a script fail because of missing prompt file, it usually just does not play anything if it is missing).    I note that if I run a system script like AA.aef it works just fine, so I am thinking it is not a codex issue (which usually results in a fast busy error).

So I will set up Real time monitoring tool and configure trace and play the MIVR log game..

[Anthony Holloway]

All good information, especailly your test of the AA.aef script.  Thanks for the follow up.  I'm curious to see what you MIVR logs say. You may even want to turn your ENG debugging to debug first.  This gives you more details about what the engine is processing.  As well as turning your CUCM tracing to detailed.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Hieronymous Merkin]

So it is a day of lessons. 

Partial Services was clearly an Application Manager error;

Log shows "failed to load script name.aef"

As I already owned up to these were Version 7 scripts, but I did upload them using Version 9 Editor.

Deleteing the Scripts from the Repository and setting the applications all to load aa.aef (setting enalbe to no, does not change and I did not want to delete all my applications and triggers) allowed me to get the services working.   As soon as I associated a script with an application - even though it validated and showed no error in appadmin - the services again went partial.

Tac indicates that you can not load a script created in a different editor version regardless of how you load it!

[Anthony Holloway · Accepted solution]

Hieronymous Merkin wrote:
Tac indicates that you can not load a script created in a different editor version regardless of how you load it!

That statement is missleading, and I hope Cisco TAC did not tell you this information, the same way it reads here.

If you are upgrading your UCCX, all of your scripts will work on the newer version.  If you are going from UCCX 4.0 (if memory serves) to anything higher, you are required to open and "Save As" all of your scripts in the higher editor, before you are allowed to load them into the repository.  This was due to a fundemental change in the way the Select Resource step referenced the Agent object (String versus User), and this process modified your script to bring it up to standards.  However, this has not happened since that time frame, and all subsequent upgrades to UCCX do not require you do this.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.