ヘッダーをスキップ

Oracle Applications開発者ガイド
リリース12
E06048-01		目次へ
目次		前のページへ
前へ		次のページへ
次へ

コーディング標準の概要

コーディング標準の概要

これらの標準の重要性

このマニュアルで説明するコーディング標準は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』で説明されるユーザー・インタフェース標準とともに、Oracleの開発者によってOracle Applicationsを構築する際に使用されています。Oracle Applicationsと統合し、同じルック・アンド・フィールのカスタム・アプリケーション・コードを作成する場合は、これらの標準に従う必要があります。これらの標準に正確に従わない場合には、適切な結果を得られない場合があります。

このマニュアルは、特定のケースにおいて、これらの標準から外れた場合にどのような結果となるかを分析するものではありません。Oracle Applicationsにパッケージされているライブラリおよびプロシージャは、すべてこれらの標準に準拠することを想定しています。実際、Oracle Forms、Oracle Applicationsの標準ライブラリおよび標準は密接に関係しているため、少しでも標準から外れると、大きくかけ離れた予期せぬ結果になる場合があります。したがって、カスタム・アプリケーション・コードを開発する際は、このマニュアルおよび『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』で説明されている標準に正確に従うことをお薦めします。

コーディングの原則

Oracle Applicationsのコーディング標準は、次の原則に従います。

ハンドラでのコーディング

Oracle Applicationsは、開発、保守およびデバッグしやすいようPL/SQLコードの形式で組織化するため、ハンドラと呼ばれるパッケージ化されたプロシージャのグループを使用します。

Oracle Formsではトリガーにコードが配置され、トリガー・イベント発生時にコードが実行されます。複雑なロジックの実装には、複数のトリガーにわたってそのコードを分散させる必要がある場合があります。トリガーにあるコードは1箇所に配置されていないため、包括的な書込みまたは検討ができず、開発、保守およびデバッグが困難になります。特定の項目に影響を及ぼすコードおよびイベントを調べるため、開発者はフォーム全体で多くのトリガーをスキャンする必要があります。複数の項目に影響するコードは、トレースが非常に困難な場合があります。

開発、保守およびデバッグを容易にするためコードを集中化するには、パッケージ化されたプロシージャにコードを置き、それらのプロシージャをトリガーからコールします。処理するプロシージャへの引数として、トリガーの名前を渡します。このスキームによって、単一のビジネス・ルールのコードを、存在場所は1箇所であるが、複数のトリガー・ポイントに関連付けることができます。

項目ハンドラ、イベント・ハンドラ、表ハンドラ、ビジネス・ルールなど、作成するコードの種類ごとに、異なる種類のプロシージャが存在します。コードはこれらのプロシージャに存在します。プロシージャへのコール以外では、トリガーにコードは置かないでください。

ハンドラは、フォームそのもの、フォーム・ライブラリ、または必要に応じてデータベースの格納済パッケージにあるプログラム・ユニットに存在します。

項目ハンドラ

項目ハンドラは、項目に作用するコードをすべてカプセル化するPL/SQLプロシージャです。項目の検証、デフォルト化および動作ロジックのほとんどは、通常は項目ハンドラにあります。

関連項目: 項目ハンドラのコーディング

イベント・ハンドラ

イベント・ハンドラは、イベントに作用するコードをすべてカプセル化するPL/SQLプロシージャです。通常、イベント・ハンドラは、製品の特定のビジネス要件とは異なり、Oracle Formsまたは『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』の要件を満たすために存在します。

関連項目: イベント・ハンドラのコーディング

表ハンドラ

表ハンドラは、ブロックとその実表との間の相互作用を管理するコードをすべてカプセル化します。更新可能なブロックがビューに基づいている場合は、挿入、更新、ロックおよび削除を管理するプロシージャを提供する必要があります。参照整合性検査では、追加プロシージャがよく要求されます。表ハンドラは、そのサイズおよびデータベースとの相互作用の量により、Formsサーバーまたはデータベースに存在できますが、通常はデータベースに存在します。

関連項目: 表ハンドラのコーディングおよびサーバー側対クライアント側

ビジネス・ルール

ビジネス・ルールは、データの複雑な振舞いを記述します。たとえば、「購買担当の現在の信用評価が「よい」に達しない場合、値引を10%より大きくできない」というビジネス・ルールがあります。また、「在庫品目に対して購買依頼を行う場合は、希望入手日が必要である」というビジネス・ルールもあります。

ビジネス・ルール・プロシージャは、ビジネス・ルールが複雑、または1つ以上の項目やイベントに影響する場合、1つのビジネス・ルールを実装するためのコードをすべてカプセル化します。次にそのビジネス・ルール・プロシージャは、ビジネス・ルールに関与する項目またはイベント・ハンドラからコールされます。ビジネス・ルールが単純で、1つの項目またはイベントにのみ影響する場合は、ビジネス・ルールを項目またはイベント・ハンドラに直接に実装します。

ライブラリ

ライブラリには、再利用可能なクライアント側コードが含まれます。ライブラリは、特定の検証、ナビゲーションおよび外面的な動作と外観を保つために、同じコードをすべてのフォームで使用することによって、これらのフォーム・コーディング標準をサポートしています。

ライブラリでは、コードを一度作成すると複数のフォームで使用可能になります。さらに、実行ファイルがランタイムで添付されるため、フォームに影響を与えることなく容易に開発および保守できます。

フォームにはすべて、フォームをライブラリにリンクするための複数の標準トリガーおよびプロシージャが必要です。これらのトリガーおよびプロシージャの多くには、特定の項目またはブロックを開発者がオーバーライドするというデフォルトの動作があります。

関連項目: TEMPLATEフォームでの特殊トリガー

アプリケーション固有のライブラリ

アプリケーションごとに個別のライブラリを作成することをお薦めします。通常、各アプリケーションは、フォームの多くで見られるオブジェクトの動作を規定する、中央ライブラリを作成します。次のことを容易にするため、主要なトランザクション・フォームごとに追加ライブラリを作成する必要があります。

すべてのライブラリは、$AU_TOP/resourceディレクトリ（または同等ディレクトリ）に存在する必要があります。

ライブラリの添付

ファイル名に大文字・小文字の区別があるプラットフォームでは、ライブラリ添付が失われる場合があります。Oracle Applicationsの標準では、ライブラリ名はすべて大文字である必要があります（ファイル拡張子を除く）。ただし、Microsoft Windowsを使用して開発したフォームでは、添付ライブラリのファイル名に大文字・小文字が混在して使用されている可能性があり、UNIXなど大文字・小文字を区別するプラットフォームでは添付が無効となります。Microsoft Windows上のOracle Forms Developerでフォームにライブラリを添付する場合、ファイルの検索にブラウザの機能は使用しないでください。ファイル名のみを、拡張子を付けずに大文字のみで入力してください（たとえば、CUSTOM）。Oracle Formsにより、添付が入力したとおりに保存されます。添付にはディレクトリ・パスを含めないことに注意してください。Formsパスに、すべてのライブラリを保持するディレクトリを含める必要があります。

パフォーマンス

パフォーマンスは、どのアプリケーションにおいても重要な問題です。アプリケーションのパフォーマンスに対するユーザーの認識に最も影響するのはネットワークのパフォーマンスである場合が多いため、デスクトップ・クライアント、サーバーおよびデータベース・サーバー・コンピュータを接続するネットワークのオーバーロードは回避する必要があります。

Oracle Applicationsは、すべての層においてネットワークの通信量が最小になるよう設計されています。たとえば、次のコーディング標準を採用することによって、ユーザーが区別できるイベント当たりのネットワークのラウンド・トリップを1つに制限することを試みています。

Web互換性に配慮したコーディング

Oracle Applicationsの標準に正しく従うと、確実にフォームをWeb上に配置できます。

次の機能は、このアーキテクチャでは適用されないためフォームで使用しないでください。

標準の開発環境

これらのコーディング標準は、いくつかの製品の互換性のあるバージョンを含む、適切なOracle Applications開発環境でコードを開発していることを想定しています。1セットのOracle Applicationsリリース12のCDから全製品をインストールすると、Oracle Applicationsおよび他のOracle製品の正しいバージョンすべてを確実に用意できます。

標準のOracle Forms Developerを使用してフォームを開発することはできますが、Oracle Forms DeveloperからOracle Applicationsベースのフォームは実行できません。そのようなフォームを実行するには、JInitiatorでブラウザを介してフォームを実行する際に参照できる設定およびランタイム・コードに加え、ライブラリによっても参照される追加のOracle Application Object Libraryユーザー・イグジットが必要となります。ライブラリとユーザー・イグジットは両方とも、Oracle Application Object Libraryデータベース・スキーマの表、ビューおよびパッケージを参照するため、Oracle Application Object Libraryデータベース・スキーマが完全にインストールされていることも想定しています。

Oracle Applications実行のための必須設定

Oracle Applicationsの起動に使用するHTMLファイルには、Oracle Applicationsが正しく機能するためのいくつかの特定の設定が含まれている必要があります。次の表に、必須パラメータとその値を示します。

名前 値
colorScheme blue
lookAndFeel oracle
separateFrame true
darkLook true
readOnlyBackground automatic
dontTruncateTabs true
background no

さらに、ファイルOracleApplications.datには、次の行が含まれている必要があります。

app.ui.requiredFieldVABGColor=255,242,203

app.ui.lovButtons=true

app.ui.requiredFieldVA=true

Oracle Applicationsを実行するためForms Serverを起動する前に、UNIX環境変数またはNTレジストリの設定として、正しく設定する必要のある変数がいくつかあります。これらの変数にNLS_DATE_FORMATがあります。NLS_DATE_FORMATは、DD-MON-RRに設定する必要があります。

詳細は、『Oracle Applicationsのインストール』を参照してください。

フォーム生成の必須設定

フォーム生成時、Windows NTレジストリまたは環境ファイル（UNIXの場合）のNLS_LANG変数に、使用言語向けのキャラクタ・セットを指定していることを確認してください。指定するキャラクタ・セットと、Oracle Applicationsのインストールで使用されているキャラクタ・セットが同じになる必要があります。

また、環境ファイル（またはそのプラットフォームのWindows NTレジストリに相当するもの）のFormsパス環境変数の値を、フォームの開発および生成に使用するフォーム、ファイルまたはライブラリのあるディレクトリが含まれるように設定することも必要です。特に、参照されるすべてのフォームを検出するには<$AU_TOP>/forms/USディレクトリへのパスを、必要なOracle Applicationsライブラリ・ファイルを検出するには<$AU_TOP>/resourceディレクトリ（<$AU_TOP>は変数ではなく、適切なディレクトリ・パス）へのパスを含める必要があります。

フォーム開発の推奨設定

Oracle Forms Developerでは、ローカルのフォームにおいて、参照しているオブジェクトをオーバーライドできます。また、Oracle Forms Developerでは、特別の環境変数（NTではレジストリ設定）を設定しないかぎりオブジェクトが参照されていることは、通常示されません。Oracle Forms Developerを起動する前に、環境変数（レジストリ設定）ORACLE_APPLICATIONSをTRUEに設定します。この設定によって、参照しているオブジェクトに参照マーカー（中に「R」が表示された小さなフラグ）が表示されるため、参照しているオブジェクトを誤って変更することが避けられます。APPSTANDフォームから参照しているオブジェクトは、いずれも変更しないでください。

警告: Oracle Forms Developerでは、ローカルのフォームにおいて、参照しているオブジェクトをオーバーライドできます。APPSTANDフォームから参照しているオブジェクトは、いずれも変更しないでください。

Oracle Application Object Library for Release 12

Oracle Application Object Libraryには次のものが含まれます（一部分のリスト）。

オブジェクト・プロパティの設定

モジュール、ウィンドウ、キャンバス、ブロック、リージョン、項目など、ほとんどのフォーム・オブジェクトの特性は次のように設定されます。

共有オブジェクト

これらの標準は、Oracle Formsのオブジェクト参照機能に大きく依存します。これらの機能によって、複数のフォームでオブジェクトを再利用し、そのオブジェクトを共有するフォームにマスター・インスタンスへの変更を自動的に継承させることが可能になります。さらに、これらの共有オブジェクトによってクロス・プラットフォーム・サポートの柔軟性が提供され、稼動しているプラットフォームのルック・アンド・フィール規則にOracle Applicationsが準拠します。

APPSTANDフォーム

APPSTANDフォームには、共有オブジェクトのマスター・コピーが含まれます。これには次のものが含まれます。

TEMPLATEフォーム

TEMPLATEフォームは、新規フォームの開発すべてに必要な開始点です。これには、多くのAPPSTANDオブジェクト、いくつかの添付ライブラリ、必須トリガーおよび他のオブジェクトへの参照が含まれます。

$AU_TOP/forms/US（またはユーザーの言語およびプラットフォームに対応するもの）に置かれているこのファイルを、ローカルのディレクトリにコピーして適宜名前を変更し、新規フォームの開発をそれぞれ開始します。ファイル名、内部モジュール名、およびフォーム・レベルのPRE-FORMトリガーにあるFND_STANDARD.FORM_INFOへのコールにリストされている名前は必ず変更してください。

TEMPLATEフォームの概要

FNDMENU

（「ファイル」、「編集」、「表示」、「ヘルプ」など、すべてのフォームに共通のメニュー・エントリのある）Oracle Applicationsのデフォルト・メニューは、$AU_TOP/resource/USディレクトリ（またはその同等のもの）にファイルFNDMENUとして含まれています。このファイルを修正したり、自分のフォーム用に独自のメニューを作成したりしないでください。

標準ライブラリ

Application Object Libraryには、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』をサポートするいくつかのライブラリが含まれています。

TEMPLATEフォームには、FNDSQF、APPCOREおよびAPPDAYPKライブラリへの添付が含まれています。その他の標準のOracle Applicationsライブラリはこれらのライブラリに添付され、TEMPLATEフォームに添付されているように見える場合があります。

関連項目: TEMPLATEフォームでのライブラリ。TEMPLATEフォームに基づくフォーム内でコードを作成する場合、これらのライブラリに存在する任意の（パブリック）プロシージャをコールできます。独自のライブラリをコーディングする場合は、必要なライブラリを添付する必要があります。

プロパティ・クラス

プロパティ・クラスは、ほとんどすべてのOracle Formsオブジェクトに適用できる属性のセットです。TEMPLATEフォームには、APPSTANDへの参照を介して、すべてのウィジェットおよびコンテナの標準の外見および動作を『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』の記述にあわせるプロパティ・クラスが自動的に含められます。

このマニュアルで明示的に許可されている場合や、やむを得ない場合でないかぎり、プロパティ・クラスによって設定された属性はオーバーライドしないでください。継承した属性のオーバーライドは、ごくまれにしか必要ありません。

アプリケーション固有のプロパティ・クラス、オブジェクト・グループおよびオブジェクト

各アプリケーションでは、APPSTANDと同じ方法で特定のアプリケーションに標準を実装できるよう、Oracle Formsの参照機能を利用する必要があります。

たとえば、General Ledgerアプリケーションでは、アプリケーション全体に渡って、「合計」フィールドの幅および動作に指定の標準が存在する場合があります。各フォームに参照されるGL_TOTALプロパティ・クラスは、幅、書式マスクなどのプロパティを設定できます。General Ledgerの開発者は、プロパティ・クラスのこのセットを参照した後に、GL_TOTALプロパティ・クラスをフォームの「合計」フィールドである各項目に適用するだけで、その標準の外見および動作を自動的に継承できます。項目またはブロック全体を再利用することもできます。

さらに、プロパティ・クラスは他のプロパティ・クラスに基づくことが可能なため、GL_TOTALクラスはAPPSTANDの標準TEXT_ITEM_ DISPLAY_ONLYクラスに基づくことができます。このようなサブクラス化によって、APPSTAND内で加えられた変更をアプリケーション固有のオブジェクトに自動的に継承させることが可能になります。

また、ほとんどのOracle Applications製品には、製品の開発バージョンをインストールしている場合、同じディレクトリに標準フォーム（GLSTANDやBOMSTANDなど、[アプリケーション短縮名]STANDという名前）があります。これらのファイルは、Oracle Applicationsフォームに参照されるアプリケーション固有のオブジェクト・グループ、プロパティ・クラスおよびその他のオブジェクトの格納に使用されます。

視覚属性

『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』に記述されているすべての視覚属性は、APPSTANDへの参照を介してTEMPLATEフォームに自動的に含められます。それぞれの視覚属性は、プロパティ・クラスに関連付けられるか、APPCOREルーチンによって実行時に適用されます。

特定のカラー・パレットまたは視覚属性の効果の詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。

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

Oracle Applicationsと統合されるアプリケーションは、フォームに限定されず、コンカレント・プログラムおよびレポート、データベース表およびオブジェクト、メッセージ、メニュー、職責、フレックスフィールド定義、オンライン・ヘルプなど多くの要素から構成されます。

また、アプリケーション構築では、アプリケーションが稼動するプラットフォームおよび言語、統合するその他のアプリケーション、保守の問題など、多くの全体的な設計課題を考慮する必要もあります。

考慮に入れる全体的な設計課題

アプリケーションを設計する際は、Oracle Applicationsの多くの機能がデータベース・オブジェクト、フォーム、コンカレント・プログラムなどを含むアプリケーションの様々な面に影響すること、またこれらの機能を含めることをアプリケーション設計の初期の段階から考慮する必要があることに留意してください。これらの機能の一部として、次のようなものがあります。

アプリケーション開発手順の概要

これは、Oracle Applicationsと統合するアプリケーションを作成する一般的なプロセスです。

  1. アプリケーションを登録します。関連項目: 『Oracle Applicationsシステム管理者ガイド - 構成』

  2. アプリケーション・ディレクトリ構造を設定します。関連項目: アプリケーション・フレームワーク設定の概要

  3. 適切な環境ファイルを修正します。関連項目: 『Oracle Applications概要』

  4. カスタムOracleスキーマを登録します。関連項目: 『Oracle Applicationsシステム管理者ガイド - 構成』

  5. データ・グループにカスタム・アプリケーションおよびOracleスキーマを含めます。関連項目: 『Oracle Applicationsシステム管理者ガイド - 構成』

  6. アプリケーションの表およびビューを作成します。関連項目: 表およびビュー

  7. Oracle ApplicationsのAPPSスキーマに表およびビューを統合します。関連項目: カスタム・オブジェクトとスキーマの統合

  8. フレックスフィールド表を登録します。関連項目: 表登録API

  9. アプリケーション・ライブラリおよびフォームを構築します。関連項目: フォーム開発手順の概要

  10. アプリケーション機能およびメニューを構築します。関連項目: メニューおよび機能セキュリティの概要

  11. アプリケーション職責を構築します。関連項目: 『Oracle Applicationsシステム管理者ガイド - セキュリティ』。

  12. コンカレント・プログラムおよびレポートを構築します。関連項目: コンカレント処理の概要

  13. CUSTOMライブラリを使用し、必要に応じてOracle Applicationsフォームをカスタマイズします。関連項目: CUSTOMライブラリを使用したOracle Applicationsのカスタマイズ

フォーム開発手順の概要

これは、Oracle Applicationsと統合するフォームを構築する一般的なプロセスです。

  1. フォームTEMPLATEをコピーして名前を変更します。関連項目: TEMPLATEフォームの概要

  2. TEMPLATEのコピーに必要なライブラリを添付します。TEMPLATEにはすでにいくつかのライブラリが添付されています。関連項目: TEMPLATEフォームの概要

  3. フォーム・ブロック、項目、値リストおよびその他のオブジェクトを作成し、適切なプロパティ・クラスを適用します。関連項目: コンテナ・オブジェクトのプロパティの設定およびウィジェット・オブジェクトのプロパティの設定

  4. 『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』に従って、ウィンドウ・レイアウトを作成します。

  5. 表ハンドラのロジックを追加します。関連項目: 表ハンドラのコーディング

  6. ウィンドウおよび代替のリージョン制御をコーディングします。関連項目: ウィンドウの動作の制御

  7. 「検索」ウィンドウ、行の値リストを追加し、問合せ検索を有効にします。関連項目: 問合せ検索の概要

  8. 従属フィールドなど、項目関連のロジックをコーディングします。関連項目: 項目関連

  9. メッセージ・ディクショナリを使用するメッセージをコーディングします。関連項目: メッセージ・ディクショナリの概要

  10. 必要に応じてフレックスフィールドのロジックを追加します。関連項目: フレックスフィールドの概要

  11. スペシャル・メニューに選択肢を追加し、必要に応じデフォルトのメニューおよびツールバーの動作を修正するロジックを追加します。

  12. その他のロジックをコーディングします。

  13. フォームを自己テストします。

  14. フォームをOracle Application Object Libraryに登録します。関連項目: フォーム・ウィンドウ

  15. フォームにフォーム機能を作成し、必要な場合はサブ機能を登録します。関連項目: メニューおよび機能セキュリティの概要

  16. フォーム機能をメニューに追加するか、カスタム・メニューを作成します。関連項目: メニューおよび機能セキュリティの概要

  17. メニューを職責に割り当て、職責をユーザーに割り当てます。関連項目: 『Oracle Applicationsシステム管理者ガイド - セキュリティ』

  18. Oracle Applications内からフォームをテストします（特にユーザー・プロファイルまたは機能セキュリティなどの機能を使用している場合）。

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

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