In previous articles I promoted the trinity of Composite Bag Entities (CBE), Entity Event Handler (EEH), and the System.ResolveEntities (RE) component as the (new) go-to technique for building model-driven conversations in Oracle Digital Assistant. Entity event handlers are called in the context of resolving composite bag entities, which allows you to influence the flow of conversations, but also how entities extract information from user messages.
In this article, I provide a Expense Report Skill (ZIP) that uses two composite bag entities and two entity event handlers to help users submit an expense report with one or many expense items. I am sharing this sample to provide you with entity event handler sample code that you can use to learn from.
Note: I developed the skill reporting example for an Oracle Digital Assistant Design Camp session about Entity Event Handler. So, if you are new to the topic of entity event handler, please pause here and watch this video first.
Entity Event Handler Expense Report Sample In Action
Let’s start with how the demo performs at runtime to highlight areas that you find coded in an Entity Event Handler. The sample application is a simple version of an expense skill that follows the old traditional way of creating an expense report first to then add expense items to it. Let’s start with how the demo behaves at runtime to highlight areas that you can find coded in an entity event handler. The sample application is a simple version of an expense skill that follows the old traditional method of first creating an expense report and then adding expense lines.
So you start by typing “create new report” or similar. The first information you provide is a reason for the report. So provide whatever title you want to set for the report (note that at the end of filing the expense report, nothing will get submitted. The sample stops by printing a summary that could be sent to a backend system).
Once you provided a title, the system prompts you for providing an employee Id. This information could be accessed from the profile of an authenticated user in a production implementation. In this sample implementation the employee ID is a country code followed by a 1 – 6 number (see image below). Read the complete article here.
For regular information become a member in the Developer Partner Community please register here.