Aura – aura-platform

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Request access to Aura repositories in Github

Steps for L-CDO developers willing to access to aura-bot and aura-nlp Github repositories

How can L-CDO developers access to Github repositories?

All local CDO developers are enrolled into a specific team in Github for each country, which provides the access to the relevant Aura repositories in Github, such as https://github.com/Telefonica/aura-bot-libraries.

To gain access to your local CDO team in Github, you have to fulfill the following requirements:

Having a personal account in Github.
Two factor authentication (2FA) enabled for the account.
Your personal profile page in Github must fulfill the following requisites:

3.1. It must include a personal image, not an avatar, distinct from the one Github assigns by default.

3.2. It must include your name and surname.

3.3. It must include a “@telefonica.com” as the public personal email account associated to the Github profile.

ℹ️ Please, have a look at https://github.com/Korreca as an example of a valid personal profile page in Github.

ℹ️ You can also check the document Configuring two-factor authentication.

Once the previous requirements have been successfully fulfilled, please send a message to the “[APE] AURA-LCDO-XY-GENERAL” chat in Microsoft Teams (where “XY” should be substituted by the 2 letters code associated to your country) requesting access to the Aura repositories in Github.

A member of the APE team will request your registration into the Telefónica organization in Github. Afterwards, you will receive an email message including your personal invitation to be registered in it.

Once you have been included in the Telefónica organization in Github, a member of the APE team will enroll yourself in the appropriate “Aura Development XY” (where “XY” should be substituted by the 2 letters code associated to your country) which will grant you access to all the relevant Aura repositories in Github.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Alertmanager dashboard

Information provided by Alertmanager dashboards

Panels

Received alerts rate

It shows a time series with the received alerts rate aggregated by one minute.

The x-axis shows the time series and the y-axis shows received alerts rate.

The queries used to get the panel information are:

sum(rate(prometheus_notifications_alertmanagers_discovered[1m])) by(status)

An example of this panel is shown below:

The available metrics are defined in the following sections.

Successful notification rate

It shows a time series with the successful notifications rate aggregated by one minute.

The x-axis shows the time series and the y-axis shows the successful notifications rate.

The queries used to get the panel information are:

sum(rate(prometheus_notifications_sent_total[1m])) by(integration)

An example of this panel is shown below:

Failed notifications rate

It shows a time series with the failed notifications rate aggregated by one minute.

The x-axis shows the time series and the y-axis shows the failed notifications rate.

The queries used to get panel information are:

sum(rate(prometheus_notifications_errors_total[1m])) by(integration)

An example of this panel is shown below:

CPU usage rate

It shows a time series with the CPU usage rate aggregated by one minute. It also shows the current minimum, maximum and average cpu consumption of alertmanager.

The x-axis shows the time series and the y-axis shows the CPU usage rate.

The queries used to get panel information are:

sum(rate(container_cpu_usage_seconds_total{container="alertmanager"}[1m])) by (pod_name)

An example of this panel is shown below:

Memory usage

It shows a time series with the memory usage. It also shows the current minimum, maximum and average memory consumption of alertmanager.

The x-axis shows the time series and the y-axis shows the memory usage.

The queries used to get panel information are:

sum (container_memory_working_set_bytes{container="alertmanager"}) by (pod_name)

An example of this panel is shown below:

Pods network I/O

It shows a time series with the network I/O average aggregated by one minute. It also shows the current minimum, maximum and average network I/O.

The x-axis shows the time series and the y-axis shows the network usage.

The queries used to get panel information are:

sum (rate (container_network_receive_bytes_total{pod!="",pod=~"alertmanager.*"}[1m])) by (pod)
- sum (rate (container_network_transmit_bytes_total{pod!="",pod=~"alertmanager.*"}[1m])) by (pod)

An example of this panel is shown below:

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Analytics 1.1.

Description of Aura Analytics 1.1, the monitoring dataflow that allows active listening in Aura

Introduction

This document contains a description of a joint dataflow between LCDO OB teams and Aura Global Team for processing Aura log files created in production environment (i.e., coming from actual Aura users) in order to create PPDs (Privacy-Preserving Datasets). All this process is known as Active Listening.

The dataflow produces as a result, among other elements, an analytics component, named as Aura Analytics Dashboard, that can be used to gather statistics on the production system and to analyze user’s behavior. The latest version 1.1 of this dashboard is described in the current document.

The main objectives of the unified dataflow are:

Consolidate the processing of Aura logs into a framework.
Provide LCDOs and Aura Global Team with a unified common source for analytics, in a privacy-preserving way.
Enable extensibility of the dataflow.

In this framework, the current documents provide:  

The available data analytics versions
Prerequisites and recommended tools for its use
Overall description of Aura Analytics architecture
Description of the OB Analytics subsystem that enables the management by OBs
Current Aura Analytics data model

The target audience of this document includes the following roles both in LCDO Teams and Aura Global Team:

Data Scientists and Product teams, that wish to access Aura logs information and perform analytics on them.
Operation teams, for the architectural description and the requirements on OB environments.

Aura Analytics versions

Release 1.0.

The first release 1.0. sets up the basic paths, deploys the PPD infrastructure and produce:

Version 1.0. of the OB Analytics system, which includes the OB Dashboard.
The first version of pre-processed datasets (clean PPDs) for training and analytics at Aura Global.

As mentioned, this version enables OBs to go further by:

Enhancing the OB Dashboard with new visualizations, as they seem fit (given that panels and dashboards can be exported and imported, it is possible to share new ones across all OBs, as they are developed).
Processing the PPD files as desired (they are standard CSV files, which can be ingested in alternative platforms if desired). Restrictions on them are softer than on the original logs due to the anonymization process they have been subjected to, although they are still subjected to management precautions (a code of conduct is being prepared for that).

Release 1.1.

Version 1.1. introduces the following changes:

The table of data has been enlarged with these new fields: AURA_ID, STATUS_CD, sesId, sesSize, sesDuration.
An expanded list of test users is used, so that the userType column contains more identifications.
The code for data ingestion into a local Kibana, which previously consisted on a single Python script, has been turned into a full Python package to be installed, due to its increasing complexity.

Prerequisites and recommended tools

The prerequisites for the use of version 1.1. of Aura Analytics Dashboard are set below:

Aura Platform version:
Recommended operating system:Ubuntu 18.04 system
Recommended tool for data visualization: ELK stack

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Billing Module

Description of Aura Billing Module, the tool for the generation of Liceo invoices.

Introduction

The Aura Billing Module is a tool for the generation of Liceo invoices, that allow charging each customer for the services that she has used. This is a mandatory process for OBs.

It is based on the storage and processing of specific logs in the OB’s Aura systems to track the type and number of interactions of a user or service with Aura.

This information is used to assign costs based on different billing models and criteria chosen by the OB, which ultimately determines the total amount of the invoice.

The invoices will be generated in XLSX (Excel) format and stored in an Azure Storage Explorer blob container, along with the historical invoice records.

These invoices will be available for download by the Aura Global Team, to be sent to the OBs.

Interested in how the Aura Billing Module works and which are the tasks required to bring it into use? Access the document Aura Billing Module operation.

Generated Liceo invoices

The Liceo invoices generated by Aura Billing Module will contain the following information:

Invoicing model (based on the payment model of the OB)
Aura components used to provide the service
Service/app that used this component
Number of queries per component
Cost of each query in each specific component
Total amount generated by each component
Total number of requests made during the billing period
Total amount of the invoice

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Billing Module operation

This document contains:

An overview of Aura Billing Module functional operation
Tasks to be executed by OBs to bring Aura Billing Module into use

Aura Billing Module operational flowchart

Figure 1 schematically shows how Aura Billing Module operates, where three different instances come into play:

Aura: OB managed environment
Aura: Global Team managed environment
Kernel

Figure 1. Aura Billing Module operation

The operational processes executed by the Aura Billing Module are outlined below. In each step, the tasks that must be carried out by the OBs in order to bring it into use, are described.

1. Data generation

This task takes place in Aura’s OB managed environment.

Aura components automatically generate logs every time a user/service interacts with Aura in local environment.
These logs are pre-processed, cleaned and converted into datasets, in Avro format.
These are the required Avro-formatted datasets for the Aura Billing Module:
- Aura_Audit, that stores the minimum information needed for generating the Liceo invoices.
- Aura dimensional entities:
  - D_Aura_App schema definition: List of possible Apps defined in Aura.
  - D_Aura_Channel: List of possible channels defined in Aura.
  - D_Aura_Component: List of possible components defined in Aura.
  - D_Aura_Preset: List of possible presets defined in Aura.
  - D_Aura_Recognizer: List of possible recognizers defined by Aura.
  - D_Aura_Skill: List of possible skills defined in Aura.
- Aura Gateway Message: summary of Aura interactions handled by aura-gateway-api.

2. Data publication in Kernel

The latest versions of the previous Avro-formatted datasets must be published into Kernel productive environment by the Kernel team.

Tasks for OBs

2.1. Ask the Kernel Team to publish the datasets in Kernel productive environment with the latest version.

2.2. When correctly published, you can check them in the repository: 4p-datasets

3. Kernel apps configuration to write/read datasets

Two Kernel applications (clients) must be created/configured by the Kernel team to allow the use of Kernel resources:
- aura-bot-[environment]: already existing app in Kernel
- aura-billing-[environment]: new application
Specifically, the applications must be configured with concrete scopes that provide permissions to write/read the datasets.
The obligation to indicate the exact version in the configuration is removed. Therefore, in the following deployments, the version number indicated in the scope will be eliminated. For example, the configuration of the Brazil OB will have to be updated when a new scope change is made. For example: data:Aura_Audit:6:read —> data:Aura_Audit:read.

Tasks for OBs

3.1. Configure aura-bot Kernel application to write datasets

Ask the Kernel Team to create a list of scopes in the aura-bot application for your intended environment.

- admin:datasets:read
- data:read
- data:write
- data:Aura_Audit:read
- data:Aura_Audit:write
- data:Aura_Gateway_Message:read
- data:Aura_Gateway_Message:write
- data:D_Aura_App:read
- data:D_Aura_App:write
- data:D_Aura_Channel:read
- data:D_Aura_Channel:write
- data:D_Aura_Component:read
- data:D_Aura_Component:write
- data:D_Aura_Preset:read
- data:D_Aura_Preset:write
- data:D_Aura_Recognizer:read
- data:D_Aura_Recognizer:write
- data:D_Aura_Skill:read
- data:D_Aura_Skill:write
- data:D_Gbl_Brand:read
- data:D_Gbl_Contact_Channel:read
- data:D_Gbl_Country:read
The scopes are associated with a specific version of the dataset, that will increase and vary with time.

3.2. Create a new app for Aura Billing Module and configure it to write datasets

Ask the Kernel Team to create a new application aura-billing in Kernel for your intended environment

Ask the Kernel Team to create a purpose for this application. For instance, aura-kpi-data-read-purpose

Ask the Kernel Team to assign to this purpose the following scopes:
- admin:datasets:read
- data:read
- data:write
- data:Aura_Audit:read
- data:Aura_Gateway_Message:read
- data:D_Aura_App:read
- data:D_Aura_Channel:read
- data:D_Aura_Component:read
- data:D_Aura_Preset:read
- data:D_Aura_Recognizer:read
- data:D_Aura_Skill:read
- data:D_Gbl_Brand:read
- data:D_Gbl_Contact_Channel:read
- data:D_Gbl_Country:read

3.3. Access the Kernel applications

Once the Kernel team has created the app with the above-mentioned purposes and scopes, two parameters for securely accessing the app will be provided:
- client_id: unique identifier of the consuming app acting as Kernel API client.
- client_secret: password.
This allows Kernel to securely identify, authenticate and authorize any access requested from this app.

4. Data processing

Data processing is executed with Azure Databricks.

In this process, the information from the Kernel datasets is recovered and read by the Aura Billing Module, that uses algorithms to assign a unitary cost to each concept that composes the invoice to calculate the total amount of this invoice.

Tasks for OBs

4.1. Enable Aura components

Check that Aura KPIs Uploader, the component in charge of the management of KPIs entities and KPIs dimensions in Aura, is in use.

Check that Aura Databricks Jobs, component used to import Avro-formatted files into a Kernel dataset, is enabled in Aura installer.

Configure Azure Common:
- To avoid data files migrations between releases, KPI files are now stored in an Azure common storage that is not release dependent.
- The default value of days for KPIs uploading is changed to 30 days. Due to that, the variable fourth_platform.conversations.days_to_find must be removed from OB deployments, because it will be configured by the installer.

5. Data consumption

This step refers to the generation of the Liceo invoices and its storage in Azure Storage Explorer in xlsx format.

These invoices will be available for download by the Aura Global Team, to be sent to the OBs.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura infrastructure

Scope: Aura Virtual Assistant and ATRIA infrastructure documentation for DevOps Teams that describes architecture, networks and platform services

Introduction

The current section includes a view of Aura architecture focused on the Aura deployment process.

Aura architecture flowchart for DevOps Teams
Nodepool common: set of nodes with a common configuration and specification
Kubernetes cluster
Aura Platform services

Aura architecture flowchart

Nodepool common

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura system dashboards

Grafana dashboards with metrics related to the performance of Aura system

Introduction

Currently, these are the available Aura system dashboards in Grafana based on metrics stored in Prometheus:

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Basic Jenkins configuration

Discover the basic Jenkins configuration

Introduction

Aura uses Jenkins as continuous integration (CI) tool. In particular, the in-house installation in DCIP.

Webhook	URL	Content type
Pull Request	https://ci.tid.es/pro-dcip-aura-01/ghprbhook/	`application/x-www-from-urlencoded`
Push	https://ci.tid.es/pro-dcip-aura-01/github-webhook	`application/x-www-from-urlencoded`

Configuration

Configure a webhook in a github repository

Prerequirement: administrative access to Github repository and to dcip are must.

In the Github web of your repository, go to Settings and to Webhooks, as can be seen in the following picture:
Click on Add webhook, the following window will be shown:
- Fill the URL of the webhook and its content type format
- Choose Let me select indivial events and select only Pull requests. Remember to uncheck Pushes that’s checkec by default.
- Set the webhook as Active and click on the Add webhook button to save the configuration.

Jenkins jobs

ℹ️ Prerequirement: administrative access to dcip is a must.

First thing is to create a new set of Jenkins jobs for your brand new respository, so from the main aura Jenkins page, you should run _component-setup job.
Choose Build with parameters and fill the data of your repository in this case aura-bot-platform. Remember to use ssh as repository URL.

This job will generate a new set of jobs specific for the current repository and with its very same name.

Generate a dedicated slave to run these jobs

Add a Dockerfile to the root of your repository (follow the one in aura-bot-platform). In this case, a new slave definition is needed to run the jobs with a node10 docker container.

To build it, just build the job _docker-slave-setup with parameters:

This will generate automatically the job _docker-slave-builder that will process, configure and publish a docker image based on the provided Dockerfile. Slaves using this image will be available under the label repository-name, in this case: aura-bot-platform.

Build PR job

This is one of the automatically jobs generated by the _component-setup job. It will run whenever a Pull Request is requested in the repository, if it counts on the corresponding webhook.

The basic configuration provided automatically is OK, but in Aura we should apply a couple of changes to handle it properly:

Check Restrict where this project can be run and write the just created aura-bot-platform labeled slaves.
To access github, select the already available credentials (usually contint (contint user for GITHub/PDIHub)).
A couple of environment variables should be configured:
- NPM_TOKEN: it should be added in “Build Environment” section, binding a secret text, with the specific credential.
- DOCKER_HOST: it should be added in “Build Environment” section, binding a secret text, with the specific credential.
The next step is to include execution of the existing delivery/pipelines/pr.sh script during the building phase of the job.
- In Build section, just add an Execute shell step with the following content, depending on the project, further variables should be needed:
```
#!/bin/bash
set -e
export DOCKER_HOST=${DOCKER_HOST_VM}
git remote set-url origin git@github.com:Telefonica/aura-bot-platform.git
delivery/pipelines/pr.sh
```

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Basic monitoring queries

Learn how to get information for the evaluation of Aura system performance through basic queries

Introduction

The current document shows the guidelines for making queries to Grafana and Kibana in order to retrieve basic information from the system.

Number of TPS per component

Request rate in Grafana

Access Grafana of the environment.
Select “Aura HTTP inbounds” dashboard.
Select the time period for the query.
Select the service of your choice, as can be seen in the following picture:

The panel named “HTTP Request Rate” shows the total number of requests being processed by a service.

This panel is based on the Prometheus aura-bot stored metric called http_request_duration_seconds aggregated in buckets of one minute.

It shows in the y-axis the number of requests in the service and in the x-axis the time period.

Request rate in Kibana

Add a new dashboard with the following data:

Select the time interval for the filter
Query (overwrite your-env with the environment of your choice):
- aura-bot:
  - Public endpoints but healthcheck: msg: "Response returned" and kubernetes.labels.app : "aura-bot" and kubernetes.namespace_name: "your-env" and not path: "/ping".
  - For all the endpoints of the service: msg: "Response returned" and kubernetes.labels.app : "aura-bot" and kubernetes.namespace_name: "your-env".
- aura-authentication-api:
  - Public endpoints but healthcheck: msg: "Response returned" and kubernetes.labels.app : "authentication-api" and kubernetes.namespace_name: "your-env" and not path: "/ping".
  - For all the endpoints of the service: msg: "Response returned" and kubernetes.labels.app : "authentication-api" and kubernetes.namespace_name: "your-env".
- aura-bridge:
  - Public endpoints but healthcheck: msg: "Response returned" and kubernetes.labels.app : "aura-bridge" and kubernetes.namespace_name: "your-env" and not path: "/ping".
  - For all the endpoints of the service: msg: "Response returned" and kubernetes.labels.app : "aura-bridge" and kubernetes.namespace_name: "your-env".
- tac-api:
  - Public endpoints but healthcheck: msg: "Response with status" and kubernetes.labels.app : "tac" and kubernetes.namespace_name: "your-env" and not path: "/ping".
  - For all the endpoints of the service: msg: "msg: "Response with status" and kubernetes.labels.app : "tac" and kubernetes.namespace_name: "your-env".
- aura-nlp:
  - Public endpoints but healthcheck: msg: "HTTP request" and kubernetes.labels.app : "nlp" and kubernetes.namespace_name: "your-env" and not path: "/ping".
  - For all the endpoints of the service: msg: "msg: "msg: "HTTP request" and kubernetes.labels.app : "nlp" and kubernetes.namespace_name: "your-env" .
- aura-context:
  - Public endpoints but healthcheck: msg: "HTTP request" and kubernetes.labels.app : "context" and kubernetes.namespace_name: "your-env" and not path: "/ping".
  - For all the endpoints of the service: msg: "msg: "msg: "HTTP request" and kubernetes.labels.app : "context" and kubernetes.namespace_name: "your-env" .
Index: aurak8s-service
Data:
- Metric: Unique Count
  - Field: corr.keyword
  - Custom label: Number of requests
Buckets: split rows
- Aggregation: Date histogram
- Field: @timestamp
- Minimum interval: minute

Update the dashboard and name it, in order to have it available.

A basic example of this dashboard with a panel per component is delivered with Aura, so it can be imported in the Kibana of the environment using Kibana import objects API.

Number of unique users in Aura

In this case, the only way of getting the number of unique users accessing to Aura is querying the operational logs, in Kibana.

Add a new dashboard in Kibana with the following data:

Select the time interval for the filter
Query (overwrite your-env with the environment of your choice): app.keyword : "aura-bot" and kubernetes.namespace_name.keyword : "your-env"
Index: aurak8s-service
Data:
- Metric: Unique Count
- Field: auraId.keyword
- Custom label: Number of unique aura users
Buckets: split rows
- Aggregation: Date histogram
- Field: @timestamp
- Minimum interval: 1h

Update the dashboard and name it, to have it available.

A basic example of this dashboard with a panel per component is delivered with Aura, so it can be imported in the Kibana of the environment using kibana import objects API.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Configure your releases

This section group guidelines with the specific configuration required by an OB for installing a particular Aura version

Index

Dependencies update in Prince 10.0.0 release

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Dependencies update in Prince 10.0.0 release

These documents include all the updates in components that have been carried out for the release Prince 10.0.0, along with the corresponding migration or adaptation tasks that should be executed by the OBs Teams.

Index

Python repositories migration for PyUtils, Aura NLP, Aura Complex Logic Framework plugin packages and ATRIA repositories.
Nodejs-related dependencies update in Prince release

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Manage Aura logs

Learn what are Aura logs and how they are managed in Kibana and other tools

Introduction

Logs are files that record specific single events, warnings and errors as they occur within a software environment. They can include contextual information, such as the time an event occurred and which user or endpoint was associated with it.

In Aura, logs are generated by specific components when an event happens and stored in order to monitor or debug the system.

Logs are stored in an ElasticSearch cluster.

Once stored, Aura integrates a logging system based on Kibana, which is the official tool to manage logs in Aura. Moreover, logs can be managed with Grafana and fluentd for specific features.

⚠️ You should not integrate third-party applications or scripts with ElasticSearch. These kinds of integrations are weak because the ElasticSearch API is not part of the public interface with the OB. This means that it could change without notice for several reasons such as updating the version of ElasticSearch or changing Aura internal architecture.

Manage logs in Kibana

The official Kibana User Guide is the reference guide to use Kibana.

Moreover, the current section includes certain useful points for managing Aura logs through this tool.

Policies in Kibana

Kibana includes index lifecycle policies.

By default, we add one policy for each index created (service and system index), to delete the logs older than seven days.

Snapshot in Kibana

Index snapshot is configured by default as long-term storage for the logs. These snapshots are taken daily and end in the cluster Azure Storage blob container (aura-backups/elk).

Manage logs in Grafana

Discover section

The “Discover” section in Grafana is very useful to look for logs and troubleshoot issues.

You can full-text search logs using Lucene query syntax.

Moreover, logs are tagged with many fields that can be useful to narrow down a search, such as:

kubernetes.labels.app: name of the Kubernetes application that generated the log.
kubernetes.pod_name: name of the Kubernetes pod that generated the log.
corr: correlator that tracks E2E requests.
lvl: log level (TRACE, DEBUG, INFO, WARN, ERROR or FATAL).

Queries that rely on a specific text are weak. Aura cannot guarantee that log messages do not change between versions. In fact, they do change. This is why metrics based on logs will not be reliable and it is not recommended to use Kibana to get metrics.

Manage logs in fluentd

Logs external forwarding feature

It is possible to send logs to an external system (a fluentd endpoint).

To enable this feature, add the following configuration to your config file:

external_forwarding:
  secret_shared_key: "mysecretkey"
  tls_config:
    tls_enabled: True
  remote_servers:
  - hostname: xxx
    port: yyy

Set hostname and port fields with the remote endpoint. If you configure more than one remote server, fluentd load balances the traffic to them in a round-robin order.
The hostname value can be an IP address, but it is not recommended if TLS is enabled. Turning off TLS is possible but discouraged for security reasons.
secret_shared_key is used to verify client’s identity and must be configured properly in all the remote servers.

You can find additional information regarding receivers’ configuration (including TLS configuration and password authentication procedure) here.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura operational flowcharts

The current section includes certain key operational flows in Aura

Introduction

Find the following flowcharts for Aura operational processes:

Basic Direct Line flowcharts for anonymous and authenticated users
User Authentication flowcharts, that show how users’ authentication is handled depending on how the channel is integrated in Aura
Use cases flowcharts for basic use case execution flows
WhatsApp flowcharts for basic processes, Terms & Conditions management and authentication in this channel
Auraline flowcharts, containing the messages flow for this communication protocol

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura QA global test set (QA Tool)

Check Aura global quality through the QA Tool. Find in this document the description and requisites for its execution and access to the guidelines for its installation, configuration and execution

⚠️ Recommended step if a new Aura Platform version is installed:
Even though you already have the QA Tool installed, it is highly recommended to reinstall the QA Tool requirements in order to assure its proper execution.

For this purpose, follow the steps in QA Tool installation guide: install requirements.

What’s the QA Tool?

The Aura Platform Team provides developers with a QA global test set (informally, QA tool) for them to check the quality of their Aura system, with their own configuration and installed use cases. This quality can be assured in two ways:

Verification of the optimum operation of Aura system with the OB’s configuration.
Verification of the proper performance of global use cases.

⚠️ Local use cases cannot be checked using the QA Tool

The QA tool can be configured by the OB both in pre-production/production and local environments. Each configuration is useful for a specific purpose and requires different types of tests, as detailed in the figure below. Each of them is fully defined in succeeding sections.

The following sections include the requisites for the QA Tool execution, as well as the description of the working directory and branches.

Moreover, consult the guidelines for:

Requisites for QA Tool execution

OBs must work with the below detailed minimum resources to execute the QA Tool:

Technological resources

The QA tests can be executed from Mac, Windows and Linux.

The required technological resources are listed below:

Python version: 3.10 / 3.11
Pip (>= 19.1)
virtualenv (>=15.0.0)
Github license
git (>=2.13.0)
tar (>=1.30)
kubectl (recent version)
Docker (recent version)
Docker-Compose (recent version)
Access to the aura-test Github repository

Aura release vs QA Tool branches

Each Aura Platform release has its own branch for the execution of the QA Tool. The name of this branch will be:
release/[release_name]
Where [release_name] must be a unique word written in lowercase letter. In case the release name contains two words, they will be unified.

For example:

Jimi Hendrix ➡️ release/jimihendrix
Nirvana ➡️ release/nirvana

QA Tool working directory and folders

The main working directory for the execution of the QA Tool is: https://github.com/Telefonica/aura-tests

ℹ️ If the OB has any access problem, please report it to APE Team, through the established Teams chats.

The files from the aura-tests repository that will take part on the execution of the QA Tool are included in the folder /acceptance.
The remaining folders contain internal QA files that are not needed for this process:

📁 ~/[project_folder]/aura-tests/acceptance/

The folders that will take part in the process and their role, within the ~/[project_folder]/aura-tests/acceptance/ repository, are described below:

settings/ folder

📁 ~/[project_folder]/aura-tests/acceptance/settings/

Configuration of environment credentials
Users’ configuration
Generation of files for the configuration of users.
Setting of properties
Step to be carried out during the execution of the QA test set.
Configuration of kubernetes

resources/ folder

📁 ~/[project_folder]/aura-tests/acceptance/resources/

Texts resources to be used on tests.
Selenoid utility

scripts/ folder

📁 ~/[project_folder]/aura-tests/acceptance/scripts/

Scripts for launching the different tests during the QA Tool execution.

_output folder

After the QA Tool execution, this folder will be generated containing the results from the different tasks:

Environment credentials
Versioning of module installed
Users’ configuration
Text resources (POEditor)
Output files

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

QA Tool installation guide

Guidelines for the installation of Aura QA Tool

Download the QA test set from a Github repository

In order to download the QA tool from one specific branch in the GitHub repository, follow these instructions:

Open a terminal.
Change the current working directory to the location where the cloned directory will be placed.
Type the following command: git clone https://github.com/Telefonica/aura-tests.git

Press “Enter”. The local clone will be created.

$ git clone https://github.com/Telefonica/aura-tests.git
Cloning into 'aura-tests'...
remote: Enumerating objects: 1095, done.
remote: Counting objects: 100% (1095/1095), done.
remote: Compressing objects: 100% (235/235), done.
remote: Total 30040 (delta 962), reused 947 (delta 850), pack-reused 28945
Receiving objects: 100% (30040/30040), 55.39 MiB | 3.28 MiB/s, done.
Resolving deltas: 100% (23490/23490), done.

Check the specific branch for your release in Aura release vs QA Tool branches and switch to this branch using the following instructions:
```
git checkout <branch_name>
```

Create and activate the new virtual environment

Make available a new virtual environment through these steps:

Create a virtual environment for the project:

$ cd <project_folder>
$ virtualenv venv

Activate the virtual environment:
```
$ source venv/bin/activate
```
If it is required to deactivate the virtual environment:
```
$ deactivate
```

Install requirements

⚠️ Remember that it is highly recommended to reinstall the QA Tool requirements if you have installed a new Aura Platform release

Once the virtual environment is activated, install the packages required for the QA tests execution in the current environment. The installation must be done inside the activated virtual environment.

The requirements are included in the file requirements_ob.txt, within the folder: https://github.com/Telefonica/aura-tests/blob/master/acceptance

The steps to do that, are described below:

$ cd [project_folder]/aura-tests 
$ cd acceptance/ 
$ pip install -r requirements_ob.txt

ℹ️ Please, ignore no critical warning or errors messages that can be displayed, depending on the system versions.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Postman Collection - Video Contents Kernel API

Postman collection with sample requests to Video Contents Kernel API

Introduction

This Postman Collection is based in the Video Contents Kernel API.

It includes requests to get token and example requests of TV Search plugin.

Environment and collection files

Download environment and collection and import both files in Postman.

Import collection

To import the collection and environment, you can see the reference info about this process here.

Once the collections are imported, the environment’s values should be completed. Below, a short description about the enviroment’s variables is listed:

administrative_number_es: administrative number of Spanish user.
user_id_es: identifier of Spanish user.
channel_id_es: identifier of Spain channel authentication.
administrative_number_br: administrative number of Brazilian user.
user_id_br: identifier of Brazil user.
channel_id_br: identifier of Brazil channel authentication.
auth_url: authentication URL.
issuer_url: issuer URL.
expiration_token: time to expire the token in seconds.
scope: list of scopes separated with spaces.
purpose: list of purposes separated with spaces.
private_key: private key to get assertion token.
header_key_id: key id for headers to get assertion token.
client_id_es: client id to authenticate a Spanish user.
client_secret_es: client secret password to authenticate a Spanish user.
client_id_br: client id to authenticate a Brazilian user.
client_secret_br: client secret password to authenticate a Brazilian user.
authorization_id_es: authorization id for Spanish user.
authorization_id_br: authorization id for Brazilian user.

The majority of variables imported for this environment have assigned a default value, only the following variables must be completed: private_key, header_key_id, client_secret_es and client_secret_br.

The collection is composed by:

Get token ES request: to get the access token for Spanish users.
Get token BR request: to get the access token for Brazilian users.
ES folder: requests to search in the Spanish video content.
BR folder: requests to search in the Brazilian video content.

How to use this collection

First, select the environment imported, see the process here.

Then, to send a request in the folder ES or BR, it is previously required to send the request Get token ES or Get token BR respectively.

And finally, try to send any request included in the folder ES or BR.

⚠️ When the request response is UNAUTHENTICATED, send the request Get token ES or Get token BR according to each case and try again the previous request.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Analytics 1.1. architecture

Technical architecture of Aura Analytics 1.1.

Architecture description

The following figure shows a full overview of Aura Analytics Dashboard architecture and operation, which is also described below:

 Aura logs generated in local instance are converted to datasets and transferred to local Kernel via the standard procedure and with the established frequency (typically, daily).
 Once there, the “Active listening” process flow fires up daily. Through a specialized process that runs on an Aura local instance and with access to the stored datasets in the Kernel local storage space:
- PII (Personally Identifiable Information) is removed or encrypted.
- The result is transferred to a bucket/blob set up for this task and managed by Global Aura team.
- Here, the PPDs (Privacy-Preserving Datasets) are created. Currently, only MESSAGE, RECOGNIZER and API datasets are involved in this process.
In order to convert PII data to PPD, every field in these datasets can be:
- a. Not transferred.
- b. Pseudo-anonymized. In this situation, the field is transformed through a cryptographic hashing process using a secret set up by the OB.
- c. Anonymized fragments of the field (e.g., credit card number, email, etc.). The field is processed to detect specific patterns and replaces them with a specific tag (idemail, idpassport, etc.). The list of anonymization strings is agreed with each OB.
- d. Transferred as is.
 After that, the Raw PPD Datasets stored in bucket/blog managed by the Global Team are processed generating clean PPD Datasets in order to adapt them to the analytics tools.
 From that space, the clean PPD Datasets can be:

Accessed by the Aura Global Team that use them for several tasks, with the purpose of evaluating Aura quality and taking the best decisions regarding to product evolution:
- Perform analytics on Aura behavior and prototype Analytics Dashboard features
- Improve Aura Platform capabilities (e.g., adapting machine learning models)
Accessed by a Local Aura Team, ingesting the data to a dedicated server managed by the OB with analytics and data visualization capabilities. In order to do that, the Aura Global Team provides a component with the ELK (elasticsearch, logstash & kibana) preconfigured with a set of dashboards that can be deployed and adapted by the OB team.

All the code involved in this process can be found in Github. Particularly:

PPD RAW creation package
Conversion from PPD RAW to PPD Clean
Pseudo-anonymization function for identifiers
Utterance anonymization (agreed individually for ES and UK)

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Context architecture and operation

Discover Aura Context functional architecture and its operational process

Functional architecture

Aura Context v1 functional architecture contains the following components:

Context broker & server API
Server API in Aura Context for uploading, updating and recovering context data by different Aura sub-systems.
Aura Context Service
Core module of Aura Context in charge of gathering data from the context API, uploading it into de context database and data recovery.
Aura Context cache/database
Temporary high-performance database placed inside the Aura instance that is able to storage user’s data corresponding to the user’s previous experiences or environment. Data is available in the context database for a limited period of time and it cannot be recovered once this period expires.
The key features of Aura Context database are shown below:
- 360 approach: Aura Context aims to gather all type of information from an Aura interaction, including data coming from channels.
- High-available database: real-time recovery during the user’s interaction, with no lateness.
- Temporary data storage: data available only for an established period of time.
- Data persistence in Kernel for historical data exploitation purposes.
Context Kernel persistence mechanism
First basic version of the Kernel persistence mechanism. Within a one-direction flow, context data stored in the database is sent to Kernel for an unlimited period of time. Data on Kernel can be checked or processed following the same procedure as for Aura data.

Aura Context performance

The following steps schematically shows the process carried out by Aura Context:

Context data is sent to Kernel where it is stored for an unlimited period of time.
This information can be retrieved by an external stakeholder just by calling the corresponding API.
Developers can consume data in the Aura Context database when developing a use case. For this purpose, the aura-bot dialog must call the corresponding API in order to retrieve context data and include it in the response to the user.

Aura Context operational flowchart

Before facing this section, it is recommended to read the document Aura Context components.

Considering the Aura Context components, the following flowchart shows the operational process carried out by the context:

An external component makes a request to Aura Context API (POST HTTP request) for carrying out a specific operation:
- Create: creation of a data entry in Aura Context
- Upsert: modification of a data entry in Aura Context
- Fetch: data recovery from Aura Context
The context API sends the request to Aura Context service.
The request transform converts input data into data suitable with the Aura Context global data model.
The specific operation is performed: Create / Upsert / Fetch.
Output data from the operation is converted into data compatible with the user’s data model through the response transform.
The response is sent back to the context API and provided to the external component.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura components dashboards

Grafana dashboards with metrics related to the performance of specific Aura components

Introduction

Currently, these are the available dashboards for Aura components in Grafana based on metrics stored in Prometheus:

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura distributed Postman collection

Postman collection for simulations in Aura distributed

Aura distributed collection

Collection

It includes requests to refresh skills and/or channels information, and health check.

Environment variables

Environment

Environment variables for aura-distributed collection.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Basic database queries

Learn how to get information from the database to get some insights

Requirements

A valid kubeconfig for the environment
If the environment database is in Atlas: access to Atlas by IP

Get the variables to access the database:

# substitute {{aura-environment}} with the environment you're configuring
export AURA_ENVIRONMENT={{aura-environment}}

$ kubectl -n $AURA_ENVIRONMENT get cm authentication-api -o json | jq -r ".data.AURA_MONGODB_URI"

{{mongo_uri}}

$ kubectl -n $AURA_ENVIRONMENT get cm authentication-api -o json | jq -r ".data.AURA_MONGODB_USERNAME"

{{mongo_user}}

$ kubectl -n $AURA_ENVIRONMENT get secret authentication-api -o json | jq -r ".data.AURA_MONGODB_PASSWORD|@base64d"

{{mongo_pass}}

$ kubectl -n $AURA_ENVIRONMENT get cm authentication-api -o json | jq -r ".data.AURA_MONGODB_USER_DB"

{{mongo_users_db}}

$ kubectl -n $AURA_ENVIRONMENT get cm authentication-api -o json | jq -r ".data.AURA_MONGODB_USER_COLLECTION"

{{mongo_users_col}}

Get the channel_name and channel_id for the all channels in the environment:

# substitue {{aura-environment}} with the environment you're configuring
export AURA_ENVIRONMENT={{aura-environment}}

$ kubectl -n $AURA_ENVIRONMENT get cm aura-bot -o json | jq -r ".data.AURA_CHANNELS_CONFIGURATION_API_ENDPOINT"

{{channels_configuration_endpoint}}

$ kubectl -n $AURA_ENVIRONMENT get secret aura-bot -o json | jq -r ".data.AURA_AUTHORIZATION_HEADER|@base64d"

{{authorization_header}}

$ curl {{channels_configuration_endpoint}}/aura-services/v2/configuration/channels -H "Authorization: {{authorization_header}}" -o channels_config.json

$ cat channels_config.json| jq -r '.[] | .name + ":" +.id'
{{ channels }}

# Example of channels
# novum-mytelco:45494a5b-835a-4fff-a813-b3d2be529dbe
# whatsapp:f7fd1021-41cd-588a-a461-387cc24be223
# whatsapp-1004:e75e7b9d-7949-451a-9493-3d759745492c
# movistar-plus:60f0ffda-e58a-4a96-aad9-d42be70b7b42
# set-top-box:814bc401-7743-47d3-957b-7f1b2dafe398
# set-top-box-haac:dc388448-b1d1-11e9-b77b-67224ed60908

Queries

Total number of users registered in Aura

⚠️ This information is only for authenticated users. Currently, anonymous users are not stored in the Aura users’ database.

$ mongo -u {{mongo_user}} -p {{mongo_pass}} {{mongo_uri}}
> use {{mongo_users_db}}
> db.{{mongo_users_col}}.find({}).count()
10167

Total number of users registered in aura per channel

⚠️ This information is only for authenticated users. Currently, anonymous users are not stored in the Aura users’ database.

Use the output of {{ channels }} to identify the channel by its name rather than by its identifier.

$ mongo -u {{mongo_user}} -p {{mongo_pass}} {{mongo_uri}}
> use {{mongo_users_db}}
> db.{{mongo_users_col}}.aggregate([
    {"$group" : {_id: "$channelId", count: {$sum:1}}}
])
{ "_id" : "981e5db7-8031-4370-a326-b6f4d163cd82", "count" : 1 }
{ "_id" : "814bc401-7743-47d3-957b-7f1b2dafe398", "count" : 21 }
{ "_id" : "189d4016-bcd0-491d-a75e-64e7a54aa75c", "count" : 1 }
{ "_id" : "b2501583-6d76-4e77-b364-aa169490efec", "count" : 1 }
{ "_id" : "b94aec9a-da4d-46de-afc3-06cfe0157888", "count" : 1 }
{ "_id" : "60f0ffda-e58a-4a96-aad9-d42be70b7b42", "count" : 22 }
{ "_id" : "e75e7b9d-7949-451a-9493-3d759745492c", "count" : 2518 }
{ "_id" : "9924335b-321a-4f48-b820-e35c7eb9e58b", "count" : 1 }
{ "_id" : "dc388448-b1d1-11e9-b77b-67224ed60908", "count" : 69 }
{ "_id" : "f7fd1021-41cd-588a-a461-387cc24be223", "count" : 2062 }
{ "_id" : "e59aa30f-bae5-4c9e-9d1a-0be8b904711d", "count" : 1 }
{ "_id" : "45494a5b-835a-4fff-a813-b3d2be529dbe", "count" : 346 }
{ "_id" : "5ad28380-85fa-4ba2-bcdb-0732127f4a85", "count" : 4792 }
{ "_id" : "ecd189c2-b1dd-4142-bbe1-eb9549b327e2", "count" : 1 }
{ "_id" : "25695326-c67c-40fe-b5df-a8fd5b4deb22", "count" : 14 }
{ "_id" : "4c14973e-3369-4c6a-b59d-e3e0ecaed78c", "count" : 291 }

Total number of users with expired authorization_id

An authorization_id is expired if it has not been used for 180 days in a row.

$ mongo -u {{mongo_user}} -p {{mongo_pass}} {{mongo_uri}}
> use {{mongo_users_db}}
> db.{{mongo_users_col}}.find({lastAccess: {
        $lt: new Date(ISODate().getTime() - 180*24*60*60*1000)
    }
}).count()
3034

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Configuration API channel module

Description of the channel module in aura-configuration-api

Channel module

The channel module defines services associated with channel management in aura-configuration-api server.

All these services are defined in the channel namespace (/channel).

Servers definition

By default, the servers defined in the swagger include the base path (for v2): /aura-services/v2/configuration.

Therefore, in order to access the services, the base path and service path must be used.

Examples:

aura-services/v2/configuration/channels/
aura-services/v2/configuration/channels/{channelId}/libraries

Endpoints

Path	Method	Description
/channels/	GET	Get all channels information
/channels/	POST	Add a new channel
/channels/{channelId}	GET	Get channel information using channel id
/channels/{channelId}	PUT	Replace channel information associated to channel id
/channels/{channelId}	PATCH	Update some fields of channel information using channel id
/channels/{channelId}	DELETE	Delete channel information using channel id
/channels/{channelId}/libraries	POST	Add a new library configuration to channel id
/channels/{channelId}/libraries	DELETE	Remove all libraries configuration from channel id
/channels/{channelId}/libraries/{libraryId}	GET	Get library configuration from library id and channel id
/channels/{channelId}/libraries/{libraryId}	PUT	Replace library configuration associated to library and channel id
/channels/{channelId}/libraries/{libraryId}	DELETE	Delete library information using library and channel id

You can read the complete documentation of each service in the aura-configuration-api swagger file.

Retrieving information from channels

Retrieving only some fields in channel information

It is possible to get only a specific list of fields for channel information, reducing the amount of data transmitted when necessary, using the includeFields query parameter.

curl --location --request GET 'http://aura-configuration-api:8999/aura-services/v2/configuration/channels?includeFields=name,prefix' \
--header 'correlator: urn:uuid:c8a604ee-29f8-7cda-2979-d2ae6189c360' \
--header 'Accept: application/json' \
--header 'Authorization: XXX'

Response example:

[
    {
        "id": "45494a5b-835a-4fff-a813-b3d2be529dbe",
        "name": "novum-mytelco",
        "prefix": "nov"
    }
]

Excluding fields in channel information

It is also possible to exclude channel information fields using the excludeFields query parameter.

curl --location --request GET 'http://aura-configuration-api:8999/aura-services/v2/configuration/channels?excludeFields=dialogLibraries,nlp,requestOptions,responseOptions' \
--header 'correlator: urn:uuid:c8a604ee-29f8-7cda-2979-d2ae6189c360' \
--header 'Accept: application/json' \
--header 'Authorization: APIKEY XXX'

Response example:

[
    {
        "id": "45494a5b-835a-4fff-a813-b3d2be529dbe",
        "name": "novum-mytelco",
        "prefix": "nov",
        "security": {
            "authPurposes": "customer-self-service identify-customer aura-technical-problems-purpose",
            "authScopes": "",
            "channelId": "novum-mytelco"
        },
        "metadata": {
            "updatedAt": "2022-09-06T09:58:19.543Z",
            "version": "7.4.0",
            "createdAt": "2022-09-06T09:58:19.543Z"
        }
    }
]

Database

The complete definition of the data model can be found in the channels collection section in the Administration module.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

How to write code in Aura Bot global repositories

Guidelines for developers willing to contribute to Aura Bot global repositories writing code

Introduction

The aim of this document is to establish common minimum rules to contribute in Aura Global repositories: code linting, used libraries and guidelines for working over main and master branches

Programming Languages

aura-bot code is written in typescript 4.3.4 that is a programming language developed by Microsoft on top of Nodejs. Currently we use node engine version 14 and npm version 6.

This means that we follow typescript rules of naming, but we have also added some extra ones, to unify our developments:

local variables: always in camelCase.
files: always in lower case letters, dash-separated.
classes: in PascalCase.
interfaces: in PascalCase, they do not start with I.
enums: named in PascalCase, each item also in PascalCase.
library or server names: always in lower case letters, dash-separated.
environment variables: in capital letters, underscore-separated.
functions: always in camelCase.
asynchronous programming: use await/async pattern when possible, avoid chains of promises.
adding a feature to an existing server: check the already existing instances of Singleton components and use them directly. Do not create a new instance, this will lead to an error during the start-up or in runtime.
All servers count on a ConfigurationManager where all its environment variables can be obtained.

Try to use the best programming pattern for each feature, applying always Single Responsibility Point defining small modules, functions or classes that do only one specific task. Find more references for programming patterns:

Libraries used

To write logs, always aura-logging. This logger needs a module name during its initialization: it must be in lower case letters, dash-separated.
- Review aura-utilities repository to find out more libraries.
Web servers: expressjs.
Dependency injection: architect.
Environment variables configuration validation: joi.
Database: mongodb, currently version 4.2 but moving in next releases to version 6.
UnitTest: we use mocha for already existing modules, but we are moving to jest, so all brand-new modules must use jest.
Mocks-Server: we have developed a mocks server (aura-mocks-server), that mimics the behavior of all external components (such as kernel, nlp, etc.). If something is missing, add it.
API definition:
- We use API FIRST design. i.e. firstly we define the swagger of the API and then we build the routing of the API using the swagger directly from expressjs and express-openapi.
- We use OpenApi v3 for swagger definition
- We generate the client of the API and the related models automatically after a change in the swagger file.
  - Client package is published on the fly to the correspondant npm registry (github during the development phase and npm for master and release), so its code never exists in the server repository.
  - Models package is updated in the server repository, but just using the definitions in the swagger, no extra code should be written.
- Swagger file must be called swagger.yml and must be created in the root of the server, at the same level of its package.json.
- Each server that needs a client must have a client folder with just the package.json of the client, the rest of the code is autogenerated by aura’s CI system.
HTTP requests: we use superagent library to handle HTTP request, both in our generated API clients and in those done directly from the servers. Currently we use version 5.2.2, but we are moving to version 8 in following releases.
- request and request-promise are strongly prohibited.

Work on a main branch

When you work on a main branch, the libraries are published on Github.

To install the dependencies of a package, you need the following steps:

Create a Github development token with package read permission.
Configure SSO for this token.
Configure your .npmrc file in your root directory:

//npm.pkg.github.com/:_authToken=XXX

@telefonica:registry=https://npm.pkg.github.com

Work on a master branch

When you work on a master branch, the libraries are published in npm.

To install the dependencies of a package, you need the following steps:

Request a npm token from your team.
Configure your .npmrc file in your root directory:

//registry.npmjs.org/:_authToken=XXXX

@telefonica:registry=https://npm.pkg.github.com

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Elasticsearch dashboard

Information provided by Elasticsearch dashboard

Introduction

Elastic dashboard monitors multiple data, service and system related metrics.

The different graphs are shown in the following sections:

Cluster graphs
Shard graphs
system graphs
Documents graphs
Total operations stats graphs
Elastic search times graphs
Caches graphs
Thread pool graphs
JVM garbage collection graphs

Cluster graphs

The current section includes cluster related graphs.

Health status

Code coloured indicator of cluster health.

Metrics:

((sum(elasticsearch_cluster_health_status{color="green"})*2)+sum(elasticsearch_cluster_health_status{color="yellow"}))/count(elasticsearch_index_stats_up)

Nodes

Number of nodes.

Metrics:

count(elasticsearch_index_stats_up)

Data nodes

Number of data nodes per node.

Metrics:

sum(elasticsearch_cluster_health_number_of_data_nodes{cluster="elasticsearch"})/count(elasticsearch_index_stats_up)

Pending tasks

Pending tasks per node.

Metrics:

sum(elasticsearch_cluster_health_number_of_pending_tasks{cluster="elasticsearch"})/count(elasticsearch_index_stats_up)

Graph visual

Shards graphs

Shards related graphs.

Active primary shards

Number of active primary shards per node.

Metrics:

sum(elasticsearch_cluster_health_active_primary_shards{cluster="elasticsearch"})/count(elasticsearch_index_stats_up)

Active shards

Number of active shards per node.

Metrics:

sum(elasticsearch_cluster_health_active_shards{cluster="elasticsearch"})/count(elasticsearch_index_stats_up)

Initializing shards

Number of shards initializing per node.

Metrics:

sum(elasticsearch_cluster_health_initializing_shards{cluster="elasticsearch"})/count(elasticsearch_index_stats_up)

Relocating shards

Number of relocating shards per node.

Metrics:

sum(elasticsearch_cluster_health_relocating_shards{cluster="elasticsearch"})/count(elasticsearch_index_stats_up)

Unassigned shards

Number of unassigned shards per node.

Metrics:

sum(elasticsearch_cluster_health_delayed_unassigned_shards{cluster="elasticsearch"})/count(elasticsearch_index_stats_up)

Graph visual

System graphs

System related graphs.

CPU usage

Percentage of used CPU on master and data nodes.

Metrics: It includes two metrics:

Master node CPU usage

elasticsearch_process_cpu_percent{cluster="elasticsearch",es_master_node="true",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Data nodes CPU usage:

elasticsearch_process_cpu_percent{cluster="elasticsearch",es_data_node="true",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

JVM memory usage

Memory used by JVM graph in bytes.

Metrics:

It includes three metrics:

Used memory

elasticsearch_jvm_memory_used_bytes{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Committed memory

elasticsearch_jvm_memory_committed_bytes{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Max memory

elasticsearch_jvm_memory_max_bytes{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Disk usage

Disk usage in bytes.

Metrics:

1-(elasticsearch_filesystem_data_available_bytes{cluster="elasticsearch"}/elasticsearch_filesystem_data_size_bytes{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"})

Network usage

Bytes rate sent and received, aggregated by one minute.

Metrics: It includes two metrics:

Sent bytes

irate(elasticsearch_transport_tx_size_bytes_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Received bytes

irate(elasticsearch_transport_rx_size_bytes_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Graph visual

Documents graphs

Documents state related graphs.

Documents count

Number of documents in cluster.

Metrics:

elasticsearch_indices_docs{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Documents indexed rate

Rate of indexed documents, aggregated by one minute.

Metrics:

irate(elasticsearch_indices_indexing_index_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Documents deleted rate

Rate of deleted documents, aggregated by one minute.

Metrics:

rate(elasticsearch_indices_docs_deleted{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Documents merged rate

Rate of merged documents, aggregated by one minute.

Metrics:

rate(elasticsearch_indices_merges_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Graph visual

Total operations stats graphs

Data related to total operations.

Total operations rate

Total operations number rate, aggregated by one minute.

Metrics: It includes six metrics:

Indexing index

irate(elasticsearch_indices_indexing_index_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Search queries

irate(elasticsearch_indices_search_query_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Search fetch

irate(elasticsearch_indices_search_fetch_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Merges

irate(elasticsearch_indices_merges_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Refresh

irate(elasticsearch_indices_refresh_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Flush

irate(elasticsearch_indices_flush_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Total operations time

Time rate for the different operations in milliseconds, aggregated by one minute.

Metrics: It includes six metrics:

Indexing index

irate(elasticsearch_indices_indexing_index_time_seconds_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Search queries

irate(elasticsearch_indices_search_query_time_ms_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Search fetch

irate(elasticsearch_indices_search_fetch_time_ms_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Merges

irate(elasticsearch_indices_merges_total_time_ms_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Refresh

irate(elasticsearch_indices_refresh_total_time_ms_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Flush

irate(elasticsearch_indices_flush_time_ms_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Graph visual

Elasticsearch times graphs

Graphs related to elapsed times of different actions.

Query time

Time rate for search query operations in seconds, aggregated by one minute.

Metrics:

rate(elasticsearch_indices_search_query_time_seconds{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Indexing time

Time rate for indexing index operations in seconds, aggregated by one minute.

Metrics:

rate(elasticsearch_indices_indexing_index_time_seconds_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Merging time

Time rate for merge operations in seconds, aggregated by one minute.

Metrics:

rate(elasticsearch_indices_merges_total_time_seconds_total{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Caches graphs

Graphs related to caches metrics.

Field data memory size

Field data memory size in bytes.

Metrics:

elasticsearch_indices_fielddata_memory_size_bytes{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Field data evictions

Rate of field data evicted, aggregated by one minute.

Metrics:

rate(elasticsearch_indices_fielddata_evictions{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Query cache size

Bytes of memory occupied by cached queries.

Metrics:

elasticsearch_indices_query_cache_memory_size_bytes{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Query cache evictions

Rate of queries evicted, aggregated by one minute.

Metrics:

rate(elasticsearch_indices_query_cache_evictions{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Graph visual

Thread pool graphs

Graphs related to the thread pool.

Operations rejected

Rate of rejected operations, aggregated by one minute.

Metrics:

irate(elasticsearch_thread_pool_rejected_count{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Operations queued

Rate of queued operations, aggregated by one minute.

Metrics:

elasticsearch_thread_pool_active_count{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Threads active

Number of active threads.

Metrics:

elasticsearch_thread_pool_active_count{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}

Operations completed

Shows rate of completed operations, aggregated by one minute

Metrics:

irate(elasticsearch_thread_pool_completed_count{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Graph visual

JVM Garbage collection graphs

Graphs related to JVM garbage collector activity.

GC count

Rate of GC count, aggregated by one minute.

Metrics:

rate(elasticsearch_jvm_gc_collection_seconds_count{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

GC time

Rate of GC execution time, aggregated by one minute.

Metrics:

rate(elasticsearch_jvm_gc_collection_seconds_count{cluster="elasticsearch",name=~"(elasticsearch-es-aura-0|elasticsearch-es-aura-1|elasticsearch-es-aura-2)"}[1m])

Graph visual

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Hot swapping in Aura

Description of Aura processes that can be executed without service outage

Introduction

The objective of the current documents is to describe the available actions that can be carried out over Aura through hot swapping processes, that is, without interrupting its operation. These actions include the update, insertion or removal of specific components or resources. The modifications resulting from these processes can be available immediately without the need to wait for the deployment of a subsequent Aura Platform release.

Despite the previous definition, performing a specific hot swapping process within a component can impact other components. In such cases, it becomes necessary to either restart the affected component or carry out a particular action to mitigate any potential issues or conflicts.

Available hot swapping processes and associated impact

The following table illustrates the available hot swapping processes against key Aura components, the impact of the process over each of them and the consequent actions that must be executed afterwards.

Each hot swapping process in the table is fully described in the document Hot swapping processes.

|——-|————-|———————-|————|———-|———-|————-|————|————————-|——————|———————|——————|———|————————| | 1. Update locales | Restart | Restart | Restart | aura-configuration-updater

Make-up | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | 2. Update NLP packages | N/A | N/A | N/A | N/A | Restart | NO¹ | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | 3. Modify TV use cases (User helper) | N/A | N/A | N/A | N/A | N/A | Restart | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | 4. Channels handling | Restart | Restart | Reload | Make-up | Restart | Restart | Restart | NO² | Reload| Restart | Restart | N/A | | 5. Skills handling | N/A | N/A | Reload | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | 6. Applications handling | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | Reload | N/A | N/A | N/A | N/A | | 7. Add new local dialogs in aura-bot | N/A | N/A | N/A | DeployLocal | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | 8. Update libraries and dialogs configuration | N/A | N/A | N/A | aura-configuration-updater | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | 9. Add static resources in a uc | N/A | N/A | N/A | aura-configuration-updater | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | 10. Review indexes definitions | N/A | N/A | Make-up | Make-up | N/A | N/A | Make-up | Make-up | N/A | N/A | Make-up | Force | Make-up |

Legend

N/A: The change does not apply to the component
NO: The change does not apply to the component, unless a condition is met
Restart: the component will be restarted automatically by the config-watcher. The restart is executed pod by pod, with no impact to final users
Reload: the component is not restarted, but its configuration will be reloaded automatically by the config-watcher.
aura-configuration-updater: The hot swapping process must be executed using aura-configuration-updater.
Make-up: the make-up of the component is executed during the deploy phase: both with deploy-core and deploy-local. Take into account that aura-configuration-updater is included into the deploy_local process
DeployLocal: the component is automatically restarted after the execution of its make-up
Force: a restart of the component must be executed manually

Notes

Assuming it doesn’t involve resolution changes ↩︎
Until associated training is added, if applicable ↩︎

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Jenkins pipelines definition

Understand how the Continuous Integration system works in Aura system in detail

Introduction

During the refactor phase, the way to declare the configuration of the different repositories has been redefined by trying to simplify the delivery/pipelines/Jenkinsfile file statement.

The main objective of the refactor is “to simplify”. This is attempted to achieve as follows:

All repositories must execute the same stages (predefined).
Repositories with a specific language should execute the same tasks in stages.
Scripts to execute tasks should be common and defined in jenkins-libraries-aura repository to be reused.

General structure project

The files associated with the continuous integration system are found in the delivery folder, which has the following structure:

delivery/
├── docker                          # Folder to Dockerfile
├── pipelines/Jenkinsfile.aura      # Jenkinsfile
└── scripts                         # Utility script for pipelines

Scripts added to the delivery/scripts folder should be specific tasks for this repository. Otherwise, the scripts should be in the resources/org/aura/script folder and that can be reused.

Add script to delivery/scripts only if it is completely necessary.

Jenkinsfile example

@Library(['aura']) _

auraPipeline {
    language = 'node'
}

The previous definition is sufficient for a nodeJS type repository to execute the default continuous integration tasks defined for an Aura nodejs project.

Definition of pipelines

Common libraries

Although it is possible to directly define the tasks to be executed with groovy here, there are a number of predefined scripts to run common tasks that can be used by including the aura and devops libraries:

@Library(['aura','devops']) _

Pipeline configuration

auraPipeline {
    slave,          // Slave where pipeline will be executed. Default: 'aura-bot-platform-14'
    nature,         // Pipeline nature: Default: 'standard' (the refactor nature)
    language,       // Language used by the pipeline
    artifacts,      // List of artifacts that need to be generated.
    stages,         // List of stages. Default: default stages
    modifiedStages, // List of modified stages.
    options,        // Pipeline options.
    postJobs        // Post execution jobs.
}

slave property

Slave property indicates the slave where Jenkins stages will be executed.

If a slave is not specified explicitly, aura-bot-platform-14 will be finally used.

nature property

The nature property indicates the definition of pipeline that will be executed on the list defined in ‘jenkins-libraries-aura’ project.

The simplification in the definition of pipelines has reduced the list to a single generic pipeline defined as standard.

It is still possible to execute existing pipelines, previous to refactor. Simply, the value of nature should indicate the pipeline to be executed.

This is deprecated in favor of the new standard pipeline.

language property

The language property helps the standard pipeline to execute the appropriate tasks depending on the language of the repository itself.

The system is prepared to handle repositories whose source code is written in a single main language.

artifacts property

List of artifacts that will be generated.

stages property

Although the standard pipeline defines a series of default stages depending on the type of ‘push’ that is done on the repository, this field allows you to define the stages manually.

modifiedStages property

In some cases, it is necessary to modify the configuration of some default stage in standard pipeline, without defining all the stages again (as we would do on the stages property).

For example, we can modify the test stage for the ‘pr’ type:

modifiedStages = [
    'pr': [
        new Stage(name: 'test', description: 'Test', options: [ skipLint: true] )
    ]
]

or modify the test stages for all types (pr, release, etc):

modifiedStages = [
    '*': [
        new Stage(name: 'test', description: 'Test', options: [ skipLint: true] )
    ]
]

options property

The following options are available:

Option	Description	type	Default
deleteBuildOnSkip	Delete build on skip	boolean	true
uploadGeneratedArtifacts	Upload generated artifacts from ‘artifacts’ directory	boolean	false

postJobs property

Jenkins jobs that will be executed once the current job ends.

Defining artifacts

The artifacts are components that we can generate during the execution of the pipeline. All artifacts must extend from the Artifact class and depending on its type will generate one component or another.

Currently, there are only two types of components (although it can grow in the future): AuraComponent and AuraLibrary.

AuraComponent

A type component AuraComponent is used to generate a Docker image with the following configuration options:

Option	Description	type	Default
name	Component name	String
version	Version for the docker image	String
envVersionVar	Environment version variable (as `AURA_BOT_VERSION`)	String
scripts	List of names of configuration scripts	List
initScripts	List of names of initialization scripts	List
buildArguments	Docker build arguments	List
dockerImageName	Docker image name	String
dockerFile	Docker file name	String	‘Dockerfile’
dockerPromotionTag	Docker promotion tag	String	’latest’

Example:

    artifacts = [
        new AuraComponent(
            name: "aura-bot", 
            version: "\$BOT_UC_VERSION", 
            dockerImageName: "aura/aura-bot-uc", 
            dockerFile: "Dockerfile", 
            scripts: ["librariesListFile.sh", "cfBotPlatformVersion.sh"], 
            buildArguments: ["BOT_BASE_VERSION=\$BOT_BASE_VERSION", "UC_VERSION=\$UC_VERSION", "UC_REVISION=\$PRODUCT_REVISION"]),
    ]

AuraLibrary

A type component AuraLibrary is used in repositories containing several libraries (multi-repository). In this way, it is possible to execute the pipeline for each of the libraries defined in the list of components.

If a multi-repository follows the structure of adding each library within the “packages” directory, the stages in standard pipeline are able to automatically get the library list, so in most cases it is not necessary to define configuration by hand.

In case you need to define the library list, the following options are available:

Option	Description	type	Default
name	Component name	String
path	Component path (Ex. packages/my-library)	String
versionStrategy	Version strategy: distag, old	String	distag

Example:

    artifacts = [
        new AuraLibrary( name: "aura-json-schema-generator", path: "packages/aura-json-schema-generator")
    ]

How to define my own stages?

The standard pipeline defines the following stages by default:

// Default stages
'default': [
    'pr'     : [
        new Stage(name: 'decrypt', description: 'Decrypt'),
        new Stage(name: 'initialization', description: 'Initialization'),
        new Stage(name: 'build', description: 'Build'),
        new Stage(name: 'test', description: 'Test')
    ],
    'release': [
        new Stage(name: 'checkSkip', description: 'Checkout skip'),
        new Stage(name: 'decrypt', description: 'Decrypt'),
        new Stage(name: 'initialization', description: 'Initialization'),
        new Stage(name: 'build', description: 'Build'),
        new Stage(name: 'test', description: 'Test'),
        new Stage(name: 'versioning', description: 'Versioning'),
        new Stage(name: 'publish', description: 'Publish'),
        new Stage(name: 'promote', description: 'Promote'),
        new Stage(name: 'deploy', description: 'Deploy')
    ]
]

Although the standard pipeline supplies the previous list of stages by default, it is possible to define stages manually, indicating in the repository that stages will be executed for each type.

There are two different ways to do this:

Modify or add stages on the standard pipeline. For this you must use the modifiedStages property. If a stage is defined with the name of an existing one, it is becoming overwritten. In case the added stage has a name different from the existing default stage, the new stage will be added in the execution.
Refine completely the list of stages to be executed. As indicated above in the options, the stages property allows you to define the list of stages that will be executed.

Example to execute only the test stage in the ‘pr’ type:

stages = [
    'pr': [
        new Stage(name: 'test', description: 'Test')
    ]
]

What tasks are executed for each stages?

Each Stage executes a series of task based on the value of the language property.

Node

Stage	Description
checkSkip*	Perform a check to know if it can do skip of the build.
decrypt*	Decrypt files that need it.
initialization	Gets versions for AuraComponent type artifacts.
build	Run `node/build.sh` script for all `Library` type components (the scripts can get libraries automatically).
test	Run `node/test.sh` script for all `Library` type components (the scripts can get libraries automatically). After execution, reports are generated for: Test, Coverage and LiNT.
versioning	Run `node/versioning.sh` script for all `Library` type components (the scripts can get libraries automatically).
publish	If the `onlyPack` option is added, the `npmPack.sh` script will be executed. Otherwise, the `publish.sh` script will be executed.
promote*	For each `AuraComponent` type artifact performs a docker `tag` and `push` command
deploy*	For each `AuraComponent` type artifact performs a deployment for the component

The value * at the end of stage’s name indicates that it is a default stage and it has not been modified for the node language.

Scripts used in the execution process for the node language:

node
├── build.sh        # Execute "npm install".
├── npmPack.sh      # Execute "npm install", "npm pack" and move the generated packages to the _artifacts_ folder.
├── publish.sh      # Check if it is not published and runs "npm install" and "npm publish".
├── test.sh         # Execute "npm run coverage-jenkins" and "npm run lint-jenkins".
└── versioning.sh   # Detects changes in the library to increase version (only if publishConfig exists in package.json)

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes cluster

Description of the Kubernetes cluster: components, connection, automation, storage and more

Introduction

The Kubernetes cluster is created on the cloud using aks-engine (Azure), the tool provided by Microsoft to generate the Azure Resource Manager templates that deploy Kubernetes cluster. This tool simplifies the cluster installation, management and upgrades.

Kubernetes are internally used by the Aura Platform installer but they are not intended to be directly used by the Operations and Support Teams. The reason is that changes made to a Kubernetes cluster that are not reflected in the Aura Platform deployment profile could be lost in a platform upgrade. For example, if you changed the instance type in a specific agent pool with Kops, you would lose the changes in a new deployment.

Cluster metadata

The cluster metadata is saved in the object storage (Azure Blob Storage).

⚠️ Remember that if you lose this bucket, you need to rebuild the cluster manually (Azure). It also contains critical information to access the cluster (certificates, private keys), so it must not be shared.

Connecting to Kubernetes

The kubectl command-line tool is the basic tool to operate the Kubernetes cluster. It uses kubeconfig files that contain all the required information (endpoints, certificates, etc) to connect with the Kubernetes API and manage the cluster in a secure way.

A default (root) kubeconfig file with full access to the cluster is created the first time you install the Aura Platform and is stored in a bucket as part of the cluster metadata.

⚠️Do NOT use the default kubeconfig file to manage the cluster. Use it to create new users with limited permissions instead.

By default, kubectl looks for a file named config in the $HOME/.kube directory. However, you can specify other kubeconfig files by setting the KUBECONFIG environment variable or passing the flag --kubeconfig to kubectl.

export KUBECONFIG=/path/to/kubeconfig.json  # Azure

⚠️ For security reasons, kubeconfig files are personal and must not be shared. Each action a user executes on the cluster is logged. If your kubeconfig file is compromised, you must report it.

📄 You can get more information about kubeconfig files at the official Kubernetes documentation.

⚠️ Kubernetes-dashboard is not deployed in Aura cluster as we promote the kubectl use, but if you still want to use it, you can run the dashboard in your machine and connect to the cluster with your kubeconfig as follows:

docker run -p 9090:9090 -v ${PATH_TO_YOUR_KUBECONFIG}/kubeconfig.json:/opt/kubeconfig.json -v /tmp:/tmp kubernetesui/dashboard:v2.2.0 --kubeconfig /opt/kubeconfig.json

Kubernetes automation with the Cloud

Kubernetes automates certain tasks such as creating a Load Balancer for a service or mounting a disk on a node as a persistent volume for a pod.

Authentication against the cloud provider APIs is done using credentials configured automatically:

Azure: by using a Service Principal with contributor role and scope for the infrastructure Resource Group.

⚠️ Please do not change the password, delete the Service Principal or remove its Contributor role If doing so, credentials will not be automatically updated due to a known limitation of aks-engine.
See the issue Azure/aks-engine/724 in the aks-engine repository for more information.

The “Security” section describes an unofficial procedure to change the Service Principal credentials in Azure that involves a period of service disruption.

Kubernetes Namespaces

Kubernates Namespaces are a way to divide and organize cluster resources.

You can list the existing namespaces running kubectl get namespaces. In Aura Platform, you will find the following ones:

Namespaces used by the Aura Platform services:
- aura-$ENV: Aura Platform core services.
- aura-system: Aura Platform system services (prometheus, alertmanager, node-exporter, fluentd, elasticsearch, kube-static-metrics).
Namespaces used by Kubernetes:
- kube-system: for objects created by the Kubernetes system. Aura Platform also deploys some objects into this namespace that are very tied to the infrastructure.
- kube-public: readable by all users. It should be empty.
Default namespace (default): for objects with no other namespace.

In most situations, you will need to use aura-$ENV. You can use the --namespace flag in kubectl to specify which namespace you are referring to. For example, to get the pods in the Aura Platform core:

$ kubectl get pods --namespace aura-$ENV

Remember that some low-level resources, such as nodes and persistent volumes, are not in a namespace.

Kubernetes objects

Working with pods

You can list all pods in a given namespace along with additional metadata (the node where the pod is allocated, its age, etc.):

$ kubectl get pods -n aura-$ENV -o wide
NAME                                 READY   STATUS      RESTARTS   AGE
aog-bridge-744bbb9595-94g7n          1/1     Running     0          4h15m
aog-bridge-744bbb9595-pzg2l          1/1     Running     0          4h15m
api-gw-5c584b4c8d-hdk25              1/1     Running     0          4h15m
api-gw-5c584b4c8d-knm27              1/1     Running     0          4h15m
aura-bot-84bd44dc6d-5jdzk            1/1     Running     0          4h16m
aura-bot-84bd44dc6d-ktz74            1/1     Running     0          4h16m
aura-bot-makeup-4qrbl                0/1     Completed   0          4h16m
authentication-api-b849b6ff9-5t96c   1/1     Running     0          4h16m
authentication-api-b849b6ff9-rwcvm   1/1     Running     0          4h16m
nginx-5fd94584d8-tcpwd               2/2     Running     0          4h15m
nginx-5fd94584d8-z72tf               2/2     Running     0          4h15m
nlp-85b4b446cc-df2zw                 1/1     Running     0          4h16m
nlp-85b4b446cc-s6z5k                 1/1     Running     0          4h16m
nlp-provisioning-zxkk5               0/1     Completed   0          4h16m
user-helper-67b75cb8fc-6vkt9         1/1     Running     0          4h15m
user-helper-67b75cb8fc-td42l         1/1     Running     0          4h15m
web-sdk-5f7654b797-9npzn             1/1     Running     0          4h16m
web-sdk-5f7654b797-mlcrj             1/1     Running     0          4h16m

Pods can have different statuses:

Running
Completed: some pods (e.g., jobs) have a reduced lifespan. They change to completed status when they finish. Kubernetes eventually removes them from the list of pods.
Others

📄 You can get more information about working with pods in the Kubernetes documentation.

Each pod is configured using environment variables. They are a OS-agnostic standard that allows to change the configuration between deployments without changing any code in a very easy way. Sensitive information (e.g., passwords) is configured using Kubernetes secrets.

Working with deployments

A deployment controller provides declarative updates for Pods and ReplicaSets, according to the desired state described in a deployment object.

$ kubectl get deployments

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
aog-bridge           2/2     2            2           4h16m
api-gw               2/2     2            2           4h16m
aura-bot             2/2     2            2           4h17m
authentication-api   2/2     2            2           4h16m
nginx                2/2     2            2           4h16m
nlp                  2/2     2            2           4h16m
user-helper          2/2     2            2           4h16m
web-sdk              2/2     2            2           4h16m

ℹ️ You can get more information about working with deployments in the Kubernetes documentation.

Working with nodes

Nodes are the virtual machines that run Aura Platform.

There are two types of nodes in any Kubernetes cluster:

Master nodes: they host the control plane aspects of the cluster. Typically, these nodes are not used to schedule application workloads.
Compute nodes: nodes which are responsible for executing workloads for the platform services.

If there is an issue in the cluster, the first thing you should review is the status of the nodes.

$ kubectl get nodes

NAME                                 STATUS   ROLES    AGE     VERSION
k8s-common-26582301-vmss000000       Ready    agent    7h33m   v1.13.4
k8s-common-26582301-vmss000001       Ready    agent    7h33m   v1.13.4
k8s-database-26582301-vmss000000     Ready    agent    7h33m   v1.13.4
k8s-database-26582301-vmss000001     Ready    agent    7h33m   v1.13.4
k8s-database-26582301-vmss000002     Ready    agent    7h33m   v1.13.4
k8s-management-26582301-vmss000000   Ready    agent    7h33m   v1.13.4
k8s-management-26582301-vmss000001   Ready    agent    7h33m   v1.13.4
k8s-management-26582301-vmss000002   Ready    agent    7h33m   v1.13.4
k8s-master-26582301-0                Ready    master   7h33m   v1.13.4
k8s-master-26582301-1                Ready    master   7h33m   v1.13.4
k8s-master-26582301-2                Ready    master   7h32m   v1.13.4

You should see three nodes with the role “master”, that is the default recommended value. An odd number of master nodes is mandatory to guarantee that etcd, the service that stores the cluster status, reaches its consensus (see “Why an odd number of cluster members” in etcd frequently asked questions).

The normal status for a node is “Ready”, that means that the node is up and a healthy member of the Kubernetes cluster.

Nodes can become “NotReady” for different reasons when something is not right. In this case, the first step is to describe the affected node and check the “Conditions” and “Events” to determine what could be wrong:

$ kubectl describe node k8s-common-26582301-vmss000000

...
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Thu, 04 Jul 2019 07:08:50 +0200   Thu, 04 Jul 2019 07:08:50 +0200   RouteCreated                 RouteController created a route
  MemoryPressure       False   Thu, 04 Jul 2019 14:41:10 +0200   Thu, 04 Jul 2019 07:07:06 +0200   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Thu, 04 Jul 2019 14:41:10 +0200   Thu, 04 Jul 2019 07:07:06 +0200   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Thu, 04 Jul 2019 14:41:10 +0200   Thu, 04 Jul 2019 07:07:06 +0200   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Thu, 04 Jul 2019 14:41:10 +0200   Thu, 04 Jul 2019 07:07:20 +0200   KubeletReady                 kubelet is posting ready status. AppArmor enabled
...

With kubectl top nodes, you can get a quick overview of each node CPU and memory usage. If it is not enough and you need more details about the usage of resources, go to Grafana dashboards section in Monitor Aura documentation.

If a node is misbehaving, the recommended steps are:

Drain the Kubernetes node. This way, Kubernetes give the pods running on that node a chance to stop in an orderly way and stops scheduling new pods on it. This step is not mandatory, but recommended.
Terminate the node. It is always safe to terminate one node at a time, waiting until it joins the cluster. Terminating many nodes at a time can affect the quorum of services that need to form a cluster, so it is not recommended if the node you want to terminate contains these kind of pods.

Nodes that are cordoned appear with the status “SchedulingDisabled”:

k8s-common-26582301-vmss000000      Ready,SchedulingDisabled   agent    ...

Filtering nodes with kubectl is very handy. For example, you can filter nodes to get those in a specific agent pool:

$ kubectl get nodes -l 'agentpool in (common)'
NAME                             STATUS   ROLES   AGE     VERSION
k8s-common-26582301-vmss000000   Ready    agent   7h36m   v1.13.4
k8s-common-26582301-vmss000001   Ready    agent   7h36m   v1.13.4

Or to get only those in a specific availability zone:

$ kubectl get nodes -l 'failure-domain.beta.kubernetes.io/zone in (0)'
NAME                                 STATUS   ROLES    AGE     VERSION
k8s-common-26582301-vmss000000       Ready    agent    4h14m   v1.13.4
k8s-database-26582301-vmss000000     Ready    agent    4h14m   v1.13.4
k8s-management-26582301-vmss000000   Ready    agent    4h14m   v1.13.4
k8s-master-26582301-0                Ready    master   4h14m   v1.13.4
k8s-master-26582301-1                Ready    master   4h14m   v1.13.4

You can find information about the nodes usage in Grafana. Also, describing the nodes gives you information about how Kubernetes allocated resources on it:

$ kubectl describe node k8s-common-26582301-vmss000001

Non-terminated Pods:         (13 in total)
  Namespace                  Name                                     CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                     ------------  ----------  ---------------  -------------  ---
  aura-es-test               aog-bridge-744bbb9595-ffbzz              100m (5%)     1 (51%)     256Mi (4%)       512Mi (9%)     35m
  aura-es-test               api-gw-5c584b4c8d-qg7bz                  100m (5%)     1 (51%)     256Mi (4%)       512Mi (9%)     35m
  aura-es-test               aura-bot-84bd44dc6d-7cc46                100m (5%)     1 (51%)     256Mi (4%)       512Mi (9%)     36m
  aura-es-test               authentication-api-b849b6ff9-pjdk6       100m (5%)     1 (51%)     256Mi (4%)       512Mi (9%)     35m
  aura-es-test               nginx-5fd94584d8-fwmcd                   600m (31%)    2 (103%)    768Mi (14%)      1Gi (19%)      34m
  aura-es-test               nlp-85b4b446cc-2dtj8                     100m (5%)     1 (51%)     256Mi (4%)       512Mi (9%)     35m
  aura-es-test               user-helper-67b75cb8fc-szmv8             100m (5%)     1 (51%)     256Mi (4%)       512Mi (9%)     35m
  aura-es-test               web-sdk-5f7654b797-jbrfg                 100m (5%)     1 (51%)     256Mi (4%)       512Mi (9%)     35m
  aura-system                fluentd-st7jb                            50m (2%)      100m (5%)   256Mi (4%)       512Mi (9%)     51m
  aura-system                node-exporter-4mlqs                      10m (0%)      50m (2%)    24Mi (0%)        32Mi (0%)      52m
  kube-system                kube-proxy-fnb2d                         100m (5%)     0 (0%)      0 (0%)           0 (0%)         4h14m
  kube-system                kubernetes-dashboard-7947fffdf5-pdrf2    300m (15%)    300m (15%)  150Mi (2%)       150Mi (2%)     4h14m
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                       Requests      Limits
  --------                       --------      ------
  cpu                            1860m (96%)   10450m (541%)
  memory                         3246Mi (62%)  5814Mi (111%)
  ephemeral-storage              0 (0%)        0 (0%)
  attachable-volumes-azure-disk  0             0

The CPU and memory limits can be over 100%. But the CPU and memory requests cannot. This means that the resources requested by the pods also establish a limit even if they do not use the requested resources.
If all nodes in an agent pool are full, new pods will wait in a “pending” status until the cluster autoscaler adds a new node to the agent pool.

Autoscaling groups

Compute nodes In Azure, we use virtual machine scale set, this means that, when a node is terminated for any reason, another one will be automatically created and each agent pool corresponds to one VMSS in Azure.

Master nodes Master nodes in Azure are individual nodes that do not belong to any VMSS. This means that, if you remove a master node in Azure, you need to run the installer again to recreate it. For this reason, you can restart the node first and wait some minutes to verify if is able to rejoin the Kubernetes cluster. In this case you do not need to terminate it. Remember to uncordon the node if you had cordoned it previously.

Horizontal scaling of a component

Scaling deployments is easy using the kubectl scale command. It enables you to scale one or more replicated services either up or down to the desired number of replicas.

For example, you might want to scale the number of replicas of the apigw deployment to 6:

$ kubectl scale deployment aura-bot --replicas=6 -n aura-$ENV

Deployments contain stateless loads, so they can safely scale up and down. The only restrictions are:

To have only one insights-loader in order to avoid race conditions trying to load insight files from the object storage.
To have only one kube-state-metrics to avoid duplicated metrics in Prometheus.

The platform supports Horizontal Pod Autoscalers.

They have been included in some relevant services to autoscale the number of replicas based the CPU usage of a pod.

$ kubectl get hpa -n aura-$ENV

NAME                 REFERENCE                       TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
aog-bridge           Deployment/aog-bridge           0%/150%   2         4         2          65m
api-gw               Deployment/api-gw               0%/150%   2         4         2          65m
aura-bot             Deployment/aura-bot             0%/150%   2         4         2          66m
authentication-api   Deployment/authentication-api   0%/150%   2         4         2          66m
nginx                Deployment/nginx                0%/150%   2         4         2          65m
nlp                  Deployment/nlp                  0%/150%   2         4         2          65m
user-helper          Deployment/user-helper          0%/150%   2         4         2          65m
web-sdk              Deployment/web-sdk              0%/150%   2         4         2          66m

MINPODS values are set according to your deployment profile using the service_replicas value for each service.
MAXPODS values are stablished as three times the value of MINPODS.
TARGET is defined as a CPU utilization threshold fixed to 80% for all platform services. According to these policies, each service will scale up/down (when needed) based on their own CPU usage metrics. Support for additional custom metrics (e.g., latencies) will be added in future releases.

This feature is very powerful in combination with the cluster autoscaler, because once the pods created by the HPA do not fit in the available compute nodes, the cluster autoscaler will automatically add new nodes to the cluster.

Regarding statefulsets, not all of them scale nicely, so it is really important to understand them well to be able to scale them safely.

$ kubectl get statefulsets --namespace aura-system

NAME                    READY   AGE
alertmanager            2/2     82m
elasticsearch           3/3     83m
fluent-bit-aggregator   3/3     83m
mongodb                 3/3     84m
prometheus              3/3     83m

ℹ️ You have to keep in mind that:

elasticsearch scales well for adding or removing nodes.
fluentd-aggregator scales well for adding or removing nodes.
prometheus stores the same information in all the available replicas, so it is recommended to keep the number of replicas in, at least, 2 for high availability reasons.

Once you are sure about it, use kubectl to scale the statefulset, for example:

$ kubectl scale statefulsets elasticsearch --replicas=7 -n aura-$ENV

Jobs

There are some scheduled jobs that run in Aura Platform. You can check them with kubectl get jobs:

$ kubectl get jobs --namespace aura-es-test

NAME                      COMPLETIONS   DURATION   AGE
aura-bot-makeup           1/1           92s        69m
nlp-provisioning          1/1           10m        68m

Most of them are provisioning jobs that create all the required entities during the installation (applications, APIs, etc).

Horizontal scaling the infrastructure

It is possible to add and remove nodes to the different agent pools in the Kubernetes cluster.

Adding nodes to a running cluster is a safe operation. However, bear in mind that removing nodes can result in statefulsets not working properly. The reason is that some agent pools are dedicated to stateful services that need to form a cluster.

That is the case of the following agent pools:

master: Kubernetes master nodes use a quorum protocol that needs an odd number of nodes. Three nodes is the minimum number to have HA (high availability), so 3 nodes in preproduction and 5 in production environments is a safe choice. The number of master nodes in an existing environment cannot be modified for now.
database: It must be 3, for a PostgreSQL cluster with one master and two followers.

Cluster autoscaler

The Aura Platform Kubernetes cluster deploys the official Kubernetes cluster-autoscaler. It is a deployment with one pod that runs in one of the master nodes.

$ kubectl get po -l app=cluster-autoscaler -n kube-system

NAME                                  READY   STATUS    RESTARTS   AGE
cluster-autoscaler-6fb6b8dcdc-xr59x   1/1     Running   1          4h48m

This feature is intended to automatically adjust the Kubernetes cluster size when one of these conditions are met:

Scale up: there are pending pods that do not fit in the cluster due to insufficient available resources, but could fit if new compute nodes are added.
Scale down: there are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes.

The cluster autoscaler is able to scale the agent pools down to zero if needed. This is the reason why it is not needed to configure the number of nodes in your deployment profile. The cluster autoscaler will take care of everything to cut your cloud costs to the minimum.

ℹ️ You can find more information about the cluster autoscaler in the official GitHub repository.

Vertical scaling the infrastructure

The process is similar to the horizontal scaling. You need to tune the type properties in the infrastructure section of your profile configuration file.

# Infrastructure
infrastructure:
  region: "westeurope"
  compute:
    masters:
      size: 3
      type: "Standard_DS2_v2"
    common_nodes:
      min_size: 2
      max_size: 8
      type: "Standard_DS2_v2"
    database_nodes:
      min_size: 3
      max_size: 6
      type: "Standard_DS2_v2"
    management_nodes:
      min_size: 3
      max_size: 6
      type: "Standard_DS3_v2"

Afterwards, run the installer to apply the changes:

$ ./aura deploy_infra --cfg /PATH/TO/config.yml -c /PATH/TO/credentials.k8s.json -v "VAULT_PASSWD"
$ ./aura deploy_system --cfg /PATH/TO/config.yml -c /PATH/TO/credentials.k8s.json -v "VAULT_PASSWD"
$ ./aura deploy_core --cfg /PATH/TO/config.yml -c /PATH/TO/credentials.k8s.json -v "VAULT_PASSWD"

The operation has to terminate and recreate every node. It has to be done as a rolling update to avoid service disruption, so it can take a lot of time to complete (around 5-10 minutes per node) in a big Kubernetes cluster.

In Azure, it is not possible to change the instance types with the Aura Platform installer yet. This means that changing the instance types in the deployment profile has no effects on redeployments.

⚠️ Do not use the Azure Portal to modify the cluster nodes. It is an error-prone and unsupported way to scale the cluster that could impact the Aura Platform stability. Kubernetes must be aware of the changes done to the cluster and all changes must be kept in sync with the deployment profile.

Kubernetes storage

Kubernetes uses persistent volumes. They are backed by Managed Disks in Azure.

Services logs with kubectl

The best way to access to the logs of one service is using Kibana platform. Find more information in Manage Aura logs.

However, you can access the same way to:


$ kubectl logs -f -l app=aura-bot -n aura-$ENV

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura make-up processes

The current section describes the make-up processes that take place within Aura

Introduction

Make-up is a set of operations to prepare an environment once a module has been deployed, but before it starts. There is a different make-up job per module, that executes the operations needed before the module starts. The operations that a make-up process can perform are the following, although not all modules have to perform all these tasks.

The current document includes general definitions needed to understand this process.
The make-up specific processes for each module are specified in its corresponding document:
Learn how to manage the indexes of a MongoDB database in the make-up index manager

General definitions

Load External Libraries

This process is in charge of loading external modules, called libraries, which contain their own resources, locale, environment variables, code.

Manage MongoDB Indexes

Indexes in MongoDB are managed by a module called Make-up Index Manager documentation.

It relies on a versioned index configuration file to apply the indexes. Only those indexes whose version has not been applied before will be applied. The configuration file can be loaded from a remote repository. By default, all components with MongoDB access have one index configuration file.

There is a tool within each module called makeup-cli to run the make-up process as a stand-alone task.

Prepare Locale Resources

This process is responsible for collecting all the language resources and uploading them to a remote repository, so that they can be changed on the fly if necessary.

If external libraries have been loaded, this process unifies the language resources. See Locale Manager Documentation.

Set Environment Variables

This process is executed when the module loads external libraries that contain its own environment variables, unifying all these environment variables in a single file.

Prepare Remote Channel Config

It is responsible for unifying the different configurations assigned by each external library to the channels.

Process Resources

This process manages the different resources of each external library and promotes them so that they are accessible when the main program is running.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Manage Aura metrics

Learn what are Aura metrics, how they are generated and stored in Prometheus and the process for its analysis through Grafana

Introduction

Metrics provide a measurement of certain data that represent a specific aspect of the monitored system at a point in time and offer an aggregated view over the system. They are useful to visualize long-term trends and alerts on log data.

Each Aura component is in charge of publishing its own metrics, which are typically generated at fixed-time intervals from aggregated logs.

Once generated, Aura metrics are pooled by Prometheus, which is in charge of gathering and exposing them.

Grafana is the most suitable tool to represent metrics through different dashboards. Each component counts on a Grafana dashboard to show its current behavior and there is a single dashboard for an Aura overview.

If you think a new metric could useful, please contact the Aura Platform Team, so it can be officially included as part of the platform.

The aim of this section is to explain both how Aura metrics work and all the metrics stored by each component.

⚠️ Saved dashboards, visualizations and queries are not guaranteed to be kept between upgrades because all the stack, including ElasticSearch and Grafana can be upgraded to newer versions.

Prometheus

Aura metrics system is based on Prometheus, a Cloud Native Computing Foundation project that works as systems and services monitoring system. Prometheus collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts when specified conditions are observed.

prom-client is being used to implement prometheus functionality in Node.js.

Prometheus service pools every component to get the metrics generated during the last time period. Every component counts on a private endpoint (not accessible from Internet) called /metrics where Prometheus requests the metrics.

Currently, the metric types used in this component are:

Summary: similar to histogram metrics, it includes samples observations (such as request durations and response sizes). While it also provides a total count of observations and a sum of all observed values, it calculates configurable quantiles over a sliding time window.
Counter: cumulative metric that represents a single monotonically increasing counter whose value can only increase or be reset to zero on restart. For example, you can use a counter to represent the number of requests served, tasks completed, or errors.
Gauge: similar to Counter, but it represents a single numerical value that can arbitrarily go up and down.

Prometheus-es-exporter

Working with Prometheus, we can create metrics using queries to ElasticSearch indexes (as well as create alarms, dashboard, etc) using prometheus-es-exporter.

This component is not deployed by default, but it can be enabled changing the variable prometheus_es_exporter_enabled to true in you config.yml file. (In Brazil, it is set to true by default). Access here the guidelines to enable prometheus-es-exporter component.

To config your own metrics from queries, write the new section, as in the following example, in your config.yml.

prometheus_es_exporter:
  query_blocks:
    ob:
      - name: "query_ob_br"
        QueryIntervalSecs: "60"
        QueryJson: '{"size":0,"query":{"bool":{"must":[],"filter":[{"bool":{"filter":[{"bool":{"should":[{"match_phrase":{"msg":"[AzureEventHub] emit"}}],"minimum_should_match":1}},{"bool":{"should":[{"match_phrase":{"kubernetes.labels.app":"aura-bot"}}],"minimum_should_match":1}}]}},{"range":{"@timestamp":{"gte":"now-1m","lte":"now"}}}]}}}'
        QueryIndices: "aurak8s-service-*"

Where:

name: Mandatory. Name of the query. It must start with query_*
QueryIntervalSecs: Optional. It indicates how often to run queries in seconds. By default, 60.
QueryJson: Mandatory. The search query to run.
QueryIndices: Optional. Indices to run the query on. Any way of specifying indices supported by your ElasticSearch version can be used. By default, _all. Although this field is optional, it is highly recommended to delimit the search query.

Aura components metrics

The main Aura components can generate their own metrics.

Select your intended component in the left menu and access to its details.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Modifications in Aura components associated to the update of Nodejs in release Prince 10.0.0 that must be carried out by the OBs when deploying this version

Introduction

The following dependencies of Aura Nodejs components have been updated in Prince 10.0.0 release.

This affects aura-bot and, consequently, implies that different tasks must be done by the OBs in order to make their dialogs compatible with these modifications.

Changes in the rest of components do not affect neither the constructors nor the deployment itself.

Update nodejs

In Prince release, Nodejs has been updated to Nodejs 22 version.

This upgrade does not need any additional task to be executed by the OB use cases developers.

Update Typescript

In Prince release, Typescript has been updated to Typescript 5.8.2.

Prior to deploying Prince, OBs should update these versions in the package.json:

“typescript”: “~5.8.2”

This upgrade could generate certain errors listed below. In these scenarios, OBs constructors can resolve these problems with the indicated solution:

Problems with "suppressImplicitAnyIndexErrors": true in tsconfig.json
- Solution: Remove this property
Problems with some dialogs with super.initialDialogId
- Solution: Replace it by this.initialDialogId
Problems with some dialogs with super.addDialog method
- Solution: Replace it with this.addDialog
Problems with certain types
- Solution: Define them correctly

Update Bot Framework

In Prince release, Bot Framework has been updated to Bot Framework 4.23.2 version.

Prior to deploying Prince, OBs should update these dependencies, if they are needed by the local dialogs:

“botbuilder”: “~4.23.2”,
“botbuilder-core”: “~4.23.2”,
“botbuilder-dialogs”: “~4.23.2”,
“botframework-connector”: “~4.23.2”,
“@azure/core-auth”: “~1.9.0”,
“@azure/data-tables”: “~13.3.0”,
“@azure/storage-blob”: “~12.26.0”

Update Superagent

In Prince release, Aura uses the latest Superagent version 10.2.0.

Prior to deploying Prince, OBs constructors should update these versions in the package.json:

“superagent”: “^10.2.0”
“@types/superagent”: “^8.1.9”

Package.json example

{
    "name": "@telefonica/aura-bot-generic-library",
    "version": "10.0.0",
    "repository": {
        "type": "git",
        "url": "git@github.com:Telefonica/aura-bot-libraries.git",
        "directory": "packages/generic"
    },
    "license": "UNLICENSED",
    "main": "lib/index.js",
    "scripts": {},
    "dependencies": {
        "@telefonica/aura-bot-utilities": "2.0.0",
        "@telefonica/aura-clients": "2.0.0",
        "@telefonica/aura-logging": "6.0.0",
        "@telefonica/aura-utilities": "2.0.0",
        "botbuilder": "~4.23.2",
        "botbuilder-dialogs": "~4.23.2",
        "superagent": "^10.2.0",
        "joi": "^17.6.0"
    },
    "devDependencies": {
        "@telefonica/aura-locale-importer": "9.30.0",
        "@telefonica/eslint-config-aura": "2.14.0",
        "@types/chai": "^4.2.3",
        "@types/jsonwebtoken": "^9.0.1",
        "@types/mocha": "^10.0.1",
        "@types/node": "^18.16.0",
        "@types/sinon": "^10.0.14",
        "@types/superagent": "^8.1.9",
        "@typescript-eslint/eslint-plugin": "^5.57.0",
        "@typescript-eslint/parser": "^5.57.0",
        "chai": "^4.3.10",
        "cross-env": "^5.2.0",
        "eslint": "^8.36.0",
        "eslint-plugin-import": "^2.27.5",
        "eslint-plugin-jsdoc": "^40.1.0",
        "mocha": "^10.2.0",
        "mocha-jenkins-reporter": "^0.4.8",
        "mocha-sonarqube-reporter": "^1.0.2",
        "nyc": "^15.1.0",
        "shx": "^0.3.3",
        "sinon": "^15.0.4",
        "ts-node": "^10.9.1",
        "tslint": "~5.18.0",
        "typescript": "~5.8.2"
    },
    "engines": {
        "node": ">=18.0.0"
    },
    "plugin": {
        "provides": [
            "generic"
        ]
    }
}

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura QA Tool execution guide

Guidelines for the configuration and execution of the QA global test set (QA Tool)

Configure the QA Tool

Four main steps are required for the QA Tool configuration, which are described in the following sections.

Test properties file encryption

Configuration of environment credentials

For the configuration of the QA Tool, certain credentials are required, which are included in a JSON file. Ask for this file to the team that carries out the deployment: Global Deployment Team or OB’s Local Deployment Team.

⚠️ The credentials file is confidential. If the Local QA Team needs to share it through GitHub, they can use git-crypt for file encryption, as a suggestion.
Unencrypt the credentials file, whose name is:
[country_code]-[env]_info.json
Otherwise, an error message will appear: “No JSON object could be decoded”.
Place the file in the following folder:
~/[project_folder]/aura-tests/acceptance/settings/[country_code]/
Where:
- [country_code]: code of the corresponding country br, de, es, uk

Configuration of Kubernetes

Ask the corresponding Deployment Team for the kubernetes config file: [env].yml
Unencrypt the file. Otherwise, an error message will be shown:
“‘utf8’ codec can’t decode byte #xee: invalid continuation byte”
Place the unencrypted file in the following path:
~/[project_folder]/aura-tests/acceptance/settings/[country_code]/[env].yml

ℹ️ After installing an Aura platform release, you will find these two files needed for running the QATool in the output_install folder:

Once infrastructure is created, the kubeconfig file is generated.
Once the full installation is finished, a [country_code]-[environment]_info.json file is found.

Please, check the Aura Deployment documentation for further details:

Users’ configuration

For the configuration of users, create a new file in the following path: ~/[project_folder]/aura-tests/acceptance/settings/[country_code]/[country_code]-[environment]-users.json

It is important to follow the above mentioned syntax: [country_code]-[environment], where:

[country_code]: code of the corresponding country: br, de, es, uk
[environment]: environment name located in the properties file.

For example, for UK: (uk-dev-local-properties.json):

"environment": {
  "name": "uk-dev-local"
}

For the previous example, the path and file should be:
~/[project_folder]/aura-tests/acceptance/settings/uk/uk-dev-local-users.json

Afterwards, the file must be filled in with the different users’ configuration.

The detailed procedure is included in the document Configuration of users’ data.

This JSON file must include two differentiated sections:

users_definition: definition of the different type of users and their associated parameters: type, msisdn, userid, subscription, etc.
user: different use cases attached to the users defined in the previous section.

An extract of this file for UK is shown below: uk-pre-users.json

Extract of `uk-pre-users.json` file

"users_definition": {
    "user1": {
       "subscription_type": "prepaid",
       "user_type": "monomsisdn",
       "msisdn": "+44xxxxxxxx",
       "userid": "42058633",
       "uid": "325851",
       "email": user1@GMAIL.COM,
       “password”: “****”
    },
    "user2": {
       "subscription_type": "postpaid",
        "user_type": "monomsisdn",
       "msisdn": "+ +44xxxxxxxx ",
        "userid": "126529396",
        "uid": "509652361",
       "email": user2@GMAIL.COM
       “password”: “****
    },
"users": {
"default": "user1",
"common":{
     "prepaid":"user1",
     "postpaid":"user2"
       },
       "data_usage":{
            "prepaid_monomsisdn_single":"user1",
            "prepaid_monomsisdn_multiple":"",
            "postpaid_monomsisdn_single":"user2",
            "prepaid_monomsisdn_multiple":"",
            "prepaid_multimsisdn_single":"",
            "postpaid_ multimsisdn _multiple":"",
            ….
       },
"billing":{
            "prepaid_one_bill":"user1",
            "postpaid_no_bills":"user2",
            ….
       },
"bundle":{
...
}

Moreover, some examples are included in the Github repository for the Local QA Teams that can be checked:
~/[project_folder]/aura-tests/acceptance/settings/[country_code]/[country_code]-[environment]-users.json

The mandatory authorization_id is supported by the QA Tool. This parameter is included in the properties file and can have the values optional or mandatory. The default value for authorization_id is optional.

"4p": {
  "authorization_id": "mandatory"
}

There are three different ways through which the user can authenticate:

MSISDN
Uid + password
Email + password

Detailed information can be found in Configuration of users’ data.

Input yaml resources and translation of input sentences for each use case

The ~/[project_folder]/aura-tests/acceptance/resources/language/ path, contains yaml files with the texts of the resources used in the tests, depending on the configured language.

Each yaml file will contain a different section for each [language_code]: es-es, en-gb, pt-bror de-de. See the example below.

At this stage, it is required to check these resources (statements) and update them in case it is necessary.

As an example, for the data_usage resource, the file questions_novum.yaml placed in the above mentioned path contains the label for the country and the texts for each language:

data_usage:
  question:
    en-gb: why do i experience slower speed when i browse?
    pt-br: Quantos dados celulares tenho disponíveis?
    de-de: Zeig mir meinen Verbrauch vom Datenvolumen
    es-es: Consumo de datos actual

Find below two examples where this file should be updated:

Test failure with result: “I can’t understand” or similar. Check the text inside the yaml file and update it if it is not appropriate for the specific use case.
Test failure with result: “es-es do not exist”. This means that the label for the country does not exist in the yaml file. Add the label and text for that resource.

Generate and export POEditor resources

The expected answers for a specific use case provided by aura-bot are generated in POEditor (both aura-bot resources and its associated texts).

At this stage, you should follow these steps:

Export from POEditor the JSON file containing resources and texts.
- Ask the Aura Platform Team or Delivery Team for the file exported from POEditor containing the above-mentioned resources and texts. However, if the OB has admin credentials, the file can be directly downloaded from POEditor.
- Select the “Export” option in the POEditor project.

Select the JSON icon and press “Export”.

Rename this file as poeditor_terms.json and put it in the following path: ~/[project_folder]/aura-tests/acceptance/resources/poeditor/poeditor_terms[language_code].json_
Where [language_code] can be: es-es, en-gb, pt-br, de-de.

If you need to modify these resources or create new ones, do it directly in the JSON file.

An example of POEditor resource in poeditor_terms.json file is shown below:

   {
        ... 
    },     
    {
       "term": "Currently you do not have data services",
       "definition": "Currently you do not have data services",
       "context": "data_usage",
       "term_plural": "",
       "reference": "services:services.usage.noData",
       "comment": ""
    },
    {
        ... 
    }

Execute the QA Tool

The current section includes the stages for the execution of the QA Tool from DEV-LOCAL, PRE and PRO environments.

⚠️ For the execution of tests, it is required to activate VPN full.

The following figure schematically shows this process for the execution of the QA test set:

Set and check global variables

Environment variables

Firstly, it is required to set ENV as global variable. The format depends on the specific environment:

For DEV-LOCAL environments: [country_code]-dev-local-[channel]
For PRE environments: [country_code]-pre-[channel]
For PRO environments: [country_code]-pro

Where:

[country_code]: code of the corresponding country: br, de, es, uk.

For setting the ENV variable within the activated virtualenv, execute the following command:

$ export ENV=<country_code>-<environment>
For example, for Brazil and del DEV-LOCAL environment: 
$ export ENV=br-dev-local

Properties file

The properties.json file is located in the following paths, depending on the environment.

DEV-LOCAL environments:
~/[project_folder]/aura-tests/acceptance/settings/[country_code]/[country_code]-dev-local-[channel]-properties.json
PRE environments: ~/[project_folder]/aura-tests/acceptance/settings/[country_code]/[country_code]-pre-[channel]-properties.json
PRO environments:
~/[project_folder]/aura-tests/acceptance/settings/[country_code]/[country_code]-pro-[channel]-properties.json

⚠️ Local QA Teams should not modify this file.

Execute QA Tool smoke tests

Remember that smoke tests are a sub-set of tests from the QA Tool that can be executed in PRE / PRO environments

Follow the instructions below for launching specific smoke tests.

$ cd <project_folder>/aura-tests
$ ./acceptance/scripts/run_tests_ob.sh -f <features> -t <feature_tag> -e ‘-D behave_additional_tags=@smoke’

Where:

-f [features]: parameter for the execution of an individual or a specific set of features. This set can be specified using the relative path to the folder that contains the desired feature files.
For example:
- -f features/end_to_end/novum/general
The features are allocated in this folder:
~/[project_folder]/aura-tests/acceptance/features/
-t [feature_tag]: optional parameter that can have different values for several subsets of tests. The list of current allowed values is:
- -t bugs: to execute the tests about bugs.

Some examples are shown below:

Execution of smoke test cases for data_usage feature:

./acceptance/scripts/run_tests_ob.sh -f features/end_to_end/novum/simplify/data_usage.feature -e ‘-D behave_additional_tags=@smoke’

⚠️ Check if the _output folder is not previously created. In the opposite case, it is necessary to ensure that this folder has the correct permissions:

$ ls -lrth <project_folder>/aura-tests/acceptance | grep _output
drwxr-xr-x  25 my_user  staff   800B 30 ene 13:30 _output
If the folder is returned in the previous command, set the correct permissions:
$ chmod –R 755 <project_folder>/aura-tests/acceptance/_output

Execute QA Tool end-to-end tests

Remember that E2E tests include a complete QA Tool test set and are executed in `DEV-LOCAL` environment.

For the end-to-end test execution, launch the following commands:

$ cd <project_folder>/aura-tests
$ ./acceptance/scripts/run_tests_ob.sh -f [path to feature folder or file]

Where:

-f [features]: parameter for the execution of an individual or a specific set of features. This set can be specified using the relative path to the folder that contains the desired feature files.
For example:
- -f features/end_to_end/novum/general

The features are allocated in this folder:
~/[project_folder]/aura-tests/acceptance/features/

Each feature file can be launched alone using the its relative path. For example:

-f features/end_to_end/novum/general/alfred.feature

Different examples are shown below:

Execution of end-to-end tests for Novum channel:
~/[project_folder]/aura-tests/acceptance/scripts/run_tests_ob.sh -f features/end_to_end/novum
Execution of data_usage feature:
~/[project_folder]/aura-tests/acceptance/scripts/run_tests_ob.sh -f features/end_to_end/novum/simplify/data_usage.feature

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Work with Kernel

Guidelines that include different tasks required for working with Kernel

Index

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura dashboards

Discover the dashboards that can be generated through the different tools used for Aura monitoring in order to track and analyze data

Introduction

Dashboards are reporting tools that aggregate and display metrics and key indicators, so they can be examined at a glance by all possible audiences.

These dashboards allow data interpretation and provide an overall view for the evaluation of Aura’s performance, thus improving decision-making. Each component counts on a dashboard to show its current behavior and there is a single dashboard for an Aura overview.

There are two types of dashboards for Aura metrics (Prometheus) that are generated in Grafana:

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Platform services

Description of all the services that compose Aura Platform

Introduction to Aura Platform services

All services that compose the Aura Platform are run as Docker containers on the Kubernetes cluster. This helps us monitor and operate them in a consistent way.

The services can be grouped in three categories:

Infrastructure services. Services that are very tied to the infrastructure and could be reused by other products using this infrastructure.
System services. Management services that are part of Aura Platform and could be potentially shared by several Aura Platform deployments.
Core services. All the other platform services that provide the end-user features.

Infrastructure services

Services related to Aura infrastructure that could be reused by other products using this infrastructure.

cluster-autoscaler

This service scales the cluster nodes. See cluster autoscaler section in the Kubernetes cluster documentation for more details.

System services

alertmanager

The alertmanager is part of the Prometheus suite in charge of sending notifications (email, slack) when an alert goes off in Prometheus.

Notifications are sent to the notifications_email (defined in the deployment profile) using an external global SMTP server administered by the Aura Platform team.

⚠️ It is important that the different teams that operate the platform are subscribed to the alerts.

blackbox-exporter

The blackbox-exporter is a service that allows probing endpoints over HTTP, HTTPS, DNS, TCP and ICMP.

Aura Platform is deployed along with an external service/endpoint that is able to check some services health. The blackbox-exporter uses some HTTPS probes that periodically sends a request to the external endpoint to validate that is still healthy. Its metrics (result, latency, etc) are stored in Prometheus.

Elasticsearch

ElasticSearch is a stateful service that indexes the Aura Platform logs so they can be used for analysis.

It runs as a statefulset. Logs can use a lot of space in disk, so it is important to size the volume accordingly by modifying the following section of the deployment profile:

elasticsearch:
  storage: 10

The retention time of the logs is 7 days by default, but can be configured in the deployment profile. Remember that increasing this value means that logs will take more space on disk and queries against ElasticSearch could take longer to complete.

log_retention_time: 3

There is a lifecycle policy configured to remove the old index from Elasticsearch. You can check this in the Kibana UI.

Also for long term storage of indexes, there is an snapshot configured that stores the index during a year in a blob from the cluster associated storage account. This snapshot can be also checked in Kibana UI.

To check the disk usage, you can use both the Kubernetes Storage or the ElasticSearch dashboard in Grafana.

fluent-bit

Fluent-bit is a daemonset that runs in all nodes, processing its logs and sending them to fluentbit-aggregator.

fluentbit-aggregator

Stateful service that aggregates all logs coming from the fluent-bit processes on every node.

It indexes the logs in Elasticsearch. It has a small data disk of 10GB that acts as a buffer to avoid losing data if something goes wrong (e.g., a network issue or a problem with the Elasticsearch cluster) while trying to index the logs.

It is safe to kill a specific fluentbit-aggregator pod (kubectl delete pod) if it gets stuck for some reason.

node-exporter

The node-exporter is an official Prometheus exporter that gathers hardware and OS metrics exposed by the virtual machines that compose Aura Platform.

Prometheus

Prometheus is a stateful service that scrapes metrics from all the exporters in the platform.

It works in a pull-based metrics collection approach. This means that it periodically (every 30 seconds) requests metrics from every HTTP endpoint exposed by the Aura Platform services. It also gathers information about the infrastructure that sustains the Aura Platform.

Metrics are stored using a local on-disk time series database. The local storage is not meant as durable long-term storage, so metrics have a retention time of 15 days.

On average, Prometheus uses only around 1-2 bytes per sample. To plan the capacity of a Prometheus server, you can use the formula:

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

Since metrics can take some space, it is important to size its volume size accordingly in the following section of the deployment profile:

prometheus:
  storage_size: 10

If the local storage becomes corrupted for whatever reason, shut down Prometheus and remove the storage directory, that is mounted under /prometheus on the Prometheus container.

To check the disk usage, you can use the Kubernetes Storage dashboard in Grafana, looking for the PVC named data-prometheus-0.

If you have a user with a valid role to access the Kubernetes cluster, you can also check the disk usage running df -h on the Prometheus container:

$ kubectl -n aura-system exec -it prometheus-0 -- df -h

However, the second alternative is discouraged because it is more intrusive and error prone. Running arbitrary commands on the Aura Platform containers or nodes will be forbidden and will fire security alerts in future releases.

The recommended pattern for running Prometheus in HA mode is to run duplicated instances (same configuration, scraping the same targets independently). That means having at least two replicas running.

Thanos

thanos-sidecar container

The “thanos-sidecar” container is a sidecar to the “prometheus” container that enhances it by exposing a gRPC StoreAPI and by uploading blocks to an object storage API (like Azure Blob Storage). It is a stateless component.

thanos-querier

The “thanos-querier” container exposes a gRPC StoreAPI and an HTTP Prometheus v1 API. It gathers the data needed to evaluate the query from underlying StoreAPIs, evaluates the query and returns the result. It is a stateless component.

The configured StoreAPI sources are:

system namespace -> prometheus/thanos-sidecar
system namespace -> thanos-store-gateway

thanos-compact

The “thanos-compact” container is a component that applies the compaction procedure of the Prometheus 2.0 storage engine in order to block data stored in object storage APIs (like Azure Blob Storage). It also generates downsampled blocks from each raw block.

It is a stateful component, as it must be deployed as a singleton (against an exclusive label selector).

thanos-store-gateway

The “thanos-store-gateway” container exposes a gRPC StoreAPI. It serves data blocks containing metrics stored in Azure Blob Storage.

It is a stateless component; however it consumes local storage for sync purposes and benefits from persistence against increased start-up times.

Grafana

Grafana is an open-source service for analytics and monitoring purposes. The Aura Platform uses it to display metrics from Prometheus in several dashboards.

⚠️ Changes to the official Aura Platform dashboards (those with the “baikal” label) will be overridden on every deployment of the Aura Platform infrastructure.

⚠️ Grafana is not prepared to alert the Aura Platform. Aura Platform interfaces are the Prometheus API and the alertmanager.

Kibana

Kibana is the service used by Aura Platform to access logs indexed in ElasticSearch.

The first time accessing Kibana, you need to create an index mapping against “aura-services-*”, using @timestamp as the temporal reference for logs.

Remember that logs are stored in ElasticSearch for 10 days by default.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Context components

Definition of the main concepts and components in Aura Context

Introduction

The current document defines the key components in Aura Context:

Agent

Definition and sub-components

An agent is defined as a specific profile for accessing and using Aura Context.

This profile provides a unique layout of the information included in Aura Context, so the different fields included in the context database are shown or not or can be displayed with one specific structure or another.

An agent contains two main components: transforms and fields schema. When an agent is created, it includes by default a set of predefined transforms and fields schema that define how data is handled by the agent:

Transform

Component that defines the behavior of the agent when performing different operations.
It includes the default configuration for the agent using the Aura Context global data model.

If developers require the modification of fields in the global data model, it must be done via transform.
Fields schema

Component that defines and validates the agent’s own data fields. It is a JSON file named fields_schema.json, which is empty when creating an agent. It must be edited if developers want to include new fields in the global data model.

After creating an agent, developers can start using Aura Context with its default transforms.

However, if the Aura Context global data model does not fit the developer’s model, it can be modified through these two components of the agent.

Operations performed by an agent

Agents can perform three different data handling operations:

create_context
- Operation for the creation of a data entry in Aura Context. If a data entry already exists, it overwrites it.
- The URL has the following format: <agent_name>/create
upsert_context
- Operation for the modification of a data entry in Aura Context. Depending on the existing data, this operation works to update or insert data.
- The URL has the following format: <agent_name>/upsert
fetch_context
- Operation for data recovery in Aura Context.
- The URL has the following format: <agent_name>/fetch
- There are three different procedures for data fetching:
  - Retrieving data using a correlator (corrId field in the Aura Context global data model)
  - Retrieving data with user and date
  - Retrieving user’s N latest data

These endpoints are fixed, but the user can configure how each endpoint is summoned.

Transform

Definition

In Aura Context Framework, a transform is a component that defines the behavior of an agent for the performance of different operations.

It allows the adaptation of data provided by a user into data compatible with the Aura Context data model. The transform defines the request to the API, so every agent can decide how to send data by defining the appropriate transforms.

When a developer wants to use Aura Context, she is provided with a default set of transforms, that correspond to the format suitable with the Aura Context global data model:

Find here Aura Context default transforms.

If the user’s data is compatible with the global data model, the developer can use the default transforms and start working with Aura Context. This situation corresponds to the API specifications set in the swagger.
However, if the developer requires the conversion of data with specific format into data compatible with the Aura Context global data model, he must configure his own transform. In this situation, API specifications will change. This provides a great flexibility to Aura Context, so every developer can upload his own data (in different formats or with different fields) to the Context database and the homogeneity of the uploaded data is guaranteed.

The following examples show a practical use of a transform:

Scenario A
- Agent bot generates data A (integer).
- Data must be stored in the context database as a string.
- The developer converts data A from integer to string via transform.
Scenario B
- Agent NLP has a field named “applicationId_2”
- This field is named as “applicationId” in the context database
- The developer converts the name of this field to be compatible with the context database via transform.

Files

Each transform includes two different files:

request_transformer.json:
This file allows sending free-formatted fields to be included in Aura Context through the API. Data will be transformed later on, so the resulting data is suitable with the Aura Context global data model.
The file includes the data/metadata in the request from Aura Context API:
- “data” corresponds to the request body
- “metadata” corresponds with the request header
response_transformer.json:
This file allows transforming the result data from a specific operation, which fits with the context global data model, into data suitable with the input component.
The file includes the data/metadata in the response from Aura Context API:
- “data” corresponds to the response body
- “metadata” corresponds with the response header

Each type of operation performed by the agent must include these two files. Therefore, the following combination of operations and files will be generated:

[working_directory]/agents/transformations/[agent_name]/create_context/request_transformer.json
[working_directory]/agents/transformations/[agent_name]/create_context/response_transformer.json
[working_directory]/agents/transformations/[agent_name]/fetch_context/request_transformer.json
[working_directory]/agents/transformations/[agent_name]/fetch_context/response_transformer.json
[working_directory]/agents/transformations/[agent_name]/upsert_context/request_transformer.json
[working_directory]/agents/transformations/[agent_name]/upsert_context/response_transformer.json
[working_directory]/agents/fields_schemas/[agent_name]/fields_schema.json

Types of Aura Context Transforms

Depending on the goal to be achieved with the transformation of the agent, there are three different types of Aura Context transforms: inferred / injected / imported. All of them has certain mandatory files:

Imported transform

This transform allows reusing common content from other transforms. The transform is imported if it is loaded from a JSON file.

Mandatory fields for this transform are included in the tables of the section fields of Aura Context transforms.

An example is shown below:

    [
        {
            "t_type": "imported",
            "relative_file_path": "../../transformer.json"
        }
    ]

Injected transform

This transform is used to enter a forced value from the transform itself, through the o_value field. It is used when you need to load a value that is not found in the origin data or in metadata.

Mandatory fields for this transform are included in the tables of the section fields of Aura Context transforms.

An example is shown below:

    [
        {
                "t_type": "injected",
                "a_trans": [],
                "o_value": "100",
                "o_basic_type": "str",
                "o_collection_type": "simple",
                "d_path": "metadata.database.field1",
                "d_basic_type": "str",
                "d_collection_type": "simple",
                "required": true,
                "o_nullable": false,
                "d_nullable": false
        }
    ]

The output of this transform is:

    metadata = {
        'database': {
            'field1': '100'
        }
    }

The field d_path is used to define the new field name, and o_value corresponds to the origin value.

Inferred transform

This transform is used to get the value from data/metadata sent in the request and transform it. For example, if the initial data is:

        data = {
            'information': {
                'name': 'test',
            }
        }

And it is required to change the field path information by info, the following transform can be used:

        [
            {
                't_type': 'inferred',
                'a_trans': [],
                'o_path': 'data.information.name',
                'o_basic_type': 'str',
                'o_collection_type': 'simple',
                'd_path': 'data.info.name',
                'd_basic_type': 'str',
                'd_collection_type': 'simple',
                'required': True,
                'o_nullable': False,
                'd_nullable': False
            }
        ]

The results will be:

        data = {
            'info': {
                'name': 'test',
            }
        }

The field d_path is used to define the new destination field name.

Mandatory fields for this transform are included in the tables of the section fields of Aura Context transforms.

Fields of Aura Context transforms

The definition of a transform includes several mandatory fields, depending on the transform type:

Fields beginning with o_: data corresponding to the transform input (origin)
Fields beginning with d_: data corresponding to the transform output (destination)

Fields in Aura Context transforms

The following table shows the existing fields in Aura Context transforms. They can be mandatory or optional depending on the type of transform.

Field	Description
`t_type`	Field that indicates the transform type (`imported`, `injected` or `inferred`).
`relative_file_path`	Path that indicates the location of the origin JSON file with the transforms. This file needs to be included in the agent.
`a_trans`	It indicates an additional transform and can be a list composed of the following elements: `to_str`, `to_int`, `to_float`, `uniques`, `to_list`, `sum`, `average`, `from_json`, `to_json`, `min`, `max`, `round`, `round_floor` or `round_ceil`.
`o_value`	Field value.
`o_path`	Origin field name. It must be a string formed from ASCII letters, numbers, ‘.’, ‘@’, ‘_’ and ‘-’
`o_basic_type`	Field data type. It can be `str`, `bool`, `float`, `int`, `nested` or `date`
`nested_transformations`	It indicates a nested transform. It is mandatory if `o_basic_type` or `d_basic_type` is `nested`
`o_collection_type`	It indicates whether the field is a collection or a simple string. It can be `list` or `simple`
`d_basic_type`	Destination field data type in the JSON file. It can be `str`, `bool`, `float`, `int`, `nested` or `date`
`d_collection_type`	It indicates whether the field is a collection or a simple string. It can be `list` or `simple`
`d_path`	Destination field name. It must be a string formed from ASCII letters, numbers, ‘.’, ‘@’, ‘_’
`required`	Boolean field (`true` / `false`)
`o_nullable`	It indicates that the field can be nullable before transformation (origin). It is a boolean field (`true` / `false`)
`d_nullable`	Mandatory field in injected and inferred transforms. It indicates that the field can be nullable after transformation (destination). It is a boolean field (`true` / `false`)

The table below summarizes the mandatory fields ( ) for each type of transform:

Fields	Imported transform	Injected transform	Inferred transform
`t_type`
`relative_file_path`		..	..
`a_trans`	..
`o_value`	..		..
`vo_path`	..	..
`o_basic_type`	..
`nested_transformations`	..	If `o_basic_type` or `d_basic_type` is nested	if `o_basic_type` or `d_basic_type` is nested
`o_collection_type`	..
`d_basic_type`	..
`d_collection_type`	..
`d_path`	..
`required`	..
`o_nullable`	..
`d_nullable`	..

Additional Aura Context transforms

Aura Context also allow certain additional transforms that can be applied to the fields. They are indicated in the field a_trans and applied in the order they have been defined. The output of a transform is the input to the following one.

They are listed below:

to_str: It converts the field to a string.
For example: 2 –> “2”, [“hello”] –> “[“hello”]”
to_int: It converts the field to an integer.
For example: “2” –> 2, 3.2 –> 3
to_float: It converts the field to an integer.
For example: “2,6” –> 2.6, 3 –> 3.0
uniques: It receives a list of strings and remove duplicate items.
For example: [“hello”, “hello”] -> [“hello”]
to_list: It converts the field to a list.
For example: “hello” -> [“hello”]
sum: It receives a list of integers or floats and sum the elements. It returns an integer if all elements are integer and otherwise, returns a float. In case of empty list, it returns none.
average: It calculates the average of the elements of a list. It returns a float. In case of empty list, it returns none.
from_json: It deserializes the field in a JSON.
to_json: It converts the field in a serializable JSON.
min: It gets the minimum of the elements in a list. It returns a float or an integer depending on the type of element. In case of empty list, it returns none.
max: It gets the maximum of the elements in a list. It returns a float or an integer depending on the type of element. In case of empty list, it returns none.
round: Round up. It returns an integer.
round_floor: Round down. It returns an integer.
round_ceil: Round up. It returns an integer.

It is also possible to define multiple additional transforms in the a_trans field.

For example:

{
    "a_trans": ["sum", "to_int"],
}

If you have the following data: data = [2.1, 3.0]

1. All elements are added
1. It converts the result into an integer. So, the result will be 5.

Data and metadata

Data availability

Aura Context works with data and metadata for every operation to be performed (create, upsert or fetch).

In order to perform these operations, it is required to know how the Aura Context API matches input data (data sent via API) with data/metadata for Aura Context and vice versa (how internal data/metadata used by Aura Context for each operation is transformed into response data).

Currently, the three permitted operations correspond to the HTTP POST request method:

HTTP POST request’s body and headers will be matched with the input data and metadata of the request transform respectively.
- Field data: request body
- Field metadata: request headers
After the execution of the corresponding operation, the data/metadata in the response transform will be matched with the HTTP body and headers respectively:
- Field data: response body
- Field metadata: response headers

The following figure shows the match between HTTP request/response and Aura Context data/metadata:

As an example, if the following request is sent:

headers: {'my-headers-1': 'some value'}
body: {
    'my_field_1': 'another value',
    'my_field_2': 2
}

Then, the following data and metadata will be available to be used in the request transforms:

data = {
    'my_field_1': 'another value',
    'my_field_2': 2
}
metadata = {
    'my-headers-1': 'some value'
}

Therefore, a transform containing the following input fields can be generated:

{
'o_path': 'data.my_field_1',
'o_collection_type': 'simple',
'o_basic_type': 'str'
}

Apart from these general considerations for the use of data and metadata in Aura Context, each specific operation (create, upsert, fetch) require certain data/metadata for the request and for the response. They are described in the following sections.

Data and metadata in create and upsert operations

Remember that this section is useful just for generating your own transforms, as the default ones already include this content

request_transformer.json

Data and metadata required for the create/upsert operations must be transformed in a specific way so as to be a valid input for these operations:
- Data: Document to be inserted in the context database, following the requirements of the global data model. Therefore, each field must match with the fields of the global database (column “Name in database”).
- Metadata: Automatically generated.

response_transformer.json

Once data is created/modified in the context database, these two operations generates another data/metadata with the result of the corresponding operation.
These data and metadata can be used as input fields for the response_transformer.json file, with the following mandatory fields:
- Data:
  - results: List including true/false value for the result of the process of inserting/modifying data (upsert operation)
- Metadata:
  - db_execution_time: Duration of the operation execution in the database

An example is shown below:

{
'o_path': 'metadata.db_execution_time',
'o_collection_type': 'simple',
'o_basic_type': 'float',
'd_path': 'data.execution_time',
'o_collection_type': 'simple',
'o_basic_type': 'float'
}

In this example, the body of the response to the request includes a new field execution_time, with the value of the operation duration.

Data and metadata in fetch operation

The fetch operation includes different procedures, each of them requiring different data and metadata depending on the type of query to the database.

The content of data and metadata on each operation is described in the following sections.

Common data and metadata

Common data and metadata for the three different procedures in the request_transformer.json file.

Data
- projection (optional): this field filters specific fields from each document fetched from the context database
Metadata
- page_size (optional): number of documents to be retrieved from the context database (applicable in case of queries including page numbering)
- page (optional): page to be retrieved from the context database (applicable in case of queries including page numbering)

Fetch by correlator

Apart from the common data and metadata, the following mandatory data/metadata must be included in the request_transformer.json:

Metadata
- corr: correlator ID to be fetched from the context database, together with the aura_id_global parameter.

Fetch by user’s N latest data

Apart from the common data and metadata, the following mandatory data/metadata must be included in the request_transformer.json:

Data
- last_n: number of documents to be retrieved from the context database

Fetch by date range

Apart from the common data and metadata, the following mandatory data/metadata must be included in the request_transformer.json:

Data
- start_date: starting date of the date range
- end_date: ending date of the date range

When the fetch operation is executed, the data and metadata from the response, which follow the format from the global data model, can be transformed to fit with the user’s data model in the response_transformer.json file. In this transform, only data from the response documents can be modified, the remaining data are provided back by default (this is fully specified in the Aura Context swagger).

Fields schema

Definition

The fields schema is the second component of an Aura Context agent. It is used for the definition of new fields on the Aura Context global data model if it is required by the developer.

When an agent is created, it includes the empty JSON file fields_schema.json.

Find here Aura Context default fields schema.

If the developer requires the generation of a new field in the global data model to be adapted to his own data, he must modify the fields schema:

Edition of the fields_schema.json to include the necessary modifications.
Definition of the modifications in the transform: Once the fields schema file has been modified, these variations must also be reflected on the agent’s transform.

Fields schema format

The file fields_schema.json is a dictionary of dictionaries that includes the different types of fields that must be used in the agent’s transform.

These fields must have the following format:
<data | metadata>. <agent_name> @ <field_name>
Where:

<data | metadata>: origin of the field (data or metadata)
<agent_name>: name of the agent
<field_name>: name of the field

Each new field is characterized by two main parameters:

basic_type: it can be str, bool, int, float, nested and date.
collection_type: it can be of type simple or list.

It is important to bear in mind that new fields in the Aura Context global data model must be created in a new table, as it is not possible to add a field to an existing table such as Application, Environment, etc.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Contributing to Aura

Discover how to contribute to Aura Platform global repositories

Introduction

The aim of this document is to establish common minimum rules for developers willing to contribute to Aura Global repositories:

How to request access to Aura repositories in Github
How to write code in aura-bot global repositories
How to migrate a git folder to a new repository
How to manage user stories and tasks in JIRA
Types of branches and guidelines for the generation of a new branch

The target audience of the document are developers of global and local teams contributing to Aura Global repositories:

aura-bot developers
aura-bridge developers
aura-services-api developers
…

⚠️ This document assumes that the developers already have permissions to access Telefónica organization in Github.

Branches used by Aura

Aura uses 2 different types of branches:

Eternal or pseudo eternal branches

These are protected branches, that MUST be always deployable in a given environment.

Protected means:

Only code owners can push code to them
All changes MUST be pushed through a pull request, that MUST pass the continuous integration checks and count on, at least, 2 approval reviews of code owners.

These branches are:

master: it holds next release code. It MUST be deployable in the global development environments.
main/*: it holds the development of a unique User Story or set of User Stories.
release/*: it holds the given release code. It MUST be deployable in global development environments and also in PRE and PRO of the OBs involved in this release developments.
hotfix/*: it holds the resolution of an issue or set of issues happening in a pre or pro environment.

Temporary branches

As any change in eternal branches MUST be done though a Pull Request, it means that they must be done in a temporary or feature branch.

These branches are usually named after the type of change they are going to hold: feat/my-new-feature or fix/fixing-that.

This format is <type>/<description>[#issue_number] where:

type is one of feat, fix, chore and docs
description should be a short description, dash-separated words, of the change. If using Jira as issue manager, add the number of the issue being resolved after a #.

Process for generating a new branch

First of all, clone the repository and choose an eternal branch as base branch for your feature:

$ git clone git@github.com:Telefonica/aura-bot-platform.git
$ cd aura-bot-platform
$ git checkout main/my-feature#12345

Or update the base eternal branch for your feature:

$ cd aura-bot-platform
$ git checkout main/my-feature#12345
$ git pull origin main/my-feature#12345

Then, create a new branch:

$ git checkout -b feat/my-new-feature

Some recommendations should be considered:

Split your changes in small tasks (max 1 day per task)
Use a feature (feat, fix, chore, …) branch per task
Do small commits with spotted functionality
Do small PRs with all the code of a given task
When asking a PR remember to include an explanation of the why, how, what has been done in the PR, in order to help reviewers to understand the change.

Commit messages format

The format followed in Aura is the one described in Conventional Commits.

These messages are used to handle the version of each Aura component so it is very important to follow these rules.

NOTE: Pull Requests including commits without this format will be rejected.

Format

<type>(<optional scope>): <description>

[optional body]

Valid types: feat, fix, chore, docs
Valid scopes:
- global, can be omitted, if affects all the packages or it’s a basic change.
- the affected package in a multipackage repository.
- the affected library, plugin or dialog in library repository.
- if it affects a concrete feature in the repository: logging, kpis, authentication, etc.
- it can also be omitted in global cases, in minor changes, etc.
Description: indicative sentence in lower case.
Body: only if description field is not enough to understand the changes

Folder layout

In general, all the repositories containing typescript code should have an src folder with all the typescript source files there, and those source files will be transpiled into javascript into folder lib.

Unit tests

Currently aura-bot team is moving to Jest as unittest runner, so a couple of versions of unittest can be found:

Projects running with mocha, such as aura-bot-platform.

Test files should be included in the same folder as the files to test, with a trailing .spec.ts in the file name (these files should be .npmignore, to avoid being in the final package).

Test assets required for tests (.json files, images, .env files, etc.) will be placed in a test folder (that should be .npmignore too), so they will be available for typescript/javascript files by getting the path ../test or similar.

Projects running with jest, such as aura-mocks-server.

There will be a specific folder called test, at the same level than src and that will hold all the unit tests following the same structure than src. As with mocha tests, they must be ignored in the production transpilation and the files published in npm.

More about src/ folder layout in aura-bot-platform can be found in this file.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Fluent bit dashboard

Information provided by Fluent bit dashboard

Introduction

Fluent bit dashboard monitors system metrics related to fluent bit.

The available metrics are defined in the following sections.

Input bytes

Input bytes rate, aggregated by one minute.

Metrics:

rate(fluentbit_input_bytes_total[1m])

Graph visual

Output bytes

Output bytes rate, aggregated by one minute.

Metrics:

rate(fluentbit_output_proc_bytes_total[1m])

Graph visual

Retries/fails

Rate of retries and fails, aggregated by one minute

Metrics:
It includes two metrics:

Retries rate

rate(fluentbit_output_retries_total[1m])

Fails rate

rate(fluentbit_output_retries_failed_total[1m])

Graph visual

Errors

Rate of output errors, aggregated by one minute.

Metrics:

rate(fluentbit_output_errors_total[1m])

Graph visual

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

General operational guidelines

This section includes general-purpose guidelines for the operation of Aura that are transversal to different Aura components

Index

Aura operational flows: Flowcharts related to Direct Line, use cases and key channels in Aura
Description of Aura make-up processes
Hot swapping processes in Aura
Procedure for managing locales in Aura
Guidelines for the elimination of expired Aura users
Information regarding Aura Continuous Integration

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Migrate a git folder to a new repository

Learn how to migrate a folder within a Git repository to another repository

Move files with history

This document explains how to migrate the history of the files to the new repository (that could or could not be desirable).

This process tells how to move a part of a repository (folder) to a new repository, maintaining the history of the files. A new fresh copy of the origin repository is required, as it will not be usable anymore.

These commands will prepare a repo with only the commits from a specific folder (removing anything else):

# Clone a fresh copy of origin repo and enter into it
git clone <giturl-repoA>
cd <repoA>
# Optional, to avoid pushing to the wrong remote repository
git remote rm origin
# From the repo source, remove all the files and history outside the folder
git filter-branch --subdirectory-filter <folder-name> -- --all

Now, we can import in the new repository following these steps:

# Optional, clone a fresh copy of destination repo (or could use a previously existing one) and enter into it
git clone <giturl-repoB>
cd <repoB>
# Add a new remote pointing to local path with repo A
git remote add repoA <local-path-repoA>
# Pull from previous local repository the dialog files, branch master (replace if using a different one)
git pull repoA master --allow-unrelated-histories
# Optional, create a new branch to merge into
git checkout -b <destination-branch>
# Remove local remote, not required anymore
git remote rm repoA

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

OB analytics

Description of the OB OB Analytics subsystem that can be managed by OBs.

Introduction

The OB Analytics subsystem is an optional component in the dataflow, which enables the management of clean PPDs (Privacy-Preserving Datasets) by LCDOs for the analysis of Aura behavior.

In order to work with OB Analytics subsystem, the following items must be fulfilled:

 The legal agreement for log management and creation of PPDs must be signed between the OB and Aura Global Team.
 The mechanism for PPD creation and transfer must be installed. This requires the deployment of a piece of software (provided by Aura Global Team) inside the OB cloud, with access to the repository (AWS bucket or Azure Blob Storage) holding Aura logs.
 A virtual machine must be deployed on the OB cloud to hold the OB Dashboard. This virtual server must be provisioned by the OB on the same cloud environment (provider and region, e.g., AWS West Europe) than the Kernel cloud, but separated from it in terms of access rights (placing it in the same cloud enables saving transfer costs from the cloud provider for PPD access).

Architecture and installation

The basic infrastructure of the OB Analytics subsystem consists on a Virtual Machine that is fed with the extracted and cleaned PPDs. This virtual machine is set up with a proposed stack of tools based on the open-source ELK framework (See figure in Architecture document).

Elastic Search: indexing database.
Logstash: ingester for PPD data, configured to upload the anonymized clean PPD tables into Elastic Search.
Kibana: visualization tool offering dashboards and panels created over Elastic Search data.

The OB is required to set up the base VM, for which an Ubuntu 18.04 system is advised.

On top of this base system, Aura Global Team provides an installation kit that includes:

The pre-processing and ingesting configuration for feeding clean PPD data into logstash.
The indexing configuration for Elastic Search.
Certain prototype dashboards and panels for Kibana.
Basic security provisions (providing web-based secure access to the dashboard).

Once installed, the system automatically ingests any new clean PPD being produced, so that the index and dashboards remain up to date.

In principle, the PPD creation process specifies daily production, since Aura logs are sent to Kernel once a day. This means that information about Aura behavior and user actions on one given day will be available in the dashboards on the following day.

The provided system and installed dashboards are only visualization examples for clean PPDs. The system allows the creation of additional panels that may provide complementary insights on clean PPD elements and OBs are encouraged to explore data as they see fit.

Dashboards can be exported and reimported in a different system, so in addition to the LCDO team adding new analysis features, it is possible to provide later updates to the OB Analytics system. These updates can be provided by the Aura Global Team or shared between OBs.

Outside the dashboard stack, it is also possible to process clean PPD with alternative tools (PPDs are essentially CSV files with a defined structure, so they can be processed with a variety of tools).

Kibana dataflow

The Aura Analytics dashboard follows a standard ELK deployment:

An Elastic Search index has been created. It is called aura-message-COUNTRY, and its index schema contains a cleaned version of the AURA MESSAGE table (which registers input and output messages). For details on the fields that this index contains, go to the document Data model.
A Logstash configuration ingests into this index the cleaned sets of datapoints that are produced daily as a result of the transfer and processing of Aura logs. This is usually done in the early morning (which will then upload data for the previous day).
A Kibana index pattern has been created, matching the uploaded Elastic Search index. An Elastic Search index is how the data is stored inside the DB; a Kibana index pattern is how it is visualized in the interface. Typically, Kibana index patterns match Elastic Search indices, but it is, for example, possible to create a Kibana index pattern that matches more than one Elastic Search index and hence combines different data sources.
A small set of visualizations have been pre-installed in Kibana over that index pattern, as a means to get a default peek on the index data. See the section preinstalled visual elements to check them.

This configuration is deployed on the Kibana default space (the only one available on a freshly created Aura Analytics dashboard). If there is the need to create additional spaces, to better organize visualizations, then the Elastic Search index pattern needs to be installed into those additional spaces.

Preinstalled visual elements

Kibana offers many possibilities to visualize the ingested data and there are many resources and tutorials around explaining its mechanics. We therefore refer to the official Kibana documentation, or tutorials available on the web, for generic information.

In the particular case of the Aura Analytics deployment, there is an Elastic Search index that gets automatically ingested daily. It is called Aura-message-COUNTRY and contains a cleaned version of the AURA MESSAGE table (which registers input and output messages).

Over this index, three types of panels/visualizations have been preinstalled, to provide a starting point:

Discover panel
Visualizations
Dashboards

These preinstalled elements are described in the following subsections. To access them, select the appropriate icon in the left navigation panel.

Discover panel

The Discover panel in Kibana is an essential tool where one can perform queries to an Elastic Search index (and save those searches if desired), and explore users’ interactions with Aura in detail log by log, these being filtered by:

 Search terms or conditions
 A time interval
 Additional filters applied to the query results
 A set of index fields to show in the result table

These 4 steps are represented in the following figure:

As shown in the previous figure, the starting point is the Elastic Search index holding all the data. The three first steps in the chain reduces the amount of data handled, by pruning out elements that do not satisfy the defined condition. The fourth step is just a display adjustment: on the final dataset, define which of the available fields will be shown on the output table that appears in the panel. However, the retrieved data contains all fields (clicking on any of the rows will show them).

In the Aura Dashboard default set, there is one Discover panel preinstalled. It is called question-answer pairs and has the following characteristics:

A blank query (i.e., provide all the results)
A time interval for the last 7 days
A “only user” filter: it filters out all intents that correspond to non-user queries (suggestions, help commands from the client application, etc.)
A visualization that includes: the timestamp, the (cleaned) user message, the detected aura intent, associated entities (if applicable), the dialog that was invoked and Aura’s response

This figure shows a snapshot of this panel. To load it, select the Discover tool in the left navigation bar and then click on the “Open” menu option in the top menu bar. A list of saved panels will be shown, together with the already mentioned “question-answer pairs”.

Once the panel is loaded, each one of the aforementioned four elements can be freely modified. For example, the interface allows:

Adding new filters with the “+Add Filters” button
Deactivating the current filters by pressing over the predefined filter and clicking over the “Temporarily Disable” option
Modifying the query interval with the “calendar” button or “Dates Box”
Adding a specific query on a given index field(s) by using the “Search Box”, instead of the (default) blank query.

Discover panels can be saved as named objects, to be later loaded at will. So, if needed, any panel (a modified panel or a newly created one) can be saved with a new name to have it available for later loading.

Visualizations

A total of 7 visualizations come preinstalled with the base Aura Dashboard. The list can be obtained from the “visualizations” item in the left menu bar, as shown in the figure, and they are:

Three “Stats” type visualizations, which provide general statistics on platform usage.
Four “User” type visualizations, which provide insights on user behavior.

Note that this distinction between “User” and “Stats” is purely conceptual and based on the fields that have been used to generate the visualizations that, from the point of view of Kibana, are all regular visualizations. Those visualizations can be instantly loaded by clicking on their names. But they can also be integrated into dashboards, as described in the next section.

Dashboards

A dashboard in Kibana is essentially a spatial arrangement of visualizations. For example, to construct a dashboard, just place visualizations into a page, resizing them as required, so they can be observed in a single place.

It is interesting to know that in a dashboard all visualizations are linked. So that if, for example, time interval is changed, or a filter is added using the interface, these modifications affect all visualizations in the dashboard and all of them get updated.

Elements in the dashboard visualizations can also generate instant filters by clicking on graphs or table elements. Those filters are then added to the top of the page as a filter and, therefore, can then be modified or removed.

The Aura Analytics default installation preloads two dashboards. Those are available for selection when we click on the “dashboard” icon in the left navigation bar:

There are different types of dashboards, described in the following sections.

System dashboard

This dashboard integrates the three predefined “Stats” visualizations (generic statistics):

A timeline of interactions (user messages sent and answered), segmented by channel
A heatmap of interactions by weekday and time of day (hour)
A bar graph classifying the interactions produced in the period by detected intent

The following figure shows a screenshot of this dashboard:

User dashboard

The user dashboard contains the four visualizations:

Most Frequent User Utterances: list of the most frequent user’s sentences (in the time interval and filter active at the moment). It uses the usrMsgSig field to group together very similar utterances.
Aura Answer Groups: list of the most frequent answers that Aura generates, grouped by the semantic categories in AuraMsgGroup field.
Words per query: distribution of sizes for the user messages, measured as number of words in the utterance and segmented by channel.
Tag cloud: set of most frequent user utterances, as a tag cloud in which the font size represents the utterance frequency. The MESSAGE_USR_NORM field is used for its representation, so it contains normalized utterances.

The next screenshots show the dashboard with all these visualizations (it is a large dashboard, so typically it needs scrolling to visualize all its components).

Note that those four visualizations are linked as they correspond to the same subset of the data (as given by filters and time interval) but they are NOT linked at the individual item level (i.e., a given most frequent user utterance in the left table does not correspond to any specific Aura answer in the right bar graph).

Instead, the dashboard can be manipulated by selecting one specific item in any of the visualization and this will create a filter for the others. For instance, as the following image shows, if we select <CHURN> in the Aura answer group visualization, we can see in the others the user utterances that led Aura to generate that answer (i.e., an answer about contract cancelation).

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Output from QA Tool: logs and reports

Learn how to manage the content of logs and results reports generated after the execution of the QA global test set

QA Tool general results reports

After the QA Tool execution, the results of the tests are copied to the local folder:
📁 ~/[project_folder]/aura-tests/acceptance/_output/

Four general files are generated for every test executed:

Logs file

📁 ~/[project_folder]/aura-tests/acceptance/_output/acceptance_int.log

This is a pass/fail test. When a test fails, a bug is generated and it is required to evaluate its criticity level. The logs will detail the errors that have occurred and the specific part of the code which is failing.

Example of logs file

INFO    2019-07-11 09:50:59,576 [commons] Installed versions in co-pre environment:
Aura: 3.5.0
Bot: 7.14.1
Authentication API: 3.0.0
Configuration API: None
User Helper: 3.2.0.214
NLP: 1.0.9 (container), 1.116.0 (pipelines)
.......
>>>>>>>>>>>>>>>>>>>>> Request >>>>>>>>>>>>>>>>>>>
	> Method: POST
	> Url: https://auth.co-pre.baikalplatform.com/token?grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImM0MmFjMWM0NmYxZDRlMjExYzczNWNjN2RmYWQ0ZmY4MzkxMTEwZTkifQ.eyJzdWIiOiI1MDczOSIsImlzcyI6Imh0dHBzOi8vYWktc2VydmljZXMtcHJlLWNvLmF1cmFjb2duaXRpdmUuY29tL2F1cmEtc2VydmljZXMvdjEvb3BlbmlkL2lzc3Vlci8iLCJwdXJwb3NlIjoiY3VzdG9tZXItc2VsZi1zZXJ2aWNlIGRldGVjdC1hYm5vcm1hbC11c2FnZSBkZXZpY2UtcmVjb21tZW5kYXRpb25zLXYzIHNpbS11cGdyYWRlLXN1Z2dlc3Rpb24gYXVyYS1yZWFkLWluc2lnaHQtZXZlbnRzIGlkZW50aWZ5LWN1c3RvbWVyIiwiZXhwIjoxNTYyODM1MDYyLCJpYXQiOjE1NjI4MzE0NjIsInNjb3BlIjoiIiwiYXVkIjoiaHR0cHM6Ly9hdXRoLmNvLXByZS5iYWlrYWxwbGF0Zm9ybS5jb20vIn0.Zqsc16RZYFFr-GGTTDSAGgb3numx9bhSgdpT0OOCJudJsm20nyXXLxj-MUITK4Pxhnmkc7zwFd0WHJkt955C6NxygwUpURYpxcN2vq7ISewATi-QnYzfcgUUeYXxGTCOb6wWdpYbviOnU_5g1KfaVtC8noYtYkRuspQCBLH8Ao4ZCPuTdCFJdJRb49ujIuL821qTJxrqkDTpzoFH-2_xdVfx_c2OdeCObFWIVFmXMfFW3X_5K0EIP0beBh4yyRoIsWdKFpGWWQ4Ebrx0tawtTTp8Sob42sSxyP4ADN83GpjodPtv-g4KJDoch3LSqDkbvFKzTnt1v2NVY1nqNPtV_w
	> Query params: [(u'grant_type', u'urn:ietf:params:oauth:grant-type:jwt-bearer'), (u'assertion', u'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImM0MmFjMWM0NmYxZDRlMjExYzczNWNjN2RmYWQ0ZmY4MzkxMTEwZTkifQ.eyJzdWIiOiI1MDczOSIsImlzcyI6Imh0dHBzOi8vYWktc2VydmljZXMtcHJlLWNvLmF1cmFjb2duaXRpdmUuY29tL2F1cmEtc2VydmljZXMvdjEvb3BlbmlkL2lzc3Vlci8iLCJwdXJwb3NlIjoiY3VzdG9tZXItc2VsZi1zZXJ2aWNlIGRldGVjdC1hYm5vcm1hbC11c2FnZSBkZXZpY2UtcmVjb21tZW5kYXRpb25zLXYzIHNpbS11cGdyYWRlLXN1Z2dlc3Rpb24gYXVyYS1yZWFkLWluc2lnaHQtZXZlbnRzIGlkZW50aWZ5LWN1c3RvbWVyIiwiZXhwIjoxNTYyODM1MDYyLCJpYXQiOjE1NjI4MzE0NjIsInNjb3BlIjoiIiwiYXVkIjoiaHR0cHM6Ly9hdXRoLmNvLXByZS5iYWlrYWxwbGF0Zm9ybS5jb20vIn0.Zqsc16RZYFFr-GGTTDSAGgb3numx9bhSgdpT0OOCJudJsm20nyXXLxj-MUITK4Pxhnmkc7zwFd0WHJkt955C6NxygwUpURYpxcN2vq7ISewATi-QnYzfcgUUeYXxGTCOb6wWdpYbviOnU_5g1KfaVtC8noYtYkRuspQCBLH8Ao4ZCPuTdCFJdJRb49ujIuL821qTJxrqkDTpzoFH-2_xdVfx_c2OdeCObFWIVFmXMfFW3X_5K0EIP0beBh4yyRoIsWdKFpGWWQ4Ebrx0tawtTTp8Sob42sSxyP4ADN83GpjodPtv-g4KJDoch3LSqDkbvFKzTnt1v2NVY1nqNPtV_w')]
	> Headers:
{
    "Authorization": "Basic YXVyYS1ib3Q6U2pVVTdLY2dWdEllOWdGMHVjanlJakJJRA=="
}
DEBUG   2019-07-11 09:51:02,262 [connectionpool] Starting new HTTPS connection (1): auth.co-pre.baikalplatform.com
DEBUG   2019-07-11 09:51:02,950 [connectionpool] https://auth.co-pre.baikalplatform.com:443 "POST /token?grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImM0MmFjMWM0NmYxZDRlMjExYzczNWNjN2RmYWQ0ZmY4MzkxMTEwZTkifQ.eyJzdWIiOiI1MDczOSIsImlzcyI6Imh0dHBzOi8vYWktc2VydmljZXMtcHJlLWNvLmF1cmFjb2duaXRpdmUuY29tL2F1cmEtc2VydmljZXMvdjEvb3BlbmlkL2lzc3Vlci8iLCJwdXJwb3NlIjoiY3VzdG9tZXItc2VsZi1zZXJ2aWNlIGRldGVjdC1hYm5vcm1hbC11c2FnZSBkZXZpY2UtcmVjb21tZW5kYXRpb25zLXYzIHNpbS11cGdyYWRlLXN1Z2dlc3Rpb24gYXVyYS1yZWFkLWluc2lnaHQtZXZlbnRzIGlkZW50aWZ5LWN1c3RvbWVyIiwiZXhwIjoxNTYyODM1MDYyLCJpYXQiOjE1NjI4MzE0NjIsInNjb3BlIjoiIiwiYXVkIjoiaHR0cHM6Ly9hdXRoLmNvLXByZS5iYWlrYWxwbGF0Zm9ybS5jb20vIn0.Zqsc16RZYFFr-GGTTDSAGgb3numx9bhSgdpT0OOCJudJsm20nyXXLxj-MUITK4Pxhnmkc7zwFd0WHJkt955C6NxygwUpURYpxcN2vq7ISewATi-QnYzfcgUUeYXxGTCOb6wWdpYbviOnU_5g1KfaVtC8noYtYkRuspQCBLH8Ao4ZCPuTdCFJdJRb49ujIuL821qTJxrqkDTpzoFH-2_xdVfx_c2OdeCObFWIVFmXMfFW3X_5K0EIP0beBh4yyRoIsWdKFpGWWQ4Ebrx0tawtTTp8Sob42sSxyP4ADN83GpjodPtv-g4KJDoch3LSqDkbvFKzTnt1v2NVY1nqNPtV_w HTTP/1.1" 200 None
DEBUG   2019-07-11 09:51:02,952 [logger]
# Response 
	< Response code: 200
	< Headers:
{
    "Access-Control-Allow-Origin": "*",
    "Cache-Control": "no-cache, no-store, max-age=0, must-revalidate",
    "Content-Security-Policy": "script-src 'sha256-F+lLIWNuYKlUuNZaPUz2Et6V08PYVCIgGrSCOOLPEGc='",
    "Content-Type": "application/json;charset=UTF-8",
    "Date": "Thu, 11 Jul 2019 07:51:02 GMT",
    "Expires": "0",
    "Pragma": "no-cache",
    "Referrer-Policy": "no-referrer",
    "Strict-Transport-Security": "max-age=315360000; includeSubdomains; preload",
    "Transfer-Encoding": "chunked",
    "X-Content-Type-Options": "nosniff",
    "X-Frame-Options": "SAMEORIGIN",
    "X-Xss-Protection": "1; mode=block"
}
	< Payload received:
{"access_token":"eyJraWQiOiI0ZjI0MzM3NTI2NThmYTBjMTg4ZDM2MTdmNmNjNDY5ZjQ5NzJiOWYiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZGVudGlmaWVyX2JvdW5kX3Njb3BlIjpbXSwiYXVkIjoiaHR0cHM6XC9cL2FwaS5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tIiwic3ViIjoiNTA3MzkiLCJwdXJwb3NlIjoiaWRlbnRpZnktY3VzdG9tZXIgZGV2aWNlLXJlY29tbWVuZGF0aW9ucy12MyBhdXJhLXJlYWQtaW5zaWdodC1ldmVudHMgc2ltLXVwZ3JhZGUtc3VnZ2VzdGlvbiBkZXRlY3QtYWJub3JtYWwtdXNhZ2UgY3VzdG9tZXItc2VsZi1zZXJ2aWNlIiwic2NvcGUiOiJldmVudC1sb3ctZGF0YS1yZWFkIGluc2lnaHRzLWRhdGEtdXNhZ2UtcmVzdWx0LXJlYWQgYXVyYWlkLXJlYWQgbW9iaWxlLWJhbGFuY2UtdHJhbnNmZXItd3JpdGUgd2Vidmlld3MtcGhvbmUtbnVtYmVyLXJlYWQgYW1vdW50LWR1ZS1waG9uZS1udW1iZXItcmVhZCBldmVudC1zdWJzY3JpcHRpb24tdHlwZS1taWdyYXRpb24tcmVhZCBhdXRoZW50aWNhdGlvbi1pbmZvcm1hdGlvbi1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtdXNlci1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcmVhZCBldmVudC1uby1kYXRhLXJlYWQgdGltZWxpbmUtcGhvbmUtbnVtYmVyLXJlYWQgbW9iaWxlLWJhbGFuY2UtcmVhZCBzdWJzY3JpYmVkLXByb2R1Y3RzLXJlYWQgZXZlbnQtbm8tYmFsYW5jZS1yZWFkIHN1YnNjcmliZWQtcHJvZHVjdHMtdXNlci1yZWFkIGludm9pY2luZy1waG9uZS1udW1iZXItcmVhZCBldmVudC1hcHBvaW50bWVudC1yZW1pbmRlci1yZWFkIGlzc3Vlcy11c2VyLXJlYWQgaXNzdWVzLXVzZXItY3JlYXRlIGNvbnN1bXB0aW9uLXVzZXItcmVhZCB1bnVzdWFsLWRhdGEtdXNhZ2UtcmVhZCBtb2JpbGUtcXVvdGEtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLWNyZWF0ZSBldmVudC11bnVzdWFsLWJhbGFuY2UtcmVhZCBldmVudC1oaWdoLXNwZW5kLWFsZXJ0LXJlYWQgbW9iaWxlLWJhbGFuY2UtdG9wLXVwLXdyaXRlIGludm9pY2luZy11c2VyLXJlYWQgaW5zaWdodHMtc2V0dXAtNGctcmVhZHktcmVhZCBpc3N1ZXMtY3JlYXRlIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcmVhZCBldmVudC1pbnZvaWNlLXJldGFpbmVkLXJlYWQgZXZlbnQtaW52b2ljZS1jaGFyZ2UtcmVhZCBwcm9kdWN0LW1hbmFnZW1lbnQtb3JkZXJzLXBob25lLW51bWJlci1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci1waG9uZS1udW1iZXItcmVhZCB1c2VycHJvZmlsZS1yZWFkIGluc2lnaHRzLWJhbGFuY2UtcmVzdWx0LXJlYWQgd2Vidmlld3MtdXNlci1yZWFkIGV2ZW50LWxvdy12b2ljZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcGhvbmUtbnVtYmVyLXJlYWQgaW5zaWdodHMtYmlsbGluZy1xdWVyaWVzLXJlc3VsdC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci1yZWFkIGV2ZW50LXVudXN1YWwtZGF0YS11c2FnZS1yZWFkIGV2ZW50LWJhci1hbGVydC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtd3JpdGUgZXZlbnQtaW52b2ljZS1kZWJpdC1yZWFkIGV2ZW50LXBheW1lbnQtYWxlcnQtcmVhZCBhdXJhaWQtd3JpdGUgYW1vdW50LWR1ZS11c2VyLXJlYWQgc3Vic2NyaWJlZC1wcm9kdWN0cy1waG9uZS1udW1iZXItcmVhZCBldmVudC1uby12b2ljZS1yZWFkIGV2ZW50LXVudXN1YWwtYmlsbGluZy1yZWFkIG5vdGlmaWNhdGlvbnMtcmVhZCB0aW1lbGluZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci13cml0ZSBub3RpZmljYXRpb24tZW1haWwtd3JpdGUgZXZlbnQtZGlzY29ubmVjdGlvbi1hbGVydC1yZWFkIGV2ZW50LWludm9pY2UtcGF5bWVudC1kdWUtcmVhZCBldmVudC1sb3ctYmFsYW5jZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcGhvbmUtbnVtYmVyLXdyaXRlIG5vdGlmaWNhdGlvbi1lbWFpbC1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci11c2VyLXJlYWQgY29uc3VtcHRpb24tcGhvbmUtbnVtYmVyLXJlYWQgdGltZWxpbmUtdXNlci1yZWFkIGFtb3VudC1kdWUtcmVhZCBtb2JpbGUtYmFsYW5jZS10b3AtdXAtcmVhZCBpbnZvaWNpbmctcmVhZCBpc3N1ZXMtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLXJlYWQiLCJpc3MiOiJodHRwczpcL1wvYXV0aC5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tXC8iLCJhY3RpdmUiOnRydWUsImV4cCI6MTU2MjgzNTA2MiwiaWF0IjoxNTYyODMxNDYyLCJjbGllbnRfaWQiOiJhdXJhLWJvdCIsImp0aSI6ImM0Y2NhN2M4LTdiMWUtNDMyMi1iNTFjLWRhYjQxOGEwNTgwMSJ9.OMLA5T8AMp8oSPZON8NcK6lvfWjI6beyXc8tGe7kKf9ZZLqTWK6b4I3ccS4IJ4uIVOi6KG53ueqojKBK4toHCAKnVMpLthiQlP4tG34Nd5TW21dRhqokX4a48LpQDZFadQVZq5wwGtiy9HIN3wxNGNje6FabX8NAnTAzVQuVHphtG5UoXHJDJ3LsUZ04pRLKRw6Vuza7Ct1igxYf7VkircwSszbVjGYuFFr23cwCY9YEDUbtACl68JUlUJLCWGUHTvasiGOAalf_-3EykEM8an7gMLyCXMYqJn2zPNgLJvmfiBBch_zNc-Qz7f8FeDdWJGwOgrXEkdCqwA0xSweroA","token_type":"Bearer","expires_in":3599,"scope":"event-low-data-read insights-data-usage-result-read auraid-read mobile-balance-transfer-write webviews-phone-number-read amount-due-phone-number-read event-subscription-type-migration-read authentication-information-read product-management-offers-user-read product-management-orders-read event-no-data-read timeline-phone-number-read mobile-balance-read subscribed-products-read event-no-balance-read subscribed-products-user-read invoicing-phone-number-read event-appointment-reminder-read issues-user-read issues-user-create consumption-user-read unusual-data-usage-read mobile-quota-read issues-phone-number-create event-unusual-balance-read event-high-spend-alert-read mobile-balance-top-up-write invoicing-user-read insights-setup-4g-ready-read issues-create product-management-offers-read event-invoice-retained-read event-invoice-charge-read product-management-orders-phone-number-read insights-device-recommender-phone-number-read userprofile-read insights-balance-result-read webviews-user-read event-low-voice-read product-management-offers-phone-number-read insights-billing-queries-result-read product-management-orders-user-read event-unusual-data-usage-read event-bar-alert-read product-management-orders-write event-invoice-debit-read event-payment-alert-read auraid-write amount-due-user-read subscribed-products-phone-number-read event-no-voice-read event-unusual-billing-read notifications-read timeline-read product-management-orders-user-write notification-email-write event-disconnection-alert-read event-invoice-payment-due-read event-low-balance-read product-management-orders-phone-number-write notification-email-read insights-device-recommender-user-read consumption-phone-number-read timeline-user-read amount-due-read mobile-balance-top-up-read invoicing-read issues-read issues-phone-number-read","purpose":"identify-customer device-recommendations-v3 aura-read-insight-events sim-upgrade-suggestion detect-abnormal-usage customer-self-service"}
DEBUG   2019-07-11 09:51:02,962 [connectionpool] Starting new HTTPS connection (1): api.co-pre.baikalplatform.com
DEBUG   2019-07-11 09:51:09,139 [connectionpool] https://api.co-pre.baikalplatform.com:443 "GET /userprofile/v3/users/50739 HTTP/1.1" 200 1144
INFO    2019-07-11 09:51:09,142 [data_4p] >>>>>>>>>>>>>>>>>>>>> Request 4TH PLATFORM >>>>>>>>>>>>>>>>>>>
INFO    2019-07-11 09:51:09,142 [data_4p] curl -s -H "Authorization: Bearer eyJraWQiOiI0ZjI0MzM3NTI2NThmYTBjMTg4ZDM2MTdmNmNjNDY5ZjQ5NzJiOWYiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZGVudGlmaWVyX2JvdW5kX3Njb3BlIjpbXSwiYXVkIjoiaHR0cHM6XC9cL2FwaS5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tIiwic3ViIjoiNTA3MzkiLCJwdXJwb3NlIjoiaWRlbnRpZnktY3VzdG9tZXIgZGV2aWNlLXJlY29tbWVuZGF0aW9ucy12MyBhdXJhLXJlYWQtaW5zaWdodC1ldmVudHMgc2ltLXVwZ3JhZGUtc3VnZ2VzdGlvbiBkZXRlY3QtYWJub3JtYWwtdXNhZ2UgY3VzdG9tZXItc2VsZi1zZXJ2aWNlIiwic2NvcGUiOiJldmVudC1sb3ctZGF0YS1yZWFkIGluc2lnaHRzLWRhdGEtdXNhZ2UtcmVzdWx0LXJlYWQgYXVyYWlkLXJlYWQgbW9iaWxlLWJhbGFuY2UtdHJhbnNmZXItd3JpdGUgd2Vidmlld3MtcGhvbmUtbnVtYmVyLXJlYWQgYW1vdW50LWR1ZS1waG9uZS1udW1iZXItcmVhZCBldmVudC1zdWJzY3JpcHRpb24tdHlwZS1taWdyYXRpb24tcmVhZCBhdXRoZW50aWNhdGlvbi1pbmZvcm1hdGlvbi1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtdXNlci1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcmVhZCBldmVudC1uby1kYXRhLXJlYWQgdGltZWxpbmUtcGhvbmUtbnVtYmVyLXJlYWQgbW9iaWxlLWJhbGFuY2UtcmVhZCBzdWJzY3JpYmVkLXByb2R1Y3RzLXJlYWQgZXZlbnQtbm8tYmFsYW5jZS1yZWFkIHN1YnNjcmliZWQtcHJvZHVjdHMtdXNlci1yZWFkIGludm9pY2luZy1waG9uZS1udW1iZXItcmVhZCBldmVudC1hcHBvaW50bWVudC1yZW1pbmRlci1yZWFkIGlzc3Vlcy11c2VyLXJlYWQgaXNzdWVzLXVzZXItY3JlYXRlIGNvbnN1bXB0aW9uLXVzZXItcmVhZCB1bnVzdWFsLWRhdGEtdXNhZ2UtcmVhZCBtb2JpbGUtcXVvdGEtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLWNyZWF0ZSBldmVudC11bnVzdWFsLWJhbGFuY2UtcmVhZCBldmVudC1oaWdoLXNwZW5kLWFsZXJ0LXJlYWQgbW9iaWxlLWJhbGFuY2UtdG9wLXVwLXdyaXRlIGludm9pY2luZy11c2VyLXJlYWQgaW5zaWdodHMtc2V0dXAtNGctcmVhZHktcmVhZCBpc3N1ZXMtY3JlYXRlIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcmVhZCBldmVudC1pbnZvaWNlLXJldGFpbmVkLXJlYWQgZXZlbnQtaW52b2ljZS1jaGFyZ2UtcmVhZCBwcm9kdWN0LW1hbmFnZW1lbnQtb3JkZXJzLXBob25lLW51bWJlci1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci1waG9uZS1udW1iZXItcmVhZCB1c2VycHJvZmlsZS1yZWFkIGluc2lnaHRzLWJhbGFuY2UtcmVzdWx0LXJlYWQgd2Vidmlld3MtdXNlci1yZWFkIGV2ZW50LWxvdy12b2ljZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcGhvbmUtbnVtYmVyLXJlYWQgaW5zaWdodHMtYmlsbGluZy1xdWVyaWVzLXJlc3VsdC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci1yZWFkIGV2ZW50LXVudXN1YWwtZGF0YS11c2FnZS1yZWFkIGV2ZW50LWJhci1hbGVydC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtd3JpdGUgZXZlbnQtaW52b2ljZS1kZWJpdC1yZWFkIGV2ZW50LXBheW1lbnQtYWxlcnQtcmVhZCBhdXJhaWQtd3JpdGUgYW1vdW50LWR1ZS11c2VyLXJlYWQgc3Vic2NyaWJlZC1wcm9kdWN0cy1waG9uZS1udW1iZXItcmVhZCBldmVudC1uby12b2ljZS1yZWFkIGV2ZW50LXVudXN1YWwtYmlsbGluZy1yZWFkIG5vdGlmaWNhdGlvbnMtcmVhZCB0aW1lbGluZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci13cml0ZSBub3RpZmljYXRpb24tZW1haWwtd3JpdGUgZXZlbnQtZGlzY29ubmVjdGlvbi1hbGVydC1yZWFkIGV2ZW50LWludm9pY2UtcGF5bWVudC1kdWUtcmVhZCBldmVudC1sb3ctYmFsYW5jZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcGhvbmUtbnVtYmVyLXdyaXRlIG5vdGlmaWNhdGlvbi1lbWFpbC1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci11c2VyLXJlYWQgY29uc3VtcHRpb24tcGhvbmUtbnVtYmVyLXJlYWQgdGltZWxpbmUtdXNlci1yZWFkIGFtb3VudC1kdWUtcmVhZCBtb2JpbGUtYmFsYW5jZS10b3AtdXAtcmVhZCBpbnZvaWNpbmctcmVhZCBpc3N1ZXMtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLXJlYWQiLCJpc3MiOiJodHRwczpcL1wvYXV0aC5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tXC8iLCJhY3RpdmUiOnRydWUsImV4cCI6MTU2MjgzNTA2MiwiaWF0IjoxNTYyODMxNDYyLCJjbGllbnRfaWQiOiJhdXJhLWJvdCIsImp0aSI6ImM0Y2NhN2M4LTdiMWUtNDMyMi1iNTFjLWRhYjQxOGEwNTgwMSJ9.OMLA5T8AMp8oSPZON8NcK6lvfWjI6beyXc8tGe7kKf9ZZLqTWK6b4I3ccS4IJ4uIVOi6KG53ueqojKBK4toHCAKnVMpLthiQlP4tG34Nd5TW21dRhqokX4a48LpQDZFadQVZq5wwGtiy9HIN3wxNGNje6FabX8NAnTAzVQuVHphtG5UoXHJDJ3LsUZ04pRLKRw6Vuza7Ct1igxYf7VkircwSszbVjGYuFFr23cwCY9YEDUbtACl68JUlUJLCWGUHTvasiGOAalf_-3EykEM8an7gMLyCXMYqJn2zPNgLJvmfiBBch_zNc-Qz7f8FeDdWJGwOgrXEkdCqwA0xSweroA" --proxy http://proxytid.hi.inet:8080 "https://api.co-pre.baikalplatform.com/userprofile/v3/users/50739"
INFO    2019-07-11 09:51:09,142 [data_4p] >>>>>>>>>>>>>>>>>>>>> Response 4TH PLATFORM >>>>>>>>>>>>>>>>>>>
INFO    2019-07-11 09:51:09,142 [data_4p] status: 200, reason: OK
INFO    2019-07-11 09:51:09,142 [data_4p] data: {u'id_document': {u'country': u'CO', u'type': u'CC', u'value': u'1049615041'}, u'identities': [{u'services': [u'mobile_postpaid'], u'type': u'phone_number', u'id': u'+573182529375', u'roles': [u'owner']}, {u'services': [u'mobile_prepaid'], u'type': u'phone_number', u'id': u'+573142182110', u'roles': [u'owner']}, {u'services': [u'mobile_postpaid'], u'type': u'phone_number', u'id': u'+573132709928', u'roles': [u'owner']}, {u'services': [u'mobile_postpaid'], u'type': u'phone_number', u'id': u'+573005271795', u'roles': [u'owner']}, {u'services': [u'mobile_postpaid'], u'type': u'phone_number', u'id': u'+573114591615', u'roles': [u'owner']}, {u'services': [u'mobile_postpaid'], u'type': u'phone_number', u'id': u'+573167412035', u'roles': [u'owner']}, {u'services': [u'mobile_postpaid'], u'type': u'phone_number', u'id': u'+573166905565', u'roles': [u'owner']}, {u'services': [u'internet', u'landline'], u'type': u'phone_number', u'id': u'+5787457006', u'roles': [u'owner', u'user']}, {u'services': [u'dth'], u'type': u'uid', u'id': u'TV_93994162_2', u'roles': [u'owner', u'user']}, {u'services': [u'dth'], u'type': u'uid', u'id': u'TV_108879147_2', u'roles': [u'owner', u'user']}, {u'services': [u'email'], u'type': u'email', u'id': u'jcamiloct-9412@hotmail.com', u'roles': [u'owner']}], u'id': u'50739', u'name': u'ERIKA JURIETH VASQUEZ MARTINEZ'}
DEBUG   2019-07-11 09:51:09,155 [connectionpool] Starting new HTTPS connection (1): api.co-pre.baikalplatform.com
DEBUG   2019-07-11 09:51:11,094 [connectionpool] https://api.co-pre.baikalplatform.com:443 "GET /subscribed_products/v2/phone_numbers/+573167412035/products HTTP/1.1" 200 2999
INFO    2019-07-11 09:51:11,097 [data_4p] >>>>>>>>>>>>>>>>>>>>> Request 4TH PLATFORM >>>>>>>>>>>>>>>>>>>
INFO    2019-07-11 09:51:11,097 [data_4p] curl -s -H "Authorization: Bearer eyJraWQiOiI0ZjI0MzM3NTI2NThmYTBjMTg4ZDM2MTdmNmNjNDY5ZjQ5NzJiOWYiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZGVudGlmaWVyX2JvdW5kX3Njb3BlIjpbXSwiYXVkIjoiaHR0cHM6XC9cL2FwaS5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tIiwic3ViIjoiNTA3MzkiLCJwdXJwb3NlIjoiaWRlbnRpZnktY3VzdG9tZXIgZGV2aWNlLXJlY29tbWVuZGF0aW9ucy12MyBhdXJhLXJlYWQtaW5zaWdodC1ldmVudHMgc2ltLXVwZ3JhZGUtc3VnZ2VzdGlvbiBkZXRlY3QtYWJub3JtYWwtdXNhZ2UgY3VzdG9tZXItc2VsZi1zZXJ2aWNlIiwic2NvcGUiOiJldmVudC1sb3ctZGF0YS1yZWFkIGluc2lnaHRzLWRhdGEtdXNhZ2UtcmVzdWx0LXJlYWQgYXVyYWlkLXJlYWQgbW9iaWxlLWJhbGFuY2UtdHJhbnNmZXItd3JpdGUgd2Vidmlld3MtcGhvbmUtbnVtYmVyLXJlYWQgYW1vdW50LWR1ZS1waG9uZS1udW1iZXItcmVhZCBldmVudC1zdWJzY3JpcHRpb24tdHlwZS1taWdyYXRpb24tcmVhZCBhdXRoZW50aWNhdGlvbi1pbmZvcm1hdGlvbi1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtdXNlci1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcmVhZCBldmVudC1uby1kYXRhLXJlYWQgdGltZWxpbmUtcGhvbmUtbnVtYmVyLXJlYWQgbW9iaWxlLWJhbGFuY2UtcmVhZCBzdWJzY3JpYmVkLXByb2R1Y3RzLXJlYWQgZXZlbnQtbm8tYmFsYW5jZS1yZWFkIHN1YnNjcmliZWQtcHJvZHVjdHMtdXNlci1yZWFkIGludm9pY2luZy1waG9uZS1udW1iZXItcmVhZCBldmVudC1hcHBvaW50bWVudC1yZW1pbmRlci1yZWFkIGlzc3Vlcy11c2VyLXJlYWQgaXNzdWVzLXVzZXItY3JlYXRlIGNvbnN1bXB0aW9uLXVzZXItcmVhZCB1bnVzdWFsLWRhdGEtdXNhZ2UtcmVhZCBtb2JpbGUtcXVvdGEtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLWNyZWF0ZSBldmVudC11bnVzdWFsLWJhbGFuY2UtcmVhZCBldmVudC1oaWdoLXNwZW5kLWFsZXJ0LXJlYWQgbW9iaWxlLWJhbGFuY2UtdG9wLXVwLXdyaXRlIGludm9pY2luZy11c2VyLXJlYWQgaW5zaWdodHMtc2V0dXAtNGctcmVhZHktcmVhZCBpc3N1ZXMtY3JlYXRlIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcmVhZCBldmVudC1pbnZvaWNlLXJldGFpbmVkLXJlYWQgZXZlbnQtaW52b2ljZS1jaGFyZ2UtcmVhZCBwcm9kdWN0LW1hbmFnZW1lbnQtb3JkZXJzLXBob25lLW51bWJlci1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci1waG9uZS1udW1iZXItcmVhZCB1c2VycHJvZmlsZS1yZWFkIGluc2lnaHRzLWJhbGFuY2UtcmVzdWx0LXJlYWQgd2Vidmlld3MtdXNlci1yZWFkIGV2ZW50LWxvdy12b2ljZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcGhvbmUtbnVtYmVyLXJlYWQgaW5zaWdodHMtYmlsbGluZy1xdWVyaWVzLXJlc3VsdC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci1yZWFkIGV2ZW50LXVudXN1YWwtZGF0YS11c2FnZS1yZWFkIGV2ZW50LWJhci1hbGVydC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtd3JpdGUgZXZlbnQtaW52b2ljZS1kZWJpdC1yZWFkIGV2ZW50LXBheW1lbnQtYWxlcnQtcmVhZCBhdXJhaWQtd3JpdGUgYW1vdW50LWR1ZS11c2VyLXJlYWQgc3Vic2NyaWJlZC1wcm9kdWN0cy1waG9uZS1udW1iZXItcmVhZCBldmVudC1uby12b2ljZS1yZWFkIGV2ZW50LXVudXN1YWwtYmlsbGluZy1yZWFkIG5vdGlmaWNhdGlvbnMtcmVhZCB0aW1lbGluZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci13cml0ZSBub3RpZmljYXRpb24tZW1haWwtd3JpdGUgZXZlbnQtZGlzY29ubmVjdGlvbi1hbGVydC1yZWFkIGV2ZW50LWludm9pY2UtcGF5bWVudC1kdWUtcmVhZCBldmVudC1sb3ctYmFsYW5jZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcGhvbmUtbnVtYmVyLXdyaXRlIG5vdGlmaWNhdGlvbi1lbWFpbC1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci11c2VyLXJlYWQgY29uc3VtcHRpb24tcGhvbmUtbnVtYmVyLXJlYWQgdGltZWxpbmUtdXNlci1yZWFkIGFtb3VudC1kdWUtcmVhZCBtb2JpbGUtYmFsYW5jZS10b3AtdXAtcmVhZCBpbnZvaWNpbmctcmVhZCBpc3N1ZXMtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLXJlYWQiLCJpc3MiOiJodHRwczpcL1wvYXV0aC5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tXC8iLCJhY3RpdmUiOnRydWUsImV4cCI6MTU2MjgzNTA2MiwiaWF0IjoxNTYyODMxNDYyLCJjbGllbnRfaWQiOiJhdXJhLWJvdCIsImp0aSI6ImM0Y2NhN2M4LTdiMWUtNDMyMi1iNTFjLWRhYjQxOGEwNTgwMSJ9.OMLA5T8AMp8oSPZON8NcK6lvfWjI6beyXc8tGe7kKf9ZZLqTWK6b4I3ccS4IJ4uIVOi6KG53ueqojKBK4toHCAKnVMpLthiQlP4tG34Nd5TW21dRhqokX4a48LpQDZFadQVZq5wwGtiy9HIN3wxNGNje6FabX8NAnTAzVQuVHphtG5UoXHJDJ3LsUZ04pRLKRw6Vuza7Ct1igxYf7VkircwSszbVjGYuFFr23cwCY9YEDUbtACl68JUlUJLCWGUHTvasiGOAalf_-3EykEM8an7gMLyCXMYqJn2zPNgLJvmfiBBch_zNc-Qz7f8FeDdWJGwOgrXEkdCqwA0xSweroA" --proxy http://proxytid.hi.inet:8080 "https://api.co-pre.baikalplatform.com/subscribed_products/v2/phone_numbers/+573167412035/products"
INFO    2019-07-11 09:51:11,097 [data_4p] >>>>>>>>>>>>>>>>>>>>> Response 4TH PLATFORM >>>>>>>>>>>>>>>>>>>
INFO    2019-07-11 09:51:11,098 [data_4p] status: 200, reason: OK
INFO    2019-07-11 09:51:11,098 [data_4p] data: [{u'phone_number': u'+573167412035', u'product_type': u'bundle', u'subscription_type': u'postpaid', u'price': {u'currency': u'COP', u'amount': 98990.0}, u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'Mas Gigas: 28GB para navegar en internet+Min y sms ilimitados a todo destino nal+500 min LDI USA, Canada y Pto Rico+FamiliayAmigos+Movistar play lite+Cloud'}], u'sub_products': [{u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'Movistar Play'}], u'display_name': u'Movistar play', u'id': u'GMEHPLP4PE3NTFG9F8'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'Waze'}], u'display_name': u'Waze', u'id': u'XBKIIAUUKCH7R75PWH'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'PAQUETE CHAT FACEBOOK INCLUIDO 10MB'}], u'display_name': u'Facebook', u'id': u'E61F2UBOMK7NUDYIII'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'250 MB'}], u'display_name': u'Whatsapp', u'id': u'CMF7NEFWLRAGNP5VCA'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'cloud '}], u'display_name': u'Movistar Cloud ', u'id': u'JYRESC775YDJYN2KUD'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'5 x 1 Familia Movistar'}], u'display_name': u'5 x 1 Familia Movistar', u'id': u'C3P6PA9QCNA90CKIZ8'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'120 MB'}], u'display_name': u'Twitter', u'id': u'WLN3NHWR9W0C9XUMS8'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'Movistar m\ufffd\ufffdsica'}], u'display_name': u'Movistar Musica', u'id': u'NDZOB87DVQI0681VMP'}, {u'phone_number': u'+573167412035', u'product_type': u'value_added_service', u'subscription_type': u'postpaid', u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'Movistar play lite'}], u'display_name': u'Movistar play Lite', u'id': u'19V0VDYPRIGTM3HLK4'}, {u'phone_number': u'+573167412035', u'product_type': u'mobile', u'subscription_type': u'postpaid', u'quota': {u'max_sms': -1, u'data_max_bytes': 29360128000, u'voice_max_seconds': -1}, u'start_date': u'2017-01-05T19:00:00Z', u'descriptions': [{u'text': u'Mas Gigas: 28GB para navegar en internet+Min y sms ilimitados a todo destino nal+500 min LDI USA, Canada y Pto Rico+FamiliayAmigos+Movistar play lite+Cloud'}], u'display_name': u'SIN CONTROL MIN + DATOS_2016', u'id': u'2016'}], u'display_name': u'SIN CONTROL MIN + DATOS_2016', u'id': u'2016'}]
DEBUG   2019-07-11 09:51:11,107 [connectionpool] Starting new HTTPS connection (1): api.co-pre.baikalplatform.com
DEBUG   2019-07-11 09:51:13,657 [connectionpool] https://api.co-pre.baikalplatform.com:443 "GET /mobile_balance/v2/phone_numbers/+573167412035/balance HTTP/1.1" 500 53
INFO    2019-07-11 09:51:39,975 [data_4p] >>>>>>>>>>>>>>>>>>>>> Request 4TH PLATFORM >>>>>>>>>>>>>>>>>>>
INFO    2019-07-11 09:51:39,975 [data_4p] curl -s -H "Authorization: Bearer eyJraWQiOiI0ZjI0MzM3NTI2NThmYTBjMTg4ZDM2MTdmNmNjNDY5ZjQ5NzJiOWYiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZGVudGlmaWVyX2JvdW5kX3Njb3BlIjpbXSwiYXVkIjoiaHR0cHM6XC9cL2FwaS5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tIiwic3ViIjoiNTA3MzkiLCJwdXJwb3NlIjoiaWRlbnRpZnktY3VzdG9tZXIgZGV2aWNlLXJlY29tbWVuZGF0aW9ucy12MyBhdXJhLXJlYWQtaW5zaWdodC1ldmVudHMgc2ltLXVwZ3JhZGUtc3VnZ2VzdGlvbiBkZXRlY3QtYWJub3JtYWwtdXNhZ2UgY3VzdG9tZXItc2VsZi1zZXJ2aWNlIiwic2NvcGUiOiJldmVudC1sb3ctZGF0YS1yZWFkIGluc2lnaHRzLWRhdGEtdXNhZ2UtcmVzdWx0LXJlYWQgYXVyYWlkLXJlYWQgbW9iaWxlLWJhbGFuY2UtdHJhbnNmZXItd3JpdGUgd2Vidmlld3MtcGhvbmUtbnVtYmVyLXJlYWQgYW1vdW50LWR1ZS1waG9uZS1udW1iZXItcmVhZCBldmVudC1zdWJzY3JpcHRpb24tdHlwZS1taWdyYXRpb24tcmVhZCBhdXRoZW50aWNhdGlvbi1pbmZvcm1hdGlvbi1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtdXNlci1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcmVhZCBldmVudC1uby1kYXRhLXJlYWQgdGltZWxpbmUtcGhvbmUtbnVtYmVyLXJlYWQgbW9iaWxlLWJhbGFuY2UtcmVhZCBzdWJzY3JpYmVkLXByb2R1Y3RzLXJlYWQgZXZlbnQtbm8tYmFsYW5jZS1yZWFkIHN1YnNjcmliZWQtcHJvZHVjdHMtdXNlci1yZWFkIGludm9pY2luZy1waG9uZS1udW1iZXItcmVhZCBldmVudC1hcHBvaW50bWVudC1yZW1pbmRlci1yZWFkIGlzc3Vlcy11c2VyLXJlYWQgaXNzdWVzLXVzZXItY3JlYXRlIGNvbnN1bXB0aW9uLXVzZXItcmVhZCB1bnVzdWFsLWRhdGEtdXNhZ2UtcmVhZCBtb2JpbGUtcXVvdGEtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLWNyZWF0ZSBldmVudC11bnVzdWFsLWJhbGFuY2UtcmVhZCBldmVudC1oaWdoLXNwZW5kLWFsZXJ0LXJlYWQgbW9iaWxlLWJhbGFuY2UtdG9wLXVwLXdyaXRlIGludm9pY2luZy11c2VyLXJlYWQgaW5zaWdodHMtc2V0dXAtNGctcmVhZHktcmVhZCBpc3N1ZXMtY3JlYXRlIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcmVhZCBldmVudC1pbnZvaWNlLXJldGFpbmVkLXJlYWQgZXZlbnQtaW52b2ljZS1jaGFyZ2UtcmVhZCBwcm9kdWN0LW1hbmFnZW1lbnQtb3JkZXJzLXBob25lLW51bWJlci1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci1waG9uZS1udW1iZXItcmVhZCB1c2VycHJvZmlsZS1yZWFkIGluc2lnaHRzLWJhbGFuY2UtcmVzdWx0LXJlYWQgd2Vidmlld3MtdXNlci1yZWFkIGV2ZW50LWxvdy12b2ljZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vZmZlcnMtcGhvbmUtbnVtYmVyLXJlYWQgaW5zaWdodHMtYmlsbGluZy1xdWVyaWVzLXJlc3VsdC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci1yZWFkIGV2ZW50LXVudXN1YWwtZGF0YS11c2FnZS1yZWFkIGV2ZW50LWJhci1hbGVydC1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtd3JpdGUgZXZlbnQtaW52b2ljZS1kZWJpdC1yZWFkIGV2ZW50LXBheW1lbnQtYWxlcnQtcmVhZCBhdXJhaWQtd3JpdGUgYW1vdW50LWR1ZS11c2VyLXJlYWQgc3Vic2NyaWJlZC1wcm9kdWN0cy1waG9uZS1udW1iZXItcmVhZCBldmVudC1uby12b2ljZS1yZWFkIGV2ZW50LXVudXN1YWwtYmlsbGluZy1yZWFkIG5vdGlmaWNhdGlvbnMtcmVhZCB0aW1lbGluZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtdXNlci13cml0ZSBub3RpZmljYXRpb24tZW1haWwtd3JpdGUgZXZlbnQtZGlzY29ubmVjdGlvbi1hbGVydC1yZWFkIGV2ZW50LWludm9pY2UtcGF5bWVudC1kdWUtcmVhZCBldmVudC1sb3ctYmFsYW5jZS1yZWFkIHByb2R1Y3QtbWFuYWdlbWVudC1vcmRlcnMtcGhvbmUtbnVtYmVyLXdyaXRlIG5vdGlmaWNhdGlvbi1lbWFpbC1yZWFkIGluc2lnaHRzLWRldmljZS1yZWNvbW1lbmRlci11c2VyLXJlYWQgY29uc3VtcHRpb24tcGhvbmUtbnVtYmVyLXJlYWQgdGltZWxpbmUtdXNlci1yZWFkIGFtb3VudC1kdWUtcmVhZCBtb2JpbGUtYmFsYW5jZS10b3AtdXAtcmVhZCBpbnZvaWNpbmctcmVhZCBpc3N1ZXMtcmVhZCBpc3N1ZXMtcGhvbmUtbnVtYmVyLXJlYWQiLCJpc3MiOiJodHRwczpcL1wvYXV0aC5jby1wcmUuYmFpa2FscGxhdGZvcm0uY29tXC8iLCJhY3RpdmUiOnRydWUsImV4cCI6MTU2MjgzNTA2MiwiaWF0IjoxNTYyODMxNDYyLCJjbGllbnRfaWQiOiJhdXJhLWJvdCIsImp0aSI6ImM0Y2NhN2M4LTdiMWUtNDMyMi1iNTFjLWRhYjQxOGEwNTgwMSJ9.OMLA5T8AMp8oSPZON8NcK6lvfWjI6beyXc8tGe7kKf9ZZLqTWK6b4I3ccS4IJ4uIVOi6KG53ueqojKBK4toHCAKnVMpLthiQlP4tG34Nd5TW21dRhqokX4a48LpQDZFadQVZq5wwGtiy9HIN3wxNGNje6FabX8NAnTAzVQuVHphtG5UoXHJDJ3LsUZ04pRLKRw6Vuza7Ct1igxYf7VkircwSszbVjGYuFFr23cwCY9YEDUbtACl68JUlUJLCWGUHTvasiGOAalf_-3EykEM8an7gMLyCXMYqJn2zPNgLJvmfiBBch_zNc-Qz7f8FeDdWJGwOgrXEkdCqwA0xSweroA" --proxy http://proxytid.hi.inet:8080 "https://api.co-pre.baikalplatform.com/mobile_quota/v2/phone_numbers/+573167412035/quota"
INFO    2019-07-11 09:51:39,976 [data_4p] >>>>>>>>>>>>>>>>>>>>> Response 4TH PLATFORM >>>>>>>>>>>>>>>>>>>
INFO    2019-07-11 09:51:39,976 [data_4p] status: 200, reason: OK
INFO    2019-07-11 09:51:39,976 [data_4p] data: {u'phone_number': u'+573167412035', u'sms': [], u'voice': [{u'time_bands': [u'all'], u'description': u'LDI', u'end_date': u'2038-01-02T04:59:59Z', u'consumed_seconds': 0, u'origins': [u'home'], u'max_seconds': 30000, u'start_date': u'2018-05-24T11:08:43Z', u'destinations': [u'national']}], u'data': [{u'time_bands': [u'all'], u'consumed_bytes': 2040109465, u'description': u'Datos', u'end_date': u'2038-01-02T04:59:59Z', u'origins': [u'home'], u'max_bytes': 30064771072, u'start_date': u'2018-10-06T01:11:29Z'}]}
DEBUG   2019-07-11 09:51:39,985 [connectionpool] Starting new HTTPS connection (1): api.co-pre.baikalplatform.com
DEBUG   2019-07-11 09:51:40,519 [connectionpool] https://api.co-pre.baikalplatform.com:443 "GET /insights/data_usage_result/v2/users/50739 HTTP/1.1" 404 47
..........
DEBUG   2019-07-11 09:51:40,552 [connectionpool] Starting new HTTPS connection (1): ai-pre-co.auracognitive.com
DEBUG   2019-07-11 09:51:41,122 [connectionpool] https://ai-pre-co.auracognitive.com:443 "GET /v1/kv/config/pre_co/aura-bot/FPA_SUBSCRIBED_PRODUCTS_ENDPOINT HTTP/1.1" 200 218
ERROR   2019-07-11 09:51:41,130 [configuration] Mapping chain not found in the configuration properties file or given json structure. 'mock.url'
INFO    2019-07-11 09:51:41,150 [authentication] JWT: {'nonce': '1fa324asxqdsf', 'acr': '3', 'sub': u'50739', 'name': 'QA user', 'iat': 1562831501, 'iss': u'https://ai-services-pre-co.auracognitive.com/aura-services/v1/openid/issuer/', 'exp': 1562832501, 'amr': ['sms'], 'authentication_context': [{'identifier': u'+573167412035', 'type': u'phone_number'}], 'aud': [u'https://api.co-pre.baikalplatform.com']}
INFO    2019-07-11 09:51:43,834 [configuration] Mapping language param 'data_usage.question' to its configured value '{'en-gb': 'why do i experience slower speed when i browse?', 'es-ar': u'\xbfComprobar el uso actual de mi plan de datos m\xf3viles?', 'de-de': 'Zeig mir meinen Verbrauch vom Datenvolumen', 'es-cl': 'Consumo de datos', 'es-co': 'Consumo de datos actual', 'pt-br': u'Quantos dados celulares tenho dispon\xedveis?'}'
DEBUG   2019-07-11 09:51:43,837 [activities] Question asked: Consumo de datos actual
DEBUG   2019-07-11 09:51:43,866 [logger]
>>>>>>>>>>>>>>>>>>>>> Request >>>>>>>>>>>>>>>>>>>
	> Method: POST
	> Url: https://directline.botframework.com/v3/directline/conversations/Je9bvMoUJQa6qWPKf89xCd-j/activities
	> Headers:
{
    "Authorization": "Bearer ew0KICAiYWxnIjogIlJTMjU2IiwNCiAgImtpZCI6ICJBT08tZXhGd2puR3lDTEJhOTgwVkxOME1tUTgiLA0KICAieDV0IjogIkFPTy1leEZ3am5HeUNMQmE5ODBWTE4wTW1ROCIsDQogICJ0eXAiOiAiSldUIg0KfQ.ew0KICAiYm90IjogIkJPVC1hdXJhLXByZS1jbyIsDQogICJzaXRlIjogIjRndnB0b29xZTBZIiwNCiAgImNvbnYiOiAiSmU5YnZNb1VKUWE2cVdQS2Y4OXhDZC1qIiwNCiAgIm5iZiI6IDE1NjI4MzE1MDIsDQogICJleHAiOiAxNTYyODM1MTAyLA0KICAiaXNzIjogImh0dHBzOi8vZGlyZWN0bGluZS5ib3RmcmFtZXdvcmsuY29tLyIsDQogICJhdWQiOiAiaHR0cHM6Ly9kaXJlY3RsaW5lLmJvdGZyYW1ld29yay5jb20vIg0KfQ.iQD6tVTKV2EYH70fBJIl10WwNh3h-1zM4ZTivsT4kZCfLDf67nG8-kmrLkcqme-ZaWDkkoPcJFLMLdthJo26Ef0KkVc9-eFZ7B5Su4z_m2vEiDWAuEP7AF7dQuYNBncMQ2PSq5jaeWz2xtbOwjbVOE2KeakkiaJhLvhQnZCRF7a7Jm7qXaH49VB3EQEef4cHjb6fY22YRMYhTPm8eCR_H4VcKAsff-Zw4qxUCShZ36FQRu1psZ1bbTBlgYyv04j0ix_0eUtGnA7a1aDFc5W9f2umcO-2TE3HBUmRtJcUcYnaqtEQIXoVe83ltBq_MvzXxJvyo3Hy5P6ZHWs8irMCdQ",
    "Content-Type": "application/json"
}
	> Payload sent:
{"text": "Consumo de datos actual", "channelData": {"imageMaxWidth": 480, "version": "0.3", "auraMode": {"fullAura": {"cards": "none", "voice": false}}, "allowed": ["commands", "handover"]}, "from": {"id": "26e29273-e928-4408-add1-b6bf0b499240", "name": "+573167412035"}, "type": "message", "timestamp": "Thu Jul 11 09:51:43 GMT+0200 2019"}
DEBUG   2019-07-11 09:51:43,867 [connectionpool] Starting new HTTPS connection (1): directline.botframework.com
DEBUG   2019-07-11 09:51:44,502 [connectionpool] https://directline.botframework.com:443 "POST /v3/directline/conversations/Je9bvMoUJQa6qWPKf89xCd-j/activities HTTP/1.1" 200 48
DEBUG   2019-07-11 09:51:44,512 [logger]
# Response 
	< Response code: 200
	< Headers:
{
    "Cache-Control": "no-cache",
    "Content-Length": "48",
    "Content-Type": "application/json; charset=utf-8",
    "Date": "Thu, 11 Jul 2019 07:51:44 GMT",
    "Expires": "-1",
    "Pragma": "no-cache",
    "Server": "Microsoft-IIS/10.0",
    "Strict-Transport-Security": "max-age=31536000",
    "x-ms-request-id": "|9cee4d1ebbcba0498d98da30e7c97348.9f932b10_"
}
	< Payload received:
{
  "id": "Je9bvMoUJQa6qWPKf89xCd-j|0000000"
}
INFO    2019-07-11 09:51:44,519 [activities] Getting bot response calling to activities endpoint
DEBUG   2019-07-11 09:52:08,347 [helpers]
# Response 
	< Response code: 200
	< Headers:
{
    "Cache-Control": "no-cache",
    "Content-Length": "5902",
    "Content-Type": "application/json; charset=utf-8",
    "Date": "Thu, 11 Jul 2019 07:52:06 GMT",
    "Expires": "-1",
    "Pragma": "no-cache",
    "Server": "Microsoft-IIS/10.0",
    "Strict-Transport-Security": "max-age=31536000",
    "x-ms-request-id": "|0afa06490259db4eaa4e31e8692fe060.2854829f_"
}
	< Payload received:
{
    "activities": [
        {
            "channelData": {
                "allowed": [
                    "commands",
                    "handover"
                ],
                "auraMode": {
                    "fullAura": {
                        "cards": "none",
                        "voice": false
                    }
                },
                "imageMaxWidth": 480,
                "version": "0.3"
            },
            "channelId": "directline",
            "conversation": {
                "id": "Je9bvMoUJQa6qWPKf89xCd-j"
            },
            "from": {
                "id": "26e29273-e928-4408-add1-b6bf0b499240",
                "name": "+573167412035"
            },
            "id": "Je9bvMoUJQa6qWPKf89xCd-j|0000000",
            "serviceUrl": "https://directline.botframework.com/",
            "text": "Consumo de datos actual",
            "timestamp": "2019-07-11T07:51:43.9546337Z",
            "type": "message"
        },
        {
            "channelData": {
                "hasMoreMessages": true
            },
            "channelId": "directline",
            "conversation": {
                "id": "Je9bvMoUJQa6qWPKf89xCd-j"
            },
            "from": {
                "id": "BOT-aura-pre-co",
                "name": "BOT-aura-pre-co"
            },
            "id": "Je9bvMoUJQa6qWPKf89xCd-j|0000001",
            "inputHint": "ignoringInput",
            "localTimestamp": "2019-07-11T07:51:48.562+00:00",
            "replyToId": "Je9bvMoUJQa6qWPKf89xCd-j|0000000",
            "text": "Te quedan 26.10 GB de datos de tu plan de 28 GB, hasta el 01/01/2038",
            "timestamp": "2019-07-11T07:51:48.6310043Z",
            "type": "message"
        },
        {
            "attachmentLayout": "carousel",
            "attachments": [
                {
                    "content": {
                        "actions": [
                            {
                                "title": "M\u00e1s detalles",
                                "type": "Action.OpenUrl",
                                "url": "https://web.movistar.com.co/_/account/redirect.php?target=subscription-dashboard"
                            }
                        ],
                        "body": [
                            {
                                "columns": [
                                    {
                                        "items": [
                                            {
                                                "type": "Image",
                                                "url": "https://stgfunctionspreco.blob.core.windows.net/static-resources/images/icn_assistant_data.png?sr=c&si=static-resources-policy-pre-co&sig=MkKm0NeX8MXcOU1qUtDqtepQusrnHh4YMDmOEvrUS4U%3D&sv=2018-03-28"
                                            }
                                        ],
                                        "type": "Column",
                                        "width": "auto"
                                    },
                                    {
                                        "items": [
                                            {
                                                "size": "medium",
                                                "text": "Datos",
                                                "type": "TextBlock",
                                                "weight": "bolder"
                                            }
                                        ],
                                        "type": "Column",
                                        "width": "auto"
                                    }
                                ],
                                "type": "ColumnSet"
                            },
                            {
                                "columns": [
                                    {
                                        "items": [
                                            {
                                                "altText": "74636f87-e35b-41f7-9d87-b73ca72ba9fa",
                                                "horizontalAlignment": "center",
                                                "id": "74636f87-e35b-41f7-9d87-b73ca72ba9fa",
                                                "type": "Image",
                                                "url": "https://stgfunctionspreco.blob.core.windows.net/aura-temporal-resources19071107/progress2Circles_1562831507956.png?st=2019-07-11T06%3A11%3A48Z&se=2019-07-11T08%3A16%3A48Z&sp=r&sv=2018-03-28&sr=b&sig=c3kKW26iwMwzGun%2FJ453FmmzA3mbc%2FWKc3QxTMRtgWU%3D"
                                            }
                                        ],
                                        "type": "Column"
                                    }
                                ],
                                "separator": true,
                                "spacing": "medium",
                                "type": "ColumnSet"
                            }
                        ],
                        "type": "AdaptiveCard",
                        "version": "1.0"
                    },
                    "contentType": "application/vnd.microsoft.card.adaptive"
                }
            ],
            "channelData": {
                "customData": {
                    "data": [
                        {
                            "74636f87-e35b-41f7-9d87-b73ca72ba9fa": [
                                {
                                    "max": {
                                        "amount": 28,
                                        "unit": "GB"
                                    },
                                    "of": "de",
                                    "progress": 0.06785714283718594,
                                    "remaining": {
                                        "amount": 26.100000000558794,
                                        "unit": "GB"
                                    },
                                    "usage": {
                                        "amount": 1.8999999994412065,
                                        "unit": "GB"
                                    }
                                },
                                {
                                    "endDate": "2038-01-02T04:59:59Z",
                                    "max": {
                                        "amount": 7028,
                                        "unit": "d\u00edas"
                                    },
                                    "progress": 0.039698349459305636,
                                    "remaining": {
                                        "amount": 6749,
                                        "unit": "d\u00edas"
                                    },
                                    "remainingText": "restante",
                                    "startDate": "2018-10-06T01:11:29Z",
                                    "usage": {
                                        "amount": 279,
                                        "unit": "d\u00edas"
                                    }
                                }
                            ]
                        }
                    ],
                    "type": "graphData"
                },
                "hasMoreMessages": false
            },
            "channelId": "directline",
            "conversation": {
                "id": "Je9bvMoUJQa6qWPKf89xCd-j"
            },
            "from": {
                "id": "BOT-aura-pre-co",
                "name": "BOT-aura-pre-co"
            },
            "id": "Je9bvMoUJQa6qWPKf89xCd-j|0000002",
            "inputHint": "acceptingInput",
            "localTimestamp": "2019-07-11T07:51:48.727+00:00",
            "replyToId": "Je9bvMoUJQa6qWPKf89xCd-j|0000000",
            "timestamp": "2019-07-11T07:51:48.7509824Z",
            "type": "message"
        }
    ],
    "watermark": "2"
}
...

Report XML file

📁 ~/[project_folder]/aura-tests/acceptance/_output/reports/1_[language]-[country]-[feature].xml

This file provides more general and complementary information regarding the QA Tool results: it identifies the step that is failing and in which feature (high level evaluation).

The result of this test can have three different status:

pass: tests are satisfactory.
skip: this status is achieved for tests that are not executed due to different internal reasons.
fail: tests are not satisfactory.

This test has the following general structure:

<?xml version='1.0' encoding='UTF-8'?>
<testsuite errors="0" failures="3" hostname="..." name="1_es-co_data_usage.Data Usage - Check data usage" skipped="28" tests="32" time="90.071549" timestamp="2019-07-30T13:23:19.913963">

Examples for the different status are shown below:

Example of FAIL test

<testcase classname="1_es-co_data_usage.Data Usage - Check data usage" name="Get the data usage of a postpaid user -- @1.1 users.data_usage.postpaid user logged with phone_number - [LANG:data_usage.question]" status="failed" time="29.682661"><failure message="Question asked: &quot;Consumo de datos actual&quot;&#10;Current response &quot;Te quedan 21.50 GB de datos de tu plan de 33 GB, hasta el 02/02/2029&quot; doesn´t match any of the &#10;Expected responses: [u'Conoce los servicios que tienes contratados']" type="AssertionError">
<![CDATA[
Failing step: And Message number "1" contains a text matching one of "services:services.usage.generic" ... failed in 0.014s
Location: features/end_to_end/novum/simplify/data_usage.feature:18
Assertion Failed: Question asked: "Consumo de datos actual"
Current response "Te quedan 21.50 GB de datos de tu plan de 33 GB, hasta el 02/02/2029" doesn´t match any of the 
Expected responses: [u'Conoce los servicios que tienes contratados']]]>
</failure><system-out>
<![CDATA[
@scenario.begin
  @smoke @TL.AUR-6748 @ap @ap_nov @ar @ar_nov @gb @gb_nov @br @br_nov @co @co_nov
  Scenario Outline: Get the data usage of a postpaid user -- @1.1 users.data_usage.postpaid user logged with phone_number - [LANG:data_usage.question]
    Given I have a users.data_usage.postpaid msisdn logged with phone_number ... passed in 21.850s
    And I have a valid AURA ID ... passed in 1.215s
    And I have started a conversation ... passed in 0.975s
    When I am prepared to ask a question ... passed in 0.009s
    And The following question is asked: "[LANG:data_usage.question]" ... passed in 0.746s
    Then The bot response is completed, that is, contains "3" messages ... passed in 4.867s
    And The response complies with the activities schema ... passed in 0.007s
    And Message number "1" contains a text matching one of "services:services.usage.generic" ... failed in 0.014s
    And Message number "2" contains a list "postpaid" of adaptive cards of type "data_usage" ... skipped in 0.000s
    And Message number "3" contains an actions card with suggestions of type: "check_data_usage" for: "postpaid" contract ... skipped in 0.000s
@scenario.end
-----------------------------------------------------------------------------

Example of SKIP test

</system-out></testcase><testcase classname="1_es-co_data_usage.Data Usage - Check data usage" name="Get the data usage in different situations of a postpaid user -- @2.4 postpaid data with 2.00 GB" status="skipped" time="0.0"><skipped /><system-out>
<![CDATA[
@scenario.begin
@ @TL.AUR-6082 @bug_br @ap @ap_nov @ar @ar_nov @br @br_nov @gb @gb_nov
  Scenario Outline: Get the data usage in different situations of a postpaid user -- @2.4 postpaid data with 2.00 GB
    Given I have a users.data_usage.data_round_2GB msisdn ... skipped in 0.000s
    And I have a valid AURA ID ... skipped in 0.000s
    And I have started a conversation ... skipped in 0.000s
    When I am prepared to ask a question ... skipped in 0.000s
    And The following question is asked: "[LANG:data_usage.question]" ... skipped in 0.000s
    Then The bot response is completed, that is, contains "3" messages ... skipped in 0.000s
    And The response complies with the activities schema ... skipped in 0.000s
    And Message number "1" contains a text matching one of "services:services.usage.summary" ... skipped in 0.000s
    And Message number "2" contains a list "postpaid.data.data_round_2GB" of adaptive cards of type "data_usage" ... skipped in 0.000s
    And Message number "3" contains an actions card with suggestions of type: "check_data_usage" for: "postpaid" contract ... skipped in 0.000s
@scenario.end
------------------------------------------------------------------------------

Example of PASS test

--------------------------
------------------------------------------------------------------------------
]]>
</system-out></testcase><testcase classname="1_es-co_data_usage.Data Usage - Check data usage" name="Try to get the data usage with a multimsisdn user with username -- @1.1 multimsisdn user - [LANG:data_usage.question]" status="passed" time="19.751802"><system-out>
<![CDATA[
@scenario.begin
  @smoke @ap @ap_nov @ar @ar_nov @gb @gb_nov @co @co_nov
  Scenario Outline: Try to get the data usage with a multimsisdn user with username -- @1.1 multimsisdn user - [LANG:data_usage.question]
    Given I have a users.multimsisdn.postpaid msisdn logged with username ... passed in 15.484s
    And I have a valid AURA ID ... passed in 1.237s
    And I have started a conversation ... passed in 0.992s
    When I am prepared to ask a question ... passed in 0.009s
    And The following question is asked: "[LANG:data_usage.question]" ... passed in 0.703s
    Then The bot response is completed, that is, contains "1" messages ... passed in 1.309s
    And The response complies with the activities schema ... passed in 0.004s
    And A single message contains a text matching one of "context-filter:user-type-not-allowed.text" ... passed in 0.013s
@scenario.end
--------------------------------------------------------------------------------
]]>
</system-out></testcase></testsuite>

Allure Report

To generate the Allure report, run the following command:
$ allure serve ./_output/allure

The execution of this command generates a report in a temporary folder with data found in the provided path and then creates a local server instance, serves the generated report and opens it in the default browser.

Each Allure report contains a tree-like data structure that represents the test execution process. Different tabs allow to switch between the views of the original data structure, thus giving a different perspective: overview tab, navigation bar, several tabs for different types of data representation and test case pages for each individual test.

If you do not have Allure installed, access this link and follow the instructions: https://docs.qameta.io/allure/#_installing_a_commandline

⚠️ Allure is a third party tool and no support is provided by the Aura Global Team.

An example of the content of an Allure report is included below:

Overview page

The entry point for every report would be the overview page, that includes relevant dashboards and widgets:

The overview page hosts several default widgets representing basic characteristics of the project and test environment. Navigation bar is collapsible and enables to switch into several basic results overview modes.

Detail

Tests are shown grouped by features, through clicking “show all” or “Behaviors” from the overview page:

Test case page

For some of the results in the overview page described above, it is possible to access to the test case page after clicking on the individual tests. This page will typically contains relevant individual data related to the test case: steps executed during the test, timings, attachments, test categorization labels, descriptions and links.

Users’ files

📁 ~/[project_folder]/aura-tests/acceptance/_output/users/[country]/[userid].json Users’ data are contained in the Telefónica Kernel APIs. When the QA tests are executed, the system recovers the data and stores it in these JSON files.

Example of Telefonica Kernel data user JSON file

{
    "bundle_list": [
        {
            "date": "regex:[0-9]{1,2} de [a-zA-Zç]+ de [0-9]{4}", 
           "name": "Plan Prepago *", 
           "desc": ": InternetXdiaPlus$14 x50MB, HABLÁ: Si elegiste HABLÁ tenés un 50% de descuento en llamadas a Movistar por 7 días con tus recargas desde $6"
        }
    ], 
   "bills": [], 
   "roles": [
        "owner", 
       "admin"
    ], 
   "subscription_type": "prepaid", 
   "msisdn": "+541136742577", 
   "userid": "126529396", 
   "user_type": "monomsisdn", 
   "setup_4g_ready": [
        {
            "suggestion_des": "Tu telefono es 4G, por favor revisa tu configuracion aca", 
           "result_tm": "2029-01-24", 
           "description1_des": "http://ayuda.movistar.com.ar/pregunta/como-configurar-mi-equipo-en-la-red-4g.html", 
           "result_dt": ""
        }
    ], 
   "data_usage": [
        {
            "suggestion_des": "De acuerdo a tu patron de consumo, te recomiendo el plan Plan Comunidad 1 GB", 
           "result_tm": "2029-01-20 00:00:00.0", 
           "end_data_day_dt": null, 
           "additional_info_des": null, 
           "consumed_qt": "44.923", 
           "contracted_qt": "524288000", 
           "anomaly_ind": false
        }
    ], 
   "services": [
        "mobile_prepaid"
    ], 
   "device_recommender": [], 
   "balance": {
        "date": "[0-9]{1,2} de [a-zA-Zç]+ de [0-9]{4}", 
       "currency": "ARS", 
       "amount": "\\$ [0-9]+,[0-9]+"
    }, 
   "data": [], 
   "email": "MEDINA.M1990@GMAIL.COM"
}

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Update CLU API version for releases previous to Nodoubt 9.11.0

In releases previous to Nodoubt 9.11.0, it is required to update the CLU API used for the clu-storage

Introduction

The current version of the CLU API used for the clu-storage (2023-04-15-preview) will be deprecated on March 31, 2025.

This version should be updated to 2024-11-15-preview for all environments before this date by the GES Team.

The update of the CLU API version enables the copy of CLU projects in cache. This leads to more efficient processes: reuse of CLU trainings with no need for retraining, reduced deployment times, hot swapping processes, etc.

On the other hand, this update does not impact in the use of Aura NLP.

Steps to update CLU API version

To update the version of the CLU API, follow the steps below:

Prerequisite: A kubeconfig of the environment must be previously configured.

Access to edit configuration:

  kubectl edit configmap nlp-provisioning-bootstrap -n <namespace>

In the section clu of the nlp-provisioning-bootstrap configmap, the value storage_api_version should be updated to 2024-11-15-preview.
Save and close the ConfigMap.

Restart nlp-provisioning deployment:

  kubectl rollout restart deployment/nlp-provisioning -n <namespace>

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Management of alerts in Aura

Learn how to manage alerts through Prometheus system

Introduction to alerts in Aura

As previously stated, Prometheus has a list of alert rules that are part of the platform configuration. These alerting rules allow you to define alert conditions based on Prometheus expression language.

⚠️ It is possible to edit the Aura alert rules but, for now, changes are lost in a re-deployment.
If you think an alert is important and should be part of the platform, let us know, so we can officially include it.

Alerts are sent via email, using a global SMTP server managed by the Aura Team. Other notification channels (Slack) are also available but not used by default in production.

Alerts are disabled (silenced) during Aura deployments to avoid false positives due to services that need to be restarted, etc.

In order to manage alerts, Aura Platform includes the AlertManager system, which is the part of Prometheus Stack. The URL to access to alertmanager is:
alerts-{{ environment_name }}.auracognitive.com

When accessing the web, you can see all the alerts, as shown in the image below.

In this panel, the most important thing that you can do is “silence” one alarm pushing in the “silence alarm” or pressing the “new silence button”

In order to check if the cluster is ok (ready) or the status of the system, click in the “status” section.

Alerts set in Aura

The current section includes the different alerts currently set in Aura, organized by their scope.

Scope: infrastructure

high_cpu_usage_on_hosts
- Description: « $labels.kubernetes_io_hostname » is using a LOT of CPU. CPU usage is « humanize $value »%.
- Expr: sum by(kubernetes_io_hostname) (rate(container_cpu_usage_seconds_total{id="/"}[5m])) / sum by(kubernetes_io_hostname) (machine_cpu_cores) * 100 > 90
- For: 10m
- summary: HIGH CPU USAGE WARNING ON ‘{{ $labels.kubernetes_io_hostname }}’
high_memory_usage_on_hosts
- Description: « $labels.kubernetes_io_hostname » is using a LOT of Memory. Memory usage is « humanize $value »%.
- Expr: sum by(kubernetes_io_hostname) (container_memory_working_set_bytes{id="/"}) / sum by(kubernetes_io_hostname) (machine_memory_bytes) * 100 > 90
- For: 10m
- summary: HIGH MEMORY USAGE WARNING ON ‘{{ $labels.kubernetes_io_hostname }}’
high_fs_usage_on_hosts
- Description: « $labels.kubernetes_io_hostname » is using a LOT of FileSystem space. FileSystem usage is « humanize $value »%.
- Expr: sum by(kubernetes_io_hostname) (container_fs_usage_bytes{device=~"^/dev/.*$",id="/"}) / sum by(kubernetes_io_hostname) (container_fs_limit_bytes{device=~"^/dev/.*$",id="/"}) * 100 > 70
- For: 10m
- summary: HIGH FILESYSTEM USAGE WARNING ON ‘{{ $labels.kubernetes_io_hostname }}’

Scope: kubernetes

high_persistent_volume_usage
- Description: « $labels.persistentvolumeclaim » on « $labels.kubernetes_io_hostname » is using a LOT of persistent volume space. Persistent volume usage is « humanize $value »%.
- Expr: kubelet_volume_stats_used_bytes * 100 / kubelet_volume_stats_capacity_bytes > 70
- For: 10m
- summary: HIGH PERSISTENT VOLUME USAGE WARNING ON ‘{{ $labels.kubernetes_io_hostname }}’ by ‘{{ $labels.persistentvolumeclaim }}’
high_persistent_volume_inode_usage
- Description: « $labels.persistentvolumeclaim » on « $labels.kubernetes_io_hostname » is using a LOT of persistent volume inodes. Persistent volume inode usage is « humanize $value »%.
- Expr: kubelet_volume_stats_inodes_used * 100 / kubelet_volume_stats_inodes > 70
- For: 10m
- summary: HIGH PERSISTENT VOLUME INODE USAGE WARNING ON ‘{{ $labels.kubernetes_io_hostname }}’ by ‘{{ $labels.persistentvolumeclaim }}’
docker_deleted_container_rate_on_hosts
- Description: « $labels.kubernetes_io_hostname » has a HIGH rate of deleted/stopped containers.
- Expr: sum by(kubernetes_io_hostname) (rate(kubelet_docker_operations{operation_type=~"remove_container|stop_container"}[5m])) > 0.1
- For: 1m
- summary: DOCKER DELETED/STOPPED CONTAINER RATE WARNING
runtime_deleted_container_rate_on_hosts
- Description: « $labels.kubernetes_io_hostname » has a HIGH rate of deleted/stopped containers.
- Expr: sum by(kubernetes_io_hostname) (rate(kubelet_runtime_operations{operation_type=~"stop_podsandbox|remove_container|stop_container"}[5m])) > 0.1
- For: 1m
- summary: RUNTIME DELETED/STOPPED CONTAINER RATE WARNING
frequent_container_restarts
- Description: Container « $labels.container » on pod « $labels.pod » has been restarted « $value » times within the last hour.
- Expr: increase(kube_pod_container_status_restarts_total[1h]) > 5
- For: 5m
- summary: KUBERNETES FREQUENT CONTAINER RESTARTS WARNING
node_not_ready
- Description: Node « $labels.node » has status « $labels.condition » as « $labels.status ».
- Expr: kube_node_status_condition{condition!="Ready",status!="false"} > 0 or on(node) kube_node_status_condition{condition="Ready",status="false"} > 0
- For: 5m
- summary: KUBERNETES NODE NOT READY WARNING
job_error
- Description: JOB ERROR
- Expr: kube_job_status_failed==1
- For: 5m
- summary: KUBERNETES JOB NOT READY WARNING

Scope: prometheus

prometheus_rule_evaluation_slow
- Description: Prometheus has a 90th percentile latency of « $value »s completing rule evaluation cycles.
- Expr: prometheus_evaluator_duration_seconds{quantile="0.9"} > 60
- For: 10m
- summary: PROMETHEUS RULE EVALUATION SLOW WARNING
prometheus_indexing_backlog
- Description: Prometheus is backlogging on the indexing queue. Queue is currently « $value | printf %.0f »% full.
- Expr: prometheus_local_storage_indexing_queue_length / prometheus_local_storage_indexing_queue_capacity * 100 > 10
- For: 10m
- summary: PROMETHEUS INDEXING BACKLOG WARNING
prometheus_not_ingesting_samples
- Description: Prometheus has not ingested any sample in the last 10 minutes.
- Expr: rate(prometheus_local_storage_ingested_samples_total[5m]) == 0
- For: 5m
- summary: PROMETHEUS NOT INGESTING SAMPLES WARNING
prometheus_persist_errors
- Description: Prometheus has encountered « $value » persistent errors per second in the last 10 minutes.
- Expr: rate(prometheus_local_storage_persist_errors_total[10m]) > 0
- For: 5m
- summary: PROMETHEUS PERSIST ERRORS WARNING
prometheus_notifications_backlog
- Description: Prometheus is backlogging on the notifications queue. The queue has not been empty for 10 minutes. Current queue length: « $value ».
- Expr: prometheus_notifications_queue_length > 0
- For: 10m
- summary: PROMETHEUS NOTIFICATIONS BACKLOG WARNING
prometheus_storage_inconsistent
- Description: Prometheus has detected a storage inconsistency. A server restart is needed to initiate recovery.
- Expr: prometheus_local_storage_inconsistencies_total > 0
- For: 5m
- summary: PROMETHEUS STORAGE INCONSISTENCY WARNING
prometheus_persistence_pressure_too_high_24h
- Description: Prometheus is approaching critical persistence pressure. Throttled ingestion expected within the next 24h.
- Expr: prometheus_local_storage_persistence_urgency_score > 0.8 and predict_linear(prometheus_local_storage_persistence_urgency_score[30m], 3600 * 24) > 1
- For: 30m
- summary: PROMETHEUS PERSISTENCE PRESSURE 24H WARNING
prometheus_persistence_pressure_too_high_2h
- Description: Prometheus is approaching critical persistence pressure. Throttled ingestion expected within the next 2h.
- Expr: prometheus_local_storage_persistence_urgency_score > 0.85 and predict_linear(prometheus_local_storage_persistence_urgency_score[30m], 3600 * 2) > 1
- For: 30m
- summary: PROMETHEUS PERSISTENCE PRESSURE 24H WARNING
prometheus_series_maintenance_stalled
- Description: Prometheus is maintaining memory time series so slowly that it will take « $value | printf %.0f »h to complete a full cycle. This will lead to persistence falling behind.
- Expr: prometheus_local_storage_memory_series / on(job, instance) rate(prometheus_local_storage_series_ops_total{type="maintenance_in_memory"}[5m]) / 3600 > 24 and prometheus_local_storage_rushed_mode == 1
- For: 1h
- summary: PROMETHEUS SERIES MAINTENANCE WARNING
prometheus_target_scrape_sync_too_low
- Description: Prometheus target scrape sync rate is too low.
- Expr: rate(prometheus_target_scrape_pool_sync_total{app="prometheus"}[10m]) == 0
- For: 5m
- summary: PROMETHEUS TARGET SCRAPE SYNC WARNING

Scope: logs

elasticsearch_too_few_nodes_running
- Description: There are only « $value » < 3 ElasticSearch nodes running.
- Expr: elasticsearch_cluster_health_number_of_node < 3
- For: 10m
- summary: TOO FEW ELASTICSEARCH NODES
elasticsearch_high_memory_usage
- Description: The memory (heap) usage is over 90% for 15m on node « $labels.node »
- Expr: elasticsearch_jvm_memory_used_bytes{area="heap"} / elasticsearch_jvm_memory_max_bytes{area="heap"} > 0.9
- For: 15m
- summary: ELASTICSEARCH HIGH MEMORY USAGE
elasticsearch_not_indexing
- Description: ElasticSearch data node is not indexing new documents
- Expr: increase(elasticsearch_indices_docs{es_data_node="true"}[1m]) == 0
- For: 5m
- summary: ELASTICSEARCH NOT INDEXING

Scope: Aura

aura-bot_unauthorized_aura-bridge
- Description: aura-bridge has not authorized the connection with aura-bot for 3 minutes.
- Expr: sum by (status_code) (rate(http_request_duration_seconds_count{app="aura-bridge",status_code=~"401"}[3m])) > 0
- For: 3m
- summary: AURA-BOT RETURN UNAUTHORIZED TO AURA-BRIDGE
aura-bot_bad-request_aura-bridge
- Description: aura-bridge has not been able to correctly handle the connection with aura-bot for 3 minutes.
- Expr: sum by (status_code) (rate(http_request_duration_seconds_count{app="aura-bridge",status_code=~"400"}[3m])) > 0
- For: 3m
- summary: AURA-BOT RETURN BAD REQUEST TO AURA-BRIDGE
aura-bot_internal-error_aura-bridge
- Description: aura-bridge failed to connect to aura-bot for 3 minutes.
- Expr: sum by (host,status) (rate(outgoing_request_duration_seconds_count{app="aura-bridge",status=~"5..",host=~"aura-bot.*"}[3m])) > 0
- For: 3m
- summary: COMMUNICATION ERROR BETWEEN AURA-BOT AND AURA-BRIDGE
aura-bridge-error_callback
- Description: aura-bridge failed to handle the connection with callback for 3 minutes.
- Expr: sum by (host,status) (rate(outgoing_request_duration_seconds_count{app="aura-bridge",status=~"5..",host!~"aura-bot.*"}[3m])) > 0
- For: 3m
- summary: COMMUNICATION ERROR BETWEEN AURA-BRIDGE AND CALLBACK
aura-bridge_error_whatsapp
- Description: errors in aura-bridge with WhatsApp functionality for 5 minutes.
- Expr: sum by (origin,originStatus)(rate(outgoing_message_duration_seconds_count{app="aura-bridge",origin=~"aura-bot|whatsapp|4p",originStatus!="200",httpStatus!~"403|408|400"}[5m])) > 0
- For: 5m
- summary: Error happened in WhatsApp functionality.
aura-bridge_error_4p
- Description: errors in aura-bridge with Kernel in WhatsApp functionality for 5 minutes.
- Expr: sum by (origin,originStatus)(rate(outgoing_message_duration_seconds_count{app="aura-bridge",origin=~"4p",httpStatus=~"403|408|400"}[5m])) > 0
- For: 5m
- summary: Error happened with Kernel in WhatsApp functionality.
nlp-provisioning_killed-processes
- Description: killed nlp-provisioning processes for 15 minutes.
- Expr: sum by (exported_job) (rate(nlp_provisioning_killed_processes{exported_job="nlp_provisioning_job"}[15m])) > 0
- For: 15m
- summary: Processes killed in nlp-provisioning
alive-processes_nlp-provisioning_expected-alive-processes
- Description: alive nlp-provisioning processes vs expected alive nlp-provisioning processes for 15 minutes.
- Expr: sum by (exported_job)(nlp_provisioning_alive_processes{exported_job="nlp_provisioning_job"}) / sum by (exported_job) (nlp_provisioning_expected_alive_processes{exported_job="nlp_provisioning_job"})!=1
- For: 15m
- summary: Processes killed in nlp-provisioning

Scope: misc

probe_down
- Description: The endpoint « $labels.instance » is down or not reachable. The blackbox exporter could not validate « $labels.app »’s health.
- Expr: probe_success == 0
- For: 2m
- summary: PROBE FAILING

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura HTTP Inbound dashboard

Information provided Aura HTTP inbound dashboard

Introduction

HTTP inbound dashboard monitors inbound traffic to different services.

This inbound traffic can be visualized by channel, thus providing a detailed insight into the specific incoming traffic to this particular channel. It clearly improves the optimization of strategies for that channel or a performance comparison between different channels.

The available metrics are defined in the following sections.

HTTP request latency

HTTP request latency graph shows mean latency time aggregated by one minute.

Graph metrics

sum by (app, kubernetes_namespace)(rate(http_request_duration_seconds_sum{app=~'(aura-bot|aura-bridge|authentication-api|complex-logic|context|nlp|tac|thanos-querier)'}[1m])) /
sum by (app, kubernetes_namespace)(rate(http_request_duration_seconds_count{app=~'(aura-bot|aura-bridge|authentication-api|complex-logic|context|nlp|tac|thanos-querier)'}[1m]))

Graph visual

HTTP Request Rate

HTTP requests rate graph shows number of requests aggregated by one minute.

Graph metrics

sum by (app, kubernetes_namespace)  (rate(http_request_duration_seconds_count{app=~'(aura-bot|aura-bridge|authentication-api|complex-logic|context|nlp|tac|thanos-querier)'}[1m]))

Graph visual

HTTP request latency

HTTP request latency graph shows request latency aggregated by one minute.

Graph metrics

sum by (app, kubernetes_namespace)  (rate(http_request_duration_seconds_sum{app=~'(aura-bot|aura-bridge|authentication-api|complex-logic|context|nlp|tac|thanos-querier)'}[1m]))

Graph visual

HTTP error rate

HTTP error rate shows rate of petition errors aggregated by one minute.

Graph metrics

sum by (app, kubernetes_namespace)  (rate(http_request_duration_seconds_count{app=~'(aura-bot|aura-bridge|authentication-api|complex-logic|context|nlp|tac|thanos-querier)',status_code=~"4..|5.."}[1m]))

Graph visual

Errors

Errors graph shows errors duration aggregated by one minute.

Graph metrics

sum(rate(http_request_duration_seconds_count{app=~'(aura-bot|aura-bridge|authentication-api|complex-logic|context|nlp|tac|thanos-querier)',status_code=~"4..|5.."}[1m])) by (app, kubernetes_namespace)

Graph visual

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Configuration of user’s data

Guidelines for the configuration of of Aura users required to launch the QA tests

Introduction

The configuration of the different Aura’s users is required in order to launch the QA Tool.

When the QA tests are executed, the system recovers the users’ data from Telefónica Kernel APIs and stores it in the path:

~/[project_folder]/aura-tests/acceptance/_output/users/[country_code]/

At this stage, the local QA team must create a new file for the configuration of users in the following path:
~/[project_folder]/aura-tests/acceptance/settings/[country_code]/[country_code]-[environment]-local-users.json

This file must be edited with the sections and procedure detailed in the following sections.

Fields in the file [country_code]-[environment]-local-users.json

The required steps to fill in this file with the users’ configuration are fully explained below.

`user_definition` field

Firstly, it is required to fill in the user_definition field:

subscription_type: subscription type of users, it can be ‘prepaid’, ‘postpaid’ or ‘control’)
msisdn: phone number of the user
user_id: id of user in Telefónica Kernel
user_type: user type, it can be ‘monomsisdn’, ‘multimsisdn’, ’nomsisdn’, ‘invalid’
uid: user identification (used for authentication purposes)
email: email address of user (used for authentication purposes)
password: uid/email password (used for authentication purposes)

ℹ️ In environments with mandatory authorization_id, the user can authenticate through:

MSISDN
Uid + password
Email + password

If possible, add both fields, uid and email or add SKIP value to avoid authentication failures (if it is impossible, obtain the uid and/or email of the user), as tests with this user will be skipped.

See more details in Troubleshooting: Error related to users’ config file.

Example of definition

"users_definition": {
    "user1": {
      "subscription_type": "prepaid",
      "user_type": "monomsisdn",
      "msisdn": "+573152641455",
      "userid": "50914",
      “login_user”: “navx@o2.com”,
      “login_password”: “test1234”
    },
    "user2": {
      "subscription_type": "postpaid",
      "user_type": "monomsisdn",
      "msisdn": "+573156492873",
      "userid": "50908",
      "uid": "509652361",
      "email": user2@gmail.com,
      "password": "user2pwd"
    },
    "user3": {
      "subscription_type": "control",
      "user_type": "monomsisdn",
      "msisdn": "+573102553679",
      "userid": "50913"
      "uid": "509090909",
      "password": "user3pwd"

    },
    "user4": {
      "subscription_type": "postpaid",
      "user_type": "multimsisdn",
      "msisdn": "+573167412035",
      "userid": "50739"
      "email": user4@gmail.com,
      "password": "user4pwd"

    },
    "user5": {
      "subscription_type": "control",
      "user_type": "multimsisdn",
      "msisdn": "+573152445674",
      "userid": "50911"
    },
    "user6": {
      "subscription_type": "postpaid",
      "user_type": "monomsisdn",
      "msisdn": "999999999",
      "userid": "999999999"
    },
    "user7": {
      "subscription_type": "prepaid",
      "user_type": "monomsisdn",
      "msisdn": "",
      "userid": "50914"
    }
  }

`users` element

It is required to fill in the users’ definition name in the users element. For this purpose, there are different types of users, depending on the type of data that the user has on Telefónica Kernel.

Default user

Main user executed in tests, independently on the type of data.

Contract type

user_profile endpoint configured in Telefónica Kernel (element identities.services)
users.common.prepaid: Value of the service is ‘mobile_prepaid’
users.common.postpaid: Value of the service is ‘mobile_postpaid’
users.common.control: Value of the service element is ‘mobile_control’

Example of user profile call

"id_document": {
    "country": "ES",
    "type": "NIF",
    "value": "6667337566Y"
  },
  "identities": [
    {
      "type": "uid",
      "id": "412d606f-4937-443b-b5e7-a8d0f63ef0bc",
      "services": [
        "authentication"
      ],
      "roles": [
        "owner"
      ]
    },
    {
      "type": "uid",
      "id": "8971245361267438349",
      "services": [
        "iptv"
      ],
      "roles": [
        "owner"
      ],
      "group_ids": [
        "bundle_1"
      ]
    },
    {
      "type": "phone_number",
      "id": "+34629123456",
      "services": [
        "mobile_postpaid"
      ],
      "roles": [
        "owner",
        "admin"
      ],
      "group_ids": [
        "bundle_1"
      ]
    },
    {
      "type": "phone_number",
      "id": "+34609332266",
      "services": [
        "mobile_postpaid"
      ],
      "roles": [
        "owner"
      ],
      "group_ids": [
        "bundle_1"
      ]
    },
    {
      "type": "phone_number",
      "id": "+34983456789",
      "services": [
        "landline",
        "internet"
      ],
      "roles": [
        "owner"
      ],
      "group_ids": [
        "bundle_1"
      ]
    }
  ],
  "name": "Andrés Iniesta",
  "contact_media": [
    {
      "type": "phone_number",
      "value": "+34629123456"
    }
  ],
  "id": "412d606f-4937-443b-b5e7-a8d0f63ef0bc"
}

User type

user_profile endpoint configured on Telefónica Kernel (in the element identities.services).

Four types of users are defined:

monomsisdn User that only has one phone. In this case, it is possible to classify the user by subscription type:
- users.prepaid: user type monomsisdn whose phone number is prepaid
- users.postpaid: user type monomsisdn whose phone number is postpaid
- users.control: user type monomsisdn whose phone number is control
multimsisdn: User that has several phones. In this case, it is possible to classify the user by subscription type:
- users.multimsisdn.prepaid: user type multimsisdn whose phone number is prepaid
- users.multimsisdn.postpaid: user type multimsisdn whose phone number is postpaid
- users.multimsisdn.control: user type multimsisdn whose phone number is control
nomsisdn: User with no phone number.
invalid: Invalid user in Telefónica Kernel and Aura.

balance_check

It can be checked in mobile_balance and mobile_quota endpoints configured on Telefónica Kernel. User should have data in mobile_balance endpoint, for example:

{
    "phone_number": "+5567999170892",
    "expiration_date": "2019-03-08T09:42:51Z",
    "amount": 44.17,
    "currency": "BRL"
}

users.balance_check.voice_data
User with voice and data in mobile quota endpoint.
Example of mobile quota:

{
    "phone_number": "+541121700177",
    "sms": [
        {
            "consumed_sms": 0,
            "max_sms": 25000,
            "description": "SMS",
            "end_date": "2018-12-17T03:00:00Z",
            "start_date": "2018-11-18T03:00:00Z"
        }
    ],
    "voice": [
        {
            "description": "Minutos Multidestino No Acumulable",
            "end_date": "2018-12-17T03:00:00Z",
            "consumed_seconds": 3448,
            "max_seconds": 30000,
            "start_date": "2018-11-18T03:00:00Z",
            "destinations": [
                "any"
            ]
        },
        {
            "description": "Minutos a Comunidad",
            "end_date": "2018-12-17T03:00:00Z",
            "consumed_seconds": 75336,
            "max_seconds": 3000000,
            "start_date": "2018-11-18T03:00:00Z",
            "destinations": [
                "telefonica"
            ]
        }
    ],
    "data": [
        {
            "max_bytes": 4294967296,
            "consumed_bytes": 1230395392,
            "description": "Datos Incluidos/Velocidad",
            "end_date": "2018-12-17T03:00:00Z",
            "start_date": "2018-11-18T03:00:00Z"
        }
    ]
}

users.balance_check.no_voice
User without voice element in mobile quota endpoint.
Example of mobile quota data:

{
    "phone_number": "+541121700177",
    "sms": [
        {
            "consumed_sms": 0,
            "max_sms": 25000,
            "description": "SMS",
            "end_date": "2018-12-17T03:00:00Z",
            "start_date": "2018-11-18T03:00:00Z"
        }
    ],
    "voice": [],
    "data": [
        {
            "max_bytes": 4294967296,
            "consumed_bytes": 1230395392,
            "description": "Datos Incluidos/Velocidad",
            "end_date": "2018-12-17T03:00:00Z",
            "start_date": "2018-11-18T03:00:00Z"
        }
    ]
}

users.balance_check.multiple_mobiles
User with multiple mobiles in subscribed_products endpoint.
users.balance_check.bonus_balance
User with several bonus contracted.
Example of mobile quota:

{
    "phone_number": "+5511982099898",
    "sms": [],
    "voice": [],
    "data": [
        {
            "max_bytes": 53689188352,
            "consumed_bytes": 1506646425,
            "description": "MULTIVIVO GRATIS.",
            "end_date": "2019-01-01T02:00:00Z",
            "start_date": "2018-12-02T02:00:00Z"
        },
        {
            "max_bytes": 524288000,
            "consumed_bytes": 524288000,
            "description": "BONUS CONTA DIGITAL",
            "end_date": "2019-01-01T02:00:00Z",
            "start_date": "2018-12-02T02:00:00Z"
        },
        {
            "max_bytes": 524288000,
            "consumed_bytes": 524288000,
            "description": "BONUS DEBITO AUTOMATICO",
            "end_date": "2019-01-01T02:00:00Z",
            "start_date": "2018-12-02T02:00:00Z"
        },
        {
            "max_bytes": 51215052308,
            "consumed_bytes": 0,
            "description": "Vivo Bis",
            "end_date": "2019-01-01T02:00:00Z",
            "start_date": "2018-12-02T02:00:00Z"
        },
        {
            "max_bytes": 53687091200,
            "consumed_bytes": 326620938,
            "description": "App Facilidades",
            "end_date": "2019-01-01T02:00:00Z",
            "start_date": "2018-12-02T02:00:00Z"
        },
        {
            "max_bytes": 42949672960,
            "consumed_bytes": 14754460467,
            "description": "Double Play",
            "end_date": "2019-01-01T02:00:00Z",
            "start_date": "2018-12-02T02:00:00Z"
        }
    ]
}

users.balance_check.no_balance
Example of mobile balance data:

{
    "phone_number": "+541121700177",
    "expiration_date": "2019-03-06T13:45:33Z",
    "amount": 0,
    "currency": "ARS"
}

users.balance_check.start_date
User with start_date in mobile quota.
users.balance_check.no_start_date
User with no start_date in mobile quota.
Example of mobile quota:

{
    "phone_number": "+541121700177",
    "sms": [
        {
            "consumed_sms": 0,
            "max_sms": 25000,
            "description": "SMS",
            "end_date": "2018-12-17T03:00:00Z",
            "start_date": "2018-11-18T03:00:00Z"
        }
    ],
    "voice": [
        {
            "description": "Minutos Multidestino No Acumulable",
            "end_date": "2018-12-17T03:00:00Z",
            "consumed_seconds": 3448,
            "max_seconds": 30000,
            "destinations": [
                "any"
            ]
        },
        {
            "description": "Minutos a Comunidad",
            "end_date": "2018-12-17T03:00:00Z",
            "consumed_seconds": 75336,
            "max_seconds": 3000000,
            "destinations": [
                "telefonica"
            ]
        }
    ],
    "data": [
        {
            "max_bytes": 4294967296,
            "consumed_bytes": 1230395392,
            "description": "Datos Incluidos/Velocidad",
            "end_date": "2018-12-17T03:00:00Z",
        }
    ]
}

users.balance_check.today_expiration
User in which the expiration_date element in mobile balance endpoint is today.

{
    "phone_number": "+541121700177",
    "expiration_date": "{today}",
    "amount": 0,
    "currency": "ARS"
}

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Analytics data model

Data model of Aura Analytics 1.1. that can be used as the base for building new elements

Introduction

New elements can be built (or the current elements modified) by making use of the available fields in Kibana through the ingested Elastic Search index.

In this document, we provide a reference of the schema that the index follows, so that it can be used to build such new visualizations, or to better understand the existing ones.

Elements in the Aura-message data model have 3 different types:

Numeric: single numbers, integer or real. Suitable for numerical statistics, such as averages, or for plotting variation across time in graphs.
Keyword: they are opaque strings, i.e., terms that cannot be searched within (it is not possible to look for words inside a keyword field). They can, however, be used to create some term-level queries, such as prefix queries (find all instances that begin with) and they usually work great for aggregations, since most of them are categorical variables (fields that only have a limited number of possible values) and can therefore be bucketed and counted.
Text: these fields are divided into separate terms (words), and some pre-processing is done to them before indexing to improve access though an Elastic Search analyzer. Text fields cannot be used in aggregated visualizations, since they cannot be grouped. They are most useful for queries, because they allow searching for fragments (only a few words) and fuzzy searches.

Fields list

The following table lists all the fields available in the Aura-message-COUNTRY Elastic Search index, together with their type and a brief description.

The most relevant ones include a more detailed description in the section fields explanations.

Note that some fields of text type have a mirror field of type keyword, with the same content. Having the same data indexed in two different ways at the same time (as text and as keyword) enables to perform different types of analysis by choosing the right field.

The “Raw” column indicates if this field is already present in the Aura raw PPD files:

Yes: field contained in raw PPDs.
No: generated field, produced when creating clean PPDs. They can be recognized as lowercase fields.
Partial: It exists in the raw PPDs, but in a somehow different shape.

Field	Type	Raw	Contents
CORR_ID	keyword	yes	Unique identifier for each interaction
VERSION_ID	keyword	yes	Aura Platform version
CHANNEL_CD	keyword	yes	Identifier for the channel this interaction corresponds to
STATUS_CD	keyword	yes	Internal code related to operation status
AURA_ID_GLOBAL	keyword	yes	(Mostly) unique identifier for the user
AURA_ID	keyword	yes	(Mostly) local identifier for the user
INTENT	keyword	yes	Detected user intent, including “system” intents
MESSAGE_USR	text	partial	Text request sent by the user
MESSAGE_USR_NORM	text	no	A normalized version of MESSAGE_USR
MESSAGE_USR_NORM.keyword	keyword	no	A keyword version of MESSAGE_USR_NORM, to enable aggregating on it
MESSAGE_AURA	text	partial	Text message sent by AURA to the user
MESSAGE_AURA.keyword		partial	Keyword version of MESSAGE_AURA, to enable aggregating on it
MODALITY_CD_USR	text	partial	Modality of the user message
MODALITY_CD_AURA	text	partial	Modality of Aura response
ENTITIES	text	yes	Comma-separated list of the entities recognized in the user message
DIALOG_ID	text	yes	Identifier for the dialog that produced Aura response
DIALOG_ID.keyword	keyword	yes	Keyword version of `DIALOG_ID`, to enable aggregating on it
DURATION_NU	number	yes	Elapsed time, in ms, between the reception of the user message and the moment the response is generated to be sent to the channel
userType	keyword	no	A single char identifier that characterizes the user as a test user
usrMsgWc	number	no	Message word count: number of words contained in the user message
usrMsgSig	keyword	no	Message signature: a string that helps clustering user messages
AuraMsgGroup	keyword	no	Cluster the Aura response belongs to
weekday	number	no	Day of the week the interaction happened (0=Monday to 6=Sunday)
hour	number	no	(Integer) hour the interaction happened
country	keyword	partial	Two-letter code for the country
sesId	keyword	no	Session information
sesSize	number	no	Session information
sesDuration	number	no	Session information

Fields explanations

This subsection contains more detailed descriptions of some of the key fields in the schema.

AURA_ID_GLOBAL

This element (mostly) uniquely identifies the user generating the interaction.

Note the concrete value of this field is not the same as the actual identifier used within Aura and uploaded to Kernel: for privacy reasons, the identifier was hashed when generating the PPD and has no resemblance to the original one. The correspondence is however maintained across time, so it is possible to analyse user behavior.

The “mostly” qualifier reflects one quirk of the original Aura identifier: it is generated with a dependence to the authentication method used by the channel, so if two channels follow different authentication methods (e.g., MobileConnect vs. User/Password) then the AURA_ID_GLOBAL identifier for the same user will be different. In summary:

The identifier stays the same for a given user across time.
Different users will not have the same identifier.
But the same user could produce two different identifiers if connected to two channels that use a different authentication method.

AURA_ID

This is a “local” identifier, i.e., one that is generated inside the channel according to specific channel characteristics and it is not tied as much as AURA_ID_GLOBAL to user authentication.

Its main disadvantage is its transient nature: the same user, on the same channel, could generate different AURA_ID strings when connecting different times on a different session. Therefore, for user accounting and tracing, AURA_ID_GLOBAL is usually preferred.

However, there are instances in which AURA_ID works better, namely for anonymous access (when the user is not authenticated). This depends on the channel:  

In the WhatsApp channel, the initial use of the channel will be anonymous from the Aura side (i.e., no authentication is done), hence AURA_ID_GLOBAL will also be empty (at least until the user authenticates, which depends on the use case). But in this channel, AURA_ID has a permanent value, linked to the WhatsApp user, so here it is a good substitute for a persistent id, even for unauthenticated users.

MESSAGE_USR

This field includes the message sent by the user.

It has been partially processed to enhance anonymization by removing some standard identifiers contained in it with <idxxx> strings (e.g., phone numbers appear as <idphone>).

Removal is done mostly through regular expressions, so there might be occasional glitches (such as identifying as phone a number that does not really correspond to a phone, just because it follows the phone number pattern).

MESSAGE_USR is a field of text type. As such, it is searchable: it is possible to search for specific words the user might have said.

Furthermore, it has been processed through an ElasticSearch analyzer adapted to the specific language used. This means that searches are able to match related words (e.g., plural versions of a singular query word, or verb conjugations). Phrase searches are also possible (by using double quotes around the phrase). If a phrase (several words) is used as a query without the quotes, ElasticSearch interprets it as a query for any of the words, so it will return all data elements that contain any of the words in the query.

In Kibana, more sophisticated text searches can be made by switching Lucene query syntax: proximity queries (words close to each other), fuzzy searches (query words allowing typos), wildcards, etc.

MESSAGE_USR_NORM

This is a normalized version of MESSAGE_USR, in which the user text has been streamlined by:

Converting all the sentence to lowercase
Removing all punctuation
Removing any extra spaces

Furthermore, this field is not processed through a language-dependent analyzer as MESSAGE_USR is, so queries on this field must match words exactly. It is still a text type field. However, the same query language can be used.

MESSAGE_AURA

This contains the text message generated by Aura and sent to the user as response to the user query. It is a text type field, so it is possible to search for specific words in it.

In the current version of Aura KPIs logs, this field only contains the text response. Some Aura use cases do not generate a purely textual message, but a more elaborated one (e.g., a card with text and graphics). These complex answers are inserted as attachments into Aura’s response to the channel and since attachments are not logged into the MESSAGE field, this field will appear empty in those cases. So, an empty MESSAGE_AURA field does not necessarily mean that Aura did not provide an answer. As an alternative for those situations, looking at the DIALOG_ID field (or INTENT) may give a hint of the type of answer that Aura delivered.

 MODALITY_CD_USR

This field contains the modality in which the user sent the message.

It is a slightly transformed field because there are some variations across Aura versions and, in order to unify it, the modalities are consolidated into only four different keywords: audio (spoken message), text (written free-text message) o form (commands sent via automatic processing or menus).

 DIALOG_ID

This field contains the identifier for the user case dialog module at the aura-bot Framework that was selected to construct the Aura response.

Dialog identifiers have two components (library  and dialog) separated by a colon e.g., services:service-usage

This field uses a custom analyser that splits the identifier at the colon, generating two terms. This makes possible to construct queries with one of the terms, e.g., “give me all the elements for the domain services”. But being a text field makes it impossible to do aggregations on it, so it cannot be used for statistics like bar charts (use DIALOG_ID.keyword for that).

DURATION_NU

This number reflects the time that took Aura to understand, process and respond to the user message. It is the difference (in milliseconds) between the timestamp of the moment the user message was received and the timestamp in which Aura’s response was finalized and sent to the channel.

Note that it is not a complete end-to-end delay time from the user’s point of view, since it does not include either the time it took the request to arrive to Aura through the channel or the time it took the response to travel back through the channel and get rendered at the client application (those times are outside Aura, and as such not registered by it).

Session Information

Session information includes the fields: sesId, sesSize, sesDuration.

These fields are generated by running a process over the time series formed by interactions from each user at each channel.

A session is automatically identified as a consecutive list of such user’s interactions, each separated from the next by a time interval shorter than 5 minutes. Once each session is identified, it is tabulated and labelled with three fields:

 sesId: string, forming a unique identifier for the session. It should be considered as an opaque identifier and the guarantee is that no other session in the data stream carries the same identifier.
As an aside, interactions that do not correspond to actual user interactions (because no user could be identified or because the datapoint corresponds to an interaction not triggered by the user) are all labelled with a <void> sesId.
 sesSize: number of interactions this session contains. This is labelled only for the first interaction in the session, all other interactions carry a 0 in this field. Non-sessions such as the ones with <void> sesId will be left empty. This facilitates computing averages or other statistics on valid sessions, by just first filtering out all zero and empty values.
 sesDuration: time duration for each session, counted from the instant the first user message was received, to the instant the last Aura message was sent. For single-interaction sessions its value will be the same as DURATION_NU, for multiple interactions it will contain the time interval between all of them.

As with sesSize, only the first interaction in a session is annotated with sesDuration; the remaining interactions will be assigned a 0 value (and interactions that do not correspond to a session will be left empty). Therefore, to compute statistics on sesDuration, remove the 0 and empty values first.

userType

This field may be used, in certain cases, to help identify rows that do not correspond to real users but to test users (internal users that belong to test/QA teams and whose behaviour is, therefore, not representative of actual Aura users).

The field contains a single character, which is s for standard (real) users, and can be Q or T for QA/Test users respectively (there are also lowercased versions q and t, referring to unconfirmed test users).

Note that test user identification is not available on every country, since it depends on having a register of the AURA_GLOBAL_ID identifiers that QA/Test users authenticate and this is not always available.

usrMsgSig

This field is not useful by itself. Instead, it is intended to be used to help grouping together very similar user utterances. It does so by generating a signature of the utterance that is (hopefully) insensitive to small variations in the sentence.

This is an experimental field; it might change if we reach a variant that is better suited for its purpose.

The way to generate this signature is by following these steps with the utterance:

Start with the normalized utterance (i.e., MESSAGE_USR_NORM).
Perform stemming (removal of word suffixes) on all the words. This makes bills and bill the same word.
Substitute words from a fixed list of very common, uninformative tokens (stopwords) by an asterisk. For example, this converts both “get my bill” and “get the bill” to the same phrase “get * bill”.
Group words in sets of 3 elements (trigrams) and sort them alphabetically. This removes the global structure of the sentence, while retaining local structure.

The resulting string is a non-understandable version of the original utterance (hence, it cannot be used by itself), but the fact that several very similar utterances produce the same signature helps cluster those utterances. An example is one of the preinstalled visualizations “Most Frequent User Utterances” which uses this field to group very similar utterances.

Another example is provided in the following figure, which shows message utterances generating the same signature:

As it can be seen, the signature is the same for “how can I upgrade” and “when can I upgrade”, “when does my contract end” and “when is my contract ending”, and “live chat” & “live chats”. So, they would be counted together when aggregating by signature.

The procedure has its limitations and, as explained, it is experimental, so we are trying to improve it, but it can already alleviate a bit the inherent variability in user expressions.

AuraMsgGroup

Messages produced by Aura are as generated by its text resource database. In some cases, the same category of message produces different output texts, maybe because the message includes some user-dependent parameter or because the text database contains several variants of the same text (and Aura picks one at random).

The AuraMsgGroup field is a keyword field that helps categorize Aura answer by abstracting away some of this variation. It classifies the response given by Aura into two types of elements:

Generic group: a name such as <NONE>, <GREETING> or <NOTFOUND>, which corresponds to a response category (see Table 3)
Truncated answer: for answers that do not have a defined generic group, as a fallback the literal answer text is inserted, after substituting all numbers in it with a placeholder and truncating it (i.e., retain only the first characters).

The following table contains the generic groups defined so far. They correspond to the most frequent Aura messages. It is country-dependent, since it also depends on the use cases deployed in each country. As said above, responses not falling into these groups will be assigned a truncated version of the response text.

Note that th emost frequent Aura messages list can be enlarged with time. Also, the correspondence between Aura messages and groups is not static, if the text database is updated with new variants, it will be necessary to also update the translation table in the PPD cleaner process that generates this field.

Group	Meaning
EMPTY	No textual answer from Aura (see note in Section MESSAGE_AURA for the usual meaning of no text answer)
NONE	Aura says it did not understand the user utterance
ERR	There was a processing error of some kind at Aura side, and the request could not be fulfilled
GREETING	Aura is greeting the user
GOODBYE	Aura is acknowledging a conversation end
YOU-ARE-WELCOME	Aura is accepting a compliment
CHURN	Aura recognizes the user intention to terminate a contract
NOTFOUND	Aura tried to search for some bit of data concerning the user query, and could not find it
CANNOT	Aura cannot fulfil the user request because of insufficient information (in the query, or on user data)
BILL-INFO	The user requested information about her bill, and Aura is returning it
DATA-INFO	The user requested information about her data usage, and Aura is returning it

: The list can be enlarged with time. Also, the correspondence between Aura messages and groups is not static, if the text database is updated with new variants, it will be necessary to also update the translation table in the PPD cleaner process that generates this field.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Aura Context global data model

Description of the global model in which Aura Context data is structured

Introduction

Aura Context data is structured in context fields, each of them defined by a pair name-value.

This model is common for all developers willing to use Aura Context: Aura Global Team defines and manages the model and uploads data from Aura modules, channels or devices into the Aura Context database.

An Aura Context developer:

Can consume this data directly, if the global data model is fully compatible with his own data model, or
Can use a transform or a file schema in order to modify or add new fields to the database

Certain key considerations regarding the Aura Context global data model are included below:

Different Aura components, channels or devices can upload data to certain specific fields of the global database.
It is possible to have fields with no filled data in the database due to several reasons. For example: in a specific lapse of time, information has not been sent from a module, channel or device; a specific channel is not available, thus its associated fields are not of application, etc.
However, there are certain mandatory fields that correspond to the table “Identification fields” of the database that must be always filled. These fields cannot be modified via an Aura Context transform.
The storage of data into the database is always based on:
- A user, identified by the field aura:idGlobal
- An interaction, identified by the field aura:corrId
The name of the field is different from the name of the field that is stored in the database. Both are included in columns 1 and 2 of the following tables.

Identification fields

Name	Name in database	Format	Semantics	Current Aura Context version
`aura:idGlobal`	`aura_id_global`	string (UUID)	`aura_id_global` for the user	✔️
`aura:userId`	`user_id`	string (UUID)	`userId` in the OB	✔️
`aura:corrId`	`corr`	string (UUID)	`corr_id` corresponding to the current interaction	✔️
`aura:timestamp`	`timestamp`	ISO 8601 (UTC, with milliseconds)	First transaction storage timestamp	✔️ (automatically filled)
`aura:timestampLastUpdate`	`timestamp_last_update`	ISO 8601 (UTC, with milliseconds)	Last timestamp update of this interaction	✔️ (automatically filled)
`aura:activeMsisdn`	`active_msisdn`	string (country prefix and MSISDN integer number)	Currently active MSISDN of the interaction. Empty if a MultiMSISDN user is logged with user/pass.	✔️ (phoneNumber)
`aura:userType`	`data.user_type`	enum string: monoMSISDN, multiMSISDN, anonymous, etc.	Type of Aura user	✔️
`aura:subscriptionType`	`subscription_type`	enum string: prepaid, postpaid, control, other	Type of user subscription. Empty, if a multiMSISDN user is logged with user/pass.	✔️
`aura:accountNumber`	`account_number`	string	User AccountNumber in TV use cases. Empty for other use cases.	✔️

Application

Name	Name in database	Format	Semantics	Current Aura Context version
`application:id`	`application_app_id`	string (UUID or similar)	Unique identifier for the application (it changes with each application version)	✔️
`application:channelName`	`application_app_channel_name`	string	Canonic name of the channel where the request is sent by the user	✔️ (prefix format)
`application:contextFilters`	`application_app_context_filters`	Array of strings	`application:contextFilters` semantics. String to filter the final response sent by aura-bot instance back to the Telefónica client. I.e., to determine the most appropriate answer to a generic question. The format of each entry of the array should be `key:value`, where both key and value are application dependant.	✔️
`application:playId`	`application_app_play_id`	string (integer, UUID or similar)	Identifier for the content being played (local or remote)	✔️
`application:playMode`	`application_app_play_mode`	string: `local` or `remote`	Content playing mode set in the application	✔️
`application:playType`	`application_app_play_type`	string: `live`, `catchup`, `vod`, etc.	Content type being played	✔️
`application:playServiceId`	`application_app_play_service_id`	string	Identifier of the service to be played	✔️
`application:playServiceUID`	`application_app_play_service_uid`	string	Unique Identifier of the service being played	✔️
`application:playLiveProgramId`	`application_app_play_live_program_id`	string	Identifier of the show being played	✔️
`application:timezone`	`application_app_timezone`	IANA timezone	Timezone configured at the application/client	✔️
`application:userAction`	`application_app_user_action`	string, app-dependent. Eg: `playContent`, `searchContent`, `viewAccountDetails`, `phoneCall`, etc.	A token describing the action the user was carrying on in the device that generated the request when the Aura request was launched	Field currently not filled
`application:interfaceLanguage`	`application_app_interface_language`	string: ISO 639-1 + ISO 3166 (joined by underscore)	Language in which the application is configured	✔️
`application:channelDataVersion`	`application_app_channel_data_version`	string	Version sent in the channel request	✔️
`device:id`	`application_device_id`	string (UUID or similar)	Unique identifier for the device running the application	✔️ (from device)
`device:type`	`application_device_type`	string: `homebase`, `ios.cell`, `android.cell`, `ios.tablet`, `android.tablet`, `pc`	Device class	✔️ (from device)
`application:screenId`	`application_app_screen_id`	string (application dependent)	Identifier designating the application section/screen where the Aura request came from	✔️
`application:screenElements`	`application_app_screen_elements` Name in the database for internal sub-fields: `ucid`; `type`; `resume_time`; `live_program_id`; `focus`	Array of maps showing content in the device. Each map has these fields: `ucid`: string; `type`: string; `resumeTime`: string; `liveProgramId`: string; `focus`: boolean	List of elements that appears in the application screen. It could be empty.	✔️
`output:showSuggestions`	`application_output_show_suggestions` Name in the database for internal sub-fields: `suggestion_id`; `intent`; `entities`; `type`; `value`; `canon`; `label`; `score`; `text`; `timestamp`; `show_to_user`	Array of maps with suggestions sent to the channel: `suggestion_id`: string; `intent`: string; `entities`: array of maps; `type`: entity-type; `value`: entity-value; `canon`: canon-value; `label`: label-value; `score`: score-value; `text`: string; `timestamp`: ISO 8601; `show_to_user`: boolean	List of suggestions shown to the user. Each has a unique identifier (`suggestion_id`) to correlate the effect on the next user’s action and contains a timestamp of the approximate moment when it was shown to the user. The rest of elements are the suggestion components, including intent, entity types (useful for further semantic analysis on analytical models), entities and the current text shown. The field `show_to_user` tells whether the suggestion has been shown to user by the channel.	Field currently not filled

Environment

Name	Name in database	Format	Semantics	Current Aura Context version
`location:logical`	`environment_location_logical`	string: home, outsidehome	Current logical location for the user	✔️

Conversation

Name	Name in database	Format	Semantics	Current Aura Context version
`input:modality`	`conversation_input_modality`	string: `voice`, `text`, `form`	Modality for the input user interaction	✔️
`input:utterance`	`conversation_input_utterance`	string	Utterance sent by the user. Empty if auraCommand.	✔️
`input:command`	`conversation_input_command`	string	Stringified of the auraCommand object	✔️
`recog:module`	`conversation_recog_module`	string: `nlp`, `value`, `text`, `command`	A string identifying the module that was responsible for the NLP decision	✔️
`recog:domain`	`conversation_recog_domain`	string	Domain recognized by NLP	Field currently not filled
`recog:resultList`	`conversation_recog_result_list` Name for internal sub-fields: `id`; `score`	`id`: string; `score`: number	List of recognized results (up to 3), ordered by they corresponding scores.	✔️
`recog:entities`	`conversation_recog_entities` Name for internal sub-fields: `type`; `value`; `canon`; `label`; `score`	Array of maps: `type`: entity-type; `value`: entity-value; `canon`: canon-value; `label`: label-value; `score`: score-value	List of recognized entities, regarding only to the first intent returned during the main recognition phase	✔️
`recog:negativity`	`conversation_recog_negativity`	double: value in [0, 1]	Level of negative sentiment identified by a trained model	Field currently not filled
`dialog:intents`	`conversation_dialog_intents`	array of strings	Each intent redirection made by the bot will add the name of the intent to the list.	Currently, only redirections with contex-filter are stored
`dialog:ids`	`conversation_dialog_ids`	array of strings	Each dialog redirection made by the bot will add the id of the dialog to the list.	Currently, only first dialog id is stored
`output:text`	`conversation_output_text`	string	Message sent back to the user	✔️
`output:speak`	`conversation_output_speak`	string	Spoken message sent back to the user	✔️
`output:suggestions`	`conversation_output_suggestions` Name for internal sub-fields from ‘suggestions’: `type`; `value`; `canon`; `label`; `score`	Array of suggestion results. A suggestion is a map with type, id and (optionally) an array of entities as a map. The entities array contains: `type`: entity-type; `value`: entity-value; `canon`: canon-value; `label`: label-value; `score`: score-value	Produced list of suggestions	✔️

User

Name	Name in database	Format	Semantics	Current Aura Context version
`userProductList`	`user_user_product_list`	array of strings	List of products/services contracted by the user	Field currently not filled
`videoProfileName`	`user_video_profile_name`	string	The video profile assigned to the user	Field currently not filled

Data model in Kernel

The process of data storage in Kernel is automatic and transparent for developers.

Information is stored in Kernel datasets using URM format. These specific datasets are:

Aura_Agent_Context

{
  "namespace": "com.plainAVRO",
  "name": "Aura_Agent_Context",
  "type": "record",
  "doc": "Contains the data for Aura context stored by agents for each user and correlator",
  "x-fp-version": "5.9.0",
  "fields": [
    {
      "name": "OPERATOR_ID",
      "aliases": [
        "operator_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Global Operator Identifier (Operator acting as owner of the information present in the current entity)"
    },
    {
      "name": "USER_4P_ID",
      "aliases": [
        "user_4p_id"
      ],
      "type": {
        "type": "string",
        "x-fp-user-id": true
      },
      "doc": "Identifier of the user in 4th Platform (as returned by the OB in the 4th Platform APIs)"
    },
    {
      "name": "RECORD_ID",
      "aliases": [
        "record_id"
      ],
      "type": "string",
      "doc": "Id for the record in context"
    },
    {
      "name": "AGENT_DES",
      "aliases": [
        "agent_des"
      ],
      "type": "string",
      "doc": "Agent name using context"
    },
    {
      "name": "FIELD_DES",
      "aliases": [
        "field_des"
      ],
      "type": "string",
      "doc": "Agent stored field name"
    },
    {
      "name": "VALUE_DES",
      "aliases": [
        "value_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Agent stored field value"
    },
    {
      "name": "PARTITION_TM",
      "aliases": [
        "partition_tm"
      ],
      "type": {
        "type": "string",
        "logicalType": "datetime"
      },
      "doc": "Date-time of the record, for data partitioning purposes"
    }
  ]
}

Aura_Context

    {
      "name": "APPLICATION_APP_PLAY_ID",
      "aliases": [
        "application_app_play_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Identifier for the content being played"
    },
    {
      "name": "APPLICATION_APP_PLAY_MODE_DES",
      "aliases": [
        "application_app_play_mode_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Content playing mode set in the application"
    },
    {
      "name": "APPLICATION_APP_PLAY_TYPE_DES",
      "aliases": [
        "application_app_play_type_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Content type being played"
    },
    {
      "name": "APPLICATION_APP_PLAY_SERVICE_ID",
      "aliases": [
        "application_app_play_service_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Identifier of the service being used to played"
    },
    {
      "name": "APPLICATION_APP_PLAY_SERVICE_U_ID",
      "aliases": [
        "application_app_play_service_u_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Unique identifier of the service being played"
    },
    {
      "name": "APPLICATION_APP_PLAY_LIVE_PROGRAM_ID",
      "aliases": [
        "application_app_play_live_program_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Identifier of the show being played"
    },
    {
      "name": "APPLICATION_APP_TIMEZONE_DES",
      "aliases": [
        "application_app_timezone_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Timezone configured at the application/client"
    },
    {
      "name": "APPLICATION_APP_USER_ACTION_DES",
      "aliases": [
        "application_app_user_action_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "A token describing the action the user was carrying on in the device that generated the request when the AURA request was launched"
    },
    {
      "name": "APPLICATION_APP_INTERFACE_LANG_ID",
      "aliases": [
        "application_app_interface_lang_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Language the application is configured in"
    },
    {
      "name": "APPLICATION_APP_CHANNEL_DATA_VERSION_DES",
      "aliases": [
        "application_app_channel_data_version_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Version sent in the request of the channel"
    },
    {
      "name": "APPLICATION_APP_SCREEN_ID",
      "aliases": [
        "application_app_screen_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "An identifier designating the application section/screen where the AURA request came from"
    },
    {
      "name": "APPLICATION_APP_SCREEN_ELEMENTS_ID",
      "aliases": [
        "application_app_screen_elements_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Elements that appear in the screen of the application"
    },
    {
      "name": "APPLICATION_DEVICE_ID",
      "aliases": [
        "application_device_id"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "A unique identifier for the device running the application"
    },
    {
      "name": "APPLICATION_DEVICE_TYPE_DES",
      "aliases": [
        "application_device_type_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "The device class"
    },
    {
      "name": "APPLICATION_OUTPUT_SHOW_SUGGESTIONS_DES",
      "aliases": [
        "application_output_show_suggestions_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Suggestions shown to the user"
    },
    {
      "name": "ENVIRONMENT_LOCATION_LOGICAL_DES",
      "aliases": [
        "environment_location_logical_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Current logical location for the user"
    },
    {
      "name": "CONVERSATION_INPUT_MODALITY_DES",
      "aliases": [
        "conversation_input_modality_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Modality for the input user interaction"
    },
    {
      "name": "CONVERSATION_INPUT_UTTERANCE_DES",
      "aliases": [
        "conversation_input_utterance_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Utterance sent by the user"
    },
    {
      "name": "CONVERSATION_INPUT_COMMAND_DES",
      "aliases": [
        "conversation_input_command_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Stringified of the Aura Command object"
    },
    {
      "name": "CONVERSATION_RECOG_MODULE_DES",
      "aliases": [
        "conversation_recog_module_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "A string identifying the module that was responsible for the NLP decision"
    },
    {
      "name": "CONVERSATION_RECOG_DOMAIN_DES",
      "aliases": [
        "conversation_recog_domain_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Domain recognized by NLP"
    },
    {
      "name": "CONVERSATION_RECOG_RESULT_TYPE_DES",
      "aliases": [
        "conversation_recog_result_type_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Type of result produced by NLP"
    },
    {
      "name": "CONVERSATION_RECOG_RESULT_LIST_DES",
      "aliases": [
        "conversation_recog_result_list_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Recognized results with their scores"
    },
    {
      "name": "CONVERSATION_RECOG_ENTITIES_DES",
      "aliases": [
        "conversation_recog_entities_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Recognized entities"
    },
    {
      "name": "CONVERSATION_RECOG_NEGATIVITY_QT",
      "aliases": [
        "conversation_recog_negativity_qt"
      ],
      "type": [
        "null",
        "float"
      ],
      "doc": "Grade of negative sentiment identified by a trained model"
    },
    {
      "name": "CONVERSATION_DIALOG_INTENTS_DES",
      "aliases": [
        "conversation_dialog_intents_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Each intent redirection made by the bot"
    },
    {
      "name": "CONVERSATION_DIALOG_IDS_DES",
      "aliases": [
        "conversation_dialog_ids_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Each dialog redirection made by the bot"
    },
    {
      "name": "CONVERSATION_OUTPUT_TEXT_DES",
      "aliases": [
        "conversation_output_text_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Message sent back to the user"
    },
    {
      "name": "CONVERSATION_OUTPUT_SPEAK_DES",
      "aliases": [
        "conversation_output_speak_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Message to be spoken sent back to the user"
    },
    {
      "name": "CONVERSATION_OUTPUT_SUGGESTIONS_DES",
      "aliases": [
        "conversation_output_suggestions_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Produced suggestions"
    },
    {
      "name": "USER_USER_PRODUCT_LIST_DES",
      "aliases": [
        "user_user_product_list_des"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "Products/services contracted by the user"
    },
    {
      "name": "USER_VIDEO_PROFILE_NAME",
      "aliases": [
        "user_video_profile_name"
      ],
      "type": [
        "null",
        "string"
      ],
      "doc": "The video profile assigned to the user"
    },
    {
      "name": "PARTITION_TM",
      "aliases": [
        "partition_tm"
      ],
      "type": {
        "type": "string",
        "logicalType": "datetime"
      },
      "doc": "Date-time of the record, for data partitioning purposes"
    }

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Install and configure in Aura Virtual Assistant

Install components in Aura Virtual Assistant, customize your system once deployed through the activation/deactivation of features and adapt the configuration to your requirements

Introduction

Once Aura Virtual Assistant is deployed, OBs can adapt their system to their specific requirements and users need in terms of components, types of clients, demanded experiences, etc. Tasks in this section can be organized in four groups:

Installation of components in Aura Virtual Assistant

Get started with Aura Bot: install and configure aura-bot
Install global use cases: guidelines for the installation of global use cases and global dialogs in charge of their logic.

Activation of features

After deployment, learn how to activate or deactivate features in Aura such as the aura-file-manager

Configure Aura

Use the Aura configuration updater to easily change channels configuration and POEditor resources.

Keda configuration

Guidelines for the configuration of Keda, used for the autoscaling of pods

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes cluster monitoring dashboard

Information provided by Kubernetes cluster monitoring dashboard

Introduction

Kubernetes cluster monitoring dashboard monitors multiple systems and networks related data from Kubernetes clusters.

The available metrics are defined in the following sections.

Network I/O pressure graph

Rate of total received/sent data on all cluster containers, in bytes and aggregated by one minute.

Metrics:
It includes two metrics:

Received bytes

sum (rate (container_network_receive_bytes_total{kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m]))

Sent bytes (negative value)

- sum (rate (container_network_transmit_bytes_total{kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m]))

Graph visual

Total usage

Graphs with different system parameters usage.

Cluster memory usage

It is composed by three graphs:

Memory usage, showing percentage of used memory
Used, showing used memory
Total, showing total memory

Metrics:
It includes three metrics:

Memory usage percentage

sum (container_memory_working_set_bytes{id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) / 
sum (machine_memory_bytes{kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) * 100

Used memory

sum (container_memory_working_set_bytes{id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"})

Total cluster memory

sum (machine_memory_bytes{kubernetes_io_hostname=~"^.*$",agentpool=~".*"})

Cluster CPU usage

It is composed by three graphs:

CPU usage, showing percentage of used CPU cores, aggregated by one minute
Used, showing used CPU cores, aggregated by one minute
Total, showing total CPU cores

Metrics:
It includes three metrics:

CPU usage percentage

sum (rate (container_cpu_usage_seconds_total{id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) / 
sum (machine_cpu_cores{kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) * 100

Used CPUs

sum (rate (container_cpu_usage_seconds_total{id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m]))

Total cluster CPUs

sum (machine_cpu_cores{kubernetes_io_hostname=~"^.*$",agentpool=~".*"})

Cluster filesystem usage

It is composed by three graphs:

Filesystem usage, showing percentage of used filesystem space
Used, showing used filesystem space
Total, showing total filesystem space

Metrics:
It includes three metrics:

Filesystem usage

sum (container_fs_usage_bytes{device=~"^/dev/.*$",id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) / 
sum (container_fs_limit_bytes{device=~"^/dev/.*$",id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) * 100

Used

sum (container_fs_usage_bytes{device=~"^/dev/.*$",id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"})

Total

sum (container_fs_limit_bytes{device=~"^/dev/.*$",id="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"})

Graph visual

Pods CPU usage

CPU usage rate, classified by pod and aggregated by one minute.

Metrics:

sum (rate (container_cpu_usage_seconds_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (pod_name)

Graph visual

Containers CPU usage

CPU usage rate, classified by container and aggregated by one minute.

Metrics:
It includes two metrics:

Containers with “k8s_”

sum (rate (container_cpu_usage_seconds_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (pod_name)

Containers without “k8s_”

sum (rate (container_cpu_usage_seconds_total{image!="",name!~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (kubernetes_io_hostname, name, image)

Graph visual

All processes CPU usage

Total CPU usage rate, aggregated by one minute.

Metrics:

sum (rate (container_cpu_usage_seconds_total{id!="/",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (id)

Graph visual

Pods memory usage

Memory usage, classified by pod.

Metrics:

sum (container_memory_working_set_bytes{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) by (pod_name)

Graph visual

Containers memory usage

Memory usage, classified by container.

Metrics:
It includes two metrics:

Containers with “k8s_”

sum (container_memory_working_set_bytes{image!="",name=~"^k8s_.*",container_name!="POD",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) by (container_name, pod_name)

Containers without “k8s_”

sum (container_memory_working_set_bytes{image!="",name!~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) by (kubernetes_io_hostname, name, image)

Graph visual

All processes memory usage

Total memory usage rate.

Metrics:

sum (container_memory_working_set_bytes{pod_name!="",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}) by (pod_name)

Graph visual

Pods network I/O

Total network received/sent usage rate, classified by pod and aggregated by one minute.

Metrics:

Received bytes

sum (rate (container_network_receive_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (pod_name)

Sent bytes

- sum (rate (container_network_transmit_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (pod_name)

Graph visual

Containers network I/O

Total network received/sent usage rate, classified by container and aggregated by one minute.

Metrics:

Received bytes, containers with “k8s_”

sum (rate (container_network_receive_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (container_name, pod_name)

Sent bytes, containers with “k8s_”

- sum (rate (container_network_transmit_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (container_name, pod_name)

Received bytes, containers without “k8s_”

sum (rate (container_network_receive_bytes_total{image!="",name!~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (kubernetes_io_hostname, name, image)

Sent bytes, containers without “k8s_”

- sum (rate (container_network_transmit_bytes_total{image!="",name!~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (kubernetes_io_hostname, name, image)

Graph visual

All processes network I/O

Total network received/sent usage rate, aggregated by one minute.

Metrics:

Received bytes

sum (rate (container_network_receive_bytes_total{pod_name!="",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (pod_name)

Sent bytes

- sum (rate (container_network_transmit_bytes_total{pod_name!="",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (pod_name)

Graph visual

Pods disk I/O

Total disk reads/writes rate, classified by pod and aggregated by one minute.

Metrics:

Read bytes, pods without device

sum(rate(container_fs_reads_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device!=""}[1m])) by (pod_name)

Written bytes, pods without device

sum(rate(container_fs_writes_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device!=""}[1m])) by (pod_name)

Read bytes, pods with device

sum(rate(container_fs_reads_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device=""}[1m])) by (pod_name)

Written bytes, pods with device

sum(rate(container_fs_writes_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device=""}[1m])) by (pod_name)

Graph visual

Containers disk I/O

Total disk reads/writes rate, classified by container and aggregated by one minute.

Metrics:

Read bytes, containers without device

sum(rate(container_fs_reads_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device!=""}[1m])) by (container_name, pod_name)

Written bytes, containers without device

sum(rate(container_fs_writes_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device!=""}[1m])) by (container_name, pod_name)

Read bytes, containers with device

sum(rate(container_fs_reads_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device=""}[1m])) by (container_name, pod_name)

Written bytes, containers with device

sum(rate(container_fs_writes_bytes_total{image!="",name=~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*", device=""}[1m])) by (container_name, pod_name)

Read bytes, containers without “k8s_”

sum(rate(container_fs_reads_bytes_total{image!="",name!~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (kubernetes_io_hostname, name, image)

Written bytes, containerswithout “k8s_”

sum(rate(container_fs_writes_bytes_total{image!="",name!~"^k8s_.*",kubernetes_io_hostname=~"^.*$",agentpool=~".*"}[1m])) by (kubernetes_io_hostname, name, image)

Graph visual

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Guidelines for Jira management

Learn how to handle user stories and tasks in Jira

Analysis

Description	Tool	State
Create Analysis Task	JIRA	[X]
Create Analysis Documentation	Confluence	[X]
. . . Use cases		[X]
. . . Data model		[X]
. . . Component architecture		[X]
Create “doubt repository”	JIRA/Confluence	[X]
—
Have all doubts been resolved?		[X]
Has the result of the analysis been presented?		[X]
Have several alternatives been evaluated?		[X]
Has the chosen option been agreed upon?		[X]
Chosen solution meets the performance requirements?		[X]

Development

Description	Tool	State
Create branch “feat” for each task	GIT	[X]
Create unit tests	GIT	[X]
Create Documentation (README)	GIT	[X]
Add lint rules (standard)	GIT	[X]
Create jenkins tasks (if they don’t exist)	JENKINS	[X]
Check for missing jenkins tasks	JENKINS	[X]
—
Does the code pass all unit tests?		[X]
Do the unit tests cover 80% coverage?		[X]
Does the code comply with the lint rules?		[X]
Have the Jenkinsfile and pipelines been checked?		[X]
Is the README documentation up to date?		[X]

FAQs

What to do if you have to integrate with another development team?

If, for example, we are going to integrate something with the Cognitive Team, such as the new suggestions API, we will be talking to them integrated in the same team all the time.

But the moment we need them to pass us their swagger, whether their component is deployed or the update deployed, we will give them a task to do so.

How to upload the code to git?

To upload the code to git, Pull Request to master or release/* is performed depending on the moment.

We upload it when we have finished, with a disclaimer: if we are dependent on other teams that are going to call our API or use the modification for something, we will be especially careful and upload the changes when they are necessary and not to break their development.

Do I have to notify QA at the end of coding?

Yes, you have to notify them when a new feature or a fix is deployed in the corresponding environment.

If it is bug or complete US, passing them to resolved they are already warned, but I like more to give them a touch and tell them.

In addition to when we upload the code, I like to share the analysis and design pages with them, because the discussions are usually very productive.

Should we notify someone about the generated documentation?

We must notify María Eugenia, who is the documentary maker. The ideal is to leave indicated in each US/Bug which documentation has been modified with its development. María Eugenia takes the doc from aura-docs, from Confluence or from the corresponding repo and includes it in the product versions.

How do the tasks change states?

We must pass the US/bugs from “new” -> “in progress” -> “code review” -> “resolved”. Tasks in the “resolved” state go “closed” when QA validates them.

How do I change version of component or library?

We do this process with each release or phase change. The future is that everything is done automatically by Jenkins.