| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理 12c (12.1.3) E54311-05 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理 12c (12.1.3) E54311-05 |
|
|
前へ |
次へ |
この章の内容は次のとおりです。
SOAインフラストラクチャの詳細は、「SOAインフラストラクチャ・アプリケーションの概要」を参照してください。
「SOAインフラストラクチャの共通プロパティ」ページでは、次のSOAインフラストラクチャ・プロパティを構成できます。
Oracle SOA SuiteおよびOracle BPM Suiteのプロファイル
監査レベル
ペイロードの検証
フロー・インスタンスとフォルトのデータを取得する期間
Universal Description, Discovery, and Integration (UDDI)レジストリ
コールバック・サーバーとサーバーURL
分析、BPELセンサー、およびコンポジット・エディタ
Java Naming and Directory Interface (JNDI)データソース
Webサービス・バインディング・プロパティ
このレベルで設定したプロパティは、コンポジット・アプリケーションまたはサービス・エンジン・レベルで異なる監査レベル値を明示的に設定したコンポジットを除いて、すべてのデプロイ済SOAコンポジット・アプリケーションに影響を与えます。
SOAインフラストラクチャの追加の拡張プロパティは、システムMBeanブラウザを使用して構成できます。これらのプロパティには、この項で説明するように、「共通プロパティ」ページの「詳細SOAインフラ拡張構成プロパティ」リンクからアクセスするか、または「SOAインフラストラクチャ」メニューから「管理」→「システムMBeanブラウザ」→「アプリケーション定義のMBean」→「oracle.as.soainfra.config」の順に選択してアクセスできます。
SOAインフラストラクチャ・プロパティは、SOAインフラストラクチャに関連付けられたOracle Metadata Services (MDS)リポジトリに格納されています。Oracle SOA Suiteの場合、MDSリポジトリはデフォルトでコンテンツがデータベースに格納されるように構成されています。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... | SOAコンポジットのメニューから... |
|---|---|---|
|
|
|
「SOAインフラストラクチャの共通プロパティ」ページが表示されます。
注意:
一部のプロパティ・フィールドには、緑と赤の矢印アイコンが表示されています。これらのプロパティ(例: Server URL)を変更する場合は、SOAインフラストラクチャを再起動する必要があります。
「適用」をクリックせずにこのページを終了すると、変更は保存されません。
プロパティを変更した後に元の値にリセットする場合は、「元に戻す」をクリックします。
「SOAインフラストラクチャの共通プロパティ」ページのプロパティについては、次の項で説明します。
Oracle SOA Suiteプロファイルは、機能のサブセットを提供します。プロファイルを選択し、SOAサーバーを再起動して、選択したSOAテクノロジをアクティブ化します。ドメインで一度にアクティブにできるSOAプロファイルは1つのみです。SOAプロファイルには、次の利点があります。
SOAインフラストラクチャの全体的なメモリー・フットプリントを削減します。
Oracle SOA Suiteをよりモジュール性の高いプラットフォームにします。使用する必要がある機能のみをロードします。
サーバーの全体的なクラス・ロードを削減し、全体の起動時間を短縮します。
デフォルト・プロファイルはインストール時に自動的に設定されます。(Oracle BPM Suiteを使用しない) Oracle SOA Suiteのインストールでは、デフォルト・プロファイルはSOA Foundationです。Oracle BPM Suiteのインストールでは、デフォルト・プロファイルはBPM Basicです。Oracle SOA Suiteをリリース11gからリリース12cにアップグレードする場合、プロファイルはSOA Classicに設定されます。Oracle BPM Suiteをリリース11gからリリース12cにアップグレードする場合、プロファイルはBPM Classicに設定されます。
プロファイルは慎重に構成する必要がある高度な機能です。次の問題を理解しておいてください。
プロファイルの変更が正常に実行されないと、システムが不安定な状態になります。この操作は、資格のあるSOA管理者だけが実行する必要があります。
プロファイルの変更後、SOAサーバーを再起動して、様々なコンポーネント/アプリケーションのクラス・ローダーをリセットし、Oracle WebLogic Serverインスタンスがプロファイル変更で無効になったコンポーネントのリソースを保持しないようにする必要があります。
SOAプロファイルは全SOAテクノロジのサブセットを定義しているため、SOAコンポジット・アプリケーションの既存のインストール・ベースの正しいプロファイルを選択する際に注意してください。必要なSOAテクノロジをサポートしていない小規模なプロファイルを選択すると、コンポジット・デプロイメントやランタイムのエラーが発生する可能性があります。たとえば、プロファイルをSOA FoundationからBPEL Onlyに変更したときに、ヒューマン・タスクを含むビジネス・フロー・インスタンスがあると、コンポジットのヒューマン・タスクは機能しなくなります。
プロファイルは、Oracle WebLogic Server上でのみサポートされます。
プロファイルを変更すると、実行時にインストールされたテンプレート・セットを特定するためにドメインが問合せされ、この情報を使用して、現在のインストールでどのプロファイルが有効か決定されます。
プロファイルを変更する手順は、次のとおりです。
SOAインフラストラクチャでペイロード検証、監査証跡およびデフォルト問合せ期間を構成できます。次の表に、各プロパティの説明を示します。
監査証跡、ペイロード検証およびデフォルト問合せ期間を構成する手順は、次のとおりです。
SOAインフラストラクチャで実行されているSOAコンポジット・アプリケーションは、UDDIレジストリに統合できます。このUDDIレジストリでは、公開サービスの検索、およびサービスに関するメタデータの管理(セキュリティ、トランスポートまたはサービスのクオリティ)を実行するための標準ベースの基盤が提供されます。ニーズを満たす公開されたサービスを参照および選択できます。
「ユーザー」および「パスワード」プロパティは、UDDIレジストリが保護されている場合に適用できます。これらのプロパティは、Oracle Service Registry (OSR)のセキュアHTTP構成にのみ使用されます。「照会URL」プロパティはパブリックです。
UDDIレジストリ・プロパティを構成する手順は、次のとおりです。
「サーバーURL」セクションには、次のプロパティが表示されます。ここでプロパティを明示的に設定しない場合、プロパティ値は実行時にOracle WebLogic Serverクラスタ、Webサーバーまたはローカル・サーバーのプロパティを問い合せて決定されます。
コールバック・サーバーおよびサーバーURLを構成する手順は、次のとおりです。
「分析とセンサーの構成」セクションでは、分析、BPELセンサーおよびコンポジット・センサーの収集を管理できます。デフォルトでは、すべての選択が有効です。
「SOAインフラストラクチャの共通プロパティ」ページで選択を無効または有効にする場合は、次の優先順位に注意してください。
共通プロパティ・ページで選択を無効にすると、すべてのSOAコンポジット・アプリケーションでその選択に関するデータのコレクションが無効になります。たとえば、共通プロパティ・ページでコンポジット・センサーを無効にする場合、この変更の後に作成された任意のフロー・インスタンスに関するコンポジット・センサーの詳細は収集されません。
共通プロパティ・ページで選択を有効にすると、個々のSOAコンポジット・アプリケーション・レベルでその設定を無効にすることができます。たとえば、共通プロパティ・ページでコンポジット・センサーを有効にし、ホームページの「設定」→「分析とセンサーの有効化/無効化」で個々のSOAコンポジット・アプリケーション(LoanFlowなど)のコンポジット・センサーを無効にする場合、この変更の後にLoanFlow SOAコンポジット・アプリケーションの任意のインスタンスに対してコンポジット・センサーの詳細は収集されません。ただし、他のすべてのフロー・インスタンスはコンポジット・センサーの詳細を収集し続けます。
分析およびセンサーを構成する手順は、次のとおりです。
個々のSOAコンポジット・アプリケーションでの分析およびセンサーの設定の詳細は、「分析、BPELセンサーおよびコンポジット・センサー・データの収集の無効化および有効化」を参照してください。
データ・ソースを使用すると、データベース・サーバーへの接続を取得できます。
データ・ソースおよびWebサービス・バインディング・プロパティを構成する手順は、次のとおりです。
「データソース」セクションには、次のプロパティが表示されます。
拡張パラメータを変更するには、「詳細SOAインフラ拡張構成プロパティ」をクリックします。これにより、「システムMBeanブラウザ」が開きます。表示されるプロパティの一部を次に示します。各プロパティには説明が記載されています。
AuditConfig: BPELメッセージ・リカバリのステータス。このプロパティには、次のキーが含まれています。
excludeBpelMaxCreationTimeキー: リカバリが必要なメッセージを除外する期間を設定できます。詳細は、「SOAインフラストラクチャまたは個々のパーティションの全体的ステータスの監視」を参照してください。
CreateWSCallTrackingMBean: Webサービス・コールの経過時間を追跡するMBeanの作成を制御します。経過時間のしきい値を超えると、インシデントが作成されます。trueに設定した場合は、監視を作成できます。この設定は、SOAインフラストラクチャ内のすべてのSOAコンポジット・アプリケーションに適用されます。詳細は、「監視および通知の作成」を参照してください。
GlobalTxMaxRetry: 呼出し例外を再試行できる最大回数。
GlobalTxRetryInterval: 呼出し例外の再試行間隔(秒数)。
HttpServerURL: WSDLファイルでプロセスのSOAPアドレスの一部として公開されるHTTPプロトコルURL。
HttpsServerURL: WSDLファイルでプロセスのSOAPアドレスの一部として公開されるHTTPSプロトコルURL。
KeystoreLocation: Oracle SOA Suiteキーストアへのパス。
UddiCacheLifetime: UDDIエンドポイント・キャッシュの存続期間。
メンテナンスまたは構成変更後の再起動のために、Oracle Enterprise Manager Fusion Middleware ControlでSOAインフラストラクチャを停止して起動できます。このことを行うには、SOAインフラストラクチャがインストールされている管理対象サーバーを停止して起動します。これにより、管理対象サーバーとSOAインフラストラクチャの両方が再起動されます。
注意:
11g リリース1 (11.1.1.4.0)からは、ナビゲータの「soa-infra」メニューからSOAインフラストラクチャを停止および起動できなくなりました。
管理サーバーのみが含まれ、管理対象サーバーが含まれない、開発者用の構成を使用することもできます。
サーバー起動時の問題の詳細は、「サーバーのトラブルシューティング」を参照してください。
管理対象サーバーとSOAインフラストラクチャを起動および停止する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| 「WebLogicドメイン」メニューから | ナビゲータの「WebLogicドメイン」フォルダから |
|---|---|
|
|
管理対象サーバーとSOAインフラストラクチャを停止するには、「停止」を選択します。
管理対象サーバーとSOAインフラストラクチャの停止の確認が表示されたら、「OK」をクリックします。
停止の完了を待ちます。
管理対象サーバーとSOAインフラストラクチャを起動するには、「起動」を選択します。
ノード・マネージャによる管理対象サーバーの停止および起動の詳細は、Oracle WebLogic Serverノード・マネージャの管理を参照してください。
WLSTコマンドによる管理対象サーバーの停止および起動の詳細は、Oracle Fusion Middlewareの管理を参照してください。
SOAインフラストラクチャの停止後、SOAコンポジット・アプリケーションの状態は、コンポジットが停止していることを示すように更新されません。コンポジットにアクセスしようとすると、コンポジット詳細を取得できない旨のエラー・メッセージが表示されます。
soa-infra runtime connection error An error happened while connecting to
soa-infra runtime at t3://address:8001/soa-infra.
このメッセージによって、システム内で別の問題が発生していると考える可能性があります。しかし、この場合はそうではありません。
このメトリックは、コンポジットが有効かどうか、SOAインフラストラクチャの起動に依存しているかどうかを示すため、これらのコンポジットの状態は「稼働中」また、場合によっては「保留」と表示されます。さらに、クラスタ内の他の管理対象サーバーではコンポジットは依然としてアクティブで、リクエストを受信できます。
アダプタ・エンドポイントがあるSOAコンポジット・アプリケーションがリタイア状態にある場合は、次のアクションを実行した場合にエンドポイントはアクティブになりません。
SOAインフラストラクチャの再起動
SOAコンポジット・アプリケーションのアクティブ化
これは、ファイルやレコードなどがエンドポイント・アダプタによって取得されないためです。回避策として、SOAインフラストラクチャの再起動後にSOAコンポジット・アプリケーションを再デプロイします。
cwallet.ssoにSOAマップがある場合は、SOAインフラストラクチャの起動を試行すると、次のようなエラー・メッセージが表示されます。
Caused By: java.security.UnrecoverableKeyException: Password verification
failed
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1185)
at oracle.j2ee.ws.saaj.util.SSLUtil.loadKeyStore(SSLUtil.java:73)
at
oracle.j2ee.ws.saaj.util.SSLUtil.getKeyManagerFactory(SSLUtil.java:88)
at oracle.j2ee.ws.saaj.util.SSLUtil.getKeyManagers(SSLUtil.java:97)
at
oracle.j2ee.ws.saaj.util.SSLUtil.createSSLSocketFactory(SSLUtil.java:50)
at
oracle.integration.platform.common.SSLSocketFactoryManagerImpl.getSSLSocketFac
tory(SSLSocketFactoryManagerImpl.java:58)
at oracle.fabric.common.wsdl.WSDLManager.init(WSDLManager.java:356)
at oracle.fabric.common.wsdl.WSDLManager.<init>(WSDLManager.java:101)
at
oracle.fabric.common.metadata.MetadataManagerImpl.getWSDLManager(MetadataManag
erImpl.java:283)
at
oracle.fabric.composite.model.CompositeModel.getWSDLManager(CompositeM
この問題を解決する手順は、次のとおりです。
「SOAインフラストラクチャ・プロパティの構成」で説明されているように、「SOAインフラストラクチャの共通プロパティ」ページ以外に、Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」でSOAインフラストラクチャの「ServerURL」プロパティ・ポートを変更することもできます。
ポートを変更するときは、次の点に注意してください。
SOAインフラストラクチャと管理対象のOracle WebLogic Serverのポート番号が異なる場合は、Oracle BPM Worklistに接続しようとするとConnectExceptionエラーが発生します。これらのポート番号が一致していることを確認してください。
Oracle WebLogic Server管理コンソールからSOAインフラストラクチャ・ポートを変更することはできません。Oracle WebLogic Server管理コンソールからは、管理対象のOracle WebLogic Serverのポートのみを変更できます。
SOAインフラストラクチャのポートを変更する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... | SOAコンポジットのメニューから... |
|---|---|---|
|
|
|
「名前」列で「ServerURL」をクリックします。
「属性: ServerURL」ページが表示されます。
「値」フィールドで、ポートを変更します。
「適用」をクリックします。
Oracle WebLogic Server管理コンソールで、管理対象のOracle WebLogic Serverのポートを同じ値に変更します。
Oracle WebLogic Serverクラスタの前にロード・バランサを使用する環境では、「ServerURL」プロパティのホストとポートは、Oracle WebLogic Serverのホストとポートと異なっても構いません。これは、Oracle WebLogic Serverクラスタ内の管理対象サーバー間でロード・バランサがリクエストを分散するエンタープライズ・デプロイメント環境では一般的です。詳細は、Oracle SOA Suiteエンタープライズ・デプロイメント・ガイドを参照してください。
Oracle SOA Suiteのコンポーネントではログ・ファイルが生成され、起動と停止情報、エラー、警告メッセージ、HTTPリクエストに関するアクセス情報および追加情報を含むすべてのタイプのイベントを記録するメッセージが格納されます。
ログ・ファイルを構成するには:
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「ログ構成」ページに、次の詳細が表示されます。
「ビュー」リスト。情報を表示するロガーのタイプを選択します。
永続: コンポーネントが起動するとアクティブになるロガー。このログ出力の構成詳細はファイルに保存され、ログ・レベルはコンポーネントの再起動後も維持されます。
アクティブ・ランタイム: 実行時に自動的に作成され、特定の機能領域が実行されるとアクティブになるロガー(例: oracle.soa.b2b、oracle.soa.bpel)。このログ出力のログ・レベルはコンポーネントの再起動後は維持されません。
ログ出力名、ログ・ファイルに書き込む情報の量とタイプを設定するOracle Diagnostic Logging (ODL)レベル、ログ・ファイルおよびログ・レベルの状態が表示される表。
検索基準(たとえば、soa)を指定して、「検索」アイコンをクリックします。
Oracle SOA Suiteロガーが表示されます。
このページで次のログ・ファイル・タスクを実行します。
「ロガー名」列で、ロガー名を開きます。これによって、コンポーネント内の特定のロギング・レベルを指定できます。
「Oracle Diagnostic Loggingレベル」列で、ログ・ファイルに書き込む情報のレベルとタイプを選択します。
「ログ・ファイル」列で、ログ・ファイル構成を作成および編集する特定のログ・ファイルをクリックします。
ODLログ・ファイルの詳細およびログ・ファイルに書き込むロギング情報のレベルとタイプの詳細は、Oracle Fusion Middlewareの管理を参照してください。
「ログ・ファイル」タブをクリックします。
このページを使用して、ログ・ファイル構成を作成および編集できます。ログ・ファイル構成には、ログ・メッセージが記録されるログ・ファイル、ログ・メッセージのフォーマット、使用されるローテーション・ポリシー、およびログ・ファイル構成クラスに基づく他のパラメータが含まれます。
ロギング・レベルおよび表示するOracle SOA Suiteログ・ファイルの設定の詳細は、「トラブルシューティングのためのロギング・レベルの設定」を参照してください。
soa-diagnostic.logファイルのoracle-soa-handlerログ・ハンドラ・プロパティには、SOA_Domain/config/fmwconfig/servers/server_soa/logging.xmlファイルに指定されるエンコーディング・プロパティがありません。かわりに、soa-diagnostic.logファイルにはオペレーティング・システムのデフォルトのエンコーディング・フォーマットで書き込まれます。このため、次の問題が発生する場合があります。
ロギング情報はsoa-diagnostic.logにサーバーのデフォルトのエンコーディング・フォーマットで書き込まれるため、ASCII以外のエラー・メッセージは読み取れなくなる場合があります。
Windowsオペレーティング・システムでは、デフォルトのエンコーディング・フォーマットで書き込むことによって、ASCII以外のデータが失われる場合があります。
この問題を回避するには、logging.xmlファイルで、oracle-soa-handlerログ・ハンドラ・プロパティに対して値UTF-8を指定します。
<?xml version='1.0'?> <logging_configuration> <log_handlers> <log_handler name='wls-domain' class='oracle.core.ojdl.weblogic.DomainLogHandler' level='WARNING'/> <log_handler name='oracle-soa-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'> <property name='path' value='c:\soa1210.1411\user_ projects\domains\soa/servers/server_soa/logs/soa-diagnostic.log'/> <property name='maxFileSize' value='10485760'/> <property name='maxLogSize' value='104857600'/> <property name='supplementalAttributes' value='J2EE_APP.name,J2EE_ MODULE.name,WEBSERVICE.name,WEBSERVICE_PORT.name,composite_instance_id,component_ instance_id,composite_name,component_name'/> <property name='encoding' value='UTF-8'/> </log_handler> </log_handlers> ...
これで、ログ・ファイルはODLを使用して書き込まれます。ログ・ファイルの内容は、Oracle Enterprise Manager Fusion Middleware Controlから表示できます。
ロギングの詳細は、Oracle Fusion Middlewareの管理を参照してください。
Oracle SOA Suiteでは、APIコールのパフォーマンス・メトリックをログに記録できます。作成されたOracle Enterprise Manager Fusion Middleware Controlページに対する高コストのAPIコールのパフォーマンスをトレースできます。このトレースは、APIコールが効率的に実行されない場合に役立ちます。他の情報とともにview idが次のファイルにログとして記録されます。
FMW_HOME/user_projects/domains/domain_name/servers/weblogic_name/logs/weblogic_name-soa-tracking.trc
たとえば、weblogic_name-soa-tracking.trcファイルに関連付けられたルート・ロブ出力でFINEレベルのロギングを有効化して、診断対象の問題を再生してからロギング・レベルをSEVEREに戻すことができます。ログの内容を分析して、Oracle SOA Suiteで実行された元の操作を精密に指摘できます。
パフォーマンスの問題を診断するロギングを構成する手順は次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「ログ構成」ページが表示されます。
「ロガー名」列で、oracle.soa > oracle.soa.sql.trc.fabricを開きます。
ロギング・レベルをFINEに設定します。
「適用」をクリックします。
APIコールを生成したOracle Enterprise Manager Fusion Middleware Controlページは、weblogic_name-soa-tracking.trcファイルにログ記録されます。この例では、/ai/soa/composite (SOAコンポジット・アプリケーションのホーム・ページ)がページとして特定されます。
[2012-08-07T23:21:04.488-07:00] [soa_server1] [TRACE:32] []
[oracle.soa.sql.trc.fabric.toplink_session.tracking_session] [tid:
[ACTIVE].ExecuteThread: '1' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: weblogic] [ecid:
6fec0e67fbf81939:-7d87fd84:138e67064fb:-8000-0000000000000dd6,1:24469]
[SRC_CLASS: oracle.integration.platform.instance.store.ToplinkSessionLogger]
[APP: soa-infra] [SOA.toplink.session_name: tracking_session]
[SOA.logging.category: query] [SOA.call_origin_category: /ai/soa/composite]
[SOA.call_origin: em] [SRC_METHOD: log] execute_query
デフォルトのSOAインフラストラクチャのデータ・ソースは常にXAに対応しています。データ・ソースがカスタム・ドライバのサポートを必要とする場合は、Oracle WebLogic Serverでドライバ名を変更する必要があります。
次のいずれかの方法で、ドライバ名を変更する手順は、次のとおりです。
Oracle WebLogic Server管理コンソールで編集します。
Oracle WebLogic Server管理コンソールにログインします。
ページの左側の「ドメイン構造」で、「サービス」→「データ・ソース」→「SOADatasource」→「接続プール」の順に選択します。
「ドライバ・クラス名」で、値をカスタム・データ・ソース(例: oracle.jdbc.xa.client.myDataSource)に変更します。
サーバーを再起動します。
soaDataSource-jdbc.xmlファイルを編集します。
Oracle WebLogic ServerでsoaDataSource-jdbc.xmlファイルを開きます。
SOADataSourceドライバ名を.jdbc.OracleDriverからoracle.jdbc.xa.client.myDataSourceに変更します。
<?xml version="1.0" encoding="UTF-8"?>
<jdbc-data-source
/. . .
. . .
/ <name>SOADataSource</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:myhost.us.example.com:1537:co0yf470</url>
<driver-name>*oracle.jdbc.xa.client.myDataSource*</driver-name>
<properties>
<property>
<name>user</name>
<value>fusion_soainfra</value>
</property>
</properties>
/ . . .
. . ./
</jdbc-driver-params>
/. . .
. . ./
</jdbc-data-source>
XAデータ・ソースのデフォルトのXAトランザクション・タイムアウト値は、0秒です。このデフォルト値はOracle WebLogic Server管理コンソールで変更できます。次の手順に従います。
XAデータ・ソースにデフォルト以外のXAトランザクション・タイムアウト値を指定する手順は、次のとおりです。
クライアントのリクエストが高い頻度で届くと、リクエストはキューに収集され、データベース接続が使用できるまで待機します。受信リクエストの同時処理数を増やすために、次のプロパティを変更できます。
Oracle WebLogic Server管理コンソールのSOADataSourceプロパティ
システムMBeanブラウザのSOAMaxThreadsConfigプロパティによる、最大スレッド数を計算するために使用される割合
SOAMaxThreadsConfigのincomingRequestsPercentageおよびinternalProcessingPercentageの要素は、処理タスクの組合せがデータベース接続数を超えにくくするために定義されます。最大スレッドに関するこれらの制約に使用されるスレッド制限数は、Oracle WebLogic Server管理コンソールのSOADataSourceプロパティの最大接続数値に基づいて計算されます。
SOADataSourceプロパティの最大接続数を変更すると、バックグラウンド・プロセスが開始され、incomingRequestsPercentageおよびinternalProcessingPercentageの両方の要素に定義された最大スレッド数が再調整されます。自動調整の操作を続行できるようにするには、Oracle WebLogic Serverの構成編集ロックを取得する必要があります。すでにロックを取得している場合は、ロックを解放して自動調整を続行できるようにします。
内部処理と受信リクエストに割当済の割合は調整できます。割当のデフォルトの割合では、内部処理タスクがデータベース接続のプール・サイズの65%までを使用できます。受信リクエストは、データ・ソース・プール・サイズの15%を使用し、残りの20%分はアダプタとイベント配信ネットワークの処理用です。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」で、「サービス」→「データ・ソース」の順に選択します。
ページの上部で、「接続プール」をクリックします。
「名前」列で、「SOADataSource」を選択します。
「最大接続数」フィールドの値を更新します(たとえば、200スレッドの負荷にあわせて300など)。デフォルト値は50です。
「保存」をクリックします。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... | SOAコンポジットのメニューから... |
|---|---|---|
|
|
|
「詳細SOAインフラ拡張構成プロパティ」をクリックします。
「SOAMaxThreadsConfig」を展開します。
使用環境に適した変更を行います。
たとえば、これらのスレッド値にあわせて次のように変更します。
incomingRequestsPercentage: 20 (10スレッドにあわせて)
internalBufferPercentage: 50 (25にあわせて)
internalProcessingPercentage: 30 (15スレッドにあわせて)
「適用」をクリックします。
プロパティを変更した後に元の値にリセットする場合は、「元に戻す」をクリックします。
ローカルの最適化とは、2つのSOAコンポジット・アプリケーションが同じSOAサーバー(JVM)にある環境で、直接Java呼出しによってSOAコンポジット・アプリケーションが別のSOAコンポジット・アプリケーションを呼び出すプロセスです。
一般的に、直接Java呼出しはSOAP over HTTPコールより効率的です。したがって、直接Java呼出しの条件を満たしている場合は常に、Oracle SOA Suiteでは、同じ場所に存在するコンポジット間のサービス・コールを最適化します。
Oracle SOA Suiteでは、ローカルの最適化が可能かどうかを判断するために、次の条件チェックを実行します。
コンポジット間呼出しである必要があります。これは最も基本的な条件で、クライアント・サービスとターゲット・サービスの両方が同じSOAインフラストラクチャ(つまり、同じSOAサーバー)に基づいて実装されている場合に、直接Javaコールが可能になります。
参照(ターゲット)サービスを実装するコンポジットがアクティブである必要があります。この条件ではターゲット・コンポジットが起動して実行中であることが必要で、これにより、参照サービスが使用可能であることが保証されます。
注意:
ターゲット・コンポジットの状態は「オン」および「アクティブ」である必要があります。状態が「停止済」または「リタイア」の場合は、ローカルの最適化の対象になりません。
クライアント・コンポジットとターゲット・コンポジットは同じサーバー上に存在する必要があります。これは、直接Java呼出しの明白な要件です。また、Oracle SOA Suiteで、(クライアント・コンポジットがデプロイされている)サーバーのホスト構成に対して、参照(ターゲット)サービス・エンドポイントURIで指定したホストとポート値を比較するのは重要なステップです。ホストとポート値が一致する場合は、クライアント・コンポジットとターゲット・コンポジットが同じサーバー上に存在すると判断できます。ただし、スタンドアロン・サーバー設定とクラスタ・サーバー設定の両方を使用し、ロード・バランサ構成が必要になる可能性がある場合、この比較は必ずしも単純ではありません。したがって、次に、すべてのプラットフォームでサーバー構成が正しいことを確認する条件チェックをステップごとに示します。
「SOAインフラストラクチャ・プロパティの構成」で説明したように、「SOAインフラストラクチャの共通プロパティ」ページで「サーバーURL」構成プロパティ値をチェックします。
指定されていない場合は、クラスタMBeanのFrontendHostおよびFrontendHTTPPort (また、SSLが有効化されている場合はFrontendHTTPSPort)の構成プロパティ値をチェックします。
指定されていない場合は、Oracle WebLogic Server MBeanからFrontendHostおよびFrontendHTTPPort (または、SSLが有効な場合はFrontendHTTPSPort)構成プロパティ値をチェックします。
指定されていない場合は、DNS解決されたINETアドレスのlocalhostを使用します。
参照サービス・エンドポイントURLで指定したポート値が、構成されたサーバー・ポート値と一致するかどうかをチェックします。エンドポイントURLにポート値が指定されていない場合、Oracle SOA Suiteでは、HTTP URLの場合は80、HTTPS URLの場合は443を使用します。
ポート値が一致する場合、サーバーURL、つまり、http(s)://host:port(hostとportは前のチェックから取得)が、参照エンドポイント・アドレスのサーバーURLと比較されます。URLは正規値に解決され、エンドポイントURLホストがlocalhostまたは127.0.0.1の場合もこの比較が行われます。
Oracle SOA Suiteでは、サーバーURLの比較で値trueが返された場合、コンポジットは同じ場所に存在すると判断します。
セキュリティ・ポリシー構成は、クライアント・コンポジットとサーバー・コンポジットの一方または両方に適用されている場合、ローカルの最適化に対応している必要があります。ポリシー構成およびローカルの最適化については、「コンポジット間呼出しでのポリシー・アタッチメントおよびローカルの最適化」を参照してください。
「フローのトレース」ページの「トレース」セクションで、コールによってローカルの最適化が行われたかどうかを確認できます。図3-1に示すように、呼出し元コンポジットと呼出し先コンポジットの参照とサービスに対して(ローカル呼出し)というテキストが表示されます。
「フローのトレース」ページの詳細は、「ビジネス・フロー・インスタンスのフロー・トレースの監視」を参照してください。
ローカルの最適化をオーバーライドまたは強制するために、2つの構成プロパティが用意されています。
oracle.webservices.local.optimization
デフォルトでは、Oracle SOA Suiteはローカルの最適化を実行します。ただし、composite.xmlファイルのoracle.webservices.local.optimizationバインディング・プロパティを使用してこの動作をオーバーライドできます。このプロパティをfalseに設定すると、ローカルの最適化は実行されず、コンポジット間コールはSOAP and HTTPを介して実行されます。必要に応じて、このプロパティを使用してください。このプロパティの設定については、「コンポジット間呼出しでのポリシー・アタッチメントおよびローカルの最適化」を参照してください。
oracle.soa.local.optimization.force
oracle.soa.local.optimization.forceプロパティをtrueに設定して、oracle.webservices.local.optimizationプロパティをオーバーライドすると、最適化を強制的に実行できます。このプロパティは、次のシナリオの場合に使用します。
サーバー構成がかなり複雑で(たとえば、イントラネットにファイアウォールやプロキシ設定がある場合)、「ローカルの最適化を使用するための条件チェック」で説明した同じ場所に存在するかどうかのチェックで正しい結果が得られない可能性がある場合。
ユーザーがローカルの最適化のセマンティクスを十分に理解し、システム設定がローカルの最適化に適しており、ローカルの最適化が確実に効率的である場合。
この項で説明していないこれ以外のシナリオでも、最適化を強制する場合があります。
注意:
oracle.webservices.local.optimizationをfalseに設定し、oracle.soa.local.optimization.forceをfalseに設定すると、ローカルの最適化は実行されません。
oracle.soa.local.optimization.forceプロパティのデフォルト値はfalseです。このプロパティをtrueに設定すると、Oracle SOA Suiteでは「ローカルの最適化を使用するための条件チェック」で説明した条件チェックをスキップしますが、ポリシー構成チェックは例外で、このチェックはサービス・コールの整合性を確認して強制するために必要とされます。
Oracle SOA Suiteで常にこのプロパティの設定が優先されることは、このプロパティに関する重要事項の1つです(ポリシー・チェックによって最適化が可能になる場合)。ただし、ローカル呼出しがアプリケーション以外のフォルトまたは例外によって失敗した場合(多くの場合、直接Java呼出しに関連するランタイム・エラー)、構成されたエンドポイントでの後続の呼出し、およびエンドポイントに構成されたすべての有効なエンドポイント・アドレスで、この設定の値が無視されます。
oracle.soa.local.optimization.forceプロパティを有効にする手順は、次のとおりです。
呼び出されるコンポジットのreferenceセクションに、oracle.soa.local.optimization.forceをバインディング・コンポーネント・レベルのプロパティとして追加します。たとえば、コンポジットcomp_comp2がcomp_comp1を呼び出す場合は、comp_comp2のcomposite.xmlファイルのreferenceセクションでこのプロパティを定義します。
<reference name="Service1"
ui:wsdlLocation="http://localhost:8001/soa-infra/services/default/comp_
comp1!1.0/BPELProcess1.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/comp_comp/comp_
comp1/BPELProcess1#wsdl.interface(BPELProcess1)"
callbackInterface="http://xmlns.oracle.com/comp_
comp/comp_comp1/BPELProcess1#wsdl.interface(BPELProcess1Callback)"/>
<binding.ws port="http://xmlns.oracle.com/comp_comp/comp_
comp1/BPELProcess1#wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)"
location="http://localhost:8001/soa-infra/services/default/comp_
comp1!1.0/bpelprocess1_client_ep?WSDL">
<property name="oracle.webservices.local.optimization">false</property>
<property name="oracle.soa.local.optimization.force">true</property>
</binding.ws>
参照サービス・コールバックに対してローカル最適化を強制する手順は次のとおりです。
対応する参照サービスの<service>定義で、<callback>要素にoracle.soa.local.optimization.forceプロパティを追加します。
たとえば、composite1がcomposite2を呼び出す場合、compsite2の<service>定義に、次のようにoracle.soa.local.optimization.forceプロパティを追加します。これにより、composite2からcomposite1への非同期コールバックのローカルの最適化が強制されます。
<service ui:wsdlLocation="composite2.wsdl"> . . . <callback> <binding.ws port="http://xmlns.oracle.com/example#wsdl.endpoint(FooService/FooPort)"> <property name="oracle.soa.local.optimization.force">true</property> </binding.ws> </callback> </service>
最適化、およびWS-AtomicTransaction (WS-AT)トランザクションの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の最適化有効時にサポートされないWS-ATトランザクションに関する項を参照してください。
Oracle SOA Suiteでは、ローカルの最適化かSOAP処理かを決定するたびにNOTIFICATION:1(INFO)レベルのロギングが実行されます。詳細またはデバッグ情報が必要な場合は、Oracle Enterprise Manager Fusion Middleware Controlでoracle.integration.platform.blocks.localおよびoracle.integration.platform.blocks.soapロガーをTRACE:1(FINE)レベルで設定します。
このローカル最適化コールのユースケースで説明する内容は次のとおりです。
コンポジットAが同じサーバー上にあり関連付けられているコンポジットBをコールする環境でコンポジットBに到達不能な場合にローカル最適化コールがどのように機能するか(表3-1)。
Oracle WebLogic Serverがリスニングするポートではないポート値でロード・バランサ・アドレスを作成した場合にどのようになるか(表3-2)。
表3-1 コンポジットに到達不能の場合のローカル最適化コール
| シナリオ | 説明 |
|---|---|
ローカル最適化コールの失敗時にどのようになるか。 |
ローカル最適化コールの試行前にコンポジットBのチェックが実行されます。 このチェックに失敗した場合(コンポジットBに到達不能)、SOAインフラストラクチャで例外がスローされBPELフォルトに変換されます。このBPELフォルトには、コンポジットBが到達不能であることに関する情報が組み込まれます。 |
関連付けられたコールの再試行が可能であるか。 |
基本チェックの実行後にローカル最適化コールが試行されます。このコールが失敗すると、SOAPを介して再起動されます。ただし、SOAPを介した再起動を行うには次の条件に合致している必要があります。
|
関連付けられたコールの再試行が可能な場合(たとえば、コンポジットまたはエンドポイントでフォルトのポリシーが再試行に設定されている場合など)、コールが再度最適化されるか、ローカル・コンテナの終了してロード・バランサへのアクセスを試行するか。 |
ローカルでの送信の試行時にコールが初めて失敗した場合は、その情報がキャッシュされます(つまり、ローカルでの失敗)。 その後のコールについては、コールがSOAPを介して送信されます(このときはローカル最適化コールの再試行は行われません)。 |
表3-2 Oracle WebLogic Serverがリスニングするポートではないポート値でのロード・バランサ・アドレスの作成
| シナリオ | 説明 |
|---|---|
Oracle WebLogic Serverがリスニングするポートではないポート値でロード・バランサ・アドレスを作成する場合に、ロード・バランサのアドレスとしてサーバーURL (SOAインフラストラクチャの「共通プロパティ」ページ)、およびフロントエンド・ホスト/ポート(Oracle WebLogic Serverの「HTTP」タブ内)を指定できますか。 |
はい。サーバーURL、またはフロントエンド・ホスト/ポートは、ローカル最適化ルールのアドレスの識別子としてネットワーク・リクエストの送信先の実際のアドレスより詳細度が高くなります。 |
コールを実行する際にローカル最適化でポートを使用しませんか(たとえば、ポート |
使用します。このポートは、ローカル・コールを実行するために、ターゲットが関連付けられているかどうかを調べる比較の実行のみに使用されます。 |
構成プランはコンポジット別です。このため、SOAコンポジット・アプリケーションを環境間で移動すると、構成プランのそれぞれで一部の値の置き換えが必要になります。各プランの値の置換を回避するため、Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジット・アプリケーションの特定のURIにグローバル・トークン変数を定義できます。
グローバル・トークン変数には、次の利点があります。
複数のSOAコンポジット・アプリケーションが特定のサーバー上でホストされる複数の異なるサービスを起動する場合は、単一のグローバル・トークン変数を使用して、コンポジット間でこのサーバーを参照できます。個別の構成プランが不要になり単一のトークン値セットを更新すれば済むため、開発作業が簡素化されます。たとえば、10個の異なる構成プランでサーバーのホスト名を更新するかわりに、グローバル・トークン変数を使用してこの名前をグローバルに設定します。この値は、デプロイされたSOAコンポジット・アプリケーションのcomposite.xmlファイルのbinding.ws要素内のホスト名のグローバル・トークン変数の値を取得および置換します。
グローバル・トークン変数を使用することは、実行時サーバーにデプロイされるOracle SOA Suiteメタデータには環境固有値が含まれていないことを意味します。
クラスタ環境では、グローバル・トークン変数の変更が管理サーバーで実行され、管理対象サーバーのすべてに伝播されます。
グローバル・トークン変数の管理には、次のオプションを使用できます。
Oracle Enterprise Manager Fusion Middleware Controlの「トークン構成」ページを使用して、グローバル・トークン変数の管理(作成、編集および削除)を行います。
トークンは、ws.bindingロケーションのホスト、ポート、プロトコル、およびreferenceタグ内のすべてのプロパティのみでサポートされます。
serverURLという名前の事前定義のグローバル・トークン変数を使用します。
注意:
ダッシュなどの特殊文字を含むトークン名(例: host-name)は作成しないでください。特殊文字があるとSOAコンポジット・アプリケーションの起動時にNull Pointer Exceptionエラーが発生して起動が失敗します。
作成できるのは、composite.xmlファイルで使用されるトークンのみです。
composite.xmlファイルのimport要素でのグローバル・トークン変数の使用はサポートされません。
「トークン構成」ページでは、グローバル・トークン変数を管理できます。このページでは、次の操作を実行できます。
ローカルmdm-url-resolver.xmlファイルからの変数をシステムのmdm-url-resolver.xmlファイルに追加して、必要に応じて編集します。
システムのmdm-url-resolver.xmlファイル内の変数を管理します。
「トークン構成」ページでグローバル・トークン変数を管理する手順は次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「トークン構成」ページが表示されます。
実行するグローバル・トークン変数の構成アクションを選択します。
ローカル・ファイルの変数を追加するには、次の手順を実行します。
「トークンの一括追加」をクリックします。
「参照」をクリックして、ローカル・ファイル・システムからmdm-url-resolver.xmlファイルを選択します。アップロードを成功させるには、ローカル・ファイルが次の書式に従っている必要があります。この例では、ホスト名、ポートおよびプロトコルにグローバル・トークン変数が定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>
URL Resolver file used by the Metadata manager to resolve $<variable>
in URLs
</comment>
<entry key="host">mymachine.us.example.com</entry>
<entry key="port">8001</entry>
<entry key="protocol">http</entry>
</properties>
「追加」をクリックします。
ローカル・ファイルのコンテンツが、システムのmdm-url-resolver.xmlファイルのコンテンツに追加されます。システムのmdm-url-resolver.xmlファイルに既存のグローバル・トークン変数は上書きされません。
変数の編集が必要な場合は、「構成ファイルの変更」をクリックして、手順4に進みます。
システムのmdm-url-resolver.xmlファイル内の変数を管理するには、次の手順を実行します。
「構成ファイルの変更」をクリックします。
最初に「トークンの一括追加」を選択してファイルをアップロードした場合は、ローカルmdm-url-resolver.xmlファイルとシステムのmdm-url-resolver.xmlファイルのグローバル・トークン変数のトークン名と値が表書式で表示されます。列は、昇順または降順で並べ替えることができます。変数に重複はなく、ローカル・ファイルの変数がシステム・ファイルに既存の場合は表示されません。
最初に「構成ファイルの変更」を選択した場合は、システムのmdm-url-resolver.xmlファイル内のグローバル・トークン変数がトークン名と変数が表書式で表示されます。
管理対象のグローバル・トークン変数を選択して、特定のタスクを実行します。
注意:
変更を行ったら、「保存」をクリックしてから、「トークンの一括追加」モードに切り替えるか、このページから別のページにナビゲートする必要があります。これらのアクションを実行するとコミットされていない変更が失われます。
| 要素 | 説明 |
|---|---|
 |
|
 |
|
 |
|
 |
|
 |
|
トークン値の追加、変更、または削除の実行後は、SOAインフラストラクチャを再起動してください。詳細は、「管理対象サーバーとSOAインフラストラクチャの停止と起動」を参照してください。
更新内容がクラスタ全体に伝播されます。
実行時にグローバル・トークン変数を置換する方法の詳細は、「実行時にグローバル・トークン変数を置換する方法」を参照してください。
注意:
Oracle Enterprise Manager Fusion Middleware Controlにグローバル・トークン変数を使用するSOAコンポジット・アプリケーションをデプロイすると、システムのmdm-url-resolver.xmlファイルですべてのトークンが構成されていることを確認するように求める警告メッセージが表示されます。詳細は、「SOAコンポジット・アプリケーションのデプロイ」を参照してください。
「トークン構成」ページで指定したトークン名と置換値が、次のディレクトリにあるシステムのmdm-url-resolver.xmlファイルに追加されています。
$MIDDLEWARE_HOME/user_projects/domains/domain_name/config/fmwconfig/
mdm-url-resolver.xml
たとえば、「トークン構成」ページを使用して、4つのグローバル・トークン変数名と値が定義されているとします。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>
URL Resolver file used by the Metadata manager to resolve $<variable> in
URLs
</comment>
<entry key="myprotocol">http</entry>
<entry key="myhost">mymachine.us.example.com</entry>
<entry key="myport">8001</entry>
</properties>
デプロイされたSOAコンポジット・アプリケーションのcomposite.xmlが実行時にロードされ、ファイル内のURIによって指定されたリソースが取得されると、URI内のグローバル・トークン変数の値が「トークン構成」ページで指定された値に置き換えられます。
たとえば、次のcomposite.xmlファイルは、これらのトークンを使用してbinding.ws要素のURIを指定します。
<?xml version="1.0" encoding="UTF-8"?>
<composite...>
. . .
. . .
<reference name="Service" ui:wsdlLocation="...">
. . .
<binding.ws port="..."
location="${myprotocol}://${myhost}:${myport}/soa-infra/services/default/
mycomposite/bpelprocess1_client_ep?WSDL" soapVersion="1.1">
</binding.ws>
</reference>
. . .
</composite>
実行時にWSDL定義ファイルが取得される場合、トークンはmdm-url-resolver.xml構成ファイル内の値によって置き換えられ、次のURIが作成されます。
http://mymachine.us.example.com:8001/soa-infra/services/default/myComposite/ bpelprocess1_client_ep?WSDL
リソースURLではserverURLという名前の事前定義のグローバル・トークン変数を使用できます。このトークンは、実行時にOracle Enterprise Manager Fusion Middleware ControlのSOAインフラストラクチャの「共通プロパティ」ページの「サーバーURL」プロパティの設定によって置き換えられます。
事前定義のグローバル・トークン変数を使用する手順は次のとおりです。
my.host.com:8080)を入力します。このプロパティを変更した場合は、サーバーの再起動が必要です。図3-2に詳細を示します。「サーバーURL」プロパティ、およびSOAインフラストラクチャの「共通プロパティ」ページの詳細は、「SOAインフラストラクチャ・プロパティの構成」を参照してください。
