Integration アーキテクト試験 

受験ガイドより 2
 対象者について: SALESFORCE 認定 INTEGRATION アーキテクト Salesforce 認定 Integration アーキテクトの受験者には、以下の経験、スキル、知識 が求められます。 ● Lightning Platform や他のエンタープライズアプリケーションとの性能、拡張性、安全性、信頼性が高いインテ グレーションを設計する。 ● 既存または将来におけるインテグレーションアーキテクチャを分析する。 ● プロジェクトのインテグレーションアーキテクチャ設計図を作成して管理する。 ● 他のエンタープライズアプリケーションやクラウドアプリケーションと統合する。 ● インテグレーションでドメインのベストプラクティスに従う。 ● 適切なインテグレーションパターンを追加、特定、適用する。 ● 適切なインテグレーションコンポーネントを推奨し、プラットフォームの適した機能を使用する。 ● プラットフォームの制限を考慮して設計する。 ● さまざまな Salesforce API やインテグレーションツールに精通している。 ● 特定のインテグレーションシナリオに合わせて、適切なインテグレーションパターンを活用する。 ● インテグレーションシナリオの考慮事項を理解し、適切な API を使用する。 ● 特定のインテグレーションシナリオのセキュリティ要件を挙げる。 ● エラー処理のオプションを理解する。 [出典] https://uhuru.quip.com/ubogABg3Mqjl/SALESFORCE-INTEGRATION- 

受験ガイドより 3
 試験の詳細 Salesforce 認定 Integration アーキテクト試験の詳細は次のとおりです。 ● 内容: 多肢選択/複数選択方式の 60 問 ● 試験の所要時間: 105 分 ● 合格点: 67% ● 受験料: 40,000 円（税抜） ● 受験方法: テストセンターにおける監督下の試験、またはオンライン環境における監督下の試験。受験方法の詳 細については、こちらをクリックしてください。 ● 参考資料: 試験中に紙面やオンラインの資料を参照することはできません。 ● 前提条件: なし [出典] https://uhuru.quip.com/ubogABg3Mqjl/SALESFORCE-INTEGRATION- 

受験ガイドより 4
 試験概要(一部抜粋) インテグレーションソリューションの設計: 28% ● 特定のユースケースに基づいて、ビジネス要件を満たすインテグレーションパターンを特定する。 ● 特定のユースケースに基づいて、ビジネス要件を満たすソリューションを作成するコンポーネントを定義する。 ● 特定のユースケースに基づいて、提案したソリューションに付随するトレードオフ、制限、制約を特定する。 ● 技術要件、制約、推進要因を伴う特定のユースケースに基づいて、提案したソリューションに適した Salesforce API を指定する。 ● 技術要件、制約、推進要因を伴う特定のユースケースに基づいて、使用すべき標準、コンポーネント、技法、セ キュリティメカニズムを判断する。 [出典] https://uhuru.quip.com/ubogABg3Mqjl/SALESFORCE-INTEGRATION- 

受験ガイドより 5
 試験概要(一部抜粋) ソリューションの構築: 23% ● 技術要件、制約、推進要因を伴う特定のユースケースに基づいて、API プロバイダーとしての Salesforce と API コンシューマーとしての Salesforce の両方で、API を設計して実装する場合の考慮事項を挙げる。 ● 特定のユースケースに基づいて、外部システムにアウトバウンドコールを実行する適切なオプションを選択する場 合の考慮事項を挙げる。 ● 特定のユースケースに基づいて、拡張性の高いソリューションを構築するときに考慮すべき点を説明する。 ● 特定のユースケースに基づいて、さまざまなインテグレーションオプションのエラー処理を判断する。 ● 特定のユースケースに基づいて、インバウンドまたはアウトバウンドインテグレーションのセキュリティソリューショ ンを作成する。 ● 特定のユースケースに基づいて、システムの更新のためにインテグレーションソリューションのレジリエンスを高め るために必要な要因を挙げる。 [出典] https://uhuru.quip.com/ubogABg3Mqjl/SALESFORCE-INTEGRATION- 

外部システムとの連携パターン 

外部システムとの連携パターン(サクセスナビ) 7
 ● Salesforceを基準にしたインバウ ンドとアウトバウンドとは ○ Salesforce側にエンドポイントが ある→インバウンド ○ 対向システム側にエンドポイント がある→アウトバウンド ● 同期・非同期処理とは ○ 同期は処理が返ってくるまで待つ こと ○ 非同期は処理が返ってくるまで待 たない、別途結果を取得するなど が必要 ● LDV・バルク対応とは ○ LDVはLarge Data Volumeの で大量データのこと ○ バルクは一括でレコードを扱うこと [出典] https://successjp.salesforce.com/article/NAI-000618 

REST API① 8
 [出典] https://www.apexhours.com/rest-api-in-salesforce/ ● RESTful原則に基づいたシンプルで強力なWebサービス ● レコードの作成、読み取り、更新、削除などができる ● XMLとJSONの両方をサポート ＜呼び出しの構造＞ http://xxx.my.salesforce.com/services/data/v58.0/sobjects/sObjectName/yyyzzzzzzzzzzzz ＜HTTPメソッドを指定して呼び出す＞ 作成 POST 読み取り GET 更新 PATCH 削除 DELETE あれば更新、なければ作成 PUT 

REST API② 9
 [出典] https://www.apexhours.com/salesforce-composite-resources/ ● 複数レコードを扱うこともできる <複合API> http://xxx.my.salesforce.com/services/data/v58.0/composite 1回の呼び出しで一連のAPIリクエストを実行できる。 例）AccountをPOST、その値を元にContactをPOST ＜複合バッチ＞ http://xxx.my.salesforce.com/services/data/v58.0/composite/batch 1回の呼び出しで最大25のサブリクエストを実行できる。 例）AccountをPATCH、その結果をGET ＜SObjectコレクション＞ http://xxx.my.salesforce.com/services/data/v58.0/composite/sobjects 1回の呼び出しで複数のレコードにアクションを実行できる。エラー発生時は全体をロールバックするかも選択できる。 例）AccountとContactを順にPATCH ＜複合ツリー＞ http://xxx.my.salesforce.com/services/data/v58.0/composite/tree/sObjectName 親子を辿って最大5レベルまでの作成ができる。 例）AccountとContactをまとめてPOST、別のAccountもPOST 

REST APIの問題点 10
 ①過剰なデータ 電話番号と住所 がほしいな (権限のある)全フィール ド返しますね サーバやネットワークに 負担。。 ※fieldsで必要な項目を指定できますが、権限が ないとエラーになります ②ラウンドトリップの多さ 大阪の住所を持つ人を取 得して、電話番号が登録 されてなければメールアド レスを取得したいな 何度も呼び出ししないと いけないな。。 ※SalesforceだとSOQL投げることができますが、 もし上記の例が関連のないオブジェクトだったら、 複数のリクエストが必要です 大阪の住所持つ人くださ い 電話番号と住所ください 住所の権限ないですね、 エラーコード400 じゃあ、全部で はい、これです 電話番号がない人の メールアドレスください はい、これです ③複雑なロジックは不向き 大阪の住所を持つ人を 取得して、電話番号が登 録されてなければメール アドレスを取得したいな 一気に処理してほしい ついでに対象者にフラグ つけて更新して 無理です ※Compositeで処理するか、次ページで紹介する Apex RESTの出番です 

Apex REST 11
 ● 複雑な実装のために、ApexクラスでカスタムApexエンドポイントを定義できる ● HTTPメソッドにあたるものを用意しておき、処理を自由に記述する ○ 複数オブジェクトの操作やエラーハンドリングなど ○ 返却するデータ構造も決めることができる ＜呼び出しの構造＞ http://xxx.my.salesforce.com/services/apexrest/xxx/yyy ＜URLマッピングのアノテーションをクラスにつける＞ @RestResource(urlMapping=’/api/Account/*’) 作成 @HttpPost 読み取り @HttpGet 更新 @HttpPatch 削除 @HttpDelete あれば更新、なければ作成 @HttpPut ＜HTTPメソッドにあたるアノテーションをメソッドにつける＞ 

GraphQL 12
 ● APIの標準のクエリ言語 ● REST APIの問題点を解消できる ○ 過不足なくデータを入手 ○ 1度のリクエストで必要なデータをすべて要求できる [出典] GraphQLがどんなものか見ていきましょう ここでバトンタッチです！