Admin: Key concepts
Overview
RPI consists of Server and Client applications.
Server
The RPI Server consists of a number of services made available via container images, which can be hosted in a container orchestration platform (e.g. Kubernetes). Many RPI client applications can communicate with a single RPI server.
At least one of each of the following services must be available:
Execution service
Node Manager service
Interaction API web service
Optionally the following services may also be made available:
Realtime web service
Realtime Agent web service
Note that the above can be combined into a single web service.
Help website
In addition, the following service is used to install, upgrade and manage the RPI Server:
Configuration service
Execution service
The Execution service is responsible for executing server jobs generated by the undertaking of activities in the RPI client application—for example, the testing of an audience or execution of an interaction workflow. It is also responsible for the execution of asynchronous server-side jobs (e.g. catalog synchronization).
The RPI client communicates with the Execution service via the Interaction API web service. Most communication between the Interaction API service and the Execution service is conducted via the Pulse operational database. The Execution service polls the database regularly to pick up and process the next request.
Node Manager service
The Node Manager service undertakes the following tasks:
Management of RPI triggers, which are responsible for the initiation of activity in interaction workflows.
Allocation of work to an Execution service.
Queue Reader service
The Queue Reader service is responsible for the draining of queues used in the following contexts:
Queue listeners
RPI Realtime
Interaction API Web service
All user requests to the server are handled by the Interaction API web service. All requests to the Interaction services are made using HTTPS. A valid certificate must be installed on the application server and the service must be configured to use it.
Realtime web service
The RPI Realtime web service facilitates the making of content applicability decisions, and the recording of events undertaken by e.g. a site visitor.
Realtime Agent web service
The RPI Realtime Agent web service provides access for the RPI Realtime service to the RPI operational and data databases.
Configuration Service
The RPI Configuration service provides:
A self-documented series of endpoints that facilitate the installation and maintenance of an RPI cluster and its databases.
Application settings editors, which can be used to generate JSON for inclusion in appsettings files. The same editors also document environment variable names.
Access to a Downloads page, from which the RPI Client application and a number of other useful zip files may be obtained.
Client
The RPI Client application consists of an executable, library files and configuration files. It runs on a local workstation and communicates with the server via the latter’s Interaction API web services.
The computer upon which the RPI client is to run must have the following pre-requisites installed:
.NET Desktop Runtime 8.0.6
http://ASP.NET Core Runtime 8.0.6
Tenant
A tenant is an entity within an RPI server that represents a discrete and independent usage of the tool by an organization.
RPI features multi-tenancy support. To meet client organizations’ needs, each is represented as a separate tenant within the RPI server. Each tenant’s operational information and communication history are stored entirely separately and securely.
Databases
Core operational databases
The operational databases store information necessary for RPI to function. There are two core operational databases:
Pulse: the central core operational database, which is used to persist server-wide operational data.Pulse_Logging: stores error log records.
Note that core operational databases can be hosted in SQL Server, Azure SQL or PostgreSQL.
Tenant operational databases
The following databases are created for each tenant within the server. Note that each tenant’s version of the database will be assigned a unique name by the appending of a database suffix (captured at tenant creation).
Interaction_[suffix]: stores:
Details of the entities created by a single tenant’s users running the RPI client application.
RPI users, groups, and permissions.
The RPI file system, including its folders and the files within them, such as attributes, selection rules, audiences, offers and interactions, as well as configuration collections such as audience definitions, resolution levels, joins and database keys.
InteractionAudit_[suffix]
Stores audit records created with respect to actions undertaken by a single tenant’s users only.
Tenant operational databases can be hosted in SQL Server, Azure SQL or PostgreSQL.
Data warehouse
Each RPI tenant is associated with a data warehouse—a database that is the source of the data required to engage in conversational dialogue with customers. The data warehouse is also used as the repository within which details of the execution of such communications (“offer history”) are stored.
Auxiliary databases
Each RPI tenant can be configured to support one or more auxiliary databases, in addition to the main data warehouse. Data stored within auxiliary databases can be used for targeting and segmentation purposes.
Appropriate joins between the data warehouse and auxiliary databases must exist—it is not possible to use an auxiliary database table as a resolution table, nor is it possible to write offer history data to an auxiliary database.
Help website
Optionally, an RPI server can expose an online version of the RPI Reference Guide via a Help website.
User
Management of RPI users, user groups and functional permissions (which can be used to restrict access to RPI functionality) is carried out in the RPI client application’s Configuration interface. Full details can be found in the RPI Reference Guide.
A user can be granted access to a single—or more than one—tenant. RPI automatically creates a single user with the following credentials:
Username: coreuser
Password: .Admin123
If RPI authentication is to be managed using an OIDC (Open ID Connect) provider, RPI users’ email addresses must match those configured at the OIDC provider.
Optionally, RPI users can be managed exclusively within the Keycloak OIDC provider. Details of the functional changes manifest when this is available can be found in the RPI Reference Guide's Framework section.
To manage RPI users in Keycloak, the following application settings must be configured:
RPI__UserManagement__UseExternalUserManagement=trueRPI__UserManagement__Keycloak__Address=[address]RPI__UserManagement__Keycloak__Realm=[realm]RPI__UserManagement__Keycloak__ClientId=[client ID]RPI__UserManagement__Keycloak__ClientSecret=[client secret]
If an RPI Cluster Admin user is managed in KeyCloak, they must be assigned the rpi-cluster-admin in the KeyCloak user interface.
Deployment API
The RPI Deployment API primarily facilitates the installation of core and tenant-specific operational databases.
Integration API
The RPI Integration API provides a series of endpoints that allow for a third party development team to invoke RPI functionality.