API とAPI はそのままではデータ連携できませんよという話はよく理解されていないので、API ってどうやって連携するのかという話をパターン分けしてみました。
#概要
少し誤解を生みかねない言い方ですが、あるエンジニアが上手く表現してました。
"API は基本的ににメス。メスとメスはくっつかない"
- API は基本的には、リクエストを出してもらうのを待っている状態です。Webhook でもない限り勝手にデータを送ってきたりはしません。
こういった事情で、API のデータを連携するには何らかのアプリケーション/ツールでAPI を呼び出し、受け取ったデータを変換して、データの連携先に流し込む必要があります。取得（Extract）、変換（Transfer）、ロード（Load）というETL のプロセスのことですね。
「そうは言っても、オンプレのアプリケーションのときはETL を使わなくてもアプリケーション側で連携を実装できてた。」という方がいます。それはオンプレのアプリケーション側でデータの取得（ODBC/JDBC）、変換（SQL を駆使して）という処理を実装して、アプリケーションにロードしていた訳です。
API の問題：
- API は規格がバラバラです。REST はあくまでアーキテクチャのスタイルであって、プロトコルではありません。JSON やらXML を受け取ったからといって、アプリケーションでそのまま使える訳ではなく、スキーマ定義や変換が必要です。
- SaaS （クラウドサービス）にはデータ連携機能は無い（ものがほとんど）
SaaS 間連携では、外にデータ連携を行うアプリケーション/ツールが必要かつ、連携の難易度はRDB やファイル連携のと比べ格段に複雑です。
#Web API をETL/EAI ツールで連携
多くのユーザーの方がイメージするデータ連携。
ETL はSaaS であれ、DB であれ、CSV などのファイルであれ対応しているものは何でもデータ連携してしまいます。ジョーカーみたいなやつです。連携相手がSaaS であれ、ファイルであれ、アプリケーションであれ、なんでも繋ぎます。取得（Extract）、変換（Transfer）、ロード（Load）というプロセスを全部やってしまう訳ですので当然です。
問題は、ETL ツール側ではそれぞれのデータソースのサポートを実装しないといけないという点。
CData Drivers はETL ツールに実装されているJDBC/ODBC といった標準インターフェースに100近いWeb API をラップしています。
ETL 連携の例：
ASTERIA WARP にApache Cassandra データ連携
Infromatica でGoogle BigQuery データ連携
Talend でCybozu kintone データ連携
SSIS 向けの90種類を超えるコンポーネント
Magic xpi でMarketo データ連携
Waha!Transformer でDynamics365 にデータ連携
RACCOON でNetSuite データ連携
#アプリケーション/ツールからの直接連携
API を叩くコードを直接アプリケーションやツールから書いてしまうパターンです。この場合は、ミドルウェアなどが必要ないので、シンプルです。パッケージアプリケーションなどでAPI コーディングができない場合、もしくはカスタムアプリケーションでもAPI コーディングを避けたい場合は、CData などのライブラリを使うことができます。
CData では、JDBC、ADO.NET、ODBC などのライブラリを提供しています。
API 連携部分をコーディングするかサードパーティライブラリにしてしまうかの判断は慎重に。
- データの量や構造として、ライブラリからSQL たたくことは正しいのか？許容できるのか？
- コーディングする際のコスト（含むメンテコスト）
- サードパーティロックインやブラックボックス化のデメリット
IDE、BI、DWH、Office ツールからのSaaS 連携の例：
EntityFramework6 からDynamoDB データ連携アプリを開発
NetBeans でSalesforce データ連携アプリを開発
PowerBI でMoneyForward データをビジュアライズ
Tableau でkintone データをビジュアライズ
Excel でSalesforce データをCRUD
Access リンクテーブルでGoogle Sheets データを更新
#中継アプリケーションを使ったSaaS 間連携
前述の通り、SaaS 間の連携には、中継ツールが必要です。
ETL での連携も、このカテゴリに入れなおしていいですね。
近頃はAWS Lambda やAzureFunctions などのサーバーレスなFaaS も出てきてますので大変便利です。
どのツールを選ぶのかの注意点を上げると：
- ETL ツールはデータソース対応が充実しているか？ そしてコストが高めです。
- FaaS は大変便利ですが、トランザクションなどまでコーディングするとかなり大変。データ連携の種類でもミッションクリティカルなどのSOA的なものは正直不向きです。分析、通知、レコメンドなどのSOE 的なものはコストが低く、簡単に構築ができてスケーラブルなFaaS が断然お勧めです。
CData の部品は、ここでも接続を標準化するために利用できます。
今後FaaS やクラウドETL などでの活用も記事にしていきます。
中間サーバーやFaaS を使ったSaaS 間連携の例：
C#：Salesforce-kintone のデータ同期
Java：Salesforce-kintone のデータ同期
Excel でSalesforce-MoneyForward フロー
Lambda+PyODBC+CData ODBC Driver でTwitter データ連携
AzureFunctions でGoogle Home-SharePoint 連携
#SaaS に連携機能内包
SaaS 間連携の行きつく先は、それぞれのSaaS が多くのユーザーが連携したいSaaS への連携をサービス内で提供する琴だと思います。
それでもクラウドサービスのユーザーとしては、外部ツールを使わずにデータ連携ができることがUX としてはベストと考えるでしょう。すでに一部のクラウドサービスでは他のクラウドサービスのWeb API を使って、直接他のサービスを参照したり書き込んだりする機能を実装している例も出てきています。クラウドサービス内でのSNS と連携、カレンダー機能のGoogle やOffice 365 との同期、Box などのクラウドストレージ同期、CRM とERP・会計サービス連携などが例として挙げられます。今後このような流れは大きく加速すると考えられます。
SaaS ベンダーの方々にもCData はドライバーを組み込みで提供しています。