| Oracle® Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース(11.1.1.3) B61432-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース(11.1.1.3) B61432-01 |
|
前 |
次 |
この項では、クラスタ環境でOracle Service Busをデプロイするための構成に必要な作業について説明します。
クラスタ・ドメインのアーキテクチャを、3.2項「クラスタ・デプロイメントの設計」の説明に従ってプランニングしたら、Oracle Service Busをクラスタ環境に設定できます。そのためには、管理サーバーと管理対象サーバーを構成し、Oracle Service Busリソースをサーバーにデプロイする必要があります。インバウンドHTTPロード・バランシング機能が必要な場合は、ルーター(ハードウェアまたはソフトウェア)も必要です。Oracle WebLogic Serverインスタンスとクラスタのドメインの永続構成は、Oracle Service Busドメインのルート・ディレクトリのconfigディレクトリにあるXML構成ファイル(config.xml)に格納されます。
クラスタ・ドメインでOracle Service Busを設定およびデプロイするには、次の手順を実行します:
Oracle Service Busの非クラスタ環境へのデプロイについては、第2章「非クラスタ・デプロイメントの構成」を参照してください。
この項では、クラスタ環境で実行されるOracle Service Busを構成するための以下の前提条件について説明します。
そのクラスタで使用する管理サーバーのIPアドレスを取得します。
1つのクラスタ内のすべてのOracle WebLogic Serverインスタンスは、構成およびモニターに同じ管理サーバーを使用します。サーバーをクラスタに追加する場合、各サーバーが使用する管理サーバーを指定する必要があります。
各クラスタにマルチキャスト・アドレスを割り当てます。
|
注意: Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成時に、マルチキャスト・アドレスの割当てが要求されます(4.2項「手順 2. Oracle Service Busドメインの準備」を参照してください)。マルチキャスト・アドレスは、クラスタ・メンバー間の通信に使用されます。クラスタリングされたサーバーは、1つの専用マルチキャスト・アドレスを共有する必要があります。ネットワーク上の各クラスタに対して、一意のマルチキャスト・アドレスとポート番号の組合せを割り当てる必要があります。ネットワーク上の2つのクラスタが同じマルチキャスト・アドレスを使用する場合、異なるポートを使用する必要があります。クラスタのマルチキャスト・アドレスが異なる場合は、同じポートを使用するか、またはデフォルトのポート( |
クラスタ内のサーバーのIPアドレスを定義します。アドレス定義には、以下のように、いくつかの方法があります。
|
注意: Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成時に、サーバーのリスニング・アドレスの割当てが要求されます(4.2項「手順 2. Oracle Service Busドメインの準備」を参照してください)。 |
クラスタ内のサーバーに対して1つのIPアドレスと異なるリスニング・ポート番号を割り当てる方法。
1つのIPアドレスとサーバーごとに異なるポート番号をクラスタ・サーバーに割り当てることにより、1つのマシンに、そのマシンをマルチ・ホーム・サーバー化することなくクラスタ環境を設定できます。
クライアントからこのようなIPアドレスにアクセスできるようにするには、以下のいずれかの方法で、IPアドレスとポート番号でURLを構成します。
ipAddress:portNumber-portNumber – ポート番号が連番になっている場合。例:
127.0.0.1:7003-7005
ipAddress:portNumber+...+portNumber – ポート番号が連番ではない場合。例:
127.0.0.1:7003+7006+7008
ipAddress:portNumber,ipAddress:portNumber,... – 冗長で明示的な指定。例:
127.0.0.1:7003,127.0.0.1:7004,127.0.0.1:7005
クラスタ内の各マシン上で起動するOracle WebLogic Serverインスタンスごとに静的IPアドレスを割り当てる方法。
この方法では、複数のサーバーが1つのマシン上で実行されている場合、そのマシンはマルチ・ホーム・サーバーとして構成する必要があります。つまり、複数のIPアドレスが1つのコンピュータに割り当てられます。この場合は、クラスタ・アドレスをカンマ区切りのIPアドレスのリストの形にします。
たとえば、次のリストは、config.xmlファイルで指定されているクラスタ・アドレスの例です。MyClusterという名前のクラスタ内の、4つのサーバーのそれぞれに対して、静的IPアドレスが指定されています。
<Cluster ClusterAddress="127.0.0.1:7001,127.0.0.2:7001,127.0.0.3,127.0.0.4:7001" Name="MyCluster"/>
またDNSを使用してもサーバーを指定できます。
アドレス指定の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』の「WebLogicクラスタの設定」にあるリスニング・アドレスの問題の回避に関する項を参照してください。
|
注意: テスト環境では、1台のマシンに複数のOracle WebLogic Serverインスタンスを割り当てることもできます。この場合、一部のOracle WebLogic Serverインスタンスを同一ノード上に異なるポート番号で配置し、他のOracle WebLogic Serverインスタンスを別の複数のノードに同一のポート番号で配置することができます。 |
クラスタ・ドメイン用の次のいずれかのデータベースを構成します。
Microsoft SQL Server
Oracle
|
注意: Oracle WebLogic ServerとともにインストールされるApache Derbyデータベースのローカル・コピーは、評価のみを目的としています。 |
データベースを本番用に適切に構成することが重要です。データおよびログ・メッセージを格納するための十分な領域を用意し、データベース管理のベスト・プラクティスに従う必要があります。
|
注意: 同時アクセス機能を使用するようにデータベースを構成できます。 |
特定のデータベースに関する最新情報については、製品のリリース・ノートを参照してください。
共用ファイル・システムを組み込みます。共用ファイル・システムは、高可用性が求められるあらゆるクラスタに不可欠です。ストレージ・エリア・ネットワーク(Storage Area Network : SAN)またはマルチ・ポート型のディスク・システムをお薦めします。
高可用性クラスタの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』にある「高度なJMSシステム・リソースの構成」のWebLogic JMSクラスタリングの構成に関する項を参照してください。
システム用のルーター(ハードウェアまたはソフトウェア)を構成します。ロード・バランシングは、組込みロード・バランシング機能かWebLogicプロキシ・プラグインのいずれか、または別個のロード・バランシング用ハードウェアを使用して実現されます。
ハードウェアおよびソフトウェア・ルーターについては、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。
|
注意: 1つまたは複数のファイアウォールを含めるようにドメインを設計する場合は、この他にも要件があります。ドメイン構成ファイルにファイアウォール情報を追加する方法については、4.2.1.1項「プロキシ・サーバーまたはファイアウォール情報のドメイン構成への追加」を参照してください。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のクラスタでの通信に関する項を参照してください。 |
Oracle Service Busでは、クラスタの管理対象サーバー間でファイル、電子メール、およびFTPトランスポート処理のロード・バランシングを行います。クラスタのすべての管理対象サーバーが、ファイル、電子メール、FTPの各プロキシ・サービス構成で指定されたアーカイブ、ステージ、エラーの各ディレクトリにアクセスできるようにします。これらのディレクトリは、NFSなどの共有ファイル・システムに構成します。共有ファイル・システムを使用することで、ユーザーとプログラムはリモート・システムにあるファイルにローカル・ファイルと同じようにアクセスできます。
クラスタリングされたOracle WebLogic Serverインスタンスの設定の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のWebLogicクラスタの設定に関する項を参照してください。
Oracle Service Busドメインを準備する際には、各管理対象サーバーの定義をドメイン構成ファイル(config.xml)に追加し、すべての管理対象サーバーをクラスタに割り当て、Oracle Service Busコンポーネントをドメイン上のサーバーに指定する必要があります。
クラスタリング・ドメインでOracle Service Bus環境を準備するには、以下の項で説明する作業を行う必要があります。
Oracle Fusion Middleware構成ウィザードを使用したOracle Service Busドメインの作成の詳細は、『Oracle Fusion Middleware Oracle Service Busインストレーション・ガイド』のOracle Service Bus 11gのインストールと構成に関する項を参照してください。
プロキシ・サーバーまたはファイアウォールの背後でWebサービスを使用する場合は、config.xmlファイルを編集して、そのプロキシ・サーバーまたはファイアウォールに関する情報を追加する必要があります。
プロキシ・サーバーまたはファイアウォールの情報をドメイン構成に追加するには、次の手順を実行します:
テキスト・エディタでconfig.xmlを開きます。
config.xmlファイルで、次のタグで始まる行を検索します。
<Cluster
次の3つの属性をCluster属性リストに追加します。
FrontendHTTPPort="proxyPort" FrontendHTTPSPort="proxySSLPort" FrontendHost="proxyServerHost"
たとえば、次のリストは、config.xmlファイルで指定されているクラスタ・アドレスとファイアウォールの例です。クラスタ名はMyCluster、プロキシ・サーバー名はMyProxyです。
<Cluster ClusterAddress="127.0.0.1:7001,127.0.0.2:7001,127.0.0.3,127.0.0.4:7001" FrontendHTTPPort="7006" FrontendHTTPSPort="7007" FrontendHost="MyProxy" MulticastAddress="127.0.0.5" MulticastPort="7010" Name="MyCluster"/>
変更内容を保存し、config.xmlファイルを閉じます。
Oracle Fusion Middleware構成ウィザードでJMSファイル・ストアを構成するとともに、JMSを使用するプロキシ・サービスおよびビジネス・サービスに、次のリソースを構成する必要があります。
JMSキューまたはトピック。Oracle Service Busでは、JMSを使用して実装されたプロキシ・サービスに自動的にJMSキューが構成されます。JMSを使用するすべてのビジネス・サービスおよび非JMSを使用して実装されたプロキシ・サービスには、JMSキューまたはトピックを構成する必要があります。
プロキシ・サービスでは、異なるドメインのリモート・キューからのメッセージを消費できます。この場合、Oracle Serviceでは自動的にキューが作成されません。プロキシ・サービス用のJMSキューを作成できるのは、キューが同じローカルOracle Service Busドメインにある場合に限ります。
JMS接続ファクトリ。JMSを使用して実装されたすべてのビジネス・サービスとプロキシ・サービスにJMS接続ファクトリを構成する必要があります。
JMSリソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の高度なJMSシステム・リソースの構成に関する項を参照してください。
Oracle Service Busでは、Oracle WebLogic Serverのセキュリティ機能を利用して、メッセージの機密性と整合性を確保し(メッセージ・レベルのセキュリティ)、クライアントとOracle WebLogic Serverの間の接続を保護し(トランスポート・レベルのセキュリティ)、認証と認可(アクセス制御)を行います。必要な作業については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。
|
注意: 各Oracle Service Busドメインに別々にセキュリティを構成する必要があります。Oracle Service Busでは、セキュリティ構成のエクスポートおよびインポートは行いません。 |
クラスタにSSLを構成するには、ドメインの作成時に行うか、またはOracle WebLogic Server管理コンソールを使用します。セキュリティ機能がマルチ・ノード・クラスタにデプロイされているドメインの場合は、クラスタ内の各マシンに対して、キーストア、サーバー証明書、秘密鍵なども構成する必要があります。各マシンに独立したキーストアを使用するか、すべてのマシンで利用可能な場合は単一のキーストアを使用します。
この項では、クラスタ・ドメインの管理対象サーバーに対する基本管理タスクについて説明します。
ノード・マネージャは、Oracle WebLogic Serverインスタンスの起動、停止、および移行に使用できるユーティリティです。Oracle WebLogic Server管理コンソールとともにノード・マネージャを使用して管理対象サーバーを起動できます。また、WLSTスクリプトを作成し、ノード・マネージャの機能を自動化することもできます。
|
ヒント: 起動されたサーバーでOracle Service Busクラスが使用できるように、setDomainEnvスクリプトを実行してからstartNodemanagerスクリプトを実行してください。または、サーバーを起動する前に、Oracle WebLogic Server管理コンソールでクラス・パスを明示的に設定してください。 |
デフォルトでは、Oracle Fusion Middleware構成ウィザードでOracle Service Busクラスタ・ドメインが生成されるときに、次の処理が行われます。
Domain Singleton Marker Application(domainsingletonmarker.ear)がクラスタの最初の管理対象サーバーに割り当てられます。データ集約を正しく実行するには、domainsingletonmarker.earが指定されたサーバーを最初に起動し、他の管理対象サーバーが起動するときに使用できるようにする必要があります。
PurgingMDB (msgpurger.ear)がクラスタの最初の管理対象サーバーに割り当てられます。メッセージ・パージを正しく実行するには、msgpurger.earが指定されたサーバーが使用可能であることが必要です。
ノード・マネージャの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。管理対象サーバーの起動方法と停止方法の概要については、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。
起動が完了したら、Oracle Service Busコンソールを使用してサーバーのステータスを確認できます。Oracle Service Busコンソールを使用してサーバーをモニターする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「モニター」にあるサーバーの表示と検索に関する項を参照してください。
クラスタ環境にOracle Service Bus構成をデプロイするときは、非クラスタ・デプロイメントと同じ手順に従います。デプロイメント手順については、2.4項「ステップ4. Oracle Service Bus構成のデプロイ」を参照してください。
|
注意: 非クラスタ環境から構成をインポートし、その構成にファイル、FTP、または電子メール・トランスポートを使用するプロキシ・サービスが含まれている場合、それらの各プロキシ・サービスに管理対象サーバーを指定する必要があります。管理対象サーバー・リストは、クラスタリングされたOracle Service BusドメインのOracle Service Busコンソールにのみ表示されます。 |
本番環境は、時間の経過や、アプリケーション使用の増加に伴って変化します。この項では、一般的な本番環境の変化に応じてドメインを更新する方法を説明します。
Oracle Service Busの使用が増加するに従って、Oracle Service Busクラスタに新しい管理対象サーバーを追加して能力を強化できます。クラスタに管理対象サーバーを追加するには、Oracle WebLogic Server管理コンソールを使用します。構成によっては、Oracle Service Busコンソールを使用した管理タスクの実行が必要になることがあります。
新しい管理対象サーバーをOracle Service Busクラスタに追加するには、Oracle WebLogic Server管理コンソールを使用して次の手順を実行します。
Oracle Service Busクラスタに追加する管理対象サーバーが実行されていないことを確認します。必要な場合は、サーバーを停止します。管理対象サーバーを停止する方法については、 『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。
「チェンジ・センター」で「ロックして編集」をクリックします(まだクリックしていない場合)。
「環境」を展開して「クラスタ」を選択します。「クラスタの概要」パネルで、クラスタ・アドレスを変更し、新しいサーバーのアドレスを含めます。
「サービス」を展開して「永続ストア」を選択します。新しいサーバーの新しいファイル・ストアを定義し、移行可能ではないサーバーに割り当てます。
|
注意: 新しいサーバーのファイル・ストア定義に指定するディレクトリを必ず作成してください。 |
「サービス」>「メッセージング」を展開して「JMSサーバー」を選択します。新しいファイル・ストアを使用して新しいサーバーに新しいJMSサーバーを作成し、同じ移行可能ではないサーバーに割り当てます。
「JMSサーバーのサマリー」パネルで、新しいJMSサーバーの名前をクリックします。「一時的なテンプレートを含むモジュール」リストで「jmsResources」を選択し、「一時的なテンプレート名」ボックスにTemporaryTmpltと入力し、「保存」をクリックします。
以下の手順を実行し、必要なキューを作成して対応する分散宛先に追加します。
「サービス」>「メッセージング」を展開します(まだ展開していない場合)。
「JMSモジュール」を選択し、「jmsResources」をクリックします。
QueueIn_auto_xという名前の新しいキューを作成し、テンプレートのデフォルト値をそのまま使用し、キューを新しいサーバーに割り当てます。
|
注意: これらの手順で指定するキュー名のxは、Oracle Service Busクラスタに現在ある管理対象サーバーの番号であり、1ずつ増分されます。たとえば、現在2台の管理対象サーバーがあるクラスタに管理対象サーバーを追加する場合、xは3になります。この手順でQueueIn_auto_3を作成する場合、次の手順で作成するキューの名前の最後も3にします。 |
QueueIn_auto_xを定義するとき、新しいサブデプロイメント(たとえば、sub_new)を作成し、ターゲットとして新しいサーバーのJMSサーバーを選択します。
|
注意: 次の手順では、各キューの新しいサブデプロイメントを作成するかわりに、このサブデプロイメントを再使用します。 |
wli.reporting.jmsprovider.queue_auto_xを作成し、新しいサーバーに割り当てます。
wlsb.internal.transport.task.queue.email_auto_xを作成し、新しいサーバーに割り当てます。
wlsb.internal.transport.task.queue.file_auto_xを作成し、新しいサーバーに割り当てます。
wlsb.internal.transport.task.queue.ftp_auto_xを作成し、新しいサーバーに割り当てます。
wli.reporting.jmsprovider_error.queue_auto_xを作成し、新しいサーバーに割り当てます。
wlsb.internal.transport.task.queue.sftp_auto_xを作成し、新しいサーバーに割り当てます。
「サービス」、「メッセージング」および「JMSモジュール」を展開してjmsResourcesモジュールを選択します。前の手順で作成したキューを対応する分散宛先に追加します。
QueueIn_auto_xをdist_QueueIn_autoに追加します。
wli.reporting.jmsprovider.queue_auto_xをdist_wli.reporting.jmsprovider.queue_autoに追加します。
wlsb.internal.transport.task.queue.email_auto_xをdist_wlsb.internal.transport.task.queue.email_autoに追加します。
wlsb.internal.transport.task.queue.file_auto_xをdist_wlsb.internal.transport.task.queue.file_autoに追加します。
wlsb.internal.transport.task.queue.ftp_auto_xをdist_wlsb.internal.transport.task.queue.ftp_autoに追加します。
wli.reporting.jmsprovider_error.queue_auto_xをdist_wli.reporting.jmsprovider_error.queue_autoに追加します。
wlsb.internal.transport.task.queue.sftp_auto_xをdist_wlsb.internal.transport.task.queue.sftp_autoに追加します。
「チェンジ・センター」で、「アクティブ化」をクリックします。
新しい管理対象サーバーを起動できます。管理対象サーバーを起動する方法については、 『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。
クラスタにHTTPロード・バランサ(ソフトウェアまたはハードウェア)がある場合、ロード・バランサのサーバー・リストに新しい管理対象サーバーを追加します。たとえば、WebLogic HttpClusterServletを使用する場合、対応するアプリケーションのweb.xmlファイルに新しいサーバーを追加します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のクラスタでのロード・バランシングに関する項を参照してください。
Oracle Service Bus構成にJMSリクエスト/レスポンス機能を使用する1つまたは複数のビジネス・サービスがある場合、新しい管理対象サーバーをクラスタに追加した後、Oracle Service Busコンソールを使用して以下の手順も実行する必要があります。
「チェンジ・センター」で「作成」をクリックし、セッションを作成します。
「プロジェクト・エクスプローラ」を使用し、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索して選択します。この種類のビジネス・サービスの「サービスの種類」には、「メッセージング・サービス」と表示されています。
「詳細表示」ページの一番下で「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスがある場合、クラスタ・アドレスに新しいサーバーを追加します。
「ビジネス・サービスの編集 - 概要」ページで「保存」をクリックします。
JMSリクエスト/レスポンスを使用する残りの各ビジネス・サービスに対して、前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックします。
ビジネス・サービスは拡張したドメインでの処理用に構成されました。
|
注意: ビジネス・サービスでJMS MesageID相関スキーマを使用している場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加する必要があります。キューとトピックの宛先を構成する方法については、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。 |
Oracle Service Bus構成に、クラスタ・アドレスを持つJMSエンドポイントを使用する1つまたは複数のプロキシ・サービスがある場合、新しい管理対象サーバーをクラスタに追加した後、Oracle Service Busコンソールを使用して以下の手順も実行する必要があります。
「チェンジ・センター」で「作成」をクリックし、セッションを作成します。
「プロジェクト・エクスプローラ」を使用し、クラスタ・アドレスを持つJMSエンドポイントを使用するプロキシ・サービスを検索して選択します。
「詳細表示」ページの一番下で「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスがある場合、クラスタ・アドレスに新しいサーバーを追加します。
「プロキシ・サービスの編集 - 概要」ページで「保存」をクリックします。
クラスタ・アドレスを持つJMSエンドポイントを使用する残りの各プロキシ・サービスに対して、前の手順を繰り返します。
「チェンジ・センター」で、「アクティブ化」をクリックします。
プロキシ・サービスは拡張されたドメインでの処理用に構成されました。
Oracle WebLogic Server管理ツールを使用して、Oracle Service Busクラスタから管理対象サーバーを削除できます。管理対象サーバーの削除を決定する前に、次の点に注意してください。
Oracle Service Bus構成に、クラスタから削除する管理対象サーバーにトランスポート・ポーラーを固定しているファイル、FTPまたは電子メール・トランスポートを使用するプロキシ・サービスがある場合、クラスタから管理対象サーバーを削除する前に、これらの各プロキシ・サービスに異なる管理対象サーバーを選択する必要があります。
Domain Singleton Marker Applicationをホストする管理対象サーバーはクラスタから削除しないこと。Domain Singleton Marker Applicationをホストする管理対象サーバーに障害が発生した場合、手動で移行を行う必要があります。
Message Reporting Purgerアプリケーションをホストする管理対象サーバーを削除する場合は、Message Reporting Purgerと関連するキュー(wli.reporting.purge.queue)のために別の管理対象サーバーを選択する必要があります。
クラスタから管理対象サーバーを削除する方法については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの削除に関する項を参照してください。
ビジネス・サービスを変更する手順は、非クラスタ環境でもクラスタ環境でも同じです。ビジネス・サービスの変更方法については、2.5.1項「ビジネス・サービスの変更」を参照してください。
しかし、クラスタのビジネス・サービスへの変更をデプロイする手順は、ビジネス・サービスに行った変更の種類および同時にデプロイする他の変更の性質によって異なります。詳細については、以下の項のインストール方針に関する説明を参照してください。
ビジネス要件の変化に伴い、プロキシ・サービスの変更が必要になることがあります。このような変更はオンラインで動的に行うことも、部分的または完全にオフラインで行うこともできます。変更に下位互換性がある(つまり、インタフェースは変更しない)場合、Oracle Service Busコンソールを使用してオンラインで動的に変更できます。他の種類の変更は、部分的または完全にオフラインで行う必要があり、システム管理の追加手順が必要です。
オンライン更新の実行については、2.5.3項「構成のオンライン更新」を参照してください。
プロキシ・サービス・インタフェースへの下位互換性がない変更を含む変更を行うには、完全なオフライン・デプロイメントが必要です。新しいバージョンをインストールするには、すべてのサーバーが作動中に以下の手順を実行します。
すべてのインバウンド・メッセージを休止します。
非同期にバックログされたすべてのメッセージが処理されたことを確認します。
プロキシ・サービスで必要な変更を行い、テストして、プロキシ・サービスが要求どおり動作することを確認します。
インバウンド・メッセージの受信を再開します。
下位互換性とインストール方針の詳細は、2.5.2項「新しいバージョンのプロキシ・サービスのインストール」を参照してください。
