Upgrading to RPI v7.8

Overview

This document outlines recommended steps and considerations for upgrading from RPI v7.7 to v7.8. In addition to this topic, be sure to also review the RPI v7.8 release notes.

Develop a client-specific MoP/SoP (recommended)

We recommend creating a documented procedure that includes:

• Estimated timing and ownership of each step

• Pre-upgrade shutdown steps

• Validation checks

• Rollback criteria and decision points

Executing the same procedure for each upgrade reduces operational variance and risk.

Step 1: Establish an upgrade window

After reviewing all of the upgrade requirements and process, estimate a downtime window, making sure to not attempt to upgrade during live execution.

Step 2: Back-up databases & prepare for potential rollback

Prior to upgrade:

• Perform full backups of:

  • RPI operational databases (Ops DB)

  • RPI Offer History tables. Create individual backups of these tables prior to upgrading and be prepared to replace data in the original tables from the backups if a rollback is required. Individual table backups would likely be copies of the tables with a suffix such as _bak_yymmdd or similar.

  • Campaign data warehouses (optional)

• Ensure Point-in-Time Restore (PITR) is enabled where supported (e.g., Azure SQL, Cloud SQL, Amazon RDS)

This backup serves as the rollback anchor if restoration of v7.7 becomes necessary.

Step 3: Schedule Maintenance Mode

RPI’s Maintenance Mode simplifies preparation for the upgrade by programmatically disabling workflows and non-cluster admin users and allowing you to schedule the maintenance window.

How Maintenance Mode disables workflows and user access

Workflows

To prevent new workflow activities from starting as a scheduled Maintenance Mode window approaches, you’ll need to specify the buffer, which is the amount time prior to scheduled maintenance to place any interaction workflow activity into a Queued status.

Ideally, the buffer time should be long enough to cover the expected time to execute an offer activity to avoid pausing the offer activity during the upgrade. You can do one of the following:

• Modify the buffer time prior to using Maintenance Mode with executionservice.defaultMaintenanceModeBufferTime in values.yaml (environment variable RPIExecution__DefaultMaintenanceModeBufferTime). Note, however, that modifying this setting requires redeploying the app.

• Accept the default of 5 minutes ("00:05:00") and modify the setting at a later point for future upgrades. Keep in mind that you’ll be confirming that no workflows are running before proceeding with the upgrade.

• In addition, this can be overwritten at specific triggers.

Users

When the Maintenance Mode window begins, all users (except for cluster admin users) are logged out of the system and unable to log in for the duration of the maintenance window. You can configure a message to be displayed when unauthorized users attempt to log into the client.

Step 3a: Schedule a Maintenance Mode window

Schedule a Maintenance Mode window ahead of the upgrade using the Configuration Service API (Set Maintenance Mode Schedule). For example:

DEPLOYMENT_SERVICE_URL=<prefix>-deploymentapi.<domain>
CLIENT_ID=<my RPI tenant client id>

curl -X POST "https://$DEPLOYMENT_SERVICE_URL/api/maintenance/maintenancemode/schedule" \
  -H "Content-Type: application/json" \
  -d '{
    "ID": "$CLIENT_ID",
    "StartDate": "1970-01-01T00:00:00.000Z",
    "EndDate": "1970-01-01T00:00:00.000Z",
    "StartTime": "00:00:00.000Z",
    "EndTime": "00:00:00.000Z",
    "Mode": "Single",
    "Days": [
      "Sunday"
    ],
    "DaysOfMonth": [
      0
    ],
    "Message": "string",
    "IsDeactivated": false
  }'

Step 3b: Confirm that no workflows are running

Run the following query until there are no more records returned, indicating all running activities are complete, and you are ready to proceed.

SELECT 
    (SELECT COUNT(*) 
     FROM dbo.rpi_ExecutionSchedule 
     WHERE ExecutionStatus = 'Running')
  +
    (SELECT COUNT(*) 
     FROM dbo.rpi_Tasks 
     WHERE IsRunning = 1) AS TotalRunning;

Step 4: Disable workflows

Although Maintenance Mode gracefully stops your workflows for the specified buffer time, to make sure that workflows won't start again immediately after the buffer ends, we recommend that you additionally disable active workflows programmatically. You’ll re-enable them once you’ve validated the upgrade.

Step 5: Update the Helm chart (self-hosted deployments)

In RPI v7.7, the Helm chart was enhanced so you never need to fork or edit the Helm chart. All customization is done through your overrides file, which is typically 50-100 lines. Chart updates apply automatically without reconciling template changes.

Refer to Managing Helm chart updates for details.

Update process

1. Generate or update your overrides using the RPI Helm Assistant. Use the Reference tab to browse available configuration options, or the Chat tab to ask questions about specific features. When upgrading between chart versions, refer to the Migration readme for details on key changes, new features, and any breaking changes.

2. After the v7.8 containers are running, upgrade the operational database schema via the Deployment API:

DEPLOYMENT_SERVICE_URL=<prefix>-deploymentapi.<domain>

curl -X 'GET' \
  "https://$DEPLOYMENT_SERVICE_URL/api/deployment/upgrade?waitTimeoutSeconds=360" \
  -H 'accept: text/plain'

Wait for "Status": "LastRunComplete" in the response. You can also open https://<deploymentapi-host>/ in a browser to monitor the upgrade progress.

Step 6: Validate the upgrade

After upgrade:

• Confirm application health.

• Validate:

  • Execution services

  • Message services

  • Connector connectivity

• Run a controlled test campaign.

• Monitor logs for Redis, queue, or cache-related warnings.

• Once your maintenance mode buffer has ended, workflows placed in the Queue will be ready to resume once you re-enable them, as described next.

Step 7: Re-enable workflows

Once you’ve validated the upgrade, you can re-enable your workflows.

If you want to perform any additional validation before re-enabling workflows, you can have RPI up and available to users for a few hours or so of testing to make sure everything is operating as expected before letting your campaigns run. Additionally, you can choose to enable 10-20 at a time, for example, instead of re-enabling them all at once.