by 疋田 圭介 | August 05, 2016

API の替わりにADO.NET を使う理由

Software as a Service (SaaS)として提供される Salesforce, やGoogleApps のようなCRM、グループウェア、ERP システムは とても便利、パワフル、かつユニークであり、会計、タスク管理、リード管理、その他の社内業務ニーズに的確に応えてくれます。 しかし、業務データはそれぞれのSaas の中に閉じているだけでなく、他の業務システムからアクセスすることが必要な場合が 多くあります。いえ、ほぼすべての業務アプリケーション・ツール同士はつながる必要があるのです。 そんなニーズに応えるべく多くのSaas にはREST, ODATA, JSON などのAPI (Application Programming Interface)モデルが 備わっており、外部ツールからデータにアクセスすることが可能です。個別には便利なAPI ですが、API モデルはシステム毎に 大幅に異なっており、API の利用者はエンジニアであれ、Citizen ユーザーであれ、それぞれのSaas 毎のAPI を習得したり、 データを受け入れる為に既存のアプリケーション・ツールの改修を行ったりする必要があります。

残念なことに、Saas、クラウド、オンプレのシステム同士が繋がることでデータをより効率的に利用できること、一つのシステムでの 処理から他のシステムでの処理を行うフローを作ることで大幅な効率化が行われることは、まだ多くの企業では実現されていません。 そしてメリットに気づいていても、「API 習得の負担や、既存のアプリケーション・ツールの改修の時間やコスト」から、データ連携が 後回しにされたり、実現されていないという実情があります。

そこで、その技術習得やシステムの改修コストを大幅に軽減できるツールがCData Software です。

CData ADO.NET Provider を通じて、開発者は広く使われているSalesforce, GoogleApps などの60を超えるデータソースに 対し、ADO.NET という単一の、かつ慣れ親しんだ規格でアクセスすることができます。SQL Server などのRDB を扱うのと同感覚で Saas データのAPI にアクセスるることが可能です。 また既存のシステムではすでにADO.NET のデータ規格を持つものが多く、それらのシステムでは改修なしにSaas データソースデータとの リアルタイムデータ接続を構築し、標準Transact-SQL でデータを扱うことができます。 さらに、ドキュメント作成負荷も少ないこと(テーブル形式のデータはそれ自体がドキュメントとして扱われます)や、Entity Framework のような人気のあるデータテクノロジーが利用できることもメリットです。

Entity Framework によって、開発者はデータアクセスから切り離されたアプリケーションのロジック部分に集中でき、 異なるデータソース間の既存コードやモデルを柔軟に再利用でき、パワフルなLINQ to Entitiesを利用できます。

確立されたADO.NET を単一API として利用するメリットを簡単に説明しました。 是非、30日 無償評価版 をお試しください!



 
 
ダウンロード