組み込まれた単体のアプリケーションです。アドオンによってサポートされています。機能を提供します)の両方が用意されています。次の図は、このセットアップを示したものです。アーキテクチャには次のコンポーネントが含まれます。サービスのコンテナ、ワークフローエンジンなどが含まれます。パッケージでは提供されません。さまざまなコンポーネントで使用される、スタック全体の不可欠な構成要素です。各種コンポーネントに対して共通の機能を提供します。コンポーネント内部での使用を前提とし、ユーザーの直接使用やカスタマイズは意図されていません。文書を生成するなどフォームに関係する機能を提供します。カスタムコードを組み込んで利用する形で公開されています。サーブレットで、次の機能を提供します。フロントエンドのオーサリング:フォームのオーサリングおよび管理に使用されるフォームのオーサリングと管理のユーザーインターフェイス。サイトにアクセスする一般ユーザー向け)。これはフォームのレンダリングと送信の機能を提供します。ベースのクライアントによるリモートでの利用向けにフォームサービスのサブセットがエクスポートされます。アドオンが含まれます。コンポーネントにそれぞれ次のような特定のサービスを提供します。ユーザーとして認識されます。フォームなど)を提供できます。アドオンで後処理するオプションを使用できます。アドオンを使用できます。オーサリングのユーザーインターフェイスですべてのフォームを作成できるわけではありません。アップロードする必要があります。自動で同期するように設定することもできます。デプロイメントトポロジーには、フォームデザイナーによるフォームのオーサリング、エンドユーザーによるフォームの表示と送信、送信されたフォームデータの処理と保存を支援する要素が含まれます。次の図は、これらの論理要素を示します。これにより、次の機能が有効になります。作成されたフォームなど)をアップロードすることができます。コンソールでフォームを管理することができます。フォームの発行:トポロジーの他の要素(処理および発行)へオーサーインスタンスでホストされたフォームを発行し、ランタイム操作を実行することができます。よる逆複製機能を使用して発行されます。別の複製エージェントを「受信時」トリガーが有効になった「処理」に構成することを推奨します。実行のインスタンスです。これにより、次の機能が有効になります。フォームのレンダリングおよびエンドユーザーへの送信。送信フォームの生データを「処理」へトランスポートし、最終的な記録として処理および保存すること。デフォルトで設定された逆複製機能により実行されます。ローカルに一度保存する(逆複製を有効にするには保存が必要です)代わりに、フォームデータを直接「処理」へ発行するなど、代替の処理を設定することもできます。顧客が発行における機密データの保存の問題を抱えている場合、この代替処理を設定し、より安全な「処理」への発行を行うことができます。これは、「処理」が通常、より安全なゾーンにあることが多いためです。ご使用のお客様向け):発行によりエンドユーザーに向けてレターがレンダリングされ、送信されたレターでデータが処理されて保存および後処理が行われます。保存については、データはローカルで保存することも「処理」へ逆複製する(デフォルトのオプション)こともできます。「処理」へダイレクトプッシュすることもできます(後者はセキュリティ意識の高いお客様にとって有用です)。アドオンにホストされたワークフローでデータを後処理することもできます。場合、データが送られてくるメカニズム(逆複製またはダイレクトプッシュ)によらず、ワークフローは「処理」でトリガーされます。後者は確実なフォームの作成と管理を図るためのもので、「作成者」においてのみ発生し、「処理」では実行できません。「処理」では、次の機能が有効になります。介して行われ、データを処理した後に、適切な保存場所にデータを保存します。フォームデータの安全な保存:「処理」は、ファイアウォールの後ろにユーザーから切り離された生のフォームデータのリポジトリを提供します。「作成者」上のフォーム開発者または「発行」上のエンドユーザーのどちらも、このリポジトリにアクセスすることはできません。これは、顧客が別のサードパーティデータ保存領域を使用しない場合の最終処理後のデータの安全なリポジトリとして機能します。「発行」から到着する通信データの保存とオプションの後処理。よって実行され、これらのワークフローで、最終処理後のデータを外部のデータ保存場所に保存することが選択されます。ご使用のお客様向け):「処理」によって内部ユーザー向けにワークスペースのフロントエンドがホストされ、ユーザータスクに関連するフォームがレンダリングされます。以下の理由により、「処理」は作成者実行モードで実行するように設定されています。「発行」からの生のフォームデータの逆複製ができるようになります。これはデフォルトのデータストレージハンドラーによって要求される機能です。ベースのデプロイメントの際に作成者スタイルのシステムで実行することが推奨されています。ベースのアドオンです。フォームデータのより複雑な処理が必要なユースケースにも対応することができます。レターデータをさらに処理(および適切なデータ保存場所に結果を保存)することができます。ご使用のお客様向け):このアドオンにより、「処理」でのシングルサインオンが可能になります。内でレンダリングされるフォームの送信を処理します。レターデータを保存するためのサードパーティ製のデータストアです。これは、トポロジーのオプション要素でもあります。最終的な記録として「処理」上のリポジトリの使用を選択することもできます。次に、論理トポロジー要素の物理マシンへのマッピングの推奨事項を見てみましょう。サーバーの外部で、スタンドアロンモードで実行することが推奨されます。アドオンの分離にはいくつかの利点があります。サーバーの要件を満たす必要がなくなる、等の利点が挙げられます。イントラネットベースの内部ユーザーのユースケースです。つの異なる「発行」の設定が示されています。向け)イントラネットです。アドオンは厳密にオプションとして使用可能で、その使用は完全に使用者の要件によります。デプロイメントにさらに適合したシンプルなトポロジーを利用することができます。これは、次の図のように表されます。デプロイメントを示します。使用していないので「処理」サーバーは必要ありません。フォームデータは、カスタムのフォーム送信ハンドラーを使用して顧客のデータ保存場所に直接送信されます。クラスタにデプロイされていることが推奨されます。アドオンにも同様のデプロイメントが推奨されます。顧客がアップグレードする場合は、すでにこのように構成されています。アドオンの同一の場所へのデプロイメントは必須です。サーバー内からではなく、スタンドアロンモードで「発行」を実行することがあります。リリースでは新しい機能が複数追加され、大きなファイルのバッチ処理が容易になりました。明細書を生成し、エンドユーザーにメール送信する方法を説明します。クリックすると新しいタブで拡大した図が開きます以下には、上の図の「処理」実行時の詳細なフローを示します。入力データファイルのバッチが、物理的な入力フォルダーにコピーされます。「処理」クラスタのトポロジーリーダー上で実行されるスケジュールされたジョブにより、処理する入力ファイルが取得されます。このジョブは、新しい監視フォルダーの機能からアクティベートおよび設定を行い、入力フォルダーをスキャンすることができます。スキャンジョブは、追加の処理のためのサーバーにファイルのバッチを配信します。この監視フォルダーに顧客が指定したスクリプト、サービス、またはワークフローを介してファイル処理が発生します。ファイルをプリンターに送信します。返されるパフォーマンス指標およびエラー情報は、監視フォルダーのフレームワークに戻されます。フォルダーに保存されます。規約内容は適用されません。すべてのアプリを見るラーニングとサポートマニュアルチュートリアルコミュニティフォーラムで質問アドビスタッフも参加するフォーラムをぜひご利用ください。ページの先頭へこのページは役に立ちましたか。Navigation地域を選択してください地域を選択すると、アドビサイトで使用する言語と内容が変わります。Navigation地域を選択してください地域を選択すると、アドビサイトで使用する言語と内容が変わります。עבריתSverige。