Oracle APEXのアプリケーションに組み込んだ機能の有効化/無効化をするために、いくつかの方法が提供されています。本記事では、あまり使われることがないと思われるビルド・オプション（Build Options）について紹介します。
いままで、サーバー側の条件で制御していたけど、ビルド・オプションを使った方が良いかな？と思えることもあるでしょう。
ビルド・オプションの用途
マニュアルには、ビルド・オプションの３つのユース・ケースが紹介されています。
ユースケース１: インストール・タイプに基づいて機能を有効および無効にする
それぞれのビルド・オプションに紐づいたコンポーネントは完成された状態であり、ユーザーが必要性を判断してビルド・オプションのステータス(含める/除外)を設定します。アプリケーション作成ウィザードでは、機能として情報ページ、アクセス制御、アクティビティ・レポートなどが選択できますが、それがこのユースケースと言えます。
ユースケース２: インストール・タイプに基づいて機能を有効および無効にする
ビルド・オプションのステータスを含めるにして活用します。以下のシナリオが、このユースケースでの一例になります。
- 本番稼働中のアプリケーションのコピーを、開発中のアプリケーションとします。
- 開発中のアプリケーションに新機能を追加します。新機能にビルド・オプションを紐付けます。開発中のアプリケーションでは、ステータスは含めるにします。
- 開発中アプリケーションを本番稼働中のアプリケーションに置き換えます。新機能のビルド・オプションのステータスは除外とし、新機能は一般の利用者に見えないようにします。
- テストを十分行ったのち、本番稼働中のアプリケーションのビルド・オプションのステータスを含めるに変更します。この変更の後、利用者は新機能を利用できます。
ユースケース３: 機能の削除の影響を特定する
ビルド・オプションのステータスを除外にして活用します。以下のシナリオが、このユースケースでの一例になります。
- 本番稼働中のアプリケーションのコピーを、開発中のアプリケーションとします。
- 開発中のアプリケーションから取り除くコンポーネントを、ビルド・オプションに紐付けます。ステータスを除外にします。
- 開発中のアプリケーションで、コンポーネントを除外しても問題が発生しないことを確認します。
- 開発中のアプリケーションを本番稼働中のアプリケーションに置き替えます。ビルド・オプションのステータスは除外のままです。
- 本番稼働中のアプリケーションでも問題がないことが確認できたら、ビルド・オプションに紐づいているコンポーネントをアプリケーションから削除します。
動作確認用のアプリケーションの作成
最近のOracle APEXが提供しているアプリケーション作成ウィザードでは、機能としてあらかじめ、情報ページ、アクセス制御、アクティビティ・レポート、構成オプション、フィードバック、テーマスタイルの選択、を選んで組み込むことができます。これらの機能はそれぞれビルド・オプションに紐づいています。これらの機能をすべて組み込んだ空のアプリケーションを作成し、それを使ってビルド・オプションの働きを確認します。
アプリケーション・ビルダーから作成を実行し、アプリケーション作成ウィザードを起動します。
名前をビルド・オプションの確認とし、機能のすべてをチェックをクリックし、すべての機能を選択したのち、アプリケーションの作成を実行します。
アプリケーションが作成されます。ページ番号が10000以上のページはすべて、上記でチェックを入れた機能と関連しているページです。
作成されたアプリケーションを実行します。管理ページを開くと、選択した機能に対応したリージョンの存在を確認できます。左上、左下、右上、右下の順番で、構成オプション、テーマ・スタイルの選択、アクティビティ・レポート、アクセス制御、フィードバックです。
情報ページがここに含まれていませんが、こちらは右上のメニューから呼び出される機能です。
ビルド・オプションを確認します。共有コンポーネントのアプリケーション・ロジックに含まれます。
アプリケーション作成ウィザードで選択した6つの機能が、ビルド・オプションとして定義されています。
ビルド・オプションのステータス
この中から、フィードバックの機能を取り上げて、ビルド・オプションの働きについて確認します。
機能：フィードバックをクリックして定義を開きます。
現在のビルド・オプションのステータスは、含めるになっています。つまり、関連コンポーネントとしてリストされている、それぞれのコンポーネントが有効になっています。ステータスを除外に変更すると、関連コンポーネントは実際には削除されませんが、存在していないのと同様の扱いになります。また、ここでコンポーネントの削除を行うとデータとしても削除されます。
先ほどの管理ページを開きます。ここで、フィードバックに関係するメニューやリージョンを赤枠で囲っています。
機能：フィードバックのステータスを除外に変更すると、表示が以下に変わり、メニューやリージョンが無くなります。
リージョンでのビルド・オプションの指定は、プロパティ・エディタの構成に含まれています。
ビルド・オプションとして機能：フィードバックが指定されているので、このビルド・オプションのステータスが含めるとなっているときに、有効になります。反対の効果となる選択肢として、{非機能：フィードバック}を選ぶことができます。この指定の場合は、ステータスが除外のときに有効になります。
ただし、この非機能の指定は、どうしても必要な場合に限定した方がよいでしょう。非機能の指定は以下になります。
ビルド・オプション機能：フィードバックのステータスが除外のときに、ページ番号10000を開くと以下のようになります。
メニュー上のフィードバックを呼び出す項目は消去されたままで、ビルド・オプションとして{非機能：フィードバック}を設定したリージョンは表示されます。これは設定した通りの効果です。共有コンポーネントのビルド・オプションから、機能：フィードバックの状態を確認します。
ビルド・オプションに{非機能：フィードバック}を設定したコンポーネントが、関連コンポーネントに現れていないことが確認できます。機能：フィードバックを設定していたときの関連コンポーネントのリストは以下でした。ページ番号10000のページ・リージョン、フィードバックが無くなっていることがわかります。
非機能として設定されているビルド・オプションがあると、コンポーネントの削除に失敗します。
 |
このように、ビルド・オプションのステータスを含めるまたは除外とすることにより、そのビルド・オプションに紐づいた機能を有効にしたり、無効にしたりできます。
エクスポートのデフォルト
テスト環境ではビルド・オプションのステータスを含めるに設定し、本番環境では一旦除外したい状況を考えます。
ここでは仮に機能: フィードバックを開発中とします。
この開発中アプリケーションをエクスポートし、本番環境にインポートすると、エクスポートのデフォルトが引き継がれ、本番環境でのステータスは含めるになります。
本番環境にインポートしたときに、機能: フィードバックがデフォルトで除外となってほしい場合を考えます。ステータスを一旦除外にし、エクスポートしてから、再度含めるに戻す、というのも手間がかかります。
ビルド・オプションの属性のエクスポートのデフォルトを除外に設定すると、この後にエクスポートされたアプリケーションをインポートすると、エクスポート時点のビルド・オプションのステータスにかかわらず、除外がデフォルトになります。
エスクポート前のアプリケーションでのビルド・オプションの設定は以下のように、エクスポートのデフォルトが除外です。
エスクポートしたアプリケーションを以下の画面で、次のアプリケーションとしてインストールとして新規アプリケーションIDを自動割当てを選んでインポートします。
新規に作成されたアプリケーションのビルド・オプションは、エクスポートのデフォルトとして設定されていたステータスが反映されます。
アップグレード時にステータスを維持
インポート時に既存のアプリケーションを置き換えることが可能な場合は、アップグレード時にステータスを維持をはいに設定することで、置き換えられるアプリケーションの設定を維持することができます。
エクスポート時のビルド・オプションのエクスポートのデフォルトが含める、アップグレード時にステータスを維持がはい、だったとします。
インポート時にビルド・オプションを設定する
アプリケーションのインポート時にビルド・オプションを設定することも可能です。アプリケーションのサポートするオブジェクトを開きます。
インストールに含まれるビルド・オプションを開きます。
ビルド・オプションのプロンプトにチェックを入れると、インポート時にユーザーによるビルド・オプションの変更が可能になります。機能: フィードバックにチェックを入れた上で、アプリケーションをエクスポートし、インポートしてみます。
アプリケーションのインポートを実行します。ビルド・オプションの設定を可能にするには、サポートするオブジェクトのインストールをONに指定する必要があります。
使用可能なビルド・オプションとして、ビルド・オプションのプロンプトでチェックを入れたビルド・オプションが現れます。含めるにするか除外にするか、チェックを入れることで指定できます。
インポートされたアプリケーションのビルド・オプションのステータスは、ここで設定されたステータスになります。
APEX_UTIL.SET_BUILD_OPTION_STATUSの使用
コードからビルド・オプションを指定するAPIが提供されています。APEX_UTIL.SET_BUILD_OPTION_STATUSです。以下のように呼び出します。
begin
apex_util.set_build_option_status(
p_application_id => 97521,
p_id => 26026092390449248099,
p_build_status => 'EXCLUDE'
);
end;
p_idはビルド・オプションのIDになります。APEX_APPLICATION_BUILD_OPTION_STATUSビューから確認することができます。以下のようなSQLにてビルド・オプション・IDを取得します。
select build_option_id
from apex_application_build_options
where workspace = 'DBCLOUD_DEMO'
and application_id = 97521
and feature_identifier = 'APPLICATION_FEEDBACK';
ビルド・オプションのステータスについては、APEX_UTIL.GET_BUILD_OPTION_STATUSを呼び出すことによっても取得できます。以下のようなスクリプトになります。
select
APEX_UTIL.GET_BUILD_OPTION_STATUS(
p_application_id => 97521,
p_id => 26026092390449248099
)
from dual;
インストール済みのアプリケーションに含まれるビルド・オプションであれば、APIを呼び出した時点で変更されます。
アプリケーションのインストール・スクリプト内でビルド・オプションを設定する場合は、インポート時に既存のアプリケーションを置き換えること、および、サポートするオブジェクトをインストールするをONとすることが前提です。また、アップグレード時にステータスを維持をはいに設定します。
APIによるビルド・オプションの設定は、ビルド・オプション自体が定義済みであることを前提としているため、インポート時に新規にアプリケーションIDが割り振られる場合は利用できません。また、アップグレード時にステータスを維持がいいえの場合は、APIによる変更がエクスポートのデフォルトとして設定されているステータスで上書きされてしまいます。
終わりに
以上がビルド・オプションにまつわる設定の紹介になります。コンポーネントの有効化/無効化は、サーバー側の条件や認可スキームを使うことが多いですが、ビルド・オプションを使うとひとつの設定でアプリケーション全体を変更できるため、便利に使うことができます。
完
