Oracle E-Business Suite開発者ガイド

ヘッダーをスキップ

メニューおよび機能セキュリティの概要

機能セキュリティを使用すると、アプリケーション機能を、承認されたユーザーにのみ提供できます。

アプリケーション開発者は、フォームを開発する際に機能を登録します。システム管理者は、特定の機能を含めたり除外する職責を作成することによって、機能セキュリティを管理します。

Oracle Application Object Libraryの機能セキュリティの使用方法の詳細は、Oracle E-Business Suiteセキュリティ・ガイドを参照してください。

基本の機能セキュリティ

アプリケーションのフォームと機能を、ナビゲータに表示される論理メニュー構造にグループ化します。
メニューを1つ以上の職責に割り当てます。
1つ以上の職責を1人以上のユーザーに割り当てます。

拡張機能セキュリティ

Oracle E-Business Suiteのフォーム・ベースのアーキテクチャは、複数の関連ビジネス機能を単一のフォームに集約します。
すべてのユーザーが、フォーム内の全ビジネス機能にアクセスする必要はありません。
Oracle E-Business Suiteでは、アプリケーション・ロジックの個々の要素を機能として識別できます。
機能は、職責に基づいて(職責に含むか除外するかによって)保護されます。

用語

機能

機能はアプリケーションの機能の一部であり、メニュー(さらには職責)に割り当てたり、メニューから除外するために、一意の名前を付けて登録します。

機能には、フォーム機能、サブ機能、非フォーム機能など複数のタイプがあります。フォーム機能は、短縮してフォームとも呼ばれます。

フォーム(フォーム機能)

フォーム機能(フォーム)は、Oracle Forms Developerフォームを起動します。フォーム機能には、「ナビゲータ」ウィンドウを使用してナビゲートできる一意のプロパティがあります。

サブ機能

サブ機能は、フォーム機能の保護可能なサブセットです。つまり、フォーム内から実行できる機能です。

開発者は、特定のサブ機能の可用性をテストするためにフォームを作成した後、現行の職責でそのサブ機能が使用可能かどうかに基づいてなんらかの措置を取ることができます。

サブ機能は、フォーム内のボタンその他のグラフィック要素と頻繁に関連付けられます。たとえば、あるサブ機能を有効にすると、それに対応するボタンも有効になります。

しかし、サブ機能はフォームの操作中いつでもテストおよび実行でき、それがユーザー・インタフェースへ明示的に影響するとはかぎりません。たとえば、サブ機能がグラフィック要素と関連付けられていないフォーム・プロシージャに対応している場合、このサブ機能の可用性はフォームのユーザーには明確に示されません。

セルフ・サービス機能(非フォーム機能)

機能の中には、HTMLページやJava Server Page (JSP)など他のコード・タイプをメニューや職責に含める方法を提供するものもあります。このような機能は通常、Oracle Self-Service Web Applicationsの一部として使用されます。この機能には、該当するファイルや機能をポイントするURLなど他の情報も含まれています。

メニュー

メニューとは、ナビゲータに表示される機能および機能のメニューを階層的に並べたものです。各職責には、それぞれメニューが割り当てられています。

Oracle E-Business Suiteのデフォルト・メニューはウィンドウ最上部からのプルダウン・メニューとして表示されますが、通常、機能セキュリティを使用して制御することはありません。

関連項目: プルダウン・メニューおよびツールバー

メニュー・エントリ

メニュー・エントリとは、機能または機能のメニューを識別するメニュー・コンポーネントです。場合によっては、機能と機能メニューの両方が同一のメニュー・エントリに対応していることもあります。たとえば、フォームとサブ機能メニューの両方が同じメニュー・エントリを独占することもあり得ます。

職責

職責は、アプリケーション・ユーザーがOracle E-Business Suiteを使用する際の現行権限を定義します。アプリケーション・ユーザーはサインオンする際に、次のような特定の権限を付与される職責を選択します。

ユーザーがアクセスできる機能。機能は職責に割り当てられたメニューによって決定されます。
ユーザーが実行できるレポートなどのコンカレント・プログラム(要求セキュリティ・グループ)。
フォーム、コンカレント・プログラムおよびレポートの接続先であるアプリケーション・データベース・アカウント(データ・グループ)。

フォームとサブ機能

フォームは、機能の特殊なクラスであり、次の2つの点で機能とは異なっています。

フォームは、「ナビゲータ」ウィンドウに表示され、ナビゲート先となることができます。サブ機能は、「ナビゲータ」ウィンドウに表示されず、ナビゲート先になることができません。
フォームは、それ自身で存在できます。サブ機能は、フォーム内に埋め込まれたロジックからのみコール可能であり、それ自身では存在できません。

フォームは、そのすべてのプログラム・ロジックを含む全体として、常に機能として指定されます。フォームのプログラム・ロジックのサブセットは、それらの機能を保護する必要がある場合に、オプションでサブ機能として指定できます。

たとえば、フォームに3つのウィンドウが含まれているとします。このフォーム全体が、保護できる機能として指定されます(職責に含めるか、職責から除外)。フォームの3つのウィンドウのそれぞれは、機能(サブ機能)として指定することもでき、これは個別に保護が可能であることを意味します。したがって、様々な職責でこのフォームが含まれる一方、適用された機能セキュリティ・ルールに応じて、それぞれの職責から特定のフォームのウィンドウをアクセス不可にできます。

機能セキュリティの使用方法

開発者が機能を登録

開発者は、一意の機能名を参照するためにOracle Formsコードの一部を要求でき、さらに現在の職責でその機能が使用可能かどうかに基づいてなんらかの操作を実行できます。

開発者が機能を登録します。また、開発者は機能に値を渡すパラメータも登録します。たとえば、フォームは機能パラメータがそのフォームに渡される場合のにみデータ入力をサポートします。

「フォーム機能」ウィンドウで、機能およびサブ機能を登録します。

開発者がメニューを作成

通常、開発者がアプリケーションで使用可能なすべての機能を含んでいるメニュー(つまり、すべてのフォームおよびその保護可能なサブ機能)を定義します。アプリケーションによっては、開発者は、特定のフォームおよびサブ機能を除外してアプリケーションの機能を制限する追加メニューを定義できます。

開発者が機能のメニューを定義する際は、通常はフォームに関連付けられたサブ機能メニュー上で、フォームのサブ機能をグループ化します。

メニューの作成時には、通常、各フォーム、各サブ機能、さらにメニューの個別行ごとの各サブメニューを含めます。一般に、各フォームおよび各サブメニューは、「ナビゲータ」ウィンドウ上の個別項目として表示されるようにプロンプトを持つ必要があります。

重要: サブ機能のプロンプトは、ナビゲータ上でユーザーから見えないようにするため、通常は含めないでください。これは、CUSTOMライブラリおよびズームを使用してオープンするがユーザーが明示的にナビゲートしないフォーム機能にも適用されます(つまり、フォーム機能を職責で使用可能にするためにメニューに含めますが、プロンプトは提供しないということです)。

関連項目: ズームのコーディング

システム管理者が機能を除外

各Oracle E-Business Suite製品は、事前定義された1つ以上のメニュー階層とともに提供されます。システム管理者は、事前定義されたメニュー階層を職責に割り当てることができます。職責をカスタマイズするには、システム管理者は、その職責が使用する除外ルールから、機能または機能のメニューを除外します。

メニューが除外されると、そのメニュー・エントリのすべて、つまり選択した機能および機能のメニューのすべてが除外されます。

職責から機能を除外すると、職責のメニュー体系全体にわたる機能すべてが除外されます。

現行職責によって使用可能な機能

ユーザーが職責を初めて選択したり、変更を行う場合、職責のメニュー体系から取得した機能のリストがメモリーにキャッシュされます。

システム管理者が現行職責から除外した機能は、使用不能とマークされます。

機能階層(メニュー階層)にあるフォーム機能は、「ナビゲータ」ウィンドウに表示されます。使用可能なサブ機能は、アプリケーションのフォームでの作業中にアクセスされます。

フォーム機能の使用

「ナビゲータ」ウィンドウのメニューからフォームをコールするには、フォームと、渡す必要のある引数から構成されるフォーム機能を定義します。さらに、そのフォーム機能をコールするメニューを定義します。

フォームをプログラムからオープンする必要があるときは、必ずOPEN_FORMではなくFND_FUNCTION.EXECUTEを使用します。FND_FUNCTION.EXECUTEを使用すると、Oracle E-Business Suiteセキュリティをバイパスすることなくフォームをオープンすることが可能になり、フォームの正しいディレクトリ・パスの検索も可能になります。フォームをプログラムからオープンして(たとえば異なるパラメータとともに)フォームの同じインスタンスを再起動する必要がある場合は、FND_FUNCTION.EXECUTEではなくAPP_NAVIGATE.EXECUTEを使用します。

問合せ専用フォーム

「フォーム機能」ウィンドウでフォーム機能を定義したり、FND_FUNCTION.EXECUTEまたはAPP_NAVIGATE.EXECUTEを使用して既存のフォーム機能をコールする場合は、次の文字列が使用できます。

QUERY_ONLY=YES

この文字列を「パラメータ」フィールド、または(other_params引数を使用して)引数文字列にある文字列に追加します。この引数によって、問合せ専用モードでフォームがコールできるようになります。FND_FUNCTION.EXECUTEプロシージャは、Oracle Application Object Library Navigatorでも使用されており、すべてのデータベース・ブロックを挿入不可、更新不可および削除不可に設定するQUERY_ONLYフラグを設定します。

問合せ専用モードでフォームをいつコールするかを動的に決定するには、コールのother_params引数への文字列をFND_FUNCTION.EXECUTEに追加します。

「検索」ウィンドウの「新規」ボタンなど、フォームが問合せ専用モードで実行される際には適用されないすべての機能を使用不可にするか削除します。メニュー(スペシャル・メニュー以外)上のエントリは、自動的に処理されます。フォームが問合せ専用モードにある場合に新規レコードにデフォルト値を設定するロジックは、すべてオフにします(このロジックは通常WHEN-CREATE-RECORDトリガーからコールされます)。次のようにパラメータquery_onlyをチェックしてこのコールをチェックします。

IF name_in('parameter.query_only') != 'YES' THEN
<defaulting logic here> END IF;

重要: ユーザーにフォームの更新権限がない場合にのみ、問合せ専用フォームを使用します。フォームの主要目的が値の参照である場合ではありません。

主に必要とするのが値の参照であるというだけで、フォームを問合せ専用に制限しないでください。ユーザーにフォームの更新権限がある場合、情報の問合せを目的とする特別なメニューからフォームをコールする場合であっても、個別の問合せ専用フォーム機能は作成しないようにします。変更が必要な場合に、更新可能モードでフォームを再オープンするためにナビゲータを使用することをユーザーに強いることは、ユーザー・インタフェース標準への明らかな違反です。

まれに、技術的な制限からフォームへの特定のコールについてユーザーを問合せモードに制限することが強いられる場合があります。ただし一般に、「ナビゲータ」メニューのブランチから、または別のフォームのスペシャル・メニューからなどというように、ユーザーがフォームにどうアクセスするかに関係なく、更新権限は職責内で一定となるようにする必要があります。

フォーム・ウィンドウ名の変更

「要求の発行」フォームなど、フォームによっては、フォーム・ウィンドウ名を変更する引数を受け入れるものがあります。「要求の発行」フォームで、パラメータTITLEを使用して、メッセージ・ディクショナリにあるメッセージの名前を指定します。そのメッセージがウィンドウ・タイトルとなります。

使用する構文は次のとおりです。

TITLE="<appl_short_name>:<message_name>"

メッセージREP_ROUTINGが(英語で)「Report Routing (工順レポート)」というテキストであるとします。ここで次の引数を使用します。

TITLE="MFG:REP_ROUTING"

そうすると、「Report Routing (工順レポート)」というタイトルで「要求の発行」ウィンドウがオープンされます。

「要求の発行」フォームのカスタマイズの詳細は、『Oracle E-Business Suiteセットアップ・ガイド』を参照してください。

ヘルプ・ターゲットの変更

Oracle E-Business Suiteの「ヘルプ」ボタンをユーザーが選択すると、アプリケーションはフォーム名およびウィンドウ名から構成されるヘルプ・ターゲットform_name_window_nameで、正しいヘルプ・ファイルのオープンを試行します。このターゲットのフォーム名の部分(およびオプションでヘルプ・ファイルのアプリケーション短縮名)は、次のパラメータを渡して上書きできます。

HELP_TARGET="Application_short_name/Alternate_Form_name"

たとえば、「要求の発行」フォームに対してOracle Receivablesヘルプを使用するために、次のパラメータでFNDRSRUNフォーム名に対するフォーム機能を定義できます。

HELP_TARGET="AR/FNDRSRUN"

FND_FUNCTION.EXECUTEまたはAPP_NAVIGATE.EXECUTEを使用して(other_params引数を使用して)フォーム機能をコールするとき、または「フォーム機能」ウィンドウで機能を定義するときに、HELP_TARGETパラメータを渡すことができます。

Oracle E-Business Suiteにおけるヘルプ・ターゲットの詳細は、『Oracle E-Business Suiteセットアップ・ガイド』を参照してください。

機能セキュリティ標準

この項では、Oracle開発者が遵守する機能セキュリティ標準について説明します。

一般的な機能およびメニュー標準

Oracle E-Business Suiteのメニュー構造には、機能と機能メニューという2種類の項目があります。一般的に、機能とはフォーム(フォーム機能)またはフォーム内のサブ機能(非フォーム機能)のいずれかです。

機能がフォームでもサブ機能でもないことがありますが、それはまれなケースなのでこの標準では扱っていません。

アプリケーション内の全機能を含むメニューを持つ「全機能」という職責が、すべてのOracle E-Business Suite製品に事前定義され、顧客に出荷されます。このメニューには、各製品のフォームへのリンクが1つ含まれています。

オブジェクト・ベースのメニュー

Oracle E-Business Suiteの標準のメニュー構造は、オブジェクトに対して行われるアクションのタイプとは対照的に、オブジェクト・ベースです。発注などのシングル・オブジェクトのメニュー・エントリへ最終的に到達するまで、必要なレベル数のカテゴリ別グループ化を行います。発注フォームは、トランザクション・フォーム、メンテナンス・フォーム、問合せフォーム、その他発注とともに機能するフォームなどを含め、すべて一緒にグループ化します。

メニュー・カテゴリ

メニューのトップ・レベルには、「セットアップ」と「レポート」の2つの一般カテゴリが必ずあります。セットアップ・フォームは別にグループ化します。このフォームは主にインストール時に使用するので、それが済んだ後も他のフォームと一緒にしておくと邪魔になってしまうからです。レポート・フォームは、レポートを実行することが唯一のタスクであるユーザーのために、別にグループ化します。このような構造を使用すると、レポート・フォームの保護が容易になります。また、レポートはシングル・オブジェクトのみによってグループ化されることはあまりありません。そのため、レポートはすべて、他のカテゴリ領域やブランチの下ではなく、トップ・レベルの「レポート」メニュー・エントリの下にグループ化する必要があります。

ある製品のトップ・レベルのメニューの単純な例を示します。ここでは「発注」エントリが、2番目のメニュー・レベルで複数のエントリに分解されます。

Purchase Orders 
Purchase Orders          (<-Purchase Orders Gateway) 
View Expiring Purchase Orders 
Mass Delete Purchase Orders 
Quotes 
Suppliers 
Setup 
Reports

レポートとプロセス

「要求の発行」フォームのインスタンスを別々に作成して、特定のプロセス(プログラム)またはプロセス・グループを起動する場合は、そのフォーム機能をメニュー内の該当するオブジェクト・ベースの名前の下に置きます(プロセスとはデータを操作するプログラムであり、データをソートしたり表示するだけのレポートではありません。)。

前述の例では、「発注の一括削除」というメニュー・エントリが専用の「要求の発行」ウィンドウを開き、「発注の一括削除」の標準要求発行プログラムを起動します。このプロセスはデータを削除するので、「レポート」メニュー・エントリではなく「発注」メニュー・エントリの下に表示されます。

複数行および単一行の表示

1つのフォーム内に複数行と単一行のデータ表示が両方ある場合(通常は組合せブロック)、複数行ウィンドウと関連するメニュー・エントリのタイトルは、エンティティ名の複数形の後に「要約」を付けます。たとえば「発注要約(英語の場合は発注が複数形)」となります。単一行ウィンドウ(および関連するメニュー・エントリがあればそれも)のタイトルは、エンティティ名の複数形にします。たとえば、「発注(英語の場合は複数形)」です。単一行バージョンのフォームのみがある場合、フォーム名および関連するメニュー・エントリは、単に「発注(英語の場合は複数形)」のような複数形のエンティティ名になります。

フォーム機能標準

機能名およびユーザー機能名

ユーザー機能名(「フォーム機能」フォームを使用して定義され、「メニュー」フォームのLOVの選択値である)は、単に「発注」などのフォーム名になります。エンド・ユーザーはユーザー機能名を「ナビゲータ」ウィンドウの「トップ10リスト」で確認するので、このようなユーザー機能のネーミング標準に従うことはとても重要です。

機能名(ユーザー機能名ではなく)を<APPLICATION_SHORTNAME>_<FORMNAME>_<MODE>と作成します。<MODE>はオプションであり、同じフォームを参照する機能が複数存在する場合に使用します。他の製品のフォームを参照する機能を作成する場合は、製品の短縮名をアプリケーションの短縮名として使用します(例: WIP_FNDRSRUN_AUTOCREATE)。

ユーザー機能名には、「2層の価格構造」のように数字で始まる名前を絶対に付けないでください。数字が「ナビゲータ」ウィンドウの「トップ10リスト」と見間違いやすいからです。メニュー・エントリ・プロンプトには1文字も数字を使用しないでください。これはナビゲータの「トップ10リスト」のキーボード・アクセラレータと競合してしまうためです。

同じフォームを複数の機能に使用し、渡されるパラメータのみが異なる場合、ユーザー機能名には「発注を表示」のようにその機能の論理名を付けます。このバージョンのフォームを発注の表示専用に使用することを示す場合、たとえばPO_POXPOMPO_VIEWなどの機能を内部で使用します。アンダースコア以外のセパレータ文字は使用しないでください。

サブ機能標準

使用不可機能の非表示

ボタン、フィールド、メニューの選択または他のフォーム項目が使用可能かどうかをサブ機能で判断する場合、ユーザーがアクセスできない機能の項目が非表示になるようにサブ機能をコーディングします。フォーム内で実行するアクションに基づいて有効または無効にする項目ではなく、ユーザーがフォーム内にいるときに有効にしない項目をすべて非表示にします。

サブ機能メニュー

フォーム内に、ユーザーが使用可能かどうかを職責によって判断するサブ機能がある場合があります。これを行うため、このようなサブ機能のメニューは、フォーム・レベルの下のメニュー階層に置かれます。サブ機能のメニューは、フォーム・エントリ名に必ず「_MENU」を付けることを前提としています(例: PO_POXPOMPO_MENU)。ユーザー・メニュー名は<フォーム名>: サブ機能という形式です(例: 「発注: サブ機能」)。

サブ機能は出荷時のメニューにあるフォームと直接連結しており、どのサブ機能がどのフォームの一部であるかをシステム管理者が理解しやすいようになっています。つまり、メニューとセキュリティの構造を分離して異なる階層にするのではなく、メニュー構造とセキュリティ構造を結合して1つの階層を形成しています。

サブ機能名

各フォームのサブ機能はすべて開発者が事前定義し、<フォーム>_<サブ機能>と命名します(例: PO_POXPOMPO_ DELETE)。ユーザー機能名は<フォーム名>: <サブ機能>です。たとえば、「発注: 削除」となります。システム管理者が「職責」フォームのLOVにある「自動縮小」を使用して、使用可能な全機能を検索して職責に含めたり除外できるので、このネーミング標準は重要です。たとえば、システム管理者は「発注」と入力した後、「発注」フォームそのものを表示し、そのフォームのサブ機能メニューおよびすべての制限可能なサブ機能を表示できます。このネーミング標準がないと、フォームの全サブ機能を検索することは困難です。

サブ機能をカテゴリ別にグループ化

ある特定のフォームに制限可能なサブ機能が多数存在し、それらのサブ機能が「承認」などのカテゴリ別によくまとまっている場合、サブ機能をカテゴリに基づいてグループ化し、PO_POXPOMPO_APPROVALS_MENUなどと命名して、その下に承認サブ機能をすべてリンクします。承認サブ機能すべてを単一のカテゴリにグループ化すると、システム管理者はその職責のメニュー1つを除くすべての承認サブ機能へのアクセスを制限できます。

サブ機能のカテゴリ別のグループ化は、複数のサブ機能カテゴリが存在するときに限定し、フォームの全サブ機能が単一のカテゴリに属するときは行いません。このようなサブ機能メニューおよびそれに属するサブ機能のユーザー名は、「発注: 承認」や「発注: 承認: バッチ承認」などのように、前述のサブ機能に関する標準に従います。「メニュー」という単語はサブ機能メニュー名に含まれませんが、これはサブ機能がメニューのように格納されるけれども、ユーザー表示上は本当のメニューではないことを明確に示すためです。そのかわり、「承認」ではなく「承認(英語の場合は複数形)」を使用するなど、複数形によって複数のサブ機能を表します。

メニューに複数回表示されるフォーム

メニュー内の別の場所にフォームを追加するには、システム管理者がそのフォームを追加の場所にリンクさせます。フォーム1つに適用されるサブ機能メニューは1つに限られるので、サブ機能メニューの2番目のコピーを作成する必要はありません。ただし、システム管理者が他の場所にあったサブ機能メニューとフォームの両方を新しい場所にリンクしてコピーすることは自由です(結果は同じです)。同じフォームをメニュー内の別の場所にある別のサブ機能にアクセスできるよう表示することは不可能です。

フォームの中には、1つのメニュー内に異なる機能名で数回表示されるものもあります(例:「クイックコード」フォームまたは「要求の発行」フォーム)。このようなフォームのサブ機能を「サブ機能」カテゴリに結合しないでください。各サブ機能は、下位のサブ機能メニューではなく、フォームの_menu上で別々のメニュー・エントリとして存在する必要があります。

このように特殊なケースについて、標準ではシステム管理者が明示的にメニューごとではなくサブ機能ごとに除外を行うように徹底しています。フォーム・ウィンドウ名は変わることもあるので、フォームが1つのメニューに2回以上表示されているかが常に明確にわかるわけではありません。システム管理者がサブ機能メニューを除外した場合、フォームが別の形で存在していてそれに属するサブ機能メニューのコピーが含まれていても気付かないことがあります。

メニュー内のどこかにサブ機能を含めておくと、メニューでコールすればいつでもそのサブ機能を使用できます。職責からサブ機能を除外すると、メニュー全体でそのサブ機能を使用することが制限されます。

機能セキュリティ・レポート

機能セキュリティ・レポートを使用すると、ナビゲータ・メニューの構造を文書化できます。このレポートをハードコピーとして使用することにより、Oracle E-Business Suiteソフトウェアをアップグレードする前に、自分でカスタマイズしたメニュー構造を記録しておくことができます。

機能セキュリティ・レポートは、機能セキュリティ機能レポート、機能セキュリティ・メニュー・レポートおよび機能セキュリティ・ナビゲータ・レポートで構成されます。

これらのレポートは、システム管理者の職責で設定した機能セキュリティ・メニュー・レポート要求から使用できます。各レポートで、機能セキュリティを確認する職責を指定します。

機能セキュリティ機能レポート

レポート発行時の職責を指定します。出力レポートには、指定した職責からアクセスできる機能の一覧が示されます。

レポートには、機能セキュリティ・ルールによって除外された項目は含まれません。

機能セキュリティ・メニュー・レポート

レポート発行時の職責を指定します。出力レポートには、すべてのサブメニューおよび機能を含む、完全な職責のメニューが一覧表示されます。

レポートには、ルールによって除外されたメニュー項目も示されます。

機能セキュリティ・ナビゲータ・レポート

レポート発行時の職責を指定します。出力レポートには、指定した職責について、ナビゲータに表示されるとおりにメニューが一覧表示されます。

このレポートには、機能セキュリティ・ルール、またはナビゲータに表示されない非フォーム機能によって除外された項目は含まれません。

PL/SQLプロシージャの機能セキュリティAPI

この項では、クライアント側PL/SQLプロシージャで使用できる機能セキュリティAPIについて説明します。

FND_FUNCTION.TESTおよびFND_FUNCTION_QUERYは、特定の機能に現在アクセス可能かどうかを示します。特定の機能の可用性をテストするコードを作成して、その機能が使用可能かどうかによって一定の措置を行うようにすることができます。特定のフォーム機能またはセルフ・サービス機能を実行するには

FND_FUNCTION.EXECUTEを使用します。

FND_FUNCTION.TEST

要約

function FND_FUNCTION.TEST
(function_name IN varchar2) return boolean;

説明

特定の機能に現在アクセス可能かどうかをテストします。通常、機能の可用性についてはフォームの起動時にテストします(たとえば、特定のボタンの表示や特定のウィンドウへのアクセスを防止するためです)。

引数(入力)

変数	説明
function_name	テストする機能の名前

例

IF (FND_FUNCTION.TEST('DEM_DEMXXEOR_PRINT_ORDER')) THEN  
/* Put Print Order on the Special menu */     
app_special.instantiate('SPECIAL1','&Print Order'); 
ELSE  
/* hide the corresponding button on the form
(and the special menu is not instantiated) */
app_item_property.set_property('orders.print_order',
DISPLAYED, PROPERTY_OFF); 
END IF;

FND_FUNCTION.QUERY

要約

 procedure FND_FUNCTION.QUERY
(function_name   IN varchar2,
accessible      OUT varchar2,
function_type   OUT varchar2,
form_path       OUT varchar2,
arguments       OUT varchar2);

説明

特定の機能が現在アクセス可能かどうかをチェックし、もしアクセス可能であれば、function_type、form_pathおよび引数にその機能に関する情報を戻します。その機能にアクセスできない場合、function_type、form_pathおよび引数の文字列は空白に設定されます。

引数(入力)

変数	説明
function_name	チェックする機能の名前。

引数(出力)

変数	説明
accessible	ユーザーが現在の職責からその機能にアクセスできるかどうかを「Y」または「N」で設定します。
function_type	「フォーム機能」フォームで特定される機能のタイプ。
form_path	フォームへのファイル・システム・パス(この機能に関連するフォームがない場合は空の文字列。)
arguments	この機能のために規定された引数の一覧。

FND_FUNCTION.EXECUTE

要約

 procedure FND_FUNCTION.EXECUTE
(function_name   IN varchar2,
open_flag       IN varchar2  default 'Y',
session_flag    IN varchar2  default 'SESSION',
other_params    IN varchar2  default NULL,
activate        IN varchar2  default 'ACTIVATE',
browser_target  IN varchar2  default NULL);

説明

指定のフォーム機能を実行します。フォームが添付されている機能のみを実行します。機能にアクセスできない場合は、エンド・ユーザーに対してメッセージが表示されます。

機能がOracle Application Object Libraryで定義されているかを確認してください。また、ナビゲータのメニューからフォームにアクセスする必要はなくても、職責のメニューのどこかに機能が必要です(これを行うには、機能をメニューに追加し、プロンプトは空白にしておきます)。このようにしておかないと、その機能が使用できないことを知らせるメッセージがユーザーに表示されます。

FND_FUNCTION.EXECUTEはAPP_NAVIGATE.EXECUTEと類似していますが、APP_NAVIGATE.EXECUTEの場合は2回目の起動時にフォームが再起動される点が異なります。

APP_NAVIGATE.EXECUTEおよびFND_FUNCTION.EXECUTEは、現在の(ソース)ウィンドウの位置とサイズを次のグローバル変数に格納し、これから開くターゲット・フォームからアクセス可能にします。

global.fnd_launch_win_x_pos
global.fnd_launch_win_y_pos
global.fnd_launch_win_width
global.fnd_launch_win_height

これらを使用する意図は、ターゲット・フォームをコール側フォームの現行ウィンドウと相対的に配置できるようにすることです。APP_NAVIGATE.EXECUTEをコールする際、これらの変数はターゲット・フォームが初めてオープンされるときに使用可能です。

APP_NAVIGATE.EXECUTEおよびFND_FUNCTION.EXECUTEを使用すると、Oracle Forms Developerベースのフォームおよび「ナビゲータ」ウィンドウからOracle Self-Service Applications (セルフ・サービス機能)の機能を開くことができます。引数には、OPEN_FORMスタイルの構文ではなく、URLスタイルの構文が必要です。ただし、Oracle Self-Service Applicationsから機能を開くのにAPP_NAVIGATE.EXECUTEおよびFND_FUNCTION.EXECUTEは使用できません(Oracle Forms Developerベースのライブラリにこれらのルーチンが含まれていないためです)。

引数(入力)

変数	説明
function_name	実行するフォーム機能の開発者名。
open_flag	「Y」はOPEN_FORMを使用すること、「N」はNEW_FORMを使用することを示します。open_flagには必ず「Y」を渡す必要があります。これは、Oracle FormsのNEW_FORMビルトインではなくOPEN_FORMビルトインを使用して機能を実行することを意味します。機能タイプがWWW、WWK、JSPまたはSERVELETのうちのどれかである場合、この引数は無視されます。
session_flag	「NO_SESSION」または「N」を渡すと、既存のフォームと同じセッションでフォームが開きます。他の値を渡すと、新しいデータベース・セッション(デフォルトの「SESSION」など)でフォームが開きます。新しいデータベース・セッションでフォームを開くと、独立したコミット・サイクルがそのフォームに発生します。必ず「SESSION」または「Y」を渡してください(これは下位互換性の点で「SESSION」と同じ結果になります)。機能タイプがWWW、WWK、JSPまたはSERVELETのうちのどれかである場合、この引数は無視されます。
other_params	「フォーム機能」フォームの「パラメータ」フィールドで機能に定義した任意のパラメータの追加パラメータ文字列。other_paramsを使用すると動的なパラメータ設定が可能になります。設定できるパラメータの個数に制限はありません。フォームをコールするには、複数の追加パラメータがある場合は、それらのパラメータに渡される値を二重引用符で囲む必要があります。たとえば、あるフォームが2件のコンテキスト情報を受け入れて、特定のウィンドウからフォームにアクセスして問合せを実行するとします。渡す連結文字列には次の構文が含まれます。 `FND_FUNCTION.EXECUTE( FUNCTION_NAME=> function_name, OPEN_FLAG=>'Y', SESSION_FLAG=>'Y', OTHER_PARAMS=> 'CONTEXT1="'\|\|:block.context1 \|\| ' " CONTEXT2=" \|\| :block.context2 \|\| ' " ');` Oracle Self-Service Applicationsの機能をコールする場合、機能定義から構成したようにother_params引数から任意の値をURLに追加します(アンパサンド「&」デリミタを付けます)。URLは次のように構成されます。 `HTML_Call_field&Parameters_field&OTHER_PARAMS` セルフ・サービス機能をコールする場合は、other_paramsにURLスタイルの構文を使用します。たとえば、次のようなコールを使用します。 `FND_FUNCTION.EXECUTE( FUNCTION_NAME=> function_name, OPEN_FLAG=>'Y', SESSION_FLAG=>'Y', OTHER_PARAMS=>'partyId='\|\| to_char(:cust.party_id));`

変数	説明
activate_flag	ACTIVATEまたはNO_ACTIVATEのいずれか(デフォルトはACTIVATE)。このフラグによって、フォーカスが新しいフォームに移動する(ACTIVATE)か、コール側のフォームにとどまるか(NO_ACTIVATE)が決まります。機能タイプがWWW、WWK、JSPまたはSERVELETのうちのどれかである場合、この引数は無視されます。
browser_target	この引数は、セルフ・サービス機能のコールのみに使用します。この引数を使用すると、使用するブラウザ・フレームを指定できます。デフォルトのNULLは、その機能が新しいブラウザ・ウィンドウで開かれることを意味します。

例

フォーム機能(セルフ・サービス機能ではない)のコールの例を次に示します。

FND_FUNCTION.EXECUTE(FUNCTION_NAME=>'DEM_DEMXXEOR', 
OPEN_FLAG=>'Y', SESSION_FLAG=>'Y', 
OTHER_PARAMS=> 'ORDER_ID="'||param_to_pass1||
'" CUSTOMER_NAME="'||param_to_pass2||'"');

FND_FUNCTION.USER_FUNCTION_NAME

要約

 function FND_FUNCTION.USER_FUNCTION_NAME
(function_name IN varchar2) 
return        varchar2;

説明

ユーザー機能名を戻します。

引数(入力)

変数	説明
function_name	機能の開発者名。

FND_FUNCTION.CURRENT_FORM_FUNCTION

要約

function FND_FUNCTION.CURRENT_FORM_FUNCTION return varchar2;

説明

現行フォームをコールした際に使用した機能名を戻します。

フォーム・ウィンドウ

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

アプリケーション・フォームを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』

フォーム・ブロック

フォームを一意に識別するための、アプリケーション名とフォーム名の組合せ。

フォーム

フォームのファイル名を入力します(拡張子は付けません)。フォームのファイル名はすべて大文字とし、.fmxファイルをアプリケーション・ディレクトリ構造のforms/<language>サブディレクトリに置く必要があります。

アプリケーション

これはフォームを所有しているアプリケーションです。

Oracle E-Business Suiteは、フォームを所有するアプリケーションに基づき、フォーム・ディレクトリの該当する言語ディレクトリでフォームを検索します。

たとえば、UNIXプラットフォーム上でアメリカ英語を使用している場合、Oracle E-Business Suiteは/<アプリケーションの最上位ディレクトリ>/forms/USというディレクトリでフォーム・ファイルを検索します。

ユーザー・フォーム名

「機能」ウィンドウを使用してフォームを選択した際に表示されるフォーム名。