リリース12
E06048-01
目次
前へ
次へ
| Oracle Applications開発者ガイド リリース12 E06048-01 | 目次 | 前へ | 次へ |
この項では、Oracle Applicationsと統合するカスタム・アプリケーション・コンポーネント構築の標準について説明します。これらのガイドラインを使用すると、カスタム・コンポーネントを構築および保守する管理の手間が削減されます。
すべてのOracle Applications製品がOracle Application Object Libraryを使用して構築されているため、Oracle Applicationsをカスタマイズするには、その他のOracle ToolsとともにOracle Application Object Libraryを使用する必要があります。『Oracle Applications開発者ガイド』（このマニュアル）の関連の章で説明されている概念に熟知していることが必要です。
この項で説明する内容は、次のとおりです。
Oracle Applicationsカスタマイズの概要
拡張によるカスタマイズ
変更によるカスタマイズ
Oracle Applicationsデータベースのカスタマイズ
Oracle Applicationsのアップグレードとパッチ
カスタム・フォームのリリース12へのアップグレード
Oracle Applicationsのカスタマイズには、何種類かの方法があります。カスタマイズの一般的な例として、次のようなものがあります。
フォームの変更
外観
妥当性チェックのロジック
動作
レポートまたはプログラムの変更
外観
ロジック
データベースのカスタマイズ
読取り専用スキーマの追加
データベース・トリガーを伴う拡張ロジック
サード・パーティまたはカスタム・ソフトウェアの統合
プログラムの再リンク
次の基本的ビジネス・ニーズを満たすための機能が提供されています。
ニーズに対応するためのOracle Applicationsの機能拡張
新規コンポーネントの開発
既存コンポーネントの変更
Oracle Applicationsのアップグレード手順の改善
アップグレードを行う際のカスタム・コンポーネントの保持
カスタム・コンポーネントのアップグレードの簡略化
これらの機能の詳細は、次の参照先で説明されています。
既存のOracle Applicationsのために新しいコンポーネントを開発し、Oracle Application Object Libraryの開発機能を使用して新しいアプリケーションを開発します。
拡張によるカスタマイズは、既存のOracle Applicationsコンポーネントをカスタム・アプリケーション・ディレクトリにコピーして、コピーを変更するのと同様に簡単に行うことができます。
「適切なカスタマイズ」としても知られています。既存のOracle Applicationsコンポーネントを、具体的な要件にあわせて変更します。変更には、定型挿入文テキストの変更から、妥当性チェックのロジックの変更まで、各種のものがあります。
重要: Oracle Applicationsでは、変更によるカスタマイズを選択しないことをお薦めします。かわりに、拡張によるカスタマイズを行ってください。多くの場合、変更はアップグレードまたはパッチ処理中に保持されないことに注意してください。
コードのモジュール（フォーム、レポート、SQL*Plusスクリプトなど）やOracle Application Object Libraryオブジェクト（メニュー、職責、メッセージなど）、またはデータベース・オブジェクト（表、ビュー、パッケージ、ファンクションなど）。
カスタム・アプリケーションは、Oracle Application Object Libraryによって登録する非Oracle Applicationsアプリケーションであり、通常は（少なくとも）専用のディレクトリ構造およびその他のコンポーネントを備えています。
表、索引、ビュー、順序、データベース・トリガー、パッケージ、権限またはシノニム。
アプリケーションの短い参照名で、空白を含みません。アプリケーション短縮名は、フォームからコンカレント処理を要求する際や、メッセージ・ディクショナリ・ルーチンをコールする際などに使用します。
アプリケーションのディレクトリ・ツリーの最上位ディレクトリに変換する環境変数の名前です。Oracle Application Object Libraryは、ベースパスの下にある特定のディレクトリにおいて、アプリケーションの実行ファイル（フォーム・ファイルを含む）を検索します。
アプリケーションのディレクトリ階層です。Oracle Applicationsディレクトリ構造は、Oracle Applicationsをインストールまたはアップグレードしたときに作成されます。カスタム・アプリケーションのディレクトリ構造は、別に作成します。
詳細は、『Oracle Applications概要』を参照してください。
Oracle Applicationsインストールの環境変数を定義します。環境ファイルには、<dbname>.envおよびadovars.env（UNIXプラットフォームの場合）があります。<dbname>.envファイルには、アプリケーションのベースパス変数と他の環境変数が含まれており、Oracle Applications管理ユーティリティによって自動的に再作成されます。adovars.envファイルには、Webサーバーで使用される仮想ディレクトリ構造の情報が含まれており、インストール時にアプリケーションのシステム管理者により変更されてユーザーの環境を設定します。
次の手順に従って、カスタマイズのニーズを判断します。
Oracle Applicationsに適合しない特定の要件を調べます。
実装およびユーザーに関する項にあるように、標準アプリケーションの定義パラメータを変更してその要件を満たします。通常、アプリケーション構成の変更（記述フレックスフィールドの設定など）によってカスタマイズ・ニーズを絞り込むことができます。
カスタマイズで実現する要件を文書化します。
拡張（新規コンポーネントの追加）により要件を満たすことができるか、あるいは既存コンポーネントの変更が必要かを判断します。
可能な場合は必ず、変更によるカスタマイズではなく拡張によるカスタマイズを行ってください。これにより、アプリケーション・ロジックの必要な部分を上書きしてしまったり、失ってしまうリスクを消去でき、既存のコンポーネントを検証する必要がなくなります。
変更によってカスタマイズを実行できますが、行わないことをお薦めします。このような変更にはある程度のリスクが発生し、Oracleサポート・サービスでも、アプリケーション部門でもサポートされていません。フォーム・ナビゲーションで単純な変更を行うと、妥当性チェックが実行されずに結果としてデータ整合性の問題が発生し、アップグレードまたはパッチ適用の際にデータが失われる場合があります。
Oracle Applicationsフォームの変更が必要な場合は、まずCUSTOMライブラリを使用して変更できるかどうかを判断します。CUSTOMライブラリを使用すると、フォーム・コードの内容を大きく変更することなくOracle Applicationsフォームを変更でき、変更によりアップグレードが困難になることはありません。CUSTOMライブラリを使用して行える変更には、フィールドの非表示、「ズーム」ボタンによる他のフォームのオープン、ビジネス・ルールの適用、スペシャル・メニューへの項目の追加などがあります。
関連項目: CUSTOMライブラリの使用
アプリケーションの拡張部分は、Oracle Applicationsコンポーネントとは別にして区別しやすくし、アップグレードまたはパッチの適用時の損失リスクを軽減するようにします。新規コンポーネントを別にしておくには、カスタム・アプリケーションを実装して新規コンポーネントの所有者とします。
すべてのカスタム・コンポーネントを所有する1つのカスタム・アプリケーションを実装することも、カスタム・コンポーネントを所有する複数のカスタム・アプリケーションを実装することもできます。たとえば、Oracle General Ledgerを拡張するカスタム総勘定元帳アプリケーションと、Oracle Payablesを拡張するカスタム買掛管理アプリケーションを定義できます。1つのOracle Applicationsに多数のコンポーネントを作成する場合は、複数のカスタム・アプリケーションを使用します。すべてのOracle Applications製品に少数のコンポーネントしか作成しない場合は、1つのカスタム・アプリケーションを使用します。
次の手順に従って、各カスタム・アプリケーションを実装します。
カスタム・アプリケーションの定義
カスタム・アプリケーション・ディレクトリ構造の作成
カスタム・アプリケーションのアプリケーション環境ファイルへの追加
カスタム・アプリケーションへの新しいコンポーネントの追加
新規コンポーネントの文書化
ヒント: 変更内容およびカスタム・コンポーネントの履歴を記録しておくには、改訂管理システムを使用します。
関連項目: アプリケーション構築の概要
新規コンポーネントには、それぞれ少なくとも次の項目を記述します。
目的
入力パラメータ（レポートおよびプログラム）
サンプル出力（レポートおよびプログラム）
処理ロジック
使用するデータベース・オブジェクトおよびアクセスのタイプ（選択、更新、挿入、削除）
各拡張の記述を十分に行うと、次のタスクを簡略化できます。
ビジネス要件の変更に伴うコンポーネントの変更
Oracle Applicationsのアップグレードまたはパッチの適用に伴うコンポーネントの変更
Oracle Applicationsのアップグレードまたはパッチの適用後の、不要な拡張の識別
カスタム・コンポーネントがOracle Applicationsコンポーネントのコピーを変更したものである場合、ファイルapplcust.txtにコンポーネントをリストする必要があります。$APPL_TOP/adminディレクトリ（または各プラットフォームの相当する部分）にあるこのファイルには、カスタマイズの簡単なリストを記入する場所が1箇所あります。Oracle Applicationsは、パッチ・プロセス中にこのファイルを使用し、カスタマイズが上書きされる、またはパッチの適用後に置換する必要があるという警告を出力します。さらに、アップグレードまたはパッチの適用後にカスタマイズに加える変更の範囲を判断するために、このリストを使用することもできます。
applcust.txtファイルには、変更前のファイル名および場所、変更後のファイル名および場所（カスタマイズしたファイル）、簡単なコメントを記入する箇所があります。Oracle Applicationsコンポーネントのカスタマイズではないコンポーネントをリストする必要はありません（つまり、Oracle Applicationsファイルで始まらないカスタム・アプリケーションのコンポーネントをリストする必要はありません）。
カスタム・アプリケーションを登録するには、「アプリケーション」ウィンドウを使用します。カスタム・アプリケーションには、その内容を表す名前と短縮名を付けます。適切な場合は、それらの名前を拡張するOracle Applicationsに関連付けます。たとえば、Oracle General Ledgerへ加えた拡張を、Oracle General Ledgerという名前でアプリケーション短縮名XXGLを持つカスタム・アプリケーションに関連付けることができます。
短縮名は、最大50文字を設定できますが、アプリケーションの保守と、短縮名を使用するルーチンのコールを容易にするため、4文字から6文字までの名前を使用することをお薦めします。
カスタム・アプリケーションの短縮名が、今後のOracle Applications短縮名と競合するリスクを減らすため、カスタム・アプリケーションの短縮名をXXで始めることをお薦めします。Oracleでは、現在Oracle Applications製品で使用されているすべての名前に加えて、O、CPおよびEで始まる3文字から4文字の文字コードがすべて予約されています（「アプリケーション」ウィンドウで、すべてのアプリケーションを問い合せてください）。
関連項目: アプリケーションの登録
アプリケーション・ディレクトリ構造を作成するには、適切なオペレーティング・システム・コマンドを使用します。アプリケーション・ベースパスの一部にリリース番号を定義し、将来カスタム・アプリケーションの複数のバージョンを使用できるようにする必要があります。インストール時に、リリース12には12.0など、Oracle Applicationsのリリース番号を使用してください。
アプリケーション環境ファイルを変更して、アプリケーション・ベースパスに環境変数を定義します。カスタム・アプリケーション・ベースパス環境変数を、<dbname>.envファイルではなくadovars.envファイル（または各プラットフォームの相当するファイル）に追加します。
Oracle Application Object Libraryがアプリケーション・コンポーネントを検索できるようにするため、ベースパス変数の追加および新規環境ファイルの実行後に、Forms Serverおよび内部コンカレント・マネージャを再起動する必要があります。
詳細は、『Oracle Applicationsシステム管理者ガイド』を参照してください。
新規コンポーネントを開発するときは、必ずそのコンポーネントを適切なカスタム・アプリケーションのサブディレクトリに正確に配置してください。
詳細は、『Oracle Applications概要』を参照してください。
Oracle FormsでOracle Application Object Libraryを使用して新規フォームを作成することにより、Oracle Applicationsとのシームレスな統合を確実に実施できます。Oracle Applicationsと拡張部分のユーザー・インタフェースの一貫性を保つには、TEMPLATEフォームで開始した上で、このマニュアルで説明されているOracle Applicationsフォーム開発標準に従う必要があります。
Oracle Applicationsフォームを変更して拡張する場合、元のフォームをコピーして、そのコピーに対して変更を加えます。
完了した（または変更した）フォームを、カスタム・アプリケーションの適切なディレクトリに移動します。フォームをOracle Application Object Libraryによって登録してカスタム・アプリケーションと関連付け、新規フォームの機能を定義します。
フォームを登録してフォームにファンクションを定義すると、既存のメニューにそのフォームを追加したり（「既存メニューまたは既存の職責の変更」を参照）、そのフォームを新規メニューからコールできます（「メニューの追加」および「職責の追加」を参照）。さらに、CUSTOMライブラリの「ズーム」を使用して、フォームをOracle Applicationsフォームに接続することもできます。
（レポートとプログラムの両方を含む）コンカレント・プログラムは、Oracle Reports、SQL*Plus、PL/SQL、C、Pro*Cおよび（一部のオペレーティングシステムでは）シェル・スクリプトで記述できます。Oracle Application Object Libraryのコンカレント処理機能を使用してコンカレント・プログラムを実行することにより、スケジューリング、優先順位、特定化機能といったOracle Applicationsに備わっているいくつかの標準機能を提供できます。
コンカレント・プログラムを記述する前に、このマニュアルのコンカレント処理について説明している章を参照してください。
Oracle Application Object Libraryには、アプリケーションのレポートと他のプログラムを実行およびモニタリングする標準要求発行インタフェースが備わっています。コンカレント・プログラムを発行するために、特別なフォームを設計してメンテナンスする必要はもはやありません。レポートを発行するには、「要求の発行」ウィンドウを使用します。アプリケーションにカスタム・メニューを作成する場合、メニューに「要求の発行」ウィンドウがあるかどうかを確認してください。
カスタム・フォームからレポートまたはプログラムを発行する場合、Oracle Application Object Libraryの標準サブルーチンを使用して、コンカレント・プログラムをOracle Formsトリガー内部から起動されるコンカレント・マネージャへ発行できます。カスタム・レポート発行フォームから、ユーザーが指定可能な各パラメータ値を検証できます。
Oracle Applicationsリリース12には、HTML形式のオンライン・ヘルプがあります。『Oracle Applicationsシステム管理者ガイド』のガイドラインに従って、Oracle Applicationsオンライン・ヘルプを簡単に拡張できます。オンライン・ヘルプを拡張する場合、アップグレード後にカスタム・ファイルの再伝播を実行する必要があります。
カスタム・フォームを持つカスタム・アプリケーションを作成しており、カスタム・アプリケーションに状況依存のオンライン・ヘルプを作成する場合、アプリケーションにヘルプ・システムを作成できます。
関連項目: カスタム・アプリケーション用オンライン・ヘルプの構築
新規フォームをコールする新規メニューや、Oracle Applicationsメニューおよびフォームを定義できます。新規メニューを定義する際は、必ず（非表示）メニュー名の一部としてカスタム・アプリケーション短縮名を入力することにより、作成したメニューを明確に区別して今後のOracle Applicationsメニュー名との競合を避けるようにすることをお薦めします。アップグレード中に、変更したメニューや新たに作成したすべてのメニュー・オプションを含めて、Oracle Applicationsが作成したすべてのメニューが削除されます。パッチもOracle Applicationsメニューに影響を与える場合があります。
関連項目: メニューおよび機能セキュリティの概要
Oracle Applicationsシステム管理者職責で「職責」ウィンドウを使用して、新規職責を定義できます。新規職責は、カスタム・メニューおよびフォームに作成する必要があります。それらのカスタム職責は、カスタム・アプリケーションまたはOracle Applicationsに関連付けることができます。カスタム職責は、どのアプリケーションに関連付けるかに関係なく、アップグレード後も保持されます。
詳細は、『Oracle Applicationsシステム管理者ガイド』を参照してください。
メッセージ・ディクショナリに、独自のメッセージを定義できます。新規メッセージは、常にカスタム・アプリケーションに関連付けてください（メッセージを定義する際は、作成したアプリケーション名を使用します）。アップグレードを行うと、Oracle Applications製品に関連付けられたカスタム・メッセージはすべて削除されます。カスタム・アプリケーションに関連付けられたメッセージは削除されません。
関連項目: メッセージ・ディクショナリの概要
Oracle Applications機能を使用する要件を満たしておらず、拡張によるカスタマイズがオプションとして利用できない場合にのみ、Oracle Applicationsコンポーネントを変更します。処理ロジックに関する十分な理解と、コンポーネントのデータベース構造に関する基礎的な知識がない場合は、いずれのコンポーネントも変更しないでください。Oracle Applicationsコンポーネントの変更はある程度のリスクを伴い、Oracleサポート・サービスでも、アプリケーション部門でもサポートしていません。
可能な場合は、変更するコンポーネントをカスタム・アプリケーションにコピーし、拡張によるカスタマイズのガイドラインに従ってください。カスタム・アプリケーションで変更済コンポーネントを定義できない場合、元のコピーを保持する必要があります。カスタム・アプリケーションで実行できないカスタマイズの例には、「要求の発行」ウィンドウ以外のOracle Applicationsレポート起動フォームから発行されたレポートがあります。レポートを実行する要求の実行時に、レポートが適切なOracle Applicationsディレクトリにあることと、特定の実行ファイル名が付いていることがコンカレント・マネージャで想定されます。レポートを識別する情報は、通常起動フォームにハードコードされているためです。
変更する各コンポーネントを、ファイルapplcust.txtにリストする必要があります。$APPL_TOP/adminディレクトリ（または各プラットフォームの相当する部分）にあるこのファイルには、カスタマイズの簡単なリストを記入する場所が1箇所あります。Oracle Applicationsはパッチ処理時にこのファイルを使用し、カスタマイズが上書きされてパッチ処理後に元に戻す必要があることを示す警告メッセージを生成します。アップグレードまたはパッチ適用後に、カスタマイズに加える必要のある変更の範囲を判断するためにもこのリストを使用できます。applcust.txtファイルには、元のファイル名および場所と、簡単なコメントをリストする部分があります。Oracle Applicationsファイルのコピーであるカスタマイズ・ファイル（拡張によるカスタマイズ）には、宛先のファイル名および場所（カスタマイズされたファイル）も含めます。
applcust.txtのリストに加え、各コンポーネントの変更に関して、少なくとも次の情報も記述する必要があります。
変更の目的
変更したファイルの名前
入力パラメータへの変更（レポートおよびプログラム）
サンプル出力（レポートおよびプログラム）
処理および妥当性チェックのロジックの変更
使用するデータベース・オブジェクトおよびアクセスのタイプ（選択、更新、挿入、削除）への変更
ヒント: 変更内容およびカスタム・アプリケーションの履歴を記録しておくには、改訂管理システムを使用します。
各変更の文書化を十分に行うと、次のタスクを簡略化できます。
ビジネス要件の変更に伴う追加の変更
Oracle Applicationsのアップグレード後の、不要な変更の識別
アップグレードしたOracle Applicationsコンポーネントへの変更の再作成
「所定の位置」にあるOracle Applicationsファイルをカスタマイズすることは避けてください。必ずファイルのコピーを作成し、変更はコピーに対して行い、可能であればカスタム・アプリケーション・ディレクトリで行います。
カスタマイズの前に、データを保護するため未変更のOracle ApplicationsコンポーネントをOracle Applicationsとは別のディレクトリにコピーします（変更する必要がなくなった場合は未変更のコンポーネントを取り出せます）。たとえば、UNIXシステムではOracle Applicationsインストール・ディレクトリ（多くの場合リリース番号を含んでいる$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 Applicationsディレクトリでは元のコンポーネントを変更しない場合、コンポーネントをorigディレクトリにコピーする必要はありません。
可能な場合は必ず、フォームの動作の変更をCUSTOMライブラリに限定してください。フォームそのものを変更する必要がある場合、次のガイドラインに従ってください（拡張によるカスタマイズのガイドラインも含まれています）。
Oracle Formsの.fmbファイルは、すべてのOracle Applicationsにあります。Oracle Applicationsフォームはすべて$AU_TOP/forms/<language>ディレクトリに位置しています。変更するため、Oracle Applicationsフォームをカスタム・アプリケーションにコピーします。次の手順に従って、Oracle Forms DeveloperおよびOracle Application Object Libraryを使用してフォームを変更します。
ファイルを識別します。
ファイルをカスタム・アプリケーションにコピーして、ファイル名を変更します。
元のファイルを保存します。
変更を加えます。
フォームにコメントします。
フォームを作成します。
applcust.txtにカスタマイズを登録します。
カスタマイズの内容を文書化します。
関連項目: CUSTOMライブラリの使用
変更するOracle Applicationsフォームの選択後、基礎となっているフォーム・ファイルを識別する必要があります。ファイルを検索するには、次の手順に従います。
メニューから、「ヘルプ」->「Oracle Applicationsについて」を選択します。「フォーム情報」セクションをスクロールします。該当するフォーム名に.fmbが付いたファイルが、変更するフォーム・ソース・ファイルです。
フォーム・ファイル名の最初の2文字または3文字が、アプリケーション短縮名です。ファイルは、そのアプリケーションのforms/<language>ディレクトリの下か、$AU_TOP/forms/<language>ディレクトリにあります。
フォームの変更は、外見上、ナビゲーション上および機能上の3つのカテゴリに分類できます。画面の定型挿入文テキストまたはフィールドの表示特性へ加えた外見上の変更は、フォーム処理に影響を与えません。CUSTOMライブラリを使用してフィールド・プロンプトを変更できます（プロンプトが項目のプロパティとなり、プログラムにより操作可能となったため）。ただし、フォームでのフィールドの並替え、または非表示および表示という（フィールドの並替えの影響による）フィールド属性の変更は、それらのフィールドに関連付けられた順序を起動するナビゲーションおよびトリガーを完全に分析して、ロジックおよび検証の変更により結果が変化しないことが確実である場合以外は行いません。どのフォームの妥当性チェック・ロジックも、削除または使用不可にしないでください。フィールド・エントリの特定の書式や範囲のみを許可するなど、妥当性チェックのロジックを追加できます（ただし、フォームそのものではなくCUSTOMライブラリに実施することをお薦めします）
多くのOracle Applicationsフォームでは、ほとんどのロジックがフォームに連結しているライブラリ($AU_TOP/resource下に存在)や、データベースのストアド・パッケージに含まれています。そのため、場合によってはそれらのファイルも識別、コピー、変更する必要がある点に注意してください。
Oracle ApplicationsフォームのPRE-FORMトリガーには、フォームの変更の日付および作成者を記述するルーチンがあります。Oracle Formsには、フォーム・レベルのコメントを入力する機能もあります。フォームを変更する際は、これらの機能を両方とも使用します。
PRE-FORMトリガーにあるOracle Applicationsの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 Applicationsオンライン・ヘルプを参照するように設定する場合、アプリケーション短縮名をそのままにする必要があります。オンライン・ヘルプは、アプリケーション短縮名の内容に影響される唯一の機能です。
フォームを変更する際は常に、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 Reportsの.rdfファイルは、すべてのOracle Applicationsにあります。Oracle Applicationsレポートを変更するため、カスタム・アプリケーションにコピーします。次の手順に従って、Oracle ReportsとOracle Application Object Libraryを使用してレポートを変更します。
ファイルを識別します。
変更を加えます。
レポートにコメントします。
作成したファイルを使用してコンカレント・プログラムを作成します。
変更するOracle Applicationsレポートの選択後、基礎となっているレポート・ファイルを識別する必要があります。ファイルを検索するには、次の手順に従います。
「コンカレント・プログラム」ウィンドウを使用して、コンカレント・プログラム名を問い合せます（アプリケーション開発者職責またはシステム管理者職責のいずれかを使用）。問合せ基準として「プログラム」フィールドを使用します（プログラム名は、プログラムを実行する要求の発行時に表示されるのと同じ記述名です）。「実行ファイル」リージョンにある「名称」フィールドの内容を記録します。
アプリケーション開発者職責を使用して、「コンカレント・プログラム実行ファイル」ウィンドウを表示します。「コンカレント・プログラム」ウィンドウから取得した実行ファイル名を使用して、実行ファイル名を問い合せます。
「実行方法」フィールドから、レポート・タイプを識別します。ファイル名は、適切な接尾辞を持つ実行ファイル名です。次の表は、ファイル名の拡張子に対応するレポート実行方法と、サブディレクトリのリストです。
| 実行 | 拡張子 | サブディレクトリ |
|---|---|---|
| SQL*Plus | .sql | sql |
| Oracle Reportsプログラム | .rdf | reports |
| SQL*Loader（制御ファイル） | .ctl | bin |
レポート・ファイルは、実行ファイルを所有するアプリケーションのディレクトリ構造内の適切なサブディレクトリに存在している必要があります。ただし、起動実行スタイルまたは即時実行スタイルとしてリストされているOracle Applicationsプログラムは通常Cプログラムなので、それらのプログラムは変更できません。PL/SQLストアド・プロシージャの実行スタイルとしてリストされているプログラムは、データベースに格納されます。
データを変更するレポートを、アプリケーションに与えるリスクなしに変更できます。カスタマイズしたレポートが有効な情報を生成するように、変更前に基礎的なデータ構造を十分に理解する必要があります（Oracle Applications製品のテクニカル・リファレンス・マニュアルを参照）。データを変更するレポートを修正する前に、レポートの処理ロジックを十分に理解してください。妥当性チェックのロジックは追加できますが、削除したり無効にしたりはしないでください。
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コンカレント・プログラム実行ファイルとその実行ファイルを使用するコンカレント・プログラムを定義し、プログラムをレポート・セキュリティ・グループに割り当てます。
関連項目: 標準要求発行の概要
オラクル社では、Oracle ApplicationsのCソース・コードを公開していません。新規のCおよびPro*CプログラムはOracle Applicationsに追加できます。
Oracle Applications PL/SQLストアド・プロシージャの変更は、Oracle Applicationsの操作に深刻なダメージをもたらす場合があります。拡張によるカスタマイズを使用することにより、新規ストアド・プロシージャまたはデータベース・トリガーを追加して目的を達成するか、可能な場合はCUSTOMライブラリを使用することをお薦めします。Oracle Application Object Libraryオブジェクトは変更しないでください。Oracle Libraryデータのみ、Oracle Application Object Libraryフォーム、プログラムまたはサポートされているAPIを使用して変更できます。Oracle Applicationsストアド・プロシージャを変更する場合、Oracle Applicationsのアップグレードまたはパッチ適用時に変更内容を再適用する必要があります。さらに、Oracleサポート・サービスの支援が必要な問題が発生すると、場合によっては問題を切り分けるため変更を無効にする必要があります。
Oracle Applicationsリリース12には、HTML形式のオンライン・ヘルプがあります。『Oracle Applicationsシステム管理者ガイド』のガイドラインに従って、Oracle Applicationsオンライン・ヘルプを簡単に変更および拡張できます。既存のオンライン・ヘルプを変更する場合、アップグレード後に変更を再実行する必要があります。オンライン・ヘルプを拡張する場合は、アップグレード後にカスタム・ファイルの再伝播を実行する必要があります。
既存のメッセージ・ディクショナリ・メッセージは変更しないでください。拡張によるカスタマイズを使用して、カスタム・アプリケーションに関連する新規メッセージを追加します。既存のOracle Applicationsに新規メッセージを作成できますが、アップグレードの際に削除または上書きされるので再作成する必要があります。作成したメッセージ名（Oracle Applications製品と関連する名前）と重複する新規Oracle Applicationsメッセージは、アップグレード時にメッセージを上書きします。カスタム・アプリケーションに関連するカスタム・メッセージは保持されます。
既存のメッセージを変更する必要がある場合は、アップグレードまたはパッチ適用後に再作成できるようにすべて記述しておきます。
既存のメニューおよび職責は変更しないでください。かわりに、「拡張によるカスタマイズ」の項で説明されているように新規メニューおよび職責を定義します。
機能セキュリティ・レポートを使用すると、既存のメニューを複製してからそのコピーを変更できます。カスタム・アプリケーション職責およびメニューから、Oracle Applicationsメニューおよびサブメニューをコールできます。アップグレード後に、Oracle Applicationsへの参照が無効になるという例外的なケースがあります。これは、フォーム、メニューまたはサブメニューが無効になるか、そのIDが変わった場合に発生します。アップグレード前に機能セキュリティ・レポートを実行すると、メニューがコールする対象が記録され、そのような状況を防ぐことができます。
オブジェクトを追加することにより、アプリケーションのデータベースを変更できます。既存のオブジェクトを変更することもできますが、この方法を採用しないことをお薦めします。Oracle Applicationsのデータベース・オブジェクトに加えた変更は、どれもOracleサポート・サービスおよびアプリケーション部門ではサポートされず、Oracle Applicationsの将来のリリースで競合する可能性があります。
カスタマイズを行う前に、必ずデータベースの完全バックアップを実行してください。
Oracle Applicationsを使用する以外の方法では、Oracle Applicationsのデータの操作を行わないことをお薦めします。Oracle Applicationsの表は相互に関連しています。Oracle Applicationsを使用すると、Oracle Applicationsの表に加えられたすべての変更が検証され、すべての関連が保持されます。SQL*Plusまたはカスタマイズしたアプリケーション・コンポーネントを使用してOracle Applicationsデータを変更する場合、監査機能の違反とデータ整合性の潜在的破壊といったリスクが発生します。不適切なカスタマイズが引き起こす潜在的なダメージの問題に注意する必要があります。
表またはプログラムなどの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 Applicationsのインストールに変更を移行できます。
新規データベース・オブジェクトを作成する場合、それらをカスタム・アプリケーションに関連付けます。カスタム・アプリケーション・オブジェクトに固有のORACLEスキーマ（ORACLE ID）を定義します。簡単に識別するため、カスタム・アプリケーションのアプリケーション短縮名をORACLEスキーマ名として使用します。ORACLEスキーマは、Oracle Application Object Libraryで登録する必要があります。
ORACLEスキーマの登録の詳細は、『Oracle Applicationsシステム管理者ガイド』を参照してください。
他のORACLEスキーマがカスタム・オブジェクトにアクセスし、カスタムORACLE IDがOracle Applicationsオブジェクトにアクセスできるようにするには、権限付与およびシノニムを使用する必要があります。職責を定義する際は、職責にデータ・グループを割り当てます。通常、ほとんどの職責がAPPSスキーマに接続するので、APPSスキーマにはカスタム表での権限を付与します。
たとえば、カスタム表を所有する各XXGL ORACLEスキーマを使用してカスタム総勘定元帳アプリケーションを定義するには、2つのオプションがあります（Oracle General LedgerはGL ORACLEスキーマにインストールされます）。カスタム表の数が比較的少なく、Oracle Applications表より高度なセキュリティが必要でない場合、お薦めする（APPSスキーマと緊密に統合された）アプローチは次のとおりです。
XXGLのカスタム表での権限をAPPSへ付与
APPSにあるXXGL表に対するシノニムの作成
APPS ORACLEスキーマを使用するカスタム職責の定義
Oracle Applicationsの表のセキュリティとは別に、カスタム表により高度なセキュリティが必要な場合は、次のアプローチを使用します。
APPSのOracle Applicationsオブジェクトでの権限をXXGLへ付与
同名のAPPSオブジェクトに、XXGLにあるGL表のシノニムを作成
XXGLスキーマ使用によるカスタム職責の定義
注意: Oracle Applicationsは、アプリケーション間でデータを共有します。Oracle Applications製品の適切な権限およびシノニムは、アップグレード時に自動的に作成されます。カスタムORACLEスキーマには、カスタマイズしている特定の製品ではなくOracle Applicationsからの権限が必要な場合があります。
新規または変更されたコードがOracle Applicationsデータにアクセスする場合に、コードが標準アプリケーション・データベース構造の変更の影響を受けないようにするにはビューを使用します。APPSスキーマでビューを定義します。Oracle Applicationsオブジェクト定義が変更された場合でもコードを変更する必要はなく、ビューを変更するのみです。
Oracle ApplicationsはORACLE RDBMSを使用して開発されているため、オブジェクトを追加してそれらを既存のOracle Applicationsオブジェクトに関連付けることにより簡単にデータベースを拡張できます。新規オブジェクトには標準命名規則を使用し（「ネーミング標準および定義」を参照）、新規オブジェクトをカスタムORACLEスキーマまたはAPPSスキーマへ適切に配置します。フレックスフィールドまたはOracle Alertにより使用される列を含む新規表は、Oracle Applications Object Libraryで登録する必要があります。
Oracle Application Object Libraryは、現行職責（通常はAPPS）と関連付けられたORACLEスキーマのフォームおよびプログラムを実行します。アクセスする必要のあるすべてのデータベースに、使用するORACLEスキーマへ付与された権限と、そのスキーマで作成されたシノニムが必要です。
Oracle Applicationsデータベース・オブジェクトは、フレックスフィールドまたは新規データベース・オブジェクトを使用してもニーズを満たすことができない場合にのみ変更します。オブジェクトは、表の列も含めて削除しないでください。どうしても必要な場合は、NULLを許可した新規列を追加することにより表を変更します。変更の前に、必ず表構造をエクスポートします。Oracle Applicationsのアップグレードまたはパッチ適用の際は、変更したオブジェクトがアップグレードに影響しないようにし、また影響を受けないようにもする必要があります（「Oracle Applicationsのアップグレードとパッチ」を参照）。
ここで説明する標準に従うことにより、カスタマイズに対するOracle Applicationsのアップグレードとパッチの影響を最小限に抑えることができます。カスタマイズを保持するには、アップグレード処理中に特定のタスクを実行する必要があります。それらのタスクの多くは、『Oracle Applicationsのアップグレード』に詳述されています。アップグレード実行前に、使用しているプラットフォームおよびリリースに対応するそのマニュアルを、リリースの更新も含めて十分にレビューしてください。パッチの場合、カスタマイズへの影響は完全アップグレードの場合より小さいですが、同様の注意を払ってください。
Oracle Applicationsデータベース・オブジェクトを変更した場合、メディアからOracle Applicationsの新バージョンをアンロードし（またはパッチをアンロードし）、アップグレードまたはパッチ適用前にドライバのスクリプトをすべて確認します。変更がそれらのスクリプトに影響を与えるかどうかを判断してください。変更がスクリプトに影響を与える場合、変更を元に戻してアップグレードまたはパッチの適用を行ってから、変更を再び適用する必要があります。
Oracle Applicationsデータベース構造への変更が、作成したビューに影響を与える場合、アップグレード完了後にビューを変更する必要があります。カスタマイズしたコンポーネントがOracle Applicationsの表に直接アクセスする場合、ベースとなっているOracle Applicationsのデータ構造が変更されるとコンポーネントも変更する必要があります。
各カスタマイズを確認し、そのカスタマイズが満たしていたニーズがOracle Applicationsの新しいリリースによって満たされるかどうかを判断します。カスタマイズが必要でなくなった場合、変更をアーカイブして新しいリリースへの移行は行いません。
必要な変更はすべて新しいリリースに移行する必要があります。Oracle Applicationsディレクトリ構造で変更したすべてのコンポーネントを移行する他、カスタム・アプリケーション・ディレクトリのコンポーネントもすべて移行する必要があります。
Oracle Applicationsディレクトリで変更したカスタム・コンポーネントを移行するには、まず変更していないコンポーネントがリリース間で変化していないかどうかを確認します。前のリリースのコンポーネントであった旧バージョン（origディレクトリ内にあります）と、コンポーネントの新バージョンを比較します。それらが異なっている場合、新しいコンポーネントにカスタマイズを適用する必要があります（既存コンポーネント変更のガイドラインに従ってください）。リリース間でコンポーネントが変わっていない場合、適切なorigディレクトリにコンポーネントの新しいリリースのコピーを作成し、変更済コンポーネントを前のリリースのディレクトリから新しいリリースのディレクトリにコピーします。
カスタム・アプリケーション・コードを移行する場合、アップグレード前にアプリケーション環境ファイルへの変更を文書化します。アップグレード処理により新しいアプリケーション環境ファイルが作成された後、新しいファイルを変更します。
Oracle Application Object LibraryローダーおよびAPIを使用してカスタムOracle Application Object Libraryオブジェクトを抽出し、抽出したローダー・スクリプトを使用してアップグレード後にカスタマイズを再適用することもできます。
どの変更がアップグレード後も有効であるかの判別後、カスタマイズの適切な権限およびシノニム・スクリプトを再実行します。これらはすべてadmin/sqlディレクトリに存在している必要があります。この操作が必要なのは、以前カスタム・アプリケーションへのアクセス権限を付与したオブジェクトがアップグレード処理中に削除され、再作成されるために権限が失われる場合があるからです。
アップグレード確認の最後の手順として、カスタマイズ済コンポーネントをすべてテストして、それらが正しく動作し、Oracle Applicationsに加えたどの変更もカスタマイズに影響を与えていないことを確認します。
Oracle Applicationsに付属するヘルプ・ファイルのカスタマイズに関する一般的は情報は、『Oracle Applicationsシステム管理者ガイド』の「Oracle Applicationsヘルプのカスタマイズ」を参照してください。次の項では、カスタム・フォームおよびアプリケーションのオンライン・ヘルプを構築する追加的な情報を説明します。
Oracle Applicationsのヘルプ・システムは、ウィンドウ・レベル単位での状況依存オンライン・ヘルプとなっており（つまりアプリケーションの各ウィンドウに対して別々のヘルプが提供されます）、個々の標準要求発行レポートおよびプログラムに対しても同様です。状況依存の動作の仕組みは次のとおりです。
ユーザーが「ウィンドウ・ヘルプ」ボタンをクリックするか、メニューから「ヘルプ」->「ウィンドウ」を選択します。
Oracle Applicationsが、ユーザーのWebブラウザに特定のURLから該当するヘルプ・ファイルを取得するよう指示します。ブラウザに送られるURLは、次の部分から構成されます。
APPLICATIONS_HELP_WEB_AGENTプロファイル・オプションで指定されたベースURL。このプロファイル・オプションが設定されていない場合、APPLICATIONS_WEB_AGENTプロファイル・オプションで指定された値が使用されます。これらのプロファイル・オプションは、通常Oracle Applicationsのインストール時に設定されます。
現在の言語コード
フォームのFND_STANDARD.FORM_INFOルーチンで指定されたアプリケーション短縮名
フォームの名前（POXACCWOなど）
ウィンドウの名前（HEADERS）
存在する場合は、HELP_LOCALIZATION_CODEプロファイル・オプションの値
Oracle Applicationsが、ユーザーのWebブラウザに指示されたヘルプ・ファイルを戻します。
カスタム・フォームが、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 Applicationsは有効なヘルプ・ターゲットを構成できないので、ユーザーはどのヘルプも参照できません。
任意の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 Applicationsヘルプ・システムでは、ファイル名とHTMLアンカー名のどちらも大文字と小文字は区別されずに処理されます。
アプリケーションのすべてのウィンドウおよびレポートごとに、HTMLヘルプ・ファイルを原則として1つずつ作成することをお薦めしますが、必須ではありません。どのアンカー名も各アプリケーション短縮名に対して1回のみ使用されるのであれば、ユーザーの希望どおりにHTMLファイルを編成できます。
いったんファイルを作成した後、『Oracle Applicationsシステム管理者ガイド』の「Oracle Applicationsヘルプのカスタマイズ」で説明されている手順に従って、それらのファイルをヘルプ・システムにアップロードします。
カスタム・アプリケーションにヘルプ・ナビゲーション・ツリーを作成して、そのツリーへのリンクをOracle Applicationsヘルプ・ナビゲーション・ツリーのメイン「ライブラリ」セクションに追加することもできます。ヘルプ・ナビゲーション・ツリーの作成およびカスタマイズに関する情報は、『Oracle Applicationsシステム管理者ガイド』の「ヘルプ・ナビゲーション・ツリーのカスタマイズ」を参照してください。
HELP_TREE_ROOTプロファイル・オプションでは、カスタム・アプリケーションから状況依存ヘルプが起動されたときに表示されるヘルプ・ナビゲーション・ツリーを決定します。このプロファイル・オプションの詳細は、『Oracle Applicationsシステム管理者ガイド』の「Oracle Application Object Libraryのプロファイル・オプション」を参照してください。
Oracle Applicationsヘルプ・システムのアップグレードおよびパッチは、カスタム・アプリケーション短縮名に関連したヘルプ・ファイルおよびナビゲーション・ツリーには影響しません。しかし、これにより常にファイルおよびツリー構造のコピーが安全な場所に保存されることになり、問題が発生した場合、アップグレードまたはパッチの適用後にそれらを元の場所に移動できます。
重要: ヘルプ・システムのメカニズムはリリース12以上で変更される予定となっており、アップグレード時にヘルプ・システムを修正する必要が生じる可能性があります。
Oracle Applicationsと密に統合する必要のあるカスタム・オブジェクトおよびカスタム・スキーマがある場合、この項の次の手順に従います。
注意: カスタム・オブジェクトまたはスキーマをOracle Applicationsと統合する場合は、Oracle Applicationsコンサルタントに相談することをお薦めします。
カスタム・スキーマを作成します。
Oracle Applicationsスキーマにカスタム・オブジェクトがある場合、APPSスキーマと統合する前にそれらをカスタム・スキーマに移動する必要があります。
オブジェクトが現在存在している各Oracle Applicationsスキーマのカスタム・データ・オブジェクトを保持する新規スキーマを1つ作成します。それらのスキーマからカスタム表、索引、順序をエクスポートし、新規カスタム・スキーマへインポートします。
データ・オブジェクトがAPPSスキーマと統合され、手順5でコード・オブジェクトを作成します。
重要: カスタム・オブジェクトが、Oracle Applications命名規則に準拠していることを確認します。
関連項目: ネーミング標準
カスタム・スキーマを登録します。
カスタム・スキーマをまだ登録していない場合は、Oracle Applicationsのシステム管理者職責を使用して登録します。ナビゲータを使用して、「セキュリティ: ORACLE: 登録」を選択します。
インストール・グループ番号を決定および設定します。
各カスタム・スキーマのインストール・グループ番号をまだ設定していない場合は、Oracle Applicationsのシステム管理者職責を使用して設定します。ナビゲータを使用して、「セキュリティ: ORACLE: 登録」を選択します。
1回のインストールのみ必要なカスタム・スキーマを表すには、インストール・グループ番号0を使用します。
複数組織を使用する場合、または製品インストール・グループが1つしかない場合、カスタム・スキーマのインストール・グループ番号に0を入力し、次の手順をスキップしてください。
残りのカスタム・スキーマについては、カスタマイズするOracle Applications製品のインストール・グループ番号と一致するインストール・グループ番号を選択する必要があります。たとえば、スキーマPO2がインストール・グループ番号2をリストしていて、カスタム・スキーマCUST_PO2がそのスキーマをベースとしている場合、CUST_PO2のインストール・グループ番号も2に設定します。
APPSスキーマを使用するようデータ・グループを変更します。
Oracle Applicationsのシステム管理者職責を使用して、ナビゲータから「セキュリティ: ORACLE: 登録」を選択します。カスタム・スキーマで使用していた各データ・グループについて、ORACLEスキーマ列の名前を適切なAPPSスキーマへ移動します。
カスタム・オブジェクトを作成し、APPSスキーマにアクセス権限を付与します。
複数組織を使用する場合、または製品インストール・グループが1つしかない場合、次の手順を実行します。
各カスタム・データ・オブジェクトのすべての権限を、APPSに付与します。
すべてのカスタム・スキーマについて各カスタム・データ・オブジェクトのシノニムをAPPSに作成します。
APPSにカスタム・コード・オブジェクトを作成します。
他の場合は、各表および順序のシノニムを、関連するカスタム・スキーマの適切なAPPSスキーマに作成します。これを実行するには次の手順を行います。
各カスタム・データ・オブジェクトのすべての権限を、各APPSスキーマに付与します。
カスタム・スキーマと同じインストール・グループ番号を持つAPPSスキーマに、すべてのカスタム・データ・オブジェクトのシノニムを作成します。たとえば、CUST_PO2オブジェクトのAPPS2にシノニムを作成します。
各APPSスキーマに、カスタム・コード・オブジェクトを作成します。
重複したコード・オブジェクトを削除します。
この項では、Oracle Forms 6i、Oracle Applicationsコーディング標準およびOracle Application Object Libraryで作成されたカスタム・フォームのアップグレードについて説明します。リリース11iと統合するために作成されたカスタム・フォームに適用されます。
カスタム・フォームのリリース12へのアップグレードは、次の基本的な手順で構成されています。
Oracle Forms 6iフォームをOracle Forms 10gに変換し、PL/SQL関連の必須変更もすべて行います。
Oracle Forms 10gの.fmbファイルでOracle Applicationsアップグレード・ユーティリティを使用し、フォームをリリース12の標準に準拠させるために役立つ変更を適用します。
アップグレード・ユーティリティが検出したエラーを修正し、もう一度ユーティリティを実行して変更を検証します。
アップグレードしたフォームに.fmxファイルを作成します。
Oracle Applications 12内でアップグレード済フォームをテストします。
最初の手順をスキップして、Oracle Applicationsアップグレード・ユーティリティの手順に直接進むことは技術的には可能ですが、最初の手順を別個に実行し、いずれかのアップグレード手順で問題が発生した場合に備えてフォームへの変更を独立させることをお薦めします。
