| Oracle Real-Time Collaboration管理者ガイド 10g リリース1（10.1.1） B25134-01 |
|
 戻る |
 次へ |
この章では、Oracle Real-Time Collaborationのコンポーネントを監視して、会議とインスタント・メッセージに関してサービスのクオリティを維持するとともに、会議とメッセージ・サービスを中断することなく使用可能にする方法を説明します。この章には次の項があります。
Oracle Real-Time Collaborationのプロセス・マネージャ（rtcpm）はJavaベースのプロセスでデーモンとして実行され、1つのインスタンス内のOracle Real-Time Collaborationのすべてのプロセスを管理します。プロセス・マネージャはHTTPのリスニング・ポイントを開き、プロセスの開始および停止のリクエストを受け取ります。プロセス・マネージャは具体的には次のことを行います。
1つのインスタンス内のOracle Real-Time Collaborationのすべてのプロセスを定期的にpingし、プロセスがアクティブかどうかをチェックします。
非アクティブなプロセス（pingに応答しないプロセス）を自動的に再起動します。
プロセス・マネージャは、次のOracle Real-Time Collaborationコンポーネント・プロセスを監視します。
Oracle Web Conferencingサーバー（confsvr）
Client Connection Manager（connmgr）
Oracleプレゼンス・サーバー（imrtr）
マルチプレクサ（mx）
リダイレクタ（rdtr）
ボイス・プロキシ・サーバー（voiceproxy）
プロセス・マネージャは、Oracle Real-Time CollaborationをインストールしたときにOracle Process Management and Notification（OPMN）システムと統合されます。OPMNシステムはプロセス・マネージャを監視し、プロセス・マネージャが非アクティブの場合、rtcpmを自動的に再起動します。プロセス・マネージャは、停止する前に監視していたプロセスに影響を与えずに自分の状態をリカバリできます。
rtcctl startコマンドを入力すると、Oracle Process Management and Notification、および（必要な場合には）rtcpmが自動的に起動します。次に、rtcpmによってOracle Real-Time Collaborationの他のプロセスがすべて開始され、rtcpmはこれらを管理対象とします。
追加のオプション（特定のコンポーネントやインスタンスの起動など）を指定してrtcctl startを使用する場合は、プロセス・マネージャ・プロセスをあらかじめ実行しておく必要があります。
引数を指定せずにrtcctl stopコマンドを実行すると、rtcpm、および管理している他のすべてのプロセスが停止します。
Oracleプレゼンス・サーバーは、Oracle Messengerユーザーに関するインスタント・メッセージ、チャット会議および所在の公開に必要なサービスを提供します。 Oracle Real-Time Collaborationコア・コンポーネントを複数のインスタンスにインストールしている場合は、複数のプレゼンス・サーバー・プロセスが使用可能ですが、いかなる時点においても実行可能なプロセスは1つのみです。 各サーバー・プロセスには特別な高可用性監視プロセスが関連付けられています。この監視プロセスは、サーバー・プロセスを起動すると、起動されます。 監視プロセスは、プレゼンス・サーバー・プロセスが停止するとこのプロセスを再起動しようとします。この監視プロセスがサーバー・プロセスを再起動できない場合は、次に使用可能なプレゼンス・サーバーの監視プロセスがそれに関連付けられたサーバー・プロセスをアクティブなプロセスにします。
各プレゼンス・サーバー・プロセスには専用の高可用性監視プロセスがあります。 （rtcctl stop -cname rtc-imrtrを使用して）サーバー・プロセスを停止した場合は、高可用性監視プロセスも停止します。Oracle Real-Time Collaborationのすべてのプロセスと同様に、この高可用性監視プロセスのログは、ログ・ファイル・ディレクトリ$ORACLE_HOME/imeeting/logs/imHaProcessにありますので、参照してください。
Web Conferencingなどのサービスをサポートするプロセスが実行されている場合でも、そのプロセスが特定のインスタンス上で実際にサービスをサポートできることを確認する必要があります。 rtcctl runTestsコマンドを使用して、Oracle Real-Time Collaborationサービスの可用性を判別するためのテストを実行します。
Oracle Real-Time Collaborationは、サービスの可用性を監視するためのインタフェースも公開しています。これは、任意の監視インフラストラクチャに統合できます。 詳細は、「Oracle Real-Time Collaborationの監視インタフェース」を参照してください。
rtcctl runTestsの構文の詳細は、「システムのテストと監視」を参照してください。
次の各項では、これらのサービス・テストについて説明します。
Webクライアント・サービスの可用性（apptestオプション）
データベース接続（dbtestオプション）
ドキュメント変換サービスの可用性（docconvtestオプション）
Oracle Messengerサービスの可用性（imtestオプション）
Web Conferencingサービスの可用性（mtgtestオプション）
音声変換サービスの可用性（voiceconvtestオプション）
システム構成をチェックする追加のrunTestsコマンド・オプションの詳細な使用方法は、「構成テストの実行」を参照してください。
apptestオプションは、アプリケーション層がHTTPを介してOracle Real-Time Collaboration Webクライアント・ページにアクセスできるかどうかをテストします。
このテストに失敗した場合は、Oracle HTTP ServerおよびOC4J_imeetingプロセスが実行中であるかどうかをチェックしてください。実行されていない場合は、次のようにこれらを停止し再起動します。
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
dbtestオプションは、Oracle Real-Time Collaborationとデータベースの間の接続性をテストします。
このテストに失敗した場合は、sqlplusを使用してアプリケーション層からデータベースへログインします。正常に接続された場合は、OC4J_imeetingプロセスを停止し再起動します。
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
docconvtestオプションは、ドキュメント変換サービスの可用性をテストします。このテストでは、テスト・ドキュメントをアップロードし、そのインスタンスで使用できるドキュメント変換サーバーによってドキュメントの変換を試みます。
このテストに失敗した場合は、ドキュメント変換サーバーがインストールされていない可能性があります。サーバーがインストールされており、クラスタも作成されている場合は、サーバーが対象のインスタンスと同じInstanceLocationの値を使用しているかどうかを確認してください。 InstanceLocationの値を確認するには、説明に従ってgetPropertyコマンドを使用します。 この値の設定方法の詳細は、「クラスタの構成」を参照してください。
このインスタンスに対してドキュメント変換サーバーが設定されている場合は、Oracle Real-Time Collaborationのアプリケーション層でrtcctl getStateを使用し、そのアプリケーション層のプロセスが稼働していることを確認してください。 これらのプロセスが稼働中の場合は、ドキュメント変換サーバーを停止し再起動します。
%ORACLE_HOME%\imeeting\bin\rtcctl rtcctl> stop -ct docconv rtcctl> start -ct docconv rtcctl> getState
テストが依然として失敗する場合は、OC4J_imeetingプロセスを停止し再起動します。
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
imtestオプションは、メッセージを送受信する2人のユーザーのフローを模倣して、Oracle Messengerのサービスが有効であるかどうかをテストします。
2人のユーザーがOracle Messengerにサイン・インでき、かつOracle Messengerのすべてのコンポーネントが実行されていることがrtcctl getStateコマンドで表示され、「システム」タブのステータス・レポートにimtestが失敗したことが示される場合は、Oracleプレゼンス・サーバーからデータベースへの接続をチェックする必要があります。 $ORACLE_HOMEから、RTCスキーマを含むデータベースに対してsqlplusを実行できるように、アプリケーション層にあるtnsnames.oraファイルが適切に構成されているかどうかを確認します。
何百人ものユーザーがOracle Messengerでオンライン状態になった後で、Oracle Real-Time Collaborationサーバーを再起動してimtestが失敗した場合は、しばらく待ってからimtestをもう一度実行します。 Oracle Messengerは、サーバーが切断されたときに自動的に再接続するように構成されています。ログイン情報の保存を選択済で、オンライン状態だったユーザーは、すべて1〜6分後に自動的に再接続されます。そのため、すべてのユーザーの認証およびログインのために、サーバー側にかなりの負荷がかかります。この間は、imtestが必ずしも成功するとはかぎりません。 ただし、Oracleプレゼンス・サーバーを再起動してから約6分後には、imtestは成功するはずです。
mtgtestオプションは、Webクライアントを経由してインスタント会議を開始するユーザーのフローを模倣して、Web Conferencingサーバーをテストします。これにより、インスタンス内で使用可能ないずれかの会議サーバー上で会議が正常に開始されているかどうかを確認できます。次にこのオプションは、別のクライアントを同じ会議へ参加させて、開催者のクライアントが受信する会議の状態と一致した状態を、この新しいクライアントが取得できるようにします。最後に、テスト会議が終了されます。
このテストに失敗した場合は、次のようにします。
rtcctl getStateを使用して、このインスタンス内で1つ以上のマルチプレクサ（mx）および1つ以上のConferencingサーバー（confsvr）プロセスが稼働しているかどうかを確認します。これらのプロセスが稼働していない場合は手順4へ、プロセスが稼働している場合は手順2へ進みます。
Oracle Real-Time Collaboration Webクライアントのログイン・ページ（http://yourcompany.com/imtapp/app/prelogin.uixなど）に移動します。ブラウザに表示されるエラー・メッセージにより、次に行う処理が異なります。
DNSサーバーのエラーが表示された場合は、次のようにOracle HTTP Serverを停止し再起動します。
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server
500内部サーバー・エラーが表示された場合は、Oracle HTTPサーバーおよびOC4J_imeetingのプロセスの両方を停止し再起動します。
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
表示されたログイン・ページでログインします。
ログインできない場合は、Single Server Sign-Onに問題があります。
ログインできた場合は手順3へ進みます。
Oracle Real-Time Collaborationの「ホーム」ページでインスタント会議を開始します。
「Cannot find suitable collaboration server」というメッセージが表示された場合は、手順2の説明に従いOC4J_imeetingを停止し再起動します。
その後もmtgtestのテストで失敗する場合は、Oracle Real-Time Collaborationのアプリケーション層で次のように入力します。
$ORACLE_HOME/imeeting/bin/rtcctl getMonitorStats
結果が表示されない場合は、Web Conferencingのアプリケーション層を停止し再起動します。
$ORACLE_HOME/imeeting/bin/rtcctl rtcctl> stop rtcctl> start rtcctl> getState
voiceconvtestオプションは、音声データをストリーミングするための音声変換サービスをテストします。このテストでは、有効な音声変換サーバーへの接続を試み、T1またはE1の回線がアクティブか、音声チャネルが使用可能かどうか、およびサーバーが音声をストリーミングできるかを確認します。
このテストに失敗した場合は、音声変換サーバーがインストールされていない可能性があります。サーバーがインストールされており、クラスタも作成されている場合は、サーバーが対象のインスタンスと同じInstanceLocationの値を使用しているかどうかを確認してください。 InstanceLocationの値を確認するには、rtcctl getPropertyコマンドを使用します。 この値の設定方法の詳細は、「クラスタの構成」を参照してください。
テストに失敗した場合は、音声変換サーバーのインスタンスが実行されているアプリケーション層（Windowsマシン）で次を実行します。
%ORACLE_HOME%\imeeting\bin\rtcctl rtcctl> stop -ct voiceconv rtcctl> start -ct voiceconv rtcctl> getState
テストが依然として失敗する場合は、Web Conferencingのアプリケーション層を停止し再起動します。
$ORACLE_HOME/imeeting/bin/rtcctl rtcctl> stop rtcctl> start rtcctl> getState
「システム」タブから使用できるステータス・レポートには、システムで定期的に実行されるサービス可用性テストの結果が含まれています。 このテストには、Web Conferencingサービス、ドキュメント変換と音声変換のサービス、およびOracle Messengerサービスに対するテストがあります。インスタンスおよびそのコンポーネントの階層リストは、クリックすることで開いたり閉じたりできます。
また、レポートには、アクティブな会議やチャット・セッション、システムに設定されているプロパティ、および現在実行中のWebクライアント・セッションの詳細に関する情報も表示されます。
「システム」タブは、businessadminロールのユーザーのみが使用できます。ユーザー・ロールの設定の詳細は、「ユーザー・ロールの設定」を参照してください。
Oracle Real-Time Collaborationコア・コンポーネントを定期的にpingするための監視インフラストラクチャを設定できます。 たとえば、インスタンスのURLがmy.company.comとすると、cronジョブ（UNIXまたはLinuxの場合）を設定して次のURLをpingできます。 次に、この結果をアラート管理システムにプラグインできます。 構成テストの実行に加えて、runTestsコマンドでテストできるサービスをテストできます。 このURLの構文は、次のとおりです。
http://my.company.com/imtapp/RtcServiceTests?test_name=true
testnameには、次の種類があります。
apptest: Webクライアント・サービスのテスト
dbtest: データベースの接続性のテスト
docconvtest: ドキュメント変換サービスのテスト
emailtest: 電子メールの構成のテスト
imtest: Oracle Messengerシステムのテスト
mtgtest: 会議サービスのテスト
voiceconvtest: 音声変換サービスのテスト
rtcctl getMonitorStatsコマンドを使用すると、システム内のいくつかの主要コンポーネントに関する監視データを表示できます。
1つのインスタンス上の各Web Conferencingサーバーに対して、アクティブな会議とユーザーの数、使用可能なメモリーと使用中のメモリーの合計、およびこのプロセス開始後の会議数の合計を一覧で表示できます。
1つのインスタンス上の各音声変換サーバーについて、音声ストリーミング・チャネル数、使用中のチャネル数および不正なチャネル数の合計、T1またはE1回線のステータスを一覧で表示できます。
1つのインスタンス上のプレゼンス・サーバーの実行について、そのステータスを一覧で表示できます。
-publish trueオプションは、XMLデータを出力します。独自の監視インフラストラクチャがある場合は、このプロセスを定期的に実行し、監視システムによる履歴分析用のXMLデータを収集できます。
getMonitorStatsの構文の詳細は、「システムのテストと監視」を参照してください。
Oracle Real-Time Collaboration Webクライアント・ページの「モニター」タブを使用すると、システムで実行中の会議を対話型操作によって監視できます。 「モニター」タブは、businessmonitorまたはbusinessadminロールのユーザーのみが使用できます。ユーザー・ロールの設定の詳細は、「ユーザー・ロールの設定」を参照してください。
「現在の会議ステータス」ページには、システムで実行中のすべての会議が一覧で表示されます。このページでは、各会議に関して、会議ID、会議タイトル、開催者名、会議タイプ、サイト、開始時間、参加者総数および現在の会議ステータスが表示されます。 このサーバーで実行されている会議数が多い場合は、表示する会議をID、会議タイトル、開催者名または会議開始サイトによって絞り込めます。
「会議の詳細」リンクをクリックすると、会議の基本的な詳細（開始日と開始時間、開催者名など）が表示されます。
「詳細」ページの「診断」をクリックすると、診断が実行され、この会議で発生するすべてのイベントを表示できます。 このページを使用すると重要な会議を監視できるため、問題が発生した場合は対応処置をとることができます。
「アーカイブ済ログ・ファイル」には、会議の参加と退出、会議のプロパティの変更（たとえば、開催者による参加者へのプレゼンタ・ステータスの割当て）などのアクションも含めて、この会議中に発生したすべてのイベントがリストされます。完了済の各ログ・ファイルは、「システム」タブの「ログ」でも参照できます。また、「レポート」タブにある、終了した会議のレポートでも参照できます（詳細は、「Web会議レポート」を参照してください）。
「インスタンス診断」には、Oracle Real-Time Collaborationサーバー・プロセスの実行過程の詳細が表示されます。 この情報を使用して、現行のプロセスを管理したり、必要に応じてこのページから直接プロセスを終了できます。このレポートは、「レポート」タブにある、終了した会議のレポートにも含まれています。
「詳細」ページの「参加者」タブをクリックすると、この会議に参加している参加者のリストが表示されます。参加者名の隣の「参加者の詳細」をクリックすると、参加者が会議に参加している時間、匿名で参加しているか、会議に再接続する必要があったか、音声ストリーミングを使用しているかなど、詳細を表示できます。また、参加者が会議へ接続するために使用したコンピュータのオペレーティング・システムと画面解像度、およびクライアントの接続で使用した接続タイプも表示できます。
runTestsコマンドを使用すると、Oracle Real-Time Collaborationシステムが適切に構成されているかどうかを確認できます。これらのテストはインストール後、実行は一度のみで定期的に実行する必要はありません。次の項では、各テストについて、および各テストの実行で使用するオプションについて説明します。
runTestsコマンド、およびそのオプションの構文の詳細は、「システムのテストと監視」を参照してください。
次の項では、この構成のテストについて説明します。
電子メールの構成テスト（emailtestオプション）
Oracle Real-Time Collaborationサービスの可用性を個別にテストする追加のrunTestsコマンド・オプションの詳細な使用方法は、「サービスの可用性の監視」を参照してください。
会議の開催者が予定された会議の招待を電子メールで送信するには、管理者が、Oracle Web Conferencingのプロパティを使用してエンタープライズSMTPホストおよびポートを設定する必要があります。 これらのプロパティが設定されていて、Oracle Real-Time Collaborationのアプリケーション層からSMTPサーバーにアクセスできるかどうかは、emailtestオプションによって確認できます。
このテストに失敗した場合は、「Oracle Real-Time Collaborationの電子メールと管理の設定」の手順に従ってください。
「システム」タブにある構成のステータス・レポートには、このOracle Real-Time Collaborationシステムのホストすべての現行設定が表示されます。 ここには、ホスト名、サービスのタイプ、デプロイ情報（ホストがイントラネット、インターネット、DMZのいずれであるか）、インスタンスが存在する場合はインスタンスの場所、オペレーティング・システム、ハードウェア情報（プラットフォーム、CPU、メモリー合計）が表示されます。このレポートには「編集」ボタンもあります。これを使用すると、表示された各サーバーについて、いくつかのプロパティを対話的に編集できます。サービスを削除するための「削除」ボタンもあります。
「システム」タブは、ビジネス管理者ロールのユーザーのみが使用できます。ユーザー・ロールの設定の詳細は、「ユーザー・ロールの設定」を参照してください。
この項では、Oracle Real-Time Collaborationの監視インタフェースについて説明します。このインタフェースは任意の監視インフラストラクチャにプラグインできます。監視インタフェースには、次の2つのタイプがあります。
rtcctlインタフェース。Oracle Real-Time Collaborationの主要なコンポーネントに関する監視データを取得するためのインタフェースです。
サーブレット・インタフェース。サービスの可用性を監視するためのインタフェースです。
rtcctl getMonitorStats -publish trueコマンドを使用して、監視インフラストラクチャに出力するためのコンポーネントの統計をXML形式で収集します。 収集された統計の詳細は、「コンポーネントの監視」を参照してください。
デフォルトでは、rtctest.jspを使用すると、管理者権限を持った認証済ユーザーとしてサーブレットを実行できます。 認証なしでサーブレットを実行する場合は、RtcTestServletプロパティをtrueに設定し、http://host:port/imtapp/RtcServiceTestsを使用する必要があります。
この設定が有効な場合、RtcServiceTestsを使用すると、runTestsコマンドのサービス・テストは任意の監視インフラストラクチャで実行できます。 RtcServiceTestsはAPIのように機能します。これにより、Oracle Real-Time Collaborationのすべてのテストが、Webアプリケーションとして、HTTPベースのWebアプリケーション監視の対象になります。このサーブレットは、標準のHTTPベースの監視クライアントからアクセス可能で、その結果は自動的に分析できるように設計されています。
生成するWebベースのレポートをこのページから選択することにより、監視インフラストラクチャの結果が「レポート」タブの「可用性」サブタブの下に表示されます。 詳細は、「可用性レポートの構成」を参照してください。
rtctest.jspおよびRtcServiceTestsのどちらも、表5-1に示す入力パラメータを使用し、同じ結果を生成します。
認証済ユーザー（businessadmin権限を持った管理者など）としてサーブレットを実行する場合は、次のようにrtctest.jspを使用します。
http://host:port/imtapp/app/rtctest.jsp?alltests=true
認証なしでサーブレットを実行する場合は、RtcTestServletプロパティをtrueに設定し、次のようにRtcServiceTestsを使用する必要があります。
http://host:port/imtapp/app/RtcServiceTests?alltests=true
セキュリティ上の理由から、デフォルトでは、RtcServiceTestsへのアクセスは無効です。 有効にする場合は、Oracle HTTP Serverアクセス制御または他のメカニズムを使用してRtcServiceTestsへのアクセスを制限することをお薦めします。
説明: RtcServiceTestsを実行可能にするかどうかを設定します。
デフォルト値: false
有効な値: true/false
有効範囲: システム
例: 認証なしでRtcServiceTestsへのアクセスを有効にするには、次のようにプロパティをtrueに設定します。
rtcctl> setProperty -pname RtcTestServlet -pvalue true -system true
サーブレットは、クライアントから送信されるHTTPリクエストからすべての入力情報を取得します。サーブレットは、URL問合せ文字列、またはPOST本体のいずれかからパラメータを受け取ります。
入力パラメータは、実行するテスト、および成功または失敗の場合に戻される情報を制御します。表5-1に、すべての入力パラメータを示します。
表5-1 サーブレットに対する入力
| テスト名 | オプション | デフォルト | 機能 |
|---|---|---|---|
|
alltests |
true/false |
false |
サーブレットでサポートされるすべてのテストを実行します（他のテストの選択パラメータは無視されます）。 |
|
mtgtest |
true/false |
false |
エンドツーエンドの会議テストを実行し、会議の機能が使用できるかどうかを確認します。 |
|
voiceconvtest |
true/false |
false |
音声変換サーバーのテストを実行し、会議で音声サポートが使用できるかどうかを確認します。 |
|
docconvtest |
true/false |
false |
ドキュメント変換サーバーのテストを実行し、ドキュメント変換が使用可能かどうかを確認します。 |
|
dbtest |
true/false |
false |
Oracle Real-Time Collaborationのリポジトリ・テストを実行し、リポジトリが使用可能かどうかを確認します。 |
|
imtest |
true/false |
false |
Oracle Messengerのエンドツーエンド・テストを実行し、メッセージ・サービスが使用できるかどうかを確認します。 |
|
errorcode |
有効な任意のHTTPレスポンス・コード |
500 |
選択したテストのいずれかが失敗したときに送信される、HTTPレスポンス・コードを設定します。 |
|
successcode |
有効な任意のHTTPレスポンス・コード |
200 |
選択したテストがすべて成功したときに送信される、HTTPレスポンス・コードを設定します。 |
|
errormsg |
任意の文字列 |
null |
選択したテストのいずれかが失敗したときに、レスポンス本文にメッセージを含めます。（注意: レスポンス本文には、追加のテキストを含めることができます。） |
|
successmsg |
任意の文字列 |
Test(s) successful. |
選択したテストがすべて成功したときに、レスポンス本文にメッセージを含めます。（注意: レスポンス本文には、追加のテキストを含めることができます。） |
サーブレットは、結果をHTTPレスポンスで提供します。結果が戻されるのは、選択したすべてのテストが成功した場合、またはいくつかのテストが失敗した場合です。複数のテストが入力パラメータで選択されていた場合、結果にはどのテストが失敗したかの詳細は戻されません。また、失敗に関連したメッセージも戻されません。
1つ以上のテストの結果は、HTTPレスポンス・コード、およびレスポンス本文に戻される静的文字列（オプション）の両方に反映されます。
このテストでは、複数のテストを実行する場合、集計結果のみが戻されるため、詳細な結果が必要な場合は、複数のテストを実行する際、各テストから個別にサービス可用性テストを呼び出します。システムの動作状態のみを確認する場合は、alltestsオプションを使用してテストを1つのみ実行します。
次に、テスト・サーブレットによる結果の例をいくつか示します。
http://host:port/imtapp/app/rtctest.jsp
このテスト・サーブレットが適切にインストールされているが、テストを実行していないことを確認します。
http://host:port/imtapp/RtcServiceTests
このテスト・サーブレットが適切にインストールされているが、テストを実行していないことを確認します。 RtcServiceTestsは、デフォルトでは無効なため、RtcTestServletプロパティをtrueに設定して使用する必要があります。
http://host:port/imtapp/RtcServiceTests?alltests=true
テストをすべて実行し、標準エラー（500）または成功（200）のコードを戻します。
http://host:port/imtapp/RtcServiceTests?mtgtest=true&errorcode=404
エンドツーエンドの会議テストのみを実行し、テストが失敗した場合は404のコードを戻します。
http://host:port/imtapp/RtcServiceTests?mtgtest=true&voiceconvtest=true&errormsg=mtgorvoicefailed
会議テストおよび音声テストを実行し、失敗時はカスタム・メッセージを標準の500レスポンス・コードとともにレポートします。
現行のサーブレットには、次のような制約があります。このサーブレットはOC4J_imeetingプロセス内で実行されるため、OC4J_imeetingにはアクセスができないので、Oracle Real-Time Collaborationコンポーネント（Web Conferencingやドキュメント変換サーバーなど）内での障害は詳細に検出できません。ただし、この制約は大きな問題ではありません。OC4J_imeetingが、すべてのOracle Real-Time Collaborationサービスを管理する役割を持っているためです。OC4J_imeetingにアクセスできないということは、クライアントからOracle Real-Time Collaborationのすべてのサービスにアクセスできないことと同じです。
Oracle Application Server Containers for J2EE（OC4J）が停止している間、OC4Jコンテナは、このテスト・サーブレットまたはなんらかのテストを実際に呼び出さずに、レスポンス・コード200と444のサイズを持つ本文を送信することがあります。戻されるメッセージは、このサーブレットがロードされていないことに関しての一般的なメッセージになる場合がほとんどです。 標準のテスト成功コードは200であるため、監視アプリケーションは、この結果を、テストが成功したものと間違って解釈する場合があります。
OC4Jの動作が変更される可能性はほとんどありません。 かわりに、監視アプリケーションで次のいずれかを行う必要があります。
実際のレスポンス本文を検索して、テストが実際に行われたかどうかを確認します。<test-failure-count>0を検索できれば、テストが実行され失敗しなかったことが明確に確認されます。
監視アプリケーションをカスタマイズし、successcodeの問合せ文字列パラメータを使用して、テストが成功した場合に200以外のレスポンス・コードが戻されるようにします。たとえば、テストが実際に成功したことを示すために、まだ割り当てられていないHTTP成功コード299を使用します。 次に、299以外のコードがテスト失敗とみなされるように、監視アプリケーションを構成する必要があります。たとえば、次のようにします。
http://host:port/imtapp/RtcServiceTests?alltests=true&successcode=299
成功時に別のレスポンス・コードを認識したり、レスポンス本文で特定のパターンを検索するように、監視アプリケーションをカスタマイズできない場合は、OC4Jの停止時の監視アプリケーションの結果は信頼できないものとして処理する必要があります。 OC4Jの停止中はOC4Jが一時的に使用できなくなるため、この停止中のテストは失敗すると予想されますが、停止の前後に成功したテストも同様にこれらの条件では信頼性が低くなります。
