ヘッダーをスキップ

Oracle Applications概要
リリース12
E05390-02		目次へ
目次		前のページへ
前へ		次のページへ
次へ

Oracle Applicationsアーキテクチャ

概要

ここでは、Oracle Applicationsアーキテクチャおよびこのアーキテクチャでサポートされている機能の一部について説明します。構成は次のとおりです。

Oracle Applicationsアーキテクチャは、Oracle Applications製品をサポートする、複数層から構成された分散コンピューティングのフレームワークです。このモデルでは、様々なサーバーまたはサービスが3つのレベル（層）に分散されています。

サーバー（またはサービス）は、単一のマシン上で実行され特定の機能を提供するプロセスまたはプロセス・グループです。 たとえば、WebサービスはHTTP要求を処理し、FormsサービスはOracle Formsに関連したアクティビティに対する要求を処理します。コンカレント処理サーバーは、バックグラウンドで実行されるデータ集中プログラムをサポートします。

重要: サーバーという用語は、単一プロセスという意味では、リリース12のアーキテクチャではあまり適切ではありません。該当する場合は、サービスなどの用語がかわりに使用されます。

層とは、複数の物理マシンにまたがることもある、サービスの論理グループです。 Oracle E-Business Suiteインストールを構成する3層アーキテクチャは、Oracleデータベースをサポートおよび管理するデータベース層、様々なApplicationsコンポーネントをサポートおよび管理し、中間層とも呼ばれるアプリケーション層、および標準Webブラウザへの追加コンポーネントを介するユーザー・インタフェースを提供するデスクトップ層から構成されています。

マシンは、特に1つのクラスタ内で密接に動作しているコンピュータ・グループの意味でノードとも呼ばれます。各層は1つ以上のノードで構成され、各ノードには複数の層を含めることができます。 たとえば、テスト・システムのデータベースは、1つ以上のアプリケーション層コンポーネントとして同一ノード上に常駐できます。ただし、ノードはソフトウェアの概念でもあり、サーバーの論理グループを指していることに注意してください。

Oracle Applicationsソフトウェアをアプリケーション層に集中管理することにより、各デスクトップ・クライアントPC上でアプリケーション・ソフトウェアをインストールおよび保守する必要がなくなります。この概念をさらに発展させると、共有アプリケーション層ファイル・システム・モデル（元は共有APPL_TOP）を使用する主な利点の1つが、アプリケーション層の各マシン用のコピーではなく、関連するApplicationsコードの単一のコピーのみを保守すれば良いという点になります。

データベース層では、可用性とスケーラビリティを向上させるために複数ノードで単一のデータベース・インスタンスをサポートするOracle Real Application Clusters（Oracle RAC）環境の使用が増加しています。

図1-1 Oracle Applicationsアーキテクチャ

本文の説明内容に関するイメージ

アプリケーション層とデスクトップ層間の接続は、広域ネットワーク（WAN）経由で運用できます。 これは、デスクトップ層とアプリケーション層間では、変更されたフィールド値のみなど必要最小限の情報が交換されるためです。 様々な場所のユーザーとグローバルな操作を行う場合、ネットワークの通信量の需要が少ないほど、通信費の節減になり、応答時間も短縮されます。

デスクトップ層

クライアント・インタフェースは、HTMLベース・アプリケーション用のHTMLと、従来のFormsベース・アプリケーション用のWebブラウザのJavaアプレットを介して提供されます。

図1-2 Formsベース・デスクトップ層アーキテクチャ

本文の説明内容に関するイメージ

Oracle Applicationsリリース12では、各ユーザーは、デスクトップ・クライアントWebブラウザ上のE-Business Suiteホーム・ページを介して、Oracle Applicationsにログインします。E-Business Suiteホーム・ページでは、1箇所からHTMLベース・アプリケーション、Formsベース・アプリケーションおよびBusiness Intelligenceアプリケーションにアクセスできます。

E-Business Suiteホームにログインすると、再度サインオンすることなくシステムの他の部分にアクセスできます。Oracle Applicationsでは、他のツールや製品にナビゲートするときも、ユーザー名およびパスワードを要求するプロンプトは再表示されません。また、システム内をナビゲートする際に作業環境が保存されます。たとえば、E-Business Suiteホーム・ページにドイツ語を優先言語として登録した場合、Formsベース製品またはHTMLベース・アプリケーションのどちらにアクセスしても、この作業環境は維持されます。

図1-3 Oracle E-Business Suiteホーム・ページの例

本文の説明内容に関するイメージ

Formsクライアント・アプレット

Formsクライアント・アプレットは、Oracle ApplicationsのすべてのFormsベース製品（カスタマイズおよび拡張された製品を含む）をサポートする汎用プレゼンテーション・アプレットです。Formsクライアント・アプレットは、Javaアーカイブ（JAR）ファイル・コレクションとしてパッケージされています。JARファイルには、Oracle Applicationsフォームのプレゼンテーション・レイヤーを実行するために必要なすべてのJavaクラスが含まれます。

デスクトップJavaクライアント

Formsクライアント・アプレットは、デスクトップ・クライアント上のJava仮想マシン（JVM）内で動作する必要があります。Sun社のJ2SE Plug-inコンポーネントでは、ブラウザ自体のJVMのかわりに、Oracle JVMをWebクライアント上で使用できます。これはブラウザ・プラグインとして実装されます。

従来のFormsベースOracle Applications環境の場合、JVM（旧リリースではOracle JInitiator）は、標準Applicationsサインオン・プロセスの一部として実行されていました。現在では、主としてHTMLベース環境への移行に伴い、JVM（現在はJ2SE Plug-in）は、ユーザーがフォームの実行などJVMを必要とする機能へのアクセスを選択した場合にのみ起動されます。J2SE Plug-inがインストールされていない場合、ブラウザにより、必要なインストール実行可能ファイルをダウンロードするように要求されます。たとえば、「システム管理者」の職責を選択して「コンカレント・マネージャの定義」を選択すると、次のようなメッセージが表示されます。

このアプリケーションにアクセスするには、J2SE Plug-inバージョン1.5.0_07をインストールする必要があります。このプラグインをインストールするには、ここをクリックしてoaj2se.exe実行可能プログラムをダウンロードしてください。ダウンロードが完了した後、oaj2se.exeファイルをダブルクリックしてプラグインをインストールします。インストールが完了すると、ブラウザを再起動するよう要求されます。

プラグインをダウンロードしてインストールした後、たとえば図1-4に示されているようなFormsベース・アプリケーションを実行できるようになります。

図1-4 Formsベース・アプリケーション・インタフェースの例

本文の説明内容に関するイメージ

Formsクライアント・アプレットおよび通常使用されるJARファイルは、クライアントの最初のセッションの開始時に、Webサーバーからダウンロードされます。使用頻度の低いJARファイルは、必要に応じてダウンロードされます。ダウンロードされたJARファイルは、すべてクライアント上にローカルにキャッシュされ、その後のセッションで使用できます。これにより、必要なたびにJARファイルをダウンロードすることによるネットワーク・トラフィックがなくなります。

リリース12でのキャッシュ・ディレクトリ・パスの書式は次のとおりです。

<HOMEDRIVE>¥Documents and Settings¥<Windows User Name>¥Application Data¥Sun¥Java¥Deployment¥cache

例:

C:¥Documents and Settings¥jalee¥Application Data¥Sun¥Java¥Deployment¥cache

J2SE Plug-inコントロールパネルの「詳細」タブで「コンソールを表示する」を選択すると、JARファイルのダウンロード状態が表示され、実際にダウンロードが実行されているかどうかを確認できます。Javaコンソールを図1-5に示します。

図1-5 Javaコンソール

本文の説明内容に関するイメージ

JARファイルに対するすべての更新は、アプリケーション層にインストールされ、前述のキャッシング手順を利用してクライアントに自動的にダウンロードされます。

注意: Oracle E-Business SuiteでSun社のJ2SE Native Clientを使用する方法の詳細は、OracleMetaLinkのNote 393931.1の「Upgrading Sun J2SE (Native Plug-in) with Oracle Applications 12.0 for Windows Clients」を参照してください。

アプリケーション層

アプリケーション層には、ビジネス・ロジックを処理する様々なサーバーおよびサービス・グループをホストするロールと、デスクトップ層とデータベース層との通信を管理するロールの二重のロールがあります。この層は、中間層とも呼ばれています。

次の4つのサーバーまたはサービス・グループにより、Oracle Applicationsの基本アプリケーション層が構成されます。

注意: リリース12では、WebサービスおよびFormsサービスはOracle Application Server（OracleAS）10g により提供されます。以前のリリースのApplicationsでのような単一プロセスという意味のサーバーではありません。

アプリケーション層で異なるプラットフォームを混合して使用しないようにしてください。単一のプラットフォームで使用すると、ダウンロードする必要のあるパッチが1セットのみになるため、保守が簡単になります。

ロード・バランス

アプリケーション層では、その層内にある多くのサーバーおよびサービスでロード・バランスがサポートされており、可用性、フォルト・トレランス、信頼性および最適スケーラビリティの提供に役立っています。次のタイプのサーバーを複数使用している場合に、ロード・バランスを利用できます。

様々なタイプのロード・バランスの詳細は、第10章「ロード・バランス」を参照してください。

リリース12における2つのApplication Server ORACLE_HOMEの使用

Oracle Applicationsリリース12では、2つの異なるリリースのOracleAS 10g が別々のORACLE_HOMEで使用されます。これにより、Applicationsで最新のOracleテクノロジを活用できます。

図1-6に、2つのApplication Server ORACLE_HOMEの機能的な使用方法を示します。

図1-6 2つのApplication Server ORACLE_HOMEの関係

本文の説明内容に関するイメージ

このアーキテクチャの重要な特徴は次のとおりです。

図1-7に、2つのApplication Server ORACLE_HOMEとデータベースORACLE_HOMEの関係を示します。

図1-7 データベースORACLE_HOMEおよびApplication Server ORACLE_HOME

本文の説明内容に関するイメージ

この高レベル・アーキテクチャの重要な特徴は次のとおりです。

Webサービス

Oracle Application ServerのWebサービス・コンポーネントは、ネットワーク経由でデスクトップ・クライアントから受信した要求を処理します。次のコンポーネントを含んでいます。

Oracle HTTP ServerのWebリスナー・コンポーネントでは、クライアント・ブラウザからの（特定のURLに対する）受信HTTP要求を受け取って、その要求を適切なOC4Jコンテナにルーティングします。

可能な場合、たとえば簡単なWebページを構成するためにHTMLを戻すことで、Webサーバーが要求自体を処理します。このURLで参照されるページに高度な処理が必要な場合、リスナーはサーブレット・エンジンに要求を渡し、必要に応じてサーブレット・エンジンがデータベース・サーバーに接続します。

HTMLベース・アプリケーションおよびOracle Applicationsフレームワーク

Oracle HTMLベース・アプリケーション(旧称「Self-Serviceアプリケーション」)の特徴は、次のとおりです。

Oracle Applicationsフレームワークは、HTMLベース・アプリケーションの開発プラットフォームです。Javaベースのアプリケーション層フレームワークおよび関連サービスから構成され、HTMLベース・アプリケーションの迅速な開発および配置を促進するように設計されています。

重要なOracle Applicationsフレームワーク・コンポーネントには、次のコンポーネントが含まれます。

フレームワークベースのアプリケーション・ロジックは、Apache Jservモジュールによって提供されるJavaサーブレット・エンジンにより実行されるプロシージャによって制御されています。サーブレット・エンジンでは、フレームワークUIを構成する際に、メタデータ・ディクショナリを使用します。

図1-8 HTMLベース・アプリケーション・アーキテクチャ

本文の説明内容に関するイメージ

HTMLベース・アプリケーションによるJavaサーブレット・アクセス

HTMLベース・アプリケーション・モジュールでは、次のアクセス・パスを使用します。

  1. ユーザーはブラウザから機能のハイパーリンクをクリックします。

  2. ブラウザからWebリスナーに対してURL要求が出されます。

  3. WebリスナーはJSPの実行場所であるサーブレット・エンジン（OC4J）と通信します。

  4. JSPではApplications表の内容を取得し、メタデータ・ディクショナリの情報を使用してHTMLページを構成します。

  5. 生成されたHTMLページは、Webサーバーによりブラウザに戻されます。

図1-9 Oracle Applicationsフレームワーク・アーキテクチャ

本文の説明内容に関するイメージ

Oracle Applicationsフレームワーク処理の詳細

次に、JSPではApplications表の内容を取得し、メタデータ・ディクショナリの情報を使用してHTMLページを構成する方法を示します。

  1. AOL/Jでは、ページに対するユーザー・アクセスが検証されます。

  2. ページ定義（メタデータUI定義）は、データベース層のメタデータ・リポジトリからアプリケーション層にロードされます。

  3. アプリケーション・ロジックを保有し、データベースにアクセスするBC4Jオブジェクトがインスタンス化されます。

  4. Javaコントローラでは、必要に応じて動的UIルールに基づき、ページ定義がプログラムによって操作されます。

  5. UIX（HTML UIジェネレータ）によりページ定義が解析され、UI標準に従って対応するHTMLが作成されて、このページがブラウザへ送信されます。

Formsサービス

デフォルトで、Oracle Applicationsリリース12のFormsサービスは、Forms Listener Servletにより提供されます。このサーブレットにより、後述のとおり、ファイアウォール、ロード・バランス、プロキシおよびその他のネットワーク・オプションを簡単に使用できるようになります。

Forms Listener Servletを使用する利点は、次のとおりです。

Forms Listener Servletアーキテクチャ

Forms Listener Servletは、HTTPまたはHTTPS接続でOracle Formsアプリケーションを実行する機能を提供するJavaサーブレットです。Oracle Applicationsのフォームおよび関連するランタイム・エンジンをホストし、クライアント画面の表示およびユーザー処理に基づくデータベースの変更を開始して、デスクトップ・クライアントとOracleデータベース・サーバー間の通信を仲介します。

Forms Listener Servletは、データをキャッシュして、必要に応じてそのデータをクライアントに提供します（たとえば単一画面の制限を超える複数の受注明細をスクロールする場合など）。

Forms Listener Servletは、次のネットワーク・プロトコルを使用してデスクトップ・クライアントと通信できます。

Forms Listener Servletは、Oracleデータベース・サーバーとOracle Netネットワーク・インフラストラクチャを使用して通信します。

Forms Listener Servletは、各クライアント用のFormsランタイム・プロセスの作成、およびクライアントとそのクライアントに関連付けられているFormsランタイム・プロセス間のネットワーク通信を管理します。クライアントは、HTTP要求を送信し、クライアントのネットワーク・エンドポイントとして動作するWebサービスからHTTP応答を受信します。

注意: OC4J-FormsインスタンスはOracle Application Server（AS）10.1.3 ORACLE_HOMEから実行されますが、frmweb実行可能ファイルはAS 10.1.2 ORACLE_HOMEから起動されます。

Formsソケット・モード・アーキテクチャ

従来のFormsサーバー・ソケット・モード・アーキテクチャでは、ユーザーがFormsクライアント・アプレットでフィールドにデータを入力したりボタンをクリックするなどの処理を開始すると、データはアプリケーション層のFormsサーバーに渡されます。Formsサーバーでユーザー・インタフェース・ロジックが実行され、ユーザーの処理に基づいて適切なユーザー・インタフェース結果が決定されます。たとえば、ウィンドウが開いたり、別のフィールド値が入力される場合があります。必要に応じて、アプリケーション層にまだキャッシュされていないデータ向けに、またはデータ集中処理向けに、データベース層との通信が行われます。

図1-10 Formsソケット・モード

本文の説明内容に関するイメージ

接続が完了した後は、Formsサーバーとほとんど対話せずに多くの操作を実行できます。たとえば、ユーザーの処理に応じて一部のフィールド値が変更された場合、画面全体を更新する必要はありません。この場合、変更されたフィールドのみが新規値に更新されます。

モードの選択

前述のとおり、デフォルトでOracle Applicationsリリース12は、Forms Listener Servletモードを使用します。ただし、ソケット・モードもまだ完全にサポートされており、WAN環境ではパフォーマンス上の理由を改善するために使用が必要になる場合があります。

注意: Formsソケット・モードの活用の詳細は、OracleMetaLinkのNote 384241.1の「Using Forms Socket Mode with Oracle E-Business Suite Release 12」を参照してください。

コンカレント処理サーバー

前述のとおり、Oracle Applicationsデータとのユーザーの対話は、HTMLベース・アプリケーションまたは従来のFormsベース・アプリケーション経由で実行できます。ただし、定期型または非定型ベースに実行する必要のあるレポート・プログラムおよびデータ更新プログラムもあります。これらのプログラムは、ユーザーが他のタスクの処理を続けている間にバックグラウンドで実行され、非常に多くのデータ集中型の計算を必要とする場合があるため、コンカレント処理アーキテクチャを使用して実行されます。コンカレント処理はOracle Applicationsの機能で、非対話型で潜在的に長時間実行される機能を対話型操作と並行して実行できます。コンカレント処理では、オペレーティング・システムの機能を使用して、バックグラウンドでのデータ集中型またはリソース集中型のジョブのスケジューリングを一連のプログラムおよびフォームを介して容易に実行できるようにしています。リソース集中型のコンカレント処理操作は、対話型操作の支障とならないように、専用サーバーのコンカレント処理サーバー上で実行されます。

コンカレント処理サーバー上で実行されるプロセスは、コンカレント要求と呼ばれます。HTMLベースまたはFormsベース・アプリケーションのいずれか経由でこのような要求を発行すると、実行されるプログラムを指定した行がデータベース表に挿入されます。コンカレント・マネージャにより表内の適切な要求が読み込まれ、関連付けられたコンカレント・プログラムが開始されます。

コンカレント・マネージャの特徴

コンカレント・マネージャは、コンカレント処理の基本です。ジョブのスケジューリングおよび実行システムとして機能し、次の特性があります。

コンカレント・マネージャのタイプ

内部コンカレント・マネージャ（ICM）は、その他のコンカレント・マネージャすべてを管理します。稼働シフトに定められたとおりに各マネージャの起動および停止を管理し、プロセスの障害をモニターして障害が発生した場合にはクリーン・アップします。ICMはコンカレント要求自体は処理しません（ACTIVATE、DEACTIVATEまたはABORTなどのキュー制御要求は除きます）。

基本ICM定義は変更しないでください。ただし、必要に応じて、スリープ時間（新規コンカレント要求の有無を調べる間にICMが待機する秒数）、PMON（プロセス・モニター）のサイクル時間（失敗したワーカーの有無を調べる間にICMが待機するスリープ・サイクル数）、およびキュー・サイズ（アクティブなワーカー数を調べる間隔（PMONのサイクル数））を変更できます。パラレル・コンカレント処理（後述）を使用している場合は、そのオプションの一部も設定できます。

衝突解決マネージャ（CRM）は、互換性のないコンカレント要求が同一の衝突ドメイン（データを区分するために使用されるグループ化の抽象表現）内で動作しないように設計されたルールを強制します。内部コンカレント・マネージャの場合と同様に、基本CRM定義は変更しないでください。ただし、各稼働シフトのスリープ時間とパラレル・コンカレント処理のオプションの一部は変更できます。

Oracle Applicationsとともに出荷された状態の標準マネージャは、任意のコンカレント要求を受け入れて実行します。これは、その活動を制限するような特殊化ルールがないためです。 したがって、綿密な計画を立てずに標準マネージャの定義を変更しないでください。変更すると、一部のプログラムがまったく動作しない場合があるためです。標準マネージャからジョブを除外するには、製品固有のマネージャやユーザー定義のマネージャなどの代替マネージャでそのジョブが実行可能であることを確認してからにしてください。

取引マネージャは同期要求処理をサポートし、これによってサーバー・プロセスのプールがクライアント・プログラムからの要求に応答します。コンカレント要求表をポーリングして指示を取得するかわりに、取引マネージャはクライアントからの信号を待機します。この一例が、要求を即時に実行する必要がある受注承認の場合です。

関連する取引マネージャ・プログラムは、サーバー上でクライアントに透過的に実行されます。特定のマネージャ・プロセス用の取引プログラムはすべて、同じデータベース・セッションで実行されます。クライアントとサーバー間の通信は、パイプを介し、FND_TRANSACTION.SYNCHRONOUS機能を使用して同期して実行されます。プログラムの実行の最後に、クライアント・プログラムは完了メッセージを受信し、値（たとえば受注の承認を示す値）を返します。クライアントと取引マネージャ・プロセスの間で非永続的接続を使用するこの方法により、小さなサーバー・プロセス・プールで非常に数多くのクライアントに対してリアルタイムに近い応答のサービスを提供できます。

コンカレント・マネージャの設定

『Oracle Applicationsシステム管理者ガイド』に、コンカレント・マネージャの設定およびモニタリングに必要な手順とオプションが詳細に説明されています。主要な手順の一部は、次のとおりです。

ヒント: ワーカーの最適数を特定するには、最初に控えめにして、必要に応じて（システム・リソースの可用性に従って）追加ワーカーを定義する方が簡単です。

後述のように、パラレル・コンカレント処理を使用して複数のノード上で複数のマネージャを実行できます。

コンカレント処理アーキテクチャ

コンカレント処理では、プログラムはオペレーティング・システムのバックグラウンド・プロセスとして実行されます。これらのプログラムは、様々なOracleツール、実行可能ファイル用プログラミング言語またはホスト・オペレーティング・システムのスクリプト言語を使用して作成できます。

前述のとおり、コンカレント・マネージャ独自のオペレーティング・システム・プロセスで動作するコンカレント・プログラムは、即時プログラムと呼ばれています。即時プログラムは、コンカレント・マネージャのプログラム・ライブラリ内の機能として動作します。PL/SQLプログラムがその一例です。これとは対照的に、コンカレント・マネージャ・プロセスの子プロセス内で動作するコンカレント・プログラムは、作成済プログラムと呼ばれています。この例として、SQLプログラム、SQL Loaderプログラム、Oracle Reportsプログラム、作成済CプログラムおよびUNIXシェル・スクリプトやWindowsコマンド・ファイルなどのホスト言語プログラムがあります。

重要: Reportsサーバーはリリース12では廃止されています。レポートはすべて、rwrun実行可能ファイルを介してコンカレント処理サーバー経由で実行され、インプロセス・サーバーが作成されます。

注意: Cプログラムは即時プログラムとして実行できますが、作成済プログラムとして実行することをお薦めします。保守が簡単になり、不都合な点もありません。

コンカレント要求には、3つまたは場合によっては4つのフェーズからなるライフ・サイクルがあります。

表1-1 コンカレント要求のライフ・サイクル
フェーズ アクティビティ
保留中 要求は実行を待機しています
実行中 要求は実行中です
完了 要求は終了しました
非アクティブ 要求は実行できません

コンカレント・プログラム・ライブラリには、コンカレント・マネージャによりコールできるコンカレント・プログラムが含まれています。重要な例がOracle Application Object Libraryプログラム・ライブラリ（FNDLIBR）で、これにはOracle Applications即時コンカレント・プログラムが含まれ、標準コンカレント・マネージャに割り当てられています。各コンカレント・マネージャで実行できる即時コンカレント・プログラムは、独自のコンカレント・プログラム・ライブラリのもののみですが、作成済またはOracleツール・コンカレント・プログラムも実行できます。

様々なデータベース表がコンカレント処理アーキテクチャで使用されています。

表1-2 コンカレント処理データベース表
表 内容
FND_CONCURRENT_REQUESTS ステータス、開始日および完了日を含む、ユーザー要求の詳細
FND_CONCURRENT_PROGRAMS 実行方法、プログラムの制約の有無および単独実行の要否を含む、コンカレント・プログラムの詳細
FND_CONCURRENT_PROCESSES コンカレント要求とキューの相互参照、およびコンカレント・マネージャ・プロセスの履歴
FND_CONCURRENT_QUEUES 各コンカレント・マネージャ・キューに関する情報

注意: これらの表を手動で更新しないでください。（所属組織のアーカイブ要件に従って）定期的に「コンカレント要求やマネージャ・データのパージ」プログラムを実行してこれらの表が大きくなりすぎないように防ぐことができます。詳細は『Oracle Applicationsシステム管理者ガイド』を参照してください。

コンカレント処理操作

内部コンカレント・マネージャによりその他のすべてのマネージャが管理されるため、他のマネージャをアクティブにする前に内部コンカレント・マネージャが動作している必要があります。ICMがアクティブになった後は、コンカレント処理が有効な各ノード上のサービス・マネージャをICMが起動します。ICMのエージェントとして、サービス・マネージャがそのノード上のコンカレント・マネージャ（非アクティブになっているマネージャまたは稼働シフトを現在持っていないマネージャを除く）を起動します。ICMは、オペレーティング・システム・プロンプトまたはOracle Applications Managerから、アクティブおよび非アクティブにできます。また、「コンカレント・マネージャの管理」フォームから非アクティブにすることもできます（アクティブにはできません）。

ICMがUNIX上で起動した場合、$FND_TOP/bin/startmgrプログラムが起動します。これが$FND_TOP/bin/batchmgrをコールし、それがさらに次の処理を実行します。

  1. シェル・プロセスの開始

  2. 起動パラメータFND、CPMGRおよびFNDCPMBRを指定したコマンドFNDLIBRによるICMの開始

  3. $APPLCSF/$APPLLOGへのログ・ファイル（std.mgrおよびwnnn.mgr）の作成

通常、startmgrはアプリケーション・ソフトウェア（たとえばapplmgr）を所有するユーザー・アカウントで実行されます。このアカウントには、ログ・ファイルと出力ファイルがそれぞれ書き込まれるlogおよびoutディレクトリに対する書込み権限が必要です。

ICMは、コンカレント処理が有効になっている各ノード上のサービス・マネージャを、そのノード上のApplicationsリスナーに指示してサービス・マネージャ実行可能ファイル（FNDSM）を実行するプロセスを作成することで、起動します。リスナーは、FNDSMが作成される前にApplications環境ファイルを入手するように構成されている必要があります。起動に続いて、サービス・マネージャはICMのエージェントとして、定義済の稼働シフトに従ってそのノード上のコンカレント・マネージャを開始および停止します。

注意: 一般サービス管理（GSM）とコンカレント処理は密接に統合されていますが、サービス・マネージャはコンカレント処理ではなくGSMアーキテクチャのコンポーネントです。

特定のノード上のコンカレント・マネージャ・プロセスは、次のUNIXコマンドを実行して参照できます。

ps –ef | grep FNDLIBR

ps –ef | grep FNDSM

2番目のコマンドの出力で表示されるサービス・マネージャPIDは、必要であれば、次のようにしてノード上のすべてのコンカレント・マネージャおよびサービス・プロセスの検索に使用できます。これは、サービス・マネージャが親プロセスのためです。

ps –ef | grep <sm_pid>

Windowsでは、「タスク マネージャ」を使用してコンカレント・マネージャ・プロセスを検索できます。FNDLIBRプロセスは、内部コンカレント・マネージャおよび各標準マネージャ用に動作します。ICMは、起動時に指定されたパラメータの一部を含め、追加詳細が表示されることで識別できます。

オペレーティング・システム・レベルで正常に起動したすべてのプロセスに対して、ICMはFND_CONCURRENT_PROCESSESに行を挿入します。その後、RUNNING_PROCESSES列が更新されて実際に実行中のプロセスがFND_CONCURRENT_QUEUESに表示、反映されます。

コンカレント処理出力の表示

コンカレント処理ジョブからの出力は、いくつかの段階を経てユーザーに表示されます。

  1. コンカレント処理サーバーは、Oracle Netを介してデータベース・サーバーと通信します。

  2. コンカレント要求と関連付けられたログ・ファイルまたは出力ファイルは、Report Review Agent（Web Review Agentとも呼ばれます）に戻されます。

  3. Report Review Agentにより、レポート全体が含まれるファイルがFormsサービスに渡されます。

  4. Formsサービスにより、レポートが一度に1ページずつユーザーのブラウザに戻されます。

図1-11 コンカレント処理出力の表示

本文の説明内容に関するイメージ

システムを介して渡されるファイルおよびページ数の最大サイズをプロファイル・オプションを使用して指定することで、使用するネットワークの容量およびレポート量に対応できます。

パラレル・コンカレント処理

パラレル・コンカレント処理（PCP）では、コンカレント処理をOracle Real Application Clusters（Oracle RAC）環境または類似のクラスタ・システムの複数のノードに分散できます。このようにコンカレント処理を分散することで、ハードウェア・リソースを十分に活用し、最大のスループットおよびノード障害に対するリジリエンス（回復力）を提供するとともに、集中管理を維持できます。

パラレル・コンカレント処理では、次のことができます。

1つ以上のコンカレント・マネージャを指定して1つ以上のノードで実行できるため、ユーザーの処理ニーズに最適で、使用可能なハードウェア・リソースを十分に活用できます。

パラレル・コンカレント処理はデフォルトで有効になっているため、1つ以上のコンカレント処理ノードが存在する場合は常にPCPを使用できます。

注意: PCPにOracle RAC環境は必要ありません。逆に、Oracle RAC環境でPCPを使用することは一般的に意味のあることですが、必ず使用する必要はありません。

コンカレント処理の管理

コマンドラインから、2つのコマンドを入力して内部コンカレント・マネージャを制御できます。1つ目はstartmgrで、ICMを起動し、2つ目はconcsubで、ICMの停止や中断あるいはICMに対する各マネージャのオペレーティング・システム・プロセスの確認要求に使用します。さらにAutoConfig対応の環境では、コマンドラインからアプリケーション層サービスを開始および停止するために多数のスクリプトが提供されています。コンカレント処理の開始および停止用のスクリプトはINST_TOP/admin/scripts/adcmctl.shです。

コンカレント処理システムの各種コンポーネントは、「コンカレント・マネージャ: 管理」などの様々なフォームから、またはOracle Applications Manager（OAM）の下の「Concurrent Managers」や「Concurrent Requests」から管理できます。

Adminサーバー

Admin（Administration）サーバーは、Oracle Applicationsデータベース内のデータ・モデルおよびデータを保守するノード上にあります。このサーバーから次の操作を実行します。

Daily Business Intelligence（DBI）

Daily Business Intelligence（DBI）は、Oracle E-Business Suiteと統合されたレポート・フレームワークです。現在は、Daily Business IntelligenceのかわりにBusiness Intelligence System（BIS）が使用されており、トランザクション・データを事前要約した新しいマテリアライズド・ビュー・セットが含まれています。 Daily Business Intelligenceの概要ページを使用すると、マネージャは、日次ベースの特定のトランザクションの詳細レベルまで、複数の組織についての要約情報を表示できます。

たとえば、「損益」ページでは、収益、販売した商品のコスト、経費、ライン・オブ・ビジネス別の売上総利益の概要が表示されます。マネージャは、このページを使用して、その日までの収益を表示し、予測に対する収益を追跡し、前期間の収益と比較できます。実際の収益が予測収益を下回る場合、マネージャは、特定のライン・オブ・ビジネス、特定のマネージャ、Oracle Receivables内の特定の顧客の請求書まで問題を掘り下げて、その根本的原因を調査できます。

Daily Business Intelligenceは、トランザクション・システムと同じインスタンス内に常駐します。この単一インスタンス・アーキテクチャにより、個別の保守および管理チームの必要性が軽減され、レポート・パフォーマンスが最適化されます。また、Oracleデータベースのマテリアライズド・ビュー機能や増分リフレッシュ機能の利用により、組織でデータを日次、1時間ごとまたは希望の頻度でリフレッシュできます。

注意: 従来のBISビューは、基礎となる表定義が変更されたり、変更を反映するために置換されたりする場合がありますが、使用できます。

データベース層

データベース層には、Oracle Applicationsで保守されるすべてのデータが格納されたOracleデータベース・サーバーが含まれます。また、データベースには、Oracle Applicationsオンライン・ヘルプ情報も格納できます。

より具体的には、データベース層には、システム用の表、索引などのデータベース・オブジェクトが物理的に格納された、Oracleデータ・サーバー・ファイルおよびOracle Applicationsデータベース実行ファイルが含まれます。

データベース・サーバーはデスクトップ・クライアントと直接には通信しません。かわりに、アプリケーション層にあるサーバーと通信し、このサーバーがデータベース・サーバーとクライアントとの通信を仲介します。

混合プラットフォーム・アーキテクチャ

Oracleデータベース・サーバーは、現在ではOracle Applicationsが動作保証されていないプラットフォームで使用できる場合があります。そのような場合、データベースをあるプラットフォームにインストールしてアプリケーション層を別のプラットフォームにインストールするという、混合プラットフォーム・アーキテクチャを利用できる場合があります（これは分割構成と呼ばれる場合もあります）。

たとえば、Linuxが動作するIBM zSeriesプラットフォームにデータベース層を配置して、Linuxが動作するIntel x86などのプラットフォームにアプリケーション層をインストールできます。

図1-12 混合プラットフォーム・アーキテクチャへの配置例

本文の説明内容に関するイメージ

これにより、IBM zSeriesアーキテクチャが提供する特定の機能をデータベースで利用できます。また、アプリケーション層をよりコスト効率の高い方法で管理することもできます。

Oracle Applicationsテクノロジ・レイヤー

Oracle Applicationsテクノロジ・レイヤーは、Oracle Applicationsテクノロジ・スタックとOracle Applications製品固有モジュールの間にあります。このレイヤーでは、すべてのOracle Applications製品に共通した機能が提供されます。

Oracle Applicationsテクノロジ・レイヤーの製品は、次のとおりです。

Oracle Applications DBA（AD）

Applications DBA製品には、Oracle Applicationsファイル・システムおよびデータベースの管理用ツール一式が備わっています。ADツールは、Oracle Applicationsシステムのインストレーション、アップグレード、保守およびパッチ用に使用されます。

ADユーティリティは、次のとおりです。

Oracle Common Modules（AK）

AKは、HTMLベース・アプリケーション用のOracle Applicationsコンポーネントを定義したり、多くのOracle Applications特性を実行時に生成することができるアクティブ・データ・ディクショナリです。

Oracle Common Modulesを使用すると、HTMLベース・アプリケーション用の照会アプリケーションをプログラミングなしで開発できます。トランザクション・ページのすべての属性の言語変換済ラベルを格納でき、複数言語サポートが提供できます。

たとえば、AKランタイム・ディクショナリを使用して、属性、または顧客名属性（HTMLページに顧客名フィールドが表示された場合はいつでも再使用できる）などの再使用可能コンポーネントを定義できます。

Oracle Applications Utilities（AU）

Applications Utilities（AU）製品は、Oracle Applicationsシステムの保守に使用されます。

AUは、他の製品からコピーされたファイル群に対応します。これにより、フォームやレポートなどのファイルのオンサイト・クラスを生成できます。フォームまたはレポートの生成には、共有PL/SQLライブラリへのアクセスが必要になることがあるため、これらのファイルがAU_TOPにもコピーされます。

Oracle Application Object Library（FND）

Application Object Libraryは、Applicationsテクノロジ・レイヤーのキー・コンポーネントです。Application Object Libraryは、再使用可能なコード、プログラムおよびデータベース・オブジェクト群で、すべての製品に共通の機能を提供します。

Oracle Application Object Libraryでは、セキュリティの設定と保守、およびコンカレント処理の管理など、システム管理を容易にする多くの機能が提供されます。Application Object Libraryを使用すると、フレックスフィールドの処理またはレポート発行プロシージャなどがすべての製品で同一となります。またApplication Object Libraryにより、開発者は、基本モジュールとやりとりするカスタム・プログラムの作成を許可して、Oracle Applicationsの動作を拡張できます。

エンド・ユーザー機能

Oracle Application Object Libraryには、様々なApplications製品の機能を統合する機能がいくつかあります。

標準ユーザー・インタフェース

Application Object Libraryでは、標準化された機能をすべての製品に提供することでOracle Applicationsの統合をサポートしています。したがって、ルック・アンド・フィールが製品によって異なることはありません。

共有フレックスフィールド値セット

フレックスフィールドでは、すべての製品で標準化する特定の重要な情報を入力できます。会計フレックスフィールドはその一例で、これはFinancials製品およびManufacturing製品で使用されます。

標準レポート発行（SRS）

SRSを使用してバックグラウンド・レポートをコンカレント・マネージャに発行するプロシージャは、レポートの属する製品に関係なく同じになります。SRSでは、共有フレックスフィールド値セットを利用します。

Applicationsオンライン・ヘルプ

Applicationsオンライン・ヘルプの表示もすべての製品で標準化されています。

Developerの機能

Oracle Application Object Libraryには、Oracle Applicationsとインタフェースがあるカスタム・フォーム、レポートまたはプログラムを作成するための開発者向けの機能が多数用意されています。

システム管理者向けの機能

Oracle Application Object Libraryには、Oracle Applicationsの管理を簡略化する機能が多数あり、システム管理者がルーチン・タスクを迅速かつ簡単に実行できます。これらには、次の機能があります。

Oracle Application Object Libraryのセキュリティ

Application Object Libraryでは、ユーザーのサインオンおよび職責により、Oracle Applicationsのデータへのアクセス権限が管理されます。各ユーザーには、Oracle Applicationsへのアクセス権限を取得するための有効なユーザー名およびパスワードが必要です。

職責は、Applicationsユーザーが組織での自分の役割に適した機能およびデータにのみアクセスできるOracle Applicationsでの認可レベルです。たとえば、職責は、特定の製品、元帳、営業単位、またはウィンドウ、機能、レポートならびに製品グループまたはデータ・グループの制限付きリストにアクセスするために使用できます。

ナビゲーション・メニューから使用できるフォームは、職責ごとに異なる点に注意してください。たとえば、購買管理ユーザーのナビゲーション・メニューには、購買管理責任者のナビゲーション・メニューで使用できるすべてのフォームは含まれていません。

Oracle Applicationsをインストールすると、SYSADMINというApplications標準ユーザーが作成されます。複数のデフォルト職責も作成されます。SYSADMINサインオンは自動的にシステム管理者職責に割り当てられるため、SYSADMINを使用して新規ユーザーのサインオンを作成し、これらを職責に割り当てることができます。さらに、必要なカスタム職責を作成することもできます。

Oracle Workflow（WF）

Oracle Workflowでは、ビジネス・プロセス・ベースの統合をサポートする完全なワークフロー管理システムが提供されます。そのテクノロジにより、ビジネス・プロセスのモデル化、自動化および継続的な改善、ユーザー定義のビジネス・ルールに従ったすべてのタイプの情報のルーティングが可能になります。Oracle Workflowでは、定義済のビジネス・イベントに関連したデータのエンタープライズワイドな通信にインフラストラクチャを提供する一方、次のことを実行するのに必要な機能も提供します。

Oracle Workflowでは、グラフィカル・ワークフロー・ビルダーを使用して、ビジネス・プロセスをモデル化および保守できます。ループや複数のパラレル・フローへの分散と収集、サブフローへの分解、タスク結果に基づいた分岐、タイム・アウトなどが可能なプロセスを定義し、高度なビジネス・モデルをモデル化および自動化できます。

システム統合ハブとして動作するOracle Workflowでは、ビジネス・ルールを適用し、オブジェクトを管理してアプリケーションとシステム間でルーティングします。ビジネス・プロセス自動化の範囲を企業を超えて、Eメール・ユーザー、Webユーザー、システムまで広げ、ユーザーが注意を必要とする通知の受信、分析および応答を可能にします。通知には、標準のEメール・システムまたは標準のWebブラウザを利用して応答できます。

Workflowのコンポーネント

Oracle Workflow Builderでは、プロセスをグラフィカルにドラッグしてドロップできます。既存のビジネス・プロセスやアプリケーション・コードを変更せずに、組織および顧客または仕入先間にある既存のビジネス慣行を取り入れたビジネス・プロセスを作成および展開できます。

ワークフロー・エンジンは、Oracleデータベースに埋め込まれ、実行時のプロセス定義を実装します。ワークフロー・エンジンは、ワークフローの状態をモニターし、プロセスのアクティビティのルーティングを調整します。ワークフロー・アクティビティの完了などのワークフロー状態の変化は、PL/SQLまたはJava APIを介してエンジンに通知されます。

Oracle Workflowのビジネス・イベント・システムでは、ユーザーの企業のアプリケーション統合要件について、ワークフロー対応ソリューションを提供します。ビジネス・イベント・システムは、Oracleアドバンスト・キューイング・テクノロジを使用してシステム間でビジネス・イベントを通信する、Oracle Workflow付属のアプリケーション・サービスです。ビジネス・イベント・システムでは、次のタイプの統合がサポートされています。

ビジネス・イベント・システムでは、特定のプロトコルを介してエージェントと呼ばれるシステム上の通信ポイント間でメッセージを伝播する場合、Oracleアドバンスト・キューイングを使用します。外部システムから受信したイベントは、エージェントのキュー上で実行されるエージェント・リスナーによって処理されます。

Oracle Workflowのイベント・マネージャを使用すると、XMLイベント・メッセージ生成機能を含む、指定アプリケーションの重要なビジネス・イベントを登録できます。これらのアプリケーションのユーザーは、システムにとって重要なイベントに対してサブスクリプションを登録し、カスタム・コードのトリガーなどの処理を実行できます。

機能および使用方法

完了したアプリケーション・トランザクションまたはイベントは、ビジネス・イベントの発生または一連のWorkflow Engine APIのコールによってワークフロー・プロセスを起動できます。ワークフロー・エンジンは、プロセスを実行し、すべての自動化手順を実行して通知システムをコールし、管理者操作が必要な手順に対する通知を配信します。

標準のWebブラウザを使用し、ワークリストと呼ばれる1つの中央ウィンドウで、ビジネス・プロセス通知の検討および応答ができます。これにより、タスクに優先順位付けやソート基準の定義が柔軟に実行でき、思いどおりに作業を整理できます。たとえば、タイプまたは件名ごとに通知をグループ化できるため、あるコンテキストから別のコンテキストにジャンプする必要がなくなります。または、優先順位または期日ごとにソートし、時間制約のあるタスクを最初に集中的に実行できます。Oracle WorkflowはOracle E-Business Suiteと完全に統合されているため、任意のOracle E-Business Suiteまたは関連URLまでドリルダウンしてトランザクションを表示および完了できます。

ビジネス・イベントが発生すると、ワークフロー・イベント・マネージャにより、イベントに登録されたサブスクリプションを実行できます。ローカル・イベントの場合、サブスクリプション・コードはイベントを発生させたコードと同じデータベース・トランザクション内において同期または非同期で実行でき、コストのかかるサブスクリプション処理は後で実行できるため、制御をコール・アプリケーションにより早く戻すことができます。さらに、イベントは外部システムから非同期でも受信できます。イベント・マネージャで、イベントのサブスクリプションにイベント情報が必要かどうか確認することで、処理を最小限にしてから、XMLイベント・メッセージを作成します。

追加機能

ワークフロー・エンジン・イベント・アクティビティは非常に柔軟であるため、ワークフロー・プロセス内のビジネス・イベントをモデル化できます。イベント・アクティビティを使用して、内容に基づいたルーティング、変換、エラー処理などをモデル化できます。ワークフロー・プロセスをインバウンド・メッセージによって開始または処理し、アウトバウンド・メッセージを送信したり、イベント・マネージャに対してイベントを発生させることができます。XML機能アクティビティにより、ワークフロー・プロセス内のイベント・コンテンツ・データにアクセスできます。ビジネス・イベントに基づくワークフロー・プロセスにより、統合ソリューションの実装時に高い柔軟性が得られます。ただし、Point-to-Pointメッセージを利用するために、ビジネス・イベント・システムをワークフロー・エンジンから独立して実行することもできます。

ビジネス文書に必要な様々な形式において複雑な変換を実行できます。Oracle Workflowでは、スタイルシートをXMLイベント・メッセージに適用できます。さらに、ビジネス・イベント・システムでキューを定義する際、メッセージのエンキューおよびデキューに使用するロジックを指定できます。 キュー・ハンドラと呼ばれるこのロジックには、変換を含めることができます。

Oracle Alert（ALR）

Oracle Alert（ALR）は、例外またはイベントが発生した場合に、ユーザーにEメールでシステム通知を送信できます。一部の製品では事前定義済アラートが用意されています。この機能は、指定のデータベース例外が発生した時点でユーザーに通知し、定義された計画に従ってルーチン・タスクを自動的に実行します。

たとえば、Oracle Applicationsデータベース内の表領域に十分な空き領域がない場合、主要なデータベース管理者にEメールを送信するようOracle Alertを構成できます。

Oracle XML Publisher（XDO）

Oracle XML Publisherは、World Wide Web Consortium（W3C）のExtensible Stylesheet Language（XSL）に基づいたJavaベース製品です。特に、XML Publisherでは、XSL-FO標準を使用して、XMLデータを書式設定オブジェクト（FO）に変換できます。書式設定オブジェクトには、データおよび書式情報の両方が含まれており、Portable Document Format（PDF）などの出力形式に変換できます。

XML Publisherでは、データ定義とテンプレートを使用して、希望する形式の出力レポートを作成できます。データ定義は、XMLまたはXMLを作成可能なデータ・ソース（またはデータ・ソースの組合せ）です。例には、コンカレント・プログラムおよびWebサービスからの出力が含まれています。テンプレートはレポート定義で、レポートの外観を設定します。テンプレート・レイアウトはユーザー指定が可能です。現在サポートされているテンプレートは、RTF形式、PDF形式およびXSLです。

XML Publisherの重要な機能は次のとおりです。

コア・コンポーネント

XML Publisherのコア・コンポーネントは、Oracle Applicationsまたは任意のJavaベース・アプリケーションから、Java APIを介してアクセスできる、Javaベースの公開ツール・セットです。

テンプレート・マネージャ

テンプレート・マネージャを使用すると、テンプレートやデータ・ソースをアップロードおよび保守できます。主な機能は次のとおりです。

目次   |   前へ   |   ページの先頭へ   |   次へ

Oracleロゴ
Copyright © 2000, 2007, Oracle. All rights reserved.