Aura –

Docs:

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

Aura Configuration API environment variables

List of environment variables handled by Aura Configuration API

Properties marked in bold are mandatory.
Properties marked in italics are optional.

Property	Type	Description	Modifiable by OB?
AURA_BRANDS	string[]	List of available Telefónica brands configured in Kernel. Check them in the document Telefónica brands management.	YES
AURA_CONFIGURATION_APPLICATIONS_COLLECTION	string	Collection name to store Applications information. By default: `applications`.	NO
AURA_CONFIGURATION_APPLICATIONS_ENCRYPTED_FIELDS	string[]	List of fields that will be saved encrypted in a application document. By default: `['callback']`.	YES, but only for adding fields
AURA_CONFIGURATION_CHANNELS_COLLECTION	string	Collection name to store channel information. By default: `channels`.	NO
AURA_CONFIGURATION_CHANNELS_ENCRYPTED_FIELDS	string[]	List of fields that will be saved encrypted in a channel document. By default: `['security', 'whatsapp']`.	YES, but only for adding fields
AURA_CONFIGURATION_COMPONENTS_COLLECTION	string	Component name to store component information. By default: `components`.	NO
AURA_CONFIGURATION_DATABASE_NAME	string	Aura channels configuration database name. By default: `aura-configuration`.	NO
AURA_CONFIGURATION_EVENTS_ENABLED	boolean	Enable or disable the service synchronization by events.	true
AURA_CONFIGURATION_MAX_LENGTH_TO_LOG_BODY_FIELD	number	Maximum characters length to display body field in logs. By default `1024` characters.	NO
AURA_CONFIGURATION_SERVER_PORT	number	Aura channels configuration server port. By default: `8999`.	NO
AURA_CONFIGURATION_SKILLS_COLLECTION	string	Collection name to store Skills information. By default: `skills`.	NO
AURA_CONFIGURATION_SKILLS_ENCRYPTED_FIELDS	string[]	List of fields that will be saved encrypted in a skill document. By default: `[]`.	YES, but only for adding fields
AURA_CONTACT_CHANNELS	string[]	List of contact channels that will be used.	YES
AURA_ENCRYPTION_ALGORITHM	string	Encryption algorithm that will be used to validate the APIKey. By default: `aes-256-cbc`.	NO
AURA_ENCRYPTION_IV_LENGTH	number	Size for the initialization vector used by the encryption algorithm that validates the APIKey. By default: `16`.	NO
AURA_ENCRYPTION_IV_POSITION	number	Position where to insert the initialization vector in the final string with the encrypted payload. By default: `35`.	NO
AURA_ENCRYPTION_KEY	string	Encryption key or comma-separated list of encryption keys to be used in the environment. It is mainly used to decrypt the APIKeys.	NO. It would break database encrypted data and APIKey validation.
AURA_ENVIRONMENT_NAME	string	Name of the environment where aura-bridge is deployed. Used during aura-bridge make-up to handle the indexes of the database properly. For example: `ap-next`, `es-dev`, `de-pre`	NO
AURA_HTTP_PATHS_LOG_DISABLED	string[]	Paths to be ignored in the logHttpRequestResponse middleware: By default: `['/metrics']`.	YES
AURA_HTTP_MAX_REQUEST_SIZE	string	Maximum size of incoming requests bodies in bytes allowed by the server. By default: `20mb`.	YES
AURA_LOGGING_FORMAT	string	Format to be used in monitoring logs: `json` or `dev` (more visual format). By default: `json`.	NO. Only for development, set it to `dev`.
AURA_LOGGING_LEVEL	string	Level to be used in monitoring logs, from more to less verbose: `'TRACE', 'DEBUG', 'INFO', 'WARN', 'ERROR', 'FATAL', 'OFF'`. By default: `INFO`.	YES, for development set it to ‘DEBUG’. In pre/production should be ‘INFO’ or ‘ERROR’. For analysis of an issue in pre/production it may be changed to ‘DEBUG’
AURA_MAKEUP_MODE	string	Allow dev mode of the makeup with the value `local`. By default: `full`.	NO
AURA_MICROSOFT_AZURE_STORAGE_ACCESS_KEY	string	Microsoft Storage password of the deployment.	NO
AURA_MICROSOFT_AZURE_STORAGE_ACCOUNT	string	Microsoft Storage account of the environment.	NO
AURA_MICROSOFT_AZURE_STORAGE_AVRO_SCHEMAS_FOLDER	string	Contains the Microsoft Azure Storage Avro schemas folder. Default: ‘avro/schemas’.	NO
AURA_MICROSOFT_AZURE_STORAGE_CONFIGURATION_CONTAINER	string	Aura configuration container name. Default: ‘aura-configuration’.	NO
AURA_MONGODB_PASSWORD	string	MongoDB password to access `AURA_MONGODB_BOT_DATABASE` in `AURA_MONGODB_URI`.	NO
AURA_MONGODB_SSL	boolean	`true` if access to `AURA_MONGODB_URI` is `SSL`. By default: `false`.	NO
AURA_MONGODB_URI	string	MongoDB URI of the server handling `AURA_MONGODB_BOT_DATABASE`.	NO
AURA_MONGODB_USERNAME	string	MongoDB username to access `AURA_MONGODB_BOT_DATABASE` in `AURA_MONGODB_URI`.	NO
AURA_MONGODB_POOL_SIZE	number	Number of connections available in MongoDB pool. By default: `60`.	NO
AURA_MONGODB_MAX_POOL_SIZE	number	Maximum number of connections in the MongoDB pool. By default, `60`.	NO
AURA_MONGODB_MIN_POOL_SIZE	number	Minimum number of connections in the MongoDB pool. By default, `2`.	NO
AURA_MONGODB_MAX_IDLE_TIME_MS	number	Maximum idle time in milliseconds for connections in the MongoDB pool. By default, `30000` (30 seconds).	NO
AURA_MONGODB_RETRY_WRITES	boolean	`true` if retry writes are enabled in the MongoDB connection. By default, `true`.	NO
AURA_MONGODB_RETRY_READS	boolean	`true` if retry reads are enabled in the MongoDB connection. By default, `true`.	NO
AURA_MONGODB_HEARTBEAT_FREQUENCY_MS	number	Frequency in milliseconds of the heartbeat in the MongoDB connection. By default, `2000` (2 seconds).	NO
AURA_MONGODB_SERVER_SELECTION_TIMEOUT_MS	number	Timeout in milliseconds for server selection in the MongoDB connection. By default, `5000` (5 seconds).	NO
AURA_MONGODB_SOCKET_TIMEOUT_MS	number	Timeout in milliseconds for socket operations in the MongoDB connection. By default, `45000` (45 seconds).	NO
AURA_CONNECTION_TIMEOUT_MS	number	Timeout in milliseconds for establishing a connection to the MongoDB server. By default, `10000` (10 seconds).	NO
AURA_MONGODB_READ_PREFERENCE	string	Read preference for the MongoDB connection. By default, `primaryPreferred`. Possible values: `primary`, `primaryPreferred`, `secondary`, `secondaryPreferred`, `nearest`.	NO
AURA_REDIS_CONFIGURATION_PREFIX	String	Prefix for the key in Redis used to store configuration values. By default: `aura-config:`.	No
AURA_REDIS_CONNECTION_POOL_MIN	Number	Minimum number of connections in the pool. Default: `2`.	No
AURA_REDIS_CONNECTION_POOL_MAX	Number	Maximum number of connections in the pool. Default: `100`.
AURA_REDIS_DATABASE	Number	Database number for Single or Sentinel mode. By default: `0`.
AURA_REDIS_HOSTS	String	String with a list of nodes (host:port) separated by comma. For example: “localhost:port,localhost2:port2”. Default: ‘127.0.0.0:6379’	No
AURA_REDIS_MAX_RECONNECT_INTERVAL	Number	Time in milliseconds to wait before reconnecting to Redis. By default: `5000`.	No
AURA_REDIS_MAX_RECONNECT_RETRIES	Number	Number of retries to connect to Redis. By default: `25`.	No
AURA_REDIS_MODE	String	Mode of Redis distribution. Values: `Cluster`, `Sentinel` or `Single`. By default: `Single`.	No
AURA_REDIS_PASSWORD	String	A string with the password of Redis.	No
AURA_REDIS_SENTINEL_INSTANCE_NAME	String	Name of the Redis instance. Used in `Sentinel` mode.	No
AURA_REDIS_USE_CONNECTION_POOL	Boolean	Flag to indicate the use of a connection pool for Redis connections. Default: `true`.	No
AURA_SERVER_REMOTE_CONTAINER_PREFIX	string	Remote container prefix. Default: `aura-configuration-api`.	NO
AURA_SWAGGER_FROM_REMOTE	boolean	It indicates that swagger configuration will be loaded from remote. Default: `true`.	NO
AURA_SWAGGER_LOCAL_PATH	string	Swagger local path. Default: `swagger.yaml`.	NO
AURA_SWAGGER_PLUGIN_PATH	string	Swagger plugin path. Default: `swagger.yaml`.	NO
AURA_SWAGGER_LOCAL_CORE_PATH	string	Swagger local core path. Default: `swagger-core.yaml`.	NO
AURA_SWAGGER_REMOTE_CONTAINER_PREFIX	string	Remote container prefix to store the swagger information. Default: `swagger`.	NO
AURA_SHUTDOWN_GRACEFUL_TTL	number	Time in milliseconds to complete the SHUTDOWN signal and process all the messages in queue before SIGTERM. By default: `25 * 1000`.	YES
AURA_VERSION	string	Aura release	NO

Docs:

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

Synchronization by events

Description of the synchronization by events process

Introduction

Event-driven synchronization is a system that allows updating the configuration of any module in the components in real time.

This is done through events, which are emitted when a certain module modifies its configuration data, and allows the Aura components that are subscribed to the events to update their configuration in real time.

The synchronization by events operates as follows:

A service updates a certain configuration element.
The new updated data is stored in MongoDB.
An Event is published by the Event Manager. The current system supports two Event Managers, Redis Pub/Sub and DAPR.
When the event is issued, the services subscribed to the configuration events receive the Event.
The changes are requested through the aura-configuration-api.

Event management can be activated or deactivated in both the event transmission and reception parts. The environment variable that has the aura-configuration-api and the components that support this system is called AURA_CONFIGURATION_EVENTS_ENABLED. The environment variable AURA_CONFIGURATION_EVENTS_MANAGER determines the engine used for event handling, possible values are “REDIS” or “DAPR”.

Using Redis as Event Manager

Publishers and subscribers

In order for a component to update the configuration data that has been modified by another service, two types of elements are required:

Publishers, which are the ones that notify of the change
Subscribers, which are the ones that will receive an event indicating that a change has occurred and where it has taken place.

All this is managed through the broadcasting of events in Redis through a specific channel using the Pub/Sub module.

Channel

The name of the channel has the following structure: [AURA_REDIS_DATABASE]__:[AURA_REDIS_CONFIGURATION_PREFIX][ConfigCollectionName]*

This pattern will be used by most of the current components. If any of them need to manage identifiers within the channel, such as Agents, they will be subscribed to the channel: [AURA_REDIS_DATABASE]__:[AURA_REDIS_CONFIGURATION_PREFIX][ConfigCollectionName]:[Id]

Being:

AURA_REDIS_DATABASE: Environment variable with the number of database in Redis.
AURA_REDIS_CONFIGURATION_PREFIX: Environment variable whose default value is aura-config.
ConfigCollectionName: One of the following values: ChannelConfiguration, ApplicationConfiguration, SkillConfiguration, TvSectionsConfiguration, PresetConfiguration, AgentConfiguration.

Example:
1__:aura-config:ChannelConfiguration

Event Message

When the event is sent, it has the following format:

{ 
    collection: [ConfigCollectionName]  
    op:         [OPERATION];
    id:         [IDENTIFIER];
    configData: [CONFIGURATION_DATA]; 
    metadata:   [EVENT_METADATA]                (Dapr)
    pubSubName: [DAPR_PUBSUB_NAME];             (Dapr)
    crc:        [INTEGRITY];                    (Not implemented)
}

The different types of operations are (EventConfigOperation):

Create: When a record is created in the configuration. It will carry the identifier of the new record.
Update: When a record is modified in the configuration. It will carry the identifier of the updated record.
Delete: When a record is deleted in the configuration. It will carry the identifier of the deleted record.

The configuration data contains the updated or new configuration data. This field is not mandatory, and if the configuration data is empty the subscriptor refreshes its configuration calling directly the configuration API.

Examples:

Without configuration data

{
    "op":Create",
    "id":"88834434"
}

With configuration data
{
    "op":Create",
    "id":"88834434", 
    "configData": 
        {
            "name":"Expample1",
             "id":"88834434",
             .... 
         }
}

Publishers

The publishers are inside the aura-configuration-api.

When one of the configuration models writes to the MongoDB database, the event must be generated through Redis. This is done by instantiating an element of the RedisEventPublisher class. The creation of these update records in Redis has two requirements that must be met:

The API must contain an endpoint to obtain all the data from the model named GetAll.
The API must contain an endpoint to obtain an element of the model selected by its identifier named GetById.

To write the records in Redis that will generate the events, we will use the DAO of the model, specifically the method writeConfigurationEvent that is in charge of generating the registry for the event in Redis.

    // aura-configuration-api/src/common/dao.ts
    /**
     * Write configuration event.
     * @param {EventConfigOperation} operation Operation type
     * @param {string} id Id of the configuration
     * @param {T} data Data to write
     * @param {KeyValueType} metadata Metadata to write
     */
    protected async writeConfigurationEvent(operation: EventConfigOperation, id?: string, data?: T, metadata?: KeyValueType) {
        this.configurationEventPublish.op = operation;
        this.configurationEventPublish.id = id;
        this.configurationEventPublish.configData = data;
        this.configurationEventPublish.metadata = Object.assign({}, this.configurationEventPublish.metadata, metadata);

        await this.eventPublisher.publish(this.configurationEventPublish);
    }}

The eventPublisher can be one of Redis or DAPR. For Redis, the class with the methods to publish the event is included in /aura-configuration-api/src/utils/event-publishers/redis-event-publisher.ts

Generate events

When an event is generated, the operation that has been performed is indicated with the identifier of the record affected by the change.

    /**
     * Update channel.
     *
     * @throws {NoDataError} When it hasn't been updated
     * @throws {Error} When channel is invalid
     * @param {ChannelConfiguration} channel Channel configuration
     */
    public async update(channel: ChannelConfiguration) {
        channel.metadata = {
            ...(await this.channelCollection.findOne<ChannelConfiguration>(
                { id: channel.id }, { projection: { metadata: 1 } })
            )?.metadata,
            ...channel.metadata
        };
        const updateResult = await this.channelCollection.replaceOne(
            { id: channel.id }, this.prepareChannelToInsert(channel));
        if (updateResult?.modifiedCount === 0) {
            throw new NoDataError(`Channel with id: ${channel.id} cannot be found`);
        } else {
            await this.writeConfigurationEvent(EventConfigOperation.Update, channel.id);
        }
    }

Subscribers

Subscribers are inside the aura-utilities/aura-configuration library, and are the clients of each of the models in the aura-configuration-api.

These subscribers inherit their class from a base class BaseConfiguration that contains the necessary methods to manage the data. Some methods are common to all and others are specific. They include methods to manage the data locally, that is, if we receive the content of the changes in the event itself, we should be able to apply them on the current module without having to call the aura-configuration-api* to obtain them.

An example for the method of point 3 could be the following:

    /**
      * Update channel configuration.
      *
      * @param {Configuration} configuration Configuration object.
      * @param {EventConfigModel} message Event configuration model.
      * @returns {Promise<void>} Promise.
      */
    public async updateConfiguration(message: EventConfigModel<T>): Promise<void> {
        try {
            this.logger.debug({
                msg: 'UpdateChannelConfiguration executed', message,
                corr: CorrelatorUtil.auraSystem
            });

            switch (message.op) {
                case EventConfigOperation.Create:
                    try {
                        await this.createConfigurationById(message);
                    } catch (error) {
                        // if there is an error updating a single channel, update all the config with the current values
                        await this.load();
                    }
                    break;
                case EventConfigOperation.Update: {
                    try {
                        await this.updateConfigurationById(message);
                    } catch (error) {
                        // if there is an error updating a single channel, update all the config with the current values
                        await this.load();
                    }
                }
                    break;
                case EventConfigOperation.Delete:
                    if (this.removeLocal(message.id)) {
                        this.logger.debug({
                            msg: `Channel removed with id: ${message.id}`, corr: CorrelatorUtil.auraSystem
                        });
                    } else {
                        this.logger.warning({
                            msg: `Channel not found to remove with id: ${message.id}`, corr: CorrelatorUtil.auraSystem
                        });
                        await this.load();
                    }
                    break;

                default:
                    this.logger.warning({
                        msg: `Unknown operation: ${message.op} for configuration update: ${message.id}`,
                        corr: CorrelatorUtil.auraSystem
                    });
                    break;

            }
        } catch (error) {
            this.logger.error({
                msg: 'updateChannelConfiguration failed.', error: error.message, stck: error,
                corr: CorrelatorUtil.auraSystem
            });
        }
    }

The methods createConfigurationById and updateConfigurationById contain the logic to apply the changes locally or through the aura-configuration-api*.

    /**
     * Create channel configuration by id.
     * @param {Configuration} configuration Configuration object.
     * @param {EventConfigModel<ChannelConfiguration>} message Event configuration model.
     * @returns {Promise<void>} Promise.
     */
    private async createConfigurationById(message: EventConfigModel<T>): Promise<void> {
        // if the message has the configuration data, create the channel directly.
        if (message.configData && this.addLocal(message.configData)) {
            this.logger.debug({
                msg: `Channel added with new configuration: ${message.id}`, corr: CorrelatorUtil.auraSystem
            });
        } else {
            await this.loadById(message.id);
        }
    }

Using DAPR as Event Manager

Publishers and subscribers

In order for a component to update the configuration data that has been modified by another service, two types of elements are required:

Publishers, which are the ones that notify of the change.
Subscribers, which are the ones that will receive an event indicating that a change has occurred and where it has taken place.

All this is managed through DAPR Pub/Sub block. The engine selected to manage the PubSub is Redis. Unlike the pure PubSub management in Redis, which has the problem that if a subscriber does not receive the event, it will not be resent, with DAPR this does not happen since it takes care of the Event lifetime internally and manages the retries if needed.

Channel

In the DAPR Pub/Sub block, the concept of a channel is not applicable. In order to subscribe to an event, the name of the Pub/Sub module and the topic to be subscribed are required.

pubsubname: AURA_DAPR_CONFIGURATION_PUBSUB_NAME
topic: ConfigCollectionName

Being:

AURA_DAPR_CONFIGURATION_PUBSUB_NAME: Name of PubSub module defined in DAPR for Configuration Events.
ConfigCollectionName: One of the following values: ChannelConfiguration, ApplicationConfiguration, SkillConfiguration, TvSectionsConfiguration, PresetConfiguration, AgentConfiguration.

Event Message

DAPR uses a global event management model called CloudEvents. CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.

For compatibility reasons with the Event Managr in Redis, the name of the model used for Redis has been included within the field data of CloudEvents.

Example CloudEvent
{
  "data": {
    "collection": "ChannelConfiguration",
    "id": "c71dc728-5fe2-4735-927d-0c419b35ec59",
    "metadata": {
      "ttlInSeconds": "60"
    },
    "op": "Update",
    "pubSubName": "pubsub-config-ap-four"
  },
  "datacontenttype": "application/json",
  "expiration": "2025-06-30T08:16:05Z",
  "id": "a8340fb8-9071-4da9-91d6-7a14a409d459",
  "pubsubname": "pubsub-config-ap-four",
  "source": "aura-configuration-api",
  "specversion": "1.0",
  "time": "2025-06-30T08:15:05Z",
  "topic": "ChannelConfiguration",
  "traceid": "00-00000000000000000000000000000000-0000000000000000-00",
  "traceparent": "00-00000000000000000000000000000000-0000000000000000-00",
  "tracestate": "",
  "type": "com.dapr.event.sent"
}

Inside the data property, it has the following format:

{ 
    collection: [ConfigCollectionName]  
    op:         [OPERATION];
    id:         [IDENTIFIER];
    configData: [CONFIGURATION_DATA]; 
    metadata:   [EVENT_METADATA]                (Dapr)
    pubSubName: [DAPR_PUBSUB_NAME];             (Dapr)
    crc:        [INTEGRITY];                    (Not implemented)
}

The different types of operations are (EventConfigOperation):

Create: When a record is created in the configuration. It will carry the identifier of the new record.
Update: When a record is modified in the configuration. It will carry the identifier of the updated record.
Delete: When a record is deleted in the configuration. It will carry the identifier of the deleted record.

The configuration data contains the updated or new configuration data. This field is not mandatory and if the configuration data is empty, the subscriptor refreshes its configuration calling the aura-configuration-api.

The metadata is used to manage the behavior of the event. In this case it uses a { "ttlInSeconds": "60" } to set the expiration time of the event. The pubSubName contains the AURA_DAPR_CONFIGURATION_PUBSUB_NAME.

Examples:

Without configuration data:


{
    "collection": "ChannelConfiguration",
    "id": "c71dc728-5fe2-4735-927d-0c419b35ec59",
    "metadata": {
      "ttlInSeconds": "60"
    },
    "op": "Update",
    "pubSubName": "pubsub-config-ap-four"
  }

With configuration data:

{
    "collection": "ChannelConfiguration",
    "id": "c71dc728-5fe2-4735-927d-0c419b35ec59",
    "metadata": {
      "ttlInSeconds": "60"
    },
    "op": "Update",
    "pubSubName": "pubsub-config-ap-four",
    "configData": 
        {
            "name":"Expample1",
             "id":"88834434",
             .... 
         }
}

Publishers

The publishers are inside the aura-configuration-api.

The API must contain an endpoint to obtain all the data from the model named GetAll.
The API must contain an endpoint to obtain an element of the model selected by its identifier named GetById.

To write the records in Redis that will generate the events, we will use the DAO of the model. The method writeConfigurationEvent generates the registry for the event in Redis.

    // aura-configuration-api/src/common/dao.ts
    /**
     * Write configuration event.
     * @param {EventConfigOperation} operation Operation type
     * @param {string} id Id of the configuration
     * @param {T} data Data to write
     * @param {KeyValueType} metadata Metadata to write
     */
    protected async writeConfigurationEvent(operation: EventConfigOperation, id?: string, data?: T, metadata?: KeyValueType) {
        this.configurationEventPublish.op = operation;
        this.configurationEventPublish.id = id;
        this.configurationEventPublish.configData = data;
        this.configurationEventPublish.metadata = Object.assign({}, this.configurationEventPublish.metadata, metadata);

        await this.eventPublisher.publish(this.configurationEventPublish);
    }

The eventPublisher can be Redis or DAPR. For DAPR, the class with the methods to publish the event is in /aura-configuration-api/src/utils/event-publishers/dapr-event-publisher.ts

Generate events

When an event is generated, the operation that has been performed is indicated with the identifier of the record affected by the change.

    /**
     * Update channel.
     *
     * @throws {NoDataError} When it hasn't been updated
     * @throws {Error} When channel is invalid
     * @param {ChannelConfiguration} channel Channel configuration
     */
    public async update(channel: ChannelConfiguration) {
        channel.metadata = {
            ...(await this.channelCollection.findOne<ChannelConfiguration>(
                { id: channel.id }, { projection: { metadata: 1 } })
            )?.metadata,
            ...channel.metadata
        };
        const updateResult = await this.channelCollection.replaceOne(
            { id: channel.id }, this.prepareChannelToInsert(channel));
        if (updateResult?.modifiedCount === 0) {
            throw new NoDataError(`Channel with id: ${channel.id} cannot be found`);
        } else {
            await this.writeConfigurationEvent(EventConfigOperation.Update, channel.id);
        }
    }

Subscribers

Subscribers in DAPR can be created in several ways. In this case, the “Programatic” type is used, that is, we are going to include an endpoint in our components so that DAPR can subscribe them to the PubSub. The endpoint (/dapr/subscribe) must respond with a subscription model that contains the pubSubName, the topic and the endpoint that is going to be in charge of processing the event. This type of subscription forces us to define 2 methods for DAPR.

Example:

    /**
     * Dapr Subscriptions.
     *
     */
    public daprSubscriptions() {
        this.app.get('/dapr/subscribe', (request: express.Request, response: express.Response) => {
            const subscriptions =
                [
                    {
                        pubsubname: ConfigurationManager.instance.environmentConfiguration.AURA_DAPR_CONFIGURATION_PUBSUB_NAME,
                        topic: ConfigCollectionName.ChannelConfiguration,
                        routes: {
                            default: '/dapr/processConfigurationEvents',
                        }
                    }
                ];

            response.status(200).send(subscriptions);
        });
    }

In the previous example, we are going to subscribe to one topic, that will receive the events about the channel configuration collection.

Once the event is received, we can use the same library that we use in Redis, aura-utilities/aura-configuration, since we share the data model.

Example:

    /**
     * Process configuration events.
     *
     */
    public processConfigurationEvents() {
        this.app.post('/dapr/processConfigurationEvents', async (request: express.Request, response: express.Response) => {
            try {
                const event = HTTP.toEvent({ headers: request.headers, body: request.body.toString() });
                const cloudEvent = (event || {}) as CloudEvent;
                const configModel = (cloudEvent.data || {}) as EventConfigModel<ChannelConfiguration>;
                switch (configModel.collection) {
                    case ConfigCollectionName.ChannelConfiguration:
                        // Update current channels configuration
                        this.logger.debug({
                            msg: 'Processing channel configuration events',
                            corr: CorrelatorUtil.auraSystem
                        });
                        await AuraCurrentChannelsConfiguration.instance
                            .updateConfiguration(configModel as EventConfigModel<ChannelConfiguration>);
                        break;
                    default:
                        this.logger.warning({
                            msg: `Unknown collection in configuration event: ${configModel.collection}`,
                            corr: CorrelatorUtil.auraSystem
                        });
                }
                response.status(200).send({ status: DaprResponseStatus.SUCCESS });
            } catch (error) {
                this.logger.error({
                    msg: 'Error processing configuration events',
                    error: error.message,
                    corr: CorrelatorUtil.auraSystem
                });
                response.status(500).json({ status: DaprResponseStatus.DROP, error: 'Internal Server Error' });
            }
        });
    }

It is important to indicate in the reponse that the event has been successfully processed.

Docs:

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

Aura Configuration API modules

Description of the different modules that compose Aura Configuration API

Introduction

Currently, aura-configuration-api contains the following modules:

Administration module

Module in charge of administration tasks:

Export of complete server information.
Export of information by modules.
Import of complete server information.
Import of information by modules.

Access detailed information about Administration module.

Channel module

Module responsible for managing all the information related to channels, including the configuration of each Aura channel as well as the libraries associated with each channel (replacement for the bot-response.json configuration file).

Add channel
Delete channel by id
Get channel by id
Get all channels
Get changed channels
Modify channel
Update channel

Access detailed information about Channel module.

Component module

Module responsible for managing all the information related to components, including the configuration of each Aura component.

Add new components
Delete component by name
Get component by name
Get all components
Update component by name
Modify component by name

Access detailed information about Component module.

Skill module

Module responsible for managing all the information related to skills, defining the following operations:

Add skill
Delete skill by id
Get skill by id
Get all skills
Get changed skills
Modify skill
Update skill

Access detailed information about Skill module.

Application module

Module responsible for managing all the information related to applications, defining the following operations:

Add application
Delete application by id
Get application by id
Get all applications
Get changed applications
Modify application
Update application

Access detailed information about Application module.

Library

Module responsible for managing all the information related to libraries, defining the following operations:

Add library by channel id
Delete all libraries by channel id
Delete library by id and channel id
Get library by id and channel id
Update library by channel id

From the functional point of view, this module depends on the aura-configuration-api channel module: server definition.

Prometheus

Module responsible for exposing metrics for monitoring and observability of Aura Configuration API using Prometheus. It provides metrics such as:

Aura component version (gauge)
Unhandled server errors (counter)
Outgoing message duration (summary)
Outgoing request duration (summary)

These metrics help track the health, performance, and errors of the API. Paths in metrics are normalized for aggregation. For more details, see the Prometheus metrics registration source code.

Access detailed information about Prometheus module.

Docs:

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

Aura Configuration API plugins

Description of the different plugins that compose Aura Configuration API

Introduction

Currently, aura-configuration-api contains the following plugins:

Preset plugin

Plugin responsible for managing all the information related to channels, including the configuration of each Aura preset, as well as the libraries associated with each preset.

Add preset
Delete preset by id
Get preset by id
Get all presets
Modify preset
Update preset

Access detailed information about the preset plugin.

TV section plugin

Plugin responsible for managing all the information related to TV Sections.

Add TV section
Delete TV section by id
Get TV section by id
Get all TV sections
Modify TV section
Update TV section

Access detailed information about the TV section plugin.

Agent plugin

Plugin responsible for the management of agents.

Access detailed information about the agent plugin.

Agent base plugin

Plugin responsible for the management of agents base.

Access detailed information about the agent base plugin.

Agent deployment plugin

Plugin responsible for managing the deployment of agents.

Access detailed information about the agent deployment plugin.

Routing filter plugin

Plugin responsible for managing the routing filters.

Access detailed information about the routing filter plugin.

Filter engine plugin

Plugin responsible for managing the engine routing filters.

Access detailed information about the engine filter plugin.

Docs:

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

Telefónica brands management

List of available Telefónica brands defined in Kernel

Introduction

The aura-configuration-api is responsible for the management of the different Telefónica brands for the identification of Aura channels and applications.

These brands are defined in Kernel within the D_Gbl_Brand global dimension entity.

The current document shows the available ones and the identifier, description and date for each of them.

Available brands

List of brands defined in Kernel D_Gbl_Brand global dimension entity.

ID	Description	Date
0101	O2 (Germany) GmbH & Co - DE	20211018T000000
0102	Merit - DE	20211018T000000
0103	Blau - DE	20211018T000000
0104	FONIC - DE	20211018T000000
0105	Ortel - DE	20211018T000000
0106	Ay Yildiz - DE	20211018T000000
0107	NetzClub - DE	20211018T000000
0108	NettoKom - DE	20211018T000000
0109	MSD SuperSelect (Media Saturn = Metro Group) - DE	20211018T000000
0110	Kaufland (k-classic mobil) - DE	20211018T000000
0111	WhatsAppSIM - DE	20211018T000000
0112	TürkeiSIM (previously: Tuerk Telekom) - DE	20211018T000000
0113	blauworld - DE	20211018T000000
0114	Whitelabel - DE	20211018T000000
0115	EinfachPrepaid (previously: Schlecker) - DE	20211018T000000
0116	Mobilka (Ortel) - DE	20211018T000000
0117	novamobil (previously: Norma) - DE	20211018T000000
0118	blauworld (Ortel) - DE	20211018T000000
0119	Tchibo Mobilfunk GmbH & Co KG - DE	20211018T000000
0120	Mobilka - DE	20211018T000000
0121	Aldi Talk - DE	20241018T000000
0201	Vivo - BR	20211018T000000
0202	Terra - BR	20211018T000000
0301	Movistar - AR	20211018T000000
0302	Tuenti - AR	20211018T000000
0401	Movistar - ES	20211018T000000
0402	Tuenti - ES	20211018T000000
0403	O2 - ES	20211018T000000
0501	O2 - GB	20211018T000000
0502	GiffGaff - GB	20211018T000000
0601	Movistar - CL	20211018T000000
0701	Movistar - CO	20211018T000000
0801	Movistar - MX	20211018T000000
0901	Movistar - PE	20211018T000000
1001	Movistar - UY	20211018T000000
1101	Movistar - VE	20211018T000000
1201	Movistar - EC	20211018T000000
1202	Tuenti - EC	20211018T000000
10000	Other - Unknown	20211018T000000

Brands by environment

List of brands defined in Kernel D_Gbl_Brand global dimension entity organized by environment.

ap-* environments

Channels for ap-* environments.

ID	Brand	Date
0101	O2 (Germany) GmbH & Co - DE	20211018T000000
0103	Blau - DE	20211018T000000
0201	Vivo - BR	20211018T000000
0401	Movistar - ES	20211018T000000
0403	O2 - ES	20211018T000000
0501	O2 - GB	20211018T000000
10000	Other - Unknown	20211018T000000

es-* environments

Channels for es-* environments.

ID	Brand	Date
0401	Movistar - ES	20211018T000000
0403	O2 - ES	20211018T000000
10000	Other - Unknown	20211018T000000

br-* environments

Channels for br-* environments.

ID	Brand	Date
0201	Vivo - BR	20211018T000000
10000	Other - Unknown	20211018T000000

de-* environments

Channels for de-* environments.

ID	Brand	Date
0101	O2 (Germany) GmbH & Co - DE	20211018T000000
0103	Blau - DE	20211018T000000
10000	Other - Unknown	20211018T000000

Docs:

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

Contact channels management

List of available Telefónica contact channels defined in Kernel

Introduction

The aura-configuration-api is responsible for the management of the different Telefónica contact channels for the identification of Aura channels.

These contact channels are defined in Kernel within the D_Gbl_Contact_Channel global dimension entity.

The current document shows the available ones and the identifier, description and date for each of them.

Available contact channels

List of contact channels defined in Kernel D_Gbl_Contact_Channel global dimension entity.

ID	Contact Channel	Date
1	OnLine (Website)	20220210T000000
2	Mobile App (Novum)	20220210T000000
3	Telephone (Voice)	20220210T000000
4	SMS	20220210T000000
5	MMS	20220210T000000
6	EMAIL	20220210T000000
7	WhatsApp	20220210T000000
8	Shop	20220210T000000
9	Facebook	20220210T000000
10	Facebook Messenger	20220210T000000
11	Twitter	20220210T000000
12	Instagram	20220210T000000
13	Tik Tok	20220210T000000
14	Social Network	20220210T000000
15	White Mail	20220210T000000
16	TV	20220210T000000
17	Distributor	20220210T000000
18	Partner	20220210T000000
19	Logistics	20220210T000000
20	Task force	20220210T000000
100	Other	20220210T000000

Contact channels by environment

List of contact channels defined in Kernel D_Gbl_Contact_Channel global dimension entity organized by environment.

ap-* environments

Channels for ap-* environments.

ID	Channel	Date
1	OnLine (Website)	20220210T000000
2	Mobile App (Novum)	20220210T000000
3	Telephone (Voice)	20220210T000000
7	WhatsApp	20220210T000000
9	Facebook	20220210T000000
10	Facebook Messenger	20220210T000000
16	TV	20220210T000000

es-* environments

Channels for es-* environments.

ID	Channel	Date
1	OnLine (Website)	20220210T000000
2	Mobile App (Novum)	20220210T000000
3	Telephone (Voice)	20220210T000000
7	WhatsApp	20220210T000000
16	TV	20220210T000000

br-* environments

Channels for br-* environments.

ID	Channel	Date
1	OnLine (Website)	20220210T000000
2	Mobile App (Novum)	20220210T000000
7	WhatsApp	20220210T000000
9	Facebook	20220210T000000
10	Facebook Messenger	20220210T000000
16	TV	20220210T000000

de-* environments

Channels for de-* environments.

ID	Channel	Date
1	OnLine (Website)	20220210T000000
2	Mobile App (Novum)	20220210T000000
9	Facebook	20220210T000000
10	Facebook Messenger	20220210T000000

Docs:

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

Aura Configuration APIs definition

Description of API swaggers for Aura Configuration

Introduction

The following API swaggers are available in aura-configuration-api: