[enebular][salesforce] enebularでMail to Case（メール to ケース）みたいなことをする
今年のDreamforceでSalesforce.comのMarc Benioffさんがしきりに「Disruptive Innovation（破壊的イノベーション）」と言っていたのが印象的でした。
私はどちらかというと技術よりの人間なので大小のDisruptive Innovationを肌で感じてきました。
その結果、Disruptive Innovationを恐れるよりも自らDisruptive Innovationを起こすくらいでないと企業も個人も生き残れないという現実を見てきました。
先日リリースしたenebularは大か小か解りませんがDisruptive Innovationの可能性を秘めています。
例えば、これまで我々がメール/Web to Lead/Case/All Objectの要件の度に小規模な開発を行ってきたこと。
それをパターン化してWeb to X GearとかMailer Gearというモジュール製品を作ってきたこと。
すべて自ら破壊することを承知でenebularをリリースしました！
と、まあ、大げさな話はちょっと置いといて…
今回はenebularでMail to Case（メール to ケース）みたいなことをしながら基本的な使い方を説明します。
enebularはユーザ登録（無料）すると各ユーザに作業用のHerokuアプリが作成されます（数分かかる場合もありますのでお待ちください…）
以下のようにワークスペースが表示されたら早速http nodeを配置します。
ここで勘が良い人は「email nodeじゃなくてhttp node？」と思うかもですが、メール to Case（とか任意のオブジェクト）のユースケースって「問い合わせメールのSFDCへの取り込み」だけじゃないからです。
Mailer Gearを作成した時のユースケースも問い合わせメールの取り込みと言うよりは（もちろん問い合わせ取り込み機能もありましたが）受信メールの活動履歴への取り込みという地味だけど重要なケースでした。
つまりemail nodeのように一定間隔でメールを確認（imap同期）してしまうとSFDCへ連携したいメール以外も全て連携されてしまうので、SFDC連携したいメールだけをメーラやメールサーバのフィルタ機能等を利用して選別できるようにする方が賢明です。
Mailer GearはSFDCのメールサービスを使ってforce.comネイティブで開発しましたが、今回はメール受信をフックに任意のURLへデータを転送してくれるPostmarkというサービスを利用します。
まずはPostmarkにユーザ登録してください（月25,000通の送受信メールまで無料です）
登録が完了するとそのままサーバのセットアップを行います。
「Next Step」をクリック。
任意のサーバ名を入力して「Next Step」をクリック。
「Done! Noe add sender signature」をクリック。
今回はInbound Mailのみ利用するのでSender Signatureの設定はスルーしてサーバ一覧に移動。
サーバ一覧から先ほど作成したサーバを選択。
Inbound Addressを確認。以下のメールアドレスにメールを送るとこのサーバに送られます。
試しにメールを送ってActivityを開くと届くのがわかります。
ただし「Retry」という状態です。これはhook urlを指定していないからです。
hook urlは、このサーバにメールが届いたらメールの内容をJSON形式のデータに変換して転送するURLです。
そうです、ここでenebular側に作成するURLを設定するわけです。
では、enebularに戻って先ほど配置だけしたhttp nodeをダブルクリックしてMethodを「POST」に変更して以下のようにURLを作成します。
作成したURLを外部からのアクセスに正常に応えるためにはhttp response nodeを配置します。またデバッグ用のdebug nodeも配置して以下のように接続しDeployをクリックします。
続いて、以下の「Open」アイコンをクリックするとブラウザの別タブが開きます。
開いたタブのURLは”https://＜XXX-XXX-XXX＞.herokuapp.com/red”のようになってると思います。これが自分に割り当てられたアプリケーションのホストになりますので先ほど作成したURLは”https://＜XXX-XXX-XXX＞.herokuapp.com/red/inboundmail”というURLになります（＜XXX-XXX-XXX＞の部分は各自で変わります）
つまりPostmark側のhook urlに”https://＜XXX-XXX-XXX＞.herokuapp.com/red/inboundmail”を設定するとPostmarkにメールが届いたタイミングでメールの内容をJSONデータに変換して届けてくれます。
では、やってみましょう。
Postmarkのサーバを開いた状態（先ほどActivityを開いた状態）で以下をクリックしていきhook urlを設定する画面を開いて設定します。
ちなみにhook urlを入力すると以下のように「check」リンクが現れます。このリンクをクリックすると疎通テストができます。
疎通テストが成功するとenebular側のDebugにもテストデータが表示されます（Postmarkから送られてくるJSONデータの構造はドキュメントを確認してください）
疎通テストが成功したら実際にPostmarkにメールを送ってみます。メールアドレスは以下にあります。
実際にメールを送って再度PostmarkのActivity画面を見ていたら以下のようなプッシュ通知が表示されるので「Please refresh the page to see new records.」をクリック。
以下のようなグリーンなログが表示されればenebularへの転送も成功したことを表します。
enebularのDebug画面を見てみるとメール情報をJSONデータで受け取れてますね。
ここで立ち止まってenebularのストリームデータ処理を解説します。
このように外部や内部から発生したデータがnodeをつなぎ合わせたflowを流れていくのが何となく解ると思いますが、このメインデータは主に「msg.payload」というプロパティ（データの箱のようなもの）に入っていると思ってください。
つまり次のnodeに何か値を渡したいケースではmsg.payloadで渡すというのが基本になります。
では、今回のMail to Case（メール to ケース）の要件で考えると次は何をすべきでしょうか？
取引先責任者に関連付ける必要がなければSFDCにデータを投入するだけですが今回は複雑な方でいきましょう。
次はメールのFromアドレスから取引先責任者を特定します。
force nodeにクエリを投げるには上記基本通りmsg.payloadでSOQL文を渡せば良いです。
したがって先ほどPostmarkから受け取ったデータは後から何度も使えるように「別の箱」に退避しておく必要があります。
それはchange nodeを使います。
以下のようにchange nodeを使ってmsg.maildataというプロパティ（別の箱）にmsg.payload（今の箱）のメールデータを移します（この後、何度もPostmarkからデータを送って動作確認しますが、全て先ほど上記したPostmarkの疎通テストである「check」リンクを使用すると便利です）
これでmsg.payload（今の箱）からmsg.maildataというプロパティ（別の箱）にメールデータを移せたのですが、厳密に言うと移動ではなくコピーなのでDebugの内容は相変わらずですね。
次のSOQLを作るところでmsg.maildataにデータが存在することが解るので続けましょう。
今度は以下のようにfunction nodeを配置して以下のように設定します。
これでPostmarkからの疎通テストしてみると以下のようにDebug欄に生成されたSOQL文が表示されます。
次に作成したSOQLをSFDCに投げてみましょう。
でも、その前にデバッグに便利なPostmarkの疎通テストで試せるように、連携したいSFDC組織の取引先責任者に「support@postmarkapp.com」をメールアドレスとした新規レコードを作成しておきましょう。
では、force nodeを配置して連携したいSFDC組織のアカウントを登録します。
アカウントを登録したら、そのままforce nodeの設定をします。以下のようにOperationを「query」にします。
これで以下のように接続&Deployして実行してみるとDebugにSFDCからクエリ結果がJSONで返ります。
※ここ、本当はレコードが取得できない場合や複数レコード取得してしまう場合を考慮しないといけません。今回は話を簡単にするために割愛しますが要件によってSOQLにlimitを追加するとか、複数レコード取得された場合は配列0番目を必ず使うとか、複数レコード取得された場合やレコードが取得できなかった場合は何もしないでメールで通知するとか…まあ、要件次第です。
これでSFDCのCaseに投入するデータはすべて揃いました。
では投入用JSONデータを作成するfunction nodeを配置して以下のように設定します。
例のごとくDeployしてDebugでJSON的に問題ないか確認します。
問題ないようでしたら投入用のforce nodeを配置します。今度はOperationは「Create」でSobjectに「Case」を設定します。
これでDeployして実行してみるとDebugに「success: true」と出ました。
SFDC側のケースを確認したらデータが入ってます。
もちろん取引先責任者にも関連付いてます。
実際に送ったテストメールでも以下のような感じで成功です（先にテストメールのFromアドレスをメールアドレスとする取引先責任者を作っておくのを忘れずに）
念のため言っときますが今回は受信メールデータをSFDCのケースオブジェクトに投入するというSFDCのMail to Case（メール to ケース）機能に準えて説明したに過ぎません。
既にお分かりかと思いますがデータを投入するオブジェクトはケースだけではなくカスタムオブジェクトも含め任意のオブジェクトに投入できますし、Postmarkからのデータ転送でなく今回設置したPOSTエンドポイントにWebフォームからSubmitすればWeb to X（任意のオブジェクト）になります。
このように要件に合わせて非常に柔軟にflowを構築することが可能なのです（逆に言えば一目では何をすれば良いのか解り難いツールではあります）
今回、非常に長々と説明させていただきましたが、勘の良い方が色々なアイデアに発展できるように、あえて少し複雑な例を用いてヒントを与えられる機会を増やしたつもりです。
なんか思いついたらenebularは無料ですぐに始められるので試してみてください！
このエントリはSalesforce1 Advent Calendar 2014に参加してます。