Multi-channel communication chatbot

On the 23rd of March SAS invited us to join them on this year’s ING Innovation Day. On this yearly event, ING asks several of its strategic partners to present innovative ideas related to a certain IT domain. Together with SAS we created a chatbot to answer human resource related questions, as elaborated here.

One of the core aspects developed by Finaps is the Data Service Layer (DSL), which enables multi-channel communication by combining various services.

 

Combining Enterprise Software with Open Source Software

Within the limited timeframe we had, we embraced the idea that chatbots are imperfect by themselves. To improve the response of our chatbot, we chose to combine existing technologies to quickly create value for the user. The fastest way to achieve this, is by creating a Data Service Layer (DSL) that combines open source services with enterprise software services, as can be seen in the conceptual architecture below.
 

 
This architecture is based on the idea of microservices. Microservices are small, independently deployable, modular services in which each service runs a unique process and communicates through a lightweight mechanism. The main difference with a more traditional Service Oriented Architecture (SOA), is that microservices use fast messaging mechanisms instead of a traditional Enterprise Service Bus (ESB). Both architectures share a lot of similarities. However, because of the messaging mechanisms and the smaller modules, creating new solutions or expand existing solutions can be realised easier.

For this specific use case, the Data Service Layer orchestrates all the messages between the microservices. With such a DSL, it is possible to quickly combine various types of microservices to create new experiences, values and services for users. Especially when combining existing enterprise software with open source software with the created DSL, new business values can quickly be realised when creating for instance a user application that communicates with the DSL.
 

Multi-channel communication chatbot

With the microservices architecture, a multi-channel communication chatbot can be realised rapidly, by combining several open source or freely available for use chatbots. As can be seen in the architecture below, two chatbots were used for this use case, but other services could be used to improve the experience. However, open source chatbots make it difficult to create a chatbot that adds value to employees of a company. It was therefore needed to utilise enterprise software to improve the “business knowledge” of the chatbot (e.g. “how many leave days do I have?”).
 

 
As can be seen in the above architecture, a SAS Decision Engine was used from an enterprise point of view. The SAS Decision Engine is often integrated with other enterprise systems and data warehouses within a company. This makes it possible to access company specific data and data analyses capabilities by creating an integration between the DSL and the SAS Decision Engine. This allowed us to access employee-specific (anonomized) data and have it analysed using the SAS Decision Engine, which enhanced the response of the chatbot.
 

Message orchestration

Within the DSL, orchestration is very important, as this determines which service is providing the response to the user. Below you can see the flowchart diagram that reflects the orchestration of incoming messages through the various services, ultimately leading towards a response that is sent back to the user. In this flowchart you can seen where decisions are made and what services are used at which stage.
 

 

Each incoming message is first analysed based on its content. Lets look at two example messages: “How many leave days do I have left?” and “How much parental leave do I have?”.

In both cases the user wants to know something about his or her remaining leave hours, which is the intent of both messages. In the first message, the user wants to know something about the general leave hours, while in the second message it is about parental leave. The entity of the messages is different (e.g. the entity is leave type).

When no intent and entity could be found in the message, the message is sent to an open source chatbot for a response. This chatbot excels at just keeping the conversation going. But when an intent/entity is found, the same service determines whether or not more information is needed (a data query action). If this is the case, the message is sent to the SAS Decision Engine to provide an answer based on the available data. This could mean that more information from the user is needed, which is communicated back to the first service. Either the first service or the SAS Decision Engine provides the DSL with a response that can be communicated back to the user.

One of the more powerful aspects of this setup is that each of the used services independently improves itself through machine learning. So if the chatbot is used more often, the quality of the responses only increase.

 

Play Framework

The service layer is build with the Play Framework. Play Framework is a web development framework with Java and Scala APIs that empowers developers to build applications with an ease unparalleled on the JVM. With the Play Framework you can maintain a delicate balance of performance and reliability, all within a micro-services architecture which is ideal for a chatbot service. Some key features of the Play Framework that made us choose this technology are:

  • A solid foundation in the JVM (Java Virtual Machine) while utilising other technologies for a fast solution. Fully asynchronous, non-blocking and stateless on top of Akka (an actor-based, message driven runtime);
  • Build-in support for JavaScript front ends, which can be used for various front-end applications such as API management or a web-version of the chatbot;
  • Build-support for websockets and REST for connection with other services like SAS or the mobile chatbot application;
  • Build-in support for various database types, such as SQL and NoSQL.