ようこそ > キャプチャ > 抽出グループ > ドキュメント タイプ > ドキュメント タイプのプロパティ > フィールドの検証 > 検証後の処理

検証後の処理

TotalAgility の検証のプロセスに独自の実装をプラグインできます。TotalAgility SDK を使用すると、検証を実行するコンポーネント (キャプチャ クライアント、Transformation Server、CoreWorker) に関わらず、実際のキャプチャ データに基づいてカスタム検証を実装できます。

カスタム検証の構成

ドキュメント タイプのカスタム検証は、TotalAgility Designer で有効に設定できます。

  1. [抽出グループ] > [キャプチャ] に移動します。

  2. 必要な抽出グループを選択した後、ドキュメント タイプを選択します。

  3. [フィールドの検証] タブで、[検証後の処理] を選択します。(デフォルト: クリア – つまり、検証後のプロセス マップが存在していても実行されません。)

  4. [プロセス マップ] リストで、検証後ハンドラとして割り当てるプロセス マップを選択します。

検証後ハンドラ

検証後ハンドラのプロセス マップは同期されている必要があり、次の入力変数のセットを含む必要があります。

  • ドキュメント ID: 文字列

  • フィールド名のリスト: ダイナミック複合変数

ダイナミック複合変数は必ず 4 列で構成され、最初の 2 列 ([FieldId] と [Name]) が string 型、次の 2 列 ([TableRow] と [TableColumn]) が short 型である必要があります。

テーブル フィールド ケースの列の説明です。

FieldId

テーブル フィールドの ID です。
名前

列の名前です。
TableRow と TableColumn

テーブル内の特定のセルに対応するインデックスです。

テーブル全体の検証の場合、インデックスは -1 です。

テーブル以外のフィールド ケースの列の説明です。

FieldId

フィールドの ID です。
名前

フィールドの名前です。
TableRow と TableColumn

-1 に設定されます。

TotalAgility から、検証のために要求されたフィールド名のリストが渡されます。ドキュメント全体の検証の場合、すべてのドキュメント フィールド名が渡されます。このパラメータを使用すると、カスタム ロジックでは必要なフィールドのみを検証するか、検証が要求されたフィールドに基づいてそれ以外のロジックを適用します。

注 マップが上記の要件を満たさない場合、ルールの割り当てはリジェクトされ、適切なメッセージが表示されます。

TotalAgility ではプロセス出力が無視されるため、どのような出力変数を使用することも、使用しないこともできます。

検証後ハンドラのプロセス マップが、標準検証の実行後に任意のカスタム ロジックを実装します。このプロセス マップでは、バッチ対応の SDK API 呼び出しを使用して、実行中にデータを自由に読み取り、変更できます。プロセス マップには出力がなく、プロセス マップが処理するデータの状態の変更はすべてプロセス マップ自身が行うことになります。

注 TotalAgility 7.5.0 以降のすべての CaptureDocumentServices API がバッチ対応です。

プロセス マップは標準検証の不可欠な部分であるため、標準検証が実行されるたびに必ず実行されます。検証後ハンドラが構成されていない場合は、スキップされます。

キャプチャ フォームから検証が実行されると、フォームのユーザー インターフェイス内のすべてのフィールドの変更が自動的に反映されます。

注 標準検証では、キャプチャ データを変更する TotalAgility SDK API の呼び出しはサポートされていません。TotalAgility では、データ変更 SDK を実際に呼び出すことは禁じられていませんが、サポート対象外です。自己責任で使用してください。

実行時の動作

検証後ハンドラによってフィールドのステータス (「有効」、「強制的に有効化」、「無効」、「確認済み」) またはエラー メッセージが変更された場合、変更された状態が標準ルール ロジックと矛盾する場合でも、このフィールドに割り当てられた標準検証ルールの結果よりもこの変更が優先されます。更新されたステータスが有効に設定されている場合、対応する標準ルールはフィールド値が変更されるまで「合格」として扱われます。

検証後ハンドラが一部のフィールド ステータスを変更した場合、このフィールドがいくつかのマルチフィールド ルールに含まれていると、それに応じてこのマルチフィールド ルールの結果のステータスが更新されます。この更新後に、このマルチフィールド ルールに含まれるすべてのフィールドが有効である場合、これらのフィールドのいずれかの値が変更されるまで、マルチフィールド ルールが「合格」として扱われます。逆の場合もまた同様に、すべてのマルチフィールド ルールのフィールドが有効であっても事後検証でそれらのいずれかが無効と設定された場合、マルチフィールド ルールは「合格」ではないものとして扱われます。

基本的に、検証後ハンドラがフィールド ステータスの更新を行った場合、同じ更新が標準ルールによって行われた場合と同じ動作が継続されます。

検証後ハンドラがフィールドのステータスを変更した場合、フィールドのプロパティ ExtractionConfident が自動的に true に設定されます。

フィールド ステータスは、SetDocumentFieldStatus SDK を使用して更新されたものと見なされます。この SDK により、階層にもステータスが正しく伝達されます。

ドキュメント タイプに基づいた検証

CaptureDocumentService では、ドキュメントではなくドキュメント タイプおよびフィールド データに対して検証をトリガーする次の API が公開されています。

  • ValidateAllDocumentFields

  • ValidateDocumentField

  • ValidateDocumentFields

これらの API によって検証がトリガーされた場合は、ドキュメント オブジェクトがないため、ドキュメントのデータにアクセスする SDK API は使用できません。したがって、これらの API の検証後の構成は無視され、実行されません。