Dev Studioでのデータ検証

App Studioでは、フィールド値と定数値または別フィールドの値とtrue/false比較を行う検証条件を設定できます。 複雑な検証シナリオでは、Dev Studioのバリデートルールで提供される追加機能が必要になる場合があります。

ここでは、Dev Studioでしか設定できない動作が求められる次のようなシナリオを考えてみましょう。

• カナダ在住の顧客が住所を送信する場合は、カナダの郵便番号の標準形式に準拠した郵便番号を入力する必要があります。
• 投資家が投資口座を開設する際に記入してもらうアンケートで経験レベルを確認します。 口座に信用取引を追加できるのは、豊富な投資経験を持つ個人に限られます。
• 健康保険に加入する場合、申請者は医療情報を第三者に開示するための同意書をアップロードする必要があります。

バリデートルール

バリデートルールは、ユーザーが入力したデータがケースの進行に必要な条件を満たしていることを確認します。 バリデートルールをフローアクションに割り当てると、ユーザーがアプリケーションで処理できない情報を入力するのを防ぎ、処理エラーの回数を減らせます。

Dev Studioでは、App Studioで自動作成されるバリデートルールを拡張できます。 「Process」カテゴリーに新しいバリデートルールを作成することもできます。

エディットバリデートルール

エディットバリデートルールは通常、プロパティに適用され、プロパティの値を定義済みのパターンと比較するJavaコードで構成されます。 たとえば、エディットバリデートルールを使って、プロパティ値が7桁の数字で構成されていて、3桁目と4桁目の数字の間にスペースがあるかどうかをチェックすることができます。 パターンマッチが成功した場合、入力は有効とみなされます。 その他の場合、システムでは入力にエラーのフラグが付きます。

 エディットバリデートルールはクライアントサイドの検証で使用されます。つまり、ユーザーが入力した値は、サーバーを参照せず直ちに検証されます。 バリデーションは、ユーザーが入力値を変更する際に発生します。 プロパティにエディットバリデートルールを適用するには、プロパティルールフォームの「Advanced」タブにあるUse Validateフィールドでエディットバリデートルールを参照します。

ビジネスロジックでは、ユーザー入力が特定の基準を満たしていることが求められる場合があります。 たとえば、ユーザーの連絡先情報を収集する組織は情報が有効であることを確認する必要があります。 ユーザーの郵便番号、メールアドレス、または電話番号が正確であることをアプリケーションで確認するには、それ以前にユーザーの入力が位置情報によって異なる特定の形式に準拠していることを確認する必要があります。

次の例では、ユーザー入力で米国のZIPコード形式に準拠した数字5桁の郵便番号の入力を求めるエディットバリデートルールを適用しています。

以下のインタラクションで理解度をチェックしてください。

ビジネスロジックでは、ユーザー入力、ケースのステータスやステージ、ユーザーアクションなど、特定の条件に基づいてそれぞれアプリケーションでデータの検証が求められる場合があります。 これはバリデートルールで実現できます。

新規に投資口座を開設する場合のケースタイプについて考えてみます。 ある金融機関では、株式やその他の取引可能な投資商品の購入のために顧客に資金を貸し付ける、有価証券の信用取引オプションを提供しています。 この融資は信用取引の貸付で、融資残高と口座評価額の割合が30%など一定の維持率を保つことが求められます。 この金融機関では顧客に信用取引をうまく利用してもらうために、追加証拠金がなるべく発生しないようにしたいと考えています。追加証拠金が発生すると、追加資金の入金を要請するか、融資残高と口座評価額の割合を回復するため自動的に投資商品を売却しなければなりません。 投資経験が豊富な投資家は追加証拠金が発生するリスクが低いのに対し、経験の浅い投資家ではリスクが高くなります。 また、退職金口座のように年単位で拠出額を制限している口座では、信用取引は全面的に禁止されています。 この要件を満たすように、口座の種類と経験レベルに基づいて検証ロジックを条件付けできます。

検証ロジックを審査するには、バリデートルールの「Input」タブで、いずれかのオプションを選択することにより、適用する審査のタイプを識別します。

• Input property – ユーザーが入力したデータに基づいてデータの適格性を審査します。 投資口座の新規開設の例では、検証ロジックを特殊化するために経験レベルと口座タイプの両方のフィールドが使用されます。
• Proposed work status – アプリケーションでケースに適用されるステータスに基づいて審査を行います。 たとえば、クレジットカードの申請は顧客のクレジットスコアに基づいて行われます。 「Pending-Qualification」ステータスの場合は、最小クレジットスコアは600ですが、ステータスが「Approved」に変更されると、必要な最小クレジットスコアが725になります。
• Flow Action – ユーザーが実行するアクションに基づいて審査を行います。 たとえば、従業員情報を含むフォームには入社日が必要です。 ユーザーが新人のオンボーディングを行う場合は、入社日を将来の日付にする必要があります。 ユーザーが従業員の年次評価を行う場合は、入社日を過去の日付にする必要があります。
• Stages – ケースの現在のステージに基づいて審査を行います。 たとえば、住宅ローンや住宅担保ローンを申請する場合、顧客は年収を提示する必要があります。 「Submission」ステージで、ユーザーはアプリケーションにより推定年収の入力が求められます。 「Approval」ステージでは、推定金額を確認済みの具体的な金額に置き換える必要があります。

次の例は、入力の適格性についての検証を示しています。 「Experience level」のリストで選択した値により、フォーム送信時に適用される検証条件が決まります。 ユーザーが「Experienced」や「Professional」を選択した場合は、信用取引が許可され、信用取引を有効にするチェックボックスは検証されません。 「Limited」を選択した場合は、ユーザーが信用取引のチェックボックスを選択して有効にすると、エラーが表示されます。

以下の画像の中央にある垂直線をスライドすると、入力値の審査の設定とその結果を表示できます。

App Studioでは、2種類のプロパティ値またはプロパティ値と定数の間のtrue/false比較がサポートされています。 このタイプの比較を設定できない場合は、Dev Studioのバリデートルールフォームで検証関数のライブラリーにアクセスできます。 たとえば、過去4週間または8週間以内の日付に該当するかどうかをチェックする機能や、ユーザーが特定の種類の添付ファイルをケースにアップロードしたかどうかをチェックする機能を利用できます。 各関数により、検証動作を設定するカスタマイズされたフィールドセットが提供されます。

次の例では、関数を使用して検証を設定する方法を示しています。 バリデートルールで関数A [attachment category] is [attached/not attached] to the current caseを使用すると、新規従業員のオンボーディングプロセスの一環として、ユーザーが本人確認書類を添付したことが検証されます。

以下の画像の中央にある垂直線をスライドすると、添付ファイルの検証の設定とその結果を表示できます。