by 疋田 圭介 | April 29, 2018

SaaS ベンダー向け"Salesforce 連携ガイド"

「ウチのSaaS をSalesforce と連携させたい」

SaaS ベンダーとディスカッションをする際に、「ウチのSaaS のユーザーはSalesforce と連携したい」というニーズをよく聞くようになりました。API 連携・API エコシステム構築が、「API を出して終わり」から「どうやって能動的にAPI 活用やエコシステム構築を促すか?」へとフェーズを移していることを感じます。

E メールプラットフォーム、マーケティングオートメーション、請求書発行などマーケティング・営業関連のサービスであれば、Salesforce への顧客マスターデータなどの同期ニーズは大きいでしょう。同じようにDynamics 365 (CRM)、kintone、Office 365 なども連携先として頻繁に聞かれます。

この記事では、あるSaaS から代表としてSalesforce へのデータ連携をテーマに、連携をユーザーが実装する場合とSaaS ベンダー側が内包して提供する形に分けてそのメリット・デメリットを説明します。

1. ユーザーが実装するパターン

Web API を公開することで、ユーザーが好きな方法でSaaS に連携することを可能にしています。SaaS ベンダーとしては、どのようなパターンでユーザーが連携を実装しているのかを知ることも重要です。

1.1 中継サーバーを構築して連携

一般的かつ柔軟性が一番高いSaaS 間連携が、ユーザーが双方のAPI を使って同期アプリを開発するパターンです。

この場合、ユーザーが当該SaaS およびSalesforce (もしくは他の同期先SaaS)のAPI を習得し、API コールの出し方、取得した双方のデータの処理やマッピング、どういった感覚で起動するかなどのジョブ管理をコーディングにより実装します。いくつかのマスターテーブルやトランザクションデータを同期するのであれば、小規模かつシンプルなアプリケーションでの同期が可能です。

例:富士通エフサス様 SharePoint - Dynamics CRM 連携

1.2 FaaS を使って連携を実装

同じことをFaaS (Function as a Service)を活用してサーバーレスアーキテクチャで組むことも可能です。SaaS 間の単純同期などのジョブにはLambda やAzureFunctions などのFaaS は大変便利です。サーバー構築が不要であり、開発以外の運用コストを一層さげることができるでしょう。

SharePointとAzure Functionsを組み合わせた マルチクラウドなサーバーレスアーキテクチャの展開方法 Japan share point group 勉強会

Web API に慣れたエンジニアが社内に確保できていれば、この中継サーバーを利用してシンプルにAPI を扱う方法は最もフレキシブルな方法です。また、当該SaaS およびSalesforce の双方の導入を手掛けるベンダーにリーチできる場合でもこの中間サーバーの開発が可能でしょう。

SaaS ベンダーがJava、JavaScript、C#、Python などのSDK、JDBC/ODBC/ADO.NET などのデータドライバーを提供すれば、ユーザーによる連携実装のハードルを下げることができます。CData Software では、貴社のSaaS 向けのデータドライバー(JDBC/ODBC/ADO.NET)の提供が可能です。カスタムドライバー開発を参照してください。

1.3 ETL を使った連携

ETL ツールの利用により、さらにSaaS 間連携を効率的に行うことが可能です。ETL の利点は、ノンコーディングであること(ビジュアルなデータ処理やジョブフロー作成)、データ連携に必要な多様な機能があげられます。

貴社SaaS は顧客が利用しているETL ツールで対応されていますか?もし対応されていない場合でも、CData がSaaS のAPI をDriver 化することで、多様なETL ツールからリアルタイムで該当SaaS に連携することが可能です。顧客が使っているETL には、汎用のJDBC やODBC の接続口があります。CData Drivers はJDBC やODBC の仕様に準拠しているため、汎用のDB としてSaaS API への連携を実現します。簡単に言えば、CData Drivers はどのETL ツールでもアダプタ/コネクタとして機能します。接続が可能なだけでなく、ビジュアルで作成したデータ処理フローでは、裏ではSQL が自動生成されているため、そのままクエリをSaaS API にパースすることができます。

1.4 OData オブジェクトで直接連携

間に中継アプリを含まない連携方法もあります。Salesforce やDynamics CRM には、外部オブジェクトとしてOData 形式のAPI を直接同期できる機能があります。あまり日本でメジャーな仕様にはなっていませんが、OData 形式のAPI であれば、このような連携が可能になります。有名なところでは、SAP S/4HANA Cloud、Dynamics 365 があげられます。受け手側でOData オブジェクトを受け付ける仕様になっているものは、前述のSalesforce、Dynamics のほかGoogle Spreadsheet、SharePoint、Tableau やPowerBI などのBI ツール、機械学習プラットフォームのAzure Machine Learning などがあります。

API Serverを使ってコードを書かずに外部のDBのデータをsalesforce側に連携する

ただし、外部オブジェクト連携は、1つのオブジェクトになります。例えば、SaaS の顧客アカウント情報をSalesforce に同期したい場合でも、新しいオブジェクトとしてSalesforce 内にデータを同期しておくことは可能ですが、Salesforce のAccount やLead などの既存項目にマッピングできる訳ではありません。既存項目へのマッピングを含む同期を行う場合には、別の方法で行う必要があります。

2. SaaS ベンダーによる連携実装のニーズ

これまで、1つのSaaS をSalesforce にデータ連携するための方法をいくつか紹介してきました。Web API を扱える技術者がいればフレキシブルに実装できる自社開発の中間サーバー、その変形としてのFaaS でのサーバーレス連携、既存のETL ツールを使ったノンコーディングな連携、簡易的だが手間のかからないOData オブジェクト連携などそれぞれメリットがあります。ただし、複雑な連携ならまだしもマスター連携のような単純なテーブル対テーブルの連携やトランザクションデータの移行など、「決まったパターン」が存在します。ユーザーの本音は「決まったパターンの連携は、SaaS 側で機能として対応してほしい。」というところではないでしょうか?

ここからは、ユーザーではなく、SaaS ベンダー側がSalesforce などの他のSaaS への連携を実装するパターンを見ていきます。

2.1 SaaS にETL を内包し、連携を機能として提供

SaaS ベンダーがETL ツールをOEM 利用して、連携機能を提供する方法があります。あらかじめパターン化した連携メニューを顧客が選択するだけの場合がふさわしいでしょう。この場合、顧客から何らかの方法でSalesforce に連携するための認証情報(ID/Pass/Security Token、もしくはOAuth 2.0)をSaaS UI から入力してもらい、ETL に流す仕組みを実装するだけであとは決められた連携パターンをSaaS 側にホストされたETL が行います。

ETL はある種、データ連携では完成された製品であり、構築の手間がかからないのがメリットです。ただし、顧客がカスタムオブジェクトやフィールドを使っている場合には、どの項目をどこにマッピングするかをカスタムで設定する必要があります。ETL 側にAPI でマッピングを調整する機能があれば、SaaS UI から裏のETL のマッピングを動かすような実装が必要でしょう。もしくは、カスタム項目は、UI ではなく依頼に基づいてカスタム設定をSaaS 側のエンジニアが行う形でもいいでしょう。顧客毎にコンテナを立ち上げて、顧客にETL ツールを操作させるというやり方も考えられます。

2.2 SaaS 側でデータ連携モジュールを内包

もし、「SaaS UI からのカスタムマッピング処理をユーザーが行う」というニーズが高い場合には、SaaS 側でカスタム連携モジュールを自社開発することが適切でしょう。この場合、データ連携機能である、取得(Extract)、加工(Transfer)、ジョブ管理(Load)のすべてを自社で実装する必要があります。ただし、顧客がUI からシームレスにカスタムマッピング処理を行うことができるというUX は大きなメリットです。

CData Drivers のOEM による連携機能内包化のサポート

CData Drivers をOEM して連携モジュールに組み込むことで、連携機能実装の開発効率を上げ、コストを抑えることが可能です。CData Drivers を組み込むことで、データ取得、データ処理の部分をCData Drivers + 標準SQL で行うことが可能になります。接続するSaaS を選択して認証情報を入力するUI、取得したオブジェクト間のマッピングを指定し、対応するSQL を発行する仕組みの2点を実装すれば、CData Drivers が対応するデータソースすべてを同じUIおよびSQL で処理することが可能になります。1対1 のデータ連携構築費用程度で数十のSaaS への連携が開発可能です。

CData Drivers のOEM 利用はDriver OEM ページ を参照してください。



 
 
ダウンロード