Salesforce認定 Integrationアーキテクト 試験対策メモ①

Spring'23
Salesforce認定 Integrationアーキテクト 試験対策メモ②

試験の概要

Salesforce認定Integrationアーキテクトの試験概要

求められること

• Lightning Platform や他のエンタープライズアプリケーションとの性能、拡張性、安全性、信頼性が高いインテグレーションを設計する。
• 既存または将来におけるインテグレーションアーキテクチャを分析する。
• プロジェクトのインテグレーションアーキテクチャ設計図を作成して管理する。
• 他のエンタープライズアプリケーションやクラウドアプリケーションと統合する。
• インテグレーションでドメインのベストプラクティスに従う。
• 適切なインテグレーションパターンを追加、特定、適用する。
• 適切なインテグレーションコンポーネントを推奨し、プラットフォームの適した機能を使用する。
• プラットフォームの制限を考慮して設計する。
• さまざまな Salesforce API やインテグレーションツールに精通している。
• 特定のインテグレーションシナリオに合わせて、適切なインテグレーションパターンを活用する。
• インテグレーションシナリオの考慮事項を理解し、適切な API を使用する。
• 特定のインテグレーションシナリオのセキュリティ要件を挙げる。
• エラー処理のオプションを理解する。

求められないこと

• Salesforce 以外のテクノロジー/データベースの概念
• インテグレーションツールの設定
• MDM (マスターデータ管理) ツールの使用経験
• Lightning 開発の実務経験/専門知識
• プログラミング言語

試験範囲

=試験概要の項目=

• 1. 現在のシステム環境の評価(8%)
  • 一連のビジネス要件に基づいて、現在のシステム環境を特定し、どのような標準、制限、境界、プロトコルが存在するか判断する。
  • 既存のシステム環境の制約や弱点を分析し、ビジネス要件を満たす。
  • 一連の要件に基づいて、システム環境に応じた認証や認可のニーズを評価する。
• 2. ビジネスニーズの評価(11%)
  • 1 つのユースケースについて、インテグレーションに必要な機能要件、非機能要件をそれぞれ特定する。
  • 特定のインテグレーション要件に基づいて、データを特定し、機密（Confidential）/安全（Secure）/公開（Public）の分類をする。
  • 特定のユースケースに基づいて、CRM を効率的に機能させるためのインテグレーション要件に追加すべき主な要素を特定する。
  • 特定のユースケースに基づいて、インテグレーションソリューションの選択に影響を及ぼす可能性があるビジネスの成長要因や規制要因を特定する。
• 3. ニーズからインテグレーション要件への変換(22%)
  • 既存のシステム環境の図表に基づいて、システムやインテグレーションパターンのインベントリーを作成する。
  • 特定のユースケースとビジネスプロセスに基づいて、システムやプロセスの制約を評価する。
  • 特定のユースケースに基づいて、インテグレーションのセキュリティ要件/認証要件/認可要件を特定する。
  • 特定のユースケースに基づいて、パフォーマンス上のニーズ (処理量、応答時間、遅延) を特定し、ビジネス要件を満たす適切なインテグレーションソリューションを提案する。
• 4. インテグレーションソリューションの設計(28%)
  • 特定のユースケースに基づいて、ビジネス要件を満たすインテグレーションパターンを特定する。
  • 特定のユースケースに基づいて、ビジネス要件を満たすソリューションを作成するコンポーネントを定義する。
  • 特定のユースケースに基づいて、提案したソリューションに付随するトレードオフ、制限、制約を特定する。
  • 技術要件、制約、推進要因を伴う特定のユースケースに基づいて、提案したソリューションに適した Salesforce API を指定する。
  • 技術要件、制約、推進要因を伴う特定のユースケースに基づいて、使用すべき標準、コンポーネント、技法、セキュリティメカニズムを判断する。
• 5. ソリューションの構築(23%)
  • 技術要件、制約、推進要因を伴う特定のユースケースに基づいて、API プロバイダーとしての Salesforce と API コンシューマーとしての Salesforce の両方で、API を設計して実装する場合の考慮事項を挙げる。
  • 特定のユースケースに基づいて、外部システムにアウトバウンドコールを実行する適切なオプションを選択する場合の考慮事項を挙げる。
  • 特定のユースケースに基づいて、拡張性の高いソリューションを構築するときに考慮すべき点を説明する。
  • 特定のユースケースに基づいて、さまざまなインテグレーションオプションのエラー処理を判断する。
  • 特定のユースケースに基づいて、インバウンドまたはアウトバウンドインテグレーションのセキュリティソリューションを作成する。
  • 特定のユースケースに基づいて、システムの更新のためにインテグレーションソリューションのレジリエンスを高めるために必要な要因を挙げる。
• 6. インテグレーションのメンテナンス(8%)
  • インテグレーション管理の特定のユースケースに基づいて、インテグレーション要件に関するパフォーマンス監視のニーズを特定する。
  • 特定のユースケースに基づいて、インテグレーションに失敗した場合の適切なエラー処理、エスカレーション、復旧手順を特定する。
  • 特定のユースケースに基づいて、インテグレーションの監視レポートのニーズを特定する。

1. 現在のシステム環境の評価(8%)

• どのような標準、制限、境界、プロトコルが存在するか判断する。
• ビジネス要件を満たすための、既存のシステム環境の制約や問題点を分析する。
• 認証や認可のニーズを評価する。

1.1. どのような標準、制限、境界、プロトコルが存在するか判断する。

※Salesforce認定 Integrationアーキテクト 試験対策メモ②

1.2. ビジネス要件を満たすための、既存のシステム環境の制約や問題点を分析する。

• データの不整合
  • サードパーティアプリを介する場合、レコードに不完全なデータが追加されることを疑う。
  • 外部システムからデータを受けとるレコードトリガーフローを疑う。

1.3. 認証や認可のニーズを評価する。

ゼロトラストモデルに準拠する外部システムとの統合

• ゼロトラストモデルは、あらゆる通信は潜在的な脅威であると想定し、すべての通信を検証するセキュリティフレームワーク。
• Salesforceは相互認証証明書に対応している。
• ただし、有効化のためにはSalesforceのサポートに問い合わせる必要がある（相互認証を有効にする）。

SOAP Web サービスへのコールアウトで双方向SSL認証を使用する*

1. 自己署名証明書を生成する。
2. 証明書をApexで登録する。*
   1. WebサービスのWSDLを受領する。
   2. WSDLからApexクラスを生成する。
   3. スタブクラスを編集し、インスタンス変数clientCertName_xに証明書の一意の名前を設定する。

      sampleServices.sampleImplPort stub = new sampleServices.sampleImplPort();
      stub.clientCertName_x = 'Self_Signed_Certificate_Name';
      

3. サードパーティのキーストアに証明書を共有するか、クライアント証明書を要求するようにWebサーバーまたはアプリケーションサーバーを構成する。
4. リモートサイト設定、従来の指定ログイン情報、指定ログイン情報・外部ログイン情報のいずれかを設定する。

通信の暗号化に使用する証明書

• 自己署名証明書
  • Salesforceが署名した証明書で、Salesforce組織からの通信が本物であることを証明するために使用できる。
  • プライベートネットワーク内での接続やテストなどに適している。
  • 自己署名証明書はいつでも生成、更新できる。
  • 2048ビットキーを使用した証明書の有効期間は1年で、4096ビットキーを使用した証明書は2年。
• 認証局署名証明書
  • 通信の真正性を示すために、より権威のある認証局（CA）が署名した証明書。
  • 一般公開サイトや一般公開されているシステムとの通信を保護するために使用される。

2. ビジネスニーズの評価(11%)

• インテグレーションに必要な機能要件、非機能要件をそれぞれ特定する。
• データを特定し、機密（Confidential）/安全（Secure）/公開（Public）の分類をする。
• CRM を効率的に機能させるためのインテグレーション要件に追加すべき主な要素を特定する。
• インテグレーションソリューションの選択に影響を及ぼす可能性があるビジネスの成長要因や規制要因を特定する。

2.1. インテグレーションに必要な機能要件、非機能要件をそれぞれ特定する。

※Salesforce認定 Integrationアーキテクト 試験対策メモ②

2.2. データを特定し、機密（Confidential）/安全（Secure）/公開（Public）の分類をする*

データ分類

• 標準項目・カスタム項目のデータ分類を設定する。
• 機密データとして指定されたデータをエクスポートされた時にアラートをトリガするなどのイベント監視が可能。
• 機密・安全・公開
  • 機密：機密性が高く、個人情報が含まれている可能性があるため、保護する必要がある。（社会保障番号など）
  • 安全：不正アクセスから保護される必要があり、公開された時にリスクをもたらす可能性があるデータ。（学生番号、社員番号など）
  • 公開：自由にアクセスできる情報。他の人に共有されてもリスクはない。（時間割、コース名など）

コンプライアンス分類

• 標準項目・カスタム項目のコンプライアンス分類を設定する。
• この項目に含まれるデータに関連する法、定義、規制を示すために使用される。
• 選択肢は設定 > データ分類設定から変更可能。
• デフォルトはPII, HIPAA, GDPR, PCI, COPPA, CCPA
  • PII：Personally identifiable Information。個人情報を表す用語。主に米国で使用される。
  • HIPAA：Health Insurance Portability and Accountability Act。（米国）あらゆる医療施設で患者の健康情報を保護するための米国連邦法。
  • GDPR：General Data Protection Regulation。（欧州）個人情報保護のためのEUの法律要件を定めた規則。
  • PCI DSS：Payment Card Industry Data Security Standard。クレジットカード業界の情報セキュリティ基準。
  • COPPA：Children's Online Privacy Protection Act。（米国）13歳未満の子供の個人情報が保護者の管理下に安全に保たれるように制定された米国連邦法。
  • CCPA：California Consumer Privacy Act。（カリフォルニア州）カリフォルニア州の住民のプライバシー保護を定めた州法。

データ機密度

• 標準項目・カスタム項目のデータ機密度を設定する。
• 項目のデータ感度レベルを示すために使用され、データが紛失または公に露出した場合に関連するリスクを表す。
• 選択肢は設定 > データ分類設定から変更可能。
• デフォルトはPublic, Internal, Confidential, Restricted, MissionCritical
  • Public：参照目的で公開される
  • Internal：内部の従業員・請負業者が利用できる。公開不可。NDA（秘密保持契約）に基づいて共有することはできる。
  • Confidential：承認された従業員・請負業者が利用できる。このデータは法律、規制、会社のMSA（マスターサービス契約）の制限の対象ではない。NDA（秘密保持契約）に基づいて共有することはできる。
  • Restricted：承認された従業員・請負業者が利用できる。このデータは法律、規制、NDA、会社のMSAの制限の対象となる可能性がある。
  • MissionCritical：承認された従業員・請負業者が利用できる。アクセス権を付与されるサードパーティには、より厳しい契約上の要件が課せられる可能性がある。このデータは法律、規制、NDA、会社のMSAの制限の対象となる。
• csvから一括設定可能設定 > データ分類アップロード

項目の利用状況

• フィールドが積極的に使用されているか、削除可能か、または組織内のユーザーから隠されているか（または隠されているべき）を示すために使用される。
• この項目を変更したとしても項目が非表示になったりするわけではない。
• デフォルトはActive, DeprecateCandidate, Hidden
  • Active：使用中。表示される。
  • DeprecateCandidate：廃止予定。使用されない。
  • Hidden：非表示。廃止が予定されている可能性がある。使用には注意が必要

データ所有者

• 現場のデータの分類、セキュリティ、品質に責任を持つユーザーまたはグループを示すために使用される。

2.3. CRM を効率的に機能させるためのインテグレーション要件に追加すべき主な要素を特定する*

「CRM を効率的に機能させるためのインテグレーション要件に追加すべき主な要素」とはつまり、ガバナンス（Salesforceのリーンガバナンスフレームワーク）のこと。

Salesforceのリーンガバナンスフレームワーク

リーンとは無駄がないこと。ガバナンスフレームワークとは組織がどのように運営され、意思決定を行うかのフレームワークのこと。Salesforceのリーンガバナンスフレームワークには、以下の主要なプロセスを含む。

• ビジョンと戦略：目標と戦略、プロジェクトの目的・成功の定義を決める。
• ビジネスバックログ：ビジネス要件の優先順位を決める。ビジョンと戦略と一致し、依存関係を排除する。
• ソフトウェア開発ライフサイクル：効率的な開発、デリバリプロセスを確立する。
• データ戦略・アーキテクチャ・管理：データガバナンスを実行し、遵守する。
• コミュニケーション戦略：適切な人が情報を入手し、意見を聞くことができるチャネルを確立する。

ロール*

• ビジネスユニット
  • プロジェクトのビジョンと戦略を定義
  • ビジネス要件とその優先順位を決定
  • 予算の管理
  • ユーザーのオンボーディング
  • エンドユーザーからのフィードバックの収集
  • プロダクトオーナーの指定
• テクノロジーユニット
  • ビジネスに必要な機能の作業量を正確に見積もる
  • リリース スケジュールの定義
  • システムテスト
  • システムサポート

2.4. インテグレーションソリューションの選択に影響を及ぼす可能性があるビジネスの成長要因や規制要因を特定する

データ保持ポリシ*

1. データのカタログ化（データ形式、媒体、場所、アクセスできる人など）
2. コンプライアンス分類、データ機密度、データの要否の決定
3. データのアーカイブまたは削除のためのシステムの確立

規制対象データ*

1. 規制対象データの定義
   • 法律によってプライベートまたはパブリックとして定義されるもの。B2B、B2Cで異なる規制が適用されるか。
2. 規制対象データのセクター
   • 法律によってデータがどの程度重要と認識されているかは、関連する業界セクターによって異なる可能性がある。
3. 規制対象データの量
   • 法律により、ローカルに保存できるデータの閾値、最大量が定められている場合がある。
4. 投資コストとビジネス予測
   • 規制対象データの処理に対する投資の見返りを正当化する必要がある。
5. 居住と処理の要件
   • 法律により地域外からのデータへのアクセス・処理が許可されない場合や、その他の制限がある場合がある。

プライバシーと個人データに関する国際法

• GDPR (EU および英国、2018 年発効)
• LGPD (ブラジル、2020 年発効)
• PIPL (中国、2021 年発効)

3. ニーズからインテグレーション要件への変換(22%)

• システムやインテグレーションパターンのインベントリー（目録）を作成する。
• システムやプロセスの制約を評価する。
• インテグレーションのセキュリティ要件/認証要件/認可要件を特定する。
• パフォーマンス上のニーズ (処理量、応答時間、遅延) を特定する。

3.1. システムやインテグレーションパターンのインベントリーを作成する。

• Salesforceのシステムアーキテクチャのランドスケープの種類
  • Cloud-to-Ground
    • データはSalesforceから発信され、オンプレミスシステムにプッシュされる。
  • Ground-to-Cloud
    • データはオンプレミスのアーキテクチャから発信され、Salesforceにプッシュされる。
  • Cloud-to-Cloud
    • データはあるSalesforce組織から別のSalesforce組織に移動される。
• 用語
  • DMZ：インタネットなどの外部ネットワークと社内ネットワークの中間につくられるネットワーク上のセグメント（区域）のこと。外部ネットワークからも内部ネットワークからもファイアウォールなどによって隔離されている。この隔離されたDMZ内にサーバを設置するなどによってセキュリティ強化を図れる。
  • ESB（エンタープライズ サービス バス）：接続されたシステム間でデータを送受信したり、機能を提供あるいは利用したりするミドルウェア。
  • SOA（Service Oriented Architecture）：サービスの組み合わせによってシステムを構築する設計様式。
• 参考
  • Salesforce プラットフォームの統合アーキテクチャ | Salesforce 開発者ブログ

Cloud-to-Ground

• セールスフォースからDMZへ
  • Salesforce から発信されたメッセージは、DMZサービスエンドポイント (ファイアウォール、サービスゲートウェイアプライアンス、リバースプロキシなど) に中継される。
  • インバウンド Web トラフィックに対して企業ファイアウォールを開くことはセキュリティ リスクが高いため、セキュリティ チームと緊密に協力してこの層を定義する必要がある。
  • ホワイトリストに登録された IP、双方向 SSL、および基本的な HTTP 認証は、Salesforce を DMZ レイヤーに認証する方法の一部。
• DMZからオンプレミスへ
  • DMZからのメッセージは、信頼できるオンプレミスのインフラに中継され、通常はエンタープライズ・サービス・バス（ESB）に送られ、変換、調停、オーケストレーションを処理する。
• ESBからSOAへ
  • ESBは、メッセージをWebサービスで構成されるSOAインフラに押し込むことができる。Salesforce は、これらの SOA サービスのコンシューマになることができる。
• オンプレミス データベース アクセス
  • Salesforce は、オンプレミスデータベースからリアルタイムでデータを読み込むことができる。

Ground-to-Cloud

• セールスフォースへの呼び出し
  • ESBは、Salesforceへのリアルタイムの呼び出しをすべて処理することができる。ESBがない場合、アクセスを必要とする各アプリケーションが呼び出しを処理することになる。
• バッチの設計
  • ETLツールを使用すると、Salesforceに大量のデータを一括で入出力することができる。
• データレプリケーション＆リストア
  • Salesforceのデータは、オンプレミスプラットフォームのレプリケーションコピーにオフロードすることで、後で以前の状態に復元することができる。レプリケーションは差分を処理するものであり、スケーラビリティを確保するためにテーブル全体を処理することはない。
• データベースからSalesforceへ
  • EDW（エンタープライズデータウェアハウス）からSalesforceへのデータ移行は、ETLツールで行うことができる。

Cloud-to-Cloud

• Salesforce to Salesforce
  • Salesforce to Salesforceは、複数のSalesforce組織を統合するために使用することができたが、サービスの終了が決まっている。代替としてSalesforce Connectの仕様が推奨される。
• ポイントツーポイント統合
  • ミドルウェアは、他のシステムとのポイントツーポイントの統合に使用することができる。
• クラウドベースインテグレーション
  • クラウドベースのIntegration-as-a-Serviceパッケージは、クラウドからクラウドへのユースケースを管理するために使用することができる。
• クラウドサービスバス
  • ミドルウェアは、他のクラウドベースのエンドポイントへのサービスの仲介、変換、ルーティング、およびエラー処理を行うために使用することができる。
• ESBインテグレーション
  • 企業は、クラウドからクラウドへのユースケースを含め、すべての統合をESBで仲介することができる。しかし、耐障害性の高いESBのコストは非常に高くなる可能性がある。

3.2. システムやプロセスの制約を評価する。

• システム制約
  • Salesforce またはリモートシステム内の制限や制約で、代替手法の実装が必要なもの。
• プロセス制約
  • 代替アプローチの実装を必要とするビジネスプロセスにおける制限や制約

システム制約

• セールスフォースの制約
  • 統合ソリューションに影響を与えるプラットフォームの制限やガバナ制限制限。
• リモートシステムの制約
  • ERP システムなどのリモートシステムには、必要な機能や標準をサポートしていないなど、特定の制限がある場合があります。たとえば、ERP システムが要件に対応した RESTful サービスをサポートしていない場合、拡張外部サービスは使用できない。

プロセス制約

• アクション制約
  • 特定のユーザーが必要とするアクションによる制約。項目更新で外部送信するなど。
• コンポーネント制約
  • 特定のコンポーネントを使用する制約。クイックアクションを使用してリモートシステムにデータを送信するなど。

3.3. インテグレーションのセキュリティ要件/認証要件/認可要件を特定する。

セキュリティ用語

• SSL通信：外部アプリケーションとの認証付きSSL通信で、リクエストが送信元の組織から来たものであることを確認するために使用する。
• TLS：TLS（Transport Layer Security）は、SSL（Secure Socket Layer）の改良版。
• 自己署名証明書
  • Salesforceが署名した証明書で、Salesforce組織からの通信が本物であることを証明するために使用できる。
  • プライベートネットワーク内での接続やテストなどに適している。
  • 自己署名証明書はいつでも生成、更新できる。
  • 2048ビットキーを使用した証明書の有効期間は1年で、4096ビットキーを使用した証明書は2年。
• 認証局署名証明書
  • 通信の真正性を示すために、より権威のある認証局（CA）が署名した証明書。
  • 一般公開サイトや一般公開されているシステムとの通信を保護するために使用される。
• 相互認証証明書：クライアントとサーバーが互いに身元を証明する必要がある場合に使用する証明書。SSLやTLSで相互認証を行うことができる。
• 双方向SSL/TLS
  • サーバーとクライアントの両方が、互いの身元を確認することで検証を行う。
  • クライアントがサーバーの身元を確認した後、サーバーはクライアントから渡された公開証明書を使用してクライアントの身元を確認する。
• 一方向 SSL/TLS
  • クライアントがサーバーの身元を確認することで検証を行う。
  • サーバーから渡された公開証明書を、認証局（CA）でその真偽を確認する。認証された場合、プロセスは最終的に2者間の通信を暗号化するために使用される鍵が生成さる。

セキュリティ要件

• 多要素認証（MFA）
• 信頼できるIP範囲
• セッションセキュリティ
• 外部urlリダイレクト
  • ユーザが信頼できない URL をクリックすると、リダイレクト動作が自動的にブロックされ、ユーザに警告メッセージが表示される。
• セキュティヘルスチェック
  • Salesforceが提供する設定のヘルスチェックページ。
• 監査
  • レコードの変更、ログイン履歴、フィールド履歴の追跡、設定変更履歴
• Salesforce Shield
  • Shield Platform Encryption、Event Monitoring、Field Audit Trailの3つのセキュリティツールがバンドルされてる。

認証

SSO*

• 一度のログインで複数の独立したシステムにアクセスできるようにする認証方法。
• Salesforceは、を通してSSOをサポートする。
• 外部システムをIDプロバイダーとして、Salesforceにログインするために、次の規格がサポートされている。
  • SAML（Security Assertion Markup Language）
  • OpenID Connect
  • OAuth
  • 代理認証

SAML SSOフローにおけるロール

• ユーザ：サービスプロバイダーにアクセスを要求し、認証が必要なエンドユーザー。
• IDプロバイダー：ユーザを認証するシステム。ユーザーの身元の詳細を含むSAMLアサーションをサービスプロバイダに提供するサーバー。
• サービスプロバイダー：IDプロバイダによる認証を信頼し、ユーザが要求しているサービスを提供するアプリケーション。

ジャストインタイム（JIT）プロビジョニング*

• サービスプロバイダーがSalesforceの場合、SSOで初めてログインするときに自動的にSalesforceに新しいユーザを作成する機能。
  1. IDプロバイダーがユーザの検証済みの詳細を含むSAMLアサーションをSalesforceに送信する。
  2. SalesforceのJITハンドラを使用してSAMLアサーションのデータに基づいてユーザを作成・認証する。
  3. ユーザがログインできる。
• 設定 > ID > シングルサインオン設定のSAMLシングルサインオン構成で、ユーザプロビジョニングの有効化にチェックすることで利用できる。
• カスタムJITプロビジョニング*：標準のプロビジョニングも提供されているが、Apexでプロビジョニングの処理をカスタマイズすることができる。Auth.SamlJitHandlerインターフェースを実装する。

認可

OAuthフローにおける4つのロール。

• リソースサーバー：保護されたリソースをホストするサーバー。
• リソース所有者：リソースサーバーへのアクセスを許可するエンティティ（通常はエンドユーザー）。
• 認可サーバー：認可コード、アクセストークン、リフレッシュトークンを発行するサーバー。
• クライアント（コンシューマ）：アクセストークンを使用して保護されたリソースにアクセスするアプリケーション。

用語

• 認証コード：アクセストークンと交換する一時的なコード
• アクセストークン：クライアントがリソースサーバー内の保護されたリソースにアクセスするために使用するトークン。
• リフレシュトークン：寿命が長く、新たなアクセストークンを取得するために使用されるトークン。

OAuth 認証フロー*

• OAuth 2.0 Web サーバーフロー*
  • 外部WebアプリケーションをSalesforceと統合するための承認プロセス。
  • ユーザが有効な資格情報を使用してログインすると、認証コードが発行される。
  • 認証コードと引き換えにアクセストークンを取得する。
  • アクセストークンとともに更新トークンも発行される。
• OAuth 2.0 ユーザエージェントフロー*
  • デスクトップまたはモバイルアプリケーションと統合するための認証プロセス。
  • JavaScriptなどのスクリプト言語を使用してブラウザで実行されるアプリにも適している。
• OAuth 2.0 JWT ベアラーフロー¹*
  • サーバーをSalesforceと統合するための承認プロセス。
  • JWT（JSON Web Token）をSalesforce OAuth トークンエンドポイントに送信し、JWTの検証に成功すると、Salesforceのリソースにアクセするためのアクセストークンを発行する。
• OAuth 2.0 クライアントログイン情報フロー（Winter'23）*
  • アプリケーションをSalesforceと統合するための承認プロセス。
  • コンシューマキーとコンシューマの秘密をアクセストークンと交換する。
  • このフローでは明示的なユーザ操作の必要はなくなるが、インテグレーションを実行する実行ユーザを指定する必要がある。
  • 更新トークンは発行されない。
• OAuth 2.0 デバイスフロー*
  • IoTデバイスを統合するために使用する。
• OAuth 2.0 アセットトークンフロー*
  • IoTデバイスをSalesforceAPIと統合するために使用する。
  • JWTを使用する。
• OAuth 2.0 SAML ベアラーアサーションフロー*
  • SAML 経由でアクセス トークンを要求するために使用される OAuth フロー
  • 以前の認可の署名済みSAMLアサーションを使用した認可で使用される。
• OAuth 2.0 ユーザ名パスワードフロー*
  • 外部アプリがユーザ資格情報を保存する場所で使用される。
  • ユーザの認証情報をやりとりするため、このフローの使用は推奨されない。
  • セキュリティリスクがあるため、OAuth 2.0 クライアントログイン情報フロー、OAuth 2.0 JWT ベアラーフロー、OAuth 2.0 Web サーバフローなどの異なるフローに移行する必要がある。*
• OAuth 2.0 更新トークンフロー*
  • リフレッシュトークンを使用して新しいアクセストークンを要求するために使用する。
• SAML アサーションフロー（Security Assertion Markup Language）*
  • SAML を使用したサービスの代替として使用される OAuth フロー

OAuthエンドポイント*

• OAuth 2.0 トークンエンドポイント：/service/oauth2/token
• OAuth 2.0 認証エンドポイント：/service/oauth2/authorize
  • OAuth 2.0 Web サーバフロー、OAuth 2.0 アセットトークンフローで認証コードを取得するのに使用する。
• OAuth 2.0 取り消しエンドポイント：/service/oauth2/revoke

3.4. パフォーマンス上のニーズ (処理量、応答時間、遅延) を特定する。

• 処理量
  • 「リモートプロセスの呼び出し — 要求と返信」は少量のデータをリアルタイムに扱うことに最適。
  • 「バッチデータ同期」はバルクデータ処理に適している。
  • REST・SOAP APIを使ってBLOBデータをSalesforceにアップロードする際の最大ファイルサイズは、ContentVersionオブジェクトは2GB、その他標準オブジェクトは500MB。
• 応答時間
  • 同期通信
    • リモート プロセスの呼び出し - 要求と応答
    • データの仮想化
    • リモート コールイン（実装に基づく）
  • 非同期通信
    • リモート プロセス呼び出し - Fire and Forget
    • リモート コールイン（実装に基づく）
    • バッチデータ同期

4. インテグレーションソリューションの設計(28%)

• ビジネス要件を満たすインテグレーションパターンを特定する。
• ビジネス要件を満たすソリューションを作成するコンポーネントを定義する。
• 提案したソリューションに付随するトレードオフ、制限、制約を特定する。
• 提案したソリューションに適した Salesforce API を指定する。
• 提案したソリューションにおいて使用すべき標準、コンポーネント、技法、セキュリティメカニズムを判断する。

4.1. ビジネス要件を満たすインテグレーションパターンを特定する。

※Salesforce認定 Integrationアーキテクト 試験対策メモ②

4.2. ビジネス要件を満たすソリューションを作成するコンポーネントを定義する。

• 複数選択可能な場合
  • カスタマイズを極力避ける選択をする。
  • コールアウトよりコールインを優先する。

4.3. 提案したソリューションに付随するトレードオフ、制限、制約を特定する。

※Salesforce認定 Integrationアーキテクト 試験対策メモ②

4.4. 提案したソリューションに適した Salesforce API を指定する。*

• Bulk API 2.0
  • 大規模なデータセットを非同期でインポートまたはエクスポートするために最適化されている。
• Tooling API*
  • Salesforceメタデータを他のシステム（IDEなど）と統合するために使用する。
  • 例：ソース管理、CI、Apexクラスのデプロイ、デバッグログへのアクセス、コードカバレッジ率の表示、Salesforce組織へ変更のコミット。
• Metadata API*
  • XMLファイルを使用した単純な移行を目的として、メタデータの取得、作成、更新、削除を行う。
• Streaming API
  • Salesforceから変更データキャプチャイベントまたはPushTopicイベントをサブスクライブして受信することで、外部システムがそのデータを同期できるようにするために使われる非同期ソリューション。
• ユーザーインターフェースAPI
  • SalesforceがAndroid、iOSのLightning Experienceを構築するために使用しているAPIと同じものを使用して、ネイティブモバイルアプリケーションおよびカスタムWebアプリケーション用のSalesforceUIを構築するために使用される。
• Connect REST API
  • Chatterフィード、ユーザ、グループを表示するために使用される。
• Analytics REST API*
  • データセット、レンズ、ダッシュボードなどCRM Analyticsのリソースにアクセスできる。

4.5. 提案したソリューションにおいて使用すべき標準、コンポーネント、技法、セキュリティメカニズムを判断する。

• Apex REST コールアウト、Apex SOAP コールアウト
  • デフォルトは一方向SSL。
  • 自己署名証明書とCA署名証明書の両方で双方向SSLがサポートされる。
  • WS-Securityはサポートされない。
    • Web Services Security。セキュリティを強化するためにSOAPメッセージングで使用される仕様。
  • Apex Cryptoクラスのメソッドを使用したハッシュまたはデジタル署名を使用して、要求の整合性を維持することができる。
    • Crypto.generateDigest()で作成されるハッシュを使用するとメッセージの整合性が保障される。受信側で同じアルゴリズムを使用して同一ハッシュが生成された場合、メッセージが改竄されていないことが確認できる。アルゴニズムにはMD5、SHA1、SHA256、SHA512などが使用可能。
    • デジタル署名はメッセージの信頼性と、送信者が受信したメッセージを送信したことを証明するために使用される。
• アウトバウンドメッセージ
  • デフォルトは一方向SSL。
  • 自己署名証明書とCA署名証明書の両方で双方向SSLがサポートされる。
  • Salesforce サーバーの IP 範囲は、リモート統合サーバーのホワイトリストに登録する必要がある。
• プラットフォームイベント
  • パブリッシュ：イベントエンティティに対する作成アクセス権が必要。
  • サブスクライブ：イベントエンティティに対する参照アクセス権が必要。
  • サブスクライブする外部システムはStreaming APIに認証できる必要がある。
• REST API
  • OAuth認証が必要。有効なセッションIDをSOAP APIまたはアウトバウンドメッセージで取得することも可能。
• SOAP API
  • 有効な認証情報を使用してログインをし、セッションIDを取得する。セッションIDはアウトバウンドメッセージで取得することも可能。
• Bulk API 2.0
  • OAuth認証が必要。
• SSL/TLS
  • Transport Layer Security。SSLは1999以前。
  • 通信の暗号化のプロトコル。バージョンがあるので気にかける必要あり。
• 一方向 SSL/TLS
  • 認証のないクライアントからの接続
  • サーバーサイドの証明書。クライアント認証は行われない。
• 双方向 SSL/TLS
  • 認証のあるクライアントからの接続
• 証明書
• リモートサイト設定: コールアウト
• 指定ログイン情報: コールアウト
• CSP（コンテンツセキュリティポリシー）
  • LightningコンポーネントのJavaScriptが外部サイトにリクエストを送信し、画像、スタイル、フォントなどのリソースをロードできるように設定する。
  • XSS、コードインジェクションを防止する目的。
• Shield Platform Encryption
  暗号化の仕組みの一つ。
  従来の暗号化は暗号化テキスト項目で暗号化する128ビットAESキーで保護される。
  Shield Platform Encryptionはデータの暗号化
  暗号化に使ったキーの管理

5. ソリューションの構築(23%)

• API プロバイダーとしての Salesforce と API コンシューマーとしての Salesforce の両方で、API を設計して実装する場合の考慮事項を挙げる。
• 外部システムにアウトバウンドコールを実行する適切なオプションを選択する場合の考慮事項を挙げる。
• スケーラビリティ：拡張性の高いソリューションを構築するときに考慮すべき点を説明する。
• エラー処理：さまざまなインテグレーションオプションのエラー処理を判断する。
• セキュリティ：インバウンドまたはアウトバウンドインテグレーションのセキュリティソリューションを作成する。
• エラー回復：システムの更新のためにインテグレーションソリューションのレジリエンスを高めるために必要な要因を挙げる。

5.1. API プロバイダーとしての Salesforce と API コンシューマーとしての Salesforce の両方で、API を設計して実装する場合の考慮事項を挙げる。

※Salesforce認定 Integrationアーキテクト 試験対策メモ②

• Experience Cloudで使用できる認証方法*
  • SAML シングルサインオン
  • ソーシャルサインオン
  • OAuthによる承認

5.3. 拡張性の高いソリューションを構築するときに考慮すべき点を説明する*

• 親レコードに紐づく子レコードが10,000を超えると、データスキューと呼ばれるデータ条件が発生し、クエリやトランザクションが遅延する。*
• 外部オブジェクトはデータ仮想化を実装するために使用される。これにより、データによるストレージ領域の消費が回避される。
• 共有ルールの制限
  • 所有者に基づく共有ルールは、オブジェクトあたり100までに制限されている。
  • 条件に基づく共有ルールは、オブジェクトあたり50までに制限されている。
• ロール階層は10レベル未満である必要がある。
• Batch Apexでは最大5000万件のレコードのクエリと処理が可能。
• BULK APIでは最大15GBのデータ（15個のファイルに分割される）を取得できる一括クエリを実行できる。

負荷テスト*

• ピーク時のパフォーマンス
• 応答時間
• サーバースループット：単位時間内のリクエスト数
• ハードウェアの堅牢性：CPU、メモリの安定性
• 複数実行可能なアプリケーション数

5.4. さまざまなインテグレーションオプションのエラー処理を判断する。

※Salesforce認定 Integrationアーキテクト 試験対策メモ②

5.5. インバウンドまたはアウトバウンドインテグレーションのセキュリティソリューションを作成する。

• 認証セキュリティ
• ネットワークセキュリティ
• セッションセキュリティ
• データセキュリティ
• 双方向SSL
• 暗号化
• IPホワイトリスト
• プロキシサーバー

インバウンド

• 認証
  • ユーザ名パスワードでAPIログインする場合はセキュリティトークンが必要。
  • 接続アプリケーションはOAuth、SAML、OpenID Connectなど標準プロトコルを使用してSalesforceとアプリケーションを統合する。
  • 多要素認証の使用が可能。
• ネットワーク
  • IPとログイン時間の制限をかけることが可能。
• セッション
  • HTTPS通信。
  • リクエストごとにIPアドレス範囲の検証を行う。
  • セッションタイムアウト時に自動でログアウトする。
  • クリックジャック、CSRFの対策が可能。
• データ
  • オブジェクトセキュリティ、レコードレベルセキュリティ、項目レベルセキュリティが適用される。

アウトバウンド

• 証明書
• リモートサイト設定
• 指定ログイン情報
• CSP（コンテンツセキュリティポリシー）
  • Lightningコンポーネントフレームワークでコンテンツに制限。XSS、コードインジェクションを防止。
  • 外部のサーバにリクエストを行うAPIを使用する場合にCSP信頼済みサイトに追加。
• Shield Platform Encryption
  • 暗号化の仕組みの一つ。
  • 従来の暗号化は暗号化テキスト項目で暗号化する128ビットAESキーで保護される。
  • Shield Platform Encryptionはデータの暗号化
  • 暗号化に使ったキーの管理

リモートコールアウト、アウトバウンドメッセージ

• 双方向SSL/TLS
  • 二つのシステム間の通信を保護するために使用される暗号化プロトコル。
  • サーバとクライアントの双方が自己署名またはCA署名証明書を使用してお互いの身元を検証する。
  • SSL（Security Sockets Layer）、TLS（Transport Layer Security）。SSLは1999以前。
  • 通信の暗号化のプロトコル。バージョンがあるので気にかける必要あり。
• 一方向 SSL/TLS
  • デフォルトで有効。
  • リクエストの前にクライアントのみがサーバの身元を検証する。
  • サーバーサイドの証明書。クライアント認証は行われない。
• ファイアウォール
  • 不正アクセスを防止し、脅威を特定してブロックする。
  • Salesforceからのアクセスを許可するためにホワイトリストに追加する必要があり、セキュリティ上のリスクが高い。安全にSalesforceからのアクセスを許可するには、IP許可リストを実装し、双方向SSLを使用する。
• ホワイトリストIP
  • アウトバウンドメッセージでは、SalesforceサーバのIP範囲をリモートサーバー、ファイアウォールでホワイトリストに追加する必要がある。

5.6. システムの更新のためにインテグレーションソリューションのレジリエンスを高めるために必要な要因を挙げる

※Salesforce認定 Integrationアーキテクト 試験対策メモ②

6. インテグレーションのメンテナンス(8%)

• パフォーマンス監視のニーズを特定する。
• インテグレーションに失敗した場合の適切なエラー処理、エスカレーション、復旧手順を特定する。
• インテグレーションの監視レポートのニーズを特定する。

パフォーマンス監視のニーズを特定する。*

• Salesforce Optimizer
  • Salesforce組織をスキャンし、最適化されているかを確認する。
  • 保留中のリリース更新の監視、古いAPIバージョンの使用の特定、データストレージの使用状況の確認
• リアルタイムイベントモニタリング*
  • 特定のプラットフォームイベントにサブスクライブすることで、エラーや異常をモニタリングすることができる。
    • ConcurLongRunApexErrEvent：組織が実行時間の長い同時 Apex の上限を超えたエラーを検知。
    • ApiEventStream：APIコールアウトを追跡し、経過時間、クエリ、処理された行、返された行などを確認できる。
    • ConcurLongRunApexErrEvent：組織が実行時間の長い同時Apexの上限を超えたときにエラーを検出する。
  • Event Monitoringの契約が必要。
• トランザクションセキュリティポリシー
  • イベントが基準を満たすとトランザクションセキュリティポリシーがトリガーされ、処理を実行できる。
  • Event Monitoringの契約が必要。
• イベントモニタリング*
  • 組織内で発生するユーザアクティビティ・イベントの詳細が保存される。
    • REST API Event：アウトバウンドリクエストを確認できる。リクエストのタイムスタンプ、リクエスト完了までにかかった時間、応答時間など。
    • Apex REST API Event：Apex REST API（インバウンド）のイベントを確認できる。
  • Event Monitoringの契約が必要。

インテグレーションに失敗した場合の適切なエラー処理、エスカレーション、復旧手順を特定する。*

• リモートプロセスの呼び出し — 要求と返信
  • エラー処理：呼び出し側（Salesforce）がエラー処理を行う。
  • エラー回復：成功した応答を受け取るまでSalesforceに変更をコミットしてはいけない。失敗した場合、呼び出し元は操作を再試行ができる。
• リモートプロセスの呼び出し — ファイアアンドフォーゲット
  • Apex 非同期コールアウト
    • エラー処理：リモートサービスの最初の呼び出しの例外のみを処理する。リモートサービスが例外を処理する必要がある。
    • エラー回復：リモートサービスにカスタムの再試行メカニズムを実装する。
  • アウトバウンドメッセージ
    • エラー処理：リモートシステムがエラー処理を行う。Salesforceではタイムアウト時間以内に肯定応答がないと再試行処理を行う（最大24時間以内）。
    • エラー回復：メッセージの自動再送信は最大24時間以内に制限されている。24時間以降に再送信する場合は手動で再試行する。
  • プラットフォームイベント
    • エラー処理：リモートシステムがエラー処理を実行する。
    • エラー回復：再実行IDを使用して再試行を実行する。大規模プラットフォームイベントメッセージは72時間保存されている。
• データの仮想化
  • エラー処理：呼び出し元がエラー処理を行う。
  • エラー回復：Salesforce Connectを使用する場合、Salesforce Connect Validatorツールを使用してエラーの種類と原因を確認できる。
• リモートコールイン
  • エラー処理：エラー処理はリモートシステム（呼び出し元）で行うか、ミドルウェアを使用する。
  • エラー回復：サービス品質要件に応じて、冪等設計特性に基づくカスタム再試行メカニズムを実装する。
• バッチデータの同期
  • 変更データキャプチャ
    • エラー処理：リモートサービスがメッセージのキューイング、処理、エラー処理を行う。
    • エラー回復：再試行IDを使用して再試行を開始する
  • ETLツールを使用した読み取り
    • エラー処理：インフラストラクチャ関連ではないエラーについては再試行を実装する。
    • エラー回復：エラーが繰り返される場合は、エラーログの記録、再試行、失敗時の終了、通知を行う。
  • ETLツールを使用した書き込み
    • エラー処理：レコードの識別情報、成功・失敗の通知、各レコードのエラー情報を使用して操作を再試行する。
    • エラー回復：失敗したレコードがある場合、再起動・ジョブ実行を行う。

インテグレーションの監視レポートのニーズを特定する。*

• リアルタイムイベントモニタリング
  • 異常なユーザの行動を検出するため、ApiAnomalyEventを使用できる。API関連ユーザアクティビティの異常レベルを表すScore項目が含まれていて、スコアが高いほど、異常であることを示す。
  • ApiAnomalyEvent：ユーザの異常なアクションの検知（プラットフォームイベント）
  • ApiAnomalyEventStore：ユーザの異常なアクションの検知（DB保存）
• トランザクションセキュリティポリシー
  • イベントが基準を満たしたときにカスタムの処理を実行できる。例えば、スコアが50を超えるApiAnomalyEventのトランザクションポリシーを作成できる。

参考

• 受験ガイド
• 【Salesforce公式】アーキテクトジャーニー：インテグレーションアーキテクチャ Trailmix
• 変更データキャプチャの基礎 | Salesforce Trailhead
• Welcome Architects | Salesforce Architects
• Salesforce Architects
• APIs and Integration | Salesforce Developer Center
• インテグレーションのパターンと実践 | Salesforce Developers
• Data Integration | Salesforce Architects

次
Salesforce認定 Integrationアーキテクト 試験対策メモ②

1. JWTの読み方はジョット：https://datatracker.ietf.org/doc/html/rfc7519#section-1 ↩