ドキュメントAEMユーザーガイド

[AEM Forms]{class="badge positive" title="AEM Formsに適用）。"}

フォームデータモデル（FDM）の操作 work-with-form-data-model

最終更新日： 2026年9月25日
  • 適用対象：
  • Experience Manager as a Cloud Service

作成対象：

  • Beginner
  • Intermediate
  • Admin
  • User
バージョン
記事リンク
AEM 6.5
ここをクリックしてください
AEM as a Cloud Service
この記事

フォームデータモデル （FDM） エディター​は、Adobe Experience Manager （AEM） Formsで​ フォームデータモデル （FDM） ​を作成、編集、設定するための直感的なユーザーインターフェイスと統合ツールを提供します。 エディターを使用すると、関連するデータソースから​データモデルオブジェクト、プロパティ​および​ サービス ​をフォームデータモデル（FDM）内で直接追加および設定できます。

フォームデータモデルエディターの機能

data-integration

フォームデータモデルエディターは、次の主要タスクをサポートしています。

  • 関連するデータ ソースからFDMにデータ モデル オブジェクト、プロパティ、サービス​を追加して設定します。
  • データソースを使用せずにデータモデルオブジェクトとプロパティを作成します。 最初にこれらのオブジェクトを定義し、後でそれぞれのデータモデルオブジェクトとプロパティにバインドして、デザインをソース設定から切り離すことができます。
  • データモデルオブジェクトプロパティのサンプルデータを生成して編集。 このサンプルデータでは、プレビュー時にアダプティブFormsを事前入力するので、作成者とテスターはデプロイメント前に現実的な値を使用してフォームの動作を検証できます。
  • FDMで設定されたデータモデルオブジェクトとサービスをテストして​基になるデータソースと正しく統合されていることを確認します。

前提条件

Forms のデータ統合機能を初めて使用する場合や、これまでにデータソースの設定やフォームデータモデル（FDM）の作成を行ったことがない場合は、以下のトピックを参照してください。

フォームデータモデルエディターを使用して実行できるさまざまなタスクと設定について詳しくは、この記事を参照してください。

NOTE
フォームデータモデル（FDM）を作成して作業するには、fdm-author​と​forms-user グループの両方のメンバーである必要があります。 これらのグループのメンバーになるには、Experience Manager管理者にお問い合わせください。

データモデルオブジェクトとサービスの追加 add-data-model-objects-and-services

データソースを使用してフォームデータモデル（FDM）を作成した場合、フォームデータモデルエディターを使用して、データモデルオブジェクトとサービスの追加、プロパティの設定、データモデルオブジェクト間の関連付けの構築、フォームデータモデル（FDM）とサービスのテストを行うことができます。 これにより、単一の編集環境内で、接続されたデータソースから直接完全な機能的なデータモデルを組み立てることができます。

フォームデータモデル（FDM）で使用可能なデータソースからデータモデルオブジェクトとサービスを追加できます。 追加したデータモデルオブジェクトは「モデル」タブに表示され、追加したサービスは「サービス」タブに表示され、2つのオブジェクトタイプを明確に分離して設定とテストを容易にします。

データモデルオブジェクトとサービスを追加するには、以下の手順を実行します。

  1. Experience Manager オーサーインスタンスにログインし、Forms > Data Integrations​に移動し、データモデルオブジェクトを追加するフォームデータモデル（FDM）を開きます。

  2. データソースペインでデータソースを展開して、使用可能なデータモデルオブジェクトとサービスを表示します。

  3. フォームデータモデル（FDM）に追加するデータモデルオブジェクトとサービスを選択し、選択済みを追加​を選択します。 これにより、選択したオブジェクトとサービスがFDMに追加されるので、それらのプロパティを設定し、それらの間の関連付けを構築できます。

    selected-objects

    選択されたデータモデルオブジェクトとサービス

    「モデル」タブには、フォームデータモデル（FDM）に追加されたすべてのデータモデルオブジェクトとそのプロパティのグラフィック表現が表示されます。 各データモデルオブジェクトは、フォームデータモデル（FDM）のボックスで表されるため、モデルの構造を視覚的にスキャンしやすくなります。

    model-tab

    追加したデータモデルオブジェクトが表示された「モデル」タブ

    note
    NOTE
    データモデルオブジェクトのボックスを選択してドラッグすると、コンテンツ領域内にデータモデルオブジェクトを配置できます。 フォームデータモデル（FDM）で追加されたすべてのデータモデルオブジェクトは、データソースパネルでグレー表示され、既に追加されていることを示し、重複したエントリを防ぎます。

    「サービス」タブには、追加されたサービスが一覧表示されます。

    services-tab

    データモデルサービスが表示された「サービス」タブ

    note
    NOTE
    データモデルオブジェクトとサービスに加えて、OData （Open Data Protocol）サービスメタデータドキュメントには、2つのデータモデルオブジェクト間の関連付けを定義し、関連するデータをトラバースできるようにするナビゲーションプロパティが含まれています。 詳しくは、OData サービスのナビゲーションプロパティの操作を参照してください。

  4. 「保存」を選択して、フォームモデルオブジェクトを保存します。

    note
    NOTE
    フォームデータモデル（FDM）の「サービス」タブで設定したサービスは、アダプティブフォームルールを使用して直接呼び出すことができるため、フォーム作成者は、実行時にデータの取得や書き込みなどのデータ操作をトリガーできます。 設定されたサービスは、ルールエディターの「サービスの呼び出し」アクションで使用できます。 アダプティブフォームのルールでこれらのサービスを使用する方法について詳しくは、​ ルールエディターでのサービスの呼び出しとルールの値の設定を参照してください。

データモデルオブジェクトと子プロパティの作成 create-data-model-objects-and-child-properties

データモデル​は、情報を​ オブジェクト ​と呼ばれる構造化された再利用可能なユニットに整理します。各ユニットには、オブジェクトの個々の属性を表す​ 子プロパティ ​を含めることができます。 明確に定義されたオブジェクトを作成し、その下に子プロパティをネストすることは、アプリケーションが保存、検証、交換する情報を明確に階層的に表現するため、あらゆるデータモデルを構築する上で基本となるステップです。

データモデルオブジェクトと子プロパティとは何ですか？

  • データモデルオブジェクト​は、関連するフィールドを単一の論理エンティティにグループ化する名前付きコンテナです。 オブジェクトは、顧客、注文、製品などの実世界または概念的なアイテムを表し、他の要素が接続するトップレベルの構造として機能します。
  • 子プロパティ​は、オブジェクト内にネストされた個々のフィールドです。 各子プロパティは、親オブジェクトの1つの属性と、その名前、データタイプ、値が必要かどうかなどの特性を定義します。 親オブジェクトの下にプロパティをネストすると、関連するデータがグループ化され、わかりやすくなり、モデルの保守が容易になります。

この親子関係が、データモデルに階層を与えます。 オブジェクトは親として機能し、子プロパティはそれからコンテキストを継承し、各属性が記述するエンティティに明確に関連付けられるようにします。

データモデルオブジェクトの作成方法

データモデルで新しいオブジェクトを定義するには、次の手順に従います。

  1. オブジェクトに名前を付けます。 オブジェクトが表すエンティティを識別する、わかりやすい名前を選択します。 一貫した命名により、モデルを読みやすく、後で参照しやすくなります。
  2. オブジェクトをコンテナとして定義します。 関連する子プロパティを保持する最上位の要素として、オブジェクトを設定します。
  3. 子プロパティを追加します。 オブジェクトの属性を説明する個々のフィールドを添付し、各フィールドを順番に定義します。
  4. 各プロパティにデータタイプを割り当てます。 データを正しく検証できるように、各子プロパティが受け入れる値（テキスト、数値、ブール値など）のタイプを指定します。
  5. 要件ルールを設定します。 どの子プロパティが必要で、どの子プロパティがオプションかを示し、モデルが適用する制約がアプリケーションによって異なることを確認します。

子プロパティの追加

子プロパティをオブジェクトに追加する場合は、各プロパティを次の詳細で定義します。

  • プロパティ名 – 親オブジェクト内の属性に対する一意で記述的なラベル。
  • データ型 — プロパティが保存する値の種類。値の検証および処理方法を制御します。
  • 必須またはオプションのステータス — プロパティに常に値が必要かどうか。
  • ネストされた構造（該当する場合） – 子プロパティ自体を独自の子プロパティを持つオブジェクトにすることができ、複雑でマルチレベルのデータをモデル化できます。 このネスト化により、データモデルは詳細に構造化された情報を表すことができます。

実用的な用途とメリット

オブジェクトと子プロパティを使用してデータモデルを構造化すると、いくつかの実用的なメリットが得られます。

  • 一貫性 – 関連するフィールドを共有オブジェクトの下にグループ化すると、データがアプリケーション全体で一様に保存および解釈されます。
  • 再利用性 – 明確に定義されたオブジェクトを複数の場所で参照できるため、重複を減らすことができます。
  • 検証 — データタイプと要件ルールを子プロパティに割り当てると、システムは無効または不完全なデータを自動的に検出できます。
  • スケーラビリティ — オブジェクトはネストされた子プロパティをサポートするため、モデルは大きくなって、混乱することなく、ますます複雑な関係を表すことができます。

ベストプラクティス

  • オブジェクトとその子プロパティの両方に明確で記述的な名前を使用して、モデルを自己文書化しておきます。
  • 関連する属性を、関連のない構造に広げるのではなく、同じ親オブジェクトの下にグループ化します。
  • データタイプと要件ルールを早い段階で定義します。これにより、信頼できる検証が確立されます。
  • 意図的なネストを維持：追加の階層がデータの構造を意味のある形で反映している場合にのみ、子プロパティをネストします。

オブジェクトとその子プロパティを慎重に定義することで、データモデルを作成します。このモデルは、整理され、メンテナンス可能で、アプリケーションが使用するエンティティを正確に表すことができます。

データモデルオブジェクトの作成 create-data-model-objects

設定済みのデータソースからデータモデルオブジェクトを追加できますが、データソースを使用せずに、エンティティとも呼ばれるデータモデルオブジェクトを作成することもできます。 データモデルオブジェクト​は、フォームデータモデル（FDM）内の構造化エンティティで、プロパティの論理グループを表します。このプロパティは、後でデータソースフィールドにバインドしたり、個別に使用したりできます。 この機能は、フォームデータモデル（FDM）でデータソースをまだ設定していない場合に特に便利です。バックエンド統合が行われる前に、データ構造の設計を開始できるからです。

データソースを使用せずにデータモデルオブジェクトを作成する手順

データソースを使用せずにデータモデルオブジェクトを作成するには：

  1. Experience Manager作成者インスタンスにログインし、Forms > Data Integrations​に移動し、データモデルオブジェクトまたはエンティティを作成するフォームデータモデル（FDM）を開きます。

  2. 「エンティティを作成」を選択します。

  3. データモデルを作成ダイアログで、データモデルオブジェクトの名前を指定して「追加」を選択します。 データモデルオブジェクトがフォームデータモデル（FDM）に追加されます。 新しく追加されたデータモデルオブジェクトは、データソースにバインドされておらず、次の画像に示すように、プロパティはありません。 このオブジェクトは連結されていないので、プロパティを定義するか、データソースに接続するまで、構造プレースホルダーとしてのみ存在します。

    new-entity

次の手順 next-steps-data-model-object

連結されていないデータモデルオブジェクトを作成したら、子プロパティを追加して構造を定義します。 これらの子プロパティを使用すると、オブジェクトが保持するフィールドと属性を指定でき、データ統合を設定したら、後でデータソースにバインドできます。 これにより、データモデルオブジェクトが完全に機能し、フォームで使用できるようになります。

子プロパティの追加 child-properties

フォームデータモデル（FDM）エディターでは、データモデルオブジェクト内に子プロパティを作成できます。 新しく作成された子プロパティは、デフォルトではデータソース内のどのプロパティにもバインドされません。 後で、子プロパティを含むデータモデルオブジェクト内の別のプロパティにバインドできます。

子プロパティを作成するには、以下の手順を実行します。

  1. フォームデータモデルでデータモデルオブジェクトを選択して「子プロパティを作成」を選択します。

  2. 子プロパティを作成​ダイアログで、 プロパティの名前とデータタイプをそれぞれ​ 名前 ​フィールドと​ タイプ ​フィールドに指定します。 必要に応じて、プロパティのタイトルと説明を指定できます。

  3. プロパティが​ 計算されたプロパティ ​の場合、計算された​を有効にします。このプロパティの値は、直接入力するのではなく​ ルールまたは式 ​に基づいて評価されます。 詳しくは、プロパティの編集を参照してください。

  4. データモデルオブジェクトがデータソースにバインドされている場合、追加された子プロパティは、同じ名前とデータタイプを持つ親データモデルオブジェクトのプロパティに自動的にバインドされます。 この自動バインディングは名前とデータタイプの両方で一致し、追加の手動ステップを行うことなく、子プロパティが親と一貫した状態を維持します。

    子プロパティをデータモデルオブジェクトのプロパティに手動で連結するには、「参照をバインド」フィールドの横に表示されている参照アイコンを選択します。 オブジェクトの選択​ダイアログには、親データモデルオブジェクトのすべてのプロパティが一覧表示されます。 バインドするプロパティを選択し、チェックマークアイコンをクリックします。 有効なバインディングにはデータタイプの一致が必要なため、子プロパティと同じデータタイプのプロパティのみを選択できます。

  5. 完了​を選択して子プロパティを保存し、保存​を選択してフォームデータモデル （FDM）を保存します。 これで、子プロパティがデータモデルオブジェクトに追加されました。

データモデルオブジェクトとプロパティを作成した後も、フォームデータモデル（FDM）に基づいて引き続きアダプティブ Formsを作成できます。 その後、データソースが利用可能で設定されている場合は、フォームデータモデル（FDM）をデータソースにバインドできます。 その結果、関連付けられたすべてのアダプティブFormsでバインディングが自動的に更新されるので、変更は手動で再設定しなくても反映されます。 フォームデータモデル（FDM）を使用したアダプティブ Formsの作成について詳しくは、​ フォームデータモデルの使用を参照してください。

データモデルオブジェクトとプロパティの連結 bind-data-model-objects-and-properties

フォームデータモデル（FDM）と統合するデータソースが使用可能な場合は、​ データソースの更新の説明に従って、それらをフォームデータモデル（FDM）に追加できます。 連結されていないデータモデルオブジェクトまたはプロパティ​は、フォームデータモデル（FDM）に存在するものの、接続されたデータソースのフィールドにまだマッピングされていないため、連結が確立されるまでデータの読み取りまたは書き込みはできません。 次に、バインドされていないデータモデルオブジェクトとプロパティを以下の手順でバインドします。

  1. フォームデータモデルで、データソースへのバインドの対象となるバインドされていないデータソースを選択します。

  2. 「プロパティを編集」を選択します。

  3. プロパティを編集​ペインで、バインド​フィールドの横にある参照アイコンを選択します。 参照アイコンが開き、オブジェクトを選択 ダイアログが表示され、フォームデータモデル（FDM）に追加されたデータソースが一覧表示されます。

    select-object

  4. データソースツリーを展開し、バインドするデータモデルオブジェクトを選択し、チェックアイコンを選択します。

  5. 「完了」を選択してプロパティを保存し、「保存」を選択してフォームデータモデルを保存します。 これで、データモデルオブジェクトがデータソースにバインドされました。 これにより、オブジェクトが実行時に接続されたデータソースに対して読み取りと書き込みを実行できるようになります。 保存の結果、データモデルオブジェクトは「連結なし」とマークされなくなり、連結が完了したことを確認します。

    bound-model-object

サービスの設定 configure-services

読み取り/書き込みサービスを設定すると、データモデルオブジェクトは、フォームデータモデル（FDM）内のデータを読み取り/書き込みできます。 データモデルオブジェクトの読み取りおよび書き込みサービスを設定するには、次の手順を実行します。

  1. データモデルオブジェクト上部のチェックボックスを選択して「プロパティを編集」を選択します。

    edit-properties

    データモデルオブジェクトの読み取りサービスと書き込みサービスの設定を行う「プロパティを編集」

    プロパティを編集ダイアログが表示されます。

    edit-properties-2

    プロパティを編集ダイアログ

    note
    NOTE
    データモデルオブジェクトとサービスに加えて、OData （Open Data Protocol）サービスメタデータドキュメントには、2つのデータモデルオブジェクト間の関連付けを定義する​ ナビゲーションプロパティ ​が含まれています。 OData サービスのデータソースをフォームデータモデル（FDM）に追加すると、データモデルオブジェクト内のすべてのナビゲーションプロパティに対し、フォームデータモデル（FDM）でサービスを使用できます。 このサービスを使用して、対応するデータモデルオブジェクトのナビゲーションプロパティを読み取ることができます。
    このサービスの使用について詳しくは、「OData サービスのナビゲーションプロパティの操作」を参照してください。

  2. 「トップレベルオブジェクト」を切り替えて、データモデルオブジェクトがトップレベルモデルオブジェクトであるかどうかを指定します。

    フォームデータモデル（FDM）で設定したデータモデルオブジェクトは、そのフォームデータモデル（FDM）に基づくアダプティブフォームのコンテンツブラウザーの「データモデルオブジェクト」タブで使用できるようになります。 2つのデータモデルオブジェクト間に関連付けを追加すると、関連付けるデータモデルオブジェクトは、データモデルオブジェクト タブで関連付けるデータモデルオブジェクトの下にネストされます。 ネストされたデータモデルが最上位のオブジェクトである場合は、「データモデルオブジェクト」タブにもそのデータモデルが個別に表示されます。 その結果、オブジェクトは2回表示され、ネストされた階層内のエントリと外部のエントリが2回表示され、フォーム作成者が混乱する可能性があります。 関連付けられたデータモデルオブジェクトをネストされた階層にのみ表示するには、トップレベルオブジェクト プロパティを無効にします。 これにより、フォーム作成者は、あいまいな表現をひとつだけ確認できるため、フォーム作成時の混乱を軽減できます。

  3. 選択したデータモデルオブジェクトの​ 読み取り ​および​書き込み サービスを選択します。 選択したサービスの引数が設定用に表示されます。

    read-write-services

    従業員データソースに対して設定されている読み取りサービスと書き込みサービス

  4. 読み取りサービスの引数に表示されている aem63edit を選択して、ユーザープロファイル属性、リクエスト属性またはリテラル値にその引数を連結し、連結値を指定します。

  5. 「完了」を選択して引数を保存し、もう一度「完了」を選択してプロパティを保存します。次に、「保存」を選択してフォームデータモデル（FDM）を保存します。

バインド読み取りサービスの引数 bindargument

読み取りサービス引数を、バインディング値に基づいて3つのバインディングタイプ（ユーザープロファイル属性、リクエスト属性、または​リテラル値）のいずれかにバインドします。 Read サービスは、この値を引数として使用して、指定された値に関連付けられた詳細をデータソースから取得します。 各連結タイプは、引数の値の元となる場所（固定入力、ログインユーザーのプロファイル、受信リクエスト）を決定します。

リテラル値 literal-value

連結先​ドロップダウンメニューから「リテラル」を選択し、「連結値」フィールドに値を入力します。 値に関連付けられている詳細がデータソースから取得されます。 リテラルバインディングは、ユーザーやリクエストに依存しない固定された変更されない入力を提供するため、静的値に関連する詳細を取得するには、このオプションを使用します。

この例では、4367655678 に関連付けられた詳細が、mobilenum 引数の値としてデータソースから取得されます。 モバイル番号引数の値を渡したときに返される関連する詳細には、顧客名、顧客アドレス、市区町村などのプロパティを含めることができます。

リテラル値

ユーザープロファイルの属性 user-profile-attribute

連結先​ドロップダウンメニューから「ユーザープロファイル属性」を選択し、「連結値」フィールドに属性名を入力します。 Experience Manager インスタンスにログインしたユーザーの詳細は、属性名に基づいてデータソースから取得されます。

バインディング値 フィールドで指定された属性名には、ユーザーの属性名までの完全なバインディングパスを含める必要があります。 以下の URL を開いて、CRXDE のユーザー詳細にアクセスします。

https://[server-name]:[port]/crx/de/index.jsp#/home/users/

ユーザープロファイル

この例では、grios ユーザーの「連結値」フィールドに profile.empid を指定します。

引数を編集

id引数は、ユーザープロファイルから​ empid ​属性の値を取り出し、それを引数としてRead サービスに渡します。 次に、読み取りサービスは、ログインユーザーに関連付けられているempidの従業員データモデルオブジェクトから、関連付けられたプロパティの値を読み取って返します。

リクエスト属性 request-attribute

リクエスト属性バインディングを使用して、受信リクエストで指定された値に基づいて、データソースから関連するプロパティを取得します。

  1. 連結先​ドロップダウンメニューから「リクエスト属性」を選択し、「連結値」フィールドに属性名を入力します。

  2. head.jsp のオーバーレイを作成します。 オーバーレイを作成するには、CRX DEを開き、https://<server-name>:<port number>/crx/de/index.jsp#/libs/fd/af/components/page2/afStaticTemplatePage/head.jsp ファイルを https://<server-name>:<port number>/crx/de/index.jsp#/apps/fd/af/components/page2/afStaticTemplatePage/head.jsp にコピーします

    note
    NOTE
    • 静的テンプレートを使用する場合は、head.jsp を以下の場所にオーバーレイします。
      /libs/fd/af/components/page2/afStaticTemplatePage/head.jsp
    • 編集可能なテンプレートを使用する場合は、aftemplatedpage.jsp を以下の場所でオーバーレイします。
      /libs/fd/af/components/page2/aftemplatedpage/aftemplatedpage.jsp

  3. リクエスト属性に paramMap を設定します。 例えば、apps フォルダーの .jsp ファイルに以下のコードを含めます。

    code language-javascript 
    <%Map paraMap = new HashMap();
 paraMap.put("<request_attribute>",request.getParameter("<request_attribute>"));
 request.setAttribute("paramMap",paraMap);

    例えば、次のコードを使用して、データソースからpetIdの値を取得します。

    code language-javascript 
    <%Map paraMap = new HashMap();
paraMap.put("petId",request.getParameter("petId"));
request.setAttribute("paramMap",paraMap);%>

その結果、読み取りサービスは、リクエストで指定された属性名に基づいて、データソースから詳細を取得します。

例えば、リクエストで属性をpetid=100として指定すると、その属性値に関連付けられたプロパティがデータソースから取得されます。

関連付けの追加 add-associations

関連付けは通常、データソース内のデータモデルオブジェクト間で作成され、これらの関連付けは、オブジェクトがフォームデータモデル（FDM）に取り込まれたときに保持されます。 関連付けは2つのデータモデルオブジェクト間の関係を定義し、一対一​または​ 一対多 ​のいずれかを指定できます。

1つのレコードが複数のレコードに関連する場合、1対多​の関連付けが存在します。 例えば、1人の従業員が、従業員レコードに関連付けられた複数の扶養家族を持つことができます。 この関係は1対多の関連付けと呼ばれ、関連付けられたデータモデルオブジェクトを接続する行に1:nによって示されます。 関係が正確に1つの一致するレコードを返す場合、1対1の​の関連付けが存在します。例えば、関連付けが特定の従業員IDの一意の従業員名を返す場合、1対1の関連付けになります。

関連付けられたデータモデルオブジェクトをデータソースからフォームデータモデル（FDM）に追加すると、関連付けは保持され、矢印で結びつけられて表示されます。 また、1つのフォームデータモデル（FDM）内で、異なるデータソースをまたいでデータモデルオブジェクト間の関連付けを追加することもできます。これにより、異なるバックエンドシステムから取得した関連データを組み合わせることができます。

NOTE
Java Database Connectivity （JDBC）データソース内の事前定義済みの関連付けは、フォームデータモデル（FDM）に保持されません。これは、これらの関連付けが自動的に繰り越されないためです。 それらは手動で作成する必要があります。

関連付けを追加するには：

  1. データモデルオブジェクトの上部にあるチェックボックスを選択して選択し、関連付けを追加​を選択します。 関連付けを追加ダイアログが表示されます。

    add-association

    note
    NOTE
    データモデルオブジェクトとサービスに加えて、Open Data Protocol （OData）サービスメタデータドキュメントには、2つのデータモデルオブジェクト間の関連付けを定義するナビゲーションプロパティが含まれています。 フォームデータモデル（FDM）で関連付けを追加する場合は、これらのナビゲーションプロパティを使用できます。 詳しくは、OData サービスのナビゲーションプロパティの操作を参照してください。

    関連付けを追加ダイアログが表示されます。

    add-association-2

    関連付けを追加ダイアログ

  2. 関連付けを追加ペインで、以下の操作を実行します。

    • 関連付けのタイトルを入力します。
    • 関連付けのタイプ（「1 対 1」または「1 対多」）を選択します。
    • 関連付けるデータモデルオブジェクトを選択します。
    • 選択したモデルオブジェクトからデータを読み取るための読み取りサービスを選択します。 読み取りサービスの引数が表示されます。 必要に応じて引数を編集して変更し、関連付けるデータモデルオブジェクトのプロパティにバインドします。

    以下に示す例では、「扶養家族」データモデルオブジェクトの読み取りサービスのデフォルト引数が dependentid になっています。

    add-association-example

    「扶養家族」読み取りサービスのデフォルト引数が dependentid になっている

    ただし、引数は、関連付けるデータモデルオブジェクト間で共有される共通プロパティである必要があります。この例ではEmployeeidです。 したがって、関連付けは一致するキーに依存しているため、Employeeid引数は従業員データモデルオブジェクトのid プロパティにバインドする必要があります。 このバインディングにより、システムは関連する依存関係の詳細を依存関係データモデルオブジェクトから取得できます。

    add-association-example-2

    更新後の引数とバインディング

    「完了」を選択して、引数を保存します。

  3. 完了​を選択して関連付けを保存し、保存​を選択してフォームデータモデル （FDM）を保存します。

  4. 必要に応じて、手順を繰り返して追加の関連付けを作成します。

NOTE
追加した関連付けは、入力したタイトルと、関連データモデルオブジェクトを接続する線とともに、データモデルオブジェクトのボックス内に表示されます。
関連付けを編集するには、関連付けのチェックボックスを選択し、関連付けを編集​を選択します。

added-association

プロパティの編集 properties

プロパティを編集すると、フォームデータモデル（FDM）​内でのデータモデルオブジェクト、そのプロパティおよびサービスの動作を設定できます。 プロパティを編集 ペインを使用して、FDMがデータを読み取り、書き込み、および返す方法を決定するサービス、データ型、キー、および引数を定義します。

プロパティを編集するには：

  1. フォームデータモデル（FDM）​のデータモデルオブジェクト、プロパティ、またはサービスの横にあるチェックボックスを選択します。

  2. 「プロパティを編集」を選択します。 選択したモデルオブジェクト、プロパティまたはサービスの​ プロパティを編集 ​ペインが開きます。

    • データモデルオブジェクト: 読み取りおよび書き込みサービス​を指定し、引数を編集します。 これらのサービスは、オブジェクトの基礎となるデータソースからデータを取得して保持する方法を決定します。

    • プロパティ: プロパティの​type、sub-type​および​ format ​を指定します。 選択したプロパティを、各レコードを一意に識別するデータモデルオブジェクトの​ プライマリキー ​として指定することもできます。

    • サービス：サービスの入力モデルオブジェクト、出力タイプおよび引数を指定します。 Get サービス​の場合、サービスが複数のレコードを正しく処理するように、配列を返すかどうかを指定できます。

      edit-properties-service

    Get サービスのプロパティを編集ダイアログ

  3. 「完了」を選択してプロパティ設定を保存し、「保存」を選択して​ フォームデータモデル（FDM） ​を保存します。 この最終的な保存では、すべてのプロパティの変更がFDMにコミットされます。

計算済みプロパティを作成 computed

計算プロパティ​は、その値をルールまたは式から自動的に導き出します。 ルールを使用して、計算プロパティの値をリテラル文字列、数値、数式の結果、または​ フォームデータモデル（FDM） ​の別のプロパティの値に設定できます。 値は手動で入力するのではなく計算されるので、計算されたプロパティはデータ入力エラーを減らし、基礎となるデータの変更に伴って依存フィールドの一貫性を保ちます。

例：FullName計算プロパティの作成

例えば、既存の​ FirstName ​と​ LastName ​のプロパティを連結した値の計算プロパティ FullName​を作成できます。 これを行うには、次の手順に従います。

  1. データ型が​ 文字列 ​のFullNameという名前の新しいプロパティを作成します。

  2. 「計算済み」を有効にし、「完了」を選択してプロパティを作成します。

    計算済み

    FullName​計算プロパティが作成されます。 プロパティの横にアイコンが表示され、それが計算されたプロパティであることを示します。

    computed-prop

  3. 「FullName」プロパティを選択し、「ルールを編集」を選択します。 ルールエディターウィンドウが開きます。

  4. ルールエディターウィンドウで、「作成」を選択します。 「Set Value」ルールウィンドウが開きます。

    「オプションを選択」ドロップダウンから、数式​を選択します。 その他の使用可能なオプションは、フォームデータモデルオブジェクト​および​ 文字列 ​です。

  5. 数式で、最初のオブジェクトとして​FirstName、2番目のオブジェクトとして​ LastName ​を選択します。 演算子として「プラス」を選択します。

    「完了」を選択し、「閉じる」を選択してルールエディターウィンドウを閉じます。 完了したルールは、次のようになります。

    ルール

  6. フォームデータモデル （FDM）​で、保存​を選択します。 これで、計算済みプロパティが設定されました。 これにより、FirstName​または​ LastName ​が変更されるたびに​ FullName ​値が自動的に更新されるので、連結されたフルネームは常にソースフィールドと同期したままになります。

OData サービスのナビゲーションプロパティを操作 work-with-navigation-properties-of-odata-services

OData サービスの​ ナビゲーションプロパティ ​は、2つのデータモデルオブジェクト間の関連付けを定義し、あるエンティティが別のエンティティにどのように関連し、別のエンティティにトラバースできるかを確立します。 これらのプロパティは、エンティティタイプ​または​ 複合タイプ ​で定義され、クライアントが1つのレコードから関連するレコードに移動できるようにするものです。 例えば、サンプル TripPinのOData サンプルサービスのメタデータファイルからの次の抽出では、Person エンティティに3つのナビゲーションプロパティが含まれています：Friends、BestFriend、Trips。

ナビゲーションプロパティについて詳しくは、OData ドキュメント ​を参照してください。

<edmx:Edmx xmlns:edmx="https://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
<script/>
<edmx:DataServices>
<Schema xmlns="https://docs.oasis-open.org/odata/ns/edm" Namespace="Microsoft.OData.Service.Sample.TrippinInMemory.Models">
<EntityType Name="Person">
<Key>
<PropertyRef Name="UserName"/>
</Key>
<Property Name="UserName" Type="Edm.String" Nullable="false"/>
<Property Name="FirstName" Type="Edm.String" Nullable="false"/>
<Property Name="LastName" Type="Edm.String"/>
<Property Name="MiddleName" Type="Edm.String"/>
<Property Name="Gender" Type="Microsoft.OData.Service.Sample.TrippinInMemory.Models.PersonGender" Nullable="false"/>
<Property Name="Age" Type="Edm.Int64"/>
<Property Name="Emails" Type="Collection(Edm.String)"/>
<Property Name="AddressInfo" Type="Collection(Microsoft.OData.Service.Sample.TrippinInMemory.Models.Location)"/>
<Property Name="HomeAddress" Type="Microsoft.OData.Service.Sample.TrippinInMemory.Models.Location"/>
<Property Name="FavoriteFeature" Type="Microsoft.OData.Service.Sample.TrippinInMemory.Models.Feature" Nullable="false"/>
<Property Name="Features" Type="Collection(Microsoft.OData.Service.Sample.TrippinInMemory.Models.Feature)" Nullable="false"/>
<NavigationProperty Name="Friends" Type="Collection(Microsoft.OData.Service.Sample.TrippinInMemory.Models.Person)"/>
<NavigationProperty Name="BestFriend" Type="Microsoft.OData.Service.Sample.TrippinInMemory.Models.Person"/>
<NavigationProperty Name="Trips" Type="Collection(Microsoft.OData.Service.Sample.TrippinInMemory.Models.Trip)"/>
</EntityType>

フォームデータモデルでのナビゲーションプロパティの表示方法

フォームデータモデル（FDM）​でOData サービスを設定すると、エンティティコンテナ内のすべてのナビゲーションプロパティが、FDM内の単一のサービスを通じて自動的に使用できるようになります。 この統合により、FDMはアソシエーションを個別に表示するため、各アソシエーションに対して個別のサービスは必要なくなります。 TripPin OData サービスのこの例では、Person エンティティ コンテナ内の3つのナビゲーション プロパティはすべて、FDM内の1つの​GET LINK サービスを使用して読み取ることができます。

次に、FDMの​GET LINK of Person /People サービスをハイライトします。これは、TripPin OData サービスのPerson エンティティの3つのナビゲーションプロパティ（Friends、BestFriend、Trips）を組み合わせたサービスです。

nav-prop-service

FDMの「サービス」タブに​GET LINK サービスを追加すると、そのプロパティを編集して、サービスで使用する出力モデルオブジェクトとナビゲーションプロパティを選択できます。 例えば、次の​GET LINK of Person /People サービスでは、出力モデルオブジェクトとして​ Trip ​を、ナビゲーションプロパティとして​ Trips ​を使用しています。

edit-prop-nav-prop

NOTE
NavigationPropertyName​引数の​Default Value フィールドで使用できる値は、Return配列の状態によって異なります。 トグルボタン。 有効にすると、フィールドに​コレクション タイプのナビゲーションプロパティが表示されます。

この例では、出力モデルオブジェクトとして​ Person ​を選択し、配列を返すか​に応じて、ナビゲーションプロパティ引数を​ Friends ​または​ BestFriend ​に設定することもできます は有効または無効です。

edit-prop-nav-prop2

関連でのナビゲーションプロパティの使用

同様に、FDMで関連付けを追加する際に、GET LINK サービスを選択し、そのナビゲーションプロパティを設定できます。 ただし、ナビゲーションプロパティの選択は、結合先フィールド​が​ リテラル ​に設定されている場合にのみ可能です。この要件のため、ナビゲーションプロパティオプションは、その結合が正しく設定されるまで選択できません。

add-association-nav-prop

サンプルデータの生成と編集 sample

フォームデータモデル（FDM）エディター​は、計算プロパティ​を含む、フォームデータモデル内のすべてのデータモデルオブジェクトプロパティに対して​ サンプルデータ ​を生成します。 このサンプルデータは、各プロパティに設定された​ データタイプ ​に準拠する一連のランダムな値で構成され、ライブデータソース接続を必要とせずに現実的なテスト値を提供します。

サンプルデータについて

サンプルデータは既製のテスト入力として機能し、フォームデータモデルを実稼動データにバインドする前にプレビューし、その動作を検証できます。 生成された各値は、設定されたプロパティのデータタイプを尊重するため、サンプルセットには実際のレコードの想定される構造と形式が反映され、バインディング、計算ロジック、フォーム動作を開発の初期段階で検証するのに役立ちます。

また、生成された値を編集し、変更を保存することもできます。 サンプルデータを再生成しても保存されたデータは保持されるため、手動でキュレートしたテストケースは再生成しても保持されます。 これにより、新しいランダム値が生成されるたびに編集を失うことなく、安定して再利用可能なテストシナリオを構築することが実用的になります。

サンプルデータを生成および編集する手順

  1. フォームデータモデル （FDM）​を開き、サンプルデータの編集​を選択します。 FDM エディターは、サンプルデータを編集 ウィンドウにサンプルデータを生成して表示します。

    サンプルデータの生成

  2. サンプルデータを編集 ウィンドウで、必要に応じてデータを編集し、保存​を選択します。 編集したサンプルデータは保存および保持され、サンプルデータを再生成した後でも使用できます。

データモデルオブジェクトとサービスのテスト test-data-model-objects-and-services

フォームデータモデル（FDM）を設定したら、設定されたデータモデルオブジェクトとサービスをテストしてから、ライブフォームにFDMをデプロイし、期待どおりに機能することを確認します。 デプロイメント前のテストでは、各オブジェクトとサービスが正しいデータを返すことが確認され、フォームが実稼動環境に入れたときにランタイムエラーが発生するリスクが軽減されます。

データモデルオブジェクトとサービスをテストするには、以下の手順を実行します。

  1. フォームデータモデル（FDM）でデータモデルオブジェクトまたはサービスを選択し、それぞれ​ モデルオブジェクトのテスト ​または​ サービスのテスト ​を選択します。

    「フォームデータモデルをテスト」ウィンドウが開きます。

    test-data-model

  2. フォームデータモデルのテスト ウィンドウで、入力 ペインからテストするデータモデルオブジェクトまたはサービスを選択します。 これにより、検証する特定のオブジェクトまたはサービスを特定できます。

  3. テストコードで引数値を指定し、テスト​を選択します。 テストが成功すると、出力 ペインの出力が返され、選択したオブジェクトまたはサービスが正しく設定され、意図したとおりにデータを取得または処理できることを確認します。

    テストの結果

同じ手順に従って、フォームデータモデル（FDM）で追加のデータモデルオブジェクトとサービスを検証し、モデル全体が使用前に確実に機能することを確認できます。

入力データの自動検証 automated-validation-of-input-data

フォームデータモデル（FDM）​は、DermisBridge API​が呼び出されるたびに、入力として受信したデータを自動的に検証し、フォームデータモデル内で定義された検証条件を適用します。 この検証は、APIの呼び出しに使用されるクエリオブジェクトで設定された​ValidationOptions フラグによって制御されます。 デフォルトでは、ValidationOptions フラグに値が設定されていない場合、FDMは入力データに対して​ BASIC ​検証を実行します。

ValidationOptions フラグレベル

ValidationOptions フラグは、FDMが入力を厳密に検証する方法を定義する次の3つの値のいずれかを受け入れます。

  • FULL: FDMは​ すべての定義された制約 ​に対して入力を検証します。 このレベルを使用すると、データが処理される前にすべてのデータタイプとビジネスルールの制約を適用できます。
  • OFF: FDMは​検証を実行しません。 入力データは制約チェックなしで通過します。
  • BASIC: FDMは​ required ​および​ nullable ​の制約のみを検証します。 これにより、必須フィールドが存在し、null処理ルールが完全な制約セットを評価することなく尊重されるようになります。

ValidationOptions フラグに値が設定されていない場合、FDMはデフォルトで​ BASIC ​検証を適用します。

検証フラグの設定

次の例では、検証フラグを​ FULL ​に設定し、すべての制約に対して検証を有効にします。

operationOptions.setValidationOptions(ValidationOptions.FULL);
NOTE
入力データ内の属性に指定する値は、メタデータドキュメント内のその属性に定義されたデータタイプと一致する必要があります。
データタイプチェックは検証レベルとは独立して実施されるので、指定された値が定義されたデータタイプと一致しない場合、DermisBridge API​はValidationOptions フラグ の値に関係なく、例外​を返します。 ログレベルが​ デバッグ ​に設定されている場合、APIは対応するエラーを​error.log ファイルに記録します。

データソース別のデータタイプの制約

フォームデータモデル（FDM）​は、定義されたデータタイプ制約のリストに対して入力データを検証します。 この制約のリストは、基礎となる​ データソース ​によって異なる可能性があるため、検証中に適用される正確な制約は、フォームデータモデルに関連付けられたデータソースによって決まります。

次の表に、サポートされている各データソースの入力データに適用されるデータタイプの制約を示します。

制約
説明
入力データソース
required
true の場合、パラメーターを入力データに含める必要があります。
Swagger、WSDL およびデータベース
nullable
true の場合、入力データでパラメーターの値を Null に設定できます。
WSDL、Odata およびデータベース
maximum
数値の上限を指定します。 また、上限として指定した最大値も入力データのパラメーターに割り当てることができます。
Swagger および WSDL
minimum
数値の下限を指定します。 また、下限として指定した最小値も入力データのパラメーターに割り当てることができます。
Swagger および WSDL
exclusiveMaximum
数値の上限を指定します。 上限として指定した最大値を入力データのパラメーターに割り当てないでください。
Swagger および WSDL
exclusiveMinimum
数値の下限を指定します。 下限として指定した最小値を入力データのパラメーターに割り当てないでください。
Swagger および WSDL
minLength
文字列に含まれる文字数の下限を指定します。 また、下限として指定した最小値も入力データのパラメーターに割り当てることができます。
Swagger および WSDL
maxLength
文字列に含まれる文字数の上限を指定します。 また、上限として指定した最大値も入力データのパラメーターに割り当てることができます。
Swagger、WSDL、Odata およびデータベース
pattern
文字の固定シーケンスを指定します。 文字が指定したパターンに適合する場合にのみ、入力文字列が正常に検証されます。
Swagger
minItems
配列の項目の最小数を指定します。 また、下限として指定した最小値も入力データのパラメーターに割り当てることができます。
Swagger および WSDL
maxItems
配列の項目の最大数を指定します。 また、上限として指定した最大値も入力データのパラメーターに割り当てることができます。
Swagger および WSDL
uniqueItems
true の場合、配列のすべての要素は入力データ内で一意である必要があります。
Swagger
enum（文字列）
入力データ内のパラメーターの値を固定の文字列の値のセットに制限します。 1 つ以上の要素がある配列であり、各要素は一意である必要があります。
Swagger、WSDL および Odata
enum （数値）
入力データ内のパラメーターの値を、一定の数値のセットに制限します。 1 つ以上の要素がある配列であり、各要素は一意である必要があります。
WSDL

Swagger制約を使用した入力データの検証

入力データが検証に合格するのは、注文ID​が存在し、その値が​ 1 ～ 10 ​の範囲内にある場合のみです。 この例では、入力データは、Swagger （OpenAPI） ファイルで定義されている​maximum、minimum、および​ required ​制約に対して検証されます。 次の3つの制約タイプは、受け入れられる入力を次のように管理します。

  • 必須 — パラメーターを指定する必要があります。欠落しているorderIdは検証に失敗します。
  • minimum – 値は​ 1 ​以下である必要があります。
  • maximum – 値は​ 10 ​を超えることはできません。

制約はAPI定義で直接宣言されるので、検証は操作が実行される前にスキーマレベルで自動的に実行されます。 これにより、適切に策定されたリクエストのみが基盤となるサービスに到達します。

   parameters: [
   {
   name: "orderId",
   in: "path",
   description: "ID of pet that must be fetched",
   required: true,
   type: "integer",
   maximum: 10,
   minimum: 1,
   format: "int64"
   }
   ]

検証失敗の動作とエラーのログ

入力データがこれらの条件を満たさない場合、システムは検証例外をスローします。 このエラーの結果、ログレベルが​ デバッグ ​に設定されると、error.log ファイルにエラーが書き込まれます。 このログ動作は、ログ エントリが失敗したパラメーター、違反した制約、違反した値を識別するため、開発者が違反した制約を正確に診断するのに役立ちます。

例えば、16​のorderIdを送信すると、宣言された​ 最大10 ​を超え、次のログエントリが生成されます。

21.01.2019 17:26:37.411 *ERROR* com.adobe.aem.dermis.core.validation.JsonSchemaValidator {"errorCode":"AEM-FDM-001-044","errorMessage":"Input validations failed during operation execution.","violations":{"/orderId":["numeric instance is greater than the required maximum (maximum: 10, found: 16)"]}}

エラーエントリは、エラーコード AEM-FDM-001-044、メッセージ "Input validations failed during operation execution."、およびviolations ブロックをキャプチャして、/orderId フィールド、必要な最大値​10、見つかった値（16）を特定します。 このような構造化された詳細により、範囲外の入力を簡単に識別して修正できます。

次の手順 next-steps

現在作業中の​ フォームデータモデル（FDM） ​は、アダプティブ Forms ワークフローで使用する準備ができています。 フォームデータモデルは、フォームが取得し、接続されたデータソースと交換するデータの構造と関係を表し、Adaptive Formsが直接バインドできる統一された再利用可能なスキーマを提供します。 このモデルは、基盤となるデータサービスを単一の一貫したレイヤーに抽象化するため、フォームは新しいフォームごとに統合ロジックを再構築することなく、ソースからの読み取りおよび書き込みを行うことができます。

モデルを導入したら、フォーム作成タスク全体に適用できます。 一般的な次のステップは次のとおりです。

  • フォームフィールドをモデル​にバインドして、アダプティブフォームコンポーネントがFDMで定義されたデータ属性に直接マッピングされるようにすることで、一貫したデータ取得と送信が可能になります。
  • モデルを通じて取得した既存のデータを​ フォームに事前入力 ​すると、手作業によるデータ入力を減らすことで、ユーザーエクスペリエンスが向上します。
  • フォーム送信​を設定して、キャプチャしたデータをモデルを介して接続されたデータソースに書き戻し、レコードを同期しておきます。
  • 複数のフォームでモデルを再利用​して、一貫性を維持し、設定の重複作業を削減します。

複数のワークフローをまたいで単一のフォームデータモデルを再利用すると、モデルの更新は、そのモデルに依存するあらゆるフォームに反映されるため、一貫性が促進され、継続的なメンテナンスが低下します。 アダプティブ Formsでのモデルの適用に関する詳細なガイダンスについては、​ フォームデータモデル（FDM）の使用を参照してください。

recommendation-more-help
experience-manager-cloud-service-help-main-toc