| Knowledgebase Home | Contact |
 Search the Knowledgebase |
 Jump to ID |
 Browse by Category |
| Catching a specific sum of nomatch and noinput events | ||||||||||||
| Categories: Audium OpenSDK | ||||||||||||
Suggestions for how to count and track a combination of noinput and nomatch events as they occur in a built-in Audium element. SYMPTOMS Developer wishes to use a built-in Audium element, but needs to track a sum of noinput and nomatch events (i.e. a "total errors" counter), not just one or the other. RESOLUTION There are many ways to track the sum of noinput and nomatch events that occur within a built-in element: Approach #1: Use a Counter and a Decision element (no Java programming required) Set the max nomatch and max noinput settings of the voice element to 1. Then, connect the max_nomatch and max_noinput exit states of the voice element to a Counter element. Next, connect the Counter to a Decision element that checks if a certain threshold has been met. If the threshold has been met, exit as max_sum_errors (you can choose your own name for this exit state); if the threshold has not been met, then go back to the voice element. Note that if you would like to use tapered prompts, the voice element will need a dynamic configuration class to examine the value of the counter and then update the audio items. Approach #2: Extend a built-in element (Java programming required) The following is meant as a guideline for how to approach this solution, the implementation details should be explored and defined by the developer. Create a new voice element by extending an existing voice element (for an example of how to extend an existing element, please refer to ExtendedElementExample.java from within this Audium Support Center post). Within your new voice element: 1) Watch for nomatch and noinput events. Configure the voice element to encounter max noinput and max nomatch after just 1 event, in which case it will store "maxNoInput" and "maxNoMatch" in the HashTable parameter that is sent to addXmlBody() for every single no match and no input event that occurs. You can then watch for the presence of these values in the HashTable to determine if either event has occured. 2) Keep track of the number of these events that occur using counters stored in the scratch space (note that you should never use member variables in custom element code, since one instance of the class is shared among all elements, causing the variables to act as though they were static). 3) If you are extending a Form element, and have detected that either a nomatch or noinput event has occured, remove the variable named "foundation_fld" from the HashTable. This will ensure that any stale value stored in this variable is cleared out (since elements are only instantiated once, and may contain old data if it is not cleared out), which will allow the Form to continue processing. If you are not extending a Form element, you may need to remove a different variable from the HashTable to ensure that the element does not use old data (please refer to the Element Specification for the element you are extending to see which data it stores). 4) Check for max noinput and max nomatch and exit with the appropriate pre-existing exit state if either is reached. Note that since the max nomatch and max noinput element settings have been set to 1 (in step 1) so that the event count could be tracked, the desired max noinput and max nomatch values will need to be hard coded. 5) Check if the sum of the counters has reached the desired threshold, and if so, exit with a new exit state (e.g. "max_errors", etc.). 6) If the element did not exit in step 5, remove the maxNoInput and maxNoMatch values from the HashTable. This will prevent the built-in element that we are extending from believing a max noinput or max nomatch condition has occured. 7) Allow the element you are extending to do the rest of the work by calling: exitState = super.addXmlBody(vxml, reqParameters, ved); 8) Return the exit state that the extended element returns. Remember that this exit state will never be max_noinput or max_nomatch since the variables "maxNoInput" and "maxNoMatch" were removed from the HashTable in step 1. This is why we needed to handle these exit states manually in step 4. Approach #3: Create a new element (Java programming required) The cleanest, most reusable solution to this problem is to not use a built-in element at all, but instead create a custom voice element. Rather than extending a built-in element (as described in Approach #2), implement all of the functionality of the element using VFCs. Once this is done, you can then easily track no match and no input events, without having to coerce a built-in element to alert you to them. This approach involves the most work, but produces the most reusable result. |
Print this page
Post a comment
(1 vote)
| Visitor Comments |
| No visitor comments posted. Post a comment |
| Related Questions |
| Attachments |
| No attachments were found. |