2014-02-26

SalesforceとSWFの連携【机上の空論編】

さて、これまでApexからSWFと連携させてきましたが、

SalesforceとSWFの連携のユースケースについて自由気ままに考えてみます!

※今回はSWFについてあーだこーだ言う回です。特にまとまっていません。

SWFでシステムを実装したことないので机上の空論です。

ということで、ところどころ、おかしいところがあるかもしれませんが、ご容赦くださいm(_ _)m

 

1. Salesforce内部から外部Webサービスの利用

ApexからのHTTPコールアウトはガバナ制限があり、

1トランザクション当たりの長時間のコールアウトの対応が難しい。

※2014/02時点では1トランザクション当たりの合計時間が120秒以内の制限値。

 

そこで、長時間のコールアウトになる場合、つまり時間がかかるようなタスク処理をさせるには

HTTPリクエストに対する応答は即座に返し、タスク処理を非同期で実行するような仕組みが必要になる。

この非同期実行処理はSWFが適しており、

ApexからのHTTPリクエストはSWFに対してStartWorkflowExecutionを実行し、

処理を実行するDecider、Workerは処理を実行するサーバ側に立ててあげれば容易に実現できる。

非同期処理自体はSWF等のクラウドキューサービスがなくてもWorker上に実装できるが、

SWFを利用する方がスケールアウトしやすく再利用性が向上する。

 

ただし、タスク処理自体が同期実行でなければならない場合は、基本的にはSWFは適さない。

 

2. 外部WebサービスからSalesforceを利用する場合

外部WebサービスからSalesforceのデータを利用する場合は

a. Salesforceのデータを画面表示するような即時利用パターン

b. Salesforceのデータを別サーバDBに連携するパターン

c. 別サーバのデータをSalesforceに連携するパターン

の3パターンが考えられる。

 

a のような即時利用パターンではSWFのような非同期処理は向いていないので適用不可能。

この場合は素直にforce.com canvasとか使ってAPI使っでやるのが吉かと。

 

b では連携したいSalesforceレコードを、Salesforce側からSWFに投げてもらい

別サーバがWorkerとしてそのデータを受け取り、タスク処理(連携処理)を実行する方法が考えられる。

Salesforceではアウトバウンドメッセージという外部連携用の標準機能が存在するが、

疎結合のメリットを活かすのであれば、エンドポイントを共通化出来るSWFを利用した方法が良い気がする。

 

c では別サーバ側が作成・更新したいレコード情報をSWFに投げて、

そのデータをforce.comのApexスケジューラで拾わせてApexクラス側で作成・更新処理を行う。

単なるデータ同期だけでなく、Webフォームで入力されたデータをSWFを介して

Workerに処理させることができるので、連携先プラットフォームに変更があっても

送信元プログラムの変更がないことが利点。

 

Salesforceへの連携をする上でSWFを利用する共通のメリットとしては、APIコール数を消費しないということ。

デメリットとしてはSalesforceをWorkerやDeciderとして動作させるためにはApexスケジューラを利用する必要があり、

一日あたりのスケジュール実行数等の制限値・ガバナを考慮する必要があるということ。

 

また、cのパターンでWebフォームからの連携を考える場合、エラー時は同期実行、つまり即時でエラーを

エンドユーザに知らせる必要があるので非同期になるSWFでは適していない。

エラーハンドリングをWeb側で独自で行ってしまうと、

入力規則等のSalesforceのカスタマイザブルなビジネスロジックの構築というメリットを損ねてしまう上に

バリデーション系はモデルに実装すべきというMVCモデルの理想からも離れてしまう。

 

また、経験的にAPIコール数も上限を越えるケースがあまり無く、

上限もオプション(追加料金)である程度解決できたりするから

2のパターンにおけるメリットは全体的に微妙かな~とも思ったり。

 

 

結局のところ、疎結合・非同期処理と密結合・同期処理という2つの相反する特性を把握した上で

SWFを利用するか従来型のAPI連携をするかを判断をすべきかと。

密結合なシステムでも比較的小さなシステムであればそこまで大きな問題にはならない気がする。

一番大切なのはちゃんと動くシステム。その次に保守性。って感じ?

 

スケールアウトと再利用性は比較的大きいシステムでこそ大きな力を発揮できるものなのかな~思う。

 

あと、SWFの基本概念を学んだ印象としては、

「疎結合・非同期なシステムを作るにはとてもよいサービス」である一方で

「AWSの中では比較的学習コストが高く、疎結合ワークフローが故に実装時の考慮事項が多い」

というデメリットも感じたので、ここまで書いて何だけど、なかなか実戦投入は難しそう…。

このエントリーをはてなブックマークに追加