|
上の図は、Correspondence Management Solution で推奨されるデプロイメントトポロジを示しています。 このようなデプロイメントトポロジは、デプロイメント、QA、および実稼働環境を隔離する必要性に対応します。プロジェクト、これらの各環境の規模に応じて、一般に実稼働環境は複数のインスタンスにクラスター化されます。
ソリューションは次の 2 つのインスタンスとして実装されます。
インスタンス
|
説明
|
ユーザー
|
作成者
|
アセットは、通信テンプレートのプレビューを含めて作成され、管理されます。テキスト、レイアウト、データディクショナリ(DD)、およびレターテンプレートの作成のような作成タスクが実行されます。
|
コンテンツ / 作成者
|
発行
|
最終通信が作成されます。作成インスタンスで作成された(かつ最終処理された)アセットは、(アセットを管理インターフェイスの)簡単なボタンクリックで発行インスタンスに発行されます。
|
エンドユーザーまたはエージェント
|
Correspondence Management Solution のすべてのインスタンスは同じソフトウェアのインストールを参照します。ただし、インスタンスは設定方法が異なっています。例えば、システム設定により、インスタンスが作成者または発行のどちらとして機能するかが決まります。
作成者と発行インスタンスは共通の LiveCycle サーバーを共有します。
注意: Correspondence Management Solution は、フォーム / 出力 /プロセス管理などのサービスのために Management LiveCycle サーバーを使用します。
作成者と発行インスタンスには、独自の JCR(CRX: Content Repository Extreme)リポジトリがあります。
Correspondence Management Solution の読み込み / 書き出し機能を使用し、コンテンツおよびデザインテンプレートなどの Correspondence Management アセットを開発、QA、パフォーマンス、および実稼働環境の間で転送します。この機能は アセットを管理インターフェイスで利用できます。
トポロジを計画するときには次の点を考慮します。
作成者およびパブリッシュインスタンスの両方と並行して作業するユーザーの数により、必要なインスタンスの数が決まります。
CQ インスタンスに保存されたスタティックコンテンツ(非 CM アセット)により、Dispatcher のキャッシュの必要性が決まります。
LiveCycle サーバーでのレターレンダリングの要求量により、LiveCycle サーバーの数が決まります。
システムのセキュリティ用:
通常、作成者インスタンスは内部ネットワークの内部ファイアウォールの背後にあります。
発行環境がファイアウォールの背後にある場合もない場合もあります。
このインスタンスは通信を生成するエージェントだけにアクセスできます。
作成者および発行インスタンスの設定、使用方法の詳細については、インストールのデプロイメント後のタスクを参照してください。
2 つのインスタンスのセットアップについては、デプロイメント後のタスクの「作成者インスタンスの設定」および「発行インスタンスの設定」セクションを参照してください。これには、異なる物理サーバーだけでなく、単一の物理サーバーのステップも含まれます。
|
|
|