Adobe Experience Manager(AEM)Forms を使用すると、複雑なトランザクションを単純で使いやすいデジタルエクスペリエンスに変えることができます。ただし、効率よく生産的な AEM Forms エコシステムを実装、ビルド、実行、維持するためには、多くの取り組みが必要となります。
ここでは、フォーム管理者、フォーム作成者、開発者たちが AEM Forms、特にアダプティブフォームコンポーネントを扱う際に知っておくべきガイドラインや推奨事項を紹介します。フォーム開発プロジェクトのセットアップから、AEM Forms の設定、カスタマイズ、オーサリング、最適化まで、ベストプラクティスを説明します。これらのベストプラクティスをそれぞれ実行すると、AEM Forms の全体的なパフォーマンスが向上します。
また、AEM の一般的なベストプラクティスについて、以下をお読みになることもお勧めします。
プロジェクトの構造を簡素化し標準化することで、開発と維持にかかる労力を大幅に削減することができます。AEM プロジェクトのビルドには、オープンソースツールの Apache Maven をお勧めします。
Apache Maven aem-project-archetype
を使用して、AEM プロジェクトの構造を作成および管理します。AEM プロジェクトに合わせて、推奨される構造およびテンプレートを作成します。さらに、ビルドを自動化し、変更制御システムを提供するので、プロジェクト管理が容易になります。
archetype:generate
コマンドを使用して、最初の構造を生成します。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 制約の形式で、アダプティブフォームにルールや制約を課します。
データモデルを選択する際には、要件に適合するかどうかだけでなく、すでに XFA および XSD アセットに投資をしている場合、それらの既存の投資を拡張できるかどうかを考慮することが重要です。生成される XML はスキーマで定義された XPATH に従ったデータを含むため、XSD モデルを使用してフォームテンプレートを作成することをお勧めします。フォームデータモデルのデフォルトとして XSD モデルを使用することは、データを処理して使用するバックエンドシステムからフォームデザインが切り離され、フォームフィールドとの 1 対 1 のマッピングによりフォームのパフォーマンスが向上する点でも有用です。また、フィールドの BindRef を XML でそのデータ値の XPATH にすることもできます。
詳しくは、「アダプティブフォームの作成」を参照してください。
AEM Forms には、アダプティブフォームの作成に使用できる初期設定済みのアダプティブフォームテンプレートが用意されています。独自のテンプレートを作成することも可能です。AEM では、静的テンプレートと編集可能なテンプレートを提供しています。
特定のフィールドやパネルインスタンスにスタイルを設定するには、インラインスタイルを使用します。または、CSS ファイルでクラスを定義し、そのクラス名をコンポーネントの CSS Class プロパティに指定します。
コンポーネントにクライアントライブラリを含めることで、アダプティブフォームやそのコンポーネントを使用するフラグメントに一貫したスタイルを適用します。詳しくは、「アダプティブフォームのページコンポーネントの作成」を参照してください。
アダプティブフォームコンテナのプロパティで、CSS ファイルパスフィールド内のクライアントライブラリへのパスを指定することで、選択したアダプティブフォームに、クライアントライブラリで定義したスタイルを適用します。
スタイルのクライアントライブラリを作成するには、テーマエディターのベース clientlib またはフォームコンテナのプロパティでカスタム CSS ファイルを設定します。
アダプティブフォームにはレスポンシブ、タブ形式、アコーディオン、ウィザードなどのパネルレイアウトが用意されており、フォームコンポーネントをパネル上に並べる方法を制御できます。カスタマイズパネルレイアウトを作成し、フォーム作成者が使用できるようにすることができます。詳しくは、アダプティブフォームのカスタムレイアウトコンポーネントの作成を参照してください。
フィールドやパネルレイアウトなど、アダプティブフォームの特定のコンポーネントをカスタマイズすることもできます。
PII データの取り扱いに関する推奨事項については、個人を特定できる情報の取り扱いを参照してください。
フォーム階層の下位にあるフィールドにすばやくアクセスするには、サイドバーのオブジェクトブラウザーを使用します。検索ボックスを使用してフォームまたはオブジェクトツリー内のオブジェクトを検索し、オブジェクト間を移動することができます。
サイドバーのコンポーネントブラウザーでコンポーネントのプロパティを表示して編集するには、コンポーネントを選択して をクリックします。コンポーネントをダブルクリックして、プロパティブラウザーにコンポーネントのプロパティを表示することもできます。
フォームに対する操作をすばやく実行するには、キーボードショートカットを使用します。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
でフィールドの値を変更します。ield.enabled
でフィールドを有効/無効にします。field.visible
でフィールドの表示/非表示を変更します。アダプティブフォームの作成者は、フォーム内のビジネスロジックを構築するために、場合によっては JavaScript コードを作成する必要があります。JavaScript は強力で効果的ですが、セキュリティ上の期待に対して妥協が生じる可能性があります。このため、フォーム作成者が信頼できる人物であることや、フォームを本番稼動させる前に JavaScript コードを見直して承認するプロセスがあることを確認する必要があります。管理者は、各ユーザーの役割や職務に基づいて、ユーザーグループのルールエディターへのアクセスを制限することができます。選択したユーザーグループにルールエディターへのアクセスを許可するを参照してください。
ルール内で数式を使用して、アダプティブフォームを動的にすることができます。すべての数式は有効なJavaScriptの数式で、アダプティブフォームのスクリプトモデルAPIを使用しています。これらの式は、特定のタイプの値を返します。数式およびベストプラクティスについて詳しくは、アダプティブフォームの式を参照してください。
アダプティブフォームのテーマを使用して、一貫した外観とスタイル設定をフォーム全体に適用できる再利用可能なスタイルを作成できます。テーマを使用してフォームコンポーネントやパネルのスタイル設定を定義することをお勧めします。テーマに関するベストプラクティスの一部を以下に示します。
詳しくは、「テーマ」を参照してください。
通常、パフォーマンスに関する問題が発生するのは、フォーム作成者およびエンドユーザーが、オーサリングモードで、または実行時に大規模なフォームを読み込む場合です。フォーム内のオブジェクト(フィールドおよびパネル)が増えるにしたがって、オーサリングや実行の快適さは低下します。また、複数の作成者が共同作業したり、同時にフォームをオーサリングしたりする妨げにもなります。
大規模フォームに関するパフォーマンスの問題を解決するには、以下のベストプラクティスを検討してください。
可能な場合には、XFA をアダプティブフォームに変換する場合でも、XSD フォームデータモデルを使用してアダプティブフォームを作成することをお勧めします。
アダプティブフォームには、ユーザーから情報を取得するフィールドおよびパネルのみを含めます。静的コンテンツを最小限にするか、それらのコンテンツを別のウィンドウで開く URL を使用することを検討します。
すべてのフォームは特定の目的のためにデザインされますが、ほとんどのフォームにはいくつかの共通するセグメントがあります。例えば、個人の詳細、住所、雇用の詳細などです。フォームの共通の要素およびセクションに対してアダプティブフォームフラグメントを作成し、それらを複数のフォーム間で使用します。既存のフォーム内にパネルをフラグメントとして保存することもできます。フラグメントに対する変更はすべて、関連付けられたアダプティブフォームに反映されます。これにより、複数の作成者が同時に、1 つのフォームを構成する別のフラグメントの作業を行えるため、オーサリングの共同作業が促進されます。
自動保存機能のある「保存して再開」を使用して、アダプティブフォームを定期的に保存し、ユーザーが後で再度アクセスしてフォームを完了できるようにします。
フラグメントの遅延読み込みを設定します。遅延読み込みをマークされたフラグメントは、実行時に必要な場合にのみレンダリングされます。大規模なフォームでは、読み込み時間が大幅に減少します。これは、リピート可能なパネルを使用したフラグメントでもサポートされます。詳しくは、「遅延読み込みの設定」を参照してください。
バックエンドから取得したデータを使用してアダプティブフォームフィールドに事前にデータを取り込んで、ユーザーの入力ミスを防いですばやくフォームに入力できるようにします。
AEM Forms の事前入力サービスは、事前定義されたデータ XML ファイルからデータを読み込み、事前入力 XML ファイルの内容でアダプティブフォームのフィールドに事前入力します。
事前入力データ XML は、アダプティブフォームに関連付られたフォームモデルのスキーマに準拠している必要があります。
事前入力 XML には「afBoundedData
」および「afUnBoundedData
」セクションを含めて、アダプティブフォームの連結されたフィールドと連結されていないフィールドのどちらにも事前入力するようにします。
フォームデータモデルに基づいたアダプティブフォームの場合、AEM Forms にはすぐに使用できるフォームデータモデルの事前入力サービスが用意されています。この事前入力サービスは、アダプティブフォーム内のデータモデルオブジェクトに対してデータソースのクエリを実行し、フォームのレンダリング時に、フィールドに値を取り込みます。
ファイル、crx、サービス、http プロトコルを使用してアダプティブフォームに事前入力することもできます。
AEM Forms は、OSGi サービスとしてプラグインしてアダプティブフォームに事前入力できるカスタム事前入力サービスをサポートしています。
詳しくは、アダプティブフォームフィールドの事前入力を参照してください。
Adaptive forms では、ユーザー指定のデータを処理するために、送信アクションが必要となります。送信アクションとは、アダプティブフォームを使って送信されるデータに対して実行されるタスクを決定するものです。
アダプティブフォームでAcrobat Signの複数署名操作を活用することができます。 アダプティブフォームでAcrobat Signを設定する際は、以下の点を考慮してください。 詳しくは、 アダプティブフォームでのAcrobat Signの使用.
レコードのドキュメント(DoR)はアダプティブフォームのフラットな PDF 版で、印刷、署名、アーカイブが行えます。
アダプティブフォームが基づくフォームデータモデルによって、DoR のテンプレートを以下のように設定できます
アダプティブフォームエディターの「レコードのドキュメント」タブで、ヘッダー、フッター、画像、色、フォントなどを設定します。
DoRService
を使用して、DoR をプログラムにより生成します。
DoR から非表示フィールドを除外します。
afAcceptLang
リクエストパラメーターを使用して、別のロケールで DoR を表示します。
AEM Chrome プラグインは、アダプティブフォームをデバッグするためのツールを提供する Google Chrome のブラウザー拡張機能です。フォームの作成者と開発者は、これらのツールを使用して以下の操作を実行できます。
詳しくは、AEM Chrome プラグイン - アダプティブフォームを参照してください。
Calvin SDK は、アダプティブフォームをテストするためのアダプティブフォーム開発者用のユーティリティ API です。Calvin SDK は Hobbes.js テストフレームワーク上に構築されます。このフレームワークを使用して、次のテストを実行できます。
詳しくは、「アダプティブフォームのテスト自動化」を参照してください。
クライアント側で検証をすり抜ける試みを阻止するためにも、データ送信の漏洩やビジネスルール違反の可能性を阻止するためにも、サーバー側の検証が必要です。サーバー側の検証は、必要なクライアントライブラリを読み込むことにより、サーバー上で実行されます。
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-TW)、韓国語 (ko-KR) の各ロケールのアダプティブフォームコンテンツのローカライゼーションをサポートしています。 ただし、実行時にアダプティブフォームに対する新しいロケールのサポートを追加できます。詳しくは、「アダプティブフォームのローカライズに対する新しいロケールのサポート」を参照してください。
ファイアウォール内側の保護された領域に、追加の AEM Forms サーバーを構成することもできます。このインスタンスは次の目的に使用できます。
AEM プロジェクトを別の環境に移動させたいという場合は、よくあります。移動時の主な留意事項は、次のとおりです。
AEM 全体のパフォーマンスを改善するために設定するベストプラクティスのいくつかは、次のとおりです。
Felix コンソールからの JavaScript および CSS の HTML クライアントライブラリ圧縮を有効にします。
すべてのクライアントライブラリを /etc.clientlibs/fd
にキャッシュし、追加のカスタムクライアントライブラリを AEM ディスパッチャーにキャッシュすることで、発行したフォームの応答速度とセキュリティを向上させます。詳しくは、ディスパッチャーを参照してください。
/content/forms/af/
パス および /content/dam/formsanddocuments/*
パスはキャッシュしないでください。アダプティブフォームのキャッシュ設定について詳しくは、アダプティブフォームのキャッシュを参照してください。
Web サーバー圧縮モジュールを経由して、HTML を有効にします。詳しくは、「AEM Forms サーバーのパフォーマンス調整」を参照してください。
大規模なフォームのリクエスト構成ごとの呼び出し数を増加させます。「大規模フォームおよび複雑なフォームのパフォーマンスの最適化」を参照してください。
エラーハンドラーにより表示されるカスタムエラーページを作成します。
AEM Forms サーバーを保護します。
nosamplecontent
実行モードを使用して、実稼働サーバーにサンプルコンテンツおよびサンプルユーザーがデプロイされていないことを確認します。AEM の実稼動準備完了モードでの実行を参照してください。ヒープサイズを 8 GB 以上にします。その他の設定については、「AEM Forms サーバーのパフォーマンス調整」を参照してください。
ユーザーレベルのタスクを実行するには、管理者セッションではなくサービスユーザーセッションを使用します。詳しくは、「サービス認証」を参照してください。
実稼働環境では、送信されたフォームデータを AEM リポジトリに保存しないことをお勧めします。「フォームポータル保存」、「コンテンツ保存」および「PDF の保存」送信アクションのデフォルト実装では、フォームデータが AEM リポジトリに保存されます。これらの送信アクションは、デモを目的としたものです。また、「保存して再開」機能や「自動保存」機能でも、デフォルトでポータルストレージが使用されます。このため、次の推奨事項を検討してください。
ドラフトデータの保存:アダプティブフォームの「ドラフト」機能を使用している場合は、カスタムサービスプロバイダーインターフェイス(SPI)を実装して、データベースなどのより安全なストレージにドラフトデータを保存してください。詳しくは、「ドラフト&送信コンポーネントとデータベースの統合」を参照してください。
送信データの保存:「フォームポータル送信保存」を使用している場合は、カスタム SPI を実装してデータベースに送信データを保存してください。統合例については、ドラフト&送信コンポーネントとデータベースの統合の例 を参照してください。
安全なストレージにフォームデータと添付ファイルを保存するカスタム送信アクションを作成することもできます。詳しくは、アダプティブフォーム向けカスタム送信アクションの作成 を参照してください。
組織にとって大きな課題の 1 つは、個人が特定できる情報(PII)の取り扱い方法です。このようなデータを取り扱うためのベストプラクティスのいくつかは、次のとおりです。