|
|
この節では、AquaLogic Service Bus のさまざまなコンフィグレーション アーティファクトをアップグレードする際の考慮事項について説明します。また、アップグレードするコンフィグレーションに影響を与える可能性のある、特定の領域における AquaLogic Service Bus 2.1 と AquaLogic Service Bus 2.5 の動作の違いを示します。内容は以下のとおりです。
undo レコードのシリアライズされた形式が 2.5 で変更されたため、2.5 以降では undo レコードをアップグレードできます。ただし、この拡張機能により、2.1 から 2.5 へのアップグレードの場合に undo 機能が使用できなくなりました。つまり、2.1 のコンフィグレーションを変更してから 2.5 にアップグレードする場合、(2.5 ドメインでは) 2.1 ドメインで行った変更の undo を行うことができません。ただし、引き続き AquaLogic Service Bus Console で実行およびアクティブ化履歴を参照することはできます。
AquaLogic Service Bus 2.5 では、着信応答または発信要求の準備中にエラー コード BEA-382101、BEA-382102、および BEA-382151 が生成されません。
AquaLogic Service Bus 2.1 では、これらのエラーが次の場合に生成されました。
AquaLogic Service Bus 2.1 では、これらのエラーが実行時にバインディング レイヤで捕捉されました。
AquaLogic Service Bus 2.5 では、これらのエラーが設計時に置換アクションで捕捉され、割り当てアクションが失敗したことを示すエラー コード BEA-382040 が表示されます。
プロキシ サービス エラー ハンドラまたはクライアントサイド コードで、WSS を使用しているかまたは特定の AquaLogic Service Bus 2.1 エラー コードに基づいている場合は、AquaLogic Service Bus 2.5 で以下の変更に注意してください。
WebLogic Server WSS が AquaLogic Service Bus に SOAP エラーを返す場合は常に、AquaLogic Service Bus メッセージ コンテキストで以下のエラーが生じます。
AquaLogic Service Bus デフォルト エラー ハンドラは、ルート SOAP エラーをクライアントに返します。
(2.5 の場合は、AquaLogic Service Bus リリース ノートの CR280071 を参照)
AquaLogic Service Bus 2.1 では、IntegrationOperator ロールのユーザに、AquaLogic Service Bus コンフィグレーションのエクスポートが許可されていました。2.5 では許可されていません。解決策としては、ユーザに別のロールを再割り当てします。
AquaLogic Service Bus 2.5 で許可されている PKI 資格マッピング プロバイダとユーザ名/パスワード資格マッピング プロバイダはそれぞれ 1 つだけです。
AquaLogic Service 2.5 では、最大 1 つの PKI 資格マッピング プロバイダと最大 1 つのユーザ名/パスワード資格マッピング プロバイダをコンフィグレーションできます。AquaLogic 2.1 では、複数の PKI 資格マッピング プロバイダおよび複数のユーザ名/パスワード資格マッピング プロバイダを使用できます。したがって、複数の PKI またはユーザ名/パスワード資格マッピング プロバイダを 2.1 で作成していた場合に、AquaLogic 2.1 から 2.5 へのアップグレードを行うときは、すべての PKI マッピング データを単一の PKI 資格マッピング プロバイダにインポートし、すべてのユーザ名/パスワード マッピング データを単一のユーザ名/パスワード資格マッピング プロバイダにインポートする必要があります。
2.1 では、SLA アラートが WebLogic 診断フレームワーク (WLDF) ログに記録されていました。2.5 ドメインに移行すると、2.1 のログの内容が削除されます。したがって、アラートとその詳細は、2.5 の AquaLogic Service Bus Console に表示されません。
また、移行アップグレードを行う場合は、レポート ログのアラートも削除されます。インプレース アップグレードを行う場合は、ログが保持されます。
2.1 のアラートが電子メールで発行される場合は、アップグレード後に引き続きユーザーの電子メール アカウントでそのアラートを使用できます。ただし、このようなすべてのアラートが JMS アクションのみ (つまり、JMS 送り先として定義された JMS キューか JMS トピックのいずれか) でコンフィグレーションされた場合、想定される動作はアップグレードの方法によって異なります。
AquaLogic Service Bus 2.1 では、SLA アラートの電子メール アクションを定義するときに、[アラート概要] フィールドの内容をカスタマイズできませんでした。すべてのアラート概要 (電子メールの「件名」行の内容) には、「AquaLogic Service Bus アラート」というテキストが含まれていました。AquaLogic Service Bus 2.5 には、SLA アラートとパイプラン アラートのアクションのコンフィグレーション時にカスタマイズ可能な新しい [アラート概要] フィールドがあります。
AquaLogic Service Bus では、2.1 から 2.5 に移行されるこのような SLA アラートについては、[アラート概要] フィールドに 2.1 のテキスト「AquaLogic Service Bus アラート」が入力されます。
アップグレードが完了したら、[アラート概要] フィールドのメッセージをわかりやすい内容に変更できます。アラート アクションのコンフィグレーションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」にある「アラート」を参照してください。
AquaLogic Service Bus 2.5 では、アラート送り先という新しいリソースが採用されています。このリソースは、AquaLogic Service Bus からのアラート通知を受信できる受信者のリストを取り込みます。SLA アラート ルールが 2.1 から 2.5 にアップグレードされると、2.1 の SLA アラート ルールでコンフィグレーションされたアラート アクションが抽出され、アラート送り先リソースの作成に使用されます。次に、このリソースを参照するように SLA アラート ルールがアップグレードされます。
作成されたアラート送り先は、アラート ルールを関連付けたサービスと同じプロジェクトおよびフォルダにあります。アラート送り先の名前は、「アップグレードされたアラート送り先 - xxxxxx」になります。ここで、xxxxxx はユニークな番号です。
アップグレード プロセスでは、受信者のユニークな組み合わせごとにアラート送り先が作成されます。つまり、同じ受信者のセットを含む 10 個の SLA アラート ルールが 2.1 からアップグレードされた場合、最初の SLA アラート ルールに関連付けられたサービスと同じプロジェクトおよびフォルダに作成されるアラート送り先リソースは 1 つだけです。
アラート送り先については、『AquaLogic Service Bus Console の使い方』の「アラート送り先」を参照してください。
  
|
