アダプティブフォームの操作のベストプラクティス best-practices-for-working-with-adaptive-forms

アダプティブフォームの新規作成または AEM Sites ページへのアダプティブフォームの追加には、最新の拡張可能なデータキャプチャコアコンポーネントを使用することをお勧めします。これらのコンポーネントは、アダプティブフォームの作成における大幅な進歩を表し、ユーザーエクスペリエンスの向上を実現します。この記事では、基盤コンポーネントを使用してアダプティブフォームを作成する古い方法について説明します。

概要 overview

Adobe Experience Manager(AEM)Forms を使用すると、複雑なトランザクションを単純で使いやすいデジタルエクスペリエンスに変えることができます。ただし、効率よく生産的な AEM Forms エコシステムを実装、ビルド、実行、維持するためには、協調的な努力が必要となります。

このドキュメントでは、フォームの管理者、作成者および開発者が AEM Forms、特にアダプティブフォームコンポーネントを使用する際に役立つガイドラインと推奨事項を説明します。フォーム開発プロジェクトの設定に始まり、AEM Forms の設定、カスタマイズ、オーサリング、最適化に至るベストプラクティスを説明します。これらのベストプラクティスをそれぞれ実行すると、AEM Forms エコシステムの全体的なパフォーマンスが向上します。

また、AEM の一般的なベストプラクティスについて、以下をお読みになることもお勧めします。

AEM Forms のセットアップおよび設定 set-up-and-configure-aem-forms

フォーム開発プロジェクトのセットアップ setting-up-forms-development-project

プロジェクトの構造を簡素化し標準化することで、開発と維持にかかる労力を大幅に削減できます。AEM プロジェクトのビルドには、オープンソースツールの Apache Maven をお勧めします。

  • Apache Maven aem-project-archetype を使用して、AEM プロジェクトの構造を作成および管理します。AEM プロジェクトに合わせて、推奨される構造およびテンプレートを作成します。さらに、ビルドを自動化し、変更制御システムを提供するので、プロジェクト管理が容易になります。

    • Maven archetype:generate コマンドを使用して、最初の構造を生成します。
    • Maven eclipse:eclipse コマンドを使用して eclipse プロジェクトファイルを生成し、プロジェクトを eclipse 内に読み込みます。

詳しくは、Apache Maven を使用して AEM プロジェクトをビルドする方法を参照してください。

  • FileVault ツール(VLT)は、CRX や AEM インスタンスをファイルシステムにマッピングするのに役立ちます。AEM プロジェクトコンテンツのチェックインやチェックアウトなどの変更制御を管理する操作を提供します。VLT ツールの使用方法を参照してください。

  • Eclipse 統合開発環境を使用している場合、AEM 開発者ツールを使用して Eclipse IDE を AEM インスタンスにシームレスに統合して、AEM アプリケーションを作成できます。詳しくは、Eclipse 用 AEM 開発者ツールを参照してください。

  • /libs フォルダーにコンテンツを格納したり、変更を加えたりしないでください。/app フォルダーにオーバーレイを作成して、デフォルトの機能を拡張または上書きします。

  • コンテンツを移動するパッケージを作成する場合は、パッケージのフィルターパスが正しく、必要なパスのみが記載されていることを確認します。

  • /libs フォルダーにコンテンツを格納したり、変更を加えたりしないでください。/app フォルダーにオーバーレイを作成して、デフォルトの機能を拡張または上書きします。

  • パッケージの正しい依存関係を定義し、事前に決定されたインストール順序/シーケンスを強制します。

  • /libs または /apps 内に参照可能なノードを作成しないでください。

オーサリング環境の計画 planning-for-authoring-environment

AEM プロジェクトのセットアップを完了したら、アダプティブフォームのテンプレートおよびコンポーネントを作成してカスタマイズするための計画を策定します。

  • アダプティブフォームテンプレートとは、アダプティブフォームの構造およびヘッダーとフッターの情報を定義する特別な AEM ページです。テンプレートのアダプティブフォーム用レイアウト、スタイル、基本構造は事前に設定されています。AEM Forms には、アダプティブフォームの作成にすぐに使用できるテンプレートおよびコンポーネントが用意されています。ただし、必要に応じてカスタムのテンプレートやコンポーネントを作成できます。アダプティブフォームで今後必要となる追加のテンプレートやコンポーネントの要件を収集しておくことをお勧めします。詳しくは、アダプティブフォームおよびコンポーネントのカスタマイズを参照してください。

  • CRX パッケージマネージャーのユーザーインターフェイスではなくフォームマネージャーユーザーインターフェイスを使用して、フォームパッケージをアップロードすることをお勧めします。CRX パッケージマネージャー経由でパッケージをアップロードすると、異常が発生する場合があるからです。

  • AEM Forms では、次のフォームモデルに基づいてアダプティブフォームを作成できます。フォームモデルは、フォームと AEM システム間のデータ交換のためのインターフェイスとして機能し、アダプティブフォーム内外のデータフローの XML ベースの構造を提供します。また、フォームモデルはスキーマおよび XFA 制約の形式で、アダプティブフォームにルールや制約を課します。

    • なし:このオプションを使用して作成されたアダプティブフォームは、フォームモデルを使用しません。このようなフォームで生成されるデータ XML は、フィールドと対応する値を持つフラットな構造です。
    • XML または JSON スキーマ:XML スキーマと JSON スキーマは、組織内のバックエンドシステムによって生成されて使用されるデータの構造を表します。アダプティブフォームにスキーマを関連付け、そのスキーマの要素を使用することにより、アダプティブフォームに動的なコンテンツを追加することができます。スキーマの要素は、アダプティブフォームを作成する際に、コンテンツブラウザーの「データモデルオブジェクト」タブで使用できます。スキーマ要素をドラッグ&ドロップしてフォームを作成できます。
    • XFA フォームテンプレート:これまで XFA ベースの HTML5 フォームに投資してきた場合、これが最適なフォームデータモデルです。XFA ベースのフォームをアダプティブフォームに直接変換できます。すべての既存の XFA ルールは、関連付けられたアダプティブフォームに保持されます。得られたアダプティブフォームは、検証、イベント、プロパティ、パターンなどの XFA 構成をサポートします。
    • フォームデータモデル:データベース、web サービス、AEM ユーザープロファイルなどのバックエンドシステムを統合し、アダプティブフォームに事前入力して、送信されたフォームデータをバックエンドシステムに再び書き込む場合は、このフォームモデルが適しています。フォームデータモデルエディターにより、アダプティブフォームの作成に使用できるフォームデータモデルで、エンティティとサービスを定義して設定できます。詳しくは、AEM Forms のデータ統合を参照してください。

データモデルを選択する際には、要件に適合するかどうかだけでなく、すでに XFA および XSD アセットに投資をしている場合、それらの既存の投資を拡張できるかどうかを考慮することが重要です。生成される XML はスキーマで定義された XPATH に従ったデータを含むため、XSD モデルを使用してフォームテンプレートを作成します。フォームデータモデルのデフォルトとして XSD モデルを使用することは、データを処理して使用するバックエンドシステムからフォームデザインが切り離され、フォームフィールドとの 1 対 1 のマッピングによりフォームのパフォーマンスが向上する点でも有用です。また、フィールドの BindRef を XML でそのデータ値の XPATH にすることもできます。

詳しくは、アダプティブフォームを作成を参照してください。

  • アダプティブフォーム間には一部の共通セクションがあります。これらを特定して、コンテンツの再利用を促進する計画を策定してください。アダプティブフォームでは、スタンドアロンのフラグメントを作成して、フォーム間で再利用できます。パネルをアダプティブフォーム内にフラグメントとして保存することもできます。フラグメントに対するすべての変更は関連付けられたフォームに反映されます。オーサリングにかかる時間を短縮し、フォーム間で一貫性を保つことに役立ちます。さらに、フラグメントを使用するとアダプティブフォームが軽量になるため、特に大規模なフォームではオーサリングエクスペリエンスが改善します。詳しくは、アダプティブフォームフラグメントを参照してください。

アダプティブフォームおよびコンポーネントのカスタマイズ customize-components

  • AEM Forms には、アダプティブフォームの作成にすぐに使用できる標準のアダプティブフォームテンプレートが用意されています。独自のテンプレートを作成することも可能です。AEM では、静的テンプレートと編集可能テンプレートを使用できます。

    • 静的テンプレートは、開発者が定義し、設定します。
    • 編集可能テンプレートは、作成者がテンプレートエディターを使用して作成します。テンプレートエディターを使用すれば、テンプレートで基本構造と初期コンテンツを定義できます。構造レイヤーに加えられた変更内容は、そのテンプレートを使用しているすべてのフォームに反映されます。初期コンテンツには、事前設定されたテーマ、事前入力サービス、送信アクションなどが含まれます。ただし、これらの設定はフォームエディターを使用したフォームに対して変更することができます。詳しくは、アダプティブフォームテンプレートを参照してください。
  • 特定のフィールドやパネルインスタンスにスタイルを設定するには、インラインスタイルを使用します。または、CSS ファイルでクラスを定義し、コンポーネントの CSS クラスプロパティでクラス名を指定できます。

  • コンポーネントにクライアントライブラリを含めて、そのコンポーネントを使用するアダプティブフォームやフラグメントに一貫したスタイルを適用します。詳しくは、アダプティブフォームのページコンポーネントを作成を参照してください。

  • アダプティブフォームコンテナのプロパティで、CSS ファイルパスフィールド内のクライアントライブラリへのパスを指定することで、選択したアダプティブフォームに、クライアントライブラリで定義したスタイルを適用します。

  • スタイルのクライアントライブラリを作成するには、テーマエディターのベース clientlib またはフォームコンテナプロパティで、カスタム CSS ファイルを設定します。

  • アダプティブフォームには、レスポンシブ、タブ付き、アコーディオン、ウィザードなどのパネルレイアウトが用意されており、フォームコンポーネントをパネルにレイアウトする方法を制御できます。カスタムパネルレイアウトを作成して、フォーム作成者が使用できるようにすることができます。詳しくは、アダプティブフォームのカスタムレイアウトコンポーネントの作成を参照してください。

  • フィールドやパネルレイアウトなど、アダプティブフォームの特定のコンポーネントをカスタマイズすることもできます。

    • AEM のオーバーレイ機能を使用してコンポーネントのコピーを変更します。デフォルトのコンポーネントを変更することはお勧めしません。
    • /libs のすぐに使用できるアダプティブフォームコンポーネントのレイアウトをカスタマイズするには、デフォルトレイアウトに加えて、カスタマイズレイアウトコンポーネントを作成します。
    • カスタムのウィジェットやアピアランスを作成することにより、カスタムのインタラクティブ機能を導入します。デフォルトのコンポーネントを変更することはお勧めしません。詳しくは、アピアランスのフレームワークを参照してください。
  • PII データの取り扱いに関するレコメンデーションについては、個人を特定できる情報の取り扱いを参照してください。

フォームテンプレートの作成

設定ブラウザー ​で有効になっているフォームテンプレートを使用して、アダプティブ フォームを作成できます。フォームテンプレートを有効にするには、アダプティブフォームテンプレートの作成を参照してください。

フォームテンプレートは、別のオーサーマシンで作成されたアダプティブフォームパッケージからアップロードすることもできます。 aemforms-references-* パッケージをインストールすると、フォームテンプレートが利用可能になります。推奨されるベストプラクティスの一部を次に示します。

  • nosamplecontent 実行モードは、オーサーノードに対してのみ推奨され、パブリッシュノードに対しては推奨されません。
  • アダプティブフォーム、テーマ、テンプレート、クラウド設定などのアセットのオーサリングはオーサーノード上でのみ実行でき、設定済みのパブリッシュノードで公開できます。
    詳しくは、フォームとドキュメントの公開と非公開を参照してください。
  • ドキュメントサービスの運用をサポートするためには、オーサリングとパブリッシュに Forms アドオンパッケージが必要であることから、これを依存関係と見なすことができます。
    Forms 関連のサンプルテンプレート、テーマおよび DOR パッケージのみ必要な場合は、aemforms-references-* パッケージからダウンロードすることができます。

詳しくは、アダプティブフォームのオーサリングの概要のベストプラクティスの節を参照してください。

アダプティブフォームのオーサリング author-adaptive-forms

タッチ操作向け UI をオーサリングに使用 using-touch-optimized-ui-for-authoring

  • フォーム階層の下位にあるフィールドにすばやくアクセスするには、サイドバーのオブジェクトブラウザーを使用します。検索ボックスを使用してフォームまたはオブジェクトツリー内のオブジェクトを検索し、オブジェクト間を移動することができます。

  • サイドバーのコンポーネントブラウザーでコンポーネントのプロパティを表示して編集するには、コンポーネントを選択して cmppr-1 をクリックします。コンポーネントをダブルクリックして、そのプロパティをプロパティブラウザーに表示することもできます。

  • フォームに対する操作をすばやく実行するには、キーボードショートカットを使用します。AEM Forms のキーボードショートカットを参照してください。

  • アダプティブフォームのコンポーネントは、アダプティブフォームのページでのみ使用することをお勧めします。これらのコンポーネントは、その親階層に対して依存関係を持っています。このため、AEM ページではこれらのコンポーネントを使用しないでください。

また、アダプティブフォームのオーサリングの概要に記載されているコンポーネントの説明とベストプラクティスを参照してください。

アダプティブフォームにおけるルールの使用 using-rules-in-adaptive-forms

AEM Forms が提供するルールエディターを使用すると、アダプティブフォームコンポーネントに動的な動作を追加するルールを作成できます。これらのルールを使用すると、条件を評価し、フィールドの表示または非表示、値の計算、ドロップダウンリストの動的な変更など、コンポーネントへのアクションをトリガーできます。

ルールエディターでは、ルールを記述するためのビジュアルエディターとコードエディターを使用できます。コードエディターモードを使用してルールを記述する際は、次の点を考慮してください。

  • ルールの記述時には、フォームフィールドおよびコンポーネントには意味のある一意の名前を使用し、名前の競合を回避します。

  • ルールの式で、コンポーネント自身を参照するには、コンポーネントの this 演算子を使用します。これにより、コンポーネント名が変更されても、ルールは有効なままになります。例えば、field1.valueCommit script: this.value > 10 のようになります。

  • 他のフォームコンポーネントを参照する場合には、コンポーネント名を使用します。フィールドまたはコンポーネントの値を取得するには、value プロパティを使用します。例えば、field1.value のようになります。

  • 競合を回避するために、コンポーネントは固有の相対階層で参照します。例えば、parentName.fieldName のようになります。

  • 複雑なルールやよく使用するルールを扱う場合は、指定できアダプティブフォーム間で再利用できる別個のクライアントライブラリの機能としてビジネスロジックを作成することを検討します。クライアントライブラリは独立のライブラリとし、jQuery および Underscore.js 以外の外部依存はなくす必要があります。クライアントライブラリは、送信されたフォームデータのサーバーサイドの再検証を実行するために使用することもできます。

  • アダプティブフォームが提供する一連の API を使用して、アダプティブフォームと通信したり、アダプティブフォーム上でアクションを実行したりできます。主要な API には次の項目が挙げられます。詳しくは、アダプティブフォームの JavaScript ライブラリ API リファレンスを参照してください。

    • guideBridge.reset():フォームをリセットします。

    • guideBridge.submit():フォームを送信します。

    • guideBridge.setFocus(somExp, focusOption, runCompletionExp):フィールドにフォーカスを設定します。

    • guideBridge.validate(errorList, somExpression, focus):フォームを検証します。

    • guideBridge.getDataXML(options):フォームデータを XML として取得します。

    • guideBridge.resolveNode(somExpression):フォームオブジェクトを取得します。

    • guideBridge.setProperty(somList, propertyName, valueList):フォームオブジェクトのプロパティを設定します。

    • 上記に加えて、以下のフィールドプロパティを使用できます。

      • field.value でフィールドの値を変更します。
      • field.enabled でフィールドを有効/無効にします。
      • field.visible でフィールドの表示/非表示を変更します。
  • アダプティブフォームの作成者は、フォーム内のビジネスロジックをビルドするために、場合によっては JavaScript コードを作成する必要があります。JavaScript は強力で効果的ですが、セキュリティ上の期待事項を損なう可能性があります。このため、フォーム作成者が信頼できる人物であることや、フォームを本番稼動させる前に JavaScript コードをレビューし承認するプロセスがあることを確認する必要があります。管理者は、各ユーザーの役割や職務に基づいて、ユーザーグループのルールエディターへのアクセスを制限できます。選択したユーザーグループにルールエディターへのアクセスを許可を参照してください。

  • ルール内で数式を使用して、アダプティブフォームを動的にすることができます。すべての式は、有効な JavaScript™ の式で、アダプティブフォームのスクリプトモデル API を使用しています。これらの式は、特定のタイプの値を返します。数式およびベストプラクティスについて詳しくは、アダプティブフォームの式を参照してください。

  • アドビでは、ルールエディターでルールを作成する際に、非同期操作よりも JavaScript 同期操作を使用することをお勧めしています。非同期操作を使用しないことを強くお勧めします。ただし、非同期操作が避けられない状況である場合は、JavaScript のクロージャ関数を実装する必要があります。これにより、潜在的な競合状態に対して効果的に保護し、ルールの実装が最適なパフォーマンスを提供し、全体を通して安定性を維持できるようになります。

    例えば、外部 API からデータを取得し、そのデータに基づいてルールを適用する必要があるとします。クロージャを使用して非同期 API 呼び出しを処理し、データを取得した後でルールが適用されるようにします。次にサンプルコードを示します。

    code language-javascript
         function fetchDataFromAPI(apiEndpoint, callback) {
          // Simulate asynchronous API call with setTimeout
          setTimeout(() => {
            // Assuming the API call is successful, we receive some data
            const data = {
              someValue: 42,
            };
            // Invoke the callback with the fetched data
            callback(data);
          }, 2000); // Simulate a 2-second delay for the API call
        }
        // Rule implementation using Closure
        function ruleImplementation(apiEndpoint) {
          // Using a closure to handle the asynchronous API call and rule application
          // say you have set this value in street field inside address panel
          var streetField = address.street;
          fetchDataFromAPI(apiEndpoint, (data) => {
            streetField.value = data.someValue;
          });
        }
        // Example usage of the rule implementation
        const apiEndpoint = "https://example-api.com/data";
        ruleImplementation(apiEndpoint);
    

    この例では、fetchDataFromAPI で、setTimeout を使用して非同期 API 呼び出しをシミュレートします。データが取得されると、指定されたコールバック関数が呼び出されます。これは、後続のルールアプリケーションを処理するためのクロージャです。ruleImplementation 関数には、ルールロジックが含まれます。

テーマの操作 working-with-themes

アダプティブフォームのテーマを使用して、一貫した外観とスタイル設定をフォーム全体に適用できる再利用可能なスタイルを作成できます。テーマを使用してフォームコンポーネントやパネルのスタイル設定を定義します。テーマに関するベストプラクティスの一部を以下に示します。

  • テキストスタイル、背景および画像の簡単なアプリケーション用にアセットライブラリを使用します。スタイルをアセットライブラリに追加すると、他のテーマに使用できて、フォームエディターのスタイルモードで利用できます。
  • ページレベルのセレクターを使用して、フォントやページ背景などのグローバル設定に適用します。
  • クライアントライブラリを使用して、既存のスタイル設定または詳細スタイル設定をテーマに読み込みます。
  • フォームスタイルレイヤー内の特定のフィールド、パネル、ボタンにスタイル設定を上書きできます。
  • テーマがスタイル設定の要件を満たさない場合は、事前定義済みのクラス(guideFieldNode、guideFieldLabel、guideFieldWidget、guidePanelNode など)を使用して複数のフォームに共通のスタイルを適用できます。

詳しくは、テーマを参照してください。

大規模フォームおよび複雑なフォームのパフォーマンスの最適化 optimizing-performance-of-large-and-complex-forms

通常、パフォーマンスに関する問題が発生するのは、フォーム作成者およびエンドユーザーが、オーサリングモードで、または実行時に大規模なフォームを読み込む場合です。フォーム内のオブジェクト(フィールドおよびパネル)が増えるにしたがって、オーサリングとランタイムのエクスペリエンスが低下し始めます。また、複数の作成者による共同作業や、フォームを同時にオーサリングする際の妨げにもなります。

大規模フォームのパフォーマンスの問題を解決するには、以下のベストプラクティスを検討してください。

  • 可能な場合には、XFA をアダプティブフォームに変換する場合でも、XSD フォームデータモデルを使用してアダプティブフォームを作成することをお勧めします。

  • アダプティブフォームには、ユーザーからの情報を取得するフィールドとパネルのみを含めます。静的コンテンツを最小限に抑えるか、URL を使用してそれらを別のウィンドウで開くことを検討します。

  • すべてのフォームは特定の目的のためにデザインされますが、ほとんどのフォームにはいくつかの共通するセグメントがあります。例えば、個人の詳細、住所、雇用の詳細などです。フォームの共通の要素およびセクションに対してアダプティブフォームフラグメントを作成し、それらを複数のフォーム間で使用します。パネルをフラグメントとして既存のフォーム内に保存することもできます。フラグメント内の変更はすべて、関連付けられたアダプティブフォームに反映されます。これにより、複数の作成者が同時に、1 つのフォームを構成する別のフラグメントの作業を行えるため、オーサリングの共同作業が促進されます。

    • アダプティブフォームと同様に、フラグメント固有のすべてのスタイル設定およびカスタムスクリプトは、フラグメントコンテナダイアログを使用して、クライアントライブラリで定義することをお勧めします。また、外部のオブジェクトに依存しない自己完結型のフラグメントを作成するようにしてください。
    • フラグメントをまたぐスクリプトは使用しないでください。フラグメントの外部に参照する必要があるオブジェクトが存在する場合、そのオブジェクトが親フォームの一部となるようにします。それでもオブジェクトが別のフラグメントに存在しなくてはならない場合、スクリプト中でその名前を参照します。
  • 自動保存機能のある「保存して再開」を使用して、アダプティブフォームを定期的に保存し、ユーザーが後で再度訪問してフォームを完了できるようにします。

  • フラグメントに遅延読み込みを設定します。遅延読み込みとマークされたフラグメントは、実行時に必要な場合にのみレンダリングされます。大規模なフォームの読み込み時間が大幅に減少します。これは、繰り返し可能なパネルを使用したフラグメントでもサポートされます。詳しくは、遅延読み込みを設定を参照してください。

    • レスポンシブグリッドレイアウトまたは最初のパネルには、フラグメントに遅延読み込みを設定しないでください。
    • ファイル添付および利用条件コンポーネントは、遅延読み込みフラグメントではサポートされません。
    • 遅延読み込みパネルの値がフォームの他の部分で使用されている場合、その値を「値をグローバルに使用」としてマークし、パネルがアンロードされたときにその値を使用できるようにします。
    • 条件に基づいて表示または非表示する必要があるフラグメントに対して、表示ルールを記述することを検討します。
  • Apache Sling Main Servlet の​ リクエストあたりの呼び出し数 ​の値をかなり大きな値に設定します。これにより、Forms サーバーが追加の呼び出しを許可することができます。 この設定では、デフォルト値の 1500 が表示されます。 この値(1500 の呼び出し)は、Sites や Assets などの他の Experience Manager コンポーネントに対して使用されます。 アダプティブフォームのデフォルトの値セットは 20000 です。 ログで too many calls エラーが発生した場合、またはフォームのレンダリングに失敗した場合は、値を大きくして問題を解決してください。呼び出し数が 20000 を超える場合は、フォームが複雑であるという意味で、ブラウザーでフォームをレンダリングするのに時間がかかる場合があります。これは、フォームが初めて読み込まれたときにのみ発生し、フォームがキャッシュされた後は、パフォーマンスに大きな影響を与えません。

アダプティブフォームの事前入力 prefilling-adaptive-forms

バックエンドから取得したデータをアダプティブフォームフィールドに事前に入力すると、ユーザーが素早くフォームに入力し、入力ミスを回避できるようになります。

  • AEM Forms の事前入力サービスは、事前定義されたデータ XML ファイルからデータを読み取り、アダプティブフォームのフィールドに事前入力 XML ファイルの内容を事前入力します。

  • 事前入力データ XML は、アダプティブフォームに関連付けられたフォームモデルのスキーマに準拠している必要があります。

  • 事前入力 XML には「afBoundedData」および「afUnBoundedData」セクションを含めて、アダプティブフォームの連結されたフィールドと連結されていないフィールドのどちらにも事前入力するようにします。

  • フォームデータモデルに基づいたアダプティブフォームの場合、AEM Forms にはすぐに使用できるフォームデータモデルの事前入力サービスが用意されています。この事前入力サービスは、アダプティブフォーム内のデータモデルオブジェクトのデータソースに関するクエリを実行し、フォームのレンダリング時にフィールド値を事前入力します。

  • ファイル、crx、サービスまたは http プロトコルを使用して、アダプティブフォームに事前入力することもできます。

  • AEM Forms は、OSGi サービスとしてプラグインしてアダプティブフォームに事前入力できるカスタム事前入力サービスをサポートしています。

詳しくは、アダプティブフォームフィールドの事前入力を参照してください。

アダプティブフォームの署名と送信 signing-and-submitting-adaptive-forms

アダプティブフォームでは、ユーザー指定のデータを処理するために、送信アクションが必要です。送信アクションとは、アダプティブフォームを使って送信されるデータに対して実行されるタスクを決定するものです。

  • アダプティブフォームには、初期設定済みの複数の送信アクションがあります。詳しくは、送信アクションの設定を参照してください。
  • デフォルトの送信アクションが実際のユースケースに適していない場合は、カスタム送信アクションを作成できます。詳しくは、アダプティブフォーム向けのカスタム送信アクションの作成を参照してください。
  • サーバーサイドの検証を含めて、無効なデータ送信を防ぎます。

アダプティブフォームで Adobe Sign の複数署名機能を使用できます。アダプティブフォームで Adobe Sign を設定する際は、以下の点を考慮してください。詳しくは、アダプティブフォームでの Adobe Sign の使用を参照してください。

  • Adobe Sign が有効になっているアダプティブフォームは、すべての署名者がフォームに署名するまで送信されません。すべての署名者によりフォームが署名されるまで、フォームは「保留中の署名」状態で表示されます。
  • フォーム内署名機能を設定することや、送信時に署名者を署名ページにリダイレクトすることができます。
  • 適宜、順次署名または並列署名を設定します。

レコードのドキュメントの生成 generating-document-of-record

レコードのドキュメント(DoR)は、印刷、署名、またはアーカイブが可能な、アダプティブフォームのフラット化された PDF バージョンです。

  • アダプティブフォームが基にしているフォームデータモデルに応じて、DoR 用のテンプレートを次のように設定できます。

    • XFA フォームテンプレート:関連付けられた XDP ファイルを DoR テンプレートとして使用します。
    • XSD スキーマ:アダプティブフォームで使用されているのと同じ XML スキーマを使用する、関連付けられた XFA テンプレートを使用します。
    • なし:自動生成された DoR を使用します。
  • アダプティブフォームエディターの「レコードのドキュメント」タブから、ヘッダー、フッター、画像、色、フォントなどを直接設定します。

  • DoRService を使用して、DoR をプログラムにより生成します。

  • DoR から非表示フィールドを除外します。

  • afAcceptLang リクエストパラメーターを使用して、別のロケールで DoR を表示します。

アダプティブフォームのデバッグとテスト debugging-and-testing-adaptive-forms

AEM Chrome プラグインは、Google Chrome 用のブラウザー拡張機能で、アダプティブフォームのデバッグ用のツールを提供します。フォームの作成者および開発者は、これらのツールを使用して次のことを実行できます。

  • フォームのレンダリングのボトルネックを特定し、パフォーマンスを最適化する
  • フォーム内のキーワードと bindRef エラーをデバッグする
  • ログを有効にして設定する
  • フォーム内のルールとスクリプトをデバッグする
  • guideBridge API の探索と学習を行う

詳しくは、AEM Chrome プラグイン - アダプティブフォームを参照してください。

AEM サーバー上でのアダプティブフォームの検証 validating-adaptive-forms-on-aem-server

クライアント側で検証をすり抜ける試みを阻止するためにも、データ送信の侵害やビジネスルール違反の可能性を阻止するためにも、サーバーサイドの検証が必要です。サーバーサイドの検証は、必要なクライアントライブラリを読み込むことにより、サーバー上で実行されます。

  • アダプティブフォーム内の式を検証するための関数をクライアントライブラリに含め、アダプティブフォームのコンテナダイアログでクライアントライブラリを指定します。詳しくは、サーバーサイドの再検証を参照してください。
  • サーバーサイド検証により、フォームモデルが検証されます。検証のために別個のクライアントライブラリを作成し、1 つのクライアントライブラリに HTML のスタイルや DOM 操作を混在させないことをお勧めします。

アダプティブフォームのローカライズ localizing-adaptive-forms

AEM では、アダプティブフォームのローカライズに使用できる翻訳ワークフローが提供されています。詳しくは、AEM 翻訳ワークフローを使用したアダプティブフォームのローカライズを参照してください。

アダプティブフォームをローカライズする際のベストプラクティスの一部を次に示します。

  • 複数のフォームに共通する要素に対してアダプティブフォームフラグメントを使用し、フラグメントをローカライズします。これにより、フラグメントを 1 回ローカライズするだけで、ローカライズされたフラグメントが使用されるすべてのフォームに反映されます。

  • 新しいコンポーネントの追加や、ローカライズされたフォームへのスクリプトの適用などの変更は、自動的にはローカライズされません。したがって、ローカライズを何度も行わなければならない状況を避けるには、フォームをローカライズする前に完成させる必要があります。

  • ブラウザーのロケールを上書きし、指定したロケールでフォームをレンダリングするには、afAcceptLang 要求パラメーターを使用します。例えば、次の URL を使用すると、ブラウザー設定で指定されたロケールに関係なく、日本語ロケールでのフォームのレンダリングが強制されます。

    https://'[server]:[port]'/<contextPath>/<formFolder>/<formName>.html?wcmmode=disabled&afAcceptLang=ja

  • 現在、AEM Forms がサポートしているアダプティブフォームコンテンツのロケールは、英語(en)、スペイン語(es)、フランス語(fr)、イタリア語(it)、ドイツ語(de)、日本語(ja)、ブラジルポルトガル語(pt-BR)、中国語(zh-CN)、台湾中国語(zh-TW)、韓国語(ko-KR)です。ただし、実行時にアダプティブフォームに対する新しいロケールのサポートを追加できます。詳しくは、アダプティブフォームのローカライズに対する新しいロケールのサポートを参照してください。

フォームプロジェクトを実稼動で使用するための準備 prepare-forms-project-for-production

フォーム処理サーバーの追加 adding-forms-processing-server

ファイアウォール内側の保護された領域に、追加の AEM Forms サーバーを構成することもできます。このインスタンスは次の目的に使用できます。

  • バッチ処理:反復的なジョブや、負荷の大きいバッチとしてスケジュールされるジョブ。例えば、提示文書の印刷、連絡文書の作成、ドキュメントサービス(PDF Generator、Output、Assembler など)の使用などです。
  • PII データの保存:PII データを処理サーバーに保存します。PII データの保存用にカスタムのストレージプロバイダーを使用している場合には必要ありません。

別の環境へのプロジェクトの移動 moving-project-to-another-environment

AEM プロジェクトをある環境から別の環境に移動する必要がある場合がよくあります。移動時の主な留意事項は、次のとおりです。

  • 既存のクライアントライブラリ、カスタムコード、設定のバックアップを作成します。
  • 製品パッケージおよびパッチを、手動で、新しい環境で指定された順序でデプロイします。
  • プロジェクト固有のコードのパッケージとバンドルを、手動で、新しい AEM サーバー上の別個のパッケージやバンドルとしてデプロイします。
  • JEE 上の AEM Forms のみ)LCA および DSC を手動で Forms ワークフローサーバー上にデプロイします。
  • 書き出し - 読み込み機能を使用して、アセットを新しい環境に移動します。複製エージェントを構成し、アセットを公開することもできます。
  • アップグレードする際は、廃止されるすべての API と機能を新しい API と機能に置き換えてください。

AEM の設定 configuring-aem

全体的なパフォーマンスを改善するための AEM 設定のベストプラクティスを、次にいくつか示します。

ドラフトおよび送信済みフォームのデータを保存する外部ストレージの設定 external-storage

実稼動環境では、送信されたフォームデータを AEM リポジトリに保存しないことをお勧めします。「フォームポータル保存」、「コンテンツ保存」および「PDF の保存」送信アクションのデフォルト実装では、フォームデータが AEM リポジトリに保存されます。これらの送信アクションは、デモを目的としたものです。また、「保存して再開」機能や「自動保存」機能でも、デフォルトでポータルストレージが使用されます。このため、次のレコメンデーションを検討してください。

  • ドラフトデータの保存:アダプティブフォームの「ドラフト」機能を使用している場合は、カスタムサービスプロバイダーインターフェイス(SPI)を実装して、データベースなどのより安全なストレージにドラフトデータを保存してください。詳しくは、「ドラフト&送信コンポーネントとデータベースの統合」を参照してください。

  • 送信データの保存:「フォームポータル送信保存」を使用している場合は、カスタム SPI を実装してデータベースに送信データを保存してください。統合例については、ドラフト&送信コンポーネントとデータベースの統合の例 を参照してください。

    安全なストレージにフォームデータと添付ファイルを保存するカスタム送信アクションを作成することもできます。詳しくは、アダプティブフォーム向けカスタム送信アクションの作成 を参照してください。

  • ドラフト ID の長さ:アダプティブフォームをドラフトとして保存すると、そのドラフトを一意に識別するためのドラフト ID が生成されます。ドラフト ID フィールドの長さの最小値は 26 文字です。アドビでは、ドラフト ID の長さを 26 文字以上に設定することをお勧めします。

個人を特定できる情報の処理 handling-personally-identifiable-information

組織にとって大きな課題の 1 つは、個人を特定できる情報(PII)の処理方法です。このようなデータを取り扱うためのベストプラクティスのいくつかを、以下に紹介します。

  • データベースなどの安全な外部ストレージを使用してドラフトおよび送信済みフォームのデータを保存します。ドラフトおよび送信済みフォームのデータを格納する外部ストレージの設定を参照してください。
  • 自動保存を有効にする前に、利用条件フォームコンポーネントを使用してユーザーから明示的な同意を得ます。この場合、ユーザーが利用条件コンポーネントの条件に同意した場合にのみ自動保存を有効にします。

アダプティブフォームのルールエディター、コードエディターまたはカスタムクライアントライブラリの選択 RuleEditor-CodeEditor-ClientLibs

ルールエディター rule-editor

AEM Forms ルールエディターは、ルールを作成および管理するための視覚的なインターフェイスを備えているので、大がかりなコーディングの必要性が軽減されます。この機能は、高度なプログラミングスキルを持たないが、フォーム内のビジネスルールを定義および管理する必要があるビジネスユーザーやフォームデザイナーに特に役に立ちます。ここでは、ルールエディターで以下を行えるいくつかのユースケースについて説明します。

  • 大がかりなプログラミングを必要とせずにフォームのビジネスルールを定義する。
  • フォーム内に条件ロジックを実装する。これには、フォーム要素の表示/非表示の切り替え、特定の条件に基づくフィールド値の変更、フォームの動作の動的な変更などが含まれます。
  • フォーム送信時にデータ検証ルールを強制的に適用する。ルールエディターを使用して、検証条件を定義できます。
  • フォームを外部のデータソース(FDM)またはサービスと統合する。ルールエディターを使用して、フォームの操作中にデータを取得、表示または操作するためのルールを定義できます。
  • ユーザーの操作に応じた動的でインタラクティブなフォームを作成する。ルールエディターを使用すると、フォーム要素の動作をリアルタイムで制御するルールを定義できます。

ルールエディターは、AEM Forms 基盤コンポーネントとコアコンポーネントの両方で使用できます。

コードエディター code-editor

コードエディターは、Adobe Experience Manager(AEM)Forms 内のツールで、これを使用すると、より複雑で高度な機能を実現するカスタムスクリプトやコードをフォームに作成できます。ここでは、以下のユースケースについて説明します。

  • AEM Forms ルールエディターの機能を超えるカスタムのクライアントサイドロジックまたは動作を実装する必要がある場合。コードエディターを使用すると、複雑なやり取り、計算または検証を処理する JavaScript コードを作成できます。
  • フォームでサーバーサイドの処理または外部システムとの統合が必要な場合。コードエディターを使用して、カスタムのサーバーサイドスクリプトを作成できます。コードエディターの guideBridge API にアクセスして、フォームのイベントやオブジェクトに複雑なロジックを実装できます。
  • AEM Forms コンポーネントの標準的な機能を超える高度にカスタマイズされたユーザーインターフェイスが必要な場合。コードエディターを使用すると、カスタムのスタイルや動作を実装できるほか、カスタムフォームコンポーネントの作成さえ可能です。
  • フォームが非同期データ読み込みなどの非同期操作を伴う場合。コードエディターを使用して、カスタムの非同期 JavaScript コードでこれらの操作を管理できます。

コードエディターを使用する場合は、JavaScript と AEM Forms のアーキテクチャを十分に理解しておく必要があることに注意してください。さらに、カスタムコードを実装する場合は、ベストプラクティスに従い、セキュリティガイドラインを順守し、コードを十分にテストして実稼動環境で問題が発生しないようにしてください。コードエディターを使用して、FDM のコールバックを実装できます。

コードエディターは、AEM Forms 基盤コンポーネントでのみ使用できます。アダプティブフォームのコアコンポーネントの場合は、カスタム関数を使用して独自のフォームルールを作成できます(次の節を参照)。

カスタム関数 custom-client-libs

AEM Forms(Adobe Experience Manager Forms)でカスタムクライアントライブラリを使用すると、フォームの機能、スタイル設定または動作を強化するのに様々なシナリオで役に立ちます。カスタムクライアントライブラリを使用するのが妥当な状況は次のとおりです。

  • AEM Forms に用意されているデフォルトのスタイル設定オプションの機能を超える独自のデザインまたはブランディングをフォームに実装する必要がある場合。この場合は、ルックアンドフィールを制御するカスタムクライアントライブラリを作成できます。
  • カスタムのクライアントサイドロジック、複数のフォームにわたるメソッドの再利用性、標準の AEM Forms 機能では実現できない動作が必要な場合。これには、ダイナミックフォームの操作、カスタム検証、サードパーティライブラリとの統合などが含まれます。
  • クライアントサイドのリソースを最適化および縮小して、フォームのパフォーマンスを向上させる場合。カスタムクライアントライブラリを使用して、JavaScript ファイルと CSS ファイルをバンドルおよび圧縮することで、ページ全体の読み込み時間を短縮できます。
  • デフォルトの AEM Forms 設定に含まれていない追加の JavaScript ライブラリまたはフレームワークを統合する必要がある場合。これは、拡張日付選択機能、グラフ、その他のインタラクティブコンポーネントなどの機能に必要な場合があります。

カスタムクライアントライブラリを使用することに決める前に、メンテナンスのオーバーヘッド、今後行われる更新との競合の可能性、ベストプラクティスの順守を検討することが大切です。アップグレード時や他の開発者との共同作業時に問題が発生しないように、カスタマイズの詳細な文書化とテストを実施します。

NOTE
カスタム関数は、AEM Forms 基盤コンポーネントとコアコンポーネントの両方で使用できます。

カスタム関数の利点:

カスタム関数 ​は、コンテンツとコードを明確に分離することでコラボレーションを強化しワークフローを効率化するので、コードエディター ​と比べて著しく優れています。次の利点があるので、カスタム関数の使用をお勧めします。

  • Git などのバージョン管理をシームレスに使用:

    • コンテンツからコードを分離することで、コンテンツ管理中の Git 競合が大幅に減少し、適切に整理されたリポジトリが促進されます。
    • カスタム関数は、複数の投稿者が同時に作業するプロジェクトに価値があります。
  • 技術的な利点:

    • カスタム関数は、モジュール性とカプセル化を提供します。
    • モジュールは、独立して開発、テスト、保守できます。
    • コードの再利用性と保守性を向上させます。
  • 効率的な開発プロセス:

    • モジュール性により、開発者は特定の機能に専念できます。
    • コードベース全体の複雑さを軽減して開発者の負担を軽減し、より効率的な開発プロセスを実現します。
recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2