| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.1.3) E57555-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.1.3) E57555-04 |
|
前 |
次 |
この章では、SOA 12cへのアップグレード後に実行する必要のある可能性があるタスクについて概要を説明します。
この章の内容は次のとおりです。
|
注意: 次のものについては、コンポーネント固有の追加のアップグレード後タスクがあります。Business Activity Monitoring (BAM)については、「Oracle Business Activity Monitoring (Oracle BAM)を含むSOAのアップグレード」を参照してください。 SOAコア拡張機能(AIAFP)については、「SOAコア拡張機能のアップグレード後タスクの実行」を参照してください。 Oracle Service Bus (OSB)については、「Oracle Service Busのアップグレード後タスクの実行」を参照してください。 ユーザー・メッセージング・サービス(UMS)については、『Oracle User Messaging Serviceの管理』のユーザー・メッセージング・サービスのアップグレードに関する項を参照してください。 |
次の各タスクは、アップグレード後に実行する必要があります。
11g環境で必須の起動プロパティを指定するため、または起動時に必要になるその他の操作を実行するために開始スクリプトを使用していた場合は、アップグレード後にプロパティを再適用する必要があります。
つまり、11g環境でJRockit JVMの引数を構成している場合は、アップグレード後にこれらの構成の再適用が必要になります。JVMの起動パラメータを構成する場合は、startup-plan.xmlまたはstartscript.xmlを使用することをお薦めします。
|
注意: 開始スクリプトの引数を更新していないと、アップグレード後にSOAサーバーとOSBサーバーが起動できなくなることがあります。 |
スクリプトを有効にするには:
nodemanager.propertiesファイルで、StartScriptEnabledプロパティをtrueに設定します。(デフォルトはfalseです。)開始スクリプトの名前をstartWebLogic.shまたはstartWebLogic.cmdにすると、ノード・マネージャは、これらのスクリプトのどちらかをデフォルトとして使用します。
カスタムの開始スクリプトを指定する場合は、StartScriptNameプロパティを、nodemanager.propertiesファイル内の各自のスクリプトの名前に設定します。
ノード・マネージャにより、JAVA_VENDOR、JAVA_HOME、JAVA_OPTIONS、SECURITY_POLICY、CLASSPATHおよびADMIN_URLが設定されます。これらの値は、サーバーの起動に管理コンソールを使用するとき、または管理サーバーに接続されたWLSTを使用するときに、ServerMBean、ServerStartMBeanおよびSSLMBeanから取得されます。ノード・マネージャに直接接続されたWLSTを使用するときには、値を指定できます。指定しない場合は、値を空のままにします。
ノード・マネージャは、ServerStartMBeanのArguments属性とSSLArgumentsで指定されたコマンドラインの起動オプション(-Dフラグ)のすべてを、1つの環境変数JAVA_OPTIONSに結合します。SSLArgumentsは、SSLMBeanの値から取得されます。SSLMBeanで、ignorehost nameVerification、host nameVerifierおよびReverseDNSAllowedの値が調べられ、それらの値が-Dフラグに追加されます。これらすべてのフラグにより、SSLArgumentsパラメータが構成されます。SSLArgumentsと、ServerStartMBeanのArgumentsのすべての値により、開始スクリプト用に定義されるJAVA_OPTIONS環境変数が構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。
SOA SuiteおよびBPM環境の12.1.3へのアップグレードを完了するには、開始スクリプト(setDomainEnvなど)のカスタマイズの再適用が必要になることがあります。
サーバーが起動しない場合やAdminModeで起動する場合、最も可能性の高い原因は、setDomainEnv.shの11gからの変更内容が12cドメインに再適用されていないことです。11gと12cの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
アップグレード後に、パーティション固有のロールはすべてのパーティションについて自動的には再作成されません。ロールは、デフォルト・パーティションに対してのみ作成されます。他のすべてのパーティションについては、下のWLSTコマンドを使用してこれらのロールを作成する必要があります。
sca_createDefaultPartitionAppRoles partition
この12c (12.1.3)の新機能の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のパーティションへのアクセスのセキュリティ保護に関する項を参照してください。
Oracle Web Services Manager (OWSM) 11gでは、メッセージ保護のために複数のタイプのキーストアをサポートしていましたが、Javaキー・ストア(JKS)がデフォルトのキーストアでした。しかし、OWSMリリース12c (12.1.2)の時点で、OWSMはデフォルト・キーストアをKSS (OPSS KeyStore Service)に切り替えています。
11gでJKSを使用していた場合に、12cでKSSを使用するには、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のメッセージ保護のキーストアの構成に関する項を参照してください
統合コンポーネントを含むSOA SuiteおよびBPMのアップグレード後には、環境のすべての管理サーバーと管理対象サーバーを起動して、それらが期待どおりに機能していることを確認する必要があります。
ドメインのアップグレードが適切に実行されているときには、引き続きアップグレードされた11gのドメイン・ホームからサーバーを起動します。
サーバーを起動する順序と停止する順序が重要であり、正しい順序で起動または停止していないと、デプロイメントで問題が発生することがあります。
|
注意: 管理サーバー、管理対象サーバーおよびコンポーネントを含めたOracle Fusion Middlewareの開始および停止の手順については、『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を含む)
アップグレードに多数のインスタンス(クローズおよびオープン)の移行が含まれる場合は、Enterprise Managerフロー・トレースのロード時にパフォーマンスの問題が発生することがあります。パフォーマンスの低下を防ぐには、次の手順で説明するように索引を作成します。
第8.1.7項の説明に従って、管理サーバーおよび実行中の管理対象サーバーを停止します。
SQLPLUSからSOAINFRAスキーマに接続し、次のコマンドを実行します。
CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);
第8.1.7項の説明に従って、管理サーバーおよび管理対象サーバーを再起動します。
BPMメタデータのアップグレードは、Business Process Composer 12c (12.1.3)に最初にログインすると(アップグレード完了後)開始されます。
Business Process Composerの詳細は、『Oracle Business Process Management Business Process Composerユーザーズ・ガイド』を参照してください。
包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。監査データ・ストアの使用の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の監査データ・ストアの管理に関する項を参照してください。
Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketの作成動作が変更されます。このため、host nameがlocalhostとして構成されている場合、リモート・クライアントがServerSocketに接続できない可能性があります。回避策として、localhostをhost nameに変更してください。
詳細は、テクノロジ・アダプタの理解のOracleソケット・アダプタの構成に関する項を参照してください。
Oracle SOA Suite 12c (12.1.3)から、ワーク・マネージャはほとんどのSOA関連ワーク・スレッドを処理するようになりました。SOA 11gに指定したスレッドの構成は、アップグレードしたSOA 12c環境には適用されません。SOA 12cへのアップグレード後に、スレッドを再構成する必要があります。
新しいスレッド・モデルの使用方法の詳細は、パフォーマンス・チューニングのSOAインフラストラクチャのチューニングに関する項を参照してください。
アップグレードが正常に終了したら、次のタスクを実行して、コンポーネントが引き続き期待どおりに機能していることと、新しいデプロイメントに問題がないことを確認する必要があります。
ドメイン・コンポーネント構成のアップグレードが成功したことを確認するには、次の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.1.3 Oracleホームからすべての管理ツールを実行する必要があります。 |
データベース・スキーマのアップグレードとインスタンスのアップグレードが成功したかどうかは、アップグレード・アシスタントの各アップグレード・ステータス画面に加え、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と表示されます。
BPELで捕捉されたフォルトについて、アップグレードした11gインスタンスのリカバリ・ステータスは、図8-2に示すようにNonrecoverableと表示されます。
