|
|
『Oracle Service Bus アップグレード ガイド』は、以下の節で構成されています。
Oracle Service Bus の最新バージョンの新機能の説明については、『Oracle Service Bus リリース ノート』を参照してください。
| 注意 : | Oracle Service Bus 10g リリース 3 メンテナンス パック 1 のアンインストールはサポートされていません。Maintenance Pack 1 へアップグレードした後で、前のインストールバージョンの Oracle Service Bus に戻す場合、バックアップから Oracle Service Bus 環境をリストアする必要があります。 |
AquaLogic Service Bus (ALSB) のコンフィグレーションを 2.5、2.6、2.6RP1 または 3.0 バージョンから、Oracle Service Bus バージョン 10g リリース 3 メンテナンス パック 1 (10.3.1) に直接アップグレードできます。
ALSB のバージョン 2.0 および 2.1 を Oracle Service Bus バージョン 10g リリース 3 (10.3.1) に直接アップグレードできません。まず、ALSB の 2.0 および 2.1 のバージョンを ALSB の 2.5、2.6、2.6RP1 または 3.0 にアップグレードしてから、このガイドの指示に従って、Oracle Service Bus バージョン 10g リリース 3 メンテナンス パック 1 (10.3.1) にアップグレードします。
製品のアップグレードでは、最新開発および実行時ツールを含むOracle Service Bus の最新バージョンをインストールします。インストール後、既存の Oracle Service Bus ドメインを更新するために、新しいリソースが利用可能になります。
Oracle Service Bus の最新バージョンをインストールした後、Oracle Service Bus の機能でドメインをアップグレードできます。
Oracle Service Bus 10gR3 より前のバージョンのドメインの自動インプレース アップグレードはサポートされていません。「移行アップグレード」のみをサポートします。つまり、最新バージョンの Oracle Service Bus で新しいドメインを作成してから、ALSB 2.5、2.6、2.6RP1 または 3.0 のドメインからエクスポートしたコンフィグレーションを新しく作成した Oracle Service Bus ドメインにインポートします。その結果、コンフィグレーションは、古い ALSB ドメインから新しい Oracle Service Bus ドメインに移動されます。
新しい Oracle Service Bus ドメインへのアップグレードでは、クラスタ化されたドメインおよび非クラスタ化されたドメインの両方がサポートされています。
アップグレード プロセスを開始する前に、「アップグレードに関する考慮事項」をお読みください。
表 1 に、ALSB の各バージョンまたは Oracle Service Bus が実行される WebLogic Server のバージョンを示します。
Oracle Service Bus 10g リリース 3 をすでにご使用の場合、この節では、製品とドメインを Oracle Service Bus 10g リリース 3 メンテナンス パック 1 にアップグレードするための手順について説明します。
Oracle Service Bus の製品をアップグレードするには、次の手順を実行します。
ドメインの JMS コンフィグレーションによって、ドメインをアップグレードするために使用する次の手順を選択します。
サブデプロイメント対象の接続ファクトリとともにJMS リソースを使用しない各ドメインのために、これらのドメイン アップグレード手順に従います。
サブデプロイメント対象の接続ファクトリとともにJMS リソースを使用する各ドメインのために、これらのドメイン アップグレード手順に従います。
Oracle Smart Update ツールを使用して、Oracle Service Bus インストールにパブリック パッチ 3YG8 を適用します。
DOMAIN/bin/setDomainEnv.cmd/sh コマンドを実行します。ALSB_HOME/common/upgrade に切り替えます。
Linux/Solaris: java weblogic.WLST ./upgradeDomain.py
Windows: java weblogic.WLST upgradeDomain.py
移行のすべての手順は手動で実行します。ALSB 2.5、2.6、2.6RP1 または 3.0 ドメインから Oracle Service Bus 10g リリース 3 メンテナンス パック 1 (10.3.1) ドメインへの移行のためのウィザードは提供されていません。ALSB ドメインをアップグレードするときは、この節で説明する各手順を実行してください。
次の手順を実行した後、「アップグレードに関する考慮事項」にある関連する情報を確認してください。AquaLogic Service Bus の現在バージョンのアップグレードの考慮事項に関する手順については、表 3 を使用してください。
ALSB Administration Console を使用して、アップグレードする ALSB 2.5、2.6、2.6RP1、または 3.0 コンフィグレーションをエクスポートします。これを実行するには、管理者としてログオンし、Console の ［システムの管理] パネルで [リソースのエクスポート] を選択します。ALSB コンフィグレーションをエクスポートする方法については、以下の『AquaLogic Service Bus Console の使い方』の該当するドキュメントを参照してください。
ALSBConfigurationMBean (3.0、2.6、および 2.5) を使用して、コンフィグレーションをエクスポートすることもできます。詳細については、該当する ALSB の『デプロイメント ガイド』の「デプロイメント API の使用」 (3.0、2.6、および 2.5) を参照してください。
| 注意 : | ほとんどの場合、JMS リソース、SNMP トラップ設定、ワーク マネージャ定義などの WebLogic Server リソースをエクスポートすることはできません。これらのオブジェクトは、「手順 6. その他の Oracle WebLogic Server オブジェクトの再作成」の説明に従って新しい Oracle Service Bus ドメインに再作成する必要があります。 |
WebLogic Server Administration Console を使用して、ドメインからセキュリティ データをエクスポートします。WebLogic Server Administration Console で、[ドメイン構造｜セキュリティ レルム] を選択し、セキュリティ レルムを選択します。[移行｜エクスポート] を選択して、データをエクスポートします。表 2 に、セキュリティ データと、各データを格納するセキュリティ プロバイダの種類を示します。
| 注意 : | 以下の節で説明するように、エクスポートするプロバイダのセットはアップグレードするバージョンによって異なります。 |
ALSB 2.5 リリースで作業を開始する場合、PKI 資格とユーザ名/パスワード資格の両方が WebLogic Server レルムと ALSB コンフィグレーション リポジトリに格納されています。したがって、これらの資格は、「手順 1. ALSB コンフィグレーションのエクスポート」で生成され、エクスポートされたコンフィグレーション JAR の一部としてエクスポートされます。JAR を新しいドメインにインポートすると、JAR ファイルの内容に基づいてレルム データが設定されます。つまり、ALSB 2.5 以降からアップグレードする場合は、PKI 資格またはユーザ名/パスワード資格をエクスポートする必要はありません。
詳細については、Oracle WebLogic Server のセキュリティの「セキュリティ データの移行」を参照してください。
『Oracle Service Bus インストール ガイド』の説明に従って、Oracle Service Bus 10g リリース 3 メンテナンス パック 1 (10.3.1) ソフトウェアをインストールします。
以下に記載された Domain Configuration Wizard またはオフライン コンフィグレーション ツールを使用して、新しい Oracle Service Bus ドメインを作成します。
新しいドメインで、SSL を使用する Oracle WebLogic Security フレームワークと、プロキシ サービスおよびビジネス サービスをサポートするために必要なセキュリティ プロバイダをコンフィグレーションします。『Oracle Service Bus セキュリティ ガイド』の「WebLogic Security フレームワークのコンフィグレーション : 主な手順」を参照してください。
ALSB 2.5、2.6、2.6RP1、または 3.0 コンフィグレーションのインポートに関する以下のセキュリティ関連情報に注意してください。
UseX509ForIdentity プロパティを _SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN_ コンフィグレーション (X.509 トークンによる着信認証をサポートするために必要) に追加した場合は、新しいドメインでもこのプロパティを追加します。Oracle WebLogic Server Administration Console オンライン ヘルプの「X.509 証明書を使用した ID の証明」を参照してください。
新しい Oracle Service Bus ドメインで、「手順 1. ALSB コンフィグレーションのエクスポート」でエクスポートできなかった以下の Oracle WebLogic Server オブジェクトを再作成します。
Oracle WebLogic Server ドメイン リソースのコンフィグレーションの詳細については、Oracle WebLogic Server および Oracle WebLogic Express の紹介の「Oracle WebLogic Server システム管理の概要」を参照してください。
| 注意 : | Oracle WebLogic Server コンソールで、ドメイン スコープの SNMP エージェントをコンフィグレーションする必要があります。Oracle WebLogic Server 10.x では、SNMP 機能が強化されています。SNMP の詳細については、『Oracle WebLogic SNMP 管理ガイド』を参照してください。 |
Tuxedo ドメイン ID を Oracle WebLogic Server ユーザとして追加します (これは、Tuxedo サービスへの要求を正常に呼び出すための要件です)。
コンフィグレーションに Tuxedo 転送ベースのサービスが含まれている場合は、WTC のローカル アクセス ポイント リソースとリモート アクセス ポイント リソースをコンフィグレーションします。
詳細については、『Tuxedo の相互運用ソリューション』の「Tuxedo 転送のための Oracle WebLogic Tuxedo Connector のコンフィグレーション」を参照してください。
Oracle WebLogic Server Administration Console を使用して、「手順 2. セキュリティ コンフィグレーションのエクスポート」でエクスポートしたセキュリティ データを新しい Oracle Service Bus ドメインにインポートします。Oracle WebLogic Server Administration Console オンライン ヘルプの「セキュリティ プロバイダへのデータのインポート」を参照してください。
「手順 1. ALSB コンフィグレーションのエクスポート」でエクスポートした ALSB コンフィグレーション データを新しいドメインにインポートします。
| 注意 : | コンフィグレーション データを新しく作成したドメインにインポートできます。また、既存のドメインにインポートするアーティファクトとは無関係のプロジェクト、フォルダ、またはサービスのみを含むコンフィグレーション JAR をインポートすることもできます。Oracle Service Bus 10g リリース 3 メンテナンス パック 1 (10.3.1) ドメインとドメイン タイプとドメイン名が同一の ALSB 2.5、2.6、2.6RP1 または 3.0 のドメインから Oracle Service Bus 10g リリース 3 メンテナンス パック 1 (10.3.1) ドメインへのアーチファクトのインポートは、定義されていません。 |
コンフィグレーション データをインポートするには、Oracle Service Bus Console に管理者としてログオンし、[システムの管理] パネルから [リソースのインポート] を選択します。Oracle Service Bus コンフィグレーションのインポートについては、『Workshop for WebLogic 用 Oracle Service Bus プラグインの使用』の「リソースのインポート」を参照してください。
Oracle Service Bus ドメイン コンフィグレーションの一部の変更は自動化されていないため、手動で実装する必要があります。次の「アップグレードに関する考慮事項」を参照してください。
この節では、Oracle Service Bus のさまざまなコンフィグレーション アーティファクトをアップグレードする際の考慮事項について説明します。この節では、アップグレードするコンフィグレーションに影響する可能性がある領域での、ALSB 2.5、2.6、3.0、と Oracle Service Bus 10g リリース 3 メンテナンス パック 1 (10.3.1) の動作の違いについて説明します。
有効な各アップグレード パスについて、考慮する必要があるアップグレード情報を表 3 に示します。
ALSB 2.5 または 2.6 コンフィグレーションを ALSB 3.0 にアップグレードする場合は、以下のアップグレードに関する考慮事項をお読みください。
ALSB Console で使用可能な多くの設計時の機能が、Workshop for WebLogic (ALSB 開発環境) で使用できます。
Console の代わりに IDE を使用する場合は、2.6 のコンフィグレーション JAR を 3.0 IDE に直接インポートできます。JAR ファイルを 3.0 IDE にインポートする方法については、『Workshop for WebLogic 用 Oracle Service Bus プラグインの使用』の「リソースのインポート」を参照してください。
2.5 のコンフィグレーション JAR を 3.0 IDE にインポートするには、まず JAR を ALSB Console にインポートする必要があります。次に、Console でコンフィグレーション JAR ファイルをエクスポートし、3.0 IDE にインポートします。
| 注意 : | コンフィグレーション JAR を 3.0 IDE にインポートすると、操作設定と管理設定が削除されます。これらの設定を保持するには、上記の説明に従ってまずコンフィグレーション JAR ファイルをコンソールにインポートしてからエクスポートして 3.0 IDE にインポートします。後でコンフィグレーションを IDE からコンソールに移行するときに、操作設定の保持を有効にすると、最初の手順でインポートした操作設定が保持されるようになります。 |
JAR ファイルをエクスポートする方法については、「手順 1. ALSB コンフィグレーションのエクスポート」を参照してください。
ALSB 3.0 の SLA アラート ルール機能は、以前のリリースとは若干異なります。これらの変更は、実行時の評価やアラートの発行方法には影響しません。ただし、以下の変更点に注意してください。
ALSB Console でアラート ルールの各エントリを区別できた以前のリリースとは異なり、プロキシ サービスおよびビジネス サービスからアラート ルールを介したアラート送り先への参照が保持され、1 つの参照として表示されます。たとえば、プロキシ サービスで、複数のアラート ルールと複数のパイプライン アラート アクションが同じアラート送り先を使用する場合、そのアラート送り先の [参照元] ページには、アラート送り先のエントリが 1 つだけ表示されます。詳細については、『Oracle Service Bus Console の使い方』の「アラート送り先」を参照してください。
ALSB 3.0 では、アラートは個別のリソースではなくなっているため、アラートからアラート送り先への参照を表示する方法が以前のリリースとは異なります。Console の 2 つのページが影響を受けます。影響を受ける 1 つ目のページは、[アラート送り先] ページです。このページの [参照元] フィールドに、送り先を参照しているアラート ルールが表示されなくなります。代わりに、[参照元] フィールドにアラートを含むサービスが表示されます。この二次的な影響として、同じアラート送り先を参照する複数のアラート (SLA アラートまたはパイプライン アラート) がサービスに含まれている場合、関連付けられたサービスが [参照元] フィールドに 1 回だけ示されます。影響を受けるもう 1 つのページは、[アラート ルール] ページです。このページには、参照情報が含まれなくなっています。代わりに、関連付けられたサービスの [サービス概要] ページの [参照] フィールドに参照先のアラート送り先が含まれています。詳細については、『Oracle Service Bus Console の使い方』の「アラート送り先」を参照してください。
以前のリリースと同様に、コンフィグレーションされた送り先に SLA アラートが発行されると、アラートの詳細にルール ID が含まれます。ただし、ALSB 3.0 では、ルール ID の値は親サービスのグローバル名とアラート ルール名の組み合わせに設定されます。SNMP トラップの場合、以前のリリースと同様に、ルール ID は 64 文字に切り捨てられます。
インポート時にアラートを既存のアラートとマージしていた ALSB 2.6 とは異なり、ALSB 3.0 は保持/上書きのセマンティクスをユーザに提供します。これにより、アラートの名前が同じであるかどうかに関係なく、既存のすべてのアラートを保持することも、既存のアラートを上書きすることもできます。
ALSB 2.5 または 2.6 からエクスポートされた JAR には、アクセス制御ポリシーは含まれていません。ALSB 3.0 では、以前のリリースのコンフィグレーション JAR をインポートする前に、「インポート前」アクセス制御ポリシーを使用して、3.0 への JAR のインプレース アップグレードを実行します。インプレース アップグレードを実行するために、プリプロセッサが各プロキシ サービスに管理可能なすべての認可プロバイダを照会し、適用可能なアクセス制御ポリシーのリストを取得します。次に、これらのポリシーをプロキシ サービスのサービス定義に挿入します。これは、ベストエフォート ベースで実行されます。
管理可能な認可プロバイダとは、PolicyEditorMBean インタフェースを実装する認可プロバイダです。このようなプロバイダは、WebLogic Server および ALSB Console で格納されたポリシーを追加、変更、および削除できるようにする読み込み/書き込み API を公開します。
転送レベルのポリシーと、デフォルトのメッセージレベルのポリシーの場合、システムは PolicyEditorMBean を公開しているプロバイダだけを照会し、適用可能なポリシーを取得して、それらのポリシーをサービス定義に挿入します。
操作メッセージレベルのポリシーの場合、システムは PolicyListerMBean を実装しているプロバイダしか照会できません。プロバイダが PolicyListerMBean インタフェースを実装していない場合、操作レベルのポリシーは取得されません。
インプレース アップグレードが完了すると、認可プロバイダから取得したアクセス制御ポリシーを含め、コンフィグレーション JAR が 3.0 タイプである場合と同様にインポート プロセスが進められます。表 4 に、適用可能なパラメータとインポート プロセスの結果のさまざまな組み合わせを示します。この結果はインポート プロセスの結果であり、コンフィグレーションのインポート後に実行された内容を示しているわけではありません。
対象の ALSB 3.0 システムに認可プロバイダが存在しない場合、認可プロバイダ用にインポートされた ACL がインポート時に無視され、警告が表示されます。この場合、セッションを破棄するか、インポート タスクを元に戻し、認可プロバイダをサーバに追加してから再度インポートできます。また、ALSB Console でセキュリティ パラメータのダミー更新操作を実行することもできます。この場合、システムによってベストエフォート ベースで衝突が自動修正されます。これらの変更はアトミックであり、セッションを破棄すれば元に戻すことができます。
セキュリティ パラメータの更新の詳細については、『Oracle Service Bus Console の使い方』の「メッセージ レベルのセキュリティ コンフィグレーション」を参照してください。
以下の変更は、ALSB コンフィグレーションに影響を及ぼす場合があります。
ALSB 2.6 では、メッセージの再試行回数は、ビジネス サービスの URI のリストに適用されます。3.0 では、再試行回数は個々の URL エンドポイントに適用されます。アップグレード プロセスでは、2.6 の動作が次のように維持されます。
new_retries = N-1 + old_retries*N
ここで、N は URI の総数を表し、old_retries は 2.6 の再試行回数を表します。
たとえば、ALSB 2.6 でビジネス サービスの 3 つの URL をコンフィグレーションしており、再試行回数が 1 回であるとします。2.6 の再試行メカニズムでは、3 つの URL がすべて試行されます。再試行の遅延後、3 つの URL がすべて再試行されます。3.0 で同じ動作を実現するために、再試行回数が 5 回に変更されます。これは、(3 -1) + (1*3) = 5 という式を適用して取得された値です。最終的な結果はまったく同じです。つまり、3 つの URL が 1 回試行され (5 回の再試行のうち、2 回を使用)、再試行の遅延後、3 つの URL がもう一度試行されます (5 回の再試行のうち、残りの 3 回を使用)。
コンフィグレーションされている URL が 1 つしかない場合は、以前の動作と新しい動作は同じであり、アップグレード時に再試行回数が変更されることはありません。
詳細については、『Oracle Service Bus Console の使い方』の「ビジネス サービス : 作成と管理」を参照してください。
ビジネス サービスを ALSB 3.0 にインポートするときに、インポート プロセスで 2.6 コンフィグレーションの重複 URI が削除されます。URI がランダムな重みベースのロード バランシング アルゴリズムを使用し、重みが設定されている場合、重みは適宜調整されます。たとえば、ビジネス サービスが以下の URI と重みでコンフィグレーションされているとします。
ビジネス サービスが他のアルゴリズムでコンフィグレーションされている場合は、アップグレード時に重複 URI が削除され、その他の変更は行われません。
ロード バランシング アルゴリズムのパラメータの設定の詳細については、『Oracle Service Bus Console の使い方』の「ビジネス サービス : 作成と管理」を参照してください。
発信要求の送信時に配信エラーが発生した場合、ALSB では SOAP エラーなどのアプリケーション エラーのエンドポイント URI を再試行するかどうかを指定できます。これは、通信エラーの再試行には影響を及ぼしません。この新しいオプションは、ビジネス サービスの [転送コンフィグレーション] ページに用意されています。詳細については、『Oracle Service Bus Console の使い方』の「[転送コンフィグレーション] ページ」を参照してください。再試行回数を超えるとエラーが発生します。
2.6 の動作を維持するには、[転送コンフィグレーション] ページでアップグレードのデフォルト値を [はい] に設定します。
このオプションを使用するには、例外が通信エラーとアプリケーション エラーのどちらであるかを転送 SDK に伝えるように転送プロバイダをコンフィグレーションする必要があります。ALSB 3.0 では、このために転送 SDK が拡張されています。詳細については、『転送 SDK ユーザーズ ガイド』の「転送プロバイダの開発」を参照してください。
| 注意 : | この機能を適用できるのは、HTTP プロキシ サービスのみです。 |
ALSB 3.0 Console では、HTTP と HTTPS の切り替えを簡略化するために、HTTPS 転送コンフィグレーションが削除され、その機能が 3.0 の着信 HTTP 転送プロバイダに追加されています。3.0 の [HTTP 転送コンフィグレーション] ページには、HTTPS を有効にするチェック ボックスが含まれています。
新しい要素である use-https が HTTP 転送の着信プロパティのスキーマに追加されます。
<xs:element name="use-https" type="xs:boolean" minOccurs="0"/>
既存の HTTPS 転送コンフィグレーションは、このフラグが true に設定された HTTP 転送にアップグレードされます。
以前のリリースでは、ALSB の転送は ALSB Console からしかコンフィグレーションできませんでした。ALSB 3.0 では、Eclipse で転送を設計できます。詳細については、『転送 SDK ユーザーズ ガイド』の「Workshop for WebLogic 用の Oracle Service Bus の転送の開発」を参照してください。
ALSB 2.5 コンフィグレーションを ALSB 3.0 にアップグレードする場合は、以下の考慮事項をお読みください。
ALSB JMS サービス (プロキシおよびビジネス) には、JMS キューへのアクセスに SSL を使用するかどうかを制御する [SSL を使用] 属性があります。ただし、ALSB 2.5 では、[SSL を使用] が指定されていても、JMS ビジネス サービスは発信応答の読み込み時に SSL を使用しませんでした。これは ALSB 2.6 で修正されました。そのため、ALSB 2.5 のこのようなビジネス サービス ([SSL を使用] が選択されている JMS 要求/応答ビジネス サービス) を新しいドメインにインポートすると、発信応答 URL が非 SSL ポートに対応している場合に問題が発生することがあります。SSL を使用してこの非 SSL ポートと通信しようとすると、エラーが発生します。
解決策 : [SSL を使用] が指定された要求/応答発信 JMS ビジネス サービスを含む ALSB 2.5 のコンフィグレーション JAR をインポートすると、ALSB Console に警告が出力されます。これを修正するには、SSL ポートを使用するように発信応答キューの URL を変更します。
ALSB 2.5 の JAR からインポートされたすべての SOAP サービスは、デフォルトで SOAP 1.1 を使用します。ALSB 2.6 および 3.0 リリースでは、SOAP 1.2 をサポートしています。
ALSB 2.6 以降のリリースでは、UDDI 自動インポート機能が拡張され、UDDI レジストリとの自動同期が可能になりました。ALSB のサブスクライブ先のサービスのレジストリで変更が発生すると、UDDI レジストリから ALSB に通知が送信されます。
単一ノードでは、この通知は管理対象サーバの HTTP アドレスに送信されます。クラスタ化されたコンフィグレーションでは、通知は管理サーバの HTTP アドレスに送信されます。
レジストリのコンフィグレーションに [自動インポート] フラグを追加して、レジストリの自動同期を有効にするかどうかを示します。ALSB 2.5 の JAR ファイルのインポート時に、ALSB は元の動作を維持するためにこのフラグを無効にします。
操作パラメータは ALSB 2.6 およびそれ以降のリリースで拡張されました。そのため、ALSB 2.5 コンフィグレーションの一部のパラメータに設定されていた値が、それ以降のバージョンでは別の値に設定されます。ALSB 3.0 でサービス操作パラメータに使用する値を次の表に示します。
ALSB 2.6 コンフィグレーションで設定されたパラメータでは、ALSB 3.0 ドメインへのインポート時にインポートされた JAR に指定された値が保持されます。
ALSB 3.0 コンフィグレーションを Oracle Service Bus 10g リリース 3 メンテナンス パック 1 (10.3.1) にアップグレードする場合は、以下のアップグレードに関する考慮事項をお読みください。
Workshop for WebLogic 10g リリース 3 メンテナンス パック 1 (10.3.1) で ALSB 3.0 ワークスペースをアップグレードするには、次の手順を実行します。
| 注意 : | ワークスペースをアップグレードすると、ALSB 3.0 の WorkSpace Studio 1.1 では開けなくなります。 |
10g リリース 3 (10.3) では、jndi-service-account は非推奨です。
10g リリース 3 メンテナンス パック 1 (10.3.1) にアップグレードした後、Oracle Service Bus JMS ビジネス サービスは JMS および JNDI 両方のため jms-service-account を使用します。
Oracle Service Bus の JMS ビジネス サービスでどのように JNDI アカウントと JMS アカウントを移行するかを次の表に示します。
10g リリース 3 メンテナンス パック 1 (10.3.1) にアップグレードした後、パイプラインでのすべてのアクションに対してユニークな ID が割り当てられます。
10g リリース 3 (10.3) のプロキシ サービスでは、新しいモニタ フラグを使用して、収集する統計のレベルを制御します。次の 3 つのレベルがあります。
モニタ フラグの値はアップグレードにより [パイプライン] に設定されます。
Oracle Service Bus 10g リリース 3 (10.3) から、次の領域で検証ルールがより厳密になっています。その結果、設計時エラーまたは実行時エラーが発生する場合があります。
変数 'VARIABLE-NAME' が値で初期化される前に参照されています。: Fault [{http://docs.oasis-open.org/wsbpel/2.0/process/executable}uninitializedVariable]
分割-結合が ALSB 3.0 では機能するのに Oracle Service Bus 10g リリース 3 (10.3.1) では上記のエラーで失敗する場合、挿入前に変数を初期化するように分割-結合を変更します。
詳細については、『Oracle Service Bus リリースノート』を参照してください。
|