既知の問題と回避策

Oracle User Messaging ServiceとOracle HTTP Serverを構成した後でノード・マネージャが起動しない

問題

影響を受けるプラットフォーム: 汎用

クラスタ環境では、Oracle Real Application Clusters (RAC)のマルチ・データソースが存在するドメインでOracle User Messaging Service (UMS)とOracle HTTP Serverを構成した場合、ノード・マネージャが起動しないことがあります。

回避策

RACが設定されたクラスタ環境では、データベース・サーバーで許可する最大接続数を増やす必要がある場合があります。この値を、各WebLogic Serverのデータソース当たりの最大接続数の合計に設定します。たとえば、Oracle RACが3つのノードとともに使用されている場合(3つのOracle RACデータソースと2つのWebLogic Server)、最大接続数を600に設定します(2 x 3 x 100)。

親トピック: 既知の問題と回避策

ユーザー・メッセージング・サーバーの「パフォーマンス」ページでメッセージ・メトリックが「使用不可」としてレンダリングされる

問題

影響を受けるプラットフォーム: 汎用

サーバーの設定後にメッセージの送受信がない場合などのようにメトリック・データがない場合、メトリックの「パフォーマンス」ページに「使用不可」と表示されます。これは、ソフトウェアの問題ではなく、パフォーマンス・レポート機能は適切に動作しています。送信および受信トラフィックが発生すると、即座に結果が「パフォーマンス」ページに正常に表示されます。UMSサーバーのホームページでもメッセージ数(「統計」セクション)に「使用不可」と表示されます。

回避策

回避策はありません。

親トピック: 既知の問題と回避策

再起動後にUser Messaging ServiceのURLを使用できない

問題

影響を受けるプラットフォーム: 汎用

Oracle Enterprise Manager Fusion Middleware ControlまたはOracle WebLogicコンソールを通じてUser Messaging Serviceサーバー(usermessagingserver)を再起動し、User Messaging Serviceサーバーにより提供されるユーザー・プリファレンスUI (/sdpmessaging/userprefs-ui)や様々なWebサービス・エンドポイントなどのURLにアクセスしようとすると、「エラー503 - サービスが使用できません」というエラーが発生することがあります。このエラーは、Oracle WebLogic Serverの負荷が(SOAインスタンスなどで)高い場合に断続的に発生します。

回避策

User Messaging Serviceサーバーを再起動します(2回以上の再起動が必要になる可能性があります)。
User Messaging Serviceサーバーを複数回再起動しても不十分な場合は、Oracle WebLogic Serverインスタンス全体を再起動します。

親トピック: 既知の問題と回避策

複数のドライバおよびアクセス・ポイントの登録時に例外が発生する

問題

影響を受けるプラットフォーム: 汎用

アクセス・ポイントは新規トランザクションで登録されます。つまり、クライアント・アプリケーションがロールバックされるトランザクションでアクセス・ポイントを登録した場合、アクセス・ポイントは引き続き格納されています。

回避策

アクセス・ポイントを削除する必要がある場合、5.1.2 メッセージ・クライアント・アプリケーションの登録解除に関する項(Oracle User Messaging Serviceの管理)の説明に従ってアプリケーションを登録解除します。

親トピック: 既知の問題と回避策

Upgrade AssistantのUser Messaging Serviceスキーマに接続ボタンがない

問題

影響を受けるプラットフォーム: 汎用

Oracle Fusion Middleware Upgrade AssistantによるUMSスキーマのアップグレードを行う際、「個別に選択されたスキーマ」オプションを選択すると、データベースへの接続を取得するために使用する接続ボタンと利用可能なUMSスキーマ名を移入するために使用するドロップダウン・リストがありません。

回避策

手動でスキーマ名の値を入力します。

親トピック: 既知の問題と回避策

EM「メッセージ・ステータス」ページからのメッセージの再送信が失敗する

問題 – 非クラスタ化管理対象サーバーを含むデプロイメントでの再送信

影響を受けるプラットフォーム: 汎用

UMSが複数の非クラスタ化管理対象サーバーにデプロイされているドメインで、あるUMSサーバーに関するEMの「メッセージ・ステータス」ページに、ドメイン内の別のサーバーを介して送信されたメッセージが表示されます。元々別のサーバーから送信されたメッセージを再送信すると、再送信が失敗します。再送信操作は、元々メッセージの送信に使用されたサーバーと同じサーバーから行う必要があります。

回避策

別のサーバーを介してメッセージを再送信するには、ドメイン内の正しいUMSサーバー・ターゲットの「メッセージ・ステータス」ページに移動し、再送信します。たとえば、2つの管理対象サーバー(a_ums_serverおよびb_ums_server)を含むドメインで適切に送信するには、次のステップを実行します。

左側のナビゲーション・ツリーからターゲット「usermessagingserver (a_ums_server)」を選択し、「メッセージ・ステータス」メニュー項目をクリックします。ページのメッセージ・ステータス表に、デフォルトの検索基準に基づいてすべてのメッセージが表示されます。
表内のメッセージをクリックし、メッセージの「メッセージの詳細」を表示して元々メッセージの送信に使用されたUMSサーバーを確認します。

たとえば、選択したメッセージの「エンジン」パラメータの値が"/unclustered_base_domain/base_domain/b_ums_server/usermessagingserver"の場合、現在のターゲット・サーバー(a_ums_server)は「エンジン」パラメータ内のサーバー(b_ums_server)と一致しません。選択したこのメッセージの「再送信」ボタンをクリックすると、次のエラーになります。

メッセージの再送信操作に無効なサーバーが選択されました。
このメッセージを再送信するには、左側のナビゲーション・ツリーで「usermessagingserver(b_ums_server)」に移動します。メッセージをクリックし、ターゲット名とエンジンの詳細のサーバー名が一致することを確認して「再送信」をクリックします。

問題 – 複数のクラスタを含むデプロイメントでの再送信

影響を受けるプラットフォーム: N/A

UMSが複数のクラスタにデプロイされているドメインで、あるUMSサーバー(クラスタに属する)に関するEMの「メッセージ・ステータス」ページに、ドメイン内の別のサーバーを介して送信されたメッセージが表示されます。元々別のサーバー(別のクラスタに属する)から送信されたメッセージを再送信すると、再送信が失敗します。再送信操作は、元々メッセージの送信に使用されたクラスタと同じクラスタから行う必要があります。別のクラスタを介してメッセージを再送信するには、ドメイン内の正しいUMSサーバー・ターゲット(正しいクラスタ内のUMSサーバーの1つ)の「メッセージ・ステータス」ページに移動し、再送信します。

回避策

たとえば、2つのクラスタ(a_ums_clusterおよびb_ums_cluster)を含むドメインで各クラスタに2つの管理対象サーバー(a_ums_clusterにa_ums_server1とa_ums_server2、b_ums_clusterにb_ums_server1とb_ums_server2)が含まれる場合、適切に再送信するには次のステップを実行します。

左側のナビゲーション・ツリーからターゲット「usermessagingserver (a_ums_server1)」を選択し、「メッセージ・ステータス」メニュー項目をクリックします。ページのメッセージ・ステータス表に、デフォルトの検索基準に基づいてすべてのメッセージが表示されます。
表内のメッセージをクリックし、メッセージの「メッセージの詳細」セクションを表示して元々メッセージの送信に使用されたUMSサーバーを確認します。

例に示すように、選択したメッセージの「エンジン」パラメータの値は"/cluster_base_domain/base_domain/b_ums_server1/usermessagingserver"です。

ターゲット・サーバー(a_ums_server1)と「エンジン」パラメータのサーバー(b_ums_server1)は同じクラスタに属していないため、選択したこのメッセージの「再送信」ボタンをクリックすると、次のエラーになります。

メッセージの再送信操作に無効なサーバーが選択されました
このメッセージを再送信するには、左側のナビゲーション・ツリーで「usermessagingserver (b_ums_server1)」に移動してメッセージをクリックし、ターゲット名とエンジンの詳細のサーバー名が一致すること(または同じクラスタ内にあること)を確認して「再送信」をクリックします。

親トピック: 既知の問題と回避策

WLSTコマンドmanageUserCommunicationPrefsが変更された

問題

影響を受けるプラットフォーム: 汎用

WebLogic Scripting Tool (WLST)コマンドmanageUserCommunicationPrefsの機能が変更されました。このWLSTコマンドは、コマンドの実行中に管理対象サーバーに接続しなくなりました。WLSTコマンドは、MBeanServer接続を再利用して管理対象サーバーに接続するようになりました。このため、manageUserCommunicationPrefsコマンドのすべてのバリアントから接続URL、ユーザー名およびパスワードが削除されます。

親トピック: 既知の問題と回避策

構成の問題と回避策

この項では、構成の問題および回避方法について説明します。

親トピック: 既知の問題と回避策

ドライバの構成時に正しいSSL信頼ストアを使用する

問題

影響を受けるプラットフォーム: 汎用

SSLを使用してリモート・ゲートウェイに接続するためにUser Messaging Serviceドライバ(電子メール・ドライバなど)を構成する際には、まず、SSL信頼ストアが適切に構成されていることを確認してください。詳細は、Oracle WebLogicリモート・コンソール・オンライン・ヘルプを参照してください。

$DOMAIN_HOME/bin/setDomainEnv.sh (またはWindowsの相当するファイル)に設定されている場合、JVMシステム・プロパティ(javax.net.ssl.trustStore)の値が使用する正しい信頼ストアを指していることを確認してください。Java標準信頼ストアは次の場所にあります。

$JAVA_HOME/jre/lib/security/cacertsまたは$BEA_JAVA_HOME/jre/lib/security/cacerts

SSL信頼ストアのデフォルトの即時利用可能な構成(Java標準信頼ストア)では、UMSドライバはSSLを介してOracle Beehive Email Serverに接続できません。一部のインストールでは(SOAをインストールしている場合など)、Java標準信頼ストアはデモ信頼ストアに置き換えられることに注意してください。このような場合、信頼ストアには、Oracle Beehive Email Serverが必要とする有効なルート証明書が含まれていない可能性があります。

回避策

この問題を解決するには、正しいSSL信頼ストアを使用するための手順を実行します。setDomainEnv.shファイル(またはWindowsの相当するファイル)でDemoTrustkeystoreをJava標準SSL信頼ストアで置き換えると、UMS電子メール・ドライバはSSLを介してOracle Beehive Email Serverに正常に接続できるようになります。

親トピック: 構成の問題および回避策

WebLogic管理者がEnterprise ManagerでUMSの構成を更新できない

問題

影響を受けるプラットフォーム: 汎用

WebLogic管理者は、マルチテナンシのためにEnterprise Managerでユーザー・メッセージング・サービス(UMS)の構成を編集する権限を持っていません。このため、WebLogic管理者に対しては、ドライバ構成ページとユーザー・プリファレンス構成ページの追加、編集および削除ボタンが無効化されます。

回避策

UMSの構成を編集するには、パーティション管理者としてログインする必要があります。

親トピック: 構成の問題および回避策

GlobalSignルート証明書があるWebLogicでカスタム証明書ストアを使用する

問題

影響を受けるプラットフォーム: 汎用

Google Trust Servicesに接続するには、デフォルトで各JDK cacertに追加されるGlobalSignルート証明書が必要です。

ノート:

これは、管理対象サーバー用のWebLogicでカスタム証明書ストアを使用する場合に適用されます。

GlobalSignルート証明書がないカスタム信頼証明書ストアを使用してWebLogicが構成されているとき、googleapis.comへの接続が失敗し、次のエラー・メッセージがスローされます。

unable to find valid certification path to requested target

回避策

WebLogicに構成されたカスタム証明書ストアに、keytoolを使用してグローバル・ルート証明書をインポートします。

GlobalSign Root R1の下のGlobalSignルート証明書をGlobalSignからダウンロードします。

ホスト名検証に対して次のオプションが有効になっていることを確認して、管理対象サーバーのホスト名を検証する必要があります:

なし
ワイルドカード・ホスト名の検証

次のオプションが無効になっていることを確認します:

BEAホスト名の検証

親トピック: 構成の問題および回避策