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:
-
In the Snowflake web UI, navigate to Project > Workspaces.
-
In the
RCIDR.sqlworksheet, run the SQL command.
System state
At any time you can request the “system state”, which contains a high-level view of processing:
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:
SELECT app_public.start_production_job(incremental BOOLEAN);
Set incremental as follows:
-
FALSEto run a full match (default) -
TRUEto 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:
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:
SELECT app_public.abort_production_job();
Match Results table
The output table is SHARED.MATCH_RESULT. It has the following columns:
|
Column |
Description |
|---|---|
|
|
Individual or household |
|
|
The record ID |
|
|
|
|
|
|