| TeleFlow Forums http://teleflow.org/phpbb/ |
|
| Global "Hangup" & "Fatal Error" events management http://teleflow.org/phpbb/viewtopic.php?f=11&t=917 |
Page 1 of 1 |
| Author: | fesquivel [ Mon Jun 15, 2009 11:13 am ] |
| Post subject: | Global "Hangup" & "Fatal Error" events management |
Just a quickie: If I define these Global events in the Main App and then redefine them in an inner flowchart, shoud I save their current values into local variables prior to redefinition and then restore their values before getting out of the inner flowchart? If so, what type of local variable should I use to store these "pointers"? |
|
| Author: | Tim [ Mon Jun 15, 2009 11:49 am ] |
| Post subject: | Re: Global "Hangup" & "Fatal Error" events management |
Yes! If a flowchart changes a global event handler, it is a good practice to save the original settings and restore them before the flow returns from that flowchart. The event handlers are global, and they merely store the name of the label to jump to when the event occurs. The label is located by first searching the current flowchart, and then searching in reverse, popping back through the stack of flowcharts called to reach the current level. If, for example, you have a Hangup Handler redifined in the current flowchart, to say, "SAVE_RECORDING". After you leave that flowchart, your Hangup Handler will still be set to "SAVE_RECORDING". But, that flowchart has been popped off the stack, and therefore when your caller hangs up, "SAVE_RECORDING" will not be located, and you will get an application FATAL instead. Further, that FATAL may not be handled as intended, because TeleFlow would have already popped all the way back to the first flowchart in your application looking for "SAVE_RECORDING". The current Hangup Error Handler setting can be retrieved by querying the @HANGUP system variable. The current Fatal Error Handler setting can be retrieved by querying the @FATAL system variable. You can use either local or global variables to retrieve this value. I prefer local scope, and use variable names like: @SAVE_FATAL and @SAVE_HANGUP. |
|
| Author: | fesquivel [ Mon Jun 15, 2009 1:12 pm ] |
| Post subject: | Re: Global "Hangup" & "Fatal Error" events management |
I saw the use of these @SAVE_xxx variables somewhere, but I cannot recall where... Anyway, I will take advantage of this backtracking mechanism, so as to define proper handlers where I perform special handling (as returning back result codes to higher flowcharts) and avoid saving/redefining these global handlers where no special handling is done at all. Thanks a lot! |
|
| Author: | fesquivel [ Wed Jun 17, 2009 10:49 am ] |
| Post subject: | Re: Global "Hangup" & "Fatal Error" events management |
About the backtracking thing... Code: [13] Play Voice file name '@GBL_VOXPATH\@vFileName' evaluates to 'E:\Applications\IVR_RD\Vox\Spn\Scripts\PESOS.wav' Playing 'E:\Applications\IVR_RD\Vox\Spn\Scripts\PESOS.wav' ERROR: Port not off hook FATAL Attempting to jump to Fatal Error Global Event label: 'LBL_FATALERROR' Setting system variable '@FATAL' to '' [17] Label Label: LBL_FATALERROR [2] FINISH fc_SayAmount<==fc_ReadElementCatalog [55] Play Script code is 'LB-Con' Script code 'LB-Con' corresponds to file 'Vox\Spn\Scripts\LB-Con.WAV' Playing 'E:\Applications\IVR_RD\Vox\Spn\Scripts\LB-Con.WAV' ERROR: Port not off hook FATAL Attempting to jump to Fatal Error Global Event label: '' Fatal label undefined! fc_CreditCardMenu<==fc_SayAmount fc_IVR_MenuManager<==fc_CreditCardMenu Why does the Play step [13] set @FATAL to '' (a null string) before jumping to the local LBL_FATALERROR handler? Notice that afterwards the fc_SayAmount flowchart effectively finds it null, so fails with the "Fatal label undefined!" message. |
|
| Author: | Chris [ Wed Jun 17, 2009 11:35 am ] |
| Post subject: | Re: Global "Hangup" & "Fatal Error" events management |
Quote: Why does the Play step [13] set @FATAL to '' (a null string) before jumping to the local LBL_FATALERROR handler? To avoid an infinite crash loop. This was introduced because it is very easy to create an unintentional infinite loop in fatals. By setting it blank then going to your label, TeleFlow is sure to exit properly if another fatal error is encountered after your fatal label is jumped to. Without this, a fatal label can be jumped to, run code with a fatal, jump back to the same label, run the same code with a fatal, and so on. This essentially exists to protect the developer from a simple mistake causing a line to become unavailable, and what's more, potentially hog a ton of system resources while it is so. |
|
| Page 1 of 1 | All times are UTC - 8 hours [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|