[CAIレシピ] OData Consumer接続の検証

はじめに

この記事では、CAIのアプリケーション接続(JDBC)を利用してCDIのOData Consumer接続の動作確認をする手順を確認します。

アプリケーション接続(JDBC)をOData Consumer接続で利用する

今回はDBを操作するためのアプリケーション接続設定で作成したアプリケーション接続を利用します。

REST APIとは？ODataとは？

REST API（RESTful API）とは、RESTの原則に則ったWeb APIのことを指します。REST（Representational State Transfer）は、Webの設計思想の一つで、以下の特徴を持つAPI設計のスタイルです。

• リソース指向
  REST APIが扱う対象は「リソース」と呼ばれ、それぞれがURL（エンドポイント）で一意に識別されます。
  例：ユーザー情報を取得する場合は /users/123 のように表現します。
• HTTPメソッドの活用
  操作はHTTPメソッドで表現されます。代表的なメソッドは以下の通りです。
  • GET：リソースの取得
  • POST：リソースの作成
  • PUT：リソースの更新
  • DELETE：リソースの削除
• ステートレス
  各リクエストは独立しており、サーバーはクライアントの状態を保持しません。例えば、クライアントがCurlでGETリクエストを送信してレスポンスを受け取ったら、その接続はそこで終了します(クライアント-サーバーシステムでは接続状態の保持が可能)。
• 表現の統一
  データの送受信は一般的にJSONやXMLなどのフォーマットで行われます。これにより、クライアントとサーバー間でのデータ交換が標準化されます。

OData とは、REST APIの使い方について共通の仕様を定義したものであり、REST APIのSubsetと言えます。

以下、REST APIとODataの比較表です。

	REST API	OData
規格	無し	OASIS標準(V2, V4)
データ取得方法	条件の指定方法は各API独自 Bodyで指定 Query Parameterで指定 など	条件の指定方法は規格化されておりQuery Parameterを利用 \$filter(where)) \$select(列選択) \$top/\$skip(paging)
metadata	エンドポイントが提供するデータフォーマット(metadata)は無いので、REST V2接続で接続を構成する際にSwaggerファイルとしてmetadataを定義する必要がある	URL(ServiceRootURi/$metadata)にアクセスすることでエンドポイントが提供するデータフォーマットを参照できる

metadataへのアクセス方法についてはトラブルシューティングをするうえで重要です。ODataでは、metadataをURL:ServiceRootURi/$metadata より取得します。metadataの取得について何らかの問題があった場合には、まずは、ブラウザでURL:ServiceRootURi/$metadata にアクセスしてmetadataを取得可能であるかを確認すると良いでしょう。ServiceRootURi について詳しくはODataに関する公式ウェブサイトに記載があります。

CDIで利用できるODataと接続するための接続

ODataにはいくつかバージョンがあり、CDIでは汎用接続としてバージョン別に次の接続を利用できます。

• OData V2 ... OData V2接続
• OData V4 ... OData Consumer接続

OData Consumer接続の作成

アプリケーション接続のODataオプションにより作成されるエンドポイントはOData V4に対応していますので、OData Consumer接続を作成します。

1. アプリケーション接続設定で作成したアプリケーション接続のプロパティの詳細より、ODataサービスのURLをコピーします。
   

2. OData Consumer接続の定義画面にて、コピーしたURL と アプリケーション接続の定義画面で定義したIICSユーザー を入力後に テスト を実行すると次のようにエラーが発生します。
   
   エラーメッセージより、metadataを取得するために ServiceRootURi/$metadata にアクセスしようとしているけど、うまくアクセスできていないという状況が読み取れます。更にじっくりエラーメッセージを読むと、$metadata の前にスラッシュが不足していることに気づきます。
   URLフィールドの一番後ろにスラッシュを加えて、テスト接続に成功する動作を確認できたら、接続を保存します。
   

3. ソース接続では、作成したOData Consumer接続を指定して、ソースオブジェクトとして RECIPETEST001PK を指定します。
   

4. ターゲットTX にて出力先の設定をします。今回はFlat File接続にて実行時にファイルが新規作成されるように指定しました。
   

マッピング実行時の動作確認

マッピングタスクを実行すると、完了までに2分強を要した結果、ステータスは 成功 と表示される一方で、成功した行 は 0 と表示されていました。

セッションログを参照すると次のように、11回データのフェッチ処理が行われており、ログに出力されているURLには問題は無いようでした。

セッションログ

Target tables:

     tgt_CAITestOData_csv


READER_1_1_1> 略 You specified the page size as 100.
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?%24select=COL1%2CCOL2&%24top=100].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=100].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=200].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=300].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=400].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=500].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=600].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=700].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=800].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=900].
READER_1_1_1> 略 The URI constructed for the data fetch is: [https://usw5-cai.dm-us.informaticacloud.com:443/active-bpel/odata/v4/recipe-appConn-Jdbc/RECIPETEST001PK?$select=COL1,COL2&$top=100&$skip=1000].
TRANSF_1_1_1> DBG_21216 [2025-12-15 15:01:29.813] Finished transformations for Source Qualifier [ソース]. Total errors [0] 

さて、何が問題なのか。
出力されているURLをコピーしてブラウザでアクセスして取得できたデータ(下記スクリーンショット)を見ていると、ATOM/XML形式の応答であることに気づきました。

応答形式に何らかの制約があるのかもしれないという仮説の元、接続の定義画面にて データ直列化フォーマット を JSON に変更したところ、期待どおりマッピングが動作することを確認できました。

おわりに

今回、データ直列化フォーマット として ATOM/XML 形式を使用した際に、期待どおりの動作が得られなかった原因は現時点で明確な理由を特定できていません。しかしながら、本記事の主目的であるOData Consumer接続の動作確認を行うための環境構築は無事に達成できました(そして、手を動かして動作を確認することの重要性を改めて認識できました)。

参照

• Qiita - IICS CAIの実装レシピ - マスターページ