Form configuration and process flow
Overview
This topic outlines the form configuration and process flow.
This graphic represents the web form submission process flow; details are provided in the following sections.
To be able to use forms generated from RPI, you need to have Realtime installed and configured. In addition, the following settings need to be configured for form processing to work.
Realtime preconfigured components
The expectation is that RPI Realtime is installed and configured and working as expected, which at a minimum means the Realtime system/status endpoint returns an "OverallStatus": true
.
System configuration settings
You need to have RPI Realtime configured and the RPI Realtime Address configured as listed below. In addition, you need to define the name of the queue that has been created to support Realtime. In this example, there are local queues configured (.\Private$)
, and the queue name itself is FormSubmissionQueue
. For a production deployment, it would most likely not be a private or local queue.
These settings support form configuration and telling RPI system task where to process form submissions from(queue path).
Queue provider
In addition to the System Configuration settings, there needs to be a Queue Provider defined, and it needs to be set at the default. The queue provider that is defined needs to be where the queues that are listed in the system configuration reside. Below is an example of a queue provider configuration.
Realtime appsettings.json.config configuration
In order for Realtime to be able to write messages to the queue when forms are submitted to the Realtime API endpoint, the appsettings.json
file also needs to have the form submission queue defined in it. The
C:\inetpub\wwwrpi\InteractionRealtimeAPI
Locate the section for queue providers and ensure that the path that is named in the RPI System Configuration FormSubmissionQueuePath
matches what is configured in the appsettings.json.config
FormQueuePath
.
The name of the configuration in RPI and the appsettings
file are slightly different.
{
"Queues": {
"FormQueuePath": ".\\Private$\\FormSubmissionQueue",
"EventsQueuePath": ".\\Private$\\WebEventQueue",
"CacheOutputQueueEnabled": true,
"CacheOutputQueuePath": ".\\Private$\\WebCacheQueue",
"ListenerQueuePath": ".\\Private$\\RPIListenerQueue",
"RecommendationsQueuePath": ".\\Private$\\RecommendationQueue",
"ClientQueueSettings": {
"Assembly": "RedPoint.Shared",
"Type": "RedPoint.Shared.Queues.QueueInstanceFactoryMSMQ",
"Settings": []
}
}
}
RPI system task
After the configuration is complete, you can enable the System Task "Web form Processor" in RPI Operations within the RPI Client. Currently, the default processing time is set to poll every 10 minutes. This is a setting you can adjust to be more frequent depending on the use case of the form submissions in the particular deployment. In the example above, it is set to execute every minute.
This task will pull the form submissions from the queue that was defined in the following steps and write them to the primary data warehouse.
Tables web form processor system task maintains
There are three primary tables that are associated with forms:
RPI_WebForm
- Records are created and maintained when webforms are built within RPIThis table is unique on
FormID
RPI_WebFormSubmission
- Records are inserted by the Web Form Processor System TaskThis table maintains a base set of fields related to the form submission which are documented below
This table is unique on
FormSubmissionID
and links toRPI_WebForm
onFormID
RPI_WebFormFieldSubmission
- Records are inserted by the Web Form Processor System TaskThis table maintains a set of key Pair/Values that are associated to all of the form elements that are defined and captured as a part of the form submission
This table is unique on
FormFieldSubmissionID
and links toRPI_WebFormSubmission
onFormSubmissionID