| Oracle Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for Microsoft Windows（32-Bit） B55923-02 |
|
 戻る |
 次へ |
| Oracle Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for Microsoft Windows（32-Bit） B55923-02 |
|
戻る |
次へ |
この章では、Oracle Fusion Middlewareの高可用性とエンタープライズ・デプロイメントに関連する問題について説明します。内容は次のとおりです。
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
6.1.1項「Oracle Access Manager 11gがOracle Identity Federation 11gと統合されている場合にログアウトが機能しない問題」
6.1.9項「WindowsではASCRSを使用してOracle Databaseコンソール・サービスのデータベース・リソースを作成できない問題」
6.1.14項「SOAクラスタで発生することのある無害なSQLIntegrityConstraintViolationException」
6.1.16項「I/PMからUCMに大量のアップロードが発生する場合にホスト名ベースのフィルタのかわりに必要になることのあるIPベースのフィルタの使用」
6.1.17項「フェイルオーバー中に「アクション」ドロップダウン・メニューを使用した場合にワークリスト・アプリケーションで例外がスローされる問題」
6.1.19項「11.2 Oracle RACデータベースでAQ通知およびサーバー側TAFの設定に使用するsrvctl」
6.1.20項「Oracle RACのフェイルオーバー時にOracle I/PMの入力ファイルが正常に処理されない問題」
6.1.22項「Oracle BI Publisherの管理対象サーバーのフェイルオーバー時にレイアウト・ビューにロード失敗エラーが表示される問題」
6.1.23項「Oracle BI Publisherジョブのスケジュールで管理対象サーバーのフェイルオーバー後に表示されるポップアップ・ウィンドウ」
6.1.24項「Oracle Business Intelligenceの管理対象サーバーのフェイルオーバー時にエージェントを保存できない問題」
Oracle Access ManagerがOracle Identity Federationと統合されている場合、ログアウト時にエラーが発生します。現在のところ、回避方法はありません。Oracleサポートに連絡して、Oracle Bug#9969090の修正プログラムを取得し、この問題を解決してください。
SOAエンタープライズ・デプロイメント・トポロジおよびWebCenterエンタープライズ・デプロイメント・トポロジのアプリケーション層は、匿名RMI接続に対して保護することを強くお薦めします。構成済サブセットの外部からの中間層に対するRMIアクセスを防止するには、Oracle WebLogic Server管理コンソールのオンライン・ヘルプに含まれる接続フィルタの構成に関するトピックの手順に従ってください。次に記載する部分を除くすべての手順を実行してください。
デフォルト接続フィルタを構成する手順は実行しないでください。カスタム接続フィルタを構成する手順を実行します。
「接続フィルタ・ルール」フィールドで、中間層サブネットからサーバーに対するすべてのプロトコル・アクセスを許可し、サブネット外からはHTTP（S）アクセスのみを許可します。次に例を示します。
nnn.nnn.0.0/nnn.nnn.0.0 * * allow 0.0.0.0/0 * * allow t3 t3s
Oracle Fusion Middlewareでは、管理対象サーバーのクラスタに対するOracle HTTP Serverルーティングに関して、mod_wls_ohsのみがサポートされ、mod_wlはサポートされません。
Oracle Fusion Middlewareの高可用性デプロイメントでは、『Oracle Fusion Middleware高可用性ガイド』およびOracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイドに記載されている構成手順のみを使用することを強くお薦めします。
フェイルオーバー時に、「SOAコンポーザ」ダイアログ・ボックスを操作中で、接続サーバーが停止している場合、「Target Unreachable, 'messageData' returned null」などのエラーが返されます。
「SOAコンポーザ」での操作を続けるには、新規ブラウザ・ウィンドウを開き、「SOAコンポーザ」に移動します。
コールド・フェイルオーバー・クラスタ（CFC）環境で、Fusion Middleware Controlの「Webサービス・ポリシー」ページにアクセスすると、次の例外が表示されます。
Unable to connect to Oracle WSM Policy Manager. Cannot locate policy manager query/update service. Policy manager service look up did not find a valid service.
これを回避するには、次のいずれかのオプションを実行します。
SSL証明書の別名となる仮想ホスト名を作成し、キーストアに追加します。
startWeblogic.shまたはstartWeblogic.cmdファイルのJAVA_OPTIONSパラメータに-Dweblogic.security.SSL.ignoreHostnameVerification=trueを追加します。
相互にミラー化されている2つ以上のOracle Identity Federationサーバーがあり、フロントエンドにロード・バランサがある高可用性環境でSSLを設定する場合、次の2つの方法があります。
SSL接続がユーザーとロード・バランサの間をつなぐように、ロード・バランサでSSLを構成します。この場合、ロード・バランサによって使用されるキーストアおよび証明書には、ロード・バランサのアドレスを参照するCNが含まれます。
ロード・バランサとWLS/Oracle Identity Federation間の通信では、SSLの使用は任意です（SSLを使用する場合、Oracle WebLogic Serverでは、キーストアおよび証明書がロード・バランサによって信頼されているかぎり、どのキーストアや証明書でも使用できます）。
SSL接続がユーザーとOracle Identity Federationサーバーの間をつなぐように、Oracle Identity FederationサーバーでSSLを構成します。この場合、Oracle WebLogic ServerまたはOracle Identity Federationインストール環境のキーストアおよび証明書のCNでは、ロード・バランサのアドレスを参照する必要があります。ユーザーはロード・バランサのホスト名を使用して接続するため、証明書CNはロード・バランサのアドレスと同じである必要があります。
つまり、ユーザーに接続されるSSLエンドポイント（ロード・バランサまたはOracle WebLogic Server/Oracle Identity Federation）のキーストアおよび証明書には、ロード・バランサのホスト名に設定されたCNが含まれる必要があります。ユーザーは、そのアドレスを使用してOracle Identity Federationに接続するためです。
高可用性環境では、オンライン・ヘルプの使用中に環境内のいずれかのマシンでフェイルオーバーが発生すると、アプリケーションのフェイルオーバー時にオンライン・ヘルプのコンテキストが失われる可能性があります。
たとえば、フェイルオーバー前に選択されていたトピックがオンライン・ヘルプの目次から欠落する可能性や、最後のオンライン・ヘルプの検索結果が失われる可能性があります。
データは失われていないため、フェイルオーバー後の次のオンライン・ヘルプ・リクエストは、適切に処理されます。
Oracle Fusion Middleware 11gリリース1（11.1.1）のパッチ・セット2では、Application Server Cluster Ready Services（ASCRS）に新機能が追加されており、ユーザーは、Oracle Databaseコンソール・サービスのASCRSデータベース・リソースを作成できます。ASCRSを使用してASCRSデータベース・リソースを作成する方法の詳細は、『Oracle Fusion Middleware高可用性ガイド』の「Cluster Ready Servicesの使用方法」の章にあるOracle Databaseリソースの作成に関する項を参照してください。
UNIXではOracle DatabaseコンソールでCFCを有効化できるため、この機能はUNIXで使用できます。
ただし、Windowsでは、Oracle Databaseコンソール・サービスでCFCがサポートされません。そのため、Windowsでは、ASCRSを使用してOracle Databaseコンソール・サービスのデータベース・リソースを作成できません。
Oracle RACインスタンスのフェイルオーバー時にワークリスト構成UIまたはSOAコンポーザ・アプリケーションを通じて（ヒューマン・ワークフローまたはBPELで使用される）ルールセットを更新すると、新規ルールのメタデータがデータベースに登録されないことがあります。この場合、手動で再試行する必要があります。ただし、古いバージョンのメタデータは、エラーなしで使用を継続できます。
Oracle RACインスタンスのフェイルオーバー時に大量のルールを含むタスクが再デプロイされる場合、状況によってはエンド・ユーザーが手動で再試行する必要があります。
アクティブ/アクティブのOracle SOAクラスタでノード障害が発生した場合、受信アクティビティのリクエスト/レスポンス操作のタイムアウト設定は、あるノードから他の1つ以上のノードに伝播されません。これらのアクティビティがスケジュールされていたサーバーで障害が発生した場合、サーバーの再起動時にスケジューラで各アクティビティを再スケジュールする必要があります。
WLS LDAPストアに基づくローカル・ファイルと外部LDAPストアの再関連付けを行ってから、現在の環境でスケール・アウトおよびスケール・アップ操作を実行すると、その操作は失敗します。この障害を回避するには、スケール・アップまたはスケール・アウト操作を実行する前に次の手順を実行します。
DOMAIN_HOME/binディレクトリにあるsetDomainEnv.shファイルを編集し、ファイルに-Dcommon.components.home=${COMMON_COMPONENTS_HOME}および-Djrf.version=11.1.1という変数を追加します。
これらの変数をEXTRA_JAVA_PROPERTIESに追加します。次に例を示します。
EXTRA_JAVA_PROPERTIES="-Ddomain.home=${DOMAIN_HOME}
-Dcommon.components.home=${COMMON_COMPONENTS_HOME} -Djrf.version=11.1.1
.
.
.
ファイルを保存して、引き続きスケール・アウトまたはスケール・アップ操作を実行します。
SOAクラスタで次のSQLIntegrityConstraintViolationExceptionが発生することがあります。
[TopLink Warning]: 2010.04.11 14:26:53.941--UnitOfWork(275924841)--Exception [TOPLINK-4002] (Oracle TopLink - 11g Release 1 (11.1.1.3.0): Internal Exception: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (JYIPS2RC4B49_SOAINFRA.SYS_C0035333) violated . . .
これは不具合ではありません。クラスタ環境では、同じグループに対するメッセージが2つのノードに到着すると、1つのノードで最初のメッセージに対してこの例外が常に発生します。アプリケーションではこの例外が認識され、適切に処理されます。いずれの機能も中断することはありません。
この例外は、サーバーを再起動して既存のグループに対するメッセージを送信した後に、単一ノードで発生する可能性もあります。また、この例外は、一番最初のメッセージで発生します。
つまり、この例外は、アプリケーション設計内部の問題であり、機能に対する影響はありません。そのため、この例外は、SOA診断ログで重大レベルとして記録されません。
ただし、Toplinkでは、この例外はサーバー・ログに記録されます。
特定のWebLogicクラスタ・プロセスのクラッシュ・シナリオでは、WS-ATリカバリの結果、スレッドがスタックしてサーバーが警告状態になります。このような場合、WS-ATデータ・リカバリは、ログに失敗状態を示すメッセージが記録されても成功しますが、これはコミット確認がこのシナリオでは適切に処理されないためです（この問題は、シナリオにトランザクションのロールバックが含まれる場合は発生しません）。サーバーはこの警告状態で動作し続けることが可能ですが、スレッドはトランザクション破棄のタイムアウト（デフォルトで24時間）に到達するまでスタックし続けます。この問題を回避するには、サーバーを再起動してスタック・スレッドを削除し、警告状態を解消します。この問題のパッチは、Oracleサポートから取得できます。
Oracle Fusion Middleware Oracle Enterprise Content Management Suiteのエンタープライズ・デプロイメント・ガイドに含まれる、UCMの許可ホストのリストに対するI/PMサーバーのリスニング・アドレスの追加に関する項および『Oracle Fusion Middleware高可用性ガイド』に含まれる、UCMの許可ホストのリストに対するI/PMサーバーのリスニング・アドレスの追加に関する項では、Oracle UCMの許可ホストのリストに対し、Oracle I/PM管理対象サーバーのリスニング・アドレスのホスト名に基づくフィルタを追加する方法について説明しています。
Oracle UCMでホスト名ベースのフィルタ（config.cfgファイル）を使用する場合、Oracle I/PMからOracle UCMへのドキュメントの大量アップロードが発生するシステムでは、待機時間やパフォーマンスが大幅に悪化する可能性があります。この問題の原因は、Oracle I/PMサーバーからの接続を許可するためにOracle UCMで必要とされるDNSの逆引き参照です。障害保護に対応したシステムを構成する場合や、異なるホストにリストアする場合、ホスト名ベースのフィルタを使用することをお薦めします（ホスト名ベースのフィルタを使用すると、使用される構成がIPに依存しなくなるため）。ただし、アップロードのパフォーマンスを改善する必要がある場合は、かわりにIPベースのフィルタを使用できます。次の手順を実行します。
/u01/app/oracle/admin/domainName/ucm_cluster/config/config.cfgファイルを編集し、次の部分を削除するかコメント・アウトします。
SocketHostNameSecurityFilter=localhost|localhost.mydomain.com|ecmhost1vhn1|ecmhost2vhn1 AlwaysReverseLookupForHost=Yes
WLS_IPM1およびWLS_IPM2管理対象サーバー（それぞれECMHOST1VHN1およびECMHOST2VHN1）のIPアドレス（リスニング・アドレス）を次のようにSocketHostAddressSecurityFilterパラメータ・リストに追加します。
SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|X.X.X.X|Y.Y.Y.
ここで、X.X.X.XおよびY.Y.Y.Yは、それぞれWLS_IPM1とWLS_IPM2のリスニング・アドレスです。127.0.0.1も、この例のように追加する必要があります。
UCMサーバーを再起動します。
フェイルオーバーの進行中に、Oracle Business Process Management Suiteのワークリスト・アプリケーションの「アクション」ドロップダウン・メニューを使用してタスクにアクションを実行すると、次のような例外がスローされることがあります。
<oracle.adf.view.rich.component.fragment.UIXInclude> <ADF_FACES-10020> <Tear
down of include component context failed due to an unhandled e
xception.
java.util.NoSuchElementException
at java.util.ArrayDeque.removeFirst(ArrayDeque.java:251)
at java.util.ArrayDeque.pop(ArrayDeque.java:480)
at
oracle.adfinternal.view.faces.context.ApplicationContextManagerImpl.popContext
Change(ApplicationContextManagerImpl.java:66)
.
.
.
この場合、タスクの承認または却下は処理されません。
この問題を回避するには、次のいずれかのアプローチを使用します。
「アクション」ドロップダウン・メニューを使用してタスクにアクションを実行するかわりに、タスク・フォームを使用してアクションを実行します。
エラー・メッセージの確認後にリフレッシュを実行します。その後、「アクション」ドロップダウン・メニューを使用してアクションを再度実行します。
SOAクラスタのOracle SOAワークリスト・アプリケーションでClassCastExceptionsが発生することがあります（java.lang.ClassCastException: oracle.adf.model.dcframe.DataControlFrameImplがログに記録されます）。その結果、ワークリスト・アプリケーションの状態をクラスタ内の他の管理対象サーバーにレプリケートできなくなる可能性があります。ワークリスト・アプリケーションおよび対応するユーザー・セッションは、例外のスロー後も使用できますが、クラスタ内の他のサーバーに対するフェイルオーバーは、すべて失敗します。
この問題の回避方法はありません。
この問題を解決するには、Oracle Bug#9561444のパッチをダウンロードして問題を解決します。次の手順を実行します。
パッチを取得するには、次のURLにあるMy Oracle Support（以前のOracleMetalink）にログインします。
「パッチと更新版」タブをクリックします。
「パッチ検索」セクションで、パッチIDまたは番号フィールドに9561444を入力し、プラットフォーム・フィールドの次のフィールドに現在のプラットフォームを入力します。
「検索」をクリックします。
「パッチ検索」ページで、「パッチID」列のパッチ番号をクリックします。この操作により、ページ・コンテンツが変更され、パッチの詳細情報が表示されます。
「ダウンロード」をクリックしてパッチをダウンロードします。
11.2 Oracle RACデータベースの既知の問題のため、AQ通知およびサーバー側TAFを設定する場合、srvctlを使用する必要があります。DBMS_SQLパッケージを使用しても、正常に動作しません。
次に、srvctlの使用例を示します。
srvctl modify service -d orcl -s orclSVC -e SELECT -m BASIC -w 5 -z 5 -q TRUE
この例の変数の意味は次のとおりです。
orcl: データベース名
orclSVC: ミドルウェア・コンポーネントに使用されるサービス名
SELECT: フェイルオーバー・タイプ
BASIC: フェイルオーバー方式
5: フェイルオーバー遅延
5: フェイルオーバー再試行
TRUE: AQ HA通知をTRUEに設定
このコマンドの使用方法の詳細は、Oracle 11.2 Oracle Databaseのドキュメントを参照してください。
Oracle RACインスタンスのフェイルオーバー時に、Oracle I/PMおよびOracle UCMのファイル処理で一部のファイルがUCMに適切にロードされないことがあります。
Oracle I/PMで処理される着信ファイルは、入力フォルダに配置されます。Oracle I/PMは、入力フォルダのファイルを処理し、Oracle RACデータベースを基盤とするOracle UCMにそれらのファイルを配置します。状況によっては、Oracle RACインスタンスに障害が発生したときに再試行が正常に実行されないことがあり、その場合、着信ファイルは処理されません。これらの未処理のファイルは、エラー・フォルダに配置されます。未処理のファイルは、手動で入力フォルダに戻し、処理することが可能です。
Oracle BI Publisherでレポートを作成し、そのレポートを保存する前に管理対象サーバーがフェイルオーバーされると、そのフェイルオーバーはシームレスでなくなる可能性があります。たとえば、レポートを保存しようとすると、システムが応答しなくなることがあります。
この問題が発生したら、「ホーム」や「カタログ」などのヘッダー・リンクの1つをクリックして、Oracle BI Publisherのログイン・ページに移動します。その後、ログインしてレポートを再度作成および保存します。
管理対象サーバーのフェイルオーバー時に、Oracle BI Publisherのレイアウト・エディタでWebベースのレイアウトを開いたり作成したりすると、次のエラーが表示されることがあります。
Failed to load: object_name
Please contact the system administrator.
この問題を回避するには、メッセージを閉じ、「ホーム」や「カタログ」などのヘッダー・リンクの1つをクリックしてログイン・ページに移動します。
Oracle BI Publisherでジョブをスケジュールする場合、管理対象サーバーのフェイルオーバー後、「発行」をクリックすると、ログイン・ページのHTMLソースが記載された大きなポップアップ・ウィンドウが表示されます。
この問題を回避するには、メッセージ・ウィンドウを閉じ、「ホーム」や「カタログ」などのヘッダー・リンクの1つをクリックしてログイン・ページに移動します。レポート・ジョブを再作成する必要があります。
Oracle Business Intelligence Webインタフェースでエージェントを作成し、そのエージェントを保存する前に管理対象サーバーがフェイルオーバーされると、エージェントの保存時にエラーが発生します。
この問題を回避するには、Oracle Business Intelligenceを一度ログアウトしてからログインしなおし、エージェントを再作成します。
Windowsにおいて、Oracle Business Intelligenceクラスタで仮想IPを有効化してサーバー全体の移行を設定した後、分析機能またはBusiness Intelligence Publisherにアクセスしようとすると、そのアクセス試行は失敗し、次のエラー・メッセージが返されます。
Unable to Sign In An error occurred during authentication. Try again later or contact your system administrator.
この問題を回避するには、次の操作を実行します。
すべての管理対象サーバーのsetDomainEnv.cmdファイルで、oracle.bi.management.config.urlStrategyプロパティの値をASK_WEBLOGICに設定します。たとえば、setDomainEnv.cmdファイルで次のようにエントリを作成します。
# This extra property causes WebLogic to look at the localhost instead of the # virtual IP set EXTRA_JAVA_PROPERTIES=%EXTRA_JAVA_PROPERTIES% -Doracle.bi.management.config.urlStrategy=ASK_WEBLOGIC
ASK_WEBLOGICプロパティを指定する前述の2つの行は、setDomainEnv.cmdファイルでは1つの行に記述する必要があることに注意してください。
この項では、構成に関する問題およびその回避方法について説明します。内容は次のとおりです。
6.2.3項「ロード・バランサのCookie永続性の設定によってWindowsプラットフォームのPortalへのアクセス時に断続的なタイムアウトが発生する問題」
6.2.7項「Oracle RACフェイルオーバーで作成されるリカバリ不可能な重複ヒューマン・ワークフロー・インスタンス」
クラスタ環境では、各ノードは、インバウンド再試行用にメモリー内に独自のHasmapを維持します。jca.retry.countプロパティは、インバウンド再試行機能で3と指定されます。ただし、ノードごとに3回試行されます。結果として、クラスタ環境に2つのノードがある場合、合計再試行回数は6になります。
クラスタ内のすべてのマシンは、同じタイムゾーンに存在する必要があります。WANクラスタは、Oracle Fusion Middlewareの高可用性ではサポートされません。同じタイムゾーンのマシンであっても、コマンドラインで起動されると問題が発生する可能性があります。サーバーの起動には、ノード・マネージャを使用することをお薦めします。
Oracle Portalのアクティブ/アクティブ設定では、ロード・バランサのCookie永続性は要求されません。Windowsに対するPortalデプロイメントにおいて、特定のハードウェア・ロード・バランサでCookie永続性をアクティブCookie挿入に不注意で設定すると、Oracle Portalへのアクセス時に断続的なタイムアウトが発生します。
一部の環境では、コンポーネントが再起動またはフェイルオーバーされた直後に、そのコンポーネントの間違ったステータスがOracle WebLogic Fusion Middleware Controlに表示されることがあります。
スケール・アウトされたクラスタ環境で、大量のBPELインスタンスがデータベースに蓄積されると、データベースのパフォーマンスが低下し、MANY THREADS STUCK FOR 600+ SECONDSというエラーが生成されます。
このエラーを回避するには、データベースから古いBPELインスタンスを削除してください。
XA以外の環境では、ローカル・トランザクションにおいて、メッセージがインバウンド・アダプタからエンドポイントまでただ1回のみ配信されることがMQSeriesアダプタにより保証されません。この場合、インバウンド・メッセージがエンドポイントにパブリッシュされ、トランザクションがコミットされる前にSOAサーバーが停止すると、インバウンド・メッセージはロールバックされ、同じメッセージが再度デキューされてエンドポイントにパブリッシュされます。これにより、アウトバウンド・キューに余分なメッセージが作成されます。
XA環境では、MQメッセージは失われませんが、一貫性のない状態であるためキュー・マネージャによって保留されます。保留メッセージを取得するには、キュー・マネージャを再起動します。
Oracle Human Workflowがトランザクションをコミットすると、制御は即座にBPELに戻され、BPELでほぼ同時にそのトランザクションがコミットされます。この間にOracle RACインスタンスが停止すると、フェイルオーバーでメッセージ送信が再試行され、重複タスクが発生する可能性があります。重複タスクは、2つの形式で出現する可能性があります。つまり、ワークリスト・アプリケーションに重複タスクが出現するか、またはリカバリ不可能なBPELインスタンスが作成されます。このBPELインスタンスは、BPELリカバリに出現します。該当タスクはすでに完了しているため、このBPELインスタンスはコンシューマとしてリカバリできません。
次の情報は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の第10章「トポロジの管理」に記載されています。
管理サーバー・ノードの計画的な停止（管理サーバー・マシンの再起動または停止）を実行する場合、管理サーバー自体が停止する前にOSのNFSサービスが無効になる可能性があります。これにより、OSレベルでのサービスの構成によっては、管理サーバーのドメイン・ディレクトリでファイルの欠落が検出され、他のノードのドメイン・ディレクトリでそれらの削除が行われる可能性があります。その結果、フレームワークでdomain_dir/fmwconfig/のファイルの一部が削除される可能性があります。この動作は、通常、マシン障害、停電、マシン・クラッシュなどの計画外の停止時間には発生しません。この動作を回避するには、再起動を実行する前に管理サーバーを停止します。別の方法としては、管理サーバー・プロセスより後にNFSサービスが無効化されるように、適切なOS構成を使用してサービスの優先順位を設定します。サービスの順序に対応するために必要な構成の詳細は、使用しているOSの管理ドキュメントを参照してください。
SOA B2B TCP/IPプロトコルでは、高可用性フェイルオーバーはサポートされません。このことは、主にHL7 over MLLPを使用したデプロイメントに影響します。クラスタ環境のインバウンド通信では、すべてのB2Bサーバーがアクティブであり、インバウンド・トラフィックに公開されたアドレスは、ロード・バランサの仮想サーバーです。また、アクティブな管理対象サーバーが使用できなくなる停止時間には、永続TCP/IP接続が失われ、クライアントは接続を再確立する必要があります。
複数のネットワーク・カードが搭載されたサーバーにOracle WebLogic Serverをインストールする場合、必ず管理サーバーのリスニング・アドレスを指定してください。使用するアドレスは、管理サーバー通信での使用を希望するネットワーク・カードのDNS名またはIPアドレスである必要があります。
リスニング・アドレスを設定するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールで、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「管理サーバー」をクリックします。
「チェンジ・センター」の「ロックして編集」をクリックして編集を可能にします。
リスニング・アドレスを入力します。
「保存」をクリックします。
「チェンジ・センター」の「変更のアクティブ化」をクリックします。
Oracle RACでの一部のSOAデプロイメントでは、Oracle RAC構成における個別データソースの即時利用可能な構成とは別に、追加パラメータを設定する必要があります。追加パラメータは次のとおりです。
データソースごとにoracle.jdbc.ReadTimeout=300000プロパティ（300000ミリ秒）を追加します。
ReadTimeoutパラメータの実際の値は、他の考慮事項に応じて変化する可能性があります。
ネットワークの信頼性が低い場合、サーバーの接続が突然切断されても、クライアントでは頻繁に発生する切断を検出するのが困難です。デフォルトでは、Linux上で稼働するクライアントは、突然の切断を検出するのに7200秒（2時間）かかります。この値は、tcp_keepalive_timeプロパティの値と同じです。切断をより迅速に検出するようアプリケーションを構成するには、tcp_keepalive_time、tcp_keepalive_intervalおよびtcp_keepalive_probesプロパティの値をオペレーティング・システム・レベルでより小さい値に設定します。
|
注意: tcp_keepalive_intervalプロパティに小さい値を設定すると、ネットワーク上にプローブ・パケットが頻繁に送出され、システム速度が低下する可能性があります。そのため、このプロパティの値は、システム要件に基づいて適切に設定してください。 |
たとえば、WebLogic Server管理対象サーバーが稼働するシステムでtcp_keepalive_time=600を設定します。
また、接続記述子のDESCRIPTION句にENABLE=BROKENパラメータを指定する必要があります。次に例を示します。
dbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PRO TOCOL=TCP)(HOST=node1-vip.mycompany.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_ NAME=orcl.us.oracle.com)(INSTANCE_NAME=orcl1)))
この結果、データソース構成は次のようになります。
<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PRO
TOCOL=TCP)(HOST=node1-vip.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.oracle.com)(INSTANCE_NAME=orcl1)))</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>oracle.jdbc.ReadTimeout</name>
<value>300000</value>
</property>
<property>
<name>user</name>
<value>jmsuser</value>
</property>
<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>
</properties>
Oracle B2B高可用性（HA）環境では、メッセージ順序付けおよびMLLPはサポートされません。
次の状況下では、アクセス制御例外のためにOracle Identity Federationサーバーに障害が発生します。
host1で、Identity Managementコンポーネントを含まないドメインを作成します。
host2で、クラスタ・モードでそのドメインを拡張し、すべてのIdentity Managementコンポーネントを選択して、「スキーマの作成」を選択します。
host1で、クラスタを拡張し、すべてのコンポーネントを選択します。
不具合が原因で、host1のファイルDOMAIN_HOME/config/fmwconfig system-jazn-data.xmlは、<grant>要素が削除されるように上書きされます。これにより、Oracle Identity Federationサーバーの起動時にアクセス制御例外が発生します。
<grant>要素を復元するには、WLST grantPermissionコマンドを使用します。
Linuxでは、bashプロンプトで次の3つのコマンドを入力します。各コマンドは1行で入力してください。
コマンドを入力する場合、ORACLE_COMMON_HOMEは、Middlewareホームに存在するOracle共通ホーム・フォルダのパスで置き換えます。WebLogicに接続するための情報を求められたら、WLS管理者資格証明と、WebLogic管理サーバーの場所を入力してください。
ORACLE_COMMON_HOME/common/bin/wlst.sh ORACLE_COMMON_HOME/modules/oracle.jps_11.1.1/common/wlstscripts/grantPermissi on.py -codeBaseURL file:\${domain.home}/servers/\${weblogic.Name}/tmp/_WL_user/OIF_11.1.1.2.0/- -permClass oracle.security.jps.service.credstore.CredentialAccessPermission -permTarget context=SYSTEM,mapName=OIF,keyName=* -permActions read ORACLE_COMMON_HOME/common/bin/wlst.sh ORACLE_COMMON_HOME/modules/oracle.jps_11.1.1/common/wlstscripts/grantPermissi on.py -codeBaseURL file:\${domain.home}/servers/\${weblogic.Name}/tmp/_WL_user/OIF_11.1.1.2.0/- -permClass oracle.security.jps.service.credstore.CredentialAccessPermission -permTarget credstoressp.credstore -permActions read ORACLE_COMMON_HOME/common/bin/wlst.sh ORACLE_COMMON_HOME/modules/oracle.jps_11.1.1/common/wlstscripts/grantPermissi on.py -codeBaseURL file:\${domain.home}/servers/\${weblogic.Name}/tmp/_WL_user/OIF_11.1.1.2.0/- -permClass oracle.security.jps.service.credstore.CredentialAccessPermission -permTarget credstoressp.credstore.OIF.* -permActions read
Windowsでは、コマンド・プロンプトで次の3つのコマンドを入力します。各コマンドは1行で入力してください。
コマンドを入力する場合、ORACLE_COMMON_HOMEは、Middlewareホームに存在するOracle共通ホーム・フォルダのパスで置き換えます。WebLogicに接続するための情報を求められたら、WLS管理者資格証明と、WebLogic管理サーバーの場所を入力してください。
ORACLE_COMMON_HOME\common\bin\wlst.cmd ORACLE_COMMON_HOME\modules\oracle.jps_11.1.1\common\wlstscripts\grantPermiss ion.py -codeBaseURL file:${domain.home}/servers/\${weblogic.Name}/tmp/_WL_user/OIF_11.1.1.2.0/- -permClass oracle.security.jps.service.credstore.CredentialAccessPermission -permTarget context=SYSTEM,mapName=OIF,keyName=* -permActions read ORACLE_COMMON_HOME\common\bin\wlst.cmd ORACLE_COMMON_HOME\modules\oracle.jps_11.1.1\common\wlstscripts\grantPermiss ion.py -codeBaseURL file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/OIF_11.1.1.2.0/- -permClass oracle.security.jps.service.credstore.CredentialAccessPermission -permTarget credstoressp.credstore -permActions read ORACLE_COMMON_HOME\common\bin\wlst.cmd ORACLE_COMMON_HOME\modules\oracle.jps_11.1.1\common\wlstscripts\grantPermiss ion.py -codeBaseURL file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/OIF_11.1.1.2.0/- -permClass oracle.security.jps.service.credstore.CredentialAccessPermission -permTarget credstoressp.credstore.OIF.* -permActions read
Oracle Identity Navigatorの保護されたリソースを作成するには、oamadminアカウントを使用してhttp://admin.mycompany.com/oamconsoleにあるOracle Access Managerコンソールにログインします。次の手順を実行します。
ナビゲーション・ウィンドウで、「アプリケーション・ドメイン」→「IDMDomainAgent」を展開します。
「リソース」をクリックします。
「参照」タブの下にあるツールバーの「作成」をクリックします。
次の情報を入力します。
タイプ: http
ホスト識別子: IDMDomain
リソースURL: /oinav
「適用」をクリックします。
ナビゲーション・ウィンドウで、「アプリケーション・ドメイン」→「IDMDomainAgent」→「認証ポリシー」を展開します。
「保護された上位レベル・ポリシー」をクリックします。
「参照」タブの下にあるツールバーの「編集」をクリックします。
「リソース」ボックスで、「+」をクリックします。
リストからリソース「/oinav」を選択します。
「適用」をクリックします。
ナビゲーション・ウィンドウで、「アプリケーション・ドメイン」→「IDMDomainAgent」→「認可ポリシー」を展開します。
「保護されたリソース・ポリシー」をクリックします。
「参照」タブの下にあるツールバーの「編集」をクリックします。
「リソース」ボックスで、「+」をクリックします。
リストからリソース「/oinav」を選択します。
「適用」をクリックします。
JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再起動の動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーおよび再起動後に異なる問題が発生する可能性があります。この動作は、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させることで確認できます。サーバーがサーバー移行用に構成されている場合、対応するフェイルオーバー期間の経過後に、通常、サーバーはフェイルオーバー・ノードで自動的に起動します。起動しない場合、（ノードが完全に再起動してから）同じホストでWebLogic Serverを手動で再起動できます。具体的には、JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している状態で、予期しないマシン障害の後にOracle WebLogic Serverが再起動しない場合、次のエラーがサーバー・ログ・ファイルに記録されている可能性があります。
<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent
store "_WLS_server_soa1" could not be deployed:
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource
temporarily unavailable, errno=11
このエラーは、NFSシステムがストアに対するロックを解放しないために発生します。WebLogic Serverは、同じWebLogic Serverの2つのインスタンスが偶然起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログの格納に使用しているファイルに対するロックを保持します。NFSストレージ・デバイスは、マシン障害を適切なタイミングで認識できないため、ロックを解放しません。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverが以前ロックされたファイルに対するロックを取得しようとしても、失敗する可能性があります。ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックに関する追加情報は、使用しているストレージ・ベンダーのドキュメントを参照してください。現在のNFS環境でロックの動作を調整することに無理がある場合、次のいずれかの解決策を使用してログとデータファイルのロックを解除してください。
次のいずれかの解決策を使用してログとデータファイルのロックを解除してください。
解決策1
手動でログおよびJMSデータファイルのロックを解除し、サーバーを起動します。これを行うには、ロックされた永続ストア・ファイルのコピーを作成して、後続の操作にそのコピーを使用します。ロックされた永続ストア・ファイルのコピーを作成するには、ファイル名を変更してから、そのファイルをコピーして元の名前に戻します。次の手順例では、トランザクション・ログが/shared/tlogsディレクトリに格納されており、JMSデータが/shared/jmsディレクトリに格納されていると仮定します。
cd /shared/tlogs mv _WLS_SOA_SERVER1000000.DAT _WLS_SOA_SERVER1000000.DAT.old cp _WLS_SOA_SERVER1000000.DAT.old _WLS_SOA_SERVER1000000.DAT cd /shared/jms mv SOAJMSFILESTORE_AUTO_1000000.DAT SOAJMSFILESTORE_AUTO_1000000.DAT.old cp SOAJMSFILESTORE_AUTO_1000000.DAT.old SOAJMSFILESTORE_AUTO_1000000.DAT mv UMSJMSFILESTORE_AUTO_1000000.DAT UMSJMSFILESTORE_AUTO_1000000.DAT.old cp UMSJMSFILESTORE_AUTO_1000000.DAT.old UMSJMSFILESTORE_AUTO_1000000.DAT
この解決策では、WebLogicのファイル・ロック・メカニズムにより、同じサーバーの複数のインスタンスが偶然起動した場合に発生する可能性のあるデータ破損からの保護が引き続き提供されます。ただし、サーバーは、予期しないマシン障害の後に手動で再起動する必要があります。ファイル・ストアでは、大量のデータを格納する場合、連続した番号が付けられた複数の.DATファイルが作成されます。この場合、必要に応じてすべてのファイルをコピーし、その名前を変更する必要があります。
解決策2
WebLogic Server管理コンソールを使用して、デフォルト・ファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストアおよび診断ファイル・ストアに対するWebLogicのファイル・ロック・メカニズムを無効化することもできます。次の項の手順に従ってください。
|
警告: この解決策では、WebLogicのロック機能が無効化されるため、通常は自動的なサーバーの再起動とフェイルオーバーに成功します。ただし、このオプションを使用する場合は、慎重に行ってください。WebLogicのファイル・ロック機能は、不適切な同時実行シナリオにおいて発生する可能性のある重大なファイル破損を防止する目的で設計されています。ファイル・ストアを使用するサーバーがサーバー移行用に構成されている場合、必ずデータベースに基づいたリース・オプションを構成してください。これにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、同じWebLogic Serverの複数のインスタンスが自動的に再起動しなくなります。人為的エラーを回避し、任意の時点でサーバーのただ1つのインスタンスを手動で起動するため、追加の手続き型の予防措置を実施する必要があります。同様に、特別な予防措置を実行して、同じディレクトリを参照する同じ名前の1つのストアを複数のドメインが保持しないようにする必要があります。 |
デフォルト・ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの（左上隅の）「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーのサマリー」リストで、変更するサーバーを選択します。
「構成」→「サービス」タブを選択します。
「デフォルト・ストア」セクションを下にスクロールし、「詳細」をクリックします。
下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックして変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlのエントリは、次のようになります。
<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>
カスタム・ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの（左上隅の）「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを開いて「永続ストア」を選択します。
「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。
カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックして詳細なストア設定を表示します。
ページの一番下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックして変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
カスタム・ファイル・ストアが使用中の場合、変更を反映するにはサーバーを再起動する必要があります。
生成されるconfig.xmlのエントリは、次のようになります。
<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>
JMSページング・ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの（左上隅の）「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを開き、次に「メッセージング」ノードを開いて「JMSサーバー」を選択します。
「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。
JMSサーバーの「構成」→「全般」タブで、下にスクロールして「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックして変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlファイルのエントリは、次のようになります。
<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>
診断ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの（左上隅の）「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「診断」ノードを開いて「アーカイブ」を選択します。
「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。
「<サーバー名>の設定」ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。
「保存」をクリックして変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlファイルは、次のようになります。
<server>
<name>examplesServer</name>
...
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-store-file-locking-enabled>false</diagnostic-store-file-locking-
enabled>
<diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>100</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
</server-diagnostic-config>
</server>
この項では、ドキュメントの訂正箇所を示します。内容は次のとおりです。
6.4.2項「『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』の訂正箇所」
6.4.3項「『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の訂正箇所」
6.4.4項「Oracle Fusion Middleware Oracle Identity Managementのエンタープライズ・デプロイメント・ガイドの訂正箇所」
6.4.5項「Oracle Fusion Middleware Oracle Business Intelligenceのエンタープライズ・デプロイメント・ガイドの訂正箇所」
この項には、『Oracle Fusion Middleware高可用性ガイド』の訂正箇所が含まれます。
内容は次のとおりです。
Oracle Fusion Middleware 11gドキュメント・セットの複数のマニュアルには、Oracle Fusion Middlewareシステムの要件、前提条件、仕様および動作保証情報に関する情報が含まれます。
Oracle Fusion Middlewareシステムの要件、前提条件、仕様および動作保証情報に関する最新情報は、Oracle Technology Networkの次のドキュメントを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。
Oracle Fusion Middlewareの動作保証情報は、次のURLを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。
Oracle RTD JMSのWebLogic Server JMSの構成に関する項で、手順1の最後に、次の手順が含まれる必要があります。
j. bi_server2を再起動して変更をRTDに適用します。
Oracle RTDのスケール・アウト後に、WebLogic Server管理コンソールを使用して、各管理対象サーバーの「サーバーの起動」タブに3つのシステム・プロパティを追加します。
管理コンソールで、「環境」→「サーバー」→「bi_server<1,2>」→「サーバーの起動」→「引数」を選択し、次の3つのプロパティを追加します。
-Drtd.clusterRegistryJobIntervalMs=12000 -Drtd.clusterDepartureThresholdMs=50000 -Drtd.clusterDepartureThreshold2Ms=50000
この操作により、管理対象サーバーの障害時に、RTDのインスタンスをあるホストから別のホストに正常に移行できるようにします。
これらの変更後でも、サーバー移行が50秒未満で終了すると、RTDのバッチ・フレームワークは一貫性のない状態となります。
エンタープライズでバッチ・ジョブ実装をホストするRTD Inline Servicesをデプロイしており、サーバー移行後にバッチ・コンソール・コマンドのbatch-names（短縮名bn）を使用して登録済のバッチ・ジョブが表示されない場合、次の手順に従ってRTDのバッチ・マネージャ・サービスを停止して再起動する必要があります。
Enterprise Managerで、「WebLogicドメイン」の下にあるbifoundation_domainノードの左側のペインを右クリックし、システムMBeanブラウザに移動します。
「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server1」→「Server」または「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server2」→「Server」で、BatchManager MBeanを検索します。
このMBeanは、これらの場所のどちらか一方で見つかります（両方にはありません）。
「bi_server1」で見つかった場合、「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server1」→「SDPropertyManager」→「Misc : BatchManagerEnabled」を選択して、対応するMBean属性を検索します。
この属性をfalseに設定し、更新された値を保存します。
その後、すぐに設定をtrueに戻し、値を保存します。この操作により、BatchManagerの停止と再起動が行われます。
再起動後は、前と同じサーバーで実行されるか、異なるサーバーで実行されます。
BatchManagerの再起動後、対応するMBeanは、BatchManagerが再度実行されるようになったサーバーでいつでも即座にリフレッシュされるわけではないため、問題にする必要はありません。かわりに、バッチ・コンソール・ツールを使用して、BatchManagerが現在稼働していることを確認してください。次の手順を実行します。
バッチ・コンソールは、インストール・ホームにある次のZIPファイルに含まれるRTDクライアント・ツールの1つです（次のパスで、FUSION_MIDDLEWARE_HOMEはインストール・ホームを示します）。
FUSION_MIDDLEWARE_HOME/Oracle_BI1/clients/rtd/rtd_client_11.1.1.3.0.zip
このファイルをWindowsのホスト・ディレクトリ（ここではRTD_HOMEとして示します）に解凍した後、バッチ・コンソールは次のjarファイルに含まれます（ほとんどのRTDツールは、Linux上では動作しません）。
RTD_HOME/client/Batch/batch-console.jar
このディレクトリに移動し、管理対象サーバーまたはクラスタ・プロキシのURLおよびポートを指定して、jarを実行します。
> java -jar batch-console.jar -url http://SERVER:PORT
プロンプトが表示されたら、AdministratorロールやBI_Adminstratorロールなど、RTDバッチ・ジョブを管理する権限を付与されているロールに属するユーザーの名前とパスワードを入力します。
コマンドの入力を求められたら、引用符なしでbnと入力します。
Checking server connection...
command: bn
CrossSellSelectOffers
command:quit
>
BatchManagerが正常に再起動されていれば、bnコマンドによって、すべてのデプロイ済RTD Inline Servicesでホストされているすべてのバッチ実装の名前がリストされます。
共通デプロイ例のCrossSellでは、前述のようにCrossSellSelectOffersというバッチ実装がホストされます。
『Oracle Fusion Middleware高可用性ガイド』の共有Oracle BIプレゼンテーション・カタログの場所の設定に関する項は、次の項で置き換える必要があります。
各プレゼンテーション・サービス・インスタンスでは、Fusion Middleware Controlで指定されたカタログの場所からOracle BIプレゼンテーション・カタログをロードします。
次の手順を実行してください。
既存の（ローカルに公開された）Oracle BIプレゼンテーション・カタログを共有の場所にコピーします。ローカルに公開されたカタログの例は、次のとおりです。
ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/ coreapplication_obipsn/catalog/SampleAppLite
Fusion Middleware Controlで「カタログの場所」を指定する前に、この手順を実行する必要があります。
共有カタログとしてこの項の例に記載されているSampleAppLiteカタログを使用する場合、必ずそのカタログをAPPHOST1からコピーしてください。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウの「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックし、次に「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
共有Oracle BIプレゼンテーション・カタログの「カタログの場所」を指定します。
Windows環境では、UNCパス名を指定します。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
この項には、『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』の訂正箇所が含まれます。
内容は次のとおりです。
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』のディスカッション・フォーラム接続の構成に関する項では、EMからWebCenterに対するディスカッション・サーバー接続の作成に関する項へのリンクが欠落しています。
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』のマルチキャストからユニキャストへのディスカッション・フォーラムの変換に関する項では、手順3から次の情報が欠落しています。
手順3: WLS_Services2で、次のようにWCHost1をWCHost2に、WCHost2をWCHost1に置き換えて手順1と2を繰り返します。
-Dtangosol.coherence.wka1=WCHost2 -Dtangosol.coherence.wka2=WCHost1 -Dtangosol.coherence.localhost=WCHost2 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』に含まれる、EMからWebCenterに対するディスカッション・サーバー接続の作成に関する項の手順に関連するディスカッション・サーバー接続の追加プロパティの詳細は、Oracle Fusion Middleware Oracle WebCenterの管理者ガイドのFusion Middleware Controlを使用したディスカッション・サーバーの登録に関する項を参照してください。
Oracle Fusion Middleware Oracle WebCenterの管理者ガイドのWebGateのインストールおよび構成に関する項の後に、次の項が記載される必要があります。
WebGateのIP検証の構成
IP検証では、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。IP検証では、IPターミネーションを実行するように構成されたロード・バランサ・デバイスを使用するシステムがある場合や、エンタープライズ・デプロイメントのフロントエンドに位置するロード・バランサとは異なるロード・バランサが認証WebGateのフロントエンドに存在する場合に、問題が発生する可能性があります。これらの場合にロード・バランサを検証しないように構成するには、次の手順を実行します。
次のURLを使用してアクセス・システム・コンソールに移動します。
http://hostname:port/access/oblix
ここで、hostnameはWebPassのOracle HTTP Serverインスタンスが稼働するホストを、portはOracle HTTP ServerインスタンスのHTTPポートを示します。
アクセス・システムのメイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。
アクセス・システム・コンソールのメイン・ページで、「アクセス・システム構成」をクリックし、左側のペインの「アクセス・ゲート構成」リンクをクリックしてアクセス・ゲートの検索ページを表示します。
適切な検索基準を入力し、「実行」をクリックしてアクセス・ゲートのリストを表示します。
Oracle Access Manager構成ツールで作成されたアクセス・ゲートを選択します。
ページの一番下の「変更」をクリックします。
「IPValidationException」フィールドに、デプロイメントのフロントエンドに位置するロード・バランサのアドレスを入力します。
ページの一番下の「保存」をクリックします。
この項には、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の訂正箇所が含まれます。
内容は次のとおりです。
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のEDGトポロジのBAMコンポーネントに適用される構成変更に関する項には、次の間違ったディレクトリ名が2回出現します。
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<servername>/
tmp/_WL_user/oracle-bam_11.1.1/*/APP-INF/classes/config/
前述の間違ったディレクトリ名の正しいディレクトリ名は、次のとおりです。
DOMAIN_HOME/config/fmwconfig/servers/<server_name>/applications/ oracle_bam-11.1.1/config
この項には、Oracle Fusion Middleware Oracle Identity Managementのエンタープライズ・デプロイメント・ガイドの訂正箇所が含まれます。
内容は次のとおりです。
6.4.4.6項「Identity Management EDGマニュアルから欠落しているWebGateのIP検証の構成に関する項」
6.4.4.15項「Oracle Access Manager 10g WebGateへのパッチ適用時におけるコピー・ファイルのモード変更」
6.4.4.18項「Oracle Access Manager 10gとOracle Identity Managerの統合に関する項から欠落している項」
6.4.4.19項「Oracle Identity Managerと統合するためのOracle Access Manager 10gの構成における値の間違い」
6.4.4.20項「Oracle Access Manager/Oracle Identity Manager統合のためのOracle Identity Managerの構成における値の間違い」
6.4.4.22項「Oracle Access Manager 10g/Oracle Identity Managerの認証プロバイダの構成におけるプロバイダ名の間違い」
6.4.4.23項「Oracle Identity Managerと統合するためのOracle Access Manager 10gの構成におけるポリシー・ドメインの間違い」
6.4.4.24項「Oracle Identity Managerと統合するためのOracle Access Manager 10gの構成におけるディレクトリ・パスの間違い」
6.4.4.25項「Oracle Identity Managerの2つのOracle Adaptive Access Managerプロパティのエラー」
6.4.4.26項「LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニングに関する項から欠落している手順」
6.4.4.27項「Oracle Access Manager 10gによる管理コンソールのシングル・サインオンの構成に関する項から欠落している内容」
6.4.4.28項「管理ユーザーおよびグループをプロビジョニングするLDIFファイルから欠落しているオブジェクト・クラス」
ロード・バランサに関する項には、「クライアントIPアドレスを保持する機能: ロード・バランサは、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入してクライアントIPアドレスを保持する機能を備えている必要があります」という必須のロード・バランサ機能に関する箇条書きが含まれる必要があります。
ロード・バランサでの仮想サーバーの名前およびポートの構成に関する項で、sso.mycompany.comの項には、次の追加の内容が含まれる必要があります。
この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。一部のロード・バランサでは、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入できるようにしてこれを構成します。
2.2.6項のOracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポートの表で、Oracle Coherenceポートのエントリには、エラーがあります。「ファイアウォール」列のFW1をN/Aに変更し、「プロトコル/アプリケーション」列のTCMPの後にUDPを追加する必要があります。正しいエントリは、次のとおりです。
ソフトウェアのインストール・タスクの順序を変更する必要があります。現在、各項の順序は次のとおりです。
Oracle Identity Management Platform and Directory Services Suiteのインストールに関する項
Oracle Identity and Access Management Suiteのインストールに関する項
Oracle SOA Suiteのインストールに関する項
Oracle Identity Management Platform and Directory Services SuiteのOracleホームのアップグレードに関する項
Oracle SOA SuiteのOracleホームのアップグレードに関する項
このインストール手順の順序は、次のように変更する必要があります。
Oracle Identity Management Platform and Directory Services Suiteのインストールに関する項
Oracle SOA Suiteのインストールに関する項
Oracle Identity Management Platform and Directory Services SuiteのOracleホームのアップグレードに関する項
Oracle SOA SuiteのOracleホームのアップグレードに関する項
Oracle Identity and Access Management Suiteのインストールに関する項
4.7.5項のパッチ9449855の注意として、パッチ9449855はOIDHOST1、OIDHOST2、OVDHOST1およびOVDHOST2には適用する必要がないという記述があります。この記述は間違っていませんが、追加として、このパッチはWEBHOST1およびWEBHOST2にも追加する必要はありません。
9.4.2項で、仮想ホスト定義内のadmin.confに追加するよう指示されている行は、間違っています。追加する行は、正しくは次のとおりです。
<Location /odsm> SetHandler weblogic-handler WebLogicCluster idmhost1.us.oracle.com:odsm_port1,idmhost2.us.oracle.com:odsm_port2 </Location>
編集後のファイルは次のようになります。
NameVirtualHost *:80
<VirtualHost *:80>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
<Location /odsm>
SetHandler weblogic-handler
WebLogicCluster idmhost1.us.oracle.com:odsm_port1,idmhost2.us.oracle.com:odsm_port2
</Location>
</VirtualHost>
Oracle Fusion Middleware Oracle Identity Managementのエンタープライズ・デプロイメント・ガイドの第10章に含まれるWebGateのインストールに関する項の後に、次の項が記載される必要があります。
WebGateのIP検証の構成
IP検証では、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。IP検証では、IPターミネーションを実行するように構成されたロード・バランサ・デバイスを使用するシステムがある場合や、エンタープライズ・デプロイメントのフロントエンドに位置するロード・バランサとは異なるロード・バランサが認証WebGateのフロントエンドに存在する場合に、問題が発生する可能性があります。これらの場合にロード・バランサを検証しないように構成するには、次の手順を実行します。
次のURLを使用してアクセス・システム・コンソールに移動します。
http://hostname:port/access/oblix
ここで、hostnameはWebPassのOracle HTTP Serverインスタンスが稼働するホストを、portはOracle HTTP ServerインスタンスのHTTPポートを示します。
アクセス・システムのメイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。
アクセス・システム・コンソールのメイン・ページで、「アクセス・システム構成」をクリックし、左側のペインの「アクセス・ゲート構成」リンクをクリックしてアクセス・ゲートの検索ページを表示します。
適切な検索基準を入力し、「実行」をクリックしてアクセス・ゲートのリストを表示します。
Oracle Access Manager構成ツールで作成されたアクセス・ゲートを選択します。
ページの一番下の「変更」をクリックします。
「IPValidationException」フィールドに、デプロイメントのフロントエンドに位置するロード・バランサのアドレスを入力します。
ページの一番下の「保存」をクリックします。
OAMコンソールにアクセスするためのOracle HTTP Serverの構成に関する項で、Oracle HTTP Serverを再起動する前にORACLE_INSTANCE/config/OHS/component/httpd.confを編集する必要があります。
行頭に#を挿入して次の行をコメント・アウトします。編集後は次のようになります。
#*******Default Login page alias*** #Alias /oamsso "/u01/app/oracle/product/fmw/webgate/access/oamsso" #<LocationMatch "/oamsso/*"> #Satisfy any #</LocationMatch> #**********************************
13.3.2項の手順5に、OIM HTTP URL（OIMサーバーのプロキシURL）の値の例がリストされています。これは、OIMのOHSサーバーのフロントエンドに位置するハードウェア・ロード・バランサのURLです。
正しいURLの例は、http://oiminternal.mycompany.com:80です。
18.2.2.1項に記載されているgccライブラリのダウンロード用リンクは、使用できなくなりました。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のサード・パーティGCCライブラリのインストール（LinuxおよびSolarisオペレーティング・システムのみ）に関する項の記載に従って、http://gcc.gnu.orgからライブラリをダウンロードしてください。
手順2で、クリックするリンクの実際のラベルは、「OAM 10gエージェントの追加」ではなく「OAM 10g Webゲートの追加」です。
手順6で、クリックするリンクの実際のラベルは、「エージェントの選択」→「OAMエージェント」→「10g Webゲート」です。
手順11で、ログアウトURLの1つとして/em/targetauth/emaslogout.jsが記載されています。正しいURLは、/em/targetauth/emaslogout.jspです。
手順3は、無効になりました。この手順は無視してください。
18.3.1.2項のintg_adminユーザーを作成する操作は、必要ありません。かわりに、18.4.5項に記載されているとおり、LDAPでxelsysadmというユーザーを作成します。
18.3.1.2項、18.4.5項および20.3.1項の記載に従ってユーザーをプロビジョニングする場合、そのユーザーがmail属性付きで作成されていることを確認してください。この属性は、Oracle Identity Managementのユーザー・リコンシリエーションに必要です。
たとえば、18.3.1.2項と18.4.5項では、LDIFファイルに次の行を追加します。
mail:xelsysadm@mycompany.com
20.3.1項では、LDIFファイルに次の行を追加します。
mail:weblogic_idm@mycompany.com
18.3.1.4項の手順7の後に、すべてのWebホストのORACLE_INSTANCE/config/OHS/InstanceName/cgi-binに存在するconfig.pl、loginredirect.plおよびlogout.plファイルに対する実行権限を追加する手順が必要です。すべてのWebホストで実行権限を追加するには、次のコマンドを実行します。
chmod +x ORACLE_INSTANCE/config/OHS/InstanceName/cgi-bin/*.pl
Oracle Identity Managerと統合するためのOracle Access Manager 10gの構成に関する項の手順8の前に、次の注意を追加する必要があります。
|
注意: 次の手順は、logoutRedirectUrlを設定するもので、認証WebGate（AWG）とリソースWebGate（RWG）が異なる環境では必須です。このデプロイメント・ガイドでは、AWGとRWGが同じであるため、この手順は必要ありません。 |
18.3.2.1項の手順3のURLは、間違っています。正しくは次のようになります。
ロスト・パスワードのリダイレクトURL:
https://sso.mycompany.com:443/admin/faces/pages/forgotpwd.jspx?backUrl=%HostTarget%%RESOURCE%
パスワード変更のリダイレクトURL:
https://sso.mycompany.com:443/admin/faces/pages/pwdmgmt.jspx?backUrl=%HostTarget%%RESOURCE%
アカウント・ロックアウトのリダイレクトURL:
https://sso.mycompany.com:443/ApplicationLockoutURI
18.3項には次の項が欠落しています。
18.3.4 必須オブジェクト・クラスによる既存のLDAPユーザーの更新
既存のLDAPユーザーは、OblixPersonPwdPolicy、OIMPersonPwdPolicyおよびOblixOrgPersonオブジェクト・クラスで更新する必要があります。ユーザーを更新する場合、IAM_ORACLE_HOME/server/ssointgディレクトリにあるOIM構成ツールのoimcfgtool.jarを使用します。このコマンドは、IDMHOST1（管理サーバー・ホスト）で実行します。ツールの詳細は、Oracle Fusion Middlewareのアプリケーション・セキュリティ・ガイドに含まれるIDアサーション・プロバイダの認証スキームの構成に関する項を参照してください。
18.3.4.1 前提条件
oimcfgtoolを実行する前に、次の基準を満たしていることを確認してください。
wlfullclient.jarファイルがMW_HOME/wlserver_10.3/server/libディレクトリに存在すること。このjarファイルが存在しない場合、wlfullclient.jarファイルの作成に関する項の手順に従って、jarファイルを生成します。
IAM_ORACLE_HOME/server/ssointgディレクトリからoimcfgtoolを実行すること。このツールを異なる場所にコピーしないでください。
次のようにJAVA_HOMEおよびWL_HOMEを設定すること。
JAVA_HOME=ORACLE_BASE/product/fmw/jdk160_18 WL_HOME=ORACLE_BASE/product/fmw/wlserver_10.3 PATH=JAVA_HOME/bin:$PATH
|
注意: JAVA_HOMEは、SUN JDKに設定する必要があります。 |
18.3.4.2 OIM構成ツールの使用方法
oimcfgtoolを使用してOracle Access ManagerとOracle Identity Managerを統合するには、次の手順を実行します。
|
注意: ·oimcfgtoolを実行する前に、LDAPサーバーが起動して実行中であることを確認してください。 |
ORACLE_HOMEにIAM_ORACLE_HOMEを設定し、JAVA_HOMEにSUN JDKディレクトリを設定して、PATHにJAVA_HOMEを含めます。
prompt>export MW_HOME=/opt/maa/oracle/plus/product/fmw prompt>export ORACLE_HOME=/opt/maa/oracle/plus/product/fmw/iam prompt>export JAVA_HOME=/opt/maa/oracle/plus/product/fmw/jdk160_18 prompt>export PATH=$JAVA_HOME/bin:$PATH
generate-profileオプション付きでoimcfgtoolを実行し、sso-config.profileファイルを作成します。このsso-config.profileに値を入力します。プロファイル・ファイルに必須の入力値を指定しないと、プロンプトが表示されます。次のようにツールを実行します。
java -jar oimcfgtool.jar generate-profile
出力は次のようになります。
Turning off debug logs Generating sso-config.profile... Generated sso-config.profile
IAM_ORACLE_HOME/server/ssointgディレクトリに作成されたsso-config.profileファイルを編集します。次の値を指定します。ファイルの残りの値は、既存のLDAPユーザーを更新するのに必要ありません。
LDAP Host: LDAPサーバーのホスト名
LDAP Port: LDAPサーバーのポート
LDAP Root DN: LDAPサーバーに接続するための管理者DN
User Search Base: OIMユーザーのLDAP検索ベース
Group Search Base: OIMグループのLDAP検索ベース
Password Expiry Period in Days: パスワード有効期限（日単位）。デフォルト値は7300です。
次に、sso-config.profileファイルの例を示します。
LDAP Host :-oid.mycompany.com LDAP Port :-389 LDAP Root DN :-cn=orcladmin User Search Base :-cn=Users,dc=mycompany,dc=com Group Search Base :-cn=Groups,dc=mycompany,dc=com Password Expiry Period in Days :-7300
オプション付きでoimcfgtoolを実行し、oim-config.xmlファイルのアクセス・サーバー情報を更新します。次のようにツールを実行し、要求されたらLDAPルートDNのパスワードを入力します。
java -jar oimcfgtool.jar upgrade-ldap-users
出力は次のようになります。
[orcl@strasha07 ssointg]$ java -jar oimcfgtool.jar upgrade-ldap-users Turning off debug logs ********* Upgrading LDAP Users With OAM ObjectClasses ********* Loading inputs from sso-config.profile Completed loading inputs from sso-config.profile Remaining inputs will be queried from console. Enter LDAP Root DN Password: Completed loading user inputs for - LDAP connection info Completed loading user inputs for - LDAP Upgrade Upgrading ldap users at - cn=Users,dc=mycompany,dc=com Parsing - cn=Users,dc=mycompany,dc=com objectclass OIMPersonPwdPolicy not present in cn=weblogic_idm,cn=users,dc=mycompany,dc=com. Seeding it objectclass OblixOrgPerson not present in cn=weblogic_idm,cn=users,dc=mycompany,dc=com. Seeding it objectclass OblixPersonPwdPolicy not present in cn=weblogic_idm,cn=users,dc=mycompany,dc=com. Seeding it obpasswordexpirydate added in cn=weblogic_idm,cn=users,dc=mycompany,dc=com Finished parsing LDAP LDAP Users Upgraded. ********* ********* ********* Operation completed. Please restart all servers.
Oracle Identity Managementコンポーネントの起動および停止に関する項の記載に従って、WLS管理サーバーとドメイン内のすべての管理対象サーバーを停止して起動します。
18.3.2.2項の手順4cにあるregistrationURLおよびlostPasswordURLの値は、間違っています。
正しい値は次のとおりです。
var registrationURL = OimOHSHostPort +'/oim/faces/pages/USelf.jspx?OP_TYPE=SELF_REGISTRATION&T_ID=Self-Register%20User&E_TYPE=USELF';
var lostPasswordURL = OimOHSHostPort + '/admin/faces/pages/forgotpwd.jspx';
18.3.3.1項の手順2aで、application_nameは次のように記載されています。
application_name=oim
正しくは次のようになります。
application_name=OIMMetadata
18.3.3.1項の手順1gで、<webgateType>パラメータが例から欠落しています。正しい例は次のようになります。
<ssoConfig>
<version>10.1.4.3</version>
<accessServerHost>sso.mycompany.com</accessServerHost>
<accessServerPort>443</accessServerPort>
<accessGateID>IDMEDG_AG</accessGateID>
<napVersion>3</napVersion>
<cookieDomain>.mycompany.com</cookieDomain>
<transferMode>open</transferMode>
<webgateType>ohsWebgate10g</webgateType>
<ssoEnabled>true</ssoEnabled>
</ssoConfig>
18.3.3.5項の手順4fに、次の記述があります。
「OIMAuthenticator」リンクをクリックします。
正しくは次のようになります。
「OIMAuthenticationProvider」リンクをクリックします。
手順5の表にも同様のエラーが含まれます。次の記述があります。
OIMAuthenticator
正しくは次のようになります。
OIMAuthenticationProvider
また、手順5gの認証プロバイダの正しい順序は、次のとおりです。
| 名前 | 制御フラグ |
|---|---|
| OAMIdentityAsserter | REQUIRED |
| Default Authenticator | SUFFICIENT |
| OIMSignatureAuthenticator | SUFFICIENT |
| OIMAuthentication Provider | OPTIONAL |
| OIDAuthenticator | SUFFICIENT |
| Default Identity Asserter | SUFFICIENT |
18.3.2.2項の手順6で、mapAgentIdToAgentHostPortの値がOIMPolicy_AGと記載されています。正しくはIDMEDG_AGです。
18.3.2.2項の手順5で、loginredirect.plおよびlogout.plファイルの場所は、Webgate_Home/access/oblix/libディレクトリではなくORACLE_INSTANCE/config/OHS/InstanceName/cgi-binディレクトリです。
OIMのOAAMプロパティの設定に関する項の手順4には、次の2つのエラーがあります。
bharosa.uio.default.signon.links.enum.trackregistration.urlプロパティの値に空白が挿入されています。正しい値は、https://sso.mycompany.com:443/oim/faces/pages/USelf.jspx?E_TYPE=USELF&OP_TYPE=UNAUTH_TRACK_REQUEST&backUrl=https://sso.us.oracle.com:443/oim/faces/pages/Self.jspxです。
oaam.oim.urlプロパティの値が間違っています。正しい値は、t3://oimhost1.mycompany.com:14000,oimhost2.mycompany.com:14000です。
20.3.1項には次の手順が欠落しています。
5. 必須オブジェクト・クラスによる既存のLDAPユーザーの更新に関する項の記載に従って、プロビジョニング・ユーザーを更新します。
次の内容が、Oracle Identity NavigatorおよびAPMコンソールでのSSO保護の有効化に関する項として含まれる必要があります。
OAM構成ツールの実行に関する項の手順に従って、Oracle Access Manager 10gを使用してOracle Identity NavigatorおよびAPMコンソールを保護します。10.4.3項と同じ値を使用してoamcfgtoolを実行しますが、protected_urisには/oinav, /apmを使用します。
次に例を示します。
$JAVA_HOME/bin/java -jar oamcfgtool.jar mode=CREATE app_domain="IDMEDG"web_domain="idmEDG_WD" cookie_domain="mycompany.com"protected_uris="/oinav,/apm" app_agent_password="welcome1"ldap_host=oid.us.oracle.com ldap_port=389 ldap_userdn="cn=orcladmin"ldap_userpassword=password oam_aaa_host=oamhost1.mycompany.comoam_aaa_port=6023
20.3.1項で、weblogic_idmユーザーを作成するLDIFファイルからoblixPersonPwdPolicy、OIMPersonPwdPolicyおよびoblixorgpersonオブジェクト・クラスが欠落しています。正しいファイルは次のようになります。
dn: cn=weblogic_idm, cn=Users, dc=mycompany,dc=com obpasswordchangeflag: false obpasswordexpirydate: 2035-01-01T00:00:00Z sn: admin uid: weblogic_idm givenname: weblogic_idm displayname: weblogic_idm cn: weblogic_idm objectclass: orclIDXPerson objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top objectclass: oblixPersonPwdPolicy objectclass: OIMPersonPwdPolicy objectclass: oblixorgperson userpassword: Account password obuseraccountcontrol: activated orclisenabled: ENABLED
20.3.3項の手順14の指示に従ってweblogic_idmユーザーを作成しないでください。このユーザーは、Oracle Internet Directoryにすでに存在します。かわりに、リコンシリエーション・プロセスを実行して、このユーザーをOIMコンソールで表示可能にします。次の手順を実行します。
ユーザーxelsysadmとしてhttps://sso.mycompany.com:443/oimにあるOracle Identity Managerにログインします。
「拡張」をクリックします。
「システム管理」タブをクリックします。
「スケジューラの検索」の矢印をクリックしてすべてのスケジューラをリストします。
LDAPユーザーの作成および全リコンシリエーションの更新を選択します。
「即時実行」をクリックしてジョブを実行します。
「管理」ページに移動して検索を実行し、Oracle Identity Managerコンソールにユーザーが表示されることを確認します。
この項には、Oracle Fusion Middleware Oracle Business Intelligenceのエンタープライズ・デプロイメント・ガイドの訂正箇所が含まれます。
内容は次のとおりです。
6.4.5.1項「RTDのスケール・アウト後に実行する追加手順」
6.4.5.2項「BI Publisher構成フォルダの場所の設定後に実行する必要のある追加手順」
6.4.5.3項「共有Oracle BIプレゼンテーション・カタログの場所の設定に関する項の訂正」
Oracle RTDのスケール・アウト後に、WebLogic Server管理コンソールを使用して、各管理対象サーバーの「サーバーの起動」タブに3つのシステム・プロパティを追加します。
管理コンソールで、「環境」→「サーバー」→「bi_server<1,2>」→「サーバーの起動」→「引数」を選択し、次の3つのプロパティを追加します。
-Drtd.clusterRegistryJobIntervalMs=12000 -Drtd.clusterDepartureThresholdMs=50000 -Drtd.clusterDepartureThreshold2Ms=50000
この操作により、管理対象サーバーの障害時に、RTDのインスタンスをあるホストから別のホストに正常に移行できるようにします。
これらの変更後でも、サーバー移行が50秒未満で終了すると、RTDのバッチ・フレームワークは一貫性のない状態となります。
エンタープライズでバッチ・ジョブ実装をホストするRTD Inline Servicesをデプロイしており、サーバー移行後にバッチ・コンソール・コマンドのbatch-names（短縮名bn）を使用して登録済のバッチ・ジョブが表示されない場合、次の手順に従ってRTDのバッチ・マネージャ・サービスを停止して再起動する必要があります。
Enterprise Managerで、「WebLogicドメイン」の下にあるbifoundation_domainノードの左側のペインを右クリックし、システムMBeanブラウザに移動します。
「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server1」→「Server」または「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server2」→「Server」で、BatchManager MBeanを検索します。
このMBeanは、これらの場所のどちらか一方で見つかります（両方にはありません）。
「bi_server1」で見つかった場合、「アプリケーション定義のMBean」→「OracleRTD」→「Server:bi_server1」→「SDPropertyManager」→「Misc : BatchManagerEnabled」を選択して、対応するMBean属性を検索します。
この属性をfalseに設定し、更新された値を保存します。
その後、すぐに設定をtrueに戻し、値を保存します。この操作により、BatchManagerの停止と再起動が行われます。
再起動後は、前と同じサーバーで実行されるか、異なるサーバーで実行されます。
BatchManagerの再起動後、対応するMBeanは、BatchManagerが再度実行されるようになったサーバーでいつでも即座にリフレッシュされるわけではないため、問題にする必要はありません。かわりに、バッチ・コンソール・ツールを使用して、BatchManagerが現在稼働していることを確認してください。次の手順を実行します。
バッチ・コンソールは、インストール・ホームにある次のZIPファイルに含まれるRTDクライアント・ツールの1つです（次のパスで、FUSION_MIDDLEWARE_HOMEはインストール・ホームを示します）。
FUSION_MIDDLEWARE_HOME/Oracle_BI1/clients/rtd/rtd_client_11.1.1.3.0.zip
このファイルをWindowsのホスト・ディレクトリ（ここではRTD_HOMEとして示します）に解凍した後、バッチ・コンソールは次のjarファイルに含まれます（ほとんどのRTDツールは、Linux上では動作しません）。
RTD_HOME/client/Batch/batch-console.jar
このディレクトリに移動し、管理対象サーバーまたはクラスタ・プロキシのURLおよびポートを指定して、jarを実行します。
> java -jar batch-console.jar -url http://SERVER:PORT
プロンプトが表示されたら、AdministratorロールやBI_Adminstratorロールなど、RTDバッチ・ジョブを管理する権限を付与されているロールに属するユーザーの名前とパスワードを入力します。
コマンドの入力を求められたら、引用符なしでbnと入力します。
Checking server connection...
command: bn
CrossSellSelectOffers
command:quit
>
BatchManagerが正常に再起動されていれば、bnコマンドによって、すべてのデプロイ済RTD Inline Servicesでホストされているすべてのバッチ実装の名前がリストされます。
共通デプロイ例のCrossSellでは、前述のようにCrossSellSelectOffersというバッチ実装がホストされます。
共有Oracle BI Publisher構成フォルダの場所の設定に関する項の記載に従って、構成フォルダの場所を指定する際にOracle BI Publisherを再起動した後、Oracle BI PublisherのXML構成ファイルを管理対象サーバーから管理サーバーの場所にコピーする必要があります。Oracle BI Publisherでは、管理対象サーバーの再起動時に、管理対象サーバーの構成ディレクトリではなく管理サーバーの集中管理された場所からその構成を読み取ります。
この操作を行うには、APPHOST1でxmlp-server-config.xmlファイルを次の場所からコピーします。
ORACLE_BASE/admin/domain_name/mserver/domain_name/config/bipublisher
次の場所にコピーします。
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/bipublisher
Oracle Fusion Middleware Oracle Business Intelligenceのエンタープライズ・デプロイメント・ガイドの共有Oracle BIプレゼンテーション・カタログの場所の設定に関する項は、次の項で置き換える必要があります。
各プレゼンテーション・サービス・インスタンスでは、Fusion Middleware Controlで指定されたカタログの場所からOracle BIプレゼンテーション・カタログをロードします。
次の手順を実行してください。
既存の（ローカルに公開された）Oracle BIプレゼンテーション・カタログを共有の場所にコピーします。ローカルに公開されたカタログの例は、次のとおりです。
ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/ coreapplication_obipsn/catalog/SampleAppLite
Fusion Middleware Controlで「カタログの場所」を指定する前に、この手順を実行する必要があります。
共有カタログとしてこの項の例に記載されているSampleAppLiteカタログを使用する場合、必ずそのカタログをAPPHOST1からコピーしてください。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウの「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックし、次に「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
共有Oracle BIプレゼンテーション・カタログの「カタログの場所」を指定します。
Windows環境では、UNCパス名を指定します。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
この項では、複数のエンタープライズ・デプロイメント・ガイドに関連する訂正箇所について説明します。リリース・ノートに次の訂正箇所の問題が記載されているすべてのエンタープライズ・デプロイメント・ガイドは、そのリリース・ノートの指定どおりに更新される必要があります。
内容は次のとおりです。
一部のエンタープライズ・デプロイメント・ガイドには、コンポジットをデプロイするためのOracle Coherenceの構成に関する項に、次のような注意が含まれます。
|
注意: デプロイメントに使用されるCoherenceクラスタでは、デフォルトでポート8088を使用します。このポートは、-Dtangosol.coherence.wkan.port起動パラメータを指定することで変更できます。 |
この注意は、正しくは次のようになります。
|
注意: デプロイメントに使用されるCoherenceクラスタでは、デフォルトでポート8088を使用します。このポートは、-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localport起動パラメータで異なるポート（8089など）を指定することで変更できます。次に例を示します。
WLS_SOA1（次の内容を引数フィールドに改行なしの単一行として入力）: -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 WLS_SOA2（次の内容を引数フィールドに改行なしの単一行として入力）: -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 |
一部のエンタープライズ・デプロイメント・ガイドには、サーバー移行をテストする方法について説明する1つ以上の項が含まれます。
サーバー移行のテストに関するすべての項の最後に次の注意が記載される必要があります。
|
注意: サーバーの移行後にサーバーを元のノードまたはマシンにフェイルバックするには、Oracle WebLogic管理コンソールで管理対象サーバーを停止し、その後再起動します。管理対象サーバーは、適切なノード・マネージャによって、最初に割り当てられていたマシン上で起動されます。 |
一部のエンタープライズ・デプロイメント・ガイドには、サーバー移行の構成時にリース用として使用されるデータソースを更新する方法について説明する1つ以上の項が含まれます。
サーバー移行の構成の一部としてリース用のデータソースを更新する方法に関する指示に、次のテキストが記載されています。
「グローバル・トランザクションのサポート」の「1フェーズ・コミット」を使用し、データベースのサービス名を指定します。
正しいテキストは次のとおりです。
データソースでは、グローバル・トランザクションのサポートは必要ありません。したがって、データソースに関しては、どのタイプの分散トランザクション・エミュレーション（参加）・アルゴリズムも使用せずに（「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」あるいは「1フェーズ・コミット」オプションを選択せずに）、データベースのサービス名を指定します。
