ソリューション
事前検証 - ビジネスロジックが単一の操作または属性に固有のものか、同じロジックが複数の操作または属性に使用されるかを判断します。ロジックが単一の UI コンポーネント (操作または属性) に固有の場合は、ロジックをバリデータに追加します。ロジックが複数の UI コンポーネントに適用される場合は、ロジックをフィルタに追加します。最後に、バリデータまたはフィルタを UI コンポーネントと関連付け、ビジネスロジックがそのコンポーネントに適用されるようにします。
バリデータの事前検証 - performFullPreValidation() と performLimitedPreValidation() メソッドをバリデータに実装し、必要なビジネスロジックを含めます。
フィルタの事前検証- preValidateAction メソッドをフィルタに実装し、必要なビジネスロジックを含めます。
選択後検証 - validateSelectedAction() と validateSelectedMultiSelectAction() メソッドをバリデータに実装し、必要なビジネスロジックを定義して、バリデータを操作と関連付けます。
サブミット後検証 - validateFormSubmission() メソッドをバリデータに実装し、必要なビジネスロジックを定義して、バリデータをウィザードのステップまたはウィザード全体と関連付けます。
前提となる知識
この目的を達成するには、次のことを理解している必要があります。
Windchill クライアントアーキテクチャでの操作フレームワーク
代理を登録するための、アプリケーションコンテキストまたは service.properties メカニズム
NmCommandBean とメソッドの基本的な知識があればさらに役立ちます。
検証サービスは非常にジェネリックな性質のものです。何かが有効かどうかを判断するのに必要な API はありません。サービスがバリデータやフィルタに提供するのは、UI コンポーネントが有効かどうかを判断するのに必要なコンテキストデータとフォームデータです。ただし、検証ビジネスロジックを適用するには、そのデータの使い方を知る必要があります。
ソリューションエレメント
UI 検証に関連するソリューションエレメントのほかに、このセクションでは主な用語 (太字) の定義についても説明します。
エレメント
タイプ
説明
StandardUIComponentValidation サービス
Java クラス
よく検証サービス と呼ばれます。UI 検証を制御するサービスクラスです。クライアントインフラストラクチャから検証リクエストを受け、適切なバリデータとフィルタに検証結果を委任します。その後、検証結果が元のクライアントインフラストラクチャに渡されます。
カスタマイザとアプリケーション開発者は、直接このクラスを操作する必要はありません。
UIValidationKey
Java クラス
よく検証キーと呼ばれます。検証対象の UI コンポーネントの識別には、UIValidationKey が使用されます。UIValidationKey は、操作または属性と 1 対 1 の関係を持つと考えることができます。
UIValidationCriteria
Java クラス
よく検証基準と呼ばれます。
UIValidationCriteria は Bean クラスで、検証サービスにより、クライアントインフラストラクチャからバリデータとフィルタに渡されたコンテキスト (リクエスト、セッション) データを含みます。
UIValidationCriteria のほとんどのコンテンツは、NmCommandBean から直接取得されます。ただし NmOids と異なり、オブジェクトは WTReferences として返されるのが一般的です。
UIValidationResult
Java クラス
よく検証結果と呼ばれます。
UIValidationResult が検証の 1 つの単位を表します。つまり、検証ステータスを UI コンポーネント (操作または属性) と関連付けます。複数のオブジェクトで同じ操作を実行する検証の場合は、UIValidationResult を各オブジェクトに関連付けることができます。
UIValidationResultSet
Java クラス
よく結果セットと呼ばれます。
UIValidationResultSet は、UIValidationResult オブジェクトのコレクションです。結果セットは、複数の検証を同時に実行した場合に使用します。たとえば、バリデータで複数のオブジェクトで行った同じ操作に対する事前検証チェックを行った場合は、各オブジェクトの検証結果が UIValidationResultSet に集約されます。
UIValidationStatus
Java クラス
よく検証ステータスと呼ばれます。
コンポーネントを UI に表示するかどうか、またはどのように表示するかを決めるのに使用する列挙です。たとえば、操作を非表示にする、操作を無効にする、操作を有効にするなどを示す値があります。
UIValidationFeedbackMsg
Java クラス
よくフィードバックメッセージと呼ばれます。
検証結果と関連付けることができるメッセージです。選択後検証とサブミット後検証でのみ使用されます。検証結果と関連付けられ、事前検証によって返されたフィードバックはすべて無視されます。
フィードバックメッセージには別のフィードバックタイプ (FeedbackType.java) を関連付け、エラーメッセージ、警告メッセージ、情報メッセージなどの区別を示すことができます。
UIComponentValidator
Java インタフェース
すべてのバリデータ実装に必要となるインタフェースです。ただし、バリデータにこのインタフェースを直接実装することは避けてください。代わりに、DefaultUIComponentValidator を拡張します。
各 UI コンポーネントは、ゼロまたは 1 つのバリデータを関連付けることができます。通常、バリデータには単一の UI コンポーネントに固有のロジックが含まれます。複数の UI コンポーネントに適用されるジェネリック検証ロジックについては、通常フィルタが使用されます。
バリデータは検証サービスによって呼び出され、特定の UI コンポーネントの検証ステータスを決定します。
カスタマイザとアプリケーション開発者は、直接このクラスを操作する必要はありません。
DefaultUIComponentValidator
Java クラス
これはデフォルトの UIComponentValidator インタフェースの実装です。すべてのバリデータ実装はこのクラスを拡張する必要があります。
ValidationFilter
Java インタフェース
すべてのフィルタ実装に必要となるインタフェースです。ただし、フィルタにこのインタフェースを直接実装することは避けてください。代わりに、DefaultSimpleValidationFilter または DefaultUniversalValidationFilter を拡張します。
各 UI コンポーネントは、ゼロまたは任意の数のフィルタを関連付けることができます。通常、フィルタには複数の UI コンポーネントに適用可能なジェネリック検証ロジックが含まれます。単一の UI コンポーネントまたは少数の UI コンポーネントセットに固有の検証ロジックについては、通常バリデータが使用されます。
フィルタには、シンプルフィルタとユニバーサルフィルタの 2 つのカテゴリがあります。シンプルフィルタは、コンポーネント単位で適用されます。つまり、シンプルフィルタのロジックを適用する UI コンポーネントを選択する必要があります。反対に、ユニバーサルフィルタは、すべての UI コンポーネントに適用されます。このため、ユニバーサルフィルタのロジックを適用しない UI コンポーネントを選択する必要があります。
フィルタは検証サービスによって呼び出され、特定の UI コンポーネントの検証ステータスを決定します。
カスタマイザとアプリケーション開発者は、直接このクラスを操作する必要はありません。
SimpleValidationFilter
Java インタフェース
すべてのシンプルフィルタ実装に必要となるインタフェースです。ただし、シンプルフィルタにこのインタフェースを直接実装することは避けてください。代わりに、DefaultSimpleValidationFilter を拡張します。
カスタマイザとアプリケーション開発者は、直接このクラスを操作する必要はありません。
UniversalValidationFilter
Java インタフェース
すべてのユニバーサルフィルタ実装に必要となるインタフェースです。ただし、ユニバーサルフィルタにこのインタフェースを直接実装することは避けてください。代わりに、DefaultUniversalValidationFilter を拡張します。
カスタマイザとアプリケーション開発者は、直接このクラスを操作する必要はありません。
DefaultSimpleValidationFilter
Java クラス
これはデフォルトの SimpleValidationFilter インタフェースの実装です。すべてのシンプルフィルタ実装はこのクラスを拡張する必要があります。
DefaultUniversalValidationFilter
Java クラス
これはデフォルトの UniversalValidationFilter インタフェースの実装です。すべてのユニバーサルフィルタ実装はこのクラスを拡張する必要があります。
UIComponentSolutionGroup
Java インタフェース
すべてのソリューショングループ実装に必要となるインタフェースです。
ソリューショングループは、インストールされたソリューションに基づいて事前検証で使用される特別なタイプのバリデータです。たとえば、Windchill ProjectLink がインストールされていない場合に、特定の操作を使用できないようにするロジックは、ソリューショングループで定義する必要があります。
*actions.xml
XML ファイル
操作定義を含む、複数の "サテライト" バージョンの actions.xml ファイル (通常 1 モジュールに 1 つ) があります。
シンプルフィルタを含め、ユニバーサルフィルタを除外する操作を設定するのもこのファイルです。
*service.properties.xconf
Xconf ファイル:
クラス代理レジストリエントリを含む、複数の "サテライト" バージョンの service.properites.xconf ファイル (通常 1 モジュールに 1 つ以上) があります。
これらのファイルにバリデータ、フィルタ、ソリューショングループを登録し、検証サービスがこれらを検索できるようにします。
事前検証シーケンス
事前検証シーケンスは、最初にクライアントインフラストラクチャ (通常 StandardNmActionService ですが例外もあります) が UI コンポーネントを検証サービスに送ります。すると、検証サービスが各 UI コンポーネントに対する検証結果を返し、UI コンポーネントの表示ステータスを示します。各 UI コンポーネントは検証キーで表されます。また、クライアントインフラストラクチャがコンテキスト (セッション、リクエスト、またはフォーム) データを検証基準オブジェクト内の検証サービスに渡します。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
検証サービスがクライアントインフラストラクチャから検証リクエストを受け取ると、検証サービスは各検証キーを反復して一連のタスクを実行し、各キーの検証ステータスを決定します。
検証サービスが実行する最初のタスクは、インストールされている PTC ソリューションに基づいて、対象となる検証キーが非表示にすべきコンポーネントに該当するかどうかを調べることです。これを行うには、検証サービスを最初に開始したときに作成される、無効な検証キーのキャッシュを参照します。キャッシュを作成するには、研修サービスがすべての登録済みソリューショングループを呼び出し、インストールされているソリューションに基づいて、各々に対して無効な検証キーを要求するだけです。
無効なソリューションベースのキーのキャッシュに現在の検証キーが含まれる場合、検証サービスはコンポーネントのステータスを "非表示" に設定し、そのコンポーネントに対してはその他の検証を行いません。一方、無効なソリューションベースのキーのキャッシュに現在の検証キーが含まれない場合は、検証サービスによる事前検証チェックが続行します。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 各検証キーについて、検証サービスは一連のタスクを実行し、そのキーの検証ステータスを決定します。タスクは以下の順序で実行されます。
a. インストールされているソリューションセット用の無効なキーリストに検証キーが含まれるかどうかを確認します。
2 番目の事前検証チェックでは、コンポーネントが役割ベースの UI サービスによって非表示または無効に設定されているかどうかを調べます。役割ベースの UI サービスは、管理者ユーザーがユーザーロールに基づいて UI コンポーネントの表示を設定する方法として、バージョン 8.0 で導入されました。バージョン 9.0 の UI 検証サービスの導入により、役割ベースの UI サービスは UI 検証サービスの特別代理となりました。
役割ベースの UI サービスが "非表示" または "無効" ステータスを返すと、検証サービスはそれに合わせてコンポーネントのステータスを設定し、そのコンポーネントに対してはその他の検証を行いません。一方、役割ベースの UI サービスが "有効" ステータスを返すと、検証サービスは事前検証チェックを続行します。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 各検証キーについて、検証サービスは一連のタスクを実行し、そのキーの検証ステータスを決定します。タスクは以下の順序で実行されます。
a. インストールされているソリューションセット用の無効なキーリストに検証キーが含まれるかどうかを確認します。
b. 役割ベースの UI サービスがコンポーネントを無効または非表示にするように設定されているかどうかを確認します。
役割ベースの UI サービスにより、コンポーネントを有効とするように設定されている場合、検証サービスは次に、UI コンポーネントに関連付けられているフィルタがあるかどうかを確認します。
どのフィルタを UI コンポーネントに適用するかを判断するために、検証サービスは最初に検証サービスが開始したときに保存されたその他のキャッシュデータを参照します。参照した最初のキャッシュに、すべての登録済みユニバーサルフィルタのリストが含まれます。フィルタがユニバーサルフィルタとして定義され、登録されている場合は、デフォルトで自動的にすべての UI コンポーネントに適用されます。このキャッシュにユニバーサルフィルタが 1 つでも存在する場合は、対象となる UI コンポーネントに適用されるフィルタリストに自動的に追加されます。
ユニバーサルフィルタはデフォルトですべての UI コンポーネントに適用されますが、個別にユニバーサルフィルタを無効にする操作を設定することができます(現在のところ、同じようにユニバーサルフィルタを無効にする属性の設定はサポートしていません。つまり、ユニバーサルフィルタは例外なくすべての属性に適用されます)。ユニバーサルフィルタを無視する操作を設定するには、actions.xml ファイルの操作定義を使用します。検証サービスが開始すると、操作マップと無視の設定をしたユニバーサルフィルタが入った 2 番目のキャッシュが作成されます。このキャッシュに対象となる操作のエントリが見つかった場合は、無視すべきユニバーサルフィルタが UI コンポーネントに適用されるフィルタリストから除去されます。
最後に、検証サービスは 3 番目のキャッシュを参照し、UI コンポーネントに適用すべきその他のフィルタを確認します。この 3 番目のキャッシュは、操作をシンプルフィルタに関連付けるマップです。シンプルフィルタと定義され、登録されたフィルタを操作に適用するには、明示的にその操作と関連付ける必要があります(現在のところ、シンプルフィルタと属性との関連付けはサポートしていません)。シンプルフィルタを使用する操作を設定するには、actions.xml ファイルの操作定義を使用します。検証サービスを開始したときに、この操作の 3 番目のキャッシュと、関連付けられたシンプルフィルタが作成されます。
要するに、検証サービスが対象となる UI コンポーネントに対してどのフィルタを適用するかを決定するのに使用されるアルゴリズムは、以下の式で表されます。
コンポーネントごとのフィルタ = すべてのユニバーサルフィルタ - 無視されたユニバーサルフィルタ + 関連付けられたシンプルフィルタ
フィルタリストを確立すると、検証サービスは各フィルタを呼び出して、UI コンポーネントの検証ステータスを決定します。フィルタが呼び出される順序は保証されないことに注意してください。フィルタが "非表示" または "無効" の検証ステータスを返すと、検証サービスはそれに合わせてコンポーネントのステータスを設定し、そのコンポーネントに対してはその他の検証を行いません。一方、その UI コンポーネントに適用されるすべてのフィルタが "有効" ステータスを返すと、検証サービスは事前検証チェックを続行します。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 各検証キーについて、検証サービスは一連のタスクを実行し、そのキーの検証ステータスを決定します。タスクは以下の順序で実行されます。
a. インストールされているソリューションセット用の無効なキーリストに検証キーが含まれるかどうかを確認します。
b. 役割ベースの UI サービスがコンポーネントを無効または非表示にするように設定されているかどうかを確認します。
c. UI コンポーネントと関連付けられたフィルタが、コンポーネントを無効または非表示にするように設定されているかどうかを確認します
(詳細については、次のページの図を参照してください)。UI コンポーネントを無効または非表示にするように設定されているフィルタがまったくない場合は、その UI コンポーネントに対して関連付けられているバリデータがあるかどうかの最終チェックが実行されます。
バリデータは UI コンポーネントに関連付けられます。これは、action id (操作の場合) または descriptor id (属性の場合) とそのコンポーネントに使用するバリデータクラスのクラス名をリンクするエントリを service.properties.xconf ファイルに作成することによって行います。
その UI コンポーネントに登録されているバリデータがない場合は、コンポーネントは有効となります。一方、UI コンポーネントに関連付けられたバリデータがある場合は、検証サービスがそのバリデータを呼び出し、その UI コンポーネントの検証ステータスを取得します。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 各検証キーについて、検証サービスは一連のタスクを実行し、そのキーの検証ステータスを決定します。タスクは以下の順序で実行されます。
a. インストールされているソリューションセット用の無効なキーリストに検証キーが含まれるかどうかを確認します。
b. 役割ベースの UI サービスがコンポーネントを無効または非表示にするように設定されているかどうかを確認します。
c. UI コンポーネントと関連付けられたフィルタが、コンポーネントを無効または非表示にするように設定されているかどうかを確認します
d. UI コンポーネントに関連付けられているバリデータがある場合は、そのバリデータから検証ステータスを取得します
(詳細については、次のページの図を参照してください)。この時点で、検証サービスは各 UI コンポーネントの検証チェックを完了しています。事前検証でクライアントインフラストラクチャが単一の UI コンポーネントを検証サービスに渡した場合、検証サービスは単一の検証結果を呼び出し側に戻します。また、事前検証で複数の UI コンポーネントが検証サービスに渡された場合は、検証サービスが各コンポーネントの検証結果を 1 つの検証結果セットにまとめます。検証結果セットには、UI コンポーネントごとに 1 つの結果が収められています。その後、検証結果セットが呼び出し側に戻されます。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 各検証キーについて、検証サービスは一連のタスクを実行し、そのキーの検証ステータスを決定します。タスクは以下の順序で実行されます。
a. インストールされているソリューションセット用の無効なキーリストに検証キーが含まれるかどうかを確認します。
b. 役割ベースの UI サービスがコンポーネントを無効または非表示にするように設定されているかどうかを確認します。
c. UI コンポーネントと関連付けられたフィルタが、コンポーネントを無効または非表示にするように設定されているかどうかを確認します
d. UI コンポーネントに関連付けられているバリデータがある場合は、そのバリデータから検証ステータスを取得します
3. 検証結果または検証結果セットがクライアントインフラストラクチャに戻されます。
選択後検証シーケンス
概念的には、選択後検証はユーザーが UI で操作を起動した直後に発生します。ただし実際には、選択後検証はターゲットページがレンダリングされたときに実行されます。つまり、begin.jspf (Windchill クライアントアーキテクチャで作成されたすべての JSP ページに含まれるコード) に、検証サービスを呼び出し、実際に開始する前にページのレンダリングが適切かどうかを判断するというロジックがあります。
選択後検証ロジックで許可される唯一の場所がバリデータです。事前検証と異なり、選択後検証にはソリューショングループ、役割ベースの UI サービス、またはフィルタとのやり取りはありません。このため、選択後検証のシーケンスは事前検証よりもはるかに単純です。
最初に、クライアントインフラストラクチャが検証サービスを呼び出します。サービスは、レンダリングされるページに対応する操作 (この操作は検証キーで表されます) を渡します。また操作とともに、コンテキストデータも検証基準インスタンスの形式で渡します。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
クライアントインフラストラクチャから選択後検証リクエストを受け取った後、検証サービスは指定した操作と関連付けられているバリデータがあるかどうかを確認します。
バリデータは、事前検証と同様に、action id とその操作のバリデータクラスのクラス名をリンクするエントリを service.properties.xconf ファイルに作成することで操作に関連付けられます。
その操作に登録されているバリデータがない場合、ユーザーは操作の実行を許可されます。一方、操作に関連付けられたバリデータがある場合は、検証サービスがそのバリデータを呼び出し、その操作の検証ステータスを取得します。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 検証サービスが、操作に関連付けられたバリデータがあるかどうかを確認します。ある場合は、バリデータを呼び出して、その操作の検証ステータス (許可または拒否) を取得します。
バリデータが検証結果を返した後、検証サービスが行うのは、バリデータから返された検証結果をクライアントインフラストラクチャに渡すことです。ステータスが許可か拒否かにかかわらず、クライアントインフラストラクチャは確認を行います。ステータスが "許可" の場合は、ページまたはウィザードが表示されます。ステータスが "拒否" の場合、ユーザーは前のページにリダイレクトされます。また、バリデータが操作の拒否理由を示すメッセージを返した場合は、そのメッセージがユーザーに表示されます。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 検証サービスが、操作に関連付けられたバリデータがあるかどうかを確認します。ある場合は、バリデータを呼び出して、その操作の検証ステータス (許可または拒否) を取得します。
3. 検証サービスが検証ステータス (検証結果に内包) をバリデータからクライアントインフラストラクチャに渡します。そこで、ターゲットページ/ウィザードを表示するか、または操作を起動したページにユーザーを戻します。
サブミット後検証シーケンス
サブミット後検証は、ユーザーがウィザードの 1 つのステップから次のステップに移動するとき、またはユーザーがウィザード全体をサブミットするときに発生します。
サブミット後検証ロジックで唯一許可される場所がバリデータです。事前検証と異なり、サブミット後検証にはソリューショングループ、役割ベースの UI サービス、またはフィルタとのやり取りはありません。このため、サブミット後検証のシーケンスは事前検証よりもはるかに単純です。選択後検証のシーケンスとほとんど同じです。
最初に、クライアントインフラストラクチャが検証サービスを呼び出します。サービスは、"次へ" または "OK" ウィザード操作 (この id は検証キーで表されます) に関連付けられた id を渡します。また検証キーとともに、コンテキストデータも検証基準インスタンスの形式で渡します。
キー
1. クライアントインフラストラクチャが、ウィザードの "次へ" または "OK" 操作 (検証キーで表されます) に関連付けられた id を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
クライアントインフラストラクチャからサブミット後検証リクエストを受け取った後、検証サービスはウィザードの "次へ" または "OK" 操作と関連付けられているバリデータがあるかどうかを確認します。
バリデータは、事前検証や選択後検証と同様に、action id とその操作のバリデータクラスのクラス名をリンクするエントリを service.properties.xconf ファイルに作成することで、ウィザードの "次へ" または "OK" 操作に関連付けられます。
その操作に登録されているバリデータがない場合、ユーザーは次のステップへの移動またはウィザード全体のサブミットを許可されます。一方、"次へ" または "OK" 操作に関連付けられたバリデータがある場合は、検証サービスがそのバリデータを呼び出し、その操作の検証ステータスを取得します。
キー
1. クライアントインフラストラクチャが、ウィザードの "次へ" または "OK" 操作 (検証キーで表されます) に関連付けられた id を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 検証サービスが、"次へ" または "OK" 操作に関連付けられたバリデータがあるかどうかを確認します。ある場合は、バリデータを呼び出して、その操作の検証ステータス (許可または拒否) を取得します。
バリデータが検証結果を返した後、検証サービスが行うのは、バリデータから返された検証結果をクライアントインフラストラクチャに渡すことです。ステータスが許可か拒否かにかかわらず、クライアントインフラストラクチャは確認を行います。ステータスが "許可" の場合、ユーザーは次のステップへの移動、またはウィザード全体のサブミットが許可されます。ステータスが "拒否" の場合、ユーザーは次のウィザードステップへの移動またはウィザードのサブミットが禁止され、バリデータが操作の拒否理由を示すメッセージを返した場合は、そのメッセージがユーザーに表示されます。
キー
1. クライアントインフラストラクチャが、レンダリングされるページに対応する操作 (検証キーで表されます) を渡す検証サービスと、コンテキストデータ (検証基準インスタンスで表されます) を呼び出します。
2. 検証サービスが、"次へ" または "OK" 操作に関連付けられたバリデータがあるかどうかを確認します。ある場合は、バリデータを呼び出して、その操作の検証ステータス (許可または拒否) を取得します。
3. 検証サービスが検証ステータス (検証結果に内包) をバリデータからクライアントインフラストラクチャに渡します。そこで、ユーザーがウィザードの次のステップに進む、またはウィザード全体をサブミットするのを許可するか、または操作を起動したウィザードステップにユーザーを戻します。
これは役に立ちましたか?