1. インストレーションおよび構成ガイド
  2. Oracle REST Data Servicesのその他の構成オプション

5 Oracle REST Data Servicesのその他の構成オプション

この項では、リクエストをルーティングして複数のデータベースに接続するようにOracle REST Data Servicesを構成する方法を説明し、その他の構成情報については、その他のドキュメント・ソースを参照します。

ノート:

構成の変更後、Oracle REST Data Servicesを再起動する必要があります。高可用性を確保するために、複数のORDSインスタンスの前にロード・バランサを使用して、ローリング再起動を実行できるようにすることをお薦めします。

トピック:

5.1 MySQL DatabaseでのREST対応SQLサービスの使用

この項では、Oracle Cloud Infrastructureで実行されているMySQLデータベースでのみサポートされるORDS機能について説明します。

独自のORDSインスタンスを設定して、JDBC上のMySQLデータベースでREST対応SQLサービスを使用できます。接続の詳細は、他のORDS接続プールに指定する方法と同じように指定されます。MySQL JDBC接続の場合、db.connectionTypeは常にcustomurlです。db.customURLプロパティは、データベースの有効なJDBC接続文字列である必要があります。データベースを実行しているホスト・マシンは、ORDSインスタンスが実行されているホスト・マシンからアクセスできる必要があります。使用するMySQLデータベース・アカウントは、ORDSインスタンスが実行されているホスト・マシンからのログインを許可するように構成する必要があります。ORDSは、MySQLデータ・サービスやMySQLサーバーを実行するOracle Computeインスタンスなど、OracleがホストするMySQLデータベース・サーバーへの接続をサポートします。

5.1.1 データベース資格証明のソース設定の理解

受信したリクエストごとに、ORDSはリクエストでSQL文を実行するためのJDBC接続を作成します。JDBC接続を作成するには、プール接続の詳細を使用するか、リクエストで基本的な認可資格証明を使用するようにORDSを構成できます。資格証明は、db.credentialsソース構成プロパティを使用して指定されます。使用可能な値は、POOL (デフォルト値)またはREQUESTです。

ノート:

REST対応SQLサービスにアクセスするには、クライアントがORDS SQL開発者ロールを持っている必要があります
デフォルト値POOLを使用すると、プール構成の資格証明がリクエスト内のSQL文の処理に使用されます。ただし、クライアントはアイデンティティ管理システムの資格証明を指定して、それらを認可し、SQL開発者ロールを割り当てる必要があります。そうして初めて、クライアントはREST対応SQLサービスにアクセスできます。

値がREQUESTに設定されている場合、プール構成で指定されたユーザー名とパスワードは引き続き必要です。ただし、これらの資格証明は、プールが初めて使用されるときに、プール内の接続の詳細を検証するためにのみ使用されます。基本認可ヘッダーのユーザー名とパスワードは、ターゲット・データベースとの新しいJDBC接続を確立するために使用されます。接続が確立されると、クライアントはSQL開発者ロールを持つとみなされます。これにより、REST対応SQLサービスの起動が認可されます。新しいJDBC接続は、リクエスト・ライフサイクル中に使用され、その後閉じられます。

5.1.2 MySQLデータベースのプールの構成

MySQLデータベースでORDSを使用するには、プール構成が必要です。プールは、ORDSコマンドライン・インタフェースを使用して構成できます。

顧客管理環境で実行されているOracle REST Data Services (ORDS)でMySQLデータベースを使用できるようにORDSを構成する必要があります。顧客管理対象環境のためにOracle REST Data Servicesをインストールする場所に応じて、次のいずれかを実行します。

  • Oracle REST Data Servicesの顧客管理対象環境がOracle Cloud Infrastructureで実行されている場合、Oracle YUMリポジトリを使用して、ORDSのYUMインストールを実行します。

  • Oracle REST Data Servicesの顧客管理対象環境が他の環境で実行されている場合、Oracle REST Data Servicesのダウンロード・ページからORDSをダウンロードします。

ORDSをMySQLデータベースで使用するためにデータベースへのインストールは必要ではなく、プールの構成のみが必要です。プールは、ORDSコマンドライン・インタフェースを使用して構成できます。

MySQLデータベースのプールを構成するには、次のステップを実行します。

ノート:

リクエスト内の資格証明は、SQL文の実行に使用されます。MySQLデータベースに指定されたdb.usernameは、接続を作成するためのすべての権限を持つユーザーで、プール構成の詳細全体を検証するために使用されます。 
ords config --db-pool mysql set db.connectionType customurl
ords config --db-pool mysql set db.customURL "jdbc:mysql://10.0.1.23/?sslMode=REQUIRED"
ords config --db-pool mysql set db.username user_only_has_permission_to_connect_and_nothing_more
ords config --db-pool mysql set db.credentialsSource request
ords config --db-pool mysql set restEnabledSql.active true
ords config --db-pool mysql secret db.password
前述の例では、次のとおりです。
  • JDBCドライバに関連するプロパティは、db.customURLプロパティで指定できます。前述の例では、db.customURL値sslModeは、ORDSとMySQLサーバー間のセキュアな接続を確保するために、デフォルト値PREFERREDではなくREQUIREDに設定されています。
  • データベース・プールはmysqlと呼ばれます。ただし、プールには任意の名前を付けることができます。デフォルト・プールは、MySQL接続プールとして構成できます。使用する必要がある数のMySQLデータベースに対して複数のプールを定義できます。
  • 指定されたdb.usernameは、接続を作成するための十分な権限を持つMySQLデータベース・ユーザーです。このデータベースアカウントは、プール構成全体の詳細を確認するために使用されます。
5.1.2.1 サポートされているコンテナのORDSの構成
この項では、MySQLデータベースでサポートされるコンテナで、接続プール構成を使用してORDSを使用する方法について説明します。

構成場所の指定

ords serveコマンドを使用してスタンドアロン・モードでORDSを実行する場合、構成ディレクトリの場所を指定するオプションがあります。ords.warをApache TomcatやWebLogic Serverなどのサポートされているコンテナにデプロイする場合は、config.urlシステム・プロパティを設定して構成ディレクトリの場所を指定する必要があります。これを実行するメカニズムは、コンテナ製品によって異なります。

  • Apache Tomcatを起動する前にconfig.urlシステム・プロパティを設定するには、次のコマンドを実行します。 
    export JAVA_OPTS="-Dconfig.url=/scratch/my_ords_config"
  • WebLogic Serverを起動する前にconfig.urlシステム・プロパティを設定するには、次のコマンドを実行します。 
    export JAVA_OPTIONS="-Dconfig.url=/scratch/my_ords_config"

  • または、ords warコマンドを使用して、config.urlコンテキスト・パラメータが明示的に設定され、lib/extフォルダからのjarファイルが含まれるデプロイ可能なWebアプリケーション・アーカイブ・ファイルを作成します。

ORDS用MySQL JDBC Jar

ORDSはMySQL JDBC jarを配布していません。ORDSでMySQLデータベースへのJDBC接続を作成するには、関連するJDBC jarがランタイム・クラスパスに含まれている必要があります。OCI YUM mysql-connector-javaを使用するか、https://www.mysql.com/からMySQL Connector/Jをダウンロードし、スタンドアロン、Apache TomcatまたはWebLogicサーバーのいずれかのサーバー・モードの関連する場所にjarファイルをコピーします。

ノート:

MySQL Connector/Jの最小限必要なバージョンは8.0.27です。

ORDSのOCI YUM RPMディストリビューションにより、OCI YUM mysql-connector-java JDBC jarへのシンボリック・リンクが作成されます。

OCI YUM RPM


-- Install MySQL Connector/J community edition
sudo yum install mysql-connector-java
 
-- Confirm JDBC jar is installed
ls -l /usr/share/java/mysql-connector-java.jar
 
-- Install ORDS from OCI YUM repository
sudo yum install ords
 
-- Note that ORDS RPM install will create a symbolic link to ORDS installation lib/ext/ directory
ls -l /opt/oracle/ords/lib/ext/
5.1.2.1.1 スタンドアロン・モードでのORDSの実行

スタンドアロン・モードでORDSを実行するときにランタイム・クラスパスに存在するには、最初にMySQL JDBC jarをExtensionフォルダに追加する必要があります。ExtensionフォルダはORDSディストリビューションのlib/extディレクトリで、前の項で説明したOCI YUM RPMインストール・プロセスを使用して作成されます。

5.1.2.1.2 Apache TomcatにデプロイされたORDS

ノート:

Apache Tomcatを使用する場合、java.sql.SQLException: No suitable driverエラーを回避するために、プールにJDBCドライバのクラス名を明示的に設定する必要があります。

プールにJDBCドライバ・クラス名を設定するには、次のコマンドを実行します。

ords config --db-pool mysql set jdbc.driverName com.mysql.cj.jdbc.Driver

ORDSがApache Tomcatにデプロイされたときにランタイム・クラスパスに存在するためには、MySQL JDBC jarをサーバー・クラスパスまたはデプロイされたWebアプリケーションに追加する必要があります。jarをサーバー・クラスパスに追加するには、いくつかの方法がありますが、最も一般的な方法は、jarファイルを$CATALINA_HOME/libディレクトリに追加する方法です。

最適なデプロイメント環境を決定するためのオプションおよびガイドラインについては、Apache Tomcatのドキュメントを参照してください。

デプロイされたWebアプリケーションにJDBC jarを含めるには、それがlib/ext/フォルダにあり、ords warコマンドを使用してデプロイ可能なWebアプリケーション・アーカイブ・ファイルを作成していることを確認します。このアーカイブ・ファイルにはconfig.url コンテキスト・パラメータが明示的に設定され、lib/extフォルダにあるすべてのjarファイルが含まれています。

関連項目:

Apache Tomcat 8
5.1.2.1.3 Weblogic ServerにデプロイされたORDS

ORDSがWebLogic Serverにデプロイされたときにランタイム・クラスパスに存在するためには、MySQL JDBC jarをサーバー・クラスパスまたはデプロイされたWebアプリケーションに追加する必要があります。jarファイルをサーバー・クラスパスに追加する1つの方法は、commEnv.cmd/shスクリプトのWEBLOGIC_CLASSPATH環境変数にjarの場所を指定する方法です。

最適なデプロイメント環境を決定するためのオプションおよびガイドラインについては、WebLogic Serverのドキュメントを参照してください。

デプロイされたWebアプリケーションにJDBC jarを含めるには、それがlib/ext/フォルダにあり、ords warコマンドを使用してデプロイ可能なWebアプリケーション・アーカイブ・ファイルを作成していることを確認します。このアーカイブ・ファイルにはconfig.url コンテキスト・パラメータが明示的に設定され、lib/extにあるすべてのjarファイルが含まれています。

関連項目:

WebLogic Serverデプロイメントの理解

5.2 ORDSスタンドアロン・モードでのJettyの構成

この項では、ORDSスタンドアロン・モードで使用されるEclipse Jettyサーバーを構成する方法について説明します。

スタンドアロン・モードでは、ORDSは埋込みEclipse Jettyサーバーを使用します。Jettyのデフォルト構成は、最も一般的なORDSユースケース用に最適化されています。このJettyサーバー構成は、Javaシステム・プロパティおよびJetty XML構成(${configuration.directory}/global/standalone/etc)で定義されている特定のORDS設定を使用して変更できます。

ノート:

ORDSがApache TomcatやOracle WebLogic Serverなどのコンテナにデプロイされている場合、これらの設定は無効です。

関連項目:

5.2.1 Javaシステム・プロパティの使用

この項では、Javaシステム・プロパティを指定して、ORDSで使用されるJetty構成の設定を変更する方法について説明します。

システム・プロパティを指定するには、コマンドラインで--java-optionを使用し、パラメータとしてJavaシステム・プロパティ定義を指定する必要があります。

例:

例5-1 --java-optionコマンドライン・オプションの使用 

ords --java-option '-Dthreads.max=300 -Djetty.request.header.size=8192' --config /path/to/config/ serve

関連項目:

JDK Javaのオプション

5.2.2 Javaシステム・プロパティ

この項では、Javaシステム・プロパティを示します。

表5-1 Javaシステム・プロパティ

Javaシステム・プロパティ名 説明 デフォルト値
threads.min Jettyサーバー(id="Server")のスレッド・プール内のスレッドの最小数を指定します。 10
threads.max Jettyサーバー(id="Server")のスレッド・プール内のスレッドの最大数を指定します。 200
threads.timeout

Jettyサーバー(id="Server")のスレッド・プールの最大スレッド・アイドル時間(ミリ秒)を指定します。

この期間より長くアイドル状態になっているスレッドは停止できます。

 60000
jetty.send.xpoweredBy Jetty HttpConfiguration (id="httpConfig")のSendXPoweredBy設定を指定します false
jetty.output.buffer.size Jetty HttpConfiguration (id="httpConfig")のOutputBufferSize設定を指定します 32768
jetty.request.header.size Jetty HttpConfiguration (id="httpConfig")のRequestHeaderSize設定を指定します 65536
jetty.response.header.size Jetty HttpConfiguration (id="httpConfig")のResponseHeaderSize設定を設定します 8192
jetty.send.server.version Jetty HttpConfiguration (id="httpConfig")のSendServerVersion設定を指定します false
jetty.send.date.header Jetty HttpConfiguration (id="httpConfig")のSendDateHeader設定を指定します false
jetty.dump.start Jettyサーバー(id="Server")のDumpAfterStart設定を指定します false
jetty.dump.stop Jettyサーバー(id="Server")のDumpAfterStop設定を指定します false

5.2.3 Jetty XML構成ファイルの使用

この項では、Jetty XML構成ファイルを使用した、追加機能のためのJettyサーバーの構成方法について説明します。

ORDSがスタンドアロン・モードで実行されている場合、Eclipse Jettyホームは ${configuration.directory}/global/standalone/です。Jettyホームのetcディレクトリに構成XMLファイルを配置すると、Jetty XML構文を使用して追加機能用にJettyサーバーを構成できます。これを実行する機能は、Eclipse Jettyサーバー製品を介して提供されます。

関連項目:

Eclipse Jettyのドキュメント

例

この項では、追加機能用にEclipse Jettyサーバーの動作を拡張する例を示します。次の例は、ORDSの動作ではなくEclipse Jettyサーバーの動作を変更する方法を示しています。スタンドアロン・モードでの起動時にORDSで使用されるJetty XMLファイルの場所は次のとおりです:
${configuration.directory}/global/standalone/etc/

例5-2 特定のアクセス・ログ形式の使用

構成設定standalone.access.logが指定されている場合、ORDSはアクセス・ログを生成できます。 

/global/standalone/etc/jetty-access-log.xml
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
    <Ref id="Handlers">
      <Call name="addHandler">
        <Arg>
          <New id="RequestLog" class="org.eclipse.jetty.server.handler.RequestLogHandler">
            <Set name="requestLog">
              <New id="RequestLogImpl" class="org.eclipse.jetty.server.CustomRequestLog">
                <Arg>/ords/ords-access.log</Arg>
                <Arg>%{remote}a - %u %t "%r" %s %O "%{Referer}i" "%{User-Agent}i"</Arg>
              </New>
            </Set>
          </New>
        </Arg>
      </Call>
    </Ref>
</Configure>

例5-3 常にレスポンスで特定のヘッダーを返す

これは、ORDSの前にロード・バランサまたはリバース・プロキシを使用して実現することもできます。ORDSサーバーからのすべてのレスポンスで特定のヘッダーが返されるようにする場合、次のサンプル・コード・スニペットを使用します:

/global/standalone/etc/jetty-response.xml
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
  <Call name="insertHandler">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewriteHandler">
      <Get id="Rewrite" name="ruleContainer" />
      <Call name="addRule">
        <Arg>
          <New id="header"  class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
            <Set name="pattern">*</Set>
            <Set name="name">Strict-Transport-Security</Set>
            <Set name="value">max-age=31536000;includeSubDomains</Set>
          </New>
        </Arg>
      </Call>
    </New>
  </Arg>
</Call>
</Configure>

5.3 Oracle RAC Fast Connection Failoverのサポート

Oracle REST Data Servicesは、Oracle Real Application Clusters (Oracle RAC)のFast Connection Failover (FCF)機能をサポートします。

Oracle REST Data Servicesは、WebLogic、Tomcatなど、サポートするすべてのApplication Server環境でUniversal Connection Pool (UCP)とともに実行されます。また、UCPはFast Connection Failoverをサポートします。FCFを有効化するには、Oracle Notification Service (ONS)が有効化されている必要があります。ONSを有効化するには、次のコード・スニペットに示すように、Oracle REST Data Services settings.xml構成ファイルにあるプロパティのリストにエントリを追加します。 

<entry key="jdbc.enableONS">true</entry>
<entry key= "jdbc.ONSConfig">nodes=racnode1:4200,racnode2:4200\nwalletfile=/oracle11/onswalletfile</entry>
ONSは、Fast Application Notification (FAN)イベントを送信するために使用されるメッセージング機能です。ONSが有効化されている場合、Oracle REST Data Servicesでは、FCFが自動的に有効になります。フェイル・オーバーや、ロード・バランシングなどのその他の高度なFCF機能など、特定のFCF機能を有効化するには、次のコード・スニペットに示すようにカスタム接続に対応するエントリを構成ファイルに追加する必要があります。
<entry key="db.connectionType">customurl</entry>
<entry key="db.customURL">jdbc:oracle:thin:@(DESCRIPTION=(FAILOVER=ON)(ADDRESS_LIST=
		(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=prod_scan.example.com)(PORT=1521)))
		(CONNECT_DATA=(SERVICE_NAME=ISPRD)))</entry>

defaults.xml構成ファイルを更新した後、Oracle REST Data Servicesを再起動するまで変更は有効になりません。

UCPはFast Connection Failoverをサポートします。FCFは、FANイベントをリッスンし、それに応答することで次の2つのシナリオに対応します。

  • 計画外の停止: RACはインスタンス障害を検出するとFAN Downイベントを生成し、それをFCFが捕捉します。 FCFは失敗したインスタンスへのすべての接続を終了し、それ以降のすべてのリクエストを、残っているRACインスタンスに送ります。

  • 計画的な停止: たとえば、データベース管理者(DBA)が、一部のメンテナンス・アクティビティを実行するためにRACインスタンスを正常にシャットダウンすることがあります。インスタンス・シャットダウンはFAN Planned Downイベントを生成し、それをFCFが捕捉します。 続いてFCFはすべての新しいリクエストを他のRACインスタンスに送り、現在アクティブなトランザクションを排出するか完了させます。

ノート:

長い間実行されているトランザクションは、強制終了が必要な場合があります。

5.4 Kerberos設定を使用したORDSの構成

この項では、ORDSをKerberosファイルベースのチケット・キャッシュを参照し、ORDS実行権限を持つOracle Database Kerberos認証済ユーザーに接続するように構成する方法について説明します。

Kerberos設定でORDSを構成するには、次のステップを実行します。
  1. 外部認証を使用した新規ユーザーの作成
  2. 環境変数の設定
  3. 有効なチケットの指定
  4. ORDSプール設定の追加
  1. 外部認証を使用した新規ユーザーの作成
    外部認証(Kerberos)を使用して新しいOracle Databaseユーザーを作成し、そのユーザーをORDSランタイム・ユーザーとしてプロビジョニングします。
    CREATE USER ORDS_PUBLIC_KRBUSER IDENTIFIED EXTERNALLY AS '<kerberos_principal_name>';
GRANT CONNECT TO "ORDS_PUBLIC_KRBUSER";
BEGIN
     ORDS_ADMIN.PROVISION_RUNTIME_ROLE(
         p_user => 'ORDS_PUBLIC_KRBUSER',
         p_proxy_enabled_schemas => TRUE);
END;
/
  2. 環境変数の設定

    ノート:

    Kerberos構成ファイルkrb5.confとファイルベースのチケット・キャッシュがあることを確認してください
    次の環境変数を設定します。
    export KRB5_CONFIG=<path to krb5.conf>
export KRB5CCNAME=<path to credential cache>
  3. 有効なチケットの指定
    Oracle Databaseへの接続時に認証されるように、チケット・キャッシュに有効なチケットを指定します。

    kinit <principal>

  4. ORDSプール設定の追加
    チケット・キャッシュ内のチケットを使用して、次のプール設定をpool.xmlファイルに追加します。
    <entry key="oracle.net.authentication_services">(KERBEROS5)</entry>
<entry key="oracle.net.kerberos5_mutual_authentication">true</entry>
    たとえば、Kerberosでスタンドアロン・モードでORDSを実行するには、次のコマンドを実行します。
    
ords --java-options “-Djava.security.krb5.conf=$KRB5_CONFIG” serve

5.5 Oracle Data Guardで保護されているユーザーにアクセスするためのOracle REST Data Servicesの認可

Oracle Data Vault Realmで保護されているデータベース・スキーマ・オブジェクトにアクセスするには、Oracle REST Data Services Publicユーザーにプロキシ・ユーザー認可を付与する必要があります。

次の例では、Oracle REST Data Servicesのパブリック・ユーザーORDS_PUBLIC_USERがデータベースのHRユーザーのプロキシとして動作することを認可します。
begin
  DBMS_MACADM.AUTHORIZE_PROXY_USER('ORDS_PUBLIC_USER','HR');
end;
/

5.6 REST対応SQLサービス設定の構成

この項では、REST対応SQLサービスを構成する方法について説明します。

ノート:

REST対応SQLサービスを有効にすると、Oracle RESTデータ・サービス対応のデータベース・スキーマに対する認証が有効になります。これにより、データベース・パスワードを使用して、データベース・スキーマがHTTPS経由でアクセス可能になります。Oracleでは、強力かつ安全なデータベース・パスワードを指定することをお薦めします
REST対応SQLサービスは、Oracle RESTデータ・サービスの機能の1つです。デフォルトでは、REST対応SQLサービスがオフになっています。REST対応SQLサービスおよびREST対応SQLエクスポート・サービスを有効にするには、次のステップを実行します。
  1. 次のコマンドを実行します。

    ords --config <configuration_folder> config [--db-pool <pool_name>] set restEnabledSql.active true

  2. Oracle REST Data Servicesを再起動します。

5.7 問合せから戻される行の最大数の構成

問合せから戻される行の最大数を構成するには、次のステップを実行します。
  1. 次のコマンドを実行します。

    ords --config <configuration_folder> config set [--db-pool <pool_name>] misc.pagination.maxRows <number>

    ノート:

    misc.pagination.maxRowsのデフォルト値は10000です。
  2. Oracle REST Data Servicesを再起動します。

5.8 ウィルス・スキャン用のICAPサーバー統合の構成

この項では、ウイルス・スキャン用にICAPサーバーと統合するようにORDSを構成する方法について説明します。

ORDS PL/SQLゲートウェイでは、ファイル・アップロード時に、Internet Content Adaptation Protocol (ICAP)準拠のウイルス・スキャン・サーバーにウイルス・スキャンの職責を任せることができます。ウィルス・スキャン・サーバーのホスト名とポートは、icap.server、icap.portおよびicap.secure.portグローバル構成プロパティで指定します。

APEXではORDS PL/SQLゲートウェイが使用されます。このICAP統合は、構成すると、APEXでのファイル・アップロードにも適用されます。

ICAPサーバーと統合するようにORDSを構成するには、次のステップを実行します。
  1. 次のコマンドを実行します。

    ords --config <configuration_folder> config [--db-pool <pool_name>] set icap.port <number> ords --config <configuration_folder> config [--db-pool <pool_name>] set icap.server <name_or_ip>

  2. Oracle REST Data Servicesを再起動します。
ICAPサーバーが次の要件に対応している必要があります。
  • ICAPバージョン1.0
  • AVSCANという名前のウイルス対策サービス
  • action=SCANに対応しているウイルス対策サービス
  • 4バイト以上のプレビュー
  • X-Infectionという名前のヘッダーを返す
構成後、PL/SQL Gatewayを介してファイルがアップロードされると、ORDSによって次のようなリクエストが作成されます。
RESPMOD icap://<icap_server>:<icap_port>/AVSCAN?action=SCAN ICAP/1.0
Host: <icap_server>:<icap_port>
Preview: 4
Allow: 204
Encapsulated: req-hdr=0 res-hdr=153 res-body=200

5.9 カスタム・エラー・ページの構成

この項では、Oracle REST Data Servicesにより生成されたエラー・ページではなく、カスタム・エラー・ページを構成する方法について説明します。

カスタム・エラー・ページを構成するには、次のようにします。

  1. 次のコマンドを実行します。

    ords --config /path/to/conf config set error.externalPath /path/to/error/pages/folder/

    説明:

    /path/to/error/pages/folderは、エラー・ページを定義するファイルが格納されているフォルダのパスです。ファイルは、{status}.html形式で格納されます。ここで、{status}は、カスタム・エラー・ページを作成するHTTPステータス・コードです。

  2. Oracle REST Data Servicesを再起動します

例5-4 HTTP 404ステータス・コードのカスタム・エラー・ページの構成

「HTTP 404 – Not Found」ステータスのカスタム・エラー・ページを構成するには、次のステップを実行します。

  1. 404.htmlという名前のファイルを作成します。

  2. /usr/local/share/ords/error-pages/フォルダに保存します。

  3. /usr/local/share/ords/errro-pages/フォルダを指すように、error.externalPathパラメータを構成します。

  4. Oracle REST Data Servicesを再起動します。

5.10 ORDS管理者権限の管理

ORDS_ADMIN PL/SQLパッケージへのアクセス権は、ORDS_ADMINISTRATOR_ROLEを介してプロビジョニングします。ORDS_ADMINパッケージを介してこのロールをプロビジョニングして、追加のORDS管理者を作成できます。

5.10.1 ユーザーへのORDS_ADMINISTRATOR_ROLEのプロビジョニング

この項では、ORDS_ADMINISTRATOR_ROLEロールをユーザーにプロビジョニングする方法について説明します。

データベースのGRANTコマンドまたはORDS_ADMIN.PROVISION_ADMIN_ROLE PL/SQLメソッド(ORDS管理者)を使用して、ORDS_ADMINISTRATOR_ROLEロールをユーザーにプロビジョニングできます。

例5-5 Grantコマンドの使用

GRANT ORDS_ADMINISTRATOR_ROLE TO HR_ADMIN;

例5-6 ORDS_ADMINパッケージ・メソッドの使用

BEGIN
  ORDS_ADMIN.PROVISION_ADMIN_ROLE(
    p_user => 'HR_ADMIN');
END;
/

5.10.2 ユーザーからのORDS_ADMINISTRATOR_ROLEのプロビジョニング解除

この項では、ORDS_ADMINISTRATOR_ROLEをユーザーからプロビジョニング解除する方法について説明します。

ORDS管理者は、データベースのREVOKEコマンドまたはORDS_ADMIN.UNPROVISION_ROLES PL/SQLメソッドを使用して、ORDS_ADMINISTRATOR_ROLEをユーザーからプロビジョニング解除できます。

例5-7 REVOKEコマンドの使用

REVOKE ORDS_ADMINSTRATOR_ROLE FROM HR_ADMIN;

例5-8 ORDS_ADMINパッケージ・メソッドの使用

BEGIN
  ORDS_ADMIN.UNPROVISION_ROLES(
    p_user => 'HR_ADMIN',
    p_administrator_role => TRUE);
 END;
 /

5.11 ORDS実行権限の管理

ORDS_RUNTIME_ROLEデータベース・ロールを使用すると、ユーザーはランタイム・ユーザーとして機能できます。ランタイム・ユーザーはORDSサービス・インスタンスで必要なランタイム接続リソースを管理および構成できます。ORDS_PUBLIC_USERは、そのようなデータベース・ユーザーの1つです。追加のランタイム・ユーザーがプロビジョニングされると、異なる宛先アドレスと接続プールを持つが同じOracleデータベース・コンテナでホストされる、個別のORDSサービス・インスタンスを構成できます。

ランタイム・ユーザーには他のユーザーへのプロキシに必要な権限が累積されるため、他の目的で再利用しないことをお薦めします。ランタイム・ユーザーには、ORDS_RUNTIME_ROLEロールに加えてCREATE SESSION権限のみが必要です。

5.11.1 ユーザーへのORDS_RUNTIME_ROLEのプロビジョニング

この項では、ORDS_RUNTIME_ROLEロールをユーザーにプロビジョニングする方法について説明します。

ORDS管理者は、データベースのGRANTコマンドまたはORDS_ADMIN.PROVISION_ADMIN_ROLE PL/SQLメソッドを使用して、ORDS_RUNTIME_ROLEロールをユーザーにプロビジョニングできます。

例5-9 Grantコマンドの使用

GRANT ORDS_RUNTIME_ROLE TO ORDS_PUBLIC_USER_2;

例5-10 ORDS_ADMINパッケージ・メソッドの使用

BEGIN
  ORDS_ADMIN.PROVISION_RUNTIME_ROLE(
    p_user => 'ORDS_PUBLIC_USER_2');
END;
/

5.11.2 ユーザーからのORDS_RUNTIME_ROLEのプロビジョニング解除

この項では、ORDS_RUNTIME_ROLEロールをユーザーからプロビジョニングを解除する方法について説明します

管理者は、データベースのREVOKEコマンドまたはORDS_ADMIN.UNPROVISION_ROLES PL/SQLメソッドを使用して、ORDS_RUNTIME_ROLEをユーザーからプロビジョニング解除できます。

例5-11 REVOKEコマンドの使用

REVOKE ORDS_RUNTIME_ROLE FROM ORDS_RUNTIME_USER_2;

例5-12 ORDS_ADMINパッケージ・メソッドの使用

BEGIN
  ORDS_ADMIN.UNPROVISION_ROLES(
    p_user => 'ORDS_RUNTIME_USER_2',
    p_runtime_role => TRUE);
 END;
 /

5.12 非HTTPS環境でOAuth2の使用

RESTfulサービスは、非公開データへのアクセスを制御するOAuth2プロトコルで保護できます。データのスヌーピングを防ぐため、OAuth2では、OAuth2認証プロセスに関与するすべてのリクエストをHTTPSを使用して転送する必要があります。Oracle REST Data Servicesのデフォルトの動作では、OAuth2関連のすべてのリクエストはHTTPSを使用して受信されたことを検証されます。HTTPを介して受信するリクエストへのサービスは拒否され、403 ForbiddenのHTTPステータス・コードが返されます。

このデフォルトの動作は、HTTPSを使用できない環境では次のようにして無効にできます。

  1. Oracle REST Data Servicesの構成が格納されているフォルダを探します。例: /path/to/conf

  2. 次のコマンドを実行します。

    ords --config /path/to/conf config set security.verifySSL false

  3. 実行中なら、Oracle REST Data Servicesを再起動します。

この設定の使用は、開発またはテスト環境でのみ適切であることに注意してください。ユーザーの資格証明がクリア・テキストで渡されることになるので、本番環境でこの設定を使用するのは適切ではありません。

ノート:

Oracle REST Data Servicesは、構成の変更を行った後に再起動する必要があります。アプリケーションを再起動する方法はアプリケーション・サーバーのマニュアルを参照してください。

5.13 ORDSメタデータ・キャッシュの構成

この項では、ORDSメタデータ・キャッシュの構成方法について説明します。

RESTサービスの数が増加するにつれて、対応するメタデータのデータベースを問い合せるオーバーヘッドが、サービス・パフォーマンスおよびスループット全体に悪影響を与える可能性があります。時間の経過とともに、ORDS_METADATAビューの問合せの完了に時間がかかるようになります。これらの問合せは、リクエストごとに実行されます。ORDSメタデータ・キャッシュは、ORDS_METADATAビューの問合せが各リクエストにとって高負荷になる程度までサービス数が増加したときに、RESTサービスの全体的なレスポンス時間を改善するのに役立ちます。ORDSメタデータ・キャッシュでは、権限およびモジュール・メタデータのコピーをメモリーに一時的に保持して、RESTサービス・リクエストの受信時に実行されるデータベース問合せの数を減らすことができます。メタデータに対する変更が後続のリクエストにすぐに適用されるように、キャッシュはデフォルトで有効になります。

表5-2 ORDSメタデータ・キャッシュの構成プロパティ

プロパティ データ型 デフォルト値 説明
cache.metadata.enabled ブール値 true メタデータ・キャッシュを有効または無効にする設定を指定します。
cache.metadata.timeout 期間 1s メタデータ・レコードがキャッシュに残る期間を決定するための設定を指定します。期間が長いほど、適用された変更の表示に時間がかかります。