UCCX 11.6 - DB Release step - can incorrect placement or omitted Step cause error

lleweyiss · ‎04-06-2021

I have a subflow script off a main menu script. The Subflow has steps to authenticate the caller against a Data Source.

The caller enters the Contact ID and Pin, There are DB Read and DB Get steps to go to the data source and look for the entered information to determine if they are authenticated successfully. There are a couple of other DB Read & DB Get steps to retrieve additional information from the database.

All of this has been working as configured for a while no matter if they enter correct information, enter no information, or incorrect information.

However , I have recently just noticed in the syslog that periodically I am seeing an error / exception and those calls will hit this error and then at some point the task aborts and plays that system error/problem prompt and drops the call.

Bonus: it only happens on a very small number of calls maybe a couple in days time but not everyday, nothing consistent about when it occurs or how often.

I also found the same error in the MIVR log.

For these calls the MIVR log shows the steps in the subflow - and after all the steps , at the end is a DB Release step for one of the DB Get steps earlier in the script , next starts a bunch of entries in log about an error and steps about trying to execute the DB Release step, and then repeats error and entries about 4 times before it aborts the call and plays the 'system error.

The original author of the script placed the DB Release step right above the End step.

I tried looking into any doc's I could find on the DB Read, Get, Release steps and I did not see anything "notes, caution", etc) that said anything except to put the DB Release step in the No Data Branch.

Is this the only place that I need to put the DB Release step? or is it required after each DB Get step as well (original author of script put the DB Release step after almost all DB Get steps).

I am thinking I need to remove the DB Release at the end of the script ... and either add it after the DB GET steps and make sure all No Data branches have the DB Release step .... any one have a best practice on this DB Release step ?

Below is is the MIVR log error and those other entries that repeat about 4 times before the abort of the call.

Exception=com.cisco.wfapi.WFExecutionException: 1 >= 1; nested exception is:

Task Class=class com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper,Exception=com.cisco.wfapi.WFExecutionException: 1 >= 1; nested exception is:
java.lang.ArrayIndexOutOfBoundsException: 1 >= 1
18772006: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION:com.cisco.wfapi.WFExecutionException: 1 >= 1; nested exception is:
18772007: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: java.lang.ArrayIndexOutOfBoundsException: 1 >= 1
18772008: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wf.steps.ivr.DBReleaseStep.execute(DBReleaseStep.java:120)
18772009: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.obj.WFBeanStep.executeImpl(WFBeanStep.java:141)
18772010: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.obj.WFStep.execute(WFStep.java:174)
18772011: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.obj.WFWorkflowTask.executeStep(WFWorkflowTask.java:494)
18772012: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.engine.core.WFEngineWorkflowTask.executeStep(WFEngineWorkflowTask.java:122)
18772013: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper.executeStep(WFWorkflowAppDebugTaskWrapper.java:416)
18772014: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.obj.WFWorkflowTask.execute(WFWorkflowTask.java:360)
18772015: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.engine.core.WFEngineWorkflowTask.execute(WFEngineWorkflowTask.java:77)
18772016: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper.execute(WFWorkflowAppDebugTaskWrapper.java:736)
18772017: Apr 02 01:04:12.910 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.engine.core.TaskManager.runTaskNormally(TaskManager.java:415)
18772018: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.engine.core.TaskManager.runTask(TaskManager.java:371)
18772019: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.wfframework.engine.core.TaskManager$RunnableTask.run(TaskManager.java:588)
18772020: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.runCommand(ExecutorStubImpl.java:690)
18772021: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:486)
18772022: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:762)
18772023: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:776)
18772024: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.executor.impl.PooledExecutorStubImpl$1$WorkerImpl.run(PooledExecutorStubImpl.java:99)
18772025: Apr 02 01:04:12.911 EST %MIVR-APP_MGR-3-EXCEPTION: at com.cisco.util.ThreadPoolFactory$ThreadImpl.run(ThreadPoolFactory.java:853)

The above then starts over on the exception - 3 more times before it aborts and play system error prompt and drops the call.

Sean Lynch · ‎04-06-2021

Yup. I always make sure to include a DB release step after any READ DB/GET DB data steps are performed--even if there is no data returned. It properly closes out the DB session.

Here is a sample of how I do SIMPLE DB queries using this method (in a subflow!!):

...I perform all DB queries in subflows so I can test them for accuracy without having to dial the trigger for the application. This also keeps it simple by passing input data into the subflow via the input mappings (ANI in the case above), and result in the output mappings (I evaluate the results in the parent script, first for NULL if no data is present, and then for the expected value). All major steps accounted for...

Hope this helps.

-Sean

lleweyiss · ‎04-13-2021

Thanks Sean,

I was trying to determine where to put the the location of the DB Release step -- should it be in each of the Branch steps of the DB Get and each branch of the DB Read step OR only for the branches of DB Read .... I noticed you do not have it only any Branch.

I have (3) DB Read steps, first one is ContactId - and the other (2) DB Read steps are cascaded down (via some IF steps) from the 1st DB Read.

The original author of script put DB Release steps for each branch of the 2nd & 3rd DB Get steps - but for the first DB Read & DB GET steps - the DB Release was put at the bottom of script right before the End Step - and that when that Exception occurs (shown above in MIVR log), but of course no on every call ...

I do have this as a subflow script from the main menu script.