article by Frank Nimphius, September 2018
Update: 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
Transitions in Oracle Intelligent bots are directives for the dialog flow engine of how to continue navigation. The type of transitions include
- empty transition
- action
- return
- next
- error
Transitions are defined either on the dialog flow state level for local navigation instructions …
… or as a default transition in the dialog flow header for global navigation instructions (a screen shot further below shows an example of where to define the default transition)
About Empty Transitions
Only on dialog flow states, you have the option to define an empty transition by not adding a transitions element at all or by using the following configuration: transitions:{}. With empty transitions, the navigation happens from a current state to the state defined below in the dialog flow.
Here is an example of the two configurations. First an example with no transitions element defined of state1 …
…, next an example that has the empty configuration set
Running the dialog flow for both examples, prints the following result …
So, What is the Problem?
The problem with empty transitions is that they are not explicit and therefore difficult to trace in case a dialog flow does not behave as expected. Let me give you an example. In the image below, the state1 has been changed to use a Common Response component that renders a list.
The list either navigates to state 2 or state 3, depending on what button is pressed. Looking at the OBotML code for the component in state 1, notice that an action transition is only defined for gotoState2, but not for gotoState3. Forgetting to map an action returned by system or custom components happens easily and more often that you think. So what happens of the user selects the "go to state 3" list element?
Selecting the "go to state 3" items leads to the following result.
Ouch. If state 2 was to cancel a selected flight and state 3 was to check the flight status, then you may be in trouble. Would you agree? So, what has happened?
The Common Response component state has an action transition defined to go to state 2. Since go to state 3 was selected, the dialog flow did not find a mapping in the actions transition setting. It then looked if an action mapping is defined as a default transition, and if not, follows the empty transition defined on state 1.
And yes, you don't see the empty transition as it is not explicit!
Note: A very common problem we see is that the last state in a dialog flow (the one at the very bottom oft the OBotML document) has an empty transition set. When a conversation reaches this state then the bot throws an error as the dialog engine has no clue what to do next. If the navigation to this state is a rare corner case in your bot conversation, then the error appears to be random and will cost you hours to research and fix.
The Solution: Always Use a next Transition
So, how to avoid bugs in your dialog flow through unintended navigation? The solution is to always set a "next:" transition. The "next:" transitions does what it says: it defines the name of the state to transition to if neither the action transition nor the error transition handles navigation. Here is a revised version of the CR component sample.
Now, running the bot again and selecting "go to state 3" does result in …
Of course, in a real bot implementation the "next:" transition is not meant to say sorry but to guide the user. Often its not that the bot designer forgets to map an action, but that the user provides an input you don't anticipate. In this case you may have the "next:" transition pointing to a state that prints some help text before it navigates back to the state (state1 in this case)
Thus, my recommendation to you is to always use a next: transition Always and on any state! Always adding a "next:" transition requires discipline, but makes your dialog flow better readable. If you work in a team, then other bot designers may add a needed state somewhere in the flow, in which case, allowing empty transitions, your conversation may enter the added state though it makes no sense.
Human conversations, and thus bot interactions are never linear or top-down. The go back and forth and up and down. The best way to stay in control really is to always have a "next:" transition defined even if in 99.9999999999999999% of all cases an action transition would handle the user input. Its the 0.0000000000000001% of the cases that you want to avoid.
How to Ensure That All States Have a "next:" Transition Set?
So, as a bot designer, how do you know if all states have a "next:" transition set? As usual, this is through testing and reading the dialog flow code. A trick to use is the following.
As from now on, you rule out any use of empty transition (except for quick-and-dirty functionality testing), you can define a next transition as a default transition. The image below has state 1 reset to no have a "next:" transition added. This time however it has a a default transition defined for it. The default transition is called when an action transition on a state does not handle an action and if the state does not have a "next:" transition defined. Before the empty transition is followed, the dialog flow checks for a default transition either for the action or the "next:" transition. If found, it happily follows that path
…
Running the sample and pressing the "go to state 3" option now prints
To find the state in which the empty navigation was used (after all, your bot may have many and very long conversations with a lots of states involved) go to the embedded tester and expand the JSON switch at the bottom.
Scroll down until the bottom of the message, where you will find (in case of this sample)
Notice the executedStates entry. The last state is "headsUpMyFriend", which basically means that state1 is the trouble maker. This way, while testing in the embedded tester you find it easy to find the state that does not have a "next:" transition set
How to Find the 0.0000000000000001% Chance Problem?
Not all problems can be found at design time and there is always something overlooked that shows at runtime first. In this case, instead of the "headsUpMyFriend" state to print a message, you could use a custom component, that reports the problem either through logging or other means for alerting.
Below sample code shows a simple custom component that logs the problem as a warning:
Conclusion
Avoid empty navigation by always specifying a "next:" navigation for a state. Use empty navigation only for testing. Following the hints in this article ensures that – assuming you stay disciplined – you stay in control of you bot conversation flow no matter what the user does.
So, revisiting the initial example in which the two states together print "Hello World", this should be coded using an explicit "next" transition on state1, as shown in the image below
Related Content
TechExchange Quick-Tip: Adding Default Transitions to Dialog Flows
