Redpoint Identity Studio Documentation

Production integration

Overview

While the application UI is critical to configuring, tuning, and visualizing the matching system, you will also need to integrate the RIS processing into your production system. To make that possible, the RIS service exposes several API endpoints as UDFs (User-Defined Functions) that can be called from your SQL or integration code.

We’ve provided sample SQL in the application readme; make sure to familiarize yourself with its contents. You should have already created the RCIDR.sql worksheet in Installing & configuring the app.

To run the SQL described on this page:

  1. In the Snowflake web UI, navigate to Project > Workspaces.

  2. In the RCIDR.sql worksheet, run the SQL command.

System state

At any time you can request the “system state”, which contains a high-level view of processing:

SQL
SELECT app_public.get_system_state();

Running and monitoring a production job

You can launch a production match job at any time, monitor its progress, and determine the success or failure of the job run.

To run a production match job from the RIS UI, refer to Production.

Prerequisites

To start a match job, you will have first loaded the SHARED.INPUT table with data from your source tables. The onboarding process should have assisted in the mapping of your source tables to the INPUT table columns and generated SQL for you, or you can use whatever process or SQL you want. Refer to the Getting started guide for more information on loading your INPUT table.

The INPUT table should be loaded with all of your PII data, not just the changed data; you must delete records from the INPUT table that no longer correspond to your source tables. Clearing and loading the entire INPUT table is often the best approach, unless you have very large data and want to optimize for incremental change.

If you have auto-suspend (“Sleep mode”) enabled, you’ll want to issue a “wake-up” command (app_public.resume_app) before calling the job-start UDF. Refer to Installing & configuring the app for details.

Start a production match job

To start a production match job, call the start_production_job UDF as follows:

SQL
SELECT app_public.start_production_job(incremental BOOLEAN);

Set incremental as follows:

  • FALSE to run a full match (default)

  • TRUE to run an incremental match

If you are certain that a small number of changes (< 0.1% of the database) have occurred since the last job, you can run an incremental job (incremental TRUE) in the call. This will tend to run faster for very small changes. It is purely a time optimization.

Be advised that incremental production jobs can produce subtle differences from a full production run, so even if you use incremental, you must also perform full jobs occasionally to “true up” the results. The subtle differences have to do with spillover effects from transitive chaining that are not always completely accounted for in the incremental process.

Monitor job progress

During or after a production job runs, to get the messages for the given phase of the production job, run:

SQL
SELECT app_public.get_production_job_messages(job_phase VARCHAR);

Set job_phase to one of:

  • hygiene

  • segment_individual

  • segment_household

  • match_individual

  • match_household

  • report

Abort production job

If you need to halt the production match job, run:

SQL
SELECT app_public.abort_production_job();

Match Results table

The output table is SHARED.MATCH_RESULT. It has the following columns:

Column

Description

LEVEL

Individual or household

ID

The record ID

GROUP_ID

  • The assigned group ID

  • Always equal to the lexically lowest ID of any record in the group

  • Do not expect GROUP_IDs to remain constant over time if group membership changes

TIMESTAMP

  • When the result was produced

  • Useful for verifying when the processing last completed and also to observe incremental changes since last full production job