| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.1) E77369-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.1) E77369-01 |
|
|
前 |
次 |
注意:
次のものについては、コンポーネント固有の追加のアップグレード後タスクがあります。
Business Activity Monitoring (BAM)については、「Oracle Business Activity Monitoring 11gを含むOracle SOA Suiteから12cへのアップグレード」を参照してください
Oracle Service Bus (OSB)については、「Oracle Service Busのアップグレード後タスクの実行」を参照してください
ユーザー・メッセージング・サービス(UMS)については、「ユーザー・メッセージング・サービスのアップグレード」を参照してください。
次の各タスクは、アップグレード後に実行する必要があります。
11g環境で必須の起動プロパティを指定するため、または起動時に必要になるその他の操作を実行するために開始スクリプトを使用していた場合は、アップグレード後にプロパティを再適用する必要があります。
つまり、11g環境でJRockit JVMの引数を構成している場合は、アップグレード後にこれらの構成の再適用が必要になります。JVMの起動パラメータを構成する場合は、startup-plan.xmlまたはstartscript.xmlを使用することをお薦めします。
注意:
開始スクリプトの引数を更新していないと、アップグレード後にSOAサーバーとOSBサーバーが起動できなくなることがあります。
スクリプトを有効にするには:
nodemanager.propertiesファイルで、StartScriptEnabledプロパティをtrueに設定します。(デフォルトはfalseです。)起動スクリプトの名前がstartWebLogic.shまたはstartWebLogic.cmdの場合は、ノード・マネージャはそれらのスクリプトのいずれかをデフォルトとして使用します。
カスタム起動スクリプトを指定する場合は、nodemanager.propertiesファイルで、StartScriptNameプロパティを、使用するスクリプトの名前に設定します。
ノード・マネージャは、JAVA_VENDOR、JAVA_HOME、JAVA_OPTIONS、SECURITY_POLICY、CLASSPATH、およびADMIN_URLを設定します。管理コンソールを使用してサーバーを起動するか、または管理サーバーに接続されたWLSTを使用するとき、ノード・マネージャはこれらの値をServerMBean、ServerStartMBean、およびSSLMBeanから取得します。ノード・マネージャに直接接続されたWLSTを使用する場合は、値を指定できますが、使用しない場合は空白にします。
ノード・マネージャは、ServerStartMBean Arguments属性で指定されるすべてのコマンド行起動オプション(-Dフラグ)とSSLArgumentsを組み合わせ、JAVA_OPTIONSという1つの環境変数にします。SSLArgumentsは、SSLMBeanの値から取得されます。SSLMBeanは、ignoreHostnameVerification、HostnameVerifier、およびReverseDNSAllowedの各値があるか検査し、それらの値は-Dフラグに付加されます。すべてのフラグは、SSLArgumentsパラメータから構成されます。ServerStartMBean内のSSLArgumentsおよびArgumentsのすべての値は、起動スクリプトに定義されるJAVA_OPTIONS環境変数から構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。
SOA SuiteおよびBPM環境の12.2.1へのアップグレードを完了するには、開始スクリプト(setDomainEnvなど)のカスタマイズの再適用が必要になることがあります。
サーバーが起動しない場合やAdminModeで起動する場合、最も可能性の高い原因は、setDomainEnv.shの11gからの変更内容が12cドメインに再適用されていないことです。11gと12cのsetDomainEnvを比較して、カスタムの変更をアップグレード後に追加してください。
詳細は、起動スクリプトへのカスタマイズの再適用に関する説明を参照してください。
注意:
今後のアップグレードでカスタマイズの内容が失われないようにするには、『Oracle Fusion Middlewareのアップグレードのプランニング』の、「カスタムのsetDomainEnv設定の保持」を参照してください。
アップグレード前に、XEngineの構成ファイル(SeverityConfig.xmlなど)に加えた変更は、ドメインの再構成プロセスで再生成される新しい構成ファイルにより上書きされます。そのため、アップグレード前の構成ファイルで使用していたカスタマイズしたすべての設定を、アップグレード後に再適用する必要があります。
たとえば、アップグレード前のXEngine構成ファイルSeverityConfig.xmlに、SNIPについてのセクションを追加している場合は、それと同じセクションをアップグレード後の新しいSeverityConfig.xmlファイルに追加する必要があります。
アップグレード後には、次の例で示すように、カスタマイズしたXPathクラスを新しい12c Oracleホームの/classesディレクトリにコピーする必要があります。
カスタムのXPathクラスのコピー元:
<11g Oracle Home>/soa/modules/oracle.soa.ext_11.1.1/classes
コピー先:
<12c Oracle Home>/soa/modules/oracle.soa.ext_11.1.1/classes folder
アップグレード後には、11g環境で使用していたパーティション固有のロールを再作成する必要があります。
既存のアプリケーションに対するパーティションのアプリケーション・ロールは、12cのアップグレード・プロセスでは再作成されません。そのかわりに、次のWLSTスクリプトを使用して、これらのロールを手動で作成する必要があります。
sca_createDefaultPartitionAppRoles partition
統合コンポーネントを含むSOA SuiteおよびBPMのアップグレード後には、環境のすべての管理サーバーと管理対象サーバーを起動して、それらが期待どおりに機能していることを確認する必要があります。
ドメインのアップグレードが適切に実行されているときには、引き続きアップグレードされた11gのドメイン・ホームからサーバーを起動します。
サーバーを起動する順序と停止する順序が重要であり、正しい順序で起動または停止していないと、デプロイメントで問題が発生することがあります。
注意:
管理サーバー、管理対象サーバーおよびコンポーネントを含めたOracle Fusion Middlewareの開始および停止の手順については、「Oracle Fusion Middlewareの開始と停止」を参照してください
サーバーの起動順序:
Web層(Oracle HTTP Serverを含む)
ノード・マネージャ
管理サーバー
Oracle Web Services Manager (OWSM)管理対象サーバー
サービス指向アーキテクチャ(SOA)管理対象サーバー
Oracle Service Bus (OSB)管理対象サーバー
Business Activity Monitoring (BAM)管理対象サーバー
サーバーの停止順序:
Business Activity Monitoring (BAM)管理対象サーバー
Oracle Service Bus (OSB)管理対象サーバー
サービス指向アーキテクチャ(SOA)管理対象サーバー
Oracle Web Services Manager (OWSM)管理対象サーバー
管理サーバー
ノード・マネージャ
Web層(Oracle HTTP Serverを含む)
BPMメタデータのアップグレードは、Business Process Composer 12c (12.2.1)に最初にログインすると(アップグレード完了後)開始されます。
Business Process Composerの使用の詳細は、Oracle Business Process Composerを使用したビジネス・プロセスの開発を参照してください。
包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。監査データ・ストアの使用の詳細は、「監査データ・ストアの管理」を参照してください。
Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketを作成する際の動作が変更されます。このため、hostnameがlocalhostとして構成されていると、リモート・クライアントはServerSocketに接続できなくなる可能性があります。回避策として、localhostをhostnameに変更してください。
アップグレードが正常に終了したら、次のタスクを実行して、コンポーネントが引き続き期待どおりに機能していることと、新しいデプロイメントに問題がないことを確認する必要があります。
ドメイン・コンポーネント構成のアップグレードが成功したことを確認するには、次のURLを使用して管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントでアップグレードされたバージョン番号を確認します。
管理コンソールのURL: http://administration_server_host:administration_server_port/console
Fusion Middleware ControlのURL: http://administration_server_host:administration_server_port/em
注意:
アップグレード後には、11g Oracleホームではなく、新しい12.2.1Oracleホームからすべての管理ツールを実行する必要があります。
データベース・スキーマのアップグレードとインスタンスのアップグレードが成功したかどうかは、アップグレード・アシスタントの各アップグレード・ステータス画面に加え、SQLコマンドを使用して手動で確認することもできます。
詳細は、「SQL問合せによるアップグレード・ステータスの監視」を参照してください。
12c SOAでは、インスタンスがECIDではなくflowIDを使用して制御されます。アップグレード・アシスタントでインスタンスを11g SOAから12c SOAにアップグレードすると、アップグレードした11gのフロー・インスタンスと新しく作成した12cインスタンスには、いくつかの相違点があります。このような相違点がフロー・トレースの機能性に影響を与えることはありませんが、その相違点に注意することは重要です。
後述するフロー・トレースXMLの例には、次のような相違点が示されています。
ActionType属性とActionName属性は、新しく12cに導入されたもので、アップグレードした11gインスタンスでは使用できません。
アップグレードした11gインスタンスの場合、DateとlastUpdatedDateは同じです。
アップグレードした11gインスタンスの場合、Entry Instance IdのElapsedTimeは0になります。
11gから12cにアップグレードしたインスタンスのフロー・トレースXML:
================================ <audit_trail ecid="9dd01e5816e19dbc:-33f3b618:140c1ee8b0f:-8000-000000000000317e" flowId="96102" flowCorrelationId="null" activeInstances="0" date="2013-09-02 00:09:52.133 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT" elapsedTime="23"> <entry instanceId="10093" parentInstanceId="-110092" date="2013-09-02 00:09:52.156 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT" elapsedTime="0" timestamp="1378105792156" state="18" subType="bpel" type="component"> ... </entry> </audit_trail>
新しく作成した12cインスタンスのフロー・トレースXML:
====================================
<audit_trail ecid="dfcc3828-d7de-4af8-b94e-474ff830c961-0000069a" flowId="6"
flowCorrelationId="0000K7z3tBPFCCGpIwt1if1IRXgh00000M" activeInstances="0"
date="2013-10-28 05:35:12.738 PDT" lastUpdatedDate="2013-10-28 05:35:12.825
PDT" elapsedTime="87">
<entry instanceId="13" parentInstanceId="12" date="2013-10-28
05:35:12.749 PDT" lastUpdatedDate="2013-10-28 05:35:12.786 PDT"
elapsedTime="37" timestamp="1382963712749" state="18" actionType="operation"
actionName="process" subType="bpel" type="component">
...
</entry>
</audit_trail>
さらに、BPELで捕捉されたフォルトについて、12cで作成した新しいインスタンスのリカバリ・ステータスは、図8-1に示すようにrecoveredと表示されます。
Nonrecoverableと表示されます。注意:
11gのフォルトから渡された情報は、フォルトの状態を正しく識別するのに十分ではありません。これに対処するために、11gから取得された実際のフォルトはすべて、最初はリカバリ不能として識別されます。その後、ダミーのフォルトが作成されて、適切な状態(BPEL_invoke_recovery、Bpel_activity_recovery)に設定されます。 したがって、11gのフォルトがリカバリ不能であるという警告が表示された場合や、そのことに気づいた場合、警告を無視してかまいません。
