| Oracle® Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド 11g リリース 1 (11.1.1) B61375-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド 11g リリース 1 (11.1.1) B61375-04 |
|
前 |
次 |
Oracle Reportsサービスは、Oracle Fusion Middlewareのレポート・パブリッシング・コンポーネントです。これは、高品質の稼働レポートを生成するためのエンタープライズ・レポート作成サービスです。これによって、任意のデータを動的に取得し、任意の形式で書式設定し、任意の場所で配布します。Oracle Reportsサービスを使用して、Webベースと非Webベースの両方の環境で公開できます。
この項では、Oracle Reports Servicesについて詳しく説明します。
拡張性と柔軟性に優れたアーキテクチャを備えるOracle Reports Servicesでは、レポート生成エンジンを同じサーバーや複数のサーバーに分散して自動的に管理します。また、同様のリクエストが発行された際に再利用できるよう、レポート出力をキャッシュします。これは、JSP、JavaサーブレットおよびWebサービスを使用する標準Web環境に統合されます。また、ローカルとリモートの両アプリケーション・サーバーでのレポート実行、およびレポート実行用に複数層アーキテクチャの実装が可能です。
Oracle Reports ServicesをJSP、JavaサーブレットまたはWebサービスと組み合せて使用すると、Webブラウザから標準的なURL構文を使用して任意のプラットフォームでレポートを実行できます。Oracle Reports Servlet (rwservlet)を実装する場合は、レスポンスが高速で管理が簡単なインプロセスReports Serverを使用できます。インプロセスReports Serverにより、複数のプロセス間における通信コストが削減され、結果的にレスポンス時間が短縮します。
Oracle Reports Servicesでは、すべてのジョブ・リクエストを1つのジョブ・キューに格納してレポートを実行するようクライアント・リクエストを処理します。いずれかのサーバーのエンジンが使用可能になると、キューで待機している次のジョブが実行されます。キューのジョブ数が増えると、サーバーはエンジンをサーバー構成で指定した最大数まで増やすことができます。同様に、指定したアイドル時間(第8章「Oracle Reports Servicesの構成」を参照)が経過するとエンジンは自動的に停止します。
Oracle Reports Servicesでは、実行中のジョブ、実行予定のジョブ、終了したジョブ、失敗したジョブなど、サーバーに送信されたすべてのジョブを追跡します。showjobsのWebコマンド(rwservletから)、Webサービスのインタフェース、Oracle Enterprise ManagerのOracle Reports Servicesページ、Reports Queue Manager (Windows)およびReports Queue Viewer (UNIX)により、ジョブのスケジューリング、キューイング、開始、終了およびエラーの時刻情報だけでなく、ジョブ出力やレポートの最終ステータスに関する情報も表示できます。
Oracle Reports Servicesのジョブ情報は永続的です。このため、Reports Serverがいったん停止してから再起動した場合は、スケジュールされたジョブだけではなく、すべてのジョブが回復されます脚注 1 。
Web環境で使用する場合、Oracle Reports Servicesのアーキテクチャは次の4つの層で構成されます。
|
注意: 層という用語は、Oracle Reports Servicesアーキテクチャを構成するコンポーネントの論理場所を表します。ただし、各層を同じマシンに配置することも、異なるマシンに配置することもできます。 |
クライアント層(Webブラウザ)
Webサーバー層
Oracle Reports Services層
データ層(データベースおよびその他すべてのデータソースを含む)
非Web環境で使用する場合は、次の3つの階層で構成されます(Webサーバーが不要になります)。
クライアント層
Oracle Reports Services層
データ層(データベースおよびプラガブル・データソースを含む)
クライアント・ソフトウェアは次のものになる場合があります。
rwclient
ブラウザ
これらの層の設定方法は、すべての階層を同一マシン上に設定する方法や各階層をすべて別のマシン上に設定する方法などがあります。また、複数のマシンに複数のWebサーバーをインストールしたり、複数のマシンに複数のアプリケーション・サーバーをインストールすることもできます。サンプル・トポロジの詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』を参照してください。
Webサーバーを複数のマシンにインストールすると、複数のOracle Fusion Middlewareインスタンスをクラスタ化してロード・バランシングを行い、可用性の高いフェイルセーフ環境を実現できます。
|
注意: HA Reports Serverからジョブをコールする際は「 ロード・バランシングの詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』を参照してください。エンタープライズ・デプロイメント・アーキテクチャと高可用性の詳細は、『Oracle Fusion Middleware Java EEエンタープライズ・デプロイメント・ガイド』および『Oracle Fusion Middleware高可用性ガイド』を参照してください。 |
Oracle Reports Servicesにより、イベント・ベースのレポートを実現します。この方法では、データベース・イベントを使用して、レポート生成を実行します。たとえば、収益レベルが特定の水位標を上回った(下回った)という変更を通知するイベントを定義できます。データベースでこの変更(イベント)が発生すると、レポートが自動的に生成されます。この機能の詳細は、第21章「イベント・ドリブンによる公開の使用」を参照してください。
Oracle Reports Servicesには、XMLを使用してレポート配布用に独自構成を定義する配布モジュールが付属しています。必要なXMLファイルをランタイム・コマンドラインまたはURLからコールしてレポートを1つ生成すれば、多様な出力と宛先の処理がサーバーにより実行されます。処理時間が大幅に短縮され、構成変更はすべてXMLファイル内で処理できます。この機能の詳細は、第20章「拡張配布の作成」を参照してください。
図2-1は、稼動中のOracle Reports Services環境のコンポーネントを示しています。これには次のものが含まれます。
Oracle HTTP Server。これは、Oracle Fusion Middlewareで提供されるWebサーバーです。これには、OpenSSLモジュールが組み込まれており、Secure Sockets Layer (SSL)およびHTTP Secure Sockets Layer (HTTPS)がサポートされます。また、Javaサーブレット・アプリケーションの実行をサポートするサーブレット・エンジンも備えています。
モジュールmod_weblogic。Oracle HTTP Serverは、これを使用してサーブレットやJSPからのリクエストをOracle WebLogic Serverにリダイレクトします。WebLogic Serverは、JSPトランスレータ、JSPサーブレット・エンジン(OJSP)およびEnterprise JavaBeans (EJB)コンテナを備え、完全なJava EE環境を実現します。また、高速、軽量、拡張性、操作の容易性を備え完全なJava EE環境を実現します。すべてJavaで記述されており、標準のJava Development Kit (JDK)仮想マシン(JVM)上で動作します。
モジュールmod_osso。Oracle HTTP Serverは、これを使用してシングル・サインオン・サーバーに接続します。それにより、シングル・サインオン・サーバーがOracle Internet Directoryを使用します。
Oracle Reports Servlet (rwservlet)。これは、Webサーバーのサーブレット・エンジン内で実行されるOracle Reports Servicesのコンポーネントです。Oracle Reports Servlet (rwservlet)は、HTTPとReports Serverとの間で情報を変換して配布します。認証にはSingle Sign-On Serverが使用されます。Oracle Reports Servletには、次のものが含まれます。
インプロセスReports Server。これにより、クライアントから最初のリクエストをrwservletまたはReports JSP経由で受信するたびにサーバーを自動的に起動することで、Reports Serverのメンテナンスと管理が軽減されます。
Custom Tag Handler。これは、JSPファイルに含まれるOracle Reportsカスタム・タグを処理します。JSPファイルでは、接頭辞のrw:によってOracle Reports関連のカスタム・タグが識別されます。これ以外の接頭辞が使用されるその他のカスタム・タグが存在することもあります。
Reports Server (rwserver)。これはクライアント・リクエストを処理します。この処理ではクライアント・リクエストを、セキュリティ(認証と認可)、ジョブのスケジューリング、キャッシュ処理、公開、および一括処理と配布(カスタムの宛先やプラガブル宛先への配布を含む)などの様々なサービスに割り当てます。
セキュリティ・サービスの認証は、次の方法に基づいています。
Oracle Internet Directory
Java Platform Security (JPS) Oracle Internet Directory
Java Platform Security (JPS)を使用したLDAPベースのIDストア
セキュリティ・サービスの認可は、次の方法に基づいています。
Java Platform Security (JPS) Oracle Internet Directory
XMLファイルベース
Portalベース
一括処理および配布サービスを使用すると、ワイヤレス、プリンタ、FTPサーバー、ポータル、WebDAV、ブラウザ、電子メールなどの多様な宛先にレポートを配布できます。公開サービスでは、PDF、HTML、XML、スプレッドシートなどの様々な出力形式でレポートが公開されます。
また、Reports Serverでは、リクエストされたレポートを生成するランタイム・エンジンを起動したり、生成されたレポートをReports Serverキャッシュから取り出したり、ジョブの準備完了をクライアントに通知します。レポート出力は、Reportsキャッシュまたは物理ディスクに保存できます。
Reports Serverキャッシュ。これには、完了済のジョブ出力がセキュアに格納されます。
Reports Engine。これには、SQLベースおよびプラガブル・データソースベースのレポートを実行するコンポーネントが含まれます。リクエストされたデータをデータ・ソースから取り出したり、レポートをフォーマットしたり、出力をキャッシュに送信したり、ジョブの完了をReports Serverに通知します。Reports Engineには、テキスト、データベース、JDBC、OLAP、XML、Webサービスなどのカスタム・データ・ソースであるプラガブル・データ・ソースも組み込まれています。
プラガブル・データ・ソース。これは、設計時および実行時の一連のJava APIで、PDS Javaインタフェースの実装を介して多数のソースからデータを入力できるようにすることで、Reportsにオープン性が備わります。PDS機能を使用すると、開発者はSQLを介してアクセスするデータ以外にだけでなく、他の場所で使用できるデータに対しても、Reportsの集約、合計、フォーマットおよびスケジューリング機能を利用できます。
プラガブル・エンジンは、Java APIを使用してジョブをReports Serverに渡すカスタム・エンジンであるだけでなく、スケジューリング、配布、通知、キャッシュ処理などのサーバー機能を活用するカスタム・エンジンでもあります。Oracle Reports Servicesにより、URLエンジンと呼ばれ即座に使用できるプラガブル・エンジンを実現します。URLエンジンにより、公開URLのコンテンツを電子メール、Oracle Portal、WebDAVなどの宛先に配布できます。
図2-1には、Reports Serviceのコンポーネントの他に次の事項も示されています。
Reports J2EEアプリケーションのWebサービス・モジュールを介したOracle Reportsとサービス指向アーキテクチャ(SOA)との統合
Oracle FormsとOracle Reportsとの通信
監視、スケジューリング、セキュリティ・ポリシー、フォントの設定、構成など、タスクの管理および処理を実現するEnterprise ManagerのReports固有のモジュール
さらに、Oracle Reports Bridgeは、複数のファームにおいてReports Serverを検出する機能を実現します。Reports ServerやReports Clientが複数のファームにおいてブロードキャストするパケットのゲートウェイとして、Oracle Reports Bridgeは機能します。図2-1にはOracle Reports Bridgeのメカニズムが示されていません。詳細は、第2.3.4.1.2項「複数のサブネットにわたるサーバーの検出」を参照してください。
Oracle Reports Servicesの各種コンポーネントがレポートの実行プロセスで果たす役割は、次のとおりです。
クライアントは、URL (Web)を使用したり、Webを使用せずにOracle Reports関連コマンド(rwclientなど)を使用して、サーバーに接続しレポートをリクエストします。
URLによる方法では、JSPまたはrwservletにリダイレクトされます。これはどちらもOracle HTTP Serverに関連付けされます。リクエストはmod_weblogicにリダイレクトされます(JSPとして実行されるジョブでは、mod_weblogicでOJSPを使用してJSPをサーブレットに変換)。
URLには、cgicmd.datキー・マップ・ファイル(詳細は第18.13項「キー・マップ・ファイルの使用」を参照)内のランタイム・パラメータ構成セクションを参照するランタイム・パラメータやキーワードを含めることができます。両方を含めることもできますが、URLで明示的に指定されているパラメータがcgicmd.datの関連キーワード・セクションに存在していないことも要求されます。
rwclientは、Reports Serverに直接リダイレクトされます。
コマンドラインには、ランタイム・パラメータを指定できます。ランタイム・パラメータが多数ある場合には、rwclientコマンドとパラメータ文字列を含むバッチ・ファイルまたはシェル・スクリプトを作成できます。
rwservletコンポーネントは、WebサーバーやJava EEコンテナ(Oracle WebLogic Serverなど)とReports Serverとの間で情報を変換して配布します。
Reports JSPやrwservletからのサーバー・リクエストは、インプロセスReports Serverで実行することも、スタンドアロンのReports Serverプロセス(推奨)として実行することもできます。どちらで実行する場合も、Oracle Reports Servlet (rwservlet)の構成ファイル(DOMAIN_HOME/config/fmwconfig/servers/<WLS_SERVER_NAME>/applications/reports_<version>/configuration//rwservlet.properties)で指定します。インプロセスReports Serverは、スタンドアロンのReports Serverとは異なり、クライアントからのリクエストに応答して自動的に起動するため、メンテナンスが軽減されます。インプロセスReports Serverにより、複数のプロセス間における通信が削減されます。一方、スタンドアロン・サーバーは、WebLogic Serverインスタンスからサーバー・プロセスを切り離すことで、rwservletプロセスの外部の制御を強化します。インプロセスReports Serverとデフォルトのネーミングの指定の詳細は、第8.3項「Oracle Reports Servlet構成ファイル」を参照してください。
Reports Serverは、次のようにリクエストを処理します。
リクエストにTOLERANCEオプションが指定されている場合は、Reports Serverがキャッシュを調べて、そのリクエストを満たす出力がすでに存在しているかどうかを判別します。キャッシュ内にリクエストを満たす出力があった場合、サーバーはレポートの再実行よりも、その出力を返すことを優先して行います。
|
注意: Reports Serverに送るジョブ・リクエストには、 |
リクエストが現在実行中のジョブと同じ場合、そのリクエストは、レポートを再実行せずに現在のジョブの出力を再利用します。
これらの条件が満たされない場合は、次のように処理が実行されます。
Oracle Reports Servlet (rwservlet)がSSO対応の場合、認証が確認されます。次に、セキュアなReports Serverによって、Oracle Internet Directoryを使用してユーザーが認可されます。Oracle Reports Servlet (rwservlet)がSSO対応でない場合は、セキュアなReports Serverによってユーザーの認可と認証が行われます。
レポートがスケジュールされていると、スケジュールされたジョブ・キューにReports Serverはリクエストを格納し、スケジュールに従ってレポートが実行されます。レポートがスケジュールされていなければ、リクエストは現在のジョブ・キューに挿入され、Reports Engineが利用可能になった時点で実行されます。
実行時、Reports ServerはReports Engineを起動し、実行対象のリクエストをそのエンジンに送ります。
Reports Engineは、データを取り出し、フォーマットします。
Reports Engineは、Reports Serverキャッシュに書き込みます。
Reports Engineは、レポートの準備が完了したことをReports Serverに通知します。
URL、コマンドラインまたはcgicmd.datファイルのキーワード・セクション(URLリクエストのみ)で指定されたランタイム・パラメータに従って、Reports Serverがキャッシュにアクセスし、出力するレポートを送ります。
また、イベント・ドリブンの公開を使用してレポートを作成することもできます。イベント・ドリブンの公開では、クライアントはエンド・ユーザーではなくデータベースです。イベントは、Event-Driven Publishing APIで定義されます。イベントは、Event-Driven Publishing APIをコールするデータベース・トリガー、アドバンスト・キューイング・アプリケーションまたはPL/SQLパッケージを起動して、ジョブをReports Serverに送ります。イベント・ドリブンの公開の詳細は、第21章「イベント・ドリブンによる公開の使用」を参照してください。
Oracle BPEL Process Managerでレポートを実行する方法の詳細は、第8.10項「Oracle ReportsとOracle BPEL Process Managerとの通信の構成」を参照してください。
Oracle Reportsでは、Borland社のVisiBrokerにかわって業界標準であるSun社のJava Developer's Kit Object Request Broker (JDK ORB)が使用されます。これによって、複数のサブネットにわたるクライアントからのReports Serverリクエストがサポートされるだけでなく、ブロードキャスト・メカニズムを使用してサブネット内外で動的にReports Serverが検出されます。
Oracle Reports 11g リリース(11.1.1)では、特別な設定が不要なビルトイン・ブロードキャスト・メカニズムを使用してReports Serverを動的に検出できます。Sun社のJDK ORBで実現されるCommon Object Service (COS)ネーミング・サービスのorbdを使用してもReports Serverを検出できます。
|
注意: Reports Serverの動的検出ではビルトインのブロードキャスト・メカニズムを使用することをお薦めします。次の例のように、ビルトインのブロードキャスト・メカニズムが使用環境に適さない場合にのみ、Reports Serverの検出にCommon Object Service (COS)ネーミング・サービスを使用してください。
|
この項では、次の2つのReports Server検出方法について説明します。
|
注意: Oracle Reports 11g リリース(11.1.1)には、JDK ORB実装を診断する |
ブロードキャスト・メカニズムを使用すると、1つのサブネット内または複数のサブネットにわたってReports Serverを検出できます。
|
注意: Oracle Reportsのビルトイン・ブロードキャスト・メカニズムでは、ホスト・マシンがネットワーク内に存在する必要があります。この制約によって、ブロードキャスト・メカニズムが機能しない可能性のある例を2つ、それぞれの解決策とあわせて次に示します。
|
サブネット内で、接続先Reports Serverの名前を指定したパケットをクライアントはブロードキャストします。指定された名前のReports Serverがネットワーク上にある場合は、レスポンスが返されます。次に、クライアントはレスポンスを返したReports Serverに接続して、レポート・リクエストを実行します。
rep_serverという名前のサーバーに対してレポート・リクエストを実行する例を次に示します。各手順の番号は図2-2の番号に対応しています。
getServerRef
Oracle Reportsクライアント(rwclient、rwservletまたはrwrqmなど)は、接続先サーバーの名前を含むパケットをブロードキャストします。この例では、パケットにrep_serverという名前が含まれます。
ネットワーク内のrep_serverという名前のサーバーが、Interoperable Object Reference (IOR)でレスポンスを返します。
クライアントは、このIORをオブジェクト参照に変換します。
runReport
Oracle Reportsクライアントは、レポートを実行するように、リモートのオブジェクト参照にリクエストを送信します(IIOPコール)。
executeReport
Reports Serverではレポートを実行して、レポートまたはステータスを返します。
Oracle Reportsでは、セキュアでないサブネットを複数接続するOracle Reports Bridgeメカニズムが用意されています。あるサブネットで実行しているOracle Reports Bridgeが別のサブネットで実行しているOracle Reports Bridgeに接続して、Reports Serverの参照を取得します。構成の詳細は、「Oracle Reports Bridgeの構成要素」を参照してください。
rep_serverという名前のサーバーに対してレポート・リクエストを実行する例を次に示します。各手順の番号は図2-3の番号に対応しています。
getServerRef
Oracle Reportsクライアント(rwclient、rwservletまたはrwrqmなど)は、接続先サーバーの名前を含むパケットをブロードキャストします。この例では、パケットにrep_serverという名前が含まれます。
bridge1はパケットを傍受してbridge2に渡します。
registerServerRef
bridge2はdom2でパケットをブロードキャストし、dom2のrep_serverはInteroperable Object Reference (IOR)でレスポンスを返します。
bridge2は返されたIORをbridge1に渡し、bridge1はブロードキャスト・メカニズムを使用してこれをクライアントに渡します。
Oracle Reportsクライアントは、このIORをオブジェクト参照に変換します。
runReport
Oracle Reportsクライアントは、レポートを実行するように、リモートのオブジェクト参照にリクエストを送信します(IIOPコール)。
executeReport
Reports Serverではレポートを実行して、レポートまたはステータスを返します。
JDKで提供されるCommon Object Service (COS)ネーミング・サービスを使用して、同じサブネット内のReports Serverにアクセスしたり、セキュアでないサブネットにわたってReports Serverにアクセスしたりすることもできます。ネーミング・サービスを構成するには、第8.5.1項「ネットワークの構成要素」を参照してください。
|
注意: Reports Serverの動的検出ではビルトインのブロードキャスト・メカニズムを使用することをお薦めします。次の例のように、ビルトインのブロードキャスト・メカニズムが使用環境に適さない場合にのみ、Reports Serverの検出にCommon Object Service (COS)ネーミング・サービスを使用してください。
|
OPMNを使用してCOSネーミング・サービスを制御するには、第8.8.1.4項「COSネーミング・サービスの指定」を参照してください。
rep_serverという名前のサーバーに対してレポート・リクエストを実行する例を次に示します。各手順の番号は図2-4の番号に対応しています。
registerServer
起動時、rep_serverは自身をネーミング・サービスに登録します。ネーミング・サービスは、サーバーを起動するために必ず稼動させておく必要があります。これで、rep_serverに対してリクエストが実行されるようになります。
getServerRef
Oracle Reportsクライアントは、ネーミング・サービスに接続してserver rep_serverへの参照をリクエストします。
ネーミング・サービスは、参照をrep_serverに返します。
runReport
Oracle Reportsクライアントは、レポートを実行するように、リモートのオブジェクト参照にリクエストを送信します(IIOPコール)。
executeReport
Reports Serverではレポートを実行して、レポートまたはステータスを返します。
脚注の凡例
脚注 1: この場合、同期ジョブおよび現在実行中のジョブのみが消失します。
