データの検証

ユーザーによるデータ入力が有効であることを確認することで、問題やエラーを発生させずにワークフローがエンドツーエンドで完了できるようになります。

以下の表は、データ検証要件の例を示しています。

処理エラーを防ぐため、Pega Platform™では、フィールドタイプとコントロールを提供して、検証要件をサポートしています。正しいコントロールを選択することが、検証要件を満たすために十分なこともあります。コントロールやフィールドタイプがデータ検証の実行に十分ではない場合、Pega Platformは、ビジネスロジックを使用して条件付きのフィールドをテストしてデータ検証を提供します。 

たとえば、形式がdd/mm/yyyyまたはmm/dd/yyyyのいずれであっても、ユーザーが入力したデータが日付であることを確認するDate onlyフィールドタイプを使用できます。ただし、Date onlyフィールドタイプは、職歴フォームのStart dateフィールドが過去の日付を取得するようにすることはできません。その代わりに、ビジネスロジックを使用して過去の日付を検証できます。

コントロールを使用することは、最も一般的な検証アプローチです。コントロールタイプ、必須フィールド、編集可能な設定などを利用して、コントロールでユーザーの入力を検証することができます。

コントロールタイプ

特定の目的のために正しいコントロールタイプを使用することで、ユーザーが有効な値を入力することができます。以下の表は、異なるコントロールタイプのユースケースの例を示したものです。

必須フィールド

コントロールを必須フィールドとして設定すると、ユーザーに必ず値を入力してもらえます。必須フィールドに値がないフォームを送信しようとするとエラーが表示されます。リワードプログラムのプロフィールの例では、「Date of birth」を必須フィールドに設定します。ユーザーがこのフィールドに日付を入力せずにフォームを送信しようとすると、エラーメッセージが表示されます。 フィールドに日付がある場合には、エラーメッセージは表示されません。

App Studioを使用し、ユーザーがフォームを送信した際にフィールドの値を定数値と比較する、シンプルなビジネスロジック検証を実行します。無効なデータ値を定義する条件を作成し、条件が満たされた場合にエラーメッセージを表示するようにできます。ユーザーが、無効な値の条件に一致する値を生成すると、システムによってエラーメッセージが表示されます。これにより、問題が解決するまで、ユーザーはケースを続行できなくなります。

次の画像と説明文の番号を照らし合わせて、ユーザーが「Loan amount」フィールドに100.00より大きい値を入力するように検証条件を設定する方法の詳細を確認してください。

1. 検証条件の設定：この検証を設定するには、次の条件を作成します。「Loan amount field is less than or equal to 100.00」
2. Error message guideline:エラーメッセージは、データ検証エラーを判断し解決するために必要な情報をユーザーに提示します。
3. Validation at runtime:ユーザーがフォームを送信すると、システムはフィールドの値に基づいて条件を評価します。条件が真の場合には、フィールドの値が100.00以下であることを意味し、フォームにメッセージが表示されます。 

ステージでビジネスロジック検証を使用することもできます。ステージでビジネスロジック検証を使用して、ケースが特定のステージに入る前に、アプリケーションが正しいデータを生成し、ユーザーが正しいデータを入力または適切なアクションを実行していることを確認できます。ケースタイプデータモデルのステージでビジネスロジック検証を設定すると、ケースが指定されたステージに入る前にシステムが検証をトリガーします。ステージエントリー検証で、データ値が無効なデータの条件を満たす場合には、ケースはステージに入ることができず、エラーメッセージが表示されます。

たとえば、住宅ローンのアプリでは、ケースがUnderwritingステージに移る前に、有効なクレジットスコアが必要となります。アプリケーションはユーザーにクレジットスコアが無効であることを知らせ、ユーザーはクレジット履歴を確認したり、プロセスをキャンセルしたりできます。

次の画像と説明文の番号を照らし合わせて、ケースタイプのデータモデルでの検証の設定について詳細を表示できます。

1. 再利用可能なフィールド：ステップでの検証と同様に、「Case ID」や「Case status」など、再利用可能なフィールドにステージエントリー検証を設定できます。
2. 検証グリッド：ステージエントリー検証は、グリッドとして表示され、プロパティが各行を識別し、ステージが各列を識別します。このグリッドを使用することで、特定のケースタイプのすべてのステージエントリー検証を管理できます。
3. 検証条件：ステージ検証の条件の構築は、ステップ検証の条件の構築と似ています。AND/ORグループを使用して複数の式を追加し、条件を設定します。たとえば、住宅ローンのアプリケーションでは、「Credit score」が300未満の場合や、850を超える場合には、ユーザーに対してエラーメッセージが表示されます。
4. 複数のステージでの検証：データモデルでビジネスロジック検証を作成する際には、ステージエントリー検証を複数のステージに適用するよう設定できます。

ユーザーが入力する値を予測またはコントロールできない場合は、フォームでビジネスロジック検証を使用します。フォームでビジネスロジック検証を設定すると、ユーザーがフォームを送信する際、検証がトリガーされます。ユーザーが、無効なデータの条件に一致する値を含むフォームを送信すると、フォームにエラーが表示されます。これにより、ユーザーが条件を満たすデータを送信するまでケースの作業を続けることができなくなります。フィールドに新しい値を入力するなど、ユーザーが無効なデータを解決するアクションを直ちに実行できる場合に、フォームで検証を使用します。

たとえば、フォームにDate of birthフィールドがある場合を考えます。フィールドタイプでは、ユーザーが未来の日付を入力するのを防げません。ただし、ユーザーが未来の日付を送信するとエラーが表示されるビジネスロジック検証を設計できます。このシステムでは、ユーザーが過去の日付を入力すると、フォームを送信できるようになります。

以下の画像の中央にある縦棒をスライドすると、左でDate of birthフィールドを検証し、右のフォームにエラーメッセージを表示するステップ設定を表示できます。