article by Frank Nimphius, September 2018
Note: Oracle Intelligent Bots has been rebranded Oracle Digital Assistant to better describe its capabilities beyond a standard chatbot. To learn more, visit cloud.oracle.com/digital-assistant
Oracle Digital Assistant allows you to define error handlers on individual dialog flow states in a conversation, or globally, as a default transition in the dialog flow header. In this article I'll show you how you can get the best of two worlds: A global error handler that allows you to handle local state errors.
Errors Handled by the System Error Handler
"error" is a transition in the dialog flow. This means that, to handle errors locally, you can define a transitions element to a dialog flow state. For example
mynlpState:
component: "System.Intent"
properties:
…
transitions:
error: "gotoHandleIntentErrorState"
The errors handled on a dialog flow state are usually exceptions thrown by a component or the platform. For the System.Intent component example, an error is thrown if the component variable property is not set.
Without defining a "error" transition on a state, errors are handled by the system error handler, which really should be seen as a last resort. The message printed by the system error handler is nothing you want your users to experience at runtime. Would you agree?
Well, I hope you agree. The error message below is created by a custom error handler navigated to by the "error transition", that, dependent on the state it is defined, can decide whether or not an error can be recovered from.
In the example shown in the image below, the bot apparently doesn't know how to recover from failure. At least however, it provides the user with an option of how to unlock the situation.
Well, as good as it sounds to be able to define an error handlers on individual states, very soon it might become cumbersome to manage. So, a better option would be if an error handler could be defined on a global level with the ability to still handle errors based on the state they occur. And this, as you may have guessed is possible in Oracle Digital Assistant.
Setting up a Global Error Handler
A global error handler is an "error" transition defined as a defaultTransition in the dialog flow header. The benefit of a global error handler is that all your error handling code could be in a single location, e.g at the end of the dialog flow, providing a much better way of organizing your code.
Note: You find an article written about default transitions here: TechExchange Quick-Tip: Adding Default Transitions to Dialog Flows
Globally Handling Local (State) Errors
The error message below is displayed for a multi-language bot for which the translation service is not available. An error is thrown when the system detects that the translation service is unavailable. However, in this case there is an option to recover from the situation, which is to continue the conversation in the base language of the bot (English in this case).
So when the error occurs in a state that detects the user language, then a resource bundle is used to print a message to the user in the user's language (determined by the user locale)
The German message in the image above actually says that the bot does have a problem with languages. Instead the bot asks if it is okay to continue the conversation in English.
Then, continuing the conversation in English allows the user to run the bot and get – in this case – flowers delivered. Of course, the bot should also offer an option for users that don't feel comfortable running the bot in English. Here, a button to connect with a human agent, or a phone number to call, could be provided.
The image below shows, how the sample above works. First of all, a defaultTransitions element is added to the dialog flow header. The "defaultTransitions" element aligns with the "states:" element. In here you can define the "error" transition, as well as any other dialog flow transition, like actions or the "next" transition.
In the image below, all "error" transitions are handled by the globalErrorHandler, a state defined in the dialog flow.
As the row number indicates, the error handler state is put towards the end of the bot dialog flow. The state uses a System.Switch component to determine whether the error is a local error that it can recover from, or a global error that it can't recover from. For this, the System.Switch component uses a system variable, system.errorState. The system.errorState contains the name of the state that triggered the error transition to occur. Based on the state name you can now handle errors individual.
For the sample in this article, all language errors are handled by a state called "prepareTranslationServiceErrorHandling". Other error states are passed to the "unrecoverableErrorHandler" state.
The System.Switch component allows you to handle as many state specific errors as you want. Thus the solution explained in this article gives you the best of two worlds: local and global error handling in a single implementation.
Below is the state that handles the misconfiguration in the translation service. For users with a locale set to English ("en"), it is assumed that the language used by the user is English. This means, that the error can be suppressed and instead the user entry is passed to the System.Intent state.
For other locales, the navigation proceeds to a state that displays a user message (e.g. asking of the conversation can be continued in English) or that dispatches users to a human agent.
Related Articles
TechExchange Quick-Tip: Why You Should Always Define a "next" Transition on Dialog Flow States
TechExchange Quick-Tip: Adding Default Transitions to Dialog Flows
