ヘッダーをスキップ

Oracle E-Business Suite開発者ガイド
リリース12.2
E53035-01		目次へ
目次		前のページへ
前へ		次のページへ
次へ

カスタマイズ標準

Oracle E-Business Suiteのカスタマイズの概要

この項では、Oracle E-Business Suiteと統合するカスタム・アプリケーション・コンポーネント構築の標準について説明します。これらのガイドラインを使用すると、カスタム・コンポーネントを構築および保守する管理の手間が削減されます。

すべてのOracle E-Business Suite製品はOracle Application Object Libraryを使用して構築されているため、Oracle E-Business Suiteのカスタマイズには、その他のOracle ToolsとともにOracle Application Object Libraryを使用する必要があります。『Oracle E-Business Suite開発者ガイド』(このマニュアル)の関連の章で説明されている概念を熟知していることが必要です。

この項で説明する内容は、次のとおりです。

Oracle E-Business Suiteのカスタマイズには、何種類かの方法があります。カスタマイズの一般的な例として、次のようなものがあります。

基本的なビジネス・ニーズ

次の基本的ビジネス・ニーズを満たすための機能が提供されています。

定義

これらの機能の詳細は、次の参照先で説明されています。

アプリケーション構築の概要

アプリケーション・フレームワーク設定の概要

拡張によるカスタマイズ

既存のOracle E-Business Suiteアプリケーションのために新しいコンポーネントを開発し、Oracle Application Object Libraryの開発機能を使用して新しいアプリケーションを開発します。

拡張によるカスタマイズは、既存のOracle E-Business Suiteコンポーネントをカスタム・アプリケーション・ディレクトリにコピーし、そのコピーを変更するのと同様に簡単に行うことができます。

変更によるカスタマイズ

「適切なカスタマイズ」としても知られています。既存のOracle E-Business Suiteコンポーネントを、具体的な要件にあわせて変更します。変更には、定型挿入文テキストの変更から、妥当性チェックのロジックの変更まで、各種のものがあります。

重要: Oracle E-Business Suiteでは、変更によるカスタマイズを選択しないことをお薦めします。かわりに、拡張によるカスタマイズを行ってください。多くの場合、変更はアップグレードまたはパッチ処理中に保持されないことに注意してください。

コンポーネント

コードのモジュール(フォーム、レポート、SQL*Plusスクリプトなど)やOracle Application Object Libraryオブジェクト(メニュー、職責、メッセージなど)、またはデータベース・オブジェクト(表、ビュー、パッケージ、ファンクションなど)。

カスタム・アプリケーション

カスタム・アプリケーションはOracle Application Object Libraryに登録されている非Oracle E-Business Suiteアプリケーションで、通常は(少なくとも)専用のディレクトリ構造と他のコンポーネントを備えています。

データベース・オブジェクト

表、索引、ビュー、順序、データベース・トリガー、パッケージ、権限またはシノニム。

アプリケーション短縮名

アプリケーションの短い参照名で、空白を含みません。アプリケーション短縮名は、フォームからコンカレント処理を要求する際や、メッセージ・ディクショナリ・ルーチンをコールする際などに使用します。

アプリケーション・ベースパス

アプリケーションのディレクトリ・ツリーの最上位ディレクトリに変換する環境変数の名前です。Oracle Application Object Libraryは、ベースパスの下にある特定のディレクトリにおいて、アプリケーションの実行ファイル(フォーム・ファイルを含む)を検索します。

アプリケーション・ディレクトリ構造

アプリケーションのディレクトリ階層です。Oracle E-Business Suiteディレクトリ構造は、Oracle E-Business Suiteをインストールまたはアップグレードしたときに作成されます。カスタム・アプリケーションのディレクトリ構造は、別に作成します。

詳細は、Oracle E-Business Suite概要を参照してください。

Applications環境ファイル

Oracle E-Business Suiteインストールの環境変数を定義します。環境ファイルには、<dbname>.envおよびadovars.env (UNIXプラットフォームの場合)があります。<dbname>.envファイルには、Oracle E-Business Suite製品のアプリケーション・ベースパス変数と他の環境変数が含まれており、Oracle E-Business Suite管理ユーティリティによって自動的に再作成されます。adovars.envファイルには、Webサーバーで使用される仮想ディレクトリ構造の情報が含まれており、インストール時にアプリケーションのシステム管理者により変更されてユーザーの環境を設定します。

ニーズの判断

次の手順に従って、カスタマイズのニーズを判断します。

可能な場合は必ず、変更によるカスタマイズではなく拡張によるカスタマイズを行ってください。これにより、アプリケーション・ロジックの必要な部分を上書きしてしまったり、失ってしまうリスクを消去でき、既存のコンポーネントを検証する必要がなくなります。

変更によってカスタマイズを実行できますが、行わないことをお薦めします。このような変更にはある程度のリスクが発生し、Oracleサポート・サービスでも、アプリケーション部門でもサポートされていません。フォーム・ナビゲーションで単純な変更を行うと、妥当性チェックが実行されずに結果としてデータ整合性の問題が発生し、アップグレードまたはパッチ適用の際にデータが失われる場合があります。

Oracle E-Business Suiteフォームの変更が必要な場合は、まずCUSTOMライブラリを使用して変更できるかどうかを判断します。CUSTOMライブラリを使用すると、フォーム・コードへの大きな変更なしに、Oracle E-Business Suiteフォームの動作を変更でき、変更内容のアップグレードが容易になります。CUSTOMライブラリを使用した変更には、フィールドの非表示、「ズーム」ボタンによる他のフォームのオープン、ビジネス・ルールの適用、スペシャル・メニューへの選択肢の追加などがあります。

関連項目: CUSTOMライブラリの使用

拡張によるカスタマイズ

アプリケーションの拡張部分は、Oracle E-Business Suiteのコンポーネントとは別にして区別しやすくし、アップグレードまたはパッチの適用時の損失リスクを軽減するようにします。新規コンポーネントを別にしておくには、カスタム・アプリケーションを実装して新規コンポーネントの所有者とします。

すべてのカスタム・コンポーネントを所有する1つのカスタム・アプリケーションを実装することも、カスタム・コンポーネントを所有する複数のカスタム・アプリケーションを実装することもできます。たとえば、Oracle General Ledgerを拡張するカスタム総勘定元帳アプリケーションと、Oracle Payablesを拡張するカスタム買掛管理アプリケーションを定義できます。1つのOracle E-Business Suiteに多数のコンポーネントを作成する場合は、複数のカスタム・アプリケーションを使用します。すべてのOracle E-Business Suite製品に少数のコンポーネントしか作成しない場合は、1つのカスタム・アプリケーションを使用します。

次の手順に従って、各カスタム・アプリケーションを実装します。

関連項目: アプリケーション構築の概要

アプリケーション・フレームワーク設定の概要

新規コンポーネントの文書化

新規コンポーネントには、それぞれ少なくとも次の項目を記述します。

各拡張の記述を十分に行うと、次のタスクを簡略化できます。

拡張の登録と文書化には、Oracle Applications Managerのフラグ付きファイルの登録ユーティリティを使用します。この機能の詳細は、『Oracle E-Business Suiteメンテナンス・ガイド』を参照してください。

カスタム・アプリケーションの定義

アプリケーションはadspliceを使用して登録します。関連項目: 『Oracle E-Business Suiteセットアップ・ガイド』のADスプライサに関する項およびMy Oracle Supportナレッジ・ドキュメント1577707.1『Creating a Custom Application in Oracle E-Business Suite Release 12.2』

カスタム・アプリケーションには、その内容を表すアプリケーション名と短縮名を使用します。適切な場合は、拡張しているOracle E-Business Suiteアプリケーションに名前を関連付けます。たとえば、Oracle General Ledgerに対する拡張には、Custom General Ledgerというカスタム・アプリケーション名、XXGLというアプリケーション短縮名を指定できます。アプリケーション短縮名は4文字以内にする必要があります。

カスタム・アプリケーションの短縮名と今後のOracle E-Business Suite短縮名が競合するリスクを減らすため、カスタム・アプリケーションの短縮名はXXで始めることをお薦めします。Oracleでは、現在Oracle E-Business Suite製品で使用されているすべての名前に加えて、O、CPおよびEで始まる3文字から4文字の文字コードがすべて予約されています(「アプリケーション」ウィンドウで、すべてのアプリケーションを問い合せてください)。

関連項目: アプリケーションの登録

カスタム・アプリケーション・ディレクトリ構造の作成

アプリケーション・ディレクトリ構造を作成するには、適切なオペレーティング・システム・コマンドを使用します。アプリケーション・ベースパスの一部にリリース番号を定義し、将来カスタム・アプリケーションの複数のバージョンを使用できるようにする必要があります。インストール時に、リリース12には12.0など、Oracle E-Business Suiteのリリース番号を使用してください。

アプリケーション環境ファイルの変更

アプリケーション環境ファイルを変更して、アプリケーション・ベースパスに環境変数を定義します。カスタム・アプリケーション・ベースパス環境変数を、<dbname>.envファイルではなくadovars.envファイル(または各プラットフォームの相当するファイル)に追加します。

Oracle Application Object Libraryがアプリケーション・コンポーネントを検索できるようにするため、ベースパス変数の追加および新規環境ファイルの実行後に、Forms Serverおよび内部コンカレント・マネージャを再起動する必要があります。

詳細は、『Oracle E-Business Suiteセットアップ・ガイド』および『Oracle E-Business Suiteメンテナンス・ガイド』を参照してください。

新規コンポーネントの追加

新規コンポーネントを開発するときは、必ずそのコンポーネントを適切なカスタム・アプリケーションのサブディレクトリに正確に配置してください。

詳細は、Oracle E-Business Suite概要ガイドを参照してください。

フォームの追加

Oracle FormsでOracle Application Object Libraryを使用して新規フォームを作成することにより、Oracle E-Business Suiteとのシームレスな統合を確実に実施できます。Oracle E-Business Suiteと拡張部分のユーザー・インタフェースの一貫性を保つには、TEMPLATEフォームで開始した上で、このマニュアルで説明されているOracle E-Business Suiteフォーム開発標準に従う必要があります。

Oracle E-Business Suiteフォームを変更して拡張する場合は、元のフォームをコピーして、そのコピーに対して変更を加えます。

完了した(または変更した)フォームを、カスタム・アプリケーションの適切なディレクトリに移動します。フォームをOracle Application Object Libraryによって登録してカスタム・アプリケーションと関連付け、新規フォームの機能を定義します。

登録してファンクションを定義した後のフォームは、既存のメニューに追加したり(「既存メニューまたは既存の職責の変更」を参照)、新規メニューからコールすることができます(「メニューの追加」および「職責の追加」を参照)。また、CUSTOMライブラリの「ズーム」を使用して、フォームをOracle E-Business Suiteフォームに接続することもできます。

レポートまたはコンカレント・プログラムの追加

(レポートとプログラムの両方を含む)コンカレント・プログラムは、Oracle Reports、SQL*Plus、PL/SQL、C、Pro*Cおよび(一部のオペレーティングシステムでは)シェル・スクリプトで記述できます。Oracle Application Object Libraryのコンカレント処理機能を使用してコンカレント・プログラムを実行することにより、スケジューリング、優先順位、特定化機能といったOracle E-Business Suiteに備わっているいくつかの標準機能を提供できます。

コンカレント・プログラムを記述する前に、このマニュアルのコンカレント処理について説明している章を参照してください。

新規レポート発行フォームの追加

Oracle Application Object Libraryには、アプリケーションのレポートと他のプログラムを実行およびモニタリングする標準要求発行インタフェースが備わっています。コンカレント・プログラムを発行するために、特別なフォームを設計してメンテナンスする必要はもはやありません。レポートを発行するには、「要求の発行」ウィンドウを使用します。アプリケーションにカスタム・メニューを作成する場合、メニューに「要求の発行」ウィンドウがあるかどうかを確認してください。

カスタム・フォームからレポートまたはプログラムを発行する場合、Oracle Application Object Libraryの標準サブルーチンを使用して、コンカレント・プログラムをOracle Formsトリガー内部から起動されるコンカレント・マネージャへ発行できます。カスタム・レポート発行フォームから、ユーザーが指定可能な各パラメータ値を検証できます。

オンライン・ヘルプの追加

Oracle E-Business Suiteリリース12には、HTML形式のオンライン・ヘルプがあります。Oracle E-Business Suiteオンライン・ヘルプは『Oracle E-Business Suiteセットアップ・ガイド』のガイドラインに従って簡単に拡張できます。オンライン・ヘルプを拡張する場合は、アップグレード後にカスタム・ファイルの再伝播を実行する必要があります。

カスタム・フォームを持つカスタム・アプリケーションを作成しており、カスタム・アプリケーションに状況依存のオンライン・ヘルプを作成する場合、アプリケーションにヘルプ・システムを作成できます。

関連項目: カスタム・アプリケーション用オンライン・ヘルプの構築

メニューの追加

新規フォームをコールする新規メニューや、Oracle E-Business Suiteメニューおよびフォームを定義できます。新規メニューを定義する際は、(非表示)メニュー名の一部としてカスタム・アプリケーション短縮名を必ず入力し、作成したメニューを明確に区別して今後のOracle E-Business Suiteメニュー名との競合を避けることをお薦めします。アップグレード時には、変更したメニューや新たに作成したすべてのメニュー・オプションを含めて、Oracle E-Business Suiteが作成したすべてのメニューが削除されます。パッチもOracle E-Business Suiteメニューに影響を与える場合があります。

関連項目: メニューおよび機能セキュリティの概要

職責の追加

新しい職責は、「職責」ウィンドウを使用してOracle E-Business Suiteシステム管理者職責で定義できます。新しい職責は、カスタム・メニューおよびフォームに対して作成する必要があります。これらのカスタム職責は、カスタム・アプリケーションまたはOracle E-Business Suiteアプリケーションに関連付けることができます。カスタム職責は、どのアプリケーションに関連付けるかに関係なく、アップグレード後も保持されます。

詳細は、Oracle E-Business Suiteセキュリティ・ガイドを参照してください。

メッセージ・ディクショナリ・メッセージの追加

メッセージ・ディクショナリに、独自のメッセージを定義できます。新規メッセージは、常にカスタム・アプリケーションに関連付けてください(メッセージを定義する際は、作成したアプリケーション名を使用します)。アップグレードを行うと、Oracle E-Business Suite製品に関連付けられたカスタム・メッセージはすべて削除されます。カスタム・アプリケーションに関連付けられたメッセージは削除されません。

関連項目: メッセージ・ディクショナリの概要

カスタムPRODUCT_TOPの定義

Oracle Applicationsマネージャ自動構成コンテキスト・エディタを使用すると、関連するコンテキスト・ファイルにカスタムproduct_topを追加できます。product_top変数を追加する場合は、「PROD_TOP」変数タイプを選択します。

次の要件と制限に注意してください。

このトピックの詳細は、次のソースから入手できます。

変更によるカスタマイズ

Oracle E-Business Suiteのコンポーネントを変更するのは、Oracle E-Business Suiteの機能を使用しても要件を満たすことができず、拡張によるカスタマイズを選択できない場合のみです。処理ロジックに関する十分な理解と、コンポーネントのデータベース構造に関する基礎的な知識がない場合は、いずれのコンポーネントも変更しないでください。Oracle E-Business Suiteのコンポーネントの変更にはある程度リスクが伴い、Oracleサポート・サービスでも、Oracle E-Business Suite部門でもサポートしていません。

可能な場合は、変更するコンポーネントをカスタム・アプリケーションにコピーし、拡張によるカスタマイズのガイドラインに従ってください。カスタム・アプリケーションで変更済コンポーネントを定義できない場合は、元のコピーを保持する必要があります。カスタム・アプリケーションで実行できないカスタマイズの例には、「要求の発行」ウィンドウ以外のOracle E-Business Suiteレポート起動フォームから発行されたレポートがあります。レポートを実行する要求の実行時に、コンカレント・マネージャでは、レポートが適切なOracle E-Business Suiteディレクトリにあることと、特定の実行ファイル名が付いていることが想定されています。これは、レポートを識別する情報は、通常起動フォームにハードコードされているためです。

変更の文書化

Oracle Applications Managerのフラグ付きファイルの登録ユーティリティで変更する各コンポーネントは、リストで示す必要があります。このユーティリティの詳細は、『Oracle E-Business Suiteメンテナンス・ガイド』を参照してください。

フラグ付きファイルの登録ユーティリティでのリストに加え、各コンポーネントの変更に関して、少なくとも次の情報も文書化する必要があります。

各変更の文書化を十分に行うと、次のタスクを簡略化できます。

元のファイルの保持

「所定の位置」にあるOracle E-Business Suiteファイルのカスタマイズは避けてください。必ずファイルのコピーを作成してそのコピーを変更し、可能であれば操作はカスタム・アプリケーション・ディレクトリ内で実行します。

カスタマイズの前に、データを保護するため未変更のOracle E-Business Suiteアプリケーション・コンポーネントをOracle E-Business Suiteとは別のディレクトリにコピーします(変更が不要になった場合は未変更のコンポーネントを取り出せます)。たとえば、UNIXシステムではOracle E-Business Suiteインストール・ディレクトリ(多くの場合リリース番号を含んでいる$APPL_TOP環境変数で示されるディレクトリ)の下にorigという名前のサブディレクトリを作成します。ディレクトリorigには、変更する各コンポーネントのアプリケーション・ディレクトリ構造が含まれています。たとえば、Oracle General LedgerのフォームGLXSSMHRを変更する場合は、GLXSSMHR.fmbおよびGLXSSMHR.fmxの未変更バージョンをディレクトリ$APPL_TOP/orig/gl/forms/<language>にコピーします。

変更したコンポーネントにのみ、アプリケーション・ディレクトリを作成する必要があります。たとえば、Oracle General LedgerのOracle Reportsレポートを変更しない場合、ディレクトリ$APPL_TOP/orig/gl/reports/<language>を作成する必要はありません。

変更のコンポーネントをカスタム・アプリケーション・ディレクトリにコピーし、Oracle E-Business Suiteディレクトリにある元のコンポーネントを変更しない場合、そのコンポーネントはorigディレクトリにコピーする必要はありません。

既存フォームの変更

可能な場合は必ず、フォームの動作の変更をCUSTOMライブラリに限定してください。フォームそのものを変更する必要がある場合、次のガイドラインに従ってください(拡張によるカスタマイズのガイドラインも含まれています)。

Oracle Formsの.fmbファイルは、すべてのOracle E-Business Suite製品に対して用意されています。すべてのOracle E-Business Suiteフォームは$AU_TOP/forms/<language>ディレクトリ内にあります。変更する場合は、Oracle E-Business Suiteフォームをカスタム・アプリケーションにコピーします。フォームを変更するには、次の手順に従ってOracle Forms DeveloperおよびOracle Application Object Libraryを使用します。

  1. ファイルを識別します。

  2. ファイルをカスタム・アプリケーションにコピーして、ファイル名を変更します。

  3. 元のファイルを保存します。

  4. 変更を加えます。

  5. フォームにコメントします。

  6. フォームを作成します。

  7. フラグ付きファイルの登録ユーティリティにカスタマイズを登録します。

  8. カスタマイズの内容を文書化します。

関連項目: CUSTOMライブラリの使用

ファイルの識別

変更するOracle E-Business Suiteフォームを選択した後は、基礎となっているフォーム・ファイルを識別する必要があります。ファイルを検索するには、次の手順に従います。

変更の実行

フォームの変更は、外見上、ナビゲーション上および機能上の3つのカテゴリに分類できます。画面の定型挿入文テキストまたはフィールドの表示特性へ加えた外見上の変更は、フォーム処理に影響を与えません。CUSTOMライブラリを使用してフィールド・プロンプトを変更できます(プロンプトが項目のプロパティとなり、プログラムにより操作可能となったため)。ただし、フォームでのフィールドの並替え、または非表示および表示という(フィールドの並替えの影響による)フィールド属性の変更は、それらのフィールドに関連付けられた順序を起動するナビゲーションおよびトリガーを完全に分析して、ロジックおよび検証の変更により結果が変化しないことが確実である場合以外は行いません。どのフォームの妥当性チェック・ロジックも、削除または使用不可にしないでください。フィールド・エントリの特定の書式や範囲のみを許可するなど、妥当性チェックのロジックを追加できます(ただし、フォームそのものではなくCUSTOMライブラリに実施することをお薦めします)

多くのOracle E-Business Suiteフォームの場合、ほとんどのロジックは、フォームに連結しているライブラリ($AU_TOP/resource下に存在)や、データベースのストアド・パッケージに含まれています。そのため、場合によってはそれらのファイルも識別、コピー、変更する必要がある点に注意してください。

フォームへのコメント

Oracle E-Business SuiteフォームのPRE-FORMトリガーには、フォームの変更日付および作成者を記述するルーチンがあります。Oracle Formsには、フォーム・レベルのコメントを入力する機能もあります。フォームを変更する際は、これらの機能を両方とも使用します。

PRE-FORMトリガーにあるOracle E-Business SuiteのFND_STANDARD.FORM_INFOルーチンは、次のようになっています。 

FND_STANDARD.FORM_INFO('$Revision: <Number>$', 
                   '<Form Name>', 
                   '<Application Shortname>', 
                   '$Date: <YY/MM/DD HH24:MI:SS> $',
                   '$Author: <developer name> $');

Form NameおよびApplication Shortname引数を変更して、新規ファイル名およびカスタム・アプリケーションを反映する必要があります。ただし、このアプリケーション短縮名は、ユーザーが現在のウィンドウでヘルプを選択した後に参照するオンライン・ヘルプ・ファイルの選択に影響を与えます。ユーザーが元のフォームで元のOracle E-Business Suiteオンライン・ヘルプを参照するように設定する場合は、アプリケーション短縮名をそのまま維持する必要があります。オンライン・ヘルプは、アプリケーション短縮名のこのインスタンスに影響される唯一の機能です。

フォームを変更する際は常に、Date引数(DATE_LAST_MODIFIED)値を現在の日付に更新して、Author(LAST_MODIFIED_BY)値を変更の作成者に更新する必要があります。Dateエントリがない場合は追加します。改訂番号は、変更したフォームのベースとなっているフォームの元のバージョンを識別するためのものなので、更新しないでください。日付および改訂番号は、「ヘルプ」->「Oracle Applicationsについて」でオープンするウィンドウで確認できます。

さらに、フォームを変更する際は、フォーム・レベルのコメントにも新規エントリを追加します。次のように、フォーム・レベルのコメントをフォーマットします。 

Developer  Date	        Description
------------------------------------------------------------------------
J. Smith   12-SEP-2007  Changed boilerplate in Type region
R. Brown   16-SEP-2007  Added ENTRY_STATUS field with LOV to Type region

既存レポートの変更

Oracle E-Business Suite製品には、Oracle Reportsの.rdfファイルが用意されています。Oracle E-Business Suiteレポートを変更するため、カスタム・アプリケーションにコピーします。次の手順に従って、Oracle ReportsとOracle Application Object Libraryを使用してレポートを変更します。

  1. ファイルを識別します。

  2. 変更を加えます。

  3. レポートにコメントします。

  4. 作成したファイルを使用してコンカレント・プログラムを作成します。

ファイルの識別

変更するOracle E-Business Suiteレポートを選択した後は、基礎となっているレポート・ファイルを識別する必要があります。ファイルを検索するには、次の手順に従います。

変更の実行

データを変更しないレポートは、アプリケーションに与えるリスクなしに変更できます。カスタマイズしたレポートが有効な情報を生成するように、変更前に基礎的なデータ構造を十分に理解しておく必要があります(Oracle E-Business Suite製品のテクニカル・リファレンス・マニュアルを参照)。データを変更するレポートを修正する前に、レポートの処理ロジックを十分に理解してください。妥当性チェックのロジックは追加できますが、削除したり無効にしたりはしないでください。

レポートへのコメント

SQL*PlusおよびPL/SQLのレポートに、注釈文を使用して変更を記録するコメント・セクションを作成し、各変更にコメントを追加します。

SQL*PlusおよびPL/SQL: 

REM		Developer    Date       	Description
REM		------------------------------------------ 

REM		J. Smith     12-SEP-2007	Changed column 1 heading 

REM		R. Brown     16-SEP-2007	Added subtotal row

コードの既存の行を変更する場合、元の行をコメントにして外し、コードの新規行、開発者の名前および日付の前に変更に関する詳細なコメントを含めます。たとえば、次のとおりです。

SQL*PlusおよびPL/SQL: 

REM		B. Cleaver	11-OCT-2007 

REM		Column entered_dr format 99,999.99 heading 'Dr'
REM		Expanded column width and changed heading
Column entered_dr format 9,999,999.99 heading 'Debit Amount'

Oracle Reportsレポートでは、「レポート」画面を使用してコメントを追加します。コメントを次のような構造にします。 

Developer     Date           Description
-----------------------------------------------------
J. Smith      12-SEP-2007    Changed column 1 heading
R. Brown      16-SEP-2007    Added subtotal row

作成したファイルを使用したコンカレント・プログラムの作成

コンカレント・プログラム実行ファイルとその実行ファイルを使用するコンカレント・プログラムを定義し、プログラムをレポート・セキュリティ・グループに割り当てます。

関連項目: 標準要求発行の概要

既存Cプログラムの変更

オラクル社は、Oracle E-Business SuiteのCソース・コードを公開していません。Oracle E-Business Suiteには新規のCおよびPro*Cプログラムを追加できます。

既存PL/SQLストアド・プロシージャの変更

Oracle E-Business Suite PL/SQLストアド・プロシージャの変更は、Oracle E-Business Suiteの操作に深刻なダメージをもたらす場合があります。拡張によるカスタマイズを使用して、新規ストアド・プロシージャまたはデータベース・トリガーを追加して目的を達成するか、可能な場合はCUSTOMライブラリを使用することをお薦めします。Oracle Application Object Libraryオブジェクトは変更しないでください。変更対象は、Oracle Application Object Libraryフォーム、プログラムまたはサポートされているAPIを使用しているOracle Libraryデータのみです。Oracle E-Business Suiteストアド・プロシージャを変更する場合は、Oracle E-Business Suiteのアップグレードまたはパッチ適用時に変更内容を再適用する必要があります。さらに、Oracleサポート・サービスの支援が必要な問題が発生すると、場合によっては問題を切り分けるため変更を無効にする必要があります。

既存オンライン・ヘルプの変更

Oracle E-Business Suiteリリース12には、HTML形式のオンライン・ヘルプがあります。オンライン・ヘルプは『Oracle E-Business Suiteセットアップ・ガイド』のガイドラインに従って簡単に変更および拡張できます。既存のオンライン・ヘルプを変更する場合は、アップグレード後に変更を再実行する必要があります。オンライン・ヘルプを拡張する場合は、アップグレード後にカスタム・ファイルの再伝播を実行する必要があります。

既存のメッセージ・ディクショナリ・メッセージの変更

既存のメッセージ・ディクショナリ・メッセージは変更しないでください。カスタム・アプリケーションに関連する新規メッセージを追加するには、拡張によるカスタマイズを使用します。既存のOracle E-Business Suiteに新規メッセージを作成できますが、アップグレードの際に削除または上書きされるため再作成する必要があります。メッセージは、作成したメッセージ名(Oracle E-Business Suite製品と関連する名前)と重複する新規Oracle E-Business Suiteメッセージによってアップグレード時に上書きされます。カスタム・アプリケーションに関連するカスタム・メッセージは保持されます。

既存のメッセージを変更する必要がある場合は、アップグレードまたはパッチ適用後に再作成できるようにすべて記述しておきます。

既存メニューおよび既存職責の変更

既存のメニューおよび職責は変更しないでください。かわりに、「拡張によるカスタマイズ」の項で説明されているように新規メニューおよび職責を定義します。

機能セキュリティ・レポートを使用すると、既存のメニューを複製してからそのコピーを変更できます。Oracle E-Business Suiteメニューおよびサブメニューは、カスタム・アプリケーション職責およびメニューからコールできます。アップグレード後には、Oracle E-Business Suiteへの参照が無効になるという例外的なケースがあります。これは、フォーム、メニューまたはサブメニューが無効になるか、そのIDが変わった場合に発生します。アップグレード前に機能セキュリティ・レポートを実行すると、メニューがコールする対象が記録され、そのような状況を防ぐことができます。

Oracle E-Business Suiteデータベースのカスタマイズ

アプリケーションのデータベースは、オブジェクトの追加によって変更できます。既存のオブジェクトを変更することもできますが、この方法は採用しないことをお薦めします。Oracle E-Business Suiteのデータベース・オブジェクトに加えた変更は、どれもOracleサポート・サービスおよびOracle E-Business Suite部門ではサポートされず、Oracle E-Business Suiteの将来のリリースで競合する可能性があります。

カスタマイズを行う前に、必ずデータベースの完全バックアップを実行してください。

Oracle E-Business Suiteのデータの操作

Oracle E-Business Suiteを使用する以外の方法では、Oracle E-Business Suiteのデータを操作しないことをお薦めします。Oracle E-Business Suiteの表は相互に関連しています。Oracle E-Business Suiteを使用すると、Oracle E-Business Suiteの表に加えられたすべての変更が検証され、すべての関連が保持されます。SQL*Plusまたはカスタマイズしたアプリケーション・コンポーネントを使用してOracle E-Business Suiteデータを変更する場合は、監査機能の違反とデータ整合性の潜在的破壊といったリスクが発生します。不適切なカスタマイズが引き起こす潜在的なダメージの問題に注意する必要があります。

Oracle Application Object Libraryのデータベース・オブジェクトの変更

表またはプログラムなどのOracle Application Object Libraryオブジェクトは変更しないでください。変更対象は、Oracle Application Object Libraryフォーム、プログラムまたはサポートされているAPIを使用しているOracle Application Object Libraryデータのみです。Oracle Application Object Libraryは、表間に複雑な相互関連があるデータ駆動型システムです。Oracle Application Object Libraryの基礎となっているデータに加えた変更はすべて、データの整合性およびアプリケーションの機能を破壊する可能性があります。

データベースの変更の文書化

すべてのカスタム・データベース・オブジェクトと変更内容は、SQL*Plusスクリプトを使用して既存のデータベース・オブジェクトに定義します。これらのSQL*Plusスクリプトは、カスタム・アプリケーションのadmin/sqlディレクトリに配置します。これらのスクリプトには、オブジェクト生成スクリプトと、権限、シノニム、ビューおよびオブジェクト変更スクリプトをインクルードできます。これらのスクリプトを使用すると、アップグレードまたはパッチの適用後にオブジェクトを再作成し、他のOracle E-Business Suiteのインストールに変更を移行できます。

カスタム・アプリケーションORACLE IDの定義

新規データベース・オブジェクトを作成する場合、それらをカスタム・アプリケーションに関連付けます。カスタム・アプリケーション・オブジェクトに固有のORACLEスキーマ(ORACLE ID)を定義します。簡単に識別するため、カスタム・アプリケーションのアプリケーション短縮名をORACLEスキーマ名として使用します。ORACLEスキーマは、Oracle Application Object Libraryで登録する必要があります。

ORACLEスキーマの登録の詳細は、『Oracle E-Business Suiteメンテナンス・ガイド』を参照してください。

他のORACLEスキーマがカスタム・オブジェクトにアクセスし、カスタムORACLE IDがOracle E-Business Suiteオブジェクトにアクセスできるようにするには、権限付与およびシノニムを使用する必要があります。職責を定義する際は、職責にデータ・グループを割り当てます。通常、ほとんどの職責がAPPSスキーマに接続するので、APPSスキーマにはカスタム表での権限を付与します。

たとえば、カスタム表を所有する各XXGL ORACLEスキーマを使用してカスタム総勘定元帳アプリケーションを定義するには、2つのオプションがあります(Oracle General LedgerはGL ORACLEスキーマにインストールされます)。カスタム表の数が比較的少なく、Oracle E-Business Suite表より高度なセキュリティが必要でない場合、お薦めする(APPSスキーマと緊密に統合された)アプローチは次のとおりです。

Oracle E-Business Suiteの表のセキュリティとは別に、カスタム表により高度なセキュリティが必要な場合は、次のアプローチを使用します。

注意: Oracle E-Business Suiteは、アプリケーション間でデータを共有します。Oracle E-Business Suite製品の適切な権限およびシノニムは、アップグレード時に自動的に作成されます。カスタムORACLEスキーマには、カスタマイズしている特定の製品ではなくOracle E-Business Suiteからの権限が必要な場合があります。

カスタム・ビューの定義

新規または変更されたコードがOracle E-Business Suiteデータにアクセスする場合に、コードが標準アプリケーション・データベース構造の変更の影響を受けないようにするにはビューを使用します。APPSスキーマでビューを定義します。Oracle E-Business Suiteオブジェクト定義が変更された場合でもコードを変更する必要はなく、ビューを変更するのみです。

新規オブジェクトの追加

Oracle E-Business Suite製品はORACLE RDBMSを使用して開発されているため、オブジェクトを追加してそれらを既存のOracle E-Business Suiteオブジェクトに関連付けることにより簡単にデータベースを拡張できます。新規オブジェクトには標準命名規則を使用し(「ネーミング標準および定義」を参照)、新規オブジェクトをカスタムORACLEスキーマまたはAPPSスキーマへ適切に配置します。フレックスフィールド、Oracle AlertまたはOracle Web Applications Desktop Integratorによて使用される列を含む新規表は、Oracle Applications Object Libraryに登録する必要があります。

Oracle Application Object Libraryは、現行職責(通常はAPPS)と関連付けられたORACLEスキーマのフォームおよびプログラムを実行します。アクセスする必要のあるすべてのデータベースに、使用するORACLEスキーマへ付与された権限と、そのスキーマで作成されたシノニムが必要です。

ネーミング標準

表登録API

Oracle E-Business Suiteデータベース・オブジェクトの変更

Oracle E-Business Suiteデータベース・オブジェクトは、フレックスフィールドまたは新規データベース・オブジェクトを使用してもニーズを満たすことができない場合にのみ変更します。オブジェクトは、表の列も含めて削除しないでください。どうしても必要な場合は、NULLを許可した新規列を追加することにより表を変更します。変更の前に、必ず表構造をエクスポートします。Oracle E-Business Suiteのアップグレードまたはパッチ適用の際は、変更したオブジェクトがアップグレードに影響を与えたり、影響されないようにする必要があります(「Oracle E-Business Suiteのアップグレードとパッチ」を参照)。

Oracle E-Business Suiteのアップグレードとパッチ

Oracle E-Business Suiteのアップグレードとパッチによるカスタマイズへの影響は、ここで説明する標準に従うことによって最小限に抑えることができます。カスタマイズを保持するには、アップグレード処理中に特定のタスクを実行する必要があります。それらのタスクの多くは、Oracle E-Business Suiteのアップグレードに詳述されています。アップグレード実行前には、リリースの更新も含めて特定のプラットフォームおよびリリースについて、このマニュアルを十分にレビューしてください。パッチの場合、カスタマイズへの影響は完全アップグレードの場合より小規模ですが、同様の注意を払ってください。

Databaseの変更のチェック

Oracle E-Business Suiteデータベース・オブジェクトを変更した場合は、メディアからOracle E-Business Suiteの新バージョンをアンロードし(またはパッチをアンロードし)、アップグレードまたはパッチ適用前にドライバのスクリプトをすべて確認します。変更がそれらのスクリプトに影響を与えるかどうかを判断してください。変更がスクリプトに影響を与える場合は、変更を元に戻してアップグレードまたはパッチを実行してから、変更を再適用する必要があります。

Oracle E-Business Suiteデータベース構造への変更が、作成したビューに影響を与える場合は、アップグレード完了後にビューを変更する必要があります。カスタマイズしたコンポーネントがOracle E-Business Suiteの表に直接アクセスする場合、ベースとなっているOracle E-Business Suiteのデータ構造が変更された場合は、コンポーネントも変更する必要があります。

不要なカスタマイズの識別

各カスタマイズを確認し、そのカスタマイズが満たしたニーズがOracle E-Business Suiteの新しいリリースによって満たされているかどうかを判断します。カスタマイズが必要でなくなった場合、変更をアーカイブして新しいリリースへの移行は行いません。

カスタマイズの移行

必要な変更はすべて新しいリリースに移行する必要があります。Oracle E-Business Suiteディレクトリ構造で変更したすべてのコンポーネントを移行する他、カスタム・アプリケーション・ディレクトリのコンポーネントもすべて移行する必要があります。

Oracle E-Business Suiteアプリケーション・ディレクトリで変更したカスタム・コンポーネントを移行するには、まず変更していないコンポーネントがリリース間で変化していないかどうかを確認します。前のリリースのコンポーネントであった旧バージョン(origディレクトリ内にあります)と、コンポーネントの新バージョンを比較します。それらが異なっている場合は、新しいコンポーネントにカスタマイズを適用する必要があります(既存コンポーネント変更のガイドラインに従ってください)。リリース間でコンポーネントが変わっていない場合は、適切なorigディレクトリにコンポーネントの新しいリリースのコピーを作成し、変更済コンポーネントを前のリリースのディレクトリから新しいリリースのディレクトリにコピーします。

カスタム・アプリケーション・コードを移行する場合、アップグレード前にアプリケーション環境ファイルへの変更を文書化します。アップグレード処理により新しいアプリケーション環境ファイルが作成された後、新しいファイルを変更します。

Oracle Application Object LibraryローダーおよびAPIを使用してカスタムOracle Application Object Libraryオブジェクトを抽出し、抽出したローダー・スクリプトを使用してアップグレード後にカスタマイズを再適用することもできます。

権限およびシノニム・スクリプトの再実行

どの変更がアップグレード後も有効であるかの判別後、カスタマイズの適切な権限およびシノニム・スクリプトを再実行します。これらはすべてadmin/sqlディレクトリに存在している必要があります。この操作が必要なのは、以前カスタム・アプリケーションへのアクセス権限を付与したオブジェクトがアップグレード処理中に削除され、再作成されるために権限が失われる場合があるからです。

すべてのカスタマイズのテスト

アップグレード確認の最後の手順として、カスタマイズ済コンポーネントをすべてテストして、それらが正しく動作し、Oracle E-Business Suiteに加えたどの変更もカスタマイズに影響を与えていないことを確認します。

カスタム・アプリケーション用オンライン・ヘルプの構築

Oracle E-Business Suiteに付属するヘルプ・ファイルのカスタマイズに関する一般的は情報は、『Oracle E-Business Suiteセットアップ・ガイド』の「Oracle E-Business Suiteヘルプのカスタマイズ」を参照してください。次の項では、カスタム・フォームおよびアプリケーションのオンライン・ヘルプを構築する追加的な情報を説明します。

ヘルプ・システムの動作

Oracle E-Business Suiteのヘルプ・システムは、ウィンドウ・レベル単位での状況依存オンライン・ヘルプとなっており(つまり、アプリケーションの各ウィンドウに対して別々のヘルプが提供されます)、個々の標準要求発行レポートおよびプログラムに対しても同様です。状況依存の動作の仕組みは次のとおりです。

フォームの準備

カスタム・フォームが、PRE-FORMトリガーにあるFND_STANDARD.FORM_INFOルーチンのカスタム・アプリケーション短縮名を参照しているかどうかを検証します。

FND_STANDARD.FORM_INFO('$Revision: <Number>$', 
                   '<Form Name>', 
                   '<Application Shortname>', 
                   '$Date: <YY/MM/DD HH24:MI:SS> $',
                   '$Author: <developer name> $');

Application Shortname値をFNDにした場合、Oracle E-Business Suiteは有効なヘルプ・ターゲットを構成できないため、ユーザーはどのヘルプも参照できません。

HTMLヘルプ・ファイルの作成

任意のHTMLエディタを使用して、HTMLヘルプ・ファイルを作成できます。ヘルプ・ファイルには、必要なリンクおよび情報をどれでも含めることができます。カスタム・フォームからそれらのヘルプ・ファイルをコールできるようにするには、ファイルの最初の部分に次のようなフォームに関するHTMLアンカー・タグを記述する必要があります。

<A NAME="form_name_window_name"></A>

たとえば、次のようなアンカーをヘルプ・ファイルに記述します。

<A NAME="poxaccwo_headers"></A>

標準要求発行レポートおよびプログラムに対する状況依存ヘルプも作成でき、次の構文を使用してHTMLファイルにアンカーを記述します。

<A NAME="srs_report_shortname"></A>

たとえば、次のようなアンカーをヘルプ・ファイルに記述します。

<A NAME="srs_poxacrcr"></A>

注意: Oracle E-Business Suiteヘルプ・システムでは、ファイル名とHTMLアンカー名のどちらも大文字と小文字を区別しないで処理されます。

アプリケーションのすべてのウィンドウおよびレポートごとに、HTMLヘルプ・ファイルを原則として1つずつ作成することをお薦めしますが、必須ではありません。どのアンカー名も各アプリケーション短縮名に対して1回のみ使用されるのであれば、ユーザーの希望どおりにHTMLファイルを編成できます。

いったんファイルを作成した後は、『Oracle E-Business Suiteセットアップ・ガイド』の「Oracle E-Business Suiteヘルプのカスタマイズ」で説明されている手順に従って、それらのファイルをヘルプ・システムにアップロードします。

ヘルプ・ナビゲーション・ツリーの作成

カスタム・アプリケーションにヘルプ・ナビゲーション・ツリーを作成して、そのツリーへのリンクをOracle E-Business Suiteヘルプ・ナビゲーション・ツリーのメイン「ライブラリ」セクションに追加することもできます。ヘルプ・ナビゲーション・ツリーの作成およびカスタマイズに関する情報は、『Oracle E-Business Suiteセットアップ・ガイド』の「ヘルプ・ナビゲーション・ツリーのカスタマイズ」を参照してください。

HELP_TREE_ROOTプロファイル・オプションでは、カスタム・アプリケーションから状況依存ヘルプが起動されたときに表示されるヘルプ・ナビゲーション・ツリーを決定します。このプロファイル・オプションの詳細は、『Oracle E-Business Suiteセットアップ・ガイド』の「Oracle Application Object Libraryのプロファイル・オプション」を参照してください。

アップグレードとパッチ

Oracle E-Business Suiteヘルプ・システムに対するアップグレードとパッチが、カスタム・アプリケーション短縮名に関連したヘルプ・ファイルとナビゲーション・ツリーに影響を与えることはありません。しかし、ファイルとツリー構造のコピーを安全な場所に保存し、問題の発生に備えて、アップグレードまたはパッチの適用後にそれらのコピーを元の場所に移動できるようにしておく習慣は常に有効です。

重要: ヘルプ・システムのメカニズムはリリース12以上で変更される予定となっており、アップグレード時にヘルプ・システムを修正する必要が生じる可能性があります。

カスタム・オブジェクトとスキーマの統合

Oracle E-Business Suiteと密に統合する必要のあるカスタム・オブジェクトおよびカスタム・スキーマがある場合、この項の次の手順に従います。

注意: カスタム・オブジェクトまたはスキーマをOracle E-Business Suiteと統合する場合は、Oracle E-Business Suiteコンサルタントに相談することをお薦めします。

  1. カスタム・スキーマを作成します。

    Oracle E-Business Suiteスキーマにカスタム・オブジェクトがある場合は、APPSスキーマと統合する前にそれらをカスタム・スキーマに移動する必要があります。

    オブジェクトが現在存在している各Oracle E-Business Suiteスキーマのカスタム・データ・オブジェクトを保持する新規スキーマを1つ作成します。それらのスキーマからカスタム表、索引、順序をエクスポートし、新規カスタム・スキーマにインポートします。

    データ・オブジェクトがAPPSスキーマと統合され、手順5でコード・オブジェクトを作成します。

    重要: カスタム・オブジェクトが、Oracle E-Business Suite命名規則に準拠していることを確認します。

    関連項目: ネーミング標準

  2. カスタム・スキーマを登録します。

    カスタム・スキーマが未登録の場合は、Oracle E-Business Suiteのシステム管理者職責を使用して登録します。ナビゲータを使用して、「セキュリティ: ORACLE: 登録」を選択します。

  3. インストール・グループ番号を決定および設定します。

    各カスタム・スキーマのインストール・グループ番号が未設定の場合は、Oracle E-Business Suiteのシステム管理者職責を使用して設定します。ナビゲータを使用して、「セキュリティ: ORACLE: 登録」を選択します。

    1回のインストールのみ必要なカスタム・スキーマを表すには、インストール・グループ番号0を使用します。

    複数組織を使用する場合、または製品インストール・グループが1つしかない場合、カスタム・スキーマのインストール・グループ番号に0を入力し、次の手順をスキップしてください。

    残りのカスタム・スキーマについては、カスタマイズするOracle E-Business Suite製品のインストール・グループ番号と一致するインストール・グループ番号を選択する必要があります。たとえば、スキーマPO2がインストール・グループ番号2をリストしていて、カスタム・スキーマCUST_PO2がそのスキーマをベースとしている場合、CUST_PO2のインストール・グループ番号も2に設定します。

  4. APPSスキーマを使用するようデータ・グループを変更します。

    Oracle E-Business Suiteのシステム管理者職責を使用して、ナビゲータから「セキュリティ: ORACLE: 登録」を選択します。カスタム・スキーマで使用していた各データ・グループについて、ORACLEスキーマ列の名前を適切なAPPSスキーマに移動します。

  5. カスタム・オブジェクトを作成し、APPSスキーマにアクセス権限を付与します。

    複数組織を使用する場合、または製品インストール・グループが1つしかない場合、次の手順を実行します。

    他の場合は、各表および順序のシノニムを、関連するカスタム・スキーマの適切なAPPSスキーマに作成します。これを実行するには次の手順を行います。

  6. 重複したコード・オブジェクトを削除します。

カスタム・フォームのアップグレード

この項では、Oracle Forms 6i、Oracle E-Business Suiteコーディング標準およびOracle Application Object Libraryで作成されたカスタム・フォームのアップグレードについて説明します。リリース11iと統合するために作成されたカスタム・フォームに適用されます。

カスタム・フォームのリリース12へのアップグレードは、次の基本的な手順で構成されています。

  1. Oracle Forms 6iフォームをOracle Forms 10gに変換し、PL/SQL関連の必要な変更もすべて適用します。

  2. Oracle Forms 10gの.fmbファイルでOracle E-Business Suiteアップグレード・ユーティリティを使用し、フォームをリリース12の標準に準拠させるために役立つ変更を適用します。

  3. アップグレード・ユーティリティが検出したエラーを修正し、もう一度ユーティリティを実行して変更を検証します。

  4. アップグレードしたフォームに.fmxファイルを作成します。

  5. Oracle E-Business Suiteリリース12内でアップグレードしたフォームをテストします。

最初の手順をスキップして、Oracle E-Business Suiteアップグレード・ユーティリティの手順に直接進むことは技術的には可能ですが、最初の手順は個別に実行し、いずれかのアップグレード手順で問題が発生した場合に備えてフォームへの変更を独立させることをお薦めします。

目次   |   前へ   |   先頭へ   |   次へ

Oracle Logo
Copyright © 1995, 2013, Oracle and/or its affiliates. All rights reserved.