リリース11i（11.5.10）
部品番号: B15656-01
目次
前へ
次へ
| Oracle Applications概要 リリース11i（11.5.10） 部品番号: B15656-01 | 目次 | 前へ | 次へ |
ここでは、Oracle Applicationsアーキテクチャおよびこのアーキテクチャでサポートされている機能の一部について説明します。構成は次のとおりです。
Oracle Applicationsアーキテクチャは、Oracle Applications製品をサポートする、複数層から構成された分散コンピューティングのフレームワークです。このモデルでは、様々なサーバーが複数のレベルまたは層に割り当てられています。
サーバーとは、単一マシン上で動作し、サービスとも呼ばれる特定の機能を提供するプロセスまたはプロセスのグループです。たとえば、HTTPサーバーはHTTP要求の受信および処理、FormsサーバーはOracle Formsに関連したアクティビティへの要求の受信および処理を行うプロセスです。
層とは、複数の物理マシンにまたがることもある、サービスの論理グループです。 Oracle E-Business Suiteインストレーションを構成する3層のアーキテクチャは、Oracleデータベースをサポートおよび管理するデータベース層、様々なApplicationsコンポーネントをサポートおよび管理し、中間層とも呼ばれるアプリケーション層、および標準Webブラウザへの追加コンポーネントを介するユーザー・インタフェースを提供するデスクトップ層から構成されています。
マシンは、特にクラスタ内で密接に動作しているコンピュータ・グループの意味でノードとも呼ばれます。各層は1つ以上のノードで構成され、各ノードには複数の層を含めることができます。 たとえば、データベースは、1つ以上のアプリケーション層コンポーネントとして同一ノード上に常駐できます。 これは、管理の簡略化、またはネットワーク通信量の軽減によるパフォーマンスの最大化（コンカレント処理の場合）のために行うことがあります。
Oracle Applicationsソフトウェアをアプリケーション層に集中管理することにより、各デスクトップ・クライアントPC上でアプリケーション・ソフトウェアをインストールおよび保守する必要がなくなります。 つまり、共有APPL_TOPモデル（「共有APPL_TOP」を参照）を使用した主な利点の1つは、アプリケーション層の各マシンのコピーではなく、関連するApplicationsコードのコピー1つのみを保守すればいいという点です。
データベース層では、可用性とスケーラビリティの向上させるために複数ノードで単一のデータベース・インスタンスをサポートするReal Application Clusters（RAC）環境の使用が増加しています。
図1-1 Oracle Applicationsアーキテクチャ
アプリケーション層とデスクトップ層間の接続は、広域ネットワーク（WAN）経由で運用できます。これは、デスクトップ層とアプリケーション層間では、フィールド値の差分などの必要最小限の情報が交換されるためです。 様々な場所のユーザーとグローバルな操作を行う場合、ネットワークの通信量の需要が少ないほど、通信費の節減になり、ユーザーに対する応答時間も短縮されます。
クライアント・インタフェースは、新しいHTMLベース・アプリケーション用のHTMLおよび従来のFormsベース・インタフェース用のWebブラウザのJavaアプレットを介して提供されます。
図1-2 Formsベース・デスクトップ層アーキテクチャ
Oracle Applicationsリリース11iでは、各ユーザーは、デスクトップ・クライアント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クライアント・アプレットは、Oracle ApplicationsのFormsベース製品（カスタマイズおよび拡張された製品を含む）をすべてサポートする汎用プレゼンテーション・アプレットです。Formsクライアント・アプレットは、Javaアーカイブ（JAR）ファイル・コレクションとしてパッケージされています。JARファイルには、Oracle Applicationsフォームのプレゼンテーション・レイヤーを実行するために必要なすべてのJavaクラスが含まれます。
Formsクライアント・アプレットは、デスクトップ・クライアント上のJava仮想マシン（JVM）内で動作する必要があります。 Oracle Jinitiatorでは、ブラウザ自体のJVMのかわりに、Oracle JVMをWebクライアント上で使用できます。JInitiatorは、プラグイン（Netscape）またはActiveXコンポーネント（Microsoft Internet Explorer）として、実装されます。
従来のFormsベースOracle Applications環境の場合、Jinitiatorは、標準Applicationsサインオン・プロセスの一部として実行されていました。 主にHTMLベース環境に移行傾向にある現在、Jinitiatorは、ユーザーがフォームの実行などJinitiatorを必要とする機能へのアクセスを選択した場合にのみ起動されます。 Jinitiatorがインストールされていない場合、Webブラウザにより、必要なインストレーション実行可能ファイルをダウンロードするように要求されます。
Formsクライアント・アプレットおよび通常使用されるJARファイルは、クライアントの最初のセッションの開始時に、Webサーバーからダウンロードされます。使用頻度の低いJARファイルは、必要に応じてダウンロードされます。 JARファイルは、Jinitiatorがインストールされると、指定のディレクトリにキャッシュされます。 たとえば、C:¥Program Files¥Oracle¥Jinitiator 1.1.8.24¥jcacheのようになります。 キャッシュすると、JARファイルが今後のセッション用に準備され、必要なたびにJARファイルをダウンロードすることによるネットワーク通信を抑えることができます。
注意: 「基本」Jinitiatorタブの「コンソールの表示」を選択すると、JARファイルのダウンロード状態が表示され、実際にダウンロードが実行されているかどうかを確認できます。
JARファイルに対するすべての更新は、アプリケーション層にインストールされ、前述のキャッシング手順を利用してクライアントに自動的にダウンロードされます。
アプリケーション層には、ビジネス・ロジックを処理する様々なサーバーをホストするロールと、デスクトップ層とデータベース層との通信を管理するロールの二重のロールがあります。この層は、中間層とも呼ばれています。Oracle 9i Application Server（9iAS）では、アプリケーション層で使用されるテクノロジが提供されます。Oracle Applicationsのアプリケーション層は、次の6つのサーバーで構成されています。
アプリケーション層で異なるプラットフォームを混合して使用しないようにしてください。 単一のプラットフォームで使用すると、ダウンロードする必要のあるパッチが1セットのみになるため、保守が簡単になります。
アプリケーション層では、その層内にある多くのサーバーでロード・バランスがサポートされており、可用性、フォルト・トレランス、信頼性および最適拡張性が向上します。 次のタイプのサーバーを複数使用している場合に、ロード・バランスを利用できます。
通常、ロード・バランスは、複数のWebサーバーにロードを分散するために使用する最も一般的な方法で、サーバーによって大幅に異なるロードを割り当てることもできます。 様々なタイプのロード・バランスの詳細は、「ロード・バランス」を参照してください。
Oracle HTTP Server（Apacheエンジン）はWebサーバーです。 このサーバーでは、ネットワーク経由で受信したデスクトップ・クライアントからの要求が処理され、次のような追加コンポーネントが含まれます。
Oracle HTTP ServerのWebリスナー・コンポーネントでは、クライアント・ブラウザからの受信HTTP要求（特定のURL）を受領します。
可能な場合、たとえば簡単なWebページを構成するためにHTMLを戻すことで、Webサーバーが要求自体を処理します。このURLで参照されるページに高度な処理が必要な場合、リスナーはサーブレット・エンジンに要求を渡し、必要に応じてサーブレット・エンジンがデータベース・サーバーに接続します。
Oracle HTML-Based (旧称「Self-Service」) Applicationsの特徴は、次のとおりです。
Oracle Applicationsフレームワークは、HTMLベース・アプリケーションの開発プラットフォームです。 Javaベースのアプリケーション層フレームワークおよび関連サービスから構成され、HTMLベース・アプリケーションの迅速な開発および配置を促進するように設計されています。
重要なOracle Applicationsフレームワーク・コンポーネントには、次のコンポーネントが含まれます。
フレームワークベースのアプリケーション・ロジックは、Apache Jservモジュールによって提供されるJavaサーブレット・エンジンにより実行されるプロシージャによって制御されています。 サーブレット・エンジンでは、フレームワークUIを構成する際に、メタデータ・ディクショナリを使用します。
図1-4 HTMLベース・アプリケーション・アーキテクチャ
HTMLベース・アプリケーションによるJavaサーブレット・アクセス
HTMLベース・アプリケーション・モジュールでは、次のアクセス・パスを使用します。
図1-5 Oracle Applicationsフレームワーク・アーキテクチャ
次に、JSPではApplications表の内容を取得し、メタデータ・ディクショナリの情報を使用してHTMLページを構成する方法を示します。
Formsサーバーは、専門インタフェースをサポートするOracle Applicationsフォームおよび関連ランタイム・エンジンに対するホストの役割を果たします。FormsサーバーはOracle Developer 6iコンポーネントであり、クライアント画面の表示およびユーザーのアクションに基づくデータベースの変更を開始して、デスクトップ・クライアントとOracleデータベース・サーバー間の通信を仲介します。
Formsサーバーではデータがキャッシュされ、必要に応じてデータがクライアントに提供されます（単一画面の制限を超える複数の受注明細をスクロールする場合など）。
Formsサーバーは、次のプロトコルを使用してデスクトップ・クライアントと通信します。
「セキュリティ」では、セキュリティの見地からHTTPおよびHTTPSを比較します。Formsサーバーは、Oracle Netネットワーク・インフラストラクチャを使用したOracleデータベース・サーバーと通信します。
ユーザーがFormsクライアント・アプレットで、フィールドにデータを入力したりボタンをクリックするなどの処理を開始すると、アプリケーション層のFormsサーバーにデータが渡されます。Formsサーバーでユーザー・インタフェース・ロジックが実行され、ユーザーの処理に基づいて適切なユーザー・インタフェース結果が決定されます。たとえば、ウィンドウが開いたり、別のフィールド値が入力される場合があります。必要に応じて、アプリケーション層にまだキャッシュされていないデータ向けに、またはデータ集中処理向けに、データベース層との通信が行われます。
図1-6 Formsサーバー・アーキテクチャ
接続が完了した後は、Formsサーバーとほとんど対話せずに多くの操作を実行できます。たとえば、ユーザーの処理に応じて一部のフィールド値が変更された場合、画面全体を更新する必要はありません。この場合、変更されたフィールドのみが新規値に更新されます。
Oracle Applicationsでは、複数のFormsサーバー間の自動ロード・バランスがサポートされています。 このようなロード・バランス構成では、メトリック・サーバーと呼ばれる追加Formsコンポーネントを利用します。メトリック・サーバーは、すべてのFormsサーバー要求に対して、単一の調整ポイントとして動作します。
メトリック・サーバーは、1つのアプリケーション・サーバー上に配置されています。その他のアプリケーション・サーバーに置かれたメトリック・クライアントから、最も負荷の軽いアプリケーション・サーバーを決定するために、定期的にロード情報がメトリック・サーバーに送信されます。
図1-7 Formsサーバー・ロード・バランス
Formsサーバー・ロード・バランスは、次のように実行されます。
注意: 11.5.10 Rapid Installを使用すると、初期インストール中、FormsサーバーおよびWebサーバーのロード・バランスを必要に応じて設定できます。
Oracle E-Business Suiteリリース11iでは、イントラネット・ユーザー用ソケット・モード、インターネット・ユーザー用HTTPSモード、Formsベース（プロフェッショナル・ユーザー・インタフェース）通信用HTTPモードの使用がサポートされています。 Forms Listener Servletは、HTTPおよびHTTPS接続でOracle Formsアプリケーションを実行する機能を配信するJavaサーブレットです。 各クライアント用のFormsサーバー・ランタイム・プロセスの作成、およびクライアントとクライアントに関連付けられているFormsサーバー・ランタイム・プロセス間のネットワーク通信を管理します。 クライアントはHTTP要求を送信し、クライアント用のネットワーク・エンドポイントとして動作するWebサーバーからHTTP要求を受信します。
Forms Listener Servletを使用する利点は、次のとおりです。
Forms Listener Servletを使用すると、HTTPプロトコルの方がソケットより通信許容量が多いため、ネットワーク通信量が約40%増加します。 ネットワーク通信量の増加による実際のパフォーマンス・オーバーヘッドは、既存のネットワーク待ち時間に依存して決定されます。
Forms Listener Servletの使用要件は、次のとおりです。
Forms Listener Servletを使用すると、Formsベース通信量のロード・バランスはJServロード・バランスを利用して実行されます。 これには、iAS 1.0.2.2.2 Apacheモジュールmod_oprocmgrを使用する必要があります。mod_oprocmgrを使用すると、プロセスの自動起動、停止の検知および再起動など、その他の新しいインフラストラクチャ機能も提供されています。
注意: ApplicationsとともにForms Listener Servletを実装する場合に必要となる手順は、Oracle MetaLinkのNote 201340.1の「Using Forms Listener Servlet with Oracle Applications 11i」を参照してください。
Reportsサーバーはコンカレント処理サーバーと同じノードに自動的にインストールされ、レポートはコンカレント処理レポートと同じディレクトリに含められます。ただし、Reportsサーバーにより生成されたレポートは、コンカレント処理レポートとは別に監視および管理されます。
Reportsサーバーでは、実行時にレポート言語が動的に選択され、各レポートがユーザーの優先言語で表示されます。
HTMLベース・レポートの要求は、次のようにHTMLベース・アプリケーション要求のフローと類似しています。
図1-9 Reportsサーバー・アーキテクチャ
ユーザーが多数存在する場合、複数のReportsサーバーを設置すると便利な場合があります。この構成では、いずれかのReportsサーバーがマスターReportsサーバーに指定されます。このサーバーでは、最初の要求が受信され、その要求は、各Reportsサーバーで処理できる負荷に応じて、いずれか1つのサーバーに配分されます。マスターReportsサーバーでは、各Reportsサーバーがサポートできるランタイム・エンジン数が判別できます。
Oracle E-Business Suiteリリース11iでは、単一のReportsサーバー上で複数の言語がサポートされています。
Discoverサーバーは、Oracle9i Application Server（9iAS）の重要なコンポーネントの1つであるOracle Discoverer 4iを構成しています。 Discoverは非定型問合せ、レポート、分析および公開用のツールで、組織のすべてのレベルのビジネス・ユーザーが、データ・マート、データ・ウェアハウスおよびオンライン・トランザクション処理（OLTP）システムから情報に直接アクセスできます。 レポート・ビルダーおよびレポート・アナリストは、非定型問合せやレポートを簡単に作成、変更および実行できます。 一時的ユーザーは、基礎データ構造の複雑性が表面に現れないビジネス・ビューを利用して、事前定義のレポートやグラフをナビゲートできます。
Oracle Discoverer 4iでは、データベースの複雑性が表面に現れず、直感的で理解しやすいインタフェースが提供されています。 表など、聞き慣れないデータベース用語が、フォルダなど親しみやすい用語にマッピングされるため、データベース構文を使用した聞き慣れない用語から、標準のビジネス用語を使用した重要な情報にアクセスできます。
Discoverer 4iは、Oracle E-Business Suite Release 11iと緊密に統合されているため、E-Business SuiteユーザーはDiscovererを使用して、Financials、Operations、Human Resources、Purchasing、Process Manufacturing、Activity Based Management、およびその他製品の選択したビジネス・エリアからデータを分析できます。
Discovererサーバーは、非定型問合せおよび問合せ結果出力の分析を可能にすることにより、Reportsサーバーを補完します。 またDiscovererサーバーのユーザーは、ビジネス環境やその他戦略的要因に対する潜在的な変化に基づき、予測ができます。
Discoverer End User Layerは、Oracle Applicationsデータベース内の基礎データを、ユーザーに使いやすくするために重要です。 Oracle Applicationsデータベース内にある、実際のApplicationsデータとは異なるメタデータ（データを説明するデータ）レイヤーです。
End User Layerにアクセスするには、次の3つのソフトウェア・コンポーネントを使用します。
注意: Oracle DiscovererとApplicationsリリース11iの統合の詳細は、MetaLinkのNote 139516.1の「Using Discoverer 4i with Oracle Applications 11i」を参照してください。
前述で説明したように、Oracle Applicationsデータとのユーザーの対話は、HTMLベース・アプリケーションまたは従来のFormsベース・アプリケーション経由で実行されます。ただし、定期型または非定型ベースに実行する必要のあるレポート・プログラムおよびデータ更新プログラムもあります。これらのプログラムは、ユーザーが他のタスクの処理を続けている間にバックグラウンドで実行され、非常に多くのデータ集中型の計算が含まれる場合があり、コンカレント処理アーキテクチャを使用して実行されます。 リソース集中型コンカレント処理操作は、対話型操作の支障とならないように、専用サーバーのコンカレント処理サーバー上で実行されます。
コンカレント処理サーバー上で実行されるプロセスは、コンカレント要求と呼ばれます。HTMLベースまたはFormsベース・アプリケーションのいずれか経由でこのような要求を発行すると、実行されるプログラムを指定した行がデータベース表に挿入されます。 コンカレント・マネージャにより表内の適切な要求が読み込まれ、関連のコンカレント・プログラムが開始されます。内部コンカレント・マネージャ・サービスでは、データベース表の新規要求の監視、他のコンカレント・マネージャの管理、および要求をいつ処理するか、どのコンカレント・マネージャで実行するかを決定します。
図1-8 コンカレント処理出力の表示
コンカレント処理出力の表示
コンカレント処理サーバーは、Oracle Netを使用してデータ・サーバーと通信します。コンカレント要求から生成されたログ・ファイルまたは出力ファイルは、Report Review Agent（Web Review Agentとも呼ばれる）に戻されます。Report Review Agentにより、レポート全体が含まれるファイルがFormsサーバーに渡されます。Formsサーバーにより、レポートが一度に1ページずつユーザーのブラウザに戻されます。ネットワークの容量およびレポート量に応じて、プロファイル・オプションを使用して、ファイルのサイズとシステムから渡されるページ数を管理できます。
パラレル・コンカレント処理
パラレル・コンカレント処理では、コンカレント・マネージャをクラスタ環境内の複数ノードに分配し、コンカレント処理を使用可能なノードに分散できます。
パラレル・コンカレント処理では、次のことができます。
1つ以上のコンカレント・マネージャを指定して1つ以上のノードで実行できるため、ユーザーの処理ニーズに最適で、使用可能なハードウェア・リソースを十分に活用できます。
Admin（Administration）サーバーは、Oracle Applicationsデータベース内のデータ・モデルおよびデータを保守するノード上にあります。このサーバーから次の操作を実行します。
このプロセスは、（10.7または11.0などの旧リリースから）新規リリースにアップグレードする場合にのみ実行されます。Oracle Applicationsをアップグレードするには、AutoUpgradeユーティリティ（adaimgr）を使用します。
一般に、Applicationsパッチは、ファイル・システムおよびデータベース・オブジェクトを更新するファイルおよびスクリプトで構成されています。 ほとんどのパッチは、異なる機能を実行する多数のパッチ・ドライバ・ファイルから構成されます。 コピー（c）ドライバではApplicationsファイルの変更、データベース（d）ドライバではApplicationsデータベース・オブジェクトの変更、生成（g）ドライバではフォーム、レポート、グラフィックまたはメッセージ・ファイルの各ファイルが生成されます。 新しいパッチでは、コピー・ドライバ、データベース・ドライバおよび生成ドライバのファイル処理を1つの統合（u）ドライバ・ファイルにまとめます。
これらの更新を実行するには、AutoPatchユーティリティ（adpatch）を使用します。AutoPatchは、ミニパック（例: 11i.AD.H）およびメンテナンス・パック（例: 11.5.10）などの累積パッチを適用する際にも使用できます。
複数報告通貨などの一部の機能では、使用される追加表やスキーマへ更新が確実に伝播されるように、定期的に保守する必要があります。 AD管理ユーティリティ（adadmin）を使用すると、このようなタスクや他のファイル・システムおよびデータベースの管理タスクを保守できます。
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 Applicationsテクノロジ・レイヤーは、Oracle Applicationsテクノロジ・スタックとOracle Applications製品固有モジュール間にあります。このレイヤーでは、すべてのOracle Applications製品に共通した機能が提供されます。
Oracle Applicationsテクノロジ・レイヤーの製品は、次のとおりです。
Applications DBA製品には、Oracle Applicationsファイル・システムおよびデータベースの管理用ツール一式が備わっています。ADツールは、Oracle Applicationsシステムのインストレーション、アップグレード、保守およびパッチ用に使用されます。
ADユーティリティは、次のとおりです。
AKは、HTMLベース・アプリケーション用のOracle Applicationsコンポーネントを定義したり、多くのOracle Applications特性を実行時に生成することができるアクティブ・データ・ディクショナリです。
Oracle Common Modulesを使用すると、HTMLベース・アプリケーション用の照会アプリケーションをプログラミングなしで開発できます。 トランザクション・ページのすべての属性の言語変換済ラベルを格納でき、複数言語サポートが提供できます。
たとえば、AKランタイム・ディクショナリを使用して、属性、または顧客名属性（HTMLページに顧客名フィールドが表示された場合はいつでも再使用できる）などの再使用可能コンポーネントを定義できます。
注意: 現在は、AKのかわりにFramework 5.7のJDeveloperメタデータ・サービス（MDS）リポジトリが（Applicationsリリース11.5.8とともに）使用されています。
Applications Utilities（AU）製品は、Oracle Applicationsシステムの保守に使用されます。
AUは、他の製品からコピーされたファイル群に対応します。これにより、フォームやレポートなどのファイルのオンサイト・クラスを生成したり、標準の共有保管場所からReportsサーバーにより起動されたレポートを実行できます。フォームまたはレポートの生成には、共有PL/SQLライブラリへのアクセスが必要になることがあるため、これらのファイルがAU_TOPにもコピーされます。
Oracle Applications Javaファイルは、JAVA_TOPおよび<PROD>_TOPのみでなく、AU_TOPにも格納されます。
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オンライン・ヘルプの表示もすべての製品で標準化されています。
Oracle Application Object Libraryには、Oracle Applicationsとインタフェースがあるカスタム・フォーム、レポートまたはプログラムを作成するための開発者向けの機能が多数用意されています。
GUIおよびコーディング標準
Oracle Applications開発者が使用するコーディング標準およびグラフィカル・ユーザー・インタフェース（GUI）標準を、カスタム開発者も使用できます。
標準レポート発行
カスタム・レポートは標準レポート発行に統合できるため、他のOracle Applicationsレポートと同じ手順を使用して発行および監視できます。開発者は、カスタム・レポートまたは標準オブジェクトにアクセスするための特定のメニューおよび職責を設定できます。
フレックスフィールド開発
カスタム・フォームで使用するフレックスフィールドでは、値セット、検証およびセキュリティ・ルールなどの既存のフレックスフィールド機能を利用できます。
カスタム・メニューおよび職責
カスタム・メニューおよび職責は、Oracle Applicationsにシームレスに統合できます。
Oracle Application Object Libraryには、Oracle Applicationsの管理を簡略化する機能が多数あり、システム管理者がルーチン・タスクを迅速かつ簡単に実行できます。これらには、次の機能があります。
Application Object Libraryでは、ユーザーのサインオンおよび職責により、Oracle Applicationsのデータへのアクセス権限が管理されます。各ユーザーには、Oracle Applicationsへのアクセス権限を取得するための有効なユーザー名およびパスワードが必要です。
職責は、Applicationsユーザーが組織での自分の役割に適した機能およびデータにのみアクセスできるOracle Applicationsでの認可レベルです。職責により、特定の製品、営業単位、会計帳簿、およびウィンドウ、機能、レポートならびに製品グループまたはデータ・グループの制限付きリストにアクセスできます。
ナビゲーション・メニューから使用できるフォームは、職責ごとに異なる点に注意してください。たとえば、購買管理ユーザーのナビゲーション・メニューには、購買管理責任者のナビゲーション・メニューで使用できるすべてのフォームは含まれていません。
Oracle Applicationsをインストールすると、SYSADMINというApplications標準ユーザーが作成されます。複数のデフォルト職責も作成されます。SYSADMINサインオンは自動的にシステム管理者職責に割り当てられるため、SYSADMINを使用して新規ユーザーのサインオンを作成し、これらを職責に割り当てることができます。さらに、必要なカスタム職責を作成することもできます。
Oracle Workflowでは、定義済のビジネス・イベントに関連したデータのエンタープライズワイドな通信にインフラストラクチャを提供する一方、次のことを実行するのに必要な機能も提供します。
Oracle Workflowでは、グラフィカル・ワークフロー・ビルダーを使用して、ビジネス・プロセスをモデル化および保守できます。 ループや複数のパラレル・フローへの分散と収集、サブフローへの分解、タスク結果に基づいた分岐、タイム・アウトなどが可能なプロセスを定義し、高度なビジネス・モデルをモデル化および自動化できます。
システム統合ハブとして動作するOracle Workflowでは、ビジネス・ルールを適用し、オブジェクトを管理してアプリケーションとシステム間でルートします。 ビジネス・プロセス自動化の範囲を企業を超えて、電子メール・ユーザー、Webユーザー、システムまで広げ、ユーザーが注意を必要とする通知の受信、分析および応答を可能にします。 通知には、標準の電子メール・システムまたは標準のWebブラウザを利用して応答できます。
Oracle Workflow Builderでは、プロセスをグラフィカルにドラッグしてドロップできます。 既存のビジネス・プロセスやアプリケーション・コードを変更せずに、組織および顧客または仕入先間にある既存のビジネス慣行を取り入れたビジネス・プロセスを作成および展開できます。
Oracle Workflowのビジネス・イベント・システムでは、ユーザーの企業のアプリケーション統合要件について、ワークフロー対応ソリューションを提供します。 ビジネス・イベント・システムは、Oracleアドバンスト・キューイング・テクノロジを使用してシステム間でビジネス・イベントを通信する、Oracle Workflow付属のアプリケーション・サービスです。 ビジネス・イベント・システムでは、次のタイプの統合がサポートされています。
ビジネス・イベント・システムでは、特定のプロトコルを介してエージェントと呼ばれるシステム上の通信ポイント間でメッセージを伝播する場合、Oracleアドバンスト・キューイングを使用します。 外部システムから受信したイベントは、エージェントのキュー上で実行されるエージェント・リスナーによって処理されます。
Oracleワークフロー・イベント・マネージャを使用すると、XMLイベント・メッセージ生成機能を含む、指定アプリケーションの重要なビジネス・イベントを登録できます。 これらのアプリケーションのユーザーは、システムにとって重要なイベントに対してサブスクリプションを登録し、カスタム・コードのトリガーなどの処理を実行できます。
ビジネス・イベントが発生すると、ワークフロー・イベント・マネージャにより、イベントに登録されたサブスクリプションを実行できます。 ローカル・イベントの場合、サブスクリプション・コードはイベントを発生させたコードと同じデータベース・トランザクション内において同期または非同期で実行でき、コストのかかるサブスクリプション処理は後で実行できるため、制御をコール・アプリケーションにより早く戻すことができます。 さらに、イベントは外部システムから非同期でも受信できます。 イベント・マネージャで、イベントのサブスクリプションにイベント情報が必要かどうか確認することで、処理を最小限にしてから、XMLイベント・メッセージを作成します。
標準のWebブラウザを使用し、ワークリストと呼ばれる1つの中央ウィンドウで、ビジネス・プロセス通知の検討および応答ができます。 これにより、タスクに優先順位付けやソート基準の定義が柔軟に実行でき、思いどおりに作業を整理できます。 たとえば、タイプまたは件名ごとに通知をグループ化できるため、あるコンテキストから別のコンテキストにジャンプする必要がなくなります。 または、優先順位または期日ごとにソートし、時間制約のあるタスクを最初に集中的に実行できます。 Oracle WorkflowはOracle E-Business Suiteと完全に統合されているため、任意のOracle E-Business Suiteまたは関連URLまでドリルダウンしてトランザクションを表示および完了できます。
ワークフロー・エンジン・イベント・アクティビティは非常に柔軟であるため、ワークフロー・プロセス内のビジネス・イベントをモデル化できます。 イベント・アクティビティを使用して、内容に基づいたルーティング、変換、エラー処理などをモデル化できます。 ワークフロー・プロセスをインバウンド・メッセージによって開始または処理し、アウトバウンド・メッセージを送信したり、イベント・マネージャに対してイベントを発生させることができます。 XML機能アクティビティにより、ワークフロー・プロセス内のイベント・コンテンツ・データにアクセスできます。 ビジネス・イベントに基づくワークフロー・プロセスにより、統合ソリューションの実装時に高い柔軟性が得られます。 ただし、Point-to-Pointメッセージを利用するために、ビジネス・イベント・システムをワークフロー・エンジンから独立して実行することもできます。
ビジネス文書に必要な様々な形式において複雑な変換を実行できます。 Oracle Workflowでは、スタイルシートをXMLイベント・メッセージに適用できます。 さらに、ビジネス・イベント・システムでキューを定義する際、メッセージのエンキューおよびデキューに使用するロジックを指定できます。 キュー・ハンドラと呼ばれるこのロジックには、変換を含めることができます。
また、Oracle Workflowでは、OracleデータベースでXMLサポートを利用できます。 Oracle9i以降のリリースでは、アプリケーションでのXMLデータおよび文書の操作をシームレスで簡単にする新しいXMLデータ・タイプを利用して、XMLにネイティブ・サポートを提供しています。 Oracle9i以降、データベース・サーバーにより、ランタイム・エンジン内のXMLデータおよび文書を生成、メッセージ送信および変換する機能が提供され、優れたスケーラビリティとパフォーマンスが得られます。
Oracle Alert（ALR）は、例外またはイベントが発生した場合に、ユーザーへシステム通知を電子メールで送信できます。一部の製品では事前定義済アラートが用意されています。この機能は、指定のデータベース例外が発生した時点でユーザーに通知し、定義された計画に従ってルーチン・タスクを自動的に実行します。
たとえば、Oracle Applicationsデータベース内の表領域に十分な空き領域がない場合、主要なデータベース管理者に電子メールを送信するようOracle Alertを構成できます。
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ベースの公開ツール・セットです。
テンプレート・マネージャを使用すると、テンプレートやデータ・ソースをアップロードおよび保守できます。 主な機能は次のとおりです。
