Post validation handling
You can plug your own implementation into process of TotalAgility validation, and using TotalAgility SDK, implement custom validation based on actual capture data regardless of component (Capture Client, Transformation Server or CoreWorker) who runs the validation.
Custom validation configuration
You can enable custom validation for a document type in TotalAgility Designer.
Select the required extraction group > document type.
On the Field validation tab, select Post validation handling. (Default: Clear – This means that the post validation process map is not executed even if it exists.)
On the Process map list, select a process map to assign as post validation handler.
Post validation handler
The post validation handler process map must be synchronous and must have the following set of input variables:
Document ID: String
List of field names: Dynamic complex variable
The dynamic complex variable must have exactly four columns where first two columns (“FieldId” and “Name”) must be of type string and the next two columns (“TableRow” and “TableColumn”) of type short.
Description of columns for table field case.
ID of the table field.
Name of the column.
|TableRow and TableColumn||
Corresponding indexes of specific cell within table.
For full table validation, indexes are -1.
Description of columns for non-table field case.
ID of the field.
Name of the field.
|TableRow and TableColumn||
Set to -1
TotalAgility passes list of fields’ names that were requested for validation. For full document validation, all document field names are passed. Using this parameter, custom logic may only validate required fields or apply any other logic based on fields requested for validation.
The process output is ignored by TotalAgility so it can have any or no output variables.
The post validation handler process map implements any custom logic after standard validation is executed. This map can freely read and modify data during its execution using the batch-aware SDK API calls. The process map does not have output and is fully responsible to change state of data it operates.
The process map is integral part of standard validation and thus always executed every time when standard validation is executed. If the post validation handler is not configured, it is skipped.
When validation is executed from capture form, the form reflects all field changes in the user interface automatically.
If post validation handler has changed field’s status (Valid, Forced Valid, Invalid or Confirmed) or error message, this change overrides any standard validation rule result assigned to this field even if the changed state contradicts the standard rule logic. If the updated status is set as valid, then corresponding standard rule is treated as “passed” until field value is changed.
If post validation handler has changed some field status and this field is part of some multi-field rule, the status in result of this multi-field rule is updated accordingly. If all fields that are part of this multi-field rule are valid after this update, the multi-field rule is treated as “passed” until value of any of these fields is changed. And vice versa: if all multi-field rule’s fields were valid, but post validation sets any of them as invalid, the multi-field rule is treated as not “passed”.
Basically, if post validation handler made update of field status, the behavior remains the same as the same update done by standard rule.
If post validation handler changed field status, the field’s property ExtractionConfident is automatically set as true.
It is assumed that field status is updated using SetDocumentFieldStatus SDK. This SDK also correctly propagates status up to hierarchy.
Validation based on document type
CaptureDocumentService exposes the following APIs that trigger validation not on document, but on document type and fields data:
When validation is triggered by these APIs, you cannot use SDK APIs that access document’s data because there is no document object. Thus, post validation configuration is ignored for these APIs and not executed.