Deployment architecture

Let’s first understand where Qbo sits within a typical enterprise data and analytics architecture and how it provides data to the end users.

The figure below depicts a typical Qbo deployment.

../_images/architecture.jpg

Qbo sits between the end user and data sources. It processes natural language queries coming from the user, translates them into SQL queries to the databases, analyzes the data it receives, and presents the results in a meaningful way.

Users interact with Qbo via channels

Channels supported

Currently, Qbo supports the following channels:

  • Web

  • Mobile Web (including a progressive web app)

  • Slack

  • Teams

Users interact with a Qbo bot by asking queries in natural language. The web and mobile web interfaces offer additional features: autocompleting queries and creating and visualizing boards containing charts.

Data sources

Qbo connects to data sources using ODBC connections. It supports a multiple databases and big data systems.

Qbo server

Qbo can run on RHEL or CentOS 7. It includes:

  • an application and analytics server that interacts with users and the backend data sources.

  • a MariaDB database server that stores information about users, conversations and other configurations.

You can run each of these components on a single Linux machine, or on separate machines. Standard setup uses both components on a single machine.

You can also configure Qbo to work behind a web proxy like nginx, which allows it to expose an HTTPS endpoint to multiple channels. The web proxy can run on the same server as the Qbo application and analytics server, or on a separate machine.

Qbo supports multiple authentication mechanisms, including:

  • An internal username-password repository.

  • Connection to external systems via LDAP, such as Active Directory.

In the next sections, we will go over the software dependencies that must be satisfied before installing Qbo.