Salesforce

2014年12月24日 (水)

祝 Salesforceハッカソン入賞

ども、22日は有給もらって4連休でした。(^^v
久しぶりに休日まったくPCを開かずに遊び倒していたので、気づいてませんでしたが、その間にSalesforce1のAdvent Calendarにこんな記事が!!!

プログラミングコンテストで良い結果を出すために重要な(プログラム以外の)3つのこと

はい、私このハッカソンでHeroku部門の3位いただきました。
そのエントリー投稿はこちら

http://challengepost.com/software/salesforce-vs-heroku


で、先の記事にあるプログラミングコンテストで大事な3つのことですが、このアプリなんと全部外してます!!!(--

ていうかこの記事僕のために書かれたような気がするなぁ。。。(--
なんだか申し訳ない。。。


以下、懺悔です。


★ 1. 主催者側のニーズを読む

あいすいません。m(_ _)m

ビジネスアプリと言うお題があることは当日に知りましたが、それをガン無視してゲームを作りました。

何を作るかは前日の夜に考えたんですが、その時点では何でも良いと思ってたんですよね。。。

当日ビジネスアプリ縛りがあることを知りましたが、別のネタを考えるのも面倒だったのでそれをそのまま出しちゃいました。


★ 2. 簡潔かつ明確に、かつ視覚に訴える説明をする

今回のハッキングチャレンジでも12の入賞チームのうち、実に11チームが紹介ビデオを作成しています。(こちらで推奨したというのもありますが)

あいすいません。m(_ _)m

ビデオを作らなかった唯一の入賞者が僕です。。。

ていうか、ビデオを作ろうとか1ミリも考えませんでしたよ。。。(--
フタを開けてみたらほとんどの参加者がビデオも登録してあってかなりビックリしました。

こうしたハッカソンイベントではビデオが必須になっていることもあるので、以前には作ったこともあるんですが、正直プログラム書くよりも100倍面倒で仕上がりも残念な感じにしかならないので、あんまり気が進まないんですよね。。。

本当に入賞はなかやま絵のおかげだと思います。それが無ければ箸にも棒にもかからなかったんじゃないかと。。。(^^;;;

ちょっと修行します。


★ 3. ビルド手順を明記し、デモ環境を用意する


あいすいません。m(_ _)m

わりとギリギリまで作ってたのでビルド手順書くの忘れました。。。(--

しかもローカルではSBTだけあればRedisはなくても動くように作っていたつもりが、提出時点のコードはバグっていてローカルでもRedisが必須になっていたという。。。(--

審査では対象の全アプリを実際にビルドしたそうですが、よくこれのビルドを通せたものです。

一応現在はビルド方法を追記し、Redis無しでも動くように修正しました。


いや本当に、このアプリを推してくれた審査員の方々の努力と忍耐に心よりお礼申し上げます。


★ その他感想など


参加作品を見ると実際にサービス化することを目的としたアプリが思った以上に多いことにも驚きました。

僕の場合、完全にこのハッカソンのためだけに作ったジョークアプリなのでなんというかもう全然本気度が違う感じ。(^^;;;

ドメインもなんか取ろうかと考えはしましたが、キャラクタをSalesforceとHerokuにすることに方針転換した後に「salesforce-vs.herokuapp.com」というアプリ名が取れたところで、もうこれでいいやと思っちゃっいました。(というわけでこのアプリのランニング費用は1円もかかってません。本当にすみません。。。m(_ _)m)

ただし、アプリ自体は使い捨てるつもりでもその中で使っている個々の要素技術は実際に使い物になるかどうかの評価をしつつ、再利用する前提で作っています

今回の場合テーマは以下のものがありました。

  • WebSocketのさらなる可能性の追求
  • CodeMirror(HTML5のテキストエディタコンポーネント)の評価
  • ブラウザ上での複数人の同時コーディングの可能性評価(コードレビュー的な)
  • ブラウザ上で書いたものがその場で動く簡易インタープリタの実験
  • 実践的なCSS3アニメーションの実験


結論としてCodeMirrorは思った以上に使いやすかったですし、changeイベントを逐一相手に送りつけて、相手側のブラウザ上で自分がコードを書いている様を再現するという試みも成功したのでそれなりに満足です。(^^v

これらが将来的にどういう形で活かされるのか、あるいは闇に消えるのかはまだまったくの未定ですが。。。(^^;


しかし、このようなちょっと作ってはみたいけれど、いまいちモチベーションが無いみたいな場合にハッカソンを目標設定のために使うというのは割とアリな手段だと思います。(賞金もらえるかもしれませんし)


今回のアプリに何かしら機能を足していくということはもうあまり考えていませんが、同じようなプログラミング要素を使ったゲームみたいなものはこの先も何か作るかもしれません。(イメージ的にはIncredible MachineやElectric Boxのもっとプログラミング要素の強いモノという感じ。Incredible Machineはもはや入手できないと思うけど、どこかで再販して欲しい。。。。)

□□□□
以上、祝ってタイトルに付けたわりには謝ってばかりの謎エントリでした。

推定最後です。良いお年を。(^^)/

2014年6月10日 (火)

S1dcmaxでWebSocketの話をしてきた

ども、小西です。

昨日6月9日にビルボードライブ東京で行われたSalesforce1 Developers Community MAXというイベントでWebSocketの話をしてきました。

会場名をもう一回言うけどビルボードライブ東京だよ!Googleのインドアビューで見るとこんなだよ!!

なんでこんなところでテッキーな話を。。。と思ったけど見る側にしたら机もあって良かったのかも。(^^;

発表資料はこれ。

http://shunjikonishi.github.io/slides/websocket/index.html


持ち時間に対してとにかく内容を詰め込んだので置き去りにされた人も多かったかも。。。

あいすいません。m(_ _)m


資料はそれだけ見ればわかるように作ったつもりなので、気になる人は見てくだされ。
プレゼン中に口頭でのみ説明した内容もだいたい文章で入ってます。

春頃からこのブログでも何度もWebSocketの話題をとりあげていて、言いたいこともたくさんあったんだけど、だいたいこれで全部吐き出せたかな。(^^;


セキュリティの話とかWebSocketをAjaxの代替として使う話とかは他ではあまり見かけたことがない内容で個人的には結構満足してるけど、果たして一般受けするかどうかは謎。。。(^^;

以下今回のイベントでの個人的なトピックです。


★Happy HourにまさかのQuizar

今回Salesforceの岡本さんのご厚意(?)で、Happy Hourの余興で3月に作ったQuizarによるクイズゲームが行われました。優勝賞品はプレステ4!!

多分50人くらいが参加してたんじゃないかな?ぶっちゃけこれまでにそんな人数での実践をしたことはなかったんだけど、まぁ普通に動いて良かった。(^^;

ちなみにこれ元々は参加人数は最大50人に制限してたのを、200人まで参加可能なように会場でその場で修正しました。(^^;

作った当時はどの程度の同時接続を捌けるのかに関してあまり確信がなかったけど、その後にやったC10Kのテストの感触から言うとDynoを増やせば1000人とかでも普通に捌けるとは思います。(これが数万、数十万のオーダまでいけるようであれば、テレビとかでも使えそうだけどさすがにそれは自信ないなぁ。。。クライアントへのpushをもうちょっと賢くすればできるかもしれないけど。)

まぁ機会(と度胸)があれば試してみてください。(^^;
何にせよ会場の皆さんにWebSocketアプリを体感してもらえたのは良かったと思います。岡本さんありがとうございました。

Quizarは特に宣伝しているわけでもなく、この先大幅な機能追加が行われることもないと思うけど、ひっそりと営業中なので勉強会等をやる機会のある人は使ってみてください。
ご意見、プルリク等は歓迎します。(^^;

スターがいっぱいつくと開発/運営方針とかも変わるかもよ?(^^;


★@i556 HackChallenge癒しアプリケーション部門で優勝

同僚の@i556が見事優勝して10万円GET!!!

おめでとう!!!
そしてごちそうさま!(と、先に言ってみる)

作ったアプリはタスクを癒し系アイコン(タスクの達成度が高いほど癒し度アップ)でカレンダー上に表示してユーザーのモチベーションを上げるというもの(で、あってるよね?)


優勝者発表の前から猫には勝てると思っていたよ。
本当におめでとう。

ちなみにHeroku賞はまさかの該当者なし。。。
もうちょっと早くにお題出しとけよ。。。(--

自分のプレゼンでテンぱっててそれどころじゃなかったんだけど俺もなんか出しておけば良かった。(--


★REVEAL.jsの話

ちょろっと聞かれたけど、今回プレゼンに使ったREVEAL.js。はっきり言ってイケてる。
ていうか、プログラマが使うプレゼンツールとしては最強なんじゃなかろうか。
なにせ、基本マークダウンだけでプレゼンが作れて足りないところはHTMLとJavaScriptでどうにでもできるので。

興味のある人はサンプルサイトを覗いてみると良いと思う。
ストーンズの50年とかマジかっこよくてお勧め。

とりあえず試してみたい人は

https://github.com/shunjikonishi/slides

をcloneしてgrunt起動すれば動きます。
基本content.mdだけ編集すれば良いのでドキュメントとかまったく読まなくてもそれなりに使えると思う。

今回使ったプログラム要素は

  • プレゼンの残り時間とスライド一枚当たりの時間を画面に表示
  • iframeでアプリ埋め込み
  • お絵描きのWebSocketサンプル埋め込み
  • setIntervalのデモ
  • js-sequence-diagramsの埋め込み(ただしブラウザのSVGのレンダリングにバグがあるのか表示が安定しなかったため本番ではイメージに差し替え)

など。
今朝になってトップにTwitterとFacebookのソーシャルボタンも追加してみた。(^^;

これ本当に何でもできるのでTwitterのTLを埋め込むとか、アイデア次第で色々なことができそう。
WebSocketを使えばそれこそ聴衆参加型のプレゼンもできるはず。
なんか思いついたらそのうちどこかでチャレンジしてみたい(^^;

2013年12月11日 (水)

SalesforceとHeroku Postgresの同期

こんにちは。このエントリはSalesforce Advent Calendarの11日目です。


ノリでSalesforce Advent Calendarに手を挙げてしまいましたが、僕自身はSalesforceでアプリを作ったことは一度もありませんVisualForceは1時間で挫折しました。

そんな人間がSalesforceのAdvent Calendarで何を語ろうと言うのかというと、SOAP APIのJavaラッパーを作ったりもしているので、それを使ったSalesforceと外部RDBMSとの同期連携について書いてみようと思います。

※タイトルは半分釣りでHeroku Postgresと書いていますが他のRDBでも多分動きます。


★ところで Heroku Connect

本題に入る前にSalesforceとHeroku Postgresの同期と言えば先日のDreamForceでHeroku Connectが発表されました。

http://blogjp.sforce.com/2013/11/heroku1-.html

今のところ予告編だけで実際に試せるのは来年以降になるらしいですが、某エバンジェリストに聞いたところでは、これはSalesforce上のオブジェクトと同じ構造のテーブルをPostgres上に作成して双方向に同期するもののようです。

ちなみにガバナ制限は受けない某エバンジェリストは力強く言っていましたが、別の筋からはそんなの聞いてないという話もあり、真偽は定かではありません。(^^;

素晴らしいんですが、この枠組みだとまずSalesforceアプリありきなので、既存のHerokuアプリのデータをSalesforceに取り込みたい場合は使いにくいかもしれません。

今時のクラウドデータベースではストレージ容量は十分過ぎる程にあるので、アプリで使用するテーブルとSalesforceと同期するテーブルはきっぱり分離してPostgres内でトリガーで同期するというアプローチはアリだと思いますが、自前のテーブルの方はともかく自動生成される同期テーブルにトリガーをつけて良いかどうかは謎ですね。。。
それにこのやり方で完全双方向は無限ループの回避がやっかいかな?

いずれにせよ使えるようになったら試してみるつもりなのでこの話はまたいずれ。



★ところで flectSalesforce

ちょいちょいあるよー、とはこのブログでも言っていたのですがちゃんと紹介したことはなかったと思うので改めて。

http://oss.flect.co.jp/libs/ja/flectSalesforce.html

flectSalesforceはSalesforceのSOAP APIのJavaフルスクラッチ実装です。

僕は元々某所でSOAPのかなり初期からSOAPクライアント/サーバーを作ったりもしていたのでSOAPには色々と言いたいことがあるんですが、それはまぁ良いでしょう。

とにかくAxisは使いたくなかったので自分で作ることにしたんですが多分正解でした。SalesforceのSOAP実装にも色々と突っ込み所があるんですが、これまた誰の共感も得られそうにないので墓まで持っていきます。(^^;

□□□□
前置きが長くなりましたが。。。
そんなこんなでこれはSalesforce APIの実装のひとつです。必要なものから作っているので全部のメソッドを実装しているわけではありませんが、オブジェクトの更新/削除など主要なものは網羅しています。(describeLayoutやdescribeTabsみたいなメソッドを実装しても誰も使うことないでしょうしね)

元々は社内で使うことしか想定していなかったのでコメントも日本語です。(^^;
(必要最低限しか書いてませんが)

既存のAPIラッパーとの相違点としては単純なAPIのラッパーに留まらず、独自のユーティリティインターフェースを備えている点があげられると思います。

  • SQLライクなINSERT, UPDATE, DELETE構文によるデータ更新
  • Fixtureによるテストデータの更新、削除
  • RDBからのSELECT結果をSalesforceに取り込み
  • SalesforceからのSELECT結果をRDBに取り込み


などなど。
後ろの二つがここから紹介する内容です。
APIの使い方自体は

http://flect-salesforce-sample.herokuapp.com/

でサンプル付きで説明しているのでここでは主に処理の枠組みについて説明します。


★RDBからのSELECT結果をSalesforceに取り込み

http://flect-salesforce-sample.herokuapp.com/sqlsync

RDBからSELECTした結果でCSVを作り、それをBulk APIで投入します。

特徴的なのはSELECTしたフィールドとSaleforceオブジェクトのフィールドの対応をSELECT文内のエイリアスで指定するという点です。

 

SELECT COL1 as Col1__c,
       COL2 as Col2__c
  FROM TABLE1
 WHERE ...

 

この仕様によりJoinや関数の使用などDBMSのサポートするすべてのSQL構文を駆使してSELECT文を書くことができます。

同期処理として運用する場合はWHERE句に更新日付で結果を絞る条件を付加して定期的に実行します。(それに特化したアプリもあります。)
項目に外部IDがあればレコードの更新方法はUPSERTになります。


ちなみにBulkAPIには1万行制限がありますがSELECT結果が1万行を超える場合は内部的にファイル分割されるので、1万行を越えても問題なくデータを取り込むことができます。


★ SalesforceからのSELECT結果をRDBに取り込み

http://flect-salesforce-sample.herokuapp.com/sobjectsync

これもBulkでやりたかったんですが、クエリ自体はSOAP APIで投げています。
何故ならBulkクエリでは参照フィールド(CreatedBy.Nameとか)が取れないからです。。。


使えねー。。。(--

サブクエリは仕方がないと思うけど、参照フィールドくらいはBulkでも取らせて欲しいよ。。。

□□□□

仕組みとしては要するにSalesforceに対してクエリを実行した結果をぐるぐる回しながら指定のキーでUPDATE文を実行し、結果が0件だったらINSERT文を実行しているだけです。
QueryMoreは内部的に処理されるので、結果セットが大きい場合も問題なく実行できます。

こちらの方ではSalesforceオブジェクトのフィールドとRDBのテーブルカラムを一つずつ指定する形式をとっています。

なのでSOQLの関数は使用できません。(あるんだっけ?(^^;;; )

その代わりSELECTした結果をJavaで加工した結果をマッピングすることができます。

 

request.addFunctionMapping("NAME", new SObjectSyncRequest.Function() {
    @Override
    public Object evaluate(SObject obj) {
        String fn = obj.getString("FirstName__c");
        String ln = obj.getString("LastName__c");
        return ln + fn;
    }
});

 

引数のSObjectから値を取得してそれをごにょごにょと演算をした結果をreturnすればOK。データ移行の自由度はむしろこっちの方が高いです。


実行結果の詳細なハンドリングを行いたい場合はListenerクラスを組み込むことで個別にエラーとなったオブジェクトをハンドルすることができます。

□□□□
こんな感じで雰囲気は伝わったでしょうか?
Heroku Connectが完全自動で固定的なのに対して、こちらの方は自由度高くプログラムに組み込めるのが特徴と言えると思います。

実際のところ、これらの機能は社内要件から実装したものであって公開して誰でも使えるようにしているのは、もののついでという感はあるのですが。。。(^^;

ご意見、ご要望等あればGithubのIssue、Twitter等に書いてくれれば可能な範囲で対応するので、定常的な同期に限らずワンショットのデータ移行の場合などでも思いだしたら使ってみてくだされ。(^^)/

2013年11月28日 (木)

続・ApexからGoogle Calendarを操作する

どもども。先週の記事「ApexからGoogle Calendarを操作する」の続きです。

といっても厳密には続いてないんですが。。。(^^;

 

★Google Data API Toolkitのお話

さて、先週の記事ではぶつぶつ文句を言いながらも、「Toolkitで一通りカレンダーいじれるんじゃないの?」という結論に達しました。

しかし、今週になってやっぱり使うのを止めました。(--

イベント作成時に使用するオブジェクトが何故かSalesforceのEventオブジェクトでなんかビミョーという話は前回さんざんしましたが、実際のところはタイトル、日時、場所、説明さえ設定できれば良かったのでそれで事足りるはずだったんです。

なのに、実際に試してみると何故か場所が設定されない。。。

あれ、なんでだ?自分のコードではちゃんとEvent#Locationに値を設定してるし。。。

。。。

。。。て、CalendarService#insertEventsで引数に渡したLocationがコピーされてねー

そらあかんわ。。。(--

 

□□□□

さて、どうしたものか?

直接修正するなら1行で直せる程度のものですが、それも気が進まない。

とりあえず元のリポジトリを探してみたところ。。。

https://code.google.com/p/apex-google-data/

うーん、もう3年近くメンテされた形跡が無い。。。

その間にAPIもXMLベースのV2からRESTベースのV3に変わっているわけで、これはもうこの先も放置なんだろうなぁ。。。(--

 

★V3 APIの使用を検討してみる

さてさて、ソースまるごとフォークして自分でメンテすることも考えましたが、それやろうとすると直したいところが多すぎる。(--

それに今は面倒なXMLを使わなくてもお手軽にRESTで実行できるV3 APIがあるんだよ!

ということでとりあえずV3のドキュメントを読んでみることにしました。

https://developers.google.com/google-apps/calendar/

うん、やっぱりReference見ただけでもV2よりもはるかに簡単に使えそう。それにDeprecation Policy見ると旧APIは2015年4月までは使えるけど、そっから先は知らん!と書いてるようにも思えるしこれはやっぱりどうでもV3を使うべきでしょう。

 

★Service Account認証

とりあえずApex用のV3ライブラリを探してみるけど、どうも無いっぽい。まぁ「Salesforce Google API」みたいなワードで検索すると一撃でSalesforce公式(?)っぽいToolkitのページが見つかるからその先に踏み込む人もあんまりいないんだろう。。。2015年4月以降をどうやって乗り切るつもりかは知らないけど。。。(--

V3 APIをざっと眺めるかぎり少なくともAPI本体のREST部分はものすごくシンプルなので自分で作るとしてもそんなにたいしたことはなさそう。

問題は認証部分。

V3 APIではClientLoginは廃止されたので今までのように気軽に個人のユーザーアカウントとパスワードでログインしてAPIをたたくことはできない。

そうはいってもサーバーアプリの場合ユーザーとは無関係の固定のアカウントでAPIを叩きたい場合も多い訳で、そういう場合はService Account認証というのを使うらしい。

https://developers.google.com/accounts/docs/OAuth2ServiceAccount

これは連携用のアプリケーションを登録して、そこで発行されたClientIDとPrivateKeyを使用して認証するという方法らしい。

下に詳細な実行手順が書かれているけど要するに

  • JSONで認証用の文字列(JWTというらしい)を組み立てて、
  • Base64でエンコードして、
  • 電子署名を追加して、
  • Http POSTで投げる

とすれば良いらしい。(どうでもいいんだけどこれもOAuth2の一種なの?一般的なOAuthとまったく類似点が無い気がするんだけど。。。)

ドキュメント読んでると3回位「悪いことは言わないから自分で実装したりせずに既存のライブラリ使っとけ!」と、言われるんだけどApex用のライブラリは無いんだよ。。。(--

ApexにもJSON、EncodingUtil、Crypto、と必要な道具立ては揃ってるっぽいから多分作れるんじゃないかな?

。。。とりあえず作ってみるか!

 

★で、作ってみた

けど無理でした。。。(--

認証文字列を作るところは良いんだけど最後の最後で署名が。。。(--

ここではSHA256withRSAで電子署名する必要があるんだけど、ApexのCrypto#signではSHA1withRSAでしか署名できないという罠。。。(--

マジでかー(--

ここさえ突破すれば終わりなのにこれはどうしようもねーよ。。。

どうしよう。。。

。。。しょうがないから、外に署名だけするサーバー建てるか。。。

 

★まさかのHeroku登場

作りました。

https://github.com/shunjikonishi/sign-server

ホントにPOSTされた文字列に電子署名して返すだけのアプリ。HerokuにpushしてConfigにBase64エンコードした秘密鍵を設定すれば使えます。

。。。(^^;;;

なんたるリソースの無駄遣い!数年前にはここまで単機能のサーバを気軽に作る日が来るとは思いもしなかったよ。

さすがにちょっとやりすぎなんじゃないの?という気がしなくもないけど、このアリサマはSalesforceがSHA256をサポートしていないのが原因なんでまぁいいか。(^^;

ということで、一応動くGoogle Calendar API V3のラッパーを作ることができました。

https://github.com/shunjikonishi/apex-google-api

次回はこいつの使い方を解説します。(^^v

 

□□□□

蛇足

実はSalesforceにもJWTを使った認証があるということを今回調べてて知りました。

SalesforceのAPIはIDとPassword(とSecurityToken)の認証で普通に使えるからこれ使う人いるのか?という疑問はまぁおいとくとしてもそこではSHA256での検証もやってるっぽい。

そこまでやってるなら後はそれをCryptoにもぶちこめば良いだけなんでとっととやって欲しい。。。(--

たったそれだけでGoogle V3 APIが自由に使えるかどうかが変わってくるんだからホント頼むよ。。。m(_ _)m

2013年7月 1日 (月)

FLECT OSS Libraryが公開になりました。

こんにちは

なんと、今日から7月です。つまり2013年ももう半分終わってしまいました。。。(--

そして、小西がFLECTに入社してからちょうど1年半たったということでもあります。
はやっ!年々時が経つのが速くなっているようでかないませんな。(--

ちなみにこのブログを書き始めたのは2012年の5月末です。1年1カ月で記事数31件。
さぼっている時期もありますがだいたい月に2回位書いている計算ですね。もうちょっと頑張ります。

 

★FLECT OSS Libraryとは

これです。

http://oss.flect.co.jp/

この1年半で僕が作ったものがあらかた入っている感じですね。内容はかなり雑多な感じです。なんでこういうものを作ろうと思ったかは以前にも書いたので割愛します。

個人的に汎用性の高いモノ、開発者にとって有益なモノを作りたいという志向性が強いのでこういう形での開発はテンションがあがります。(^^;

 

★Salesforce関連

思い起こせば1年半前、Salesforceを外部からAPI連携するのをやりやすくするライブラリを整備してほしいというお題に対して、いきなりSOAPClientから作り始めたのがFLECTでのキャリアの始まりでした。

それをベースにして作成したSalesforce APIのラッパーがSalesforceClientで、これでどれ位のことができるかを示すために作成したアプリが、Salesforce Explorerです。

完全に上司の想像のナナメ上をいっていたと思います。(^^;

Salesforceを使う開発者ならそれなりに便利に使えると思うので興味ある人は触ってみると良いかもしれません。(多分)

 

★Excel関連

excel2canvasはHTML5Canvasの調査をしている時に「絵心無いし、Canvasにテスト描画する適当なものが思いつかねー(--」と困ったあげくなんとなくExcelをそのまま描画してみようと思い立ったのが最初です。凝り性なのでやり始めると最初のお題からまったく関係ないシロモノになっていきましたがそこはそれ。(^^;R&Dとはそういうものです。(キッパリ)

これ、何気にSlideも結構なViewを稼いでいるし少なくとも日本では絶対うける思うんですけどね。どの位Excelを再現できるかはサービス化を目論んで開発したExcelReportで確認できるので、なんか適当な帳票フォーマットをExcelで持っている人はアップロードしてみてください。

 うまくブラウザで描画されないという場合は連絡くれれば可能な限り直します。(多分)

 

★その他

あとはHeroku上で動かすことを前提として作成したアプリをいくつか公開しています。

ちなみに最近作っているアプリは全部Play2で開発しています。社内のHerokuチームが使用している言語はPlay1なんですが、最近はメンテもされてないようなので次期主力言語として使えるかどうかを評価するという目的も兼ねています。

ちなみにPlay2の評価は。。。うーん、どうなんだろう?(--
まだまだベストプラクティスを模索している状態なので、書いていてももっと良い書き方があるんじゃないの?とか、本当にこんなめんどくさいことを毎回書かないといけないのか?とか思うこともしばしばです。

(↑もっとも、Scalaのおかげで圧倒的に楽になっている部分もあるので、このように不満点だけをあげるのは正当な評価ではありません。Play2については近日資料にまとめるつもりです。)

とにかく最近はHerokuが面白くてしょうがないので、Herokuを便利に使うための小物ツールをもうちょっと作っていこうかなと思っています。まだOSS Libraryにはリストされてませんが現在つくっているものもHerokuユーザーにとってはかなり便利です。(多分)

 

会社としても絶賛Herokuエンジニア募集中なので興味ある人は覗いてみてください。

2013年4月24日 (水)

Salesforce BulkAPIの動作検証

こんにちは

最近珍しくSalesforceを触っています。(FLECTではSalesforce素人の僕の方が少数派なんですが。。。)

案件需要として「RDBMSのデータを定期的にSalesforceに同期する」という要件があるのでそれが汎用的にできるツールを作成しているのです。

で、そのバックロジックとしてはBulk APIを使うのでざっと検証したその動作を書きとめておきたいと思います。

 

★Bulk APIとは?

大雑把に言ってしまえばCSVで作成したデータを一気にSalesforceに取り込むためのAPIです。
他にもXML形式で取り込めたりクエリでSELECTした大量のCSVデータをダウンロードしたりもできますがここでは触れません。

Salesforce識者の方にはDataLoaderが裏で使用しているAPIというのがわかりやすいでしょうか。 (といいつつ、DataLoaderはデフォルトではSOAP APIを使用する設定になっており設定変更しないとBulkAPIは使われませんが。)

 

★とりあえず使ってみる

BulkAPIの使い方自体はドキュメントを読めばなんとなくわかります。

簡単にまとめると

  1. WebAPIのOpenJOBメソッドでジョブを開始
  2. WebAPIのAddBatchメソッドでCSVファイルをPOST(複数回可)
  3. WebAPIのCloseJOBメソッドでジョブを完了

ジョブの実行自体は非同期なのでAddBatchがリターンした時にはまだデータの更新は完了していません。ただしAddBatch自体がかなり重たいメソッドのようで7MB程度のファイルのアップロードで2分前後の時間がかかっています。

AddBatchからリターンした後にはまだデータ更新の途中であってもCloseJobメソッドを実行してしまって構いません。それでデータ更新が中断されるようなことはなく、データ更新終了時に自動的にクローズされます。

CloseJobを実行しなかった場合、ジョブは一週間オープンしたまま残ります。(とドキュメントに書いてあります。)

クローズした後でもJobのステータスは確認できるのでAddBatchが終わったらさっさとクローズしてしまった方が良いです。

 

★ジョブの実行結果の確認

ジョブのステータスの確認はWebAPIでもできますが、Salesforceの画面上で行う方が簡単です。

 

    設定 > 管理者設定 > 監視 > 一括データ読み込みジョブ

 

の項にジョブの状況確認画面があります。

この画面では処理に成功したレコードが何件あるか、失敗したレコードは何件あるかと言ったサマリ的な情報を確認できる他にバッチの「結果を表示」を実行することで処理を行った全レコードについて

  • レコードのID
  • 処理に成功したかどうか
  • 処理内容はInsertかUpdateか
  • エラーがあった場合そのエラーメッセージ

が、CSV形式で確認できます。

 

★エラー時の動作検証

さて、このBulkAPI。正常ケースは特に迷うところはありません。
API実行しました。データ入りました。以上終わり。です。

ここではガバナ制限やレコードデータの不正などエラーケースについてどのような動作をするかを検証していきたいと思います。

ちなみにテストはDeveloperEditionを使用して1万5000件くらいのデータを使用して行いましたが、その環境は現在こんなことになっています。

Salesforcestorage_2

ストレージ使用量600%です。(^^;;;
BulkAPIでもディスク容量のチェックはもちろん行われますが、ジョブの実行中はしばらく容量超過に気が付かないようで、100%を越えてもしばらくはデータがInsertできます。

バッチの途中からでもエラー(ストレージ超過)になることはあるので、どういうタイミングでチェックが行われているのかは謎ですが、これはそういうもののようです。

まぁそうでなければ今回のテストはほとんど実行できなかったので良いのですが。(^^;;
ちなみにこれだけ容量を超過していてもBulkでのUPDATEは問題なく実行できます。(INSERTはもちろんエラーになりますが。)

以下、今回チェックしたエラー時の動作です。検証はBulk APIのドキュメントにあるLimitsを超過したケースといくつかのレコードエラーについて実施しました。

 

AddBatchのファイルサイズが10MBを越えていた場合

この場合、AddBatchのレスポンスとしてHttp status「400 BadRequest」が返ってきます。当然バッチはジョブに追加されませんし実行もされません。

 

CSVに1万1行以上のレコードがあった場合

AddBatchには成功し、バッチジョブも実行されます。ただし、1万行を越えたレコードについては無視されて処理が実行されません。
実行結果を確認すると、「失敗したバッチ数」はカウントアップされていますが、「レコードの失敗」には無視されたレコードはカウントされません。

 

CSVに1000万文字以上の文字があった場合

未テストです。日本語データを含む場合1000万文字は確実に10MBを超えると思われるのであまり意味がありません。

 

1フィールドに32000文字以上の文字があった場合

AddBatchには成功しますが、バッチ処理全体が実行されません。例えば1行だけにエラー行があって他のレコードには問題がない場合であっても1行も処理は実行されません。

エラーのない行については処理してくれても良さそうなものですが。。。LongTextの上限が32768文字であるにも関わらずここでの制限が32000文字であることも謎です。

 

CSVに5000フィールド以上あった場合

未テストです。。。(--

ネタとしてMetadataAPIで5000フィールド作ろうかとも思いましたがやっぱり面倒なので。(^^;;;
BulkうんぬんよりもSalesforceの設定画面の方が先に限界を迎えそうな気がします。

 

1レコードに40万文字以上あった場合

これも未テストです。。。(--

一般的なスキーマでテストしようとすると先に1フィールド32000文字の制限に引っ掛かると思うので。
おそらく結果は1フィールドの超過の場合と同じだろうと予想しています。

 

テキスト項目サイズ超過(256文字)のレコードがある場合

そのレコードだけがエラーになります。

エラー内容はジョブの確認画面からダウンロードできる結果CSVで行単位に確認できます。

 

選択項目に未定義の選択値がある場合

エラーとはならずそのまま更新されます。

予想としてはエラーになると思ったんですが、識者に確認するとこれはそういうものらしいです。。(--

 

メール項目に不正なメールアドレスがある場合

そのレコードだけがエラーになります。

エラー内容はテキスト項目サイズ超過の場合と同じように確認できます。

基本的にはレコードのエラーはその行だけがエラーになると考えて良さそうです。
(選択項目の挙動がイマイチ納得いきませんが。。。)

 

★Bulk APIの運用方法

ここまでの結果から、なんとなくCSVを作成してとりあえず投げてみて結果はジョブ確認画面で確認。で十分な気がします。

レコード数超過だけは半端な結果になるのでCSV作成時に10000行を越えないことだけは注意した方が良いですが、それ以外のケースはエラー確認後にCSVを修正してリトライで十分な気がします。

レコードの項目エラーについてもSalesforce側でちゃんとチェックしてくれるので、事前にチェックする必要性はあまり感じません。(メールアドレスなんかは事前にチェックしたとしてもチェック内容が同じかどうかなんてわかりませんし。。。)

□□□□

そんな感じでRDBからのSELECT結果をなんとなくBulkで突っ込むツールがもうじき完成します。(^^;

採用情報

株式会社フレクトでは、事業拡大のため、
Salesforce/Force.comのアプリケーション
開発
HerokuやAWSなどのクラウドプラッ
トフォーム上でのWebアプリケーション開発

エンジニア、マネージャーを募集中です。

未経験でも、これからクラウドをやってみた
い方、是非ご応募下さい。

フレクト採用ページへ

会社紹介

株式会社フレクトは、
認定コンサルタント
認定上級デベロッパー
認定デベロッパー
が在籍している、
セールスフォースパートナーです。
heroku partnersにも登録されています。
herokuパートナー
株式会社フレクトのSalesforce/Force.com
導入支援サービス
弊社の認定プロフェッショナルが支援致します。
・Visualforce/Apexによるアプリ開発
・Salesforceと連携するWebアプリ開発
も承っております。
セールスフォースご検討の際は、
お気軽にお問合せください。
Powered by Six Apart