アダプティブフォームの操作のベストプラクティス

概要

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

ここでは、フォーム管理者、フォーム作成者、開発者たちが AEM Forms、特にアダプティブフォームコンポーネントを扱う際に知っておくべきガイドラインや推奨事項を紹介します。フォーム開発プロジェクトのセットアップから、AEM Forms の設定、カスタマイズ、オーサリング、最適化まで、ベストプラクティスを説明します。これらのベストプラクティスをそれぞれ実行すると、AEM Forms の全体的なパフォーマンスが向上します。

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

AEM Forms のセットアップおよび設定

フォーム開発プロジェクトのセットアップ

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

  • AEM プロジェクトの構造を作成し管理するために、Apache Maven aem-project-archetype を使用できます。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 開発者ツール」を参照してください。

オーサリング環境の計画

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

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

  • 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 にすることもできます。

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

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

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

  • AEM Forms には、アダプティブフォームの作成に使用できる初期設定済みのアダプティブフォームテンプレートが用意されています。独自のテンプレートを作成することも可能です。AEM では、静的テンプレートと編集可能なテンプレートを提供しています。

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

  • 特定のフィールドまたはパネルインスタンスのスタイル設定には、インラインスタイル設定を使用します。 または、CSS ファイルでクラスを定義し、そのクラス名をコンポーネントの CSS Class プロパティに指定します。

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

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

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

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

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

    • AEM のオーバーレイ機能を使用してコンポーネントのコピーを変更します。デフォルトコンポーネントは変更しないことをお勧めします。
    • /libs のすぐに使用できるアダプティブフォームコンポーネントのレイアウトをカスタマイズするには、デフォルトレイアウトに加えて、カスタマイズレイアウトコンポーネントを作成します。
    • カスタムウィジェットまたはカスタム外観を作成することで、カスタムのインタラクティブ機能を導入できます。デフォルトコンポーネントは変更しないことをお勧めします。詳しくは、「外観フレームワーク」を参照してください。

  • PIIデータの処理に関する推奨事項については、個人を特定できる情報の処理を参照してください。

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

タッチに最適化されたオーサリング用 UI の使用

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

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

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

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

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

アダプティブフォームにおけるルールの使用

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 フィールドの値を変更します。
      • f ield.enabledをクリックして、フィールドを有効/無効にします。
      • field.visible フィールドの表示／非表示を変更します。

  • アダプティブフォームの作成者は、フォーム内のビジネスロジックを構築するために、場合によっては JavaScript コードを作成する必要があります。JavaScript は強力で効果的ですが、セキュリティ上の期待に対して妥協が生じる可能性があります。このため、フォーム作成者が信頼できる人物であることや、フォームを本番稼動させる前に JavaScript コードを見直して承認するプロセスがあることを確認する必要があります。管理者は、各ユーザーの役割や職務に基づいて、ユーザーグループのルールエディターへのアクセスを制限することができます。選択したユーザーグループにルールエディターへのアクセスを許可するを参照してください。

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

テンプレートの操作

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

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

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

大規模フォームおよび複雑なフォームのパフォーマンスの最適化

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

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

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

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

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

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

  • 自動保存機能のある「保存して再開」を使用して、アダプティブフォームを定期的に保存し、ユーザーが後で再度アクセスしてフォームを完了できるようにします。

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

    • レスポンシブグリッドレイアウトまたは最初のパネルには、フラグメントに遅延読み込みを設定しないでください。
    • ファイル添付および利用条件コンポーネントは、遅延読み込みフラグメントではサポートされません。
    • 遅延読み込みパネルにある値は、その値がフォームの別の部分で使用されている場合、「グローバルに値を使用」とマークします。これにより、パネルが読み込まれていない場合に、この値を使用できるようになります。
    • フラグメントの表示ルールは、条件に基づいて表示または非表示するべきフラグメントに対して作成するようにしてください。

アダプティブフォームに事前にデータを取り込む

バックエンドから取得したデータを使用してアダプティブフォームフィールドに事前にデータを取り込んで、ユーザーの入力ミスを防いですばやくフォームに入力できるようにします。

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

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

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

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

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

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

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

アダプティブフォームの署名と送信

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

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

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

  • Adobe Sign が有効になっているアダプティブフォームは、すべての署名者がフォームに署名するまで送信されないことに注意してください。Formsは、すべての署名者がフォームに署名するまで、保留中の署名状態で表示されます。
  • フォーム内署名機能を設定する、または送信時に署名者を署名ページにリダイレクトすることができます。
  • 連続署名または並列署名のどちらか適している方を設定します。

レコードのドキュメントの生成

レコードのドキュメント（DoR）はアダプティブフォームのフラットな PDF 版で、印刷、署名、アーカイブが行えます。

  • アダプティブフォームが基づくフォームデータモデルによって、DoR のテンプレートを以下のように設定できます

    • XFA フォームテンプレート：関連付けられた XDP ファイルを DoR テンプレートとして使用します。
    • XSD スキーマ：アダプティブフォームが使用するのと同じ XML スキーマを使用する、関連付けられた XFA テンプレートを使用します。
    • なし：自動生成 DoR を使用します。

  • アダプティブフォームエディターの「レコードのドキュメント」タブで、ヘッダー、フッター、画像、色、フォントなどを設定します。

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

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

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

アダプティブフォームのデバッグとテスト

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

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

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

Calvin SDK は、アダプティブフォームをテストするためのアダプティブフォーム開発者用のユーティリティ API です。Calvin SDKは、Hobbes.jsテストフレームワーク上に構築されています。 このフレームワークを使用して、次のテストを実行できます。

  • アダプティブフォームのレンディションエクスペリエンス
  • アダプティブフォームの事前入力機能
  • アダプティブフォームの送信機能
  • 式のルール
  • 検証
  • 遅延読み込み

詳しくは、「アダプティブフォームのテスト自動化」を参照してください。

AEM サーバー上でのアダプティブフォームの検証

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

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

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

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

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

  • アダプティブフォームフラグメントをフォーム間で共通の要素に使用し、フラグメントをローカライズする。 フラグメントを一度ローカライズすると、ローカライズしたフラグメントが使用されているすべてのフォームにその内容が反映されます。

  • 新しいコンポーネントの追加やローカライズしたフォームへのスクリプトの適用などの変更を行った場合、その変更内容は自動的にローカライズされません。したがって、複数のローカライゼーションサイクルを避けるために、フォームをローカライズする前に最終決定する必要があります。

  • ブラウザーのロケールを上書きし、指定したロケールでフォームをレンダリングするには、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)ロケールのアダプティブフォームコンテンツのローカライゼーションをサポートしています。 ただし、実行時にアダプティブフォームに対する新しいロケールのサポートを追加できます。詳しくは、「アダプティブフォームのローカライズに対する新しいロケールのサポート」を参照してください。

フォームプロジェクトを実稼働で使用するための準備

フォーム処理サーバーの追加

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

  • バッチ処理:繰り返されるジョブや、負荷の高いバッチでスケジュールされるジョブ。例えば、印刷明細、通信の生成や、PDF Generator、Output、アセンブラなどのドキュメントサービスの使用が例として挙げられます。
  • PII データの保存： PII データを処理サーバーに保存します。PII データの保存用にカスタムのストレージプロバイダーを使用している場合には必要ありません。

プロジェクトの別の環境への移動

AEM プロジェクトを別の環境に移動させたいという場合は、よくあります。移動時の主な留意事項は、次のとおりです。

  • 既存のクライアントライブラリ、カスタムコード、設定のバックアップを作成します。
  • 製品パッケージおよびパッチを、手動で、新しい環境で指定された順序でデプロイします。
  • プロジェクト固有のコードパッケージおよびバンドルを、手動で、新しい AEM サーバー上の別個のパッケージまたはバンドルとしてデプロイします。
  • (JEE上のAEM Formsのみ)LCAおよびDSCをForms Workflowサーバーに手動でデプロイします。
  • エクスポート-インポート機能を使用して、アセットを新しい環境に移動します。複製エージェントを構成し、アセットを発行することもできます。

AEM の設定

AEM 全体のパフォーマンスを改善するために設定するベストプラクティスのいくつかは、次のとおりです。

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

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

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

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

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

個人が特定できる情報の処理

組織にとって大きな課題の 1 つは、個人が特定できる情報（PII）の取り扱い方法です。このようなデータを取り扱うためのベストプラクティスのいくつかは、次のとおりです。

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

このページ