Admin: Key concepts

Node

A single machine in a single stack or cluster implementation is referred to as a node. An RPI server installation must contain at least one node.

Node Manager: The node manager Windows service role is supported by all nodes within a cluster. Only one node at a time assumes the status of Master node manager; this service controls the allocation of work to Windows service roles within the cluster. In addition, the node manager service facilitates connection of the Server Workbench application itself to the cluster.
Node Roles: Nodes within a cluster fulfill a number of roles:
- Windows services
  - Execution service
- Web services
  - Interaction API Services
  - Help files

Cluster

An RPI server installation can be installed upon several physical or virtual machines. This collection of machines, and the services (or “roles”) that they provide, are collectively known as a “cluster,”.

At the heart of an RPI server lies its “core”. The core consists of:

An initial cluster node (installed on a single physical or virtual machine). By default, the initial node always supports the Node manager role.

Core operational databases (which can be installed upon the same or another machine).

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 cluster-level operational data.

Pulse_Logging: stores error log records.

It is recommended that Trusted Authentication be used in preference to SQL Authentication at the core operational databases.

If Trusted Authentication is not used, database passwords might be viewable from Server

Workbench and configuration files. Also, system management is made easier when using Trusted Authentication. In organizations that enforce password changes (e.g. every 6 months for SSAE-16 compliance), it is easier to only have to change the service account password rather than a number of separate connection strings.

Client Operational Databases

The following databases are created for each client installed within the cluster. Note that each client’s version of the database will be assigned a unique name by the appending of a database suffix (captured at client creation).

Interaction_[suffix]: stores:

Details of the entities created by a single client’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. Administration objects such as audience definitions, resolution levels, joins and database keys.

InteractionAudit_[suffix]: stores audit records created with respect to actions undertaken by a single client’s users only.

It is recommended that Trusted Authentication be used in preference to SQL Authentication at the client operational databases.

Please see comments on the benefits of using Trusted Authentication above.

Data Warehouse

Each RPI client is associated with a data warehouse—a SQL Server, SQL Server PDW, Netezza,

Oracle, Teradata, GreenPlum, MySQL, Sybase IQ, AWS Redshift, PostgreSQL, Actian VectorH,

DB2, Splice Machine, Vertica, MariaDB, Azure SQL Database, Azure Synapse Analytics, Azure Database for MySQL, Azure Database for PostgreSQL, Google BigQuery or Snowflake marketing database that is the source of the data required to engage in conversational dialogue with customers or prospects. 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 client 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. Note that 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.

All of the supported database management systems suitable for data warehouse use can be used to host an auxiliary database. In addition, the Apache Hive, MongoDB (SQL), Apache Spark, http://Salesforce.com and Apache Cassandra platforms can be used to host auxiliary databases only.

Roles

Windows Services

At least one node in the cluster must support the Windows services role. This role provides a single Windows service: the 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).

Note that, when multiple nodes expose the Windows services role, the node to be assigned the responsibility for executing a server job will be determined by the Master node manager (the job will be assigned to the Windows services node with the fewest executing server jobs).

Web Services

At least one node in the cluster must support the Web services role. This role is responsible for controlling access to the RPI server from the RPI client application. In addition, once connected, all communications between client application and server are affected by this role.

Help Files

If online help is to be made available to users, one node in the cluster can be used to support the Help files role. This role is responsible for serving online help content in a browser, as requested by RPI client application users.

Client

A client (not to be confused with the RPI client application) is an entity within an RPI server that represents a discrete and independent usage of the tool by an organization. All clients’ data are stored securely and entirely independently of one another—a user who is able to access only Client A will be completely oblivious to the existence of Client B within the same server installation.

User

RPI users can be managed centrally within Server Workbench (as well as directly within the RPI client application). A user can be granted access to a single—or more than one—client and provided with appropriate permissions in each such context.

RPI Licenses

When installing the RPI server, you must specify a valid license.

If a server license expires, you can upload a new, valid license file in the Plugins tab. When you do so, the new license will be installed automatically. You will then be able to access RPI functionality as required. Note a license must be more recent than the original to be uploaded in this way.