18.6.1 リモート・サーバーの理解

RESTデータ・ソース・サーバー情報を格納するリモート・サーバー・オブジェクトを作成します。

18.6.1.1 リモート・サーバーについて

RESTデータ・ソース・サーバー情報を格納するリモート・サーバー・オブジェクトを作成します。

Oracle APEXでは、RESTデータ・ソース・サーバー情報(REST APIなど)をリモート・サーバー・オブジェクトとして格納します。リモート・サーバーは複数のRESTデータ・ソース間で共有できます。リモート・サーバー・プロパティを変更すると、そのオブジェクトを参照するすべてのRESTソースに影響します。たとえば、リモート・サーバーのベースURLを変更して、関連付けられているすべてのRESTソースをテストから本番システムに移動できます。リモート・サーバーはワークスペースレベルで格納されるため、リモート・サーバーはワークスペース内のすべてのアプリケーションに表示されます。

リモート・サーバーを作成するときは、次のいずれかのサーバー・タイプを選択します:

  • RESTデータ・ソース - リモートREST APIを使用するためのリモート・サーバー。

  • 認証 - 認証に使用するリモート・サーバー。

  • プリント・サーバー - 外部プリント・サーバー用のリモート・サーバー。ワークスペースにプリント・サーバーを作成し、それをアプリケーションで使用できます。デフォルトでは、インスタンス・レベルのプリント・サーバー構成が使用されます。

  • ファイル・サーバー - リモート・ファイル・ストレージ用のリモートサーバー。

18.6.1.2 APEXによるRESTデータ・ソース情報の格納方法

Oracle APEXでRESTデータ・ソース情報を格納する方法について説明します。

Oracle APEXでは、RESTデータ・ソースのエンドポイントURLが2つの部分に分割されます。最初の部分はサーバー固有の部分で、リモート・サーバーと呼ばれる別個のエンティティとして格納されます。それぞれが使用するサーバー、ポートおよびURLパス接頭辞(コンテキスト・ルート)が同じである場合は、複数のRESTデータ・ソースを持つ1つのリモート・サーバーを再利用できます。リモート・サーバーはワークスペースレベルで格納され、すべてのアプリケーションに表示されます。

エンドポイントURLの2番目の部分は、RESTデータ・ソースに固有です。複数のRESTデータ・ソースが1つのリモート・サーバーを共有できることから、ベースURL、認証などの情報を共有します。リモート・サーバーの属性を変更すると、その変更はリモート・サーバーを使用しているすべてのRESTデータ・ソースに影響を与えます。リモート・サーバーにより、RESTデータ・ソースのコレクションを移動することが容易になります。たとえば、リモート・サーバー・オブジェクト内のURLを変更することで、テスト・システムから本番システムに移行できます。

18.6.1.3 フレキシブル・リモート・サーバーについて

フレキシブル・リモート・サーバーにより、「構成プロシージャ」属性で指定したコールバック・プロシージャを使用して動的にエンドポイントURLのサーバー部分を移入できるようになります。

フレキシブル・リモート・サーバーは次のように動作します:

  • RESTデータ・ソースが呼び出されると、APEXエンジンにより、リモート・サーバーの「構成プロシージャ」属性が評価されます。
  • 「構成プロシージャ」属性に値(データベース内またはPL/SQLコード属性で無名ブロック内に格納されている)がある場合は、APEXエンジンによってそのプロシージャが実行されて、置換パラメータのコレクション(後でエンドポイントURLの変更のために使用される)がフェッチされます。

フレキシブル・リモート・サーバーのユースケース

フレキシブル・リモート・サーバーを使用する一般的なユースケースを次に示します:

  • 環境依存性 - 環境がサーバーまたはアプリケーションのデプロイ場所(本番、テストまたは開発インスタンスなど)に左右される場合は、フレキシブル・リモート・サーバーを選択することをお薦めします。環境ごとに「リモート・サーバーの編集」ページで「エンドポイントURL」属性を手動で変更するかわりに、APIを使用してそれを動的に変更できます。

    ヒント:

    APPLICATION_ADMIN.SET_REMOTE_SERVERプロシージャを使用して、デプロイメント・スクリプトでエンドポイントURLを変更することもできます。『Oracle APEX APIリファレンス』SET_REMOTE_SERVERプロシージャを参照してください
  • アプリケーション・データまたはアプリケーション・ユーザーの依存性 - フレキシブル・リモート・サーバーにより、「構成プロシージャ」属性を使用して動的パラメータに応じて実行時にエンドポイントURLを変更できるようになります。これらの動的パラメータは柔軟であり、構成表、「セッション・ステート」内のアイテム、アプリケーション・アイテムまたは置換アイテムに基づいたものにできます。

    構成プロシージャの結果はキャッシュされ、同じリクエスト(ページ・ビューまたはページ処理)内で再使用されます。

ノート:

フレキシブル・リモート・サーバーは、RESTデータ・ソースおよび認証サーバー・タイプ、またはREST対応SQLで使用されるリモート・サーバーの場合のみサポートされています。

フレキシブル・リモート・サーバーの構成

フレキシブル・リモート・サーバーを構成するには、リモート・サーバーを編集し、「構成プロシージャ」属性にプロシージャ名を入力します。このプロシージャとしては、データベースに格納されているプロシージャの名前、データベース・パッケージ・プロシージャに格納されているプロシージャの名前、またはPL/SQLコード属性に格納されているプロシージャの名前を指定できます。

このプロシージャのシグネチャには、次の2つのタイプのパラメータが必要です:

  • p_info in apex_plugin.t_remote_server_info
  • p_config in out apex_plugin.t_remote_server_config

パラメータp_configには、構成プロシージャで変更できる次の2つのオプション属性があります:

  • p_config.base_url - base_urlによってエンドポイントURLを変更します。
  • p_config.substitutions - substitutionsによって、apex_t_varchar2を使用して名前と値のペアを割り当てます。Oracle APEXによって、ベースURLまたはエンドポイントURL内の各#NAME#が置換されます。

これら2つの属性を組み合せて、リモート・サーバーで使用される実際のエンドポイントURLを決定します。

ヒント:

構成プロシージャの例を表示するには、「構成プロシージャ」属性のアイテム・ヘルプを参照してください。

次の例では、アプリケーションIDが100の場合にベースURLを変更します:

procedure my_server_config(
  p_info    in  apex_plugin.t_remote_server_info,
  p_config  out apex_plugin.t_remote_server_config )
is
begin
  if v('APP_ID') = 100 then
    p_config.base_url := 'http://example100.com';
  else
    p_config.base_url := 'http://example.com';
  end if;
end;

プレースホルダを使用することもできます。このためには、"name"を数字記号(#)で囲み、substitutionsを使用してそれらのプレースホルダ内の値を置き換えます。次の例を検討してください:

procedure my_server_config(
  p_info in apex_plugin.t_remote_server_info,
  p_config out apex_plugin.t_remote_server_config )
is
begin
  p_config.base_url := 'http://example#app_id#/#tenant#.com';
  p_config.substitutions := apex_t_varchar2();
  apex_string.plist_put( p_config.substitutions, 'app_id', v('APP_ID') );
  apex_string.plist_put( p_config.substitutions, 'tenant', v('TENANT') );
end;

18.6.1.4 リモート・サーバー情報のエクスポートおよびインポート

リモート・サーバー情報のエクスポートおよびインポートについて説明します。

アプリケーションをエクスポートする際に、参照されているリモート・サーバーがエクスポート・ファイルに追加されます。アプリケーションを別のワークスペースにインポートすると、APEXは、ターゲット・ワークスペースにすでに同じ静的IDのリモート・サーバーが含まれているかどうかをチェックします。リモート・サーバーがすでに存在する場合、アプリケーションはこれを使用します。そうでない場合は、インポート・ファイルからのリモート・サーバーが、ターゲット・ワークスペースに作成されます。