RPI Offer History system ID values

Overview

This topic delineates the various system IDs used in RPI that are related to interaction and offer execution. These IDs are used to keep track of the execution of different components within the execution of an Interaction workflow. They are logged to the Offer History tables linking and tracking of fulfillment activities within an RPI interaction.

System IDs

There are some situations where you may need to set or reseed these values. Below are a few examples of when you would consider setting these IDs, but there may be other applicable situations as well.

• Global Deployments: For a global deployment of RPI where there are independent instances of RPI stood up in different regions of the world for accessibility or governance reasons, you may want to set the values of these IDs so that you can bring back all of the offer history data to a single repository for reporting and not have any overlap in IDs between regions.

• Upgrades: When performing an upgrade from RPI v6 to RPI v7, you may run into an issue where you need to fall back to v6 after some campaign executions were run in v7 that generated offer history records that you need to push back to v6 to ensure that you have a complete view of all communications without adding additional tables to v6, which could be an alternative option. In this case you would need to push the values of the IDs forward in the v6 deployment so you can load the records from the v7 executions into v6.

• New Deployments: There are instances where there will be a fresh install and new deployment of RPI to align with a new data model or strategy but you still want to preserve the offer history data from the original instance. In this case, you will need to start the IDs ahead of the highest value in the old environment so that you can load the records from the old environment to the new one.

ID Reference Table

The table below lists the various IDs used by RPI for storing data in offer history as well as how to get the current values and set (reseed) the values.

RPI ID name	Location	Get current value	Set values
WorkflowId	Interaction Ops DB	SQL SELECT MAX([WorkflowAssociationInstanceID]) FROM [Interaction_Main].[dbo].[op_InteractionWorkflows];	SQL DBCC CHECKIDENT ('op_InteractionWorkflows', RESEED, <new_value>);
DataflowId	Interaction Ops DB	SQL SELECT * FROM [Pulse_Seed] WHERE [SeedType] = 'Process';	SQL UPDATE [Pulse_Seed] SET [CurrentSeed] = <new_value> WHERE [SeedType] = 'Process';
ChannelExecutionId	Interaction Ops DB	SQL SELECT MAX([ChannelExecutionID]) FROM [op_ChannelExecution];	SQL DBCC CHECKIDENT ('op_ChannelExecution', RESEED, <new_value>);
RPContactId	DB	SQL SELECT MAX([RPContactID]) FROM [offer_history];	Alter sequence on OfferHistory table
RPContactId (Sandbox)	DB	SQL SELECT MAX([RPContactID]) FROM [offer_history_sandbox];	Alter sequence on OfferHistory_Sandbox table. Google BigQuery uses GENERATE_UUID() function to uniquely identify RPContactID and OutputID.
OutputId	DB	SQL SELECT MAX([OutputID]) FROM [offer_history_meta];	Alter sequence on OfferHistory_Meta table. Google BigQuery uses GENERATE_UUID() function to uniquely identify RPContactID and OutputID.
OutputId (Sandbox)	DB	SQL SELECT MAX([OutputID]) FROM [offer_history_sandbox_meta];	Alter sequence on OfferHistorySandbox_Meta table.