6 Powerful Capabilities of Custom Components for Oracle Digital Assistant

This technical blog explores just six of the many capabilities custom components have to offer for Oracle Digital Assistants (ODA). Before I delve into them, I’ll start by briefly describing what Oracle Digital Assistant can do and what its skills and components are.

Oracle Digital Assistant Skills #

Oracle Digital Assistant (ODA) provides automated and instantaneous support to customers and enables them to accomplish a variety of tasks using machine learning, natural language processing and conversational interfaces. It also offers a range of specialised skills, which are essentially individual bots focused on specific tasks through a combination of messaging and UI elements.

What are ODA Components? #

Every time a user engages with ODA, it evaluates the user input and routes the conversation to skills through various functions, called Components. These components can either be built-in, which perform generic functions like understanding the intent and outputting responses, or they can be custom components, which can, for example, perform custom logic to validate data or integrate with backend systems.

ODA Custom Components #

Custom components are reusable units of custom JavaScript code running in Node.js that can be called from the skill’s dialog flow. They can be entirely tailored to your business needs since the customisation possibilities are boundless.

Oracle Digital Assistant supports two types of custom components:

• Entity Event Handlers (EEH)
• Custom Dialog Flow Components (CCS)

Entity Event Handlers (EEH) #

Entity Event Handlers can be added to a skill’s dialog flow using an embedded skill container and an external IDE (Integrated Development Environment) such as Visual Studio Code, and then assigned to composite bag entities to invoke the custom code. EEH can execute API calls to backend services at any point in the custom code. However, since I’ll concentrate on backend integration for CCS, the use cases for EEH that I’ll discuss here are:

• Data collection and validation
• Conditional user prompting
• Frontend and backend two-way communication

Custom Dialog Flow Components (CCS) #

In a similar way, custom dialog flow components can be added to the dialog flow allowing custom code logic to be executed in the context of a conversation. There are numerous use cases for CCS, however, the ones that I will explore in this blog include:

• Integrating with backend systems
• Component reusability
• Debugging and error logging

6 Powerful Capabilities of Custom Components #

As readers of this blog will likely know, ODA offers an integration with Oracle Service Cloud (OSvC) and a popular use case for implementing ODA is to automate the creation of incidents in OSvC, which are linked to contacts, hugely reducing the workload on human agents. In the following portion of this blog, I will focus on the six capabilities listed above using this real-world example of creating an incident, which is linked to a contact, in OSvC. However, this is just one example of an endless amount of use cases in which an ODA can be tailored to handle your business needs.

1. Data collection and validation #

Using an EEH and a composite bag entity, which groups items that are related into a single object, to collect data for the creation of a contact and incident allows for immediate data validation upon input. For example, if you needed the user to provide an email address for their contact details, the EEH could validate the format of the email address on user input, using your business logic. Then, if the user inputs a response that does not validate, they can be re-prompted and can set the maximum number of user re-prompts. Using data validation in this way can lead to better data quality and provide your business with complete confidence in your customer data.

2. Conditional user prompting #

Furthermore, using an EEH and a composite bag entity, the bot can conditionally prompt for information depending on answers to previous questions. For example, if the user was chatting to the bot on a web support portal that they were logged into, the chatbot could extract their first name, last name and email address when the chat is initiated. The bot, since it already knows the user’s name and email, can then skip the composite bag items in which it collects the user’s details, as well as continuing the conversation, addressing the user with their first name. Extending the functionality in this way leads to a tailored and personal customer experience since the bot can intelligently ask relevant questions depending on the data it already knows.

3. Frontend and backend two-way communication #

Another powerful tool that ODA possesses is how the web SDK (which you can use to expose your ODA to your website and web application) can call any custom event in an EEH.

For scenarios where the frontend system contains more detail than is stored in a composite bag in ODA, the web SDK can be triggered by a user message, which calls a custom function and can pass information from the frontend system to the backend EEH custom component, and vice versa.

Using the web SDK can also allow you to create custom pop-up actions in the chatbot window when called from an EEH. This can hugely expand the capabilities of your bot as, for example, you can integrate with other platforms such as Google Maps. Let’s say you want to collect location information from the user. You can use an EEH to trigger a function in the web SDK to make a pop-up window, integrated with Google Maps, appear in the conversation UI. The user can then use the map and where necessary, the Street View functionality, to find the exact location of the incident, instead of using the built-in location entity that requires the user to type out the address.

4. Integrating with backend systems #

Once the composite bag as a whole has been resolved (i.e. all bag items have a value), a CCS can be called in the dialog flow. This CCS can then perform backend integration, via API calls, to commit the request to the database, so in this case, creating a contact and incident, linked together. One of the latest versions of ODA, v22.06, has introduced a new built-in component which inherently enables you to integrate with backend systems, however, it is only supported for visual dialog mode, and not for OBotML-based dialog mode. This is where custom components become invaluable.

Since CCS uses custom code, they can be as complex as is required and can fetch any amount of information prior to pushing data to a database. So in our example, instead of simply creating a new contact and incident each time a user interacts with the chatbot, backend integration could initially search the database to see if the contact already exists in OSvC. If there is a positive match, another call can be made to search to see if an incident is linked to that contact and if so, provide the user with details such as the incident reference number, status and or timeframe to resolution. In the case where the contact is not found, only then will it create a new contact and incident, leading to a completely self-serving operation.

5. Component reusability #

The way that ODA hosts custom components, if using an embedded container, allows for the CCS to be stored in external files and input parameters to be used. This means that when you create a CCS, you can have your code in one file, which can then call other more generic files of code, by simply passing in input parameters. Therefore, payloads used in web service calls, such as creating contacts, incidents and so on, can be constructed in a generic way to greatly increase their reusability in other skills and even other digital assistants.

6. Debugging and error logging #

Not only can custom components integrate with backend systems via API calls, but it can also provide powerful error logging and debugging capabilities, easing the implementation process for developers. The use of the browser developer tools when testing the skill, along with console logging lines, allows the implementer to effectively debug their code, especially useful since the capabilities of custom components are endless and so determining why it may be misbehaving is essential.

CCS defines supported actions which can be invoked to send information back to the skill. So, for example, if your supported actions are ‘success’ and ‘failure’, you can use control logic in the dialog flow to send relevant messages to the user. Additionally, where a call may fail for various reasons and the action of ‘failure’ is returned to the bot, you can extract the failure error, code, the reason and report it to an administrator. This is important in improving the performance of the chatbot as it will give evidence-based indicators as to why something may not be working.

Summary #

All in all, custom components are a hugely powerful part of ODA. They can incorporate bespoke logic that supports complex validation and other useful functions as well as allowing secure integration to backend services for querying and committing data and providing self-serving capabilities.

How can Boxfusion help? #

We have implemented many Oracle Digital Assistants across multiple industries where they have all harnessed a combination of these powerful capabilities of custom components. If you’d like to learn more about our ODA projects or if you are interested in implementing your own digital assistant, please get in touch!