概要
TDVに追加したデータソースに対してINSERT / UPDATE / DELETE文を実行するプロシージャをWebサービス形式のデータサービスとして公開(パブリッシュ)し、そのデータサービスをREST APIとしてAPIクライアントツールから実行することで、データソースに変更を加えることができます。
検証環境
PostgreSQL(外部データソース)
外部データソース用のPostgreSQLインスタンス(5432ポート)です。
TDV ServerにバンドルされているリポジトリDB(9408ポート)やデフォルトキャッシュデータベース(9404ポート)とは異なります。
TDVに追加するデータソースとして、PostgreSQLインスタンス内に作成済みの「契約管理データベース」を使用します。
「契約管理データベース」は「契約管理スキーマ」を持ち、そのスキーマ内に「契約テーブル」が存在します。
「契約テーブル」には10件のレコードが存在しています。(以下はDBeaverで接続しプレビューしたものです。)
CREATE TABLEでは、「契約管理スキーマ」内に新しいテーブルを作成しますので、TDV ServerからPostgreSQLデータソースへの接続に利用するユーザー(tdv
)には各種クエリ(INSERT, UPDATE, …)を実行するために必要な権限がPostgreSQL側で事前に付与されています。
TDV Server
TDV Serverは、PostgreSQL(外部データソース)と同一サーバー上で実行されています。
データソース
PostgreSQL(外部データソース)の「契約管理データベース」がデータソースとして追加されており、
「契約管理スキーマ」とその配下の「契約テーブル」がイントロスペクトされ、メタデータが追加されています。
公開データサービス
コンポジットデータサービス「契約管理データベース」>「契約管理スキーマ」>「契約テーブル」がデータサービス(データベース方式)として公開されています。
コンポジットデータサービス「契約管理データベース」には、コンテナのマッピング設定を事前に行います。
ここでは、コンポジットデータサービス「契約管理データベース」直下の「契約管理スキーマ」とデータソース「契約管理データベース」直下の「契約管理スキーマ」の対応付けを行います。
これにより、公開テーブル「契約管理データベース」>「契約管理スキーマ」>「契約テーブル」に対して外部のクライアントアプリなどからDDLクエリが実行された場合には、対応するスキーマ、すなわちデータソース「契約管理データベース」>「契約管理スキーマ」に対してそのDDLがわたされ、結果として、データソース「契約管理データベース」の先にある物理データソース(PostgreSQL)に対してそのDDLが実行されることになります。
プロシージャ作成・公開
契約管理テーブルに対して、INSERT / UPDATE / DELETEを実行するプロシージャを作成し、Webサービスとして公開します。
すべてのプロシージャを公開し、https://<TDV Serverのホスト>:9402/rest/api-docs/webservice.html
で確認すると、以下のように公開済みREST APIが表示されます。
以下に、作成するプロシージャとWebサービスの設定を示します。
INSERT
PROCEDURE 契約追加プロシージャ( IN cid INTEGER, IN name VARCHAR(100), IN ammount INTEGER, IN client VARCHAR(100), IN sdate DATE, IN edate DATE, OUT result VARCHAR(100)) BEGIN INDEPENDENT TRANSACTION INSERT INTO /shared/検証用データベース/契約管理データベース/契約管理スキーマ/契約テーブル( 契約ID, 契約名, 金額, 取引先名, 契約開始日, 契約終了日) VALUES ( cid, name, ammount, client, sdate, edate); SET result = 'Insert succeeded.'; EXCEPTION ELSE SET result = 'Insert failed.'; END
UPDATE
PROCEDURE 契約更新プロシージャ( IN cid INTEGER, IN name VARCHAR(100), IN ammount INTEGER, IN client VARCHAR(100), IN sdate DATE, IN edate DATE, OUT result VARCHAR(100)) BEGIN INDEPENDENT TRANSACTION UPDATE /shared/検証用データベース/契約管理データベース/契約管理スキーマ/契約テーブル SET "契約名" = name, "金額" = ammount, "取引先名" = client, "契約開始日" = sdate, "契約終了日" = edate WHERE "契約ID" = cid; SET result = 'Update succeeded.'; EXCEPTION ELSE SET result = 'Update failed.'; END
DELETE
PROCEDURE 契約削除プロシージャ( IN cid INTEGER, OUT result VARCHAR(100)) BEGIN INDEPENDENT TRANSACTION DELETE FROM /shared/検証用データベース/契約管理データベース/契約管理スキーマ/契約テーブル WHERE "契約ID" = cid; SET result = 'Delete succeeded.'; EXCEPTION ELSE SET result = 'Delete failed.'; END
REST API実行
本記事では、Talend API Tester(Google Chromeの拡張機能)からTDVの公開Webサービスにリクエストを実行し、INSERT / UPDATE / DELETEがそれぞれ正常に実行されることを確認します。
INSERT
リクエストボディは以下のとおりです。
{ "insert_contract": { "cid": 11, "name": "サーバー構築", "ammount": 80000, "client": "BCDシステムズ", "sdate": "2024-01-01", "edate": "2024-03-31" } }
続いて、TDV公開テーブルに対して、以下のSELECTクエリを実行し、 レコードが1件追加されたことを確認します。
SELECT * FROM 契約管理スキーマ.契約テーブル
TDV Studio上でも同様に確認します。
最後に、物理データソース(PostgreSQL)のテーブルも直接参照して確認します。
このように、INSERT実行用プロシージャ由来のTDV公開REST APIを実行することで、その先の物理データソースに対してINSERTを実行することができます。
UPDATE
リクエストボディは以下のとおりです。
{ "update_contract": { "cid": 8, "name": "アプリケーション開発", "ammount": 70000, "client": "STUソリューションズ", "sdate": "2023-08-01", "edate": null } }
続いて、TDV公開テーブルに対して、以下のSELECTクエリを実行し、 契約ID = 8
のレコードが更新されたことを確認します。
SELECT * FROM 契約管理スキーマ.契約テーブル
TDV Studio上でも同様に確認します。
最後に、物理データソース(PostgreSQL)のテーブルも直接参照して確認します。
このように、UPDATE用プロシージャ由来のTDV公開REST APIを実行することで、その先の物理データソースに対してUPDATEを実行することができます。
DELETE
delete_contract/{cid}
という形式でパスに契約ID
を指定してリクエストします。
続いて、TDV公開テーブルに対して、以下のSELECTクエリを実行し、 契約ID = 3
のレコードが削除されたことを確認します。
SELECT * FROM 契約管理スキーマ.契約テーブル
TDV Studio上でも同様に確認します。
最後に、物理データソース(PostgreSQL)のテーブルも直接参照して確認します。
このように、DELETE用プロシージャ由来のTDV公開REST APIを実行することで、その先の物理データソースに対してDELETEを実行することができます。