Aura Global use cases

Introduction

Global use cases are experiences already designed, developed and tested by Aura Platform Team.

OBs cannot modify their logic but use them as they are or get inspired for deploying their own experiences.

The current section includes:

• Global dialogs / libraries, that contain the logic for the management of different experiences:

  • Authentication dialogs, that manage different types of authentication in Aura.
  • generic-ai-dialogs that allow managing several experiences for TV channels using AI services and complex logic resolution.
  • generic-dialog that, currently, allows the implementation of certain experiences in TV channels.
  • Other global dialogs grouped as miscellaneous.

• Global use cases, as experiences that reach the final users:

• Aura video use cases, that provide different experiences for Telefónica customers related to video services.

• Use cases for testing Aura: libraries used by Aura Global Team for testing Aura Platform functionalities.

📃 Find guidelines for installing and using global experiences in your Aura system: Use global use cases.

ℹ️ With the introduction of the channelData normalized version (v3), these global dialogs will be progressively adapted to be compatible with this version. This information is included in the documentation of the specific dialogs where two versions (v1 and v3) are already available, together with the changes in the dialogs’ functionality that, for example, affect to video use cases.

Libraries configuration

aura-bot has the control to prepare and manage all configuration variables and make validations to get ready. In case that any validation fails, the set of libraries wrongly loaded will be shown and the bot will not start. If there is a problem with the scheme of an external library, the broken library should be extracted or fixed.

In order to validate schemas of the variables used in external libraries, it is optional that each library has an accessible scheme with the names of THEIR variables, default values, etc.

For example, there is a library that exposes a variable that contains a threshold that can be modified from outside that library. The developer´s library should create a schema (using @hapi/joi) specifying the name of the variable with the prefix of the library name (for example: LIBRARYNAME_THRESHOLD).

It is suggested that at the library level and within the src/ folder, a file named configuration-schema.ts is created, containing the configuration scheme like the one shown below:

import * as joi from 'joi';


const configurationSchema = {
    LIBRARYNAME_DEFAULT_GREETINGS: joi.string().default('hello'),
    LIBRARYNAME_COMMON_COUNT_GREETINGS: joi.number().default(1800)
};

export default configurationSchema;

In this first approach, there is no name validation (checking the prefix name of the variables).

Nomenclature for libraries variables

The naming of local library environment variables must follow these instructions:

1. Follow the structure: LIBRARYNAME_*.
2. If the environment variable is an endpoint: LIBRARYNAME_*_ENDPOINT.
3. If the environment variable is a Kernel endpoint: AURA_FP_*_ENDPOINT.
4. If the environment variable is a Kernel endpoint and is only used in one library or the use case uses a different API version than the global one: LIBRARYNAME_FP_*_ENDPOINT

Each library in this section includes its own variables.