CData Driver かAPI コーディングか？決める前にイベントドリブン連携とデータドリブン連携かを考えよう

CData は、200を超えるSaaS、クラウドDB などへの連携を簡単にするSQL ベースのデータドライバーを提供しています。

急にですがクイズです。どちらのケースがCData Driver に向いているでしょう？：

A：「アプリケーションからクラウドのSlack に連携して通知をだしたい！」

B：「クラウドのkintone データを〇〇というBI ツールに連携したい！」

答えはB です。ここで重要な点はデータ連携がイベントドリブンかデータドリブンかという考え方です。この記事では、データソースの性質に注目して、利用がイベントドリブンなのかデータドリブンなのかを考えながら、CData Drivers の利用が適切なのかどうかを考えます。

結論から言えば、データドリブンな利用にはCData Drivers はとても有効で、イベントドリブンな場合には、API をコーディングして連携実装することをお勧めします。

1. イベントドリブンなAPI

特定の機能・アクションを提供するSaaS やAPI を考えてみましょう。SNS のいいねや共有、チャット（Slack）、メール、メール配信（Sendgrid、MailChimp）、電話（Twilio）、支払（Stripe）、電子契約（CloudSign、DocuSign）など多くの便利なサービスがあります。これらのサービスは多くのアプリケーションやサービスで必要な機能をAPI で提供しており、それらのAPI を利用することで、車輪の再発明を行うことなく、低コストかつ短期間でのローンチが可能になります。まさにクラウドマッシュアップというか組み合わせ系のイノベーションにぴったりのサービス・API です。UI が存在せずにAPI での操作が前提で作られているサービスも多いです。

イベントドリブンなAPI 連携の性質

• リアルタイム性が非常に高い。ボタンを押したら、すぐに通知は飛んでほしいですし、支払はすぐにやらないと意味がありません。

• 定型処理。基本的に処理のバリエーションはあまりありません。署名は署名だし、支払は誰がいくらの処理をしたかというデータを渡すだけです。多くない情報を定型で渡すだけのAPI と言えるでしょう。コピーしてそのまま使えるスニペットで実装ができるば場合が多い。

• 連携処理単位は1レコード単位です。API リクエストではイベントごとに1レコード単位でリクエストされます。まあ、リアルタイム性と表裏の性質です。

• 処理の種類は、アクション起動かデータの1レコードの挿入です。

• イベント系のエンドポイントは、/sendmail などのようにイベント名になっていることが多いようです。データ系とおもっていたAPI でも扱うエンドポイントがこのようなイベント系の名前の場合、実はイベント系の操作の場合があります。

API 連携の手法について

これらのデータドリブンなAPI の実装はあまり難易度は高くありません。定型ですので、API コーディングでもスニペットのコピーで連携ができるものがほとんどです。CData Drivers を使うまでもなくAPI の連携実装ができると思います。

2. データドリブンなAPI

従来DB をバックに業務アプリケーションとして開発されていたものをリプレースしたようなSaaS はデータドリブンなAPI を提供しています。Salesforce、Dynamics CRM などのCRM/SFA、SAP、NetSuite、Dynamics 365 などのERP、kintone などのWebDB 的なアプリプラットフォームサービス、もちろんクラウドDB などです。

これらのサービスは基本的にユーザーはUI を操作して入力作業を行います。これらのサービスへのAPI を使ったデータ連携は以下のようなケースが多いです：

• 蓄積されたデータのBI やアナリティクスでの分析

• 他のシステムからのデータのローディング

• 他のシステムからのデータのLookup 参照

上記のイベントドリブンなAPI の利用方法とは大きく異なります。アクションではなくデータを読み書き更新するためのAPI 利用です。

データドリブンなAPI の性質

• リアルタイム性は高くない。いわゆる10秒20秒のレベルでのリアルタイム性はもとめられません（のぞくLookup 参照）。日次バッチ処理でOK というレベルが多そうです。

• 処理はある程度複雑になります。分析などでのデータの抽出であれば、さまざまなフィルタリングや並び替え条件が付きます。時にはJOIN やサブクエリも必要です。更新系ではさらに高度なデータ処理が必要になります。

• 連携の処理単位は複数レコードのバルクです。分析データを1件1件取得するような必要はありませんし、バッチでのデータローディングも当然複数データです。ある程度の規模のデータを扱うことを前提に実装が必要です。

• 処理の種類は、データのCRUD（Create、Read、Update、Delete）です。データの登録だけではなく、既存データの更新やデータの削除が必要なケースがほとんどです。

• 一般的なデータ系のエンドポイントは /customers や/products などデータセット名のエンドポイントになっています。安心してデータ系エンドポイントとして使いましょう。

API 連携の手法について

こういったデータドリブンなAPI 連携には、CData Drivers が最適です。 理由は大きく分けて2点です：

1. 複数レコードのデータ（データベース的なもの）を扱うにはSQL 言語が現状最適

SQL 言語は40年以上も世界中の開発者・企業に使われてきたデータ処理言語です。複数レコードを処理するには最も汎用的で使いやすいため、利用できる技術者も多いです。CData Driver は、ANSI-92 のSQL に準拠しています。それぞれのWeb API のリクエストをCData Driver のSQL エンジンにマッピングしており、通常のCRUD からフィルタリング、ソート、JOIN、文字列・日付・集計などの各関数が利用できます。

2. BI やデータ連携ツールでシームレスに使える

このようなデータ処理は、BI ツールやデータ連携ツールを使って連携することも多いです。BI やデータ連携ツールには通常ODBC やJDBC などの汎用のデータインターフェースがあります。CData ODBC やJDBC Driver はこれらのツールの汎用ODBC・JDBC インターフェースを使って、シームレスにノーコードでAPI への連携を実現することができます。

3. IDE や開発フレームワークからDB のように使える

もちろんIDE で直接開発する際にも各種フレームワーク、GUI コンポーネント、ORM などでもCData Drivers をDB と同感覚でつかうことができます。

ご注意

このイベントドリブンとデータドリブンの分類はおおまかなものです。以下のように使い方によっては、分類をクロスしてしまうものもありますのでご注意ください。

イベントドリブンなデータソースだけどデータドリブンな利用

Slack やメールなどの情報をデータとして取り込んで分析・解析したいという場合には連携はデータドリブンです。また、これらのサービスのユーザーのリスト化、利用状況管理を別アプリケーションから行うなどもデータドリブンな使い方です。このような場合にはCData Drivers は極めて有効に利用可能です。

業務アプリケーション系でもイベントドリブンな利用

業務アプリ系（Salesforceやkintone）でもリアルタイム性を求められるケースがあります。業務フローとして、一つのSaasでの処理を行ったら次のSaasでの処理をキックするような場合です。もしくはマスターデータをリアルタイムに維持したい場合もあります。こういった場合はイベントドリブンに近いデータ連携が求められます。

こういった場合の対処方法は：

• バッチ感覚を5分間隔などに縮めて、準リアルタイムに見せることでCData Drivers を使った構成を変えない

• Webhook などの機能を駆使してAPI コーディングで行う。もしくはデータ連携ツールでWebhook が使えるものを選ぶ

目的がわかれば、イベントドリブンかデータドリブンかわかる

データ連携の目的から、連携がイベントドリブンなのかデータドリブンなのかを考えることもできます。以下のようなキーワードでもOK です。

• 通知：イベント

• 複製：データ

• 分析：データ

まとめ

このようにCData Drivers は大変便利ですが、万能ではありません。どういった性質の連携を行うかを見定めたうえで、データドリブンであればCData Drivers をぜひご利用ください。

関連コンテンツ