AEM Forms は一連のパッケージとして AEM に組み込まれた単体のアプリケーションです。AEM Forms は、通信の後処理およびプロセス管理などの高度な機能が用意された JEE ベースの Forms Workflows アドオンによってサポートされています。AEM パッケージには、AEM OSGI コンテナに読み込まれるサービス自体（API のプロバイダー）と、AEM Sling フレームワークで管理されるサーブレットまたは JSP（フロントエンドの機能および REST API 機能を提供します）の両方が用意されています。次の図は、このセットアップを示したものです。
AEM Forms のアーキテクチャには次のコンポーネントが含まれます。
- AEM のコアサービス：組み込みアプリケーションに対する AEM の基本サービス。JCR 準拠のコンテンツリポジトリ、OSGI サービスのコンテナ、ワークフローエンジンなどが含まれます。これらのサービスは、AEM Forms アプリケーションで使用できますが AEM Forms パッケージでは提供されません。これらのサービスは、AEM Forms のさまざまなコンポーネントで使用される、スタック全体の不可欠な構成要素です。
- フォーム共通のサービス：AEM Forms の各種コンポーネントに対して共通の機能を提供します。Document Manager と監視フォルダーのサポートを除き、これらのサービスは Adobe コンポーネント内部での使用を前提とし、ユーザーの直接使用やカスタマイズは意図されていません。
- Forms サービス：フォームのレンダリング、フォームから PDF 文書を生成するなどフォームに関係する機能を提供します。これらのサービスの多くは、AEM にカスタムコードを組み込んで利用する形で公開されています。
- Web レイヤー：共通のサービスおよびフォームのサービス上に構築された JSP またはサーブレットで、次の機能を提供します。
- フロントエンドのオーサリング：フォームのオーサリングおよび管理に使用されるフォームのオーサリングと管理のユーザーインターフェイス。
- フォームのレンダリングおよび送信のフロントエンド：AEM Forms のエンドユーザーに対するユーザーインターフェイス（例えば、行政関連の Web サイトにアクセスする一般ユーザー向け）。これはフォームのレンダリングと送信の機能を提供します。
- REST API：JSP および サーブレットにより、モバイル SDK フォームなど、HTTP ベースのクライアントによるリモートでの利用向けにフォームサービスのサブセットがエクスポートされます。
AEM ベースのコンポーネントに加えて、AEM Forms には（JEE ベースの）Forms Workflows アドオンが含まれます。このアドオンは AEM コンポーネントにそれぞれ次のような特定のサービスを提供します。
- 統合されたユーザー管理：Forms Workflows アドオンのユーザーが AEM ユーザーとして認識されます。AEM とアドオンの間でシングルサインオンが必要となるシナリオでは必須です（例えば、HTML Workspace など）。
- アセットのホスティング：Forms Workflows アドオンは AEM でレンダリングされるアセット（例えば、HTML5 フォームなど）を提供できます。
- 通信の後処理：Correspondence Management をご利用いただいているお客様の場合、ワークフローエンジンにホストされたワークフローにより送信されたレターを、Forms Workflows アドオンで後処理するオプションを使用できます。
加えて、フォームに関係する複雑なワークフロー、ワークスペースおよびタスクの管理、ドキュメントセキュリティなどの高度なユースケースにおいて、AEM Forms のご利用者も Forms Workflows アドオンを使用できます。
AEM Forms オーサリングのユーザーインターフェイスですべてのフォームを作成できるわけではありません。フォームを作成できない場合、スタンドアロンの Forms Designer ユーティリティを使用してあらかじめオーサリングを可能にし、ローカルディスクに保存して、個別または Zip ファイルで AEM Forms Manager にアップロードする必要があります。または、AEM と Forms Workflows アドオンのアプリケーションが同一の JEE サーバーにデプロイされている場合は、アプリケーションアセットとしてアドオンに追加するようにフォームを構成し、そこから AEM Forms Manager と自動で同期するように設定することもできます。
AEM Forms のデプロイメントトポロジーには、フォームデザイナーによるフォームのオーサリング、エンドユーザーによるフォームの表示と送信、送信されたフォームデータの処理と保存を支援する要素が含まれます。次の図は、これらの論理要素を示します。
作成者：フォームおよびレターの設計者など内部ユーザー向けの標準的な作成者実行モードでの AEM Forms のインスタンスです。これにより、次の機能が有効になります。
- フォームの作成と管理：フォーム設計者はアダプティブフォームを作成および編集し、外部で作成された異なるタイプのフォーム（AEM Forms Designer で作成されたフォームなど）をアップロードすることができます。また、Forms Manager コンソールでフォームを管理することができます。
- フォームの発行：トポロジーの他の要素（処理および発行）へオーサーインスタンスでホストされたフォームを発行し、ランタイム操作を実行することができます。フォームは AEM による逆複製機能を使用して発行されます。発行されたフォームを手動で「処理」へプッシュするための複製エージェントを「作成者」上に 1 つ構成し、受信したフォームを自動的に「発行」に複製するためのもう 1 つ別の複製エージェントを「受信時」トリガーが有効になった「処理」に構成することを推奨します。
- レターのオーサリング / 発行（Correspondence Management をご使用のお客様向け）：フォームのオーサリング / 発行と同様です。
発行：フォームベースのアプリケーションを使用するエンドユーザー（例えば、Web サイトにアクセスし、フォームを送信するユーザーなど）向けの標準的な発行の実行モードにおける AEM Forms 実行のインスタンスです。これにより、次の機能が有効になります。
- フォームのレンダリングおよびエンドユーザーへの送信。
- 送信フォームの生データを「処理」へトランスポートし、最終的な記録として処理および保存すること。トランスポートは AEM Forms にデフォルトで設定された逆複製機能により実行されます。ローカルに一度保存する（逆複製を有効にするには保存が必要です）代わりに、フォームデータを直接「処理」へ発行するなど、代替の処理を設定することもできます。顧客が発行における機密データの保存の問題を抱えている場合、この代替処理を設定し、より安全な「処理」への発行を行うことができます。これは、「処理」が通常、より安全なゾーンにあることが多いためです。
- レターレンダリングおよび送信（Correspondence Management ご使用のお客様向け）：発行によりエンドユーザーに向けてレターがレンダリングされ、送信されたレターでデータが処理されて保存および後処理が行われます。保存については、データはローカルで保存することも「処理」へ逆複製する（デフォルトのオプション）こともできます。または「処理」へダイレクトプッシュすることもできます（後者はセキュリティ意識の高いお客様にとって有用です）。また、オプションで AEM workflow または Forms Workflows アドオンにホストされたワークフローでデータを後処理することもできます。AEM workflow の場合、データが送られてくるメカニズム（逆複製またはダイレクトプッシュ）によらず、ワークフローは「処理」でトリガーされます。
処理：Forms Manager グループにユーザーが割り当てられていない状態の作成者実行モードで実行される AEM Forms のインスタンスです。後者は確実なフォームの作成と管理を図るためのもので、「作成者」においてのみ発生し、「処理」では実行できません。「処理」では、次の機能が有効になります。
- 「発行」からの到着する生のフォームデータの処理：主にデータの受信時にトリガーされる AEM workflows を介して行われ、データを処理した後に、適切な保存場所にデータを保存します。
- フォームデータの安全な保存：「処理」は、ファイアウォールの後ろにユーザーから切り離された生のフォームデータのリポジトリを提供します。「作成者」上のフォーム開発者または「発行」上のエンドユーザーのどちらも、このリポジトリにアクセスすることはできません。また、これは、顧客が別のサードパーティデータ保存領域を使用しない場合の最終処理後のデータの安全なリポジトリとして機能します。
- 「発行」から到着する通信データの保存とオプションの後処理。オプションの後処理は、対応するレターの定義に対して設定された AEM workflow によって実行され、これらのワークフローで、最終処理後のデータを外部のデータ保存場所に保存することが選択されます。
- HTML Workspace ホスティング（HTML Workspace ご使用のお客様向け）：「処理」によって内部ユーザー向けにワークスペースのフロントエンドがホストされ、ユーザータスクに関連するフォームがレンダリングされます。
以下の理由により、「処理」は作成者実行モードで実行するように設定されています。
- 「発行」からの生のフォームデータの逆複製ができるようになります。これはデフォルトのデータストレージハンドラーによって要求される機能です。
- 「発行」から到着する生のフォームデータの主な処理先である AEM workflow は、TarMK ベースのデプロイメントの際に作成者スタイルのシステムで実行することが推奨されています。
AEM Forms Workflows アドオン：AEM Forms の特定のコンポーネントが必要とする JEE ベースのアドオンです。また、フォームデータのより複雑な処理が必要なユースケースにも対応することができます。
- 高度なフォーム／レターデータの処理：このアドオンにより、高度な処理管理機能が要求される複雑なユースケースで、フォーム / レターデータをさらに処理（および適切なデータ保存場所に結果を保存）することができます。
- HTML workspace のサポート（HTML workspace ご使用のお客様向け）：このアドオンにより、「処理」でのシングルサインオンが可能になります。「処理」でレンダリングされる一部のアセットを提供し、HTML workspace 内でレンダリングされるフォームの送信を処理します。
フォームのデータストア：最終処理後のフォーム / レターデータを保存するためのサードパーティ製のデータストアです。これは、トポロジーのオプション要素でもあります。最終的な記録として「処理」上のリポジトリの使用を選択することもできます。
次に、論理トポロジー要素の物理マシンへのマッピングの推奨事項を見てみましょう。
AEM Forms Workspace または AEM Forms Workspace アプリの使用を考えていない新規顧客には、「作成者」および「処理」は、Forms Workflows アドオンをホストする JEE サーバーの外部で、スタンドアロンモードで実行することが推奨されます。AEM と Forms Workflows アドオンの分離にはいくつかの利点があります。個々人による、より簡単な管理や更新が可能になる点や、Forms Workflows アドオンを必要とするユースケースが存在しない場合、JEE サーバーの要件を満たす必要がなくなる、等の利点が挙げられます。
アダプティブフォームは通常インターネットベースのエンドユーザーのユースケースですが、Correspondence Management はイントラネットベースの内部ユーザーのユースケースです。各シナリオで 2 つの異なる「発行」の設定が示されています。1 つは（アダプティブフォーム向け）エクストラネット、もう 1 つは（Correspondence Management 向け）イントラネットです。
このシナリオでは、Forms Workflows アドオンは厳密にオプションとして使用可能で、その使用は完全に使用者の要件によります。
Workspace や Correspondence Management を使用しない代わりにカスタムのフォームデータ送信および後処理のメカニズムを使用する基本フォーム利用者は、標準的な AEM のデプロイメントにさらに適合したシンプルなトポロジーを利用することができます。これは、次の図のように表されます。
上の図は、標準的な作成者と発行の AEM デプロイメントを示します。この場合、顧客は Workspace や Correspondence Management を使用していないので「処理」サーバーは必要ありません。また、フォームデータは、カスタムのフォーム送信ハンドラーを使用して顧客のデータ保存場所に直接送信されます。
「作成者」と開発環境 Forms Workflows アドオンが、同一の JEE サーバーインスタンス / クラスタにデプロイされていることが推奨されます。「処理」と実稼働 Forms Workflows アドオンにも同様のデプロイメントが推奨されます。AEM Forms の顧客がアップグレードする場合は、すでにこのように構成されています。HTML / Mobile Workspace を使用する新規顧客は、AEM と Forms Workflows アドオンの同一の場所へのデプロイメントは必須です。
場合によって、顧客は JEE サーバー内からではなく、スタンドアロンモードで「発行」を実行することがあります。
最新の AEM Forms のリリースでは新しい機能が複数追加され、大きなファイルのバッチ処理が容易になりました。次の図は、入力データファイルの大きいバッチから、顧客が PDF 明細書を生成し、エンドユーザーにメール送信する方法を説明します。
以下には、上の図の「処理」実行時の詳細なフローを示します。
- 入力データファイルのバッチが、物理的な入力フォルダーにコピーされます。
- 「処理」クラスタのトポロジーリーダー上で実行されるスケジュールされたジョブにより、処理する入力ファイルが取得されます。このジョブは、新しい監視フォルダーの機能からアクティベートおよび設定を行い、入力フォルダーをスキャンすることができます。
- スキャンジョブは、追加の処理のためのサーバーにファイルのバッチを配信します。この監視フォルダーに顧客が指定したスクリプト、サービス、またはワークフローを介してファイル処理が発生します。
- このシナリオでは、ファイル処理コードは新しいバッチ処理 API を使用して入力データファイルから PDF を生成します。その後、生成された PDF ファイルをプリンターに送信します。
- バッチ処理 API から返されるパフォーマンス指標およびエラー情報は、監視フォルダーのフレームワークに戻されます。それらは、手作業での分析目的で物理監視フォルダーの result / failure フォルダーに保存されます。
Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。