HTTP パス¶
HTTP リクエストをサーバーに送信してデータを取得する必要がある場合は、HTTP パスを使用します。このページでは、HTTP パスに関するすべてを説明します。
認証:
[Filters] タブについては、「 圧縮または暗号化されたデータソース 」を参照してください。フィルタはどのタイプのパス (ローカル、HTTP、FTP など) でも同様に機能します。
構成¶
HTTP パスを使用すると、HTTP メソッドの GET、PUT、POST、DELETE、または PATH のいずれかを使用してリクエストを送信できます。
POST 、 PUT 、または PATH のリクエストの本文にパラメータを追加するには、以下の 2 つの方法があります。
URL parameters: URL に存在するクエリパラメータが URL から削除され、HTML フォームの値としてリクエストの本文に置かれて送信されます。HTTP リクエストの Content-type ヘッダーは application/x-www-form-urlencoded になります。
たとえば、実行時の URL が
http://acme/customer?first_name=John&last_name=Smith
である場合、Virtual DataPort サーバーから HTTP リクエストがhttp://acme/customer
(クエリパラメータなし) に送信され、そのリクエストの本文がfirst_name=John&last_name=Smith
になります。あるいは、[Content type] ボックスから内容種別
application/x-www-form-urlencoded
を選択する際に、これらのパラメータを本文に設定することもできます。Post body: このオプションの下にあるテキスト領域の内容が HTTP リクエストの本文に設定されて送信されます。[Content type] ボックスに、本文の内容種別を入力します。
データを取得するために送信される HTTP リクエストにヘッダーを追加するには、[HTTP headers] をクリックします。[HTTP Headers] ダイアログで [New] をクリックして、ヘッダーの名前と値を入力します。
HTTP パスの以下のエレメントには、補間変数を使用できます (補間変数については、「 補間変数によるパスなどの値 」を参照)。
URL: 1 つまたは複数の補間変数を指定できます。たとえば、
https://acme.com/department?id=@{department_id}
とします。HTTP headers: 名前とその値として補間変数を指定できます。
POST body: 1 つまたは複数の補間変数を指定できます。データソースにクエリを実行するときに、POST リクエスト、および実行時に本文に設定する必要がある 1 つまたは複数の値を送信する場合に、このエレメントが便利です。たとえば、POST リクエストの本文が以下のとおりであるとします。
<employee_info> <last_name>@last_name</last_name> <first_name>@first_name</first_name> </employee_info>

XML 本文に補間変数を使用した HTTP POST リクエスト¶
@first_name
と @last_name
が記述されています。文字 @ は、first_name と last_name が補間変数であることを示します。このデータソースにクエリを実行したときに、文字列の @first_name
と @last_name
が値で置き換えられます。このデータソースから基本ビューを作成した場合、そのビューには department_id、last_name、および first_name の 3 つの追加フィールドが存在します。このビューに対するクエリでは、WHERE 句でこれらのフィールドの値を必ず指定する必要があります。
たとえば、クエリが以下のようであるとします。
SELECT *
FROM view
WHERE department_id = 2 AND first_name = 'John' AND last_name = 'Smith'
Virtual DataPort サーバーからは、以下の本文を設定したリクエストが
https://acme.com/department?id=@{department_id}
に送信されます。
<employee_info>
<last_name>Smith</last_name>
<first_name>John<first_name>
</employee_info>
このデータソースから作成された基本ビューを指定しているにもかかわらず、これら 3 つのフィールドの値を指定していないクエリは失敗します。
注釈
補間変数の名前を構成していない文字
@
、{
、および}
はエスケープする必要があります。これらの文字をエスケープするには、文字\
を使用します。文字\
はその文字自体 (\\
) でエスケープします。
<employee_info_request>
<department_name>department \@1 \{ACCT\}</department_name>
</employee_info_request>
[Load file] を使用してリクエストの本文を読み込んだ場合、これらの文字はすべて管理ツールによって自動的にエスケープされます。
補間変数を使用すると、Web サーバーに対する HTTP リクエストが静的でなくなり、クエリごとに変更できるという利点があります。
HTTP パスの定義に補間変数を使用している場合は、[Test connection] をクリックしたときに補間変数の値を指定する必要があります。このデータソースから基本ビューを作成するときも同様の指定が必要です。変数の値を入力するダイアログが、以下のように管理ツールによって表示されます。

HTTP パスにある補間変数の値の指定¶
各変数の値を URL のクエリパラメータの値として使用する場合は、このダイアログで [URI parameter] チェックボックスをチェックします。このようにチェックすると、それに応じて変数の値がエスケープされます。チェックしていない場合、変数が URL の一部であっても、その値は URL の他の部分と同じようにエスケープされます。たとえば、URL が http://acme/recipe?name=@dish
の場合、変数 dish の値を指定するときに [URI parameter] チェックボックスをチェックしたとします。 dish
の値が Mac&Cheese だとすると、Virtual DataPort サーバーからは http://acme/recipe?name=Mac%26cheese
にリクエストが送信されます。& は %26 で置き換えられることによって正しくエンコードされています。 dish
の値を指定するときに [URI parameter] をチェックしていなければ、URL は http://acme/recipe?name=Mac&cheese
となり、この場合は正しく処理されません。この URI には Mac の後に & があるため、Web サーバーでは cheese が別のクエリパラメータとして扱われるからです。
補間変数がパスの URL の一部ではない場合、[URI parameter] チェックボックスのチェックをはずしたままにします。
[Connection timeout] フィールドでは、コネクションが確立されるまでのタイムアウトをミリ秒単位で構成できます。この時間内にコネクションを確立できない場合、データソースによってリクエストがキャンセルされ、クエリは失敗します。
デフォルトでは、[Check certificates] チェックボックスが選択されています。この内容は、以下のようになります。
サービスが SSL/TLS (
https
で始まる URL) を使用していて、そのサービスが提示する証明書が、Denodo Platform に属する Java Virtual Machine (JVM) によって信頼されている証明機関 (CA) から発行されたものであることを Virtual DataPort で検証します。この検証は、サービスとのコネクションを確立するたびに実行されます。このサービスが提示する証明書が信頼できる CA によって発行されたものではない場合、または自己署名された証明書ではあるものの、Virtual DataPort で検証を必要とする場合、JVM の信頼できる証明書のリストにその証明書をインポートします。この方法については、付録「 データソースの証明書のインポート (SSL/TLS 接続) 」を参照してください。
また、サービスが SSL クライアント認証を必要とする場合も、このチェックボックスは選択したままにします。
このチェックボックスのチェックをはずすと、以下の 2 つの影響があります。
Virtual DataPort では、サービスから提示された証明書を、その発行元を確認せずに受け入れます。
サービスが SSL クライアント認証を要求する場合、すべてのリクエストは失敗します。
[Generate output on empty content] チェックボックスをオンにすると、http エンドポイントからデータが返されなくても、このデータソースを使用して基本ビューを作成できます。生成される基本ビューには result
列が追加されますが、クエリの実行時、この列にはデータがありません。
[Ignore HTTP route errors] チェックボックスをチェックして、データソースが無視する必要がある HTTP エラーを構成します。データソースがソースからデータを取得する際、選択したいずれかの HTTP エラーが発生した場合、データソースは失敗し、行を返しませんが、エラーも返しません。他のエラーが発生した場合、データソースはエラーを返し、これによりクエリは失敗します。

HTTP エラー 404 を無視する HTTP パスの構成¶
このオプションと [Ignore route errors] が異なるのは、[Ignore route errors] をチェックした場合、データソースはソースにアクセスする際に発生するあらゆるエラーを無視する点です。
[Limit source access to] ボックスを選択して、単位時間当たりにデータソースに対して行うことができるリクエストの数の制限を構成します。現在の秒/分でのリクエストの制限を超えた場合、後続のリクエストは次の秒/分までキューに入ります。
改ページ¶
REST Web サービスでは、データが「改ページ」して返されることが普通です。つまり、リクエストあたりで返されるレコード数が制限されています。クライアントアプリケーション (この場合は Virtual DataPort) では、必要なデータをすべて取得するために、特定のパラメータを使用したリクエストを複数回送信する必要があります。
改ページされたデータを REST API から取得するように、DF、JSON、および XML の各データソースを構成できます。そのように構成したデータソースからは、複数回のリクエストで取得した行がすべて透過的に返されます。

このオプションを有効にするには、[Pagination] タブに移動して [The service returns paginated data] を選択し、このサービスの改ページ方法を以下から選択します。
4 番目の方法は、アクセスする REST API が他の方法をサポートしていない場合に使用します。4 番目の方法では、このデータソースから基本ビューを作成する際に、カスタムの「タプルルート」を設定する必要があるからです。他の改ページ方法では、この設定が不要です。
改ページは、POST リクエストでも使用できます。POST 本文には、JSON を含めることができます。POST リクエストの場合、以下の 2 つの改ページ方法があります。
POST API リクエストデータの例
ここでは、以降のセクションで使用する POST API の例について説明します。
POST ソースを使用して改ページを行うには、[Configuration] タブに移動して、[post body] セクションを見つける必要があります。このセクションでは、POST API をホストするサーバーの要件に従って、補間変数 @next_page_token
を使用して POST 本文を構築する必要があります。以下に例を示します。
\{
"filter": \{
^ExecuteIfIsNotNull("\"offset\":\"",@next_page_token,"\"")
\}
\}
生成されるリクエストは主に、本文および「改ページ」セクションで説明したパラメータで構成されます。以下の例では、リクエストされたアイテムは 1003、アイテム数は 2 です。
{
"filter": {
"offset":"1003",
"count":2
}
}
POST API から取得する応答は、以下のような JSON ドキュメントです。
{
"contacts": [
{
"id": 1003,
"name": "peter",
"phone": 33333
},
{
"id": 1004,
"name": "johny",
"phone": 44444
}
],
"has-more": true,
"id-offset": 1005
}
ここで、 id
は contact
ごとの ID、 has-more
は返していない結果の有無、 id-offset
は次の結果の ID を示します。
Content-Type が XML
である場合、以下の例のように、本文は XML
構造にする必要があります。
<root>
<filter>
^ExecuteIfIsNotNull("<vidOffset>",@next_page_token,"</vidOffset>")
</filter>
</root>
Content-Type が text/plain
である場合、以下の例のように、本文はプレーンテキストにする必要があります。
^ExecuteIfIsNotNull("\"vidOffset\":\"",@next_page_token,"\"")
1. 応答の HTTP ヘッダーから「次のページの URL」を取得する¶
この改ページ方法は、「次のページ」の URL を記述した HTTP ヘッダーを応答で返す REST サービスまたは「次のページ」の URL を記述した HTTP ヘッダーを応答で返す POST サービスに接続する場合に使用します。
[Pagination] タブで [Obtain the "next page URL" from an HTTP header of the response] を選択します。つづいて、次のページの URL が記述された HTTP ヘッダーの名前を [HTTP header] に入力します。
クエリでこのデータソースを扱っている場合、データソースは以下のように動作します。
データソースは、[Configuration] タブに示された URL に最初のリクエストを送信します。
[HTTP header] フィールドで指定したヘッダーが応答に存在する場合、データソースはその値を検査します。
そのヘッダーの値が「http」で始まる場合、データソースはこの URL にリクエストを送信します。
ヘッダーの値が記号「<」で始まる場合、データソースは、サービスが「 RFC 8288 - Web Linking 」の仕様で定義されている改ページ方法を使用しているものと仮定して、
rel="next"
属性を持つ URL を探します。これは、以下のようなヘッダーを返すサービスで機能します。
RFC 5988 準拠のサービスから返される HTTP ヘッダーのサンプル¶Link: <https://rest-api.acme.com/api/v1/customer.json?opaqueA>; rel="current", <https://rest-api.acme.com/api/v1/customer.json?opaqueB>; rel="next", <https://rest-api.acme.com/api/v1/customer.json?opaqueC>; rel="first", <https://rest-api.acme.com/api/v1/customer.json?opaqueD>; rel="last"
ここの例では、 https://rest-api.acme.com/api/v1/customer.json?opaqueB にデータソースから次のリクエストが送信されます。
rel="next"
が指定された URL が存在しない場合、データソースでは、残っているページがないと見なします。データソースは、このヘッダーが応答に存在しなくなるか、[Maximum number of requests] フィールドで指定された値にリクエストの数が到達するまで、リクエストを送信し続けます。
1.1 POST の考慮事項¶
「 POST API リクエストデータの例 」に示すデータを使用します。
[Pagination] タブで [Obtain the "next page" token from an HTTP header of the response] を選択します。
次に、次のページの URL を生成するために使用する値を格納するトークンの名前を [HTTP header] に入力します。
たとえば、サーバーは、 "header-token: 1003"
など、取得する次のアイテムを示す値を持つ header-token
ヘッダーを追加できます。
2. 応答の本文から「次のページの URL」を取得する¶
この改ページ方法は、「次のページ」の URL を (ヘッダーではなく) 応答に記述して返す REST サービスに接続する場合に使用します。
2.1 REST¶
[Pagination] タブで [Obtain the "next page URL" from the response] を選択します。つづいて、応答に記述された、次のページの URL を指定する名前を [Path to "next" URL in response] に入力します。
たとえば、アクセスする API が以下のような JSON ドキュメントを返すとします。
{
"name": "p_echo",
"elements": [{
"customer_id": "1"
}, {
"customer_id": "2"
}, {
"customer_id": "3"
}
],
"links": [{
"rel": "next",
"title": "Next interval",
"href": "http://rest-api.acme.com/my_service?$start_index=10&$count=10"
}
]
}
[Path to "next" URL in response] には「 /links/href
」と入力します。構文は XML データソースの場合と同じです。XML データソースでは、URL を使用してエレメントを探すときに名前空間が考慮されません。
クエリでこのデータソースを扱っている場合、データソースは以下のように動作します。
データソースは、[Configuration] タブに示された URL にリクエストを送信します。
[Path to "next" URL in response] で指定されたエレメントが応答に存在する場合、データソースはその値を読み込んで、その URL にリクエストを送信します。
応答から取得した値が「http」で 始まらない 場合、データソースは、データソースの URL ([Configuration] タブの [URL] フィールドの値) のプロトコル (HTTP または HTTPS) とホスト名をコピーして、次のリクエストの URL を作成します。
データソースは、 応答の「次の」 URL へのパス が応答に 存在しなくなる か、[Maximum number of requests] フィールドで指定された値にリクエストの数が到達するまで、リクエストを送信し続けます。
「 共通の挙動 」も参照してください。
2.2 POST¶
「 POST API リクエストデータの例 」に示すデータを使用します。
ここでは、その本文を含むリクエストを POST API に送信します。受信する応答は、前述の JSON ドキュメントと同様です。フィールドの名前は、API 実装に応じて異なります。
[Pagination] タブで [Obtain the "next page" token from the response] を選択します。つづいて、応答を処理して次のページの URL を作成するために使用する名前を [Path to next page in the response] に入力します。
[Path to "next" page in response] には「 /id-offset
」と入力します。構文は XML データソースの場合と同じです。XML データソースでは、URL を使用してエレメントを探すときに名前空間が考慮されません。
クエリでこのデータソースを扱っている場合、データソースは以下のように動作します。
データソースは、[Configuration] タブに示された URL にリクエストを送信します。
[Path to "next" page in response] で指定されたエレメントが応答に存在する場合、データソースはその値を読み込んで、その URL にリクエストを送信します。
応答から取得した値が「http」で 始まらない 場合、データソースは、データソースの URL ([Configuration] タブの [URL] フィールドの値) のプロトコル (HTTP または HTTPS) とホスト名をコピーして、次のリクエストの URL を作成します。
データソースは、応答に has-more フィールドが 含まれなくなる か、[Maximum number of requests] フィールドで指定された値にリクエストの数が到達するまで、リクエストを送信し続けます。
「 共通の挙動 」も参照してください。
2.3 共通の挙動¶
[Parameter in URL for page size] と [Page size] に値が指定されている場合、データソースでは、送信するすべてのリクエストの URL にクエリパラメータ <Parameter in URL for page size>=<Page size> を追加します。
[Path to "next" URL in response] が配列フィールドの場合、データソースは、配列の最初のエレメントを読み込みます。URL が配列の 2 番目以降のエレメントに存在する場合、データソースは配列から URL を読み込めません。
API のレスポンスの中で、次ページの URL を含むフィールド名に「/」文字が含まれる場合、この文字に「/」を追加してエスケープする必要があります。たとえば、[Path to "next" URL in response] のフィールド名が「next/link」の場合、次のように入力してください。
/pagination/next//link
3. 応答からトークンを取得する¶
この改ページ方法は、応答にトークンを記述して返す REST サービスに接続し、そのトークンを URL に追加して「次のページ」を取得する必要がある場合に使用します。
[Pagination] タブで [Token continuation] を選択して、以下の情報を指定します。
Parameter in URL for "next" token: URL の中でページのトークンを示すパラメータ。
Path to "next" token in response: 応答に JSON または XML で記述された、「次の」トークンへのパス。
Parameter in URL for page size (オプション):URL の中でページのサイズを示すパラメータ。
Page size (オプション): リクエストあたりで返される必要があるレコードの数 (正の値)。API によっては、リクエストあたりで返すレコード数が制限されているものがあります。

クエリでこのデータソースを扱っている場合、以下のように動作します。
データソースは、[Configuration] タブに示された URL にリクエストを送信します。
応答に [Path to "next" token in response] で指定されたエレメントが存在する場合、データソースは、その値を読み取ります。つづいて、[Configuration] タブに示された URL にパラメータとして Parameter in URL for "next" token = <token read from the response> を追加して、リクエストを送信します。
たとえば、以下の条件がすべて成立している状況を考えます。
[URL] が http://rest-api.acme.com/my_service である。
[Parameter in URL for "next" token] の値が nextPageToken である。
最初のリクエストに対する応答にある [Path to "next" token in response] の値が jkldz82719aa である。
データソースは http://rest-api.acme.com/my_service?nextPageToken=jkldz82719aa に 2 番目のリクエストを送信します。
データソースは、[Maximum number of requests] フィールドの値にリクエスト数が到達するか、応答にトークンが存在しなくなるまで ([Path to "next" token in response] で指定されたエレメントが応答に存在しなくなるまで)、リクエストを送信し続けます。
考慮事項
[Parameter in URL for page size] と [Page size] に値が指定されている場合、データソースでは、送信するすべてのリクエストの URL にクエリパラメータ <Parameter in URL for page size>=<Page size> を追加します。
API のレスポンスの中で、トークンを含むフィールド名に「/」文字が含まれる場合、この文字に「/」を追加してエスケープする必要があります。たとえば、[Path to "next" token in response] のフィールド名が「next/link」の場合、次のように入力してください。
/pagination/next//link
よく起こることではありませんが、一部の API では、返すデータがなくなった場合、前のページと同じトークンを返します。たとえば、1 ページ目のトークンは「token_XYZ」、2 ページ目は「token_ABC」、最後の 3 ページ目は再び「token_ABC」で、3 ページ目が最後であることを示しています。デフォルトでは、データソースは応答にトークンを見つけると、最後のページを無限に取得し続けます。トークンが前のページと同じときにはデータソースがリクエストを停止するようにしたい場合は、以下を実行します。
-- With this command, all the HTTP requests to "acme.com" with pagination will -- stop when the token of a page is the same as the token of the previous page. SET 'com.denodo.parser.connection.http.pagination.stopWhenPaginationTokenDoesNotChange.acme.com' = 'true';
上記のコマンドで、「acme.com」をデータソースのホスト名で置き換えます。ホスト名にサブドメインがある場合は、サブドメインも含める必要があります。たとえば、データソースの URL が「https://roadrunner.acme.com/api/...」などの場合、プロパティは「com.denodo.parser.connection.http.pagination.stopWhenPaginationTokenDoesNotChange.roadrunner.acme.com」にする必要があります。
すべてのデータソースがこのように動作するようにしたい場合は、代わりに以下を実行します。
-- The difference with the previous command is that this one does not -- include the hostname SET 'com.denodo.parser.connection.http.pagination.stopWhenPaginationTokenDoesNotChange' = 'true';
まれに、API によってはクライアントアプリケーション (この場合は Virtual DataPort) が API から返される継続トークンを URL エンコードすることを想定しているものもあります。デフォルトでは、データソースはこれらのトークンをエンコードしませんが、エンコードするように構成することもできます。それには、以下を実行します。
-- With this command, all the HTTP requests to "roadrunner.acme.com" with pagination will -- encode the continuation token. SET 'com.denodo.parser.connection.http.connection.pagination.encodeNextToken.roadrunner.acme.com' = 'true';
上記のコマンドで、「roadrunner.acme.com」を、使用するデータソースのホスト名に置き換えます。
すべてのデータソースがこのように動作するようにしたい場合は、代わりに以下を実行します。
-- The difference with the previous command is that this one does not -- include the hostname SET 'com.denodo.parser.connection.http.connection.pagination.encodeNextToken' = 'true';
デフォルトの動作 (これらのトークンを URL エンコードしない) に戻すには、以下を実行して、これらの構成プロパティを削除します。
-- Setting a configuration property to NULL, removes the property. SET 'com.denodo.parser.connection.http.connection.pagination.encodeNextToken.roadrunner.acme.com' = NULL; SET 'com.denodo.parser.connection.http.connection.pagination.encodeNextToken' = NULL;
4. インデックスによる改ページ¶
これまでに説明した改ページ方法はどれもサポートしていないものの、以下のいずれかをサポートしている REST サービスに接続する場合に、この改ページ方法を使用します。
URL のパラメータとしてページ番号を指定する
URL のパラメータとして行の範囲を指定する (たとえば 50 ~ 100 番目のレコードの取得を指定する)
[Pagination] タブで [Paging indices] を選択して以下の情報を指定します。
Parameter in URL for page size: URL の中でページあたりのレコード数を示すパラメータ。
Page size: URL の中で [Parameter in URL for page size] で指定されたパラメータに設定する値。
Parameter in URL for next records: URL の中でページのインデックスを示すパラメータ。
Index of the first record: 最初のページのインデックス (通常は 0 または 1)。
Offset for the next requests: 次のリクエストで省略されるレコードの数。
Maximum number of requests: リクエストの最大数。
リクエストは、URL に取得する次のレコードのインデックスを設定することにより構築されます。
重要
インデックスによる改ページ を使用するデータソースから基本ビューを作成するプロセスでは、必ず タプルルート を入力します。デフォルト値を使用せず、タプルルートを設定する目的は、この改ページ方法を使用して、データソースがリクエストの送信を継続するか停止するかを、基本ビューが返す行数で判断することにあります。前のリクエストで返された行数より次のリクエストで返された行数が少なければ、データソースはリクエストの送信を停止します。
この警告は、JSON と XML の各データソースにのみ適用され、DF データソースには適用されません。
注釈
リクエスト 0 ~ N の場合、URL は以下のように構築されます。
URL?<ページサイズを表す URL 内パラメータ>=<ページサイズ>&<次のレコードを表す URL 内パラメータ>=<最初のレコードのインデックス + (次のリクエストのオフセット * N)>
クエリでこのデータソースを扱っている場合、以下のように動作します。
データソースは、最初のリクエストを送信するために、[Configuration] タブの URL に以下のパラメータを追加します。
Parameter in URL for page size=Page size
Parameter in URL for next record=Index of first record
データソースは、以降のリクエストを送信するために、[Configuration] タブの URL に以下のパラメータを追加します。
Parameter in URL for page size=Page size
Parameter in URL for next record = Index of first record にリクエスト数を乗算した値。
データソースは、リクエスト数が [Maximum number of requests] フィールドの値に到達するか、基本ビューから返された行数がゼロになるまで、リクエストを送信し続けます。

例
以下のパラメータを持つ API のエンドポイントを呼び出すとします。
start_index: 取得する結果セット全体で最初のレコードのインデックス。
count: 応答あたりのレコード数。リクエストあたり 100 件のレコードを取得するものとします。
このシナリオでは、以下の値を入力する必要があります。
[Parameter in URL for page size] = count
[Page size] = 100
[Parameter in URL for next records] = start_index
[Offset for the next requests] = 5
[Index of the first record] = 0 (この API の最初のページは 0 であることを考慮)
このデータソースの基本ビューにクエリを実行すると、データソースから以下のリクエストが送信されます。
リクエスト #1: http://rest-api.acme.com/my_service?count=100&start_index=0
リクエスト #2: http://rest-api.acme.com/my_service?count=100&start_index=105
リクエスト #3: http://rest-api.acme.com/my_service?count=100&start_index=210
以下同様に、リクエストで返された行数が前のリクエストで返された行数より少なくなるか、リクエスト数が [Maximum number of requests] の値に到達するまでリクエストが継続されます。
プロキシ設定¶
[Proxy] タブでは、このデータソースのプロキシ構成を設定できるほか、Virtual DataPort サーバーの [Default] 構成を使用することもできます (「 HTTP プロキシのデフォルト構成 」を参照)。
HTTP パスでの認証¶
HTTP コネクションでは、以下の認証方法がサポートされています。
Basic: 資格情報はプレーンテキストで送信されます (「 RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication 」)。
Digest: 資格情報は暗号化されて送信されます。
Login endpoint: 以下の「 ログインエンドポイント認証 」のセクションを参照してください。
Mutual (two-way SSL): 下記の「 相互認証 」を参照してください。
NTLM: Microsoft NTLM 認証 (「 NT LAN Manager 認証プロトコルの仕様 」) を使用してサービスに接続します。Virtual DataPort では、NTLM v1 と NTLM v2 をサポートしています。
OAuth 1.0a と OAuth 2.0: 「 OAuth Authentication 」を参照してください。
SPNEGO (Kerberos): 下記の「 SPNEGO (Kerberos) 」を参照してください。
[Pass-through session credentials] チェックボックス ([Basic]、[Digest]、[NTLM]、および [SPNEGO (Kerberos)] の各認証方法で選択可能) をチェックしている場合、このデータソースを扱うクエリをクライアントが実行する際に、サービスにリクエストを送信するために使用される資格情報は、[Login] フィールドと [Password] フィールドの資格情報ではなく、クエリを実行したユーザーの資格情報です。このオプションをチェックしている場合、[Login] フィールドと [Password] フィールドの資格情報が使用されるのは、このデータソースから基本ビューを作成し、サービスにリクエストを送信して、URL の出力を分析する場合のみです。
認証方法が [SPNEGO (Kerberos)] で、[Pass-through session credentials] をチェックしている場合の Virtual DataPort の動作の詳細については、「 SPNEGO (Kerberos) 」を参照してください。
警告
パススルー資格情報が有効なデータソースを使用するビューに対してキャッシュを有効にする場合は注意が必要です。このような場合に発生することが考えられる問題については、付録「 データソースをパススルー資格情報を使用して構成する場合の検討事項 」を参照してください。
ログインエンドポイント認証¶
この認証方法は、エンドポイント (独自の認証方法を持つ場合がある) にアクセスし、HTTP 応答のヘッダーや Cookie を、データソースへの後続リクエストのヘッダー、Cookie、または補間変数として解析します。
HTTP ルートでこの認証方法を有効にするには、以下の手順に従います。
[Edit HTTP connection] ダイアログで [Authentication] タブをクリックします。
[Authentication] リストで [Login Endpoint] を選択します。
使用する Http 手法 を選択します。
[Login Endpoint URL] を入力します。
ログインエンドポイントへのリクエストにヘッダーを追加できます。追加するには、[HTTP headers of the Login Endpoint request] をクリックします。
[Add new mapping] をクリックし、ログインエンドポイントマッピングを入力します。
Source type: [COOKIE] または [HEADER] を選択します。
Source name: ログインエンドポイントから返される Cookie/ヘッダーの名前。
Target type: [COOKIE]、[HEADER]、[INTERPOLATION_VAR] を選択します。
Target name: 後続のリクエストで Cookie/ヘッダー/補間変数が持つ名前。
You can set another type of authentication for the login endpoint itself by selecting it from the Authentication list that appears below and completing its fields.

データソースでのログインエンドポイント認証の構成¶
デフォルトでは、ログインエンドポイントの応答は 2 分間キャッシュされます。このキャッシュを有効または無効にするには、以下のプロパティを true または false に設定します。
-- This property indicates if the login endpoint responses should be cached
-- (Default value: true)
SET 'com.denodo.parser.connection.http.connection.loginEndpoint.enable' = 'true';
注: 開発期間中はこのキャッシュを無効にすることをお勧めします。
ログインエンドポイントのキャッシュのタイムアウトも構成できます。
-- This property indicates the amount of time (in milliseconds) that each entry of the cache is saved for
-- (Default value: 120000)
SET 'com.denodo.parser.connection.http.connection.loginEndpoint.timeout' = '120000';
相互認証¶
SSL/TLS 通信 (たとえば https を使用) を確立する際、クライアント (この場合は Denodo) は、サービスが使用する証明書が証明機関 (CA) によって署名されているかどうかを確認することによって、サービスの身元を確認します。「相互認証」 (別名「双方向 SSL/TLS」) を使用する場合でも、クライアント (この場合は Denodo サーバー) は、認証に証明書を使用し、ユーザー名とパスワードや OAuth トークンは使用しません。
この機能を使用するには、サービスにアクセスするための秘密キーを保持するキーストアファイルが必要です。このファイルは、PKCS#12 形式または Java キーストア (JKS) 形式とする必要があります。
HTTP ルートでこの認証方法を有効にするには、以下の手順に従います。
[Edit HTTP connection] ダイアログで [Authentication] タブをクリックします。
[Authentication] リストで [Mutual (two-way SSL)] を選択します。
[Certificate password] に、秘密キーを保持するファイルのパスワードを入力します。
[Load certificate] をクリックして、秘密キーを保持するファイルを選択します。
証明書が有効であれば、証明書の発行者、証明書の有効期限などが表示されます。
注釈
サービスから送信された証明書を Virtual DataPort で検証する場合は、[Configuration] タブで [Check certificates] を選択します。この検証に適合するには、このサービスが使用する証明書が証明機関 (CA) によって署名されている必要があります。証明書に CA による署名がない場合は、その証明書を Denodo サーバーの TrustStore にインポートする必要があります。そのようにしないと通信が失敗します。

相互認証ウィザード¶
OAuth 認証¶
OAuth は、サードパーティアプリケーション (この場合は Virtual DataPort) がリソース所有者の代わりにサーバー上のリソースにアクセスできるようにする認可フレームワークです。
その主な利点は、サードパーティアプリケーションから各自のデータへのアクセスを認可するために、各自のユーザー名とパスワードをサードパーティアプリケーションに伝達する必要がないことにあります。
以下のサブセクションでは、OAuth 1.0a 認証または OAuth 2.0 認証を使用してサービスに接続するうえで必要な資格情報を容易に取得できるようにするウィザードの使用方法について説明します。
注釈
Virtual DataPort でデータソースを作成する前に、アクセス先のサービスに Virtual DataPort をアプリケーションとして登録する必要があります。
注釈
OAuth 認証を通じて利用する同一サービスからデータを取得するビューが複数必要な場合、そのサービスに作成するデータソースを 1 つのみとして、そこからすべてのビューを作成することが推奨されます。何らかの時点で OAuth 資格情報が変更されても、1 つのデータソースの資格情報を変更するだけで済むからです。このようにするには、URL に補間変数を使用したデータソースを作成します (http://service.com/@OBJECT_TYPE/ <http://service.com/@OBJECT_TYPE/>
)。
OAuth 1.0a¶
注釈
サービスが OAuth 1.0a と 2.0 のどちらを使用しているかわからない場合、1.0a ではなく OAuth 2.0 を使用している可能性が高いです。
ここでは、OAuth 1.0a 認証を使用するサービスからデータを取得するように「HTTP クライアント」ルートを構成する手順について説明します。管理ツールには、OAuth 1.0a 資格情報を容易に取得できるようにする OAuth 1.0a 資格情報ウィザードが用意されています。
以下の手順に従います。
[Edit HTTP connection] ダイアログで [Authentication] タブをクリックします。
[Authentication] リストで [OAuth 1.0a] を選択します。
サービスから提供される クライアント ID と クライアント共有シークレット を入力します。
署名方法を選択します。最も広く使用されている署名は HMAC-SHA1 なので、通常はそれを選択することが適切です。
アクセストークン と アクセストークンシークレット をすでに入手している場合、下にあるボックスにそれらを入力して [Ok] をクリックします。
これらのトークンを入手していない場合、[launch the OAuth 1.0a credentials...] をクリックして、トークン取得を支援するウィザードを開きます。

OAuth 1.0a 資格情報ウィザード¶
[Temporary credential request URL]、[Resource owner authorization URL]、および [Token request URL] に適切な値を入力します。
アクセス先のサービスのドキュメントには、これらの詳細が記載されている必要があります。
[Callback URL] を選択します。ウィザードの手順 2 に進むと、ブラウザーで URL を開く必要があります。この URL をブラウザーで指定すると、Virtual DataPort によるデータへのアクセスを認可するためのページが表示されます。先に進むと 確認コード を取得できます。Virtual DataPort では、この確認コードを使用して HTTP リクエストをサービスに送信します。その応答に アクセストークン と アクセストークンシークレット が含まれています。
[Callback URL] では、サービスから 確認コード を返す方法を指定します。
注釈
サービスによっては、オプションを自由に選択できないことがあります。また、特定のリダイレクト URL の使用が求められる場合もあれば、oob などの特定のオプションのみを使用できる場合もあります。
oob: このオプションを選択すると、認証プロセスの後でブラウザーに 確認コード を表示することが、ウィザードからサービスに要求されます。
2 番目または 3 番目のオプションを選択すると、それぞれの URL にブラウザーがリダイレクトされ、そこにパラメータ
code
が追加されます。このパラメータの値が 確認コード です。デフォルトの URL (http://localhost:9090/oauth/1.0a/callbackURL.jsp) は、Denodo Platform に組み込まれている Apache Tomcat に存在する JSP を 参照 しています。そこでは、パラメータ
code
の値がボックスに表示されるので、容易にコピーできます。別のコールバック URL を指定する必要がある場合、その URL からパラメータ
code
の値を手動で抽出する必要があります。[Generate the authorization URL] をクリックします。Virtual DataPort から 一時トークン が要求され、それを使用して 認可 URL が生成されます。
[Open URL] をクリックします。ブラウザーを起動していない場合は、URL をコピーして手動でブラウザーを開きます。
この URL で、サービスからデータを取得する操作を Virtual DataPort サーバーに認可する必要があります。
データへのアクセスを Virtual DataPort に認可すると、サービスから 確認コード が返されます。このコードを [Paste the verification code] テキストフィールドに入力します。
[Callback URL] で [oob] を選択していた場合は、確認コードの値を入力する必要があります。デフォルトの URL を選択していた場合は、確認コードをコピーしてこのボックスに貼り付けることができます。
[Obtain the OAuth 1.0a credentials] をクリックします。Virtual DataPort サーバーは、入力されたすべての詳細情報と 確認コード を使用して、OAuth トークンを要求します。
[Ok] をクリックしてウィザードを閉じます。
ウィザードによって [OAuth access token] と [OAuth access token secret] の各テキスト領域に値が入力されます。
[Ok] をクリックして [Edit HTTP Connection] ダイアログを閉じます。つづいて、[Save] をクリックするとデータソースが作成されます。
このウィザードを単独で使用するには、管理ツールの [Tools] > [OAuth credentials wizards] メニューで [OAuth 1.0a wizard] をクリックします。
OAuth 資格情報を入力パラメータとするカスタムラッパーを使用する場合は、このウィザードを使用する必要があります。
OAuth 2.0¶
ここでは、OAuth 2.0 認証を使用するサービスからデータを取得するように「HTTP クライアント」ルートを構成する手順について説明します。管理ツールには、OAuth 2.0 資格情報を容易に取得できるようにする OAuth 2.0 資格情報ウィザードが用意されています。
注釈
サービスが OAuth 1.0a と 2.0 のどちらを使用しているかわからない場合は、OAuth 2.0 を使用している可能性が高いです。
管理ツールには、OAuth 2.0 資格情報を容易に取得できるようにする OAuth 2.0 資格情報ウィザードが用意されています。

データソースでの OAuth 2.0 認証の構成¶
以下の手順に従います。
[Edit HTTP connection] ダイアログで [Authentication] タブをクリックします。
[Authentication] リストで [OAuth 2.0] を選択します。
[Authentication grant] で適切なオプションを選択します。
Authorization code grant: サービスに登録しているユーザー名とパスワードを入力する必要がないことから、これが最も安全なオプションです。取得する必要があるのは「アクセストークン」と「更新トークン」のみであり、どちらもこのダイアログのウィザードを使用して取得できます。この付与方法には、(サービスにもよりますが) 通常はこのデータソースで実行できる操作を制限できるという利点もあります (データへの読み込みアクセスのみ許可するなど)。また、アクセストークンや更新トークンが侵害された場合、このサービスのユーザーアカウントのパスワードを変更しなくても、それらのトークンを無効にすることができます。
[Resource owner password credentials]
[Client credentials grant]
この 2 番目と 3 番目のオプションは、アクセストークンも更新トークンも取得する必要がないので、1 番目のオプションより構成が簡単ですが、1 番目のオプションにあるような利点は得られません。
使用可能なオプションについては、このサービスのドキュメントを参照してください。
これらのオプションの詳細については「 RFC 6749 - The OAuth 2.0 Authorization Framework 」を参照してください。
[Client identifier] と [Client secret] に、サービスから提供された情報を入力します。
[Resource owner password credentials] を選択した場合のみ、[User identifier] と [User password] を入力します。
[Authentication method used by the authorization servers] のいずれかのオプションを選択します。これは、Virtual DataPort から新しい OAuth アクセストークンを要求する際にユーザーの資格情報をサービスに送信する方法を制御します。以下のオプションがあります。
Include the client credentials in the body of the request: リクエスト本文のパラメータ
client_id
およびclient_secret
として資格情報を追加します。Send client credentials using the HTTP Basic authentication scheme: HTTP リクエストの
Authentication
ヘッダーで資格情報を送信します。
これら 2 つのオプションについては、OAuth 2.0 仕様 (RFC 6749 - The OAuth 2.0 Authorization Framework) の「2.3.1. Client Password」を参照してください。
1 番目のオプションのほうが広く使用されていますが、サービスによっては 2 番目のオプションを必要とするものがあります。
すでに OAuth アクセストークンを入手している場合、それを [Access token] ボックスに入力し、[Request signing method] で適切なオプションを選択します。更新トークンも入手している場合は、それを [Refresh token] ボックスに入力します。トークンのエンドポイント URL の値を [Token endpoint URL] に入力し、アクセストークンの有効期間 (秒数) がわかっている場合はその値も入力します。
アクセストークンが未入手で、データソースにアクセストークンを保存しておくのではなく、実行時にアクセストークンを指定する場合は、[Access token value is an interpolation variable] をチェックして、その下のボックスにトークンの補間変数の名前を入力します。実行時には、このデータソースの基本ビューに対して実行するクエリで、この補間変数の値を指定する必要があります。この値が、データソースへの接続で使用するアクセストークンになります。OAuth 2.0 認証を要求するソースであっても、その仕様を全面的には実装していない場合に、このオプションが効果的です。この場合は、このトークンを取得して基本ビューに渡すストアドプロシージャを開発するという方法もあります。
アクセストークンが未入手で、データソースからトークンを入手する場合は、[launch the OAuth 2.0 credentials...] をクリックして、トークンを容易に入手できるようにするウィザードを開きます。

OAuth 2.0 資格情報ウィザード¶
[Token endpoint URL] を入力します。
[Authorization code grant] を選択した場合のみ、[Authorization server URL] を入力します。
[Authorization code grant] を選択した場合のみ、[Redirect URI] を選択します。このウィザードの手順 2 に進むと、ブラウザーで URL を開く必要があります。この URL をブラウザーで指定すると、Virtual DataPort によるデータへのアクセスを認可するためのページが表示されます。
先に進むと、サービスによって [Redirect URI] の URI にブラウザーがリダイレクトされ、そこにいくつかのパラメータが追加されます。Virtual DataPort では、これらのパラメータの値を使用して、HTTP リクエストをサービスに送信します。その応答に アクセストークン が含まれるほか、 更新トークン が付随することもあります。
追加するスコープごとに
ボタンをクリックして、その名前を入力します。
スコープは、サービスで定義される「権限」であり、アプリケーションが要求できるデータを制御します。
たとえば、Twitter ではさまざまなスコープが定義されています。このウィザードで要求したスコープによっては、Virtual DataPort でユーザーのツイートを取得できますが、ユーザーの代わりに新しいツイートを送信することはできません。
前のダイアログで [Authorization code grant] を選択している場合は、この後の手順の e. から h. までのみを実行します。
通常、[Set the "state" request] パラメータは選択したままでかまいません。ただし、OAuth 資格情報の取得プロセスが失敗した場合は、このパラメータを選択することがサービスで許可されていることを確認します。
[Generate the authorization URL] をクリックします。
Virtual DataPort によって、指定したすべてのパラメータを使用して URL が生成されます。
[Open URL] をクリックします。
ブラウザーを起動していない場合は、URL をコピーして手動でブラウザーを開きます。
この URL で、サービスからデータを取得する操作を Virtual DataPort サーバーに認可する必要があります。
アプリケーションを認可すると、サービスによってリダイレクトされます。このリダイレクト先の URL を手順 3 のテキストフィールドに貼り付けます。
[Obtain the OAuth 2.0 credentials] をクリックします。
Virtual DataPort サーバーから、入力したすべての詳細情報、および前の手順で貼り付けた URL のパラメータを使用して OAuth 資格情報が要求されます。
[Ok] をクリックしてウィザードを閉じます。
ウィザードによって、サービスから返された情報がテキスト領域とテキストフィールドに入力されます。
すべてのサービスが 更新トークン を提供するわけではないので、このテキスト領域が空になることも考えられます。
[Request signing method] を選択します。Virtual DataPort は、 アクセストークン を使用して各リクエストに署名する必要があります。通常は、すべての OAuth サービスで、["Authorization" request header] を使用できます。これは、特殊な HTTP ヘッダーをリクエストに追加する方法です。この方法をサポートしていないサービスについては、以下に示すように、標準で定義されている他の方法を選択できます。
Form-encoded body parameter: リクエストの本文でトークンを送信します (HTTP の POST リクエストでのみ使用可能)。
URL query parameter ("access_token"): URL のパラメータ
access_token
でトークンを送信します。URL custom query parameter: "access_token" とは別の名前のクエリパラメータとしてトークンを追加します。
アクセストークンが未入手で、データソースにアクセストークンを保存しておくのではなく、実行時にアクセストークンを指定する場合は、[Refresh token value is an interpolation variable] をチェックして、その下のボックスにトークンの補間変数の名前を入力します。実行時には、このデータソースの基本ビューに対して実行するクエリで、この補間変数の値を指定する必要があります。必要に応じ、この値を使用してアクセストークンが更新されます。OAuth 2.0 認証を要求するソースであっても、その仕様を全面的には実装していない場合に、このオプションが効果的です。この場合は、このトークンを取得して基本ビューに渡すストアドプロシージャを開発するという方法もあります。
OAuth 2.0 認証を使用する REST API の中には、クライアントによる追加のパラメータの送信が必要になるものがあります。[Extra parameters of the refresh token requests] をクリックしてパラメータを追加してください。Denodo によって、パラメータが以下のどちらかのリクエストに追加されます。
アクセストークンを初めて取得するリクエストで送信。[OAuth Credentials Wizard] で [Obtain the OAuth 2.0 credentials] をクリックしたときに生成される URL にパラメータを追加します。
データソースがアクセストークンを更新するリクエストで送信。現在のアクセストークンが期限切れとなった場合、データソースは更新トークンを使用して新しいアクセストークンを取得する必要があります。
たとえば、クラウド上の Microsoft サービスに OAuth 2.0 認証を使用して接続する場合、パラメータ
resource
を追加する必要があるでしょう。その値は接続先アプリケーションの ID とします。これは、この API による要件です。このダイアログで、パラメータの値の横にある [Encrypted] チェックボックスをチェックした場合、データソースはこの値を暗号化した状態で保管します。
[Pass-through session credentials] を選択した場合、以下のいずれかのパススルー戦略を選択します。
重要
選択した戦略が関連するのは、ユーザーが OAuth 認証を使用して Virtual DataPort にログインした場合のパススルーセッション資格情報のみです。
Token exchange flow (RFC 8693): データソースは、 トークン交換フロー (「 RFC 8693 」で定義されている) を使用して、コネクションを確立するためにアクセストークンを取得します。
On-behalf-of flow (Azure AD): データソースは、Microsoft 独自の On-behalf-of フローを使用して、コネクションを確立するためにアクセストークンを取得します。
OAuth Token pass-through: データソースは、クライアントアプリケーションが Virtual DataPort にログインするために使用したのと同じアクセストークンを使用してソースに接続します。
さらに、以下に示すようなデフォルト値が入力されたいくつかのフィールドおよび新しいフィールドが表示されます。
[Resource owner password credentials] では [Authentication grant] が選択されます。
[Include the client credentials in the body of the request] では [Authentication method used by the authorization server] が選択されます。
["Authorization" request header] では [Request signing method] が選択されます。
最後に [Scope] が表示されます。セッションのアクセストークンの有効期限が切れた場合に備えて、新しいアクセストークンを取得するスコープを入力する必要があります。
注釈
ユーザーが Denodo SSO によって認証される場合、Virtual DataPort サーバーがパススルー戦略で使用するトークンを確実に取得するように、元の OAuth トークン (「 Denodo Security Token の構成ファイル 」を参照) を含むよう Denodo Security Token を構成することが重要です。
[Ok] をクリックして [Edit HTTP Connection] を閉じます。つづいて、[Save] をクリックするとデータソースが作成されます。
通常、OAuth 2.0 資格情報ウィザードを起動するには、[Create JSON data source] ダイアログまたは [Create XML data source] ダイアログを使用します。ただし、管理ツールの [Tools] > [OAuth credentials wizards] メニューで [OAuth 2.0 wizard] をクリックすることで、このウィザードを単独で使用することもできます。
OAuth 資格情報を入力パラメータとするカスタムラッパーを使用する場合は、このウィザードを使用する必要があります。
SPNEGO (Kerberos)¶
データソースの認証方法が SPNEGO (Kerberos) である場合、Virtual DataPort では Kerberos チケットを使用して、サービスに送信する HTTP リクエストに認証ヘッダーを追加します。
[Pass-through session credentials] チェックボックスをチェックしていない場合、Virtual DataPort サーバーでは、[Login] ボックスと [Password] ボックスの値を使用してキー配布センター (KDC) に接続し、Kerberos サービスチケットを要求します。
[Pass-through session credentials] チェックボックスをチェックしている場合、Virtual DataPort は、このデータソースを扱うクエリを実行するクライアントの代わりに、クライアントの資格情報を使用して Kerberos サービスチケットを取得します。Virtual DataPort の正確な動作は、クライアントが使用する認証方法によって次のように異なります。
クライアントが Kerberos 認証を使用して Virtual DataPort サーバーに接続する場合: Virtual DataPort サーバーは、クエリを実行するクライアントの代わりに、このクライアントが Virtual DataPort サーバーとのコネクションを開いたときに取得した TGT (ticket-granting ticket) を使用してキー配布センター (KDC) にサービスチケットを要求します。取得したサービスチケットを使用して、サービスに送信する HTTP リクエストに認証ヘッダーを追加します。
クライアントが標準の認証を使用して Virtual DataPort サーバーに接続する場合: Virtual DataPort サーバーは、クエリを実行するクライアントのユーザー名とパスワードを使用して KDC にサービスチケットを要求します。そのときは、以下の点が考慮されます。
Virtual DataPort サーバーが Windows で動作していても、そのホストが Windows ドメインに属していない場合は、『インストールガイド』の「 Kerberos レルムに属することなく Kerberos 認証を有効化する 」のセクションの説明に従って、java.security.krb5.realm と java.security.krb5.kdc のシステムプロパティを定義します。
Virtual DataPort サーバーが Linux で動作している場合は、システムに
krb5.ini
ファイルが必要です (このファイルがシステムに存在するかどうかを確認する手順の詳細については、「 Kerberos 認証用の krb5 ファイルの提供 」のページを参照してください)。
コネクションプール¶
デフォルトでは、HTTP パスを使用するデータソースは、ソースへのコネクションプールを維持します。これにより、リクエストの実行が高速化されます。以下のプロパティを設定することにより、このコネクションプールを無効にすることができます。
-- This property indicates if connections are checked when they are retrieved from the pool.
-- (Default value: false)
SET 'com.denodo.parser.connection.http.testOnBorrow' = 'true';
-- This property indicates the time in milliseconds that a connection can remain idle at the pool available for being used to execute a new request.
-- When this timeout is reached, then the connection will be removed from the pool in the next checking. This property only applies when "testOnBorrow" is true.
-- (Default value: 10000)
SET 'com.denodo.parser.connection.http.minEvictableIdleTimeMillis' = 0;