Salesforce 認定 Integration Architecture デザイナー試験 を勉強した時の勉強メモ
※Winter '19 の時のメモです
難しいんすよ、この試験、、私はアーキテクト系の試験ではこれを2番目に受けたんですけど、インテグレーションの概念はわかる、だが結局認証とかどうなってるの、、、っていう疑問が頭から離れませんでした。なので
ここでは、私がIntegration Architecture デザイナー試験を勉強した際に参照していたことをまとめています。
https://gyazo.com/ee71b95d4948d424e425d6ddb8115e19
受験ガイド
一番初めに読むやつ。見ましょう！
公式 Trailmix
アーキテクト系の試験ではポイントスタディがないかわりに、公式の Trailmix があります。(でも全部英語)
探したら日本語版もありました。(でもリンク先はやっぱり英語)
Trailmix をみるとわかりますが、なんと、Trailhead のモジュールが1つもない・・・！ と言うわけで、私の方で参考になりそうなモジュールをピックアップしてみました。
参考になる Trailhead
Minecraft と Salesforce を連携している事例が載ってます 笑
上級 Developer も目指している人はスーパーバッチもあとで必要になるので、このタイミングで取っちゃいましょう
最近のスーパーバッチには日本語訳もありますので安心です
海外のとてもすごい方々のブログ
試験勉強の際には毎回みさせて頂いております。ありがとうございます...!!!
書いてあることがおもしろい。以下、私の意訳で引用。
SOAP は用心棒がいるナイトクラブのようなもの。入場するためにはパスが必要。
REST はパブのようなもの。ふざけたりしない限りは歩いて中に入ることができる。
さらに、↑のブログ書いた方が超参考になったよ ( It was such a help.) と書いているブログ。こちらも大変参考になりました。
試験範囲毎のリンク集
受験ガイドの範囲毎に見ておいた方が良いものをまとめます。
SALESFORCE 連携機能
受験ガイド的には27%も出ますので、ここで点数を稼いでおいておきたいですね。
SOAP API
Simple Object Access Protcol
XML での連携。
試験問題中では大抵のレガシーなシステムは SOAP に対応できていると考えた方がよい
REST は明示的に記載されていない限り未対応と考える方がよい
SOAP では WSDL (Web Services Description Language) と呼ばれる連携仕様の定義ファイルで連携プログラムを作成する
ex) Salesforce -> 外部システムへの連携
外部システムから WSDL ファイルを受領する
Salesforce の設定 (設定 -> カスタムコード -> Apex クラス -> WSDL からの生成) から Apex コードを自動生成
ex) 外部システム (Java アプリ) -> Salesforce への連携
Salesforce の設定 (設定 -> インテグレーション -> API) から WSDL をダウンロードし、外部システム開発担当に渡す
Java プログラムで WSDL を読み込ませて Salesforce と連携するプログラムを自動作成
WSDL には 2 種類あります。 (ダウンロードは 設定 -> インテグレーション -> API から)
Enterprise WSDL
実際にダウンロードしてみるとわかるのですが、組織上のオブジェクト定義全部が xml 形式で出力されます
つまり、WSDL を読み込ませた Java プログラムとかでカスタムオブジェクトクラスとかを定義できるということ
組織に依存します
Partner WSDL
オブジェクト定義などは xml 形式では出力されません。
WSDL を読み込ませた Java プログラムとかでは sObject クラスを使ってプログラム書いていきます
組織に依存しないプログラムをかけます
Dataloader は Java で動いてますが、たぶん Partner WSDL を使って作成されてます
って書くとイメージつきやすいかも
SOAP 連携の良いところ
WSDL ファイルに型定義とかが全部書いてあるところ
型安全なので変なプログラム書いた時点でコンパイルエラー
ある程度のまとまったデータの連携に向いてる
数万とか数十万のオーダだったら Bulk 使う
クエリ (SOQL の SELECT とか) の最大バッチサイズは 2000 レコード
10000 件のレコードを SOAP で持ってこようとしたら 5 つのバッチに分割される
DML (SOQL の Insert とか Update とか) の最大バッチサイズは 200 レコード
1000 件のレコードを SOAP で Insert しようとしたら 5 つのバッチに分割される
SOAP は同期実行、非同期にするのが Bulk
REST API
REpresentational State Transfer
URI に GET とか POST とか PUT とか(他にも色々) で連携する時。
REST 連携の良いところ
JSON フォーマットで受け渡しをするので JavaScript との相性が良い
ゆえにフロントエンドなどで利用されることが多い
HTTP メソッドでエンドポイントを叩くだけで良いのでお手軽
基本的には 1, 2 件のデータを持ってきたり、更新したりするのに使われる
レコードの単純な CRUD であれば、Salesforce には標準の連携用エンドポイントが存在する
カスタムオブジェクト作った瞬間にできあがる。すごい！
複数オブジェクトを 1 リクエストで作成したかったり、トランザクション制御したかったりするときは Apex でかく
@RestResourceアノテーションを使ってクラスを作成する
Bulk API
大量データ連携
SOAP が同期実行なところ、Buik は非同期並列で実行されるので SOAP よりも断然早い
バッチサイズの上限が 10000 件
並列実行されるってことはロックの競合が起きやすい
たとえば、50000 件の取引先責任者のレコードを Insert しようすること考える
5 つのバッチに分割されるが、同じ親取引先を持つ取引先責任者のレコードがそれぞれ別のバッチとなった場合、ロック競合が発生する可能性がある (レコードの挿入時に親レコードにロックをかけるため)
回避するためには、複数のバッチで同一の親レコードとなるものがないよう、あらかじめ投入レコードをソートしておくとロック競合の発生確率を下げることができる
PK Chunking をつかって、Select を並列化することもできる
Dataloader は対応してない、、、Idea には載ってるので実装してほしい、、、
Streaming API
pub / sub のリアルタイム連携
試験範囲として出てくるのは主に publisher が Salesforce となる場合
PushTopic と呼ばれるオブジェクトに SOQL 文と、publish するための条件 (CREATE されたときなのか、UPDATE されたときなのか) レコードとして登録しておくと、条件に合致したときに Salesforce が通知を Publish してくれる
Subscriber は外部システムだったり、Salesforce だったり。Publish されるのをロングポーリングしてる
どちらの場合でも、条件に合致した場合にリアルタイムに通知を受領できる
Streaming API のよいところ
リアルタイム連携
Salesforce が Publisher になる場合は、PushTopic にレコード入れるだけ
改修の必要がないので SIer がよろこぶ
Subscriber 側はたぶん大変
外部システムから Salesforce にデータを取りに行くので、ファイアウォールを超えられることが多い
Salesforce から外部システム連携はファイアウォールに阻まれることが多い
キャンバス
Salesforce の画面に他システムの画面を埋め込む連携
同じようなもので iframe を思いつく人もいるかもだが、iframe とは違って埋め込んだ画面と Salesforce の連携ができるのが特徴
ワークフローアウトバウンド
アウトバウドメッセージは SOAP なので(重要)、SOAP API 開発者ガイドをみると書いてある
余談ですが、ワークフローでできるたいていのことはプロセスビルダーでもできる
アウトバウンドメッセージを使いたい時はワークフロー
From Salesforce to 外部システムの連携なので、大抵の場合はファイアウォールに阻まれる
外部システム側のファイアウォールに穴あけ (Salesforce の IP を許可していただく) をする必要がある
あと、認証とかはどうするの問題
アウトバウンドメッセージのよいところ
画面ぽちぽちだけで外部連携を実装できる
リトライを自動的にしてくれる
連携先システムにメッセージが届かなかった場合でも送信できるまで 24 時間までならリトライしてくれる
Apex (コールアウト、@future など)
Apex プログラムからの外部連携
@future アノテーションで非同期メソッド
トリガから同期のコールアウトは不可
非同期コールアウト @future(callout=true) にすれば OK
Lightning Connect
なんだっけこれ、、、受験ガイドみながら書いてるけど、たぶん Salesforce Connect のこと
ODATA に対応している外部システムなら Salesforce にデータを透過的に表示させることが可能
外部オブジェクトとして扱うことができ、外部システムのレコードを Salesforce 上から参照、更新もできたりする
Salesforce Connect の良いところ
外部システムのレコードをコピーするのではなく Salesforce 上から参照、更新することができる
よくあるのは重要な顧客データを連携とかで複数の場所に置きたくない、って要件がある場合
外部システムのデータソースを外部オブジェクト(API 参照名の末尾が __x となる) としてカスタマイズ可能
Salesforce 独自の項目追加したりとかもできる
参照関係追加したりもできる
外部参照関係: 外部オブジェクト同士の参照関係
関節参照関係: Salesforce のオブジェクトと外部オブジェクトとの参照関係
SALESFORCE 連携パターン
受験ガイド的には17%でます。
重要なとこ書いておきます。
リモートプロセスの呼び出し — 要求と返信
同期呼び出しのこと
リクエスト出したらレスポンスを待つ
From Salesforce から To 外部システムへの呼び出し
一般的な連携パターン
リモートプロセスの呼び出し — ファイアアンドフォーゲット
非同期呼び出しのこと
イベント発火させたらあとは忘れる
レスポンス待たずに次の操作したい時とかに使う
ファイアアンドフォーゲットって名前がかっこいい
バッチデータの同期
他システムとデータの同期とる
バッチチェーンとか ETL 使ったりとか
大量データは Bulk でドン
リモートコールイン
From 外部システムから To Salesforce への呼び出し
ガバナにカウントされる
データの変更に基づく UI の更新
更新ボタンを押したら反映されるとかではなく、何もしなくても勝手に更新とか通知とかされるイメージ
SALESFORCE 連携テスト
受験ガイド的には 10%出ます。
SOAP とか REST のプログラムを書いたりすると、当然テストコードも書くわけですが、さすがにテストコード上から外部サービスを呼び出すことはできません。なので、Mocking サービスを作成したりします。
以下のトレイルヘッドが良い感じにまとまっています。
エンタープライズ連携アーキテクチャの概念
受験ガイド的には (略 15%
シナリオから適切なアーキテクチャを選択する、と記載があるので、上に書いたことをよく調べておけば回答できるはず
SALESFORCE との連携: セキュリティ
受験 (略 15%
セキュリティ戦略・・・受験ガイド見てもどこがでるのかよくわかりませんでした
ツール
受 (略 10%
ごちゃごちゃした連携だったらいさぎよく ETL ツール使うのも良い。
あとは DataLoader とか。DataLoader は実はバッチモードで起動することができる。
DataLoader をバッチモードで使うには開発者ドキュメントを見ながら設定ファイルを作る必要があるが、その設定ファイルを簡単に作成できる DataLoader CLIq というツールがある。が、非公式なツールなので試験には確実に出ないが、実務で使いそうな予感がするので備忘として覚えておく。
監視
5%
5% しかないので捨てます。
アウトバウンドメッセージの状況とか Bulk API の状況がが監視できます、とかそこらへんかなぁ。
ここらへんはこのメモに書いてあるリンク先全部読めばなんとかなる。でしょう。きっと。
まとめるのがめんどくさかったわけではありません。
以上。