note Flashcards
Salesforceユーザーは、HTTPS要求を介して外部システムからデータを読み取る必要があります。統合を保護するために統合アーキテクトがSalesforce内で活用する必要がある2つのセキュリティ方法はどれですか?
□ 認可プロバイダ
□ 名前付き資格証明
□ 双方向 SSL
□ 接続済みアプリ
□ 名前付き資格証明
□ 双方向 SSL
双方向SSL（相互認証）を使用すると、相互に相手が正当な相手かどうか検証できるのでセキュリティ強化に繋がります。
双方向SSL認証を使用するには、
「Salesforceで生成された証明書」または「証明機関 (CA) によって署名された証明書」をコールアウトと共に送信します。
ノーザントレイルアウトフィッターズは、製造システムWebサービスに注文を送信します。最近、システムの停止が発生し、数日間サービスが利用できなくなりました。このような種類のサービス停止時のエラーを処理するには、アーキテクトはどのようなソリューションを推奨する必要がありますか?
□ アウトバウンド メッセージングを使用して、失敗したサービス呼び出しを自動的に再試行します。
□ @future jobld とカスタムのスケジュールされた Apex プロセスを使用して、失敗したサービス呼び出しを再試行します。
□ プラットフォームイベントのreplayldとカスタムスケジュールされたApexプロセスを使用して、見逃したイベントを取得します。
□ ミドルウェアのキューイングとバッファリングを使用して、Salesforceをシステム停止から保護します。
□ ミドルウェアのキューイングとバッファリングを使用して、Salesforceをシステム停止から保護します。
受信者アプリケーションに何らかの理由で障害が発生した場合、送信されたメッセージはそのままメッセージキューに蓄積され、後で受信者システムが復旧したら処理が行われるため、送信者が影響を受けずに処理を続行できます。
ノーザントレイルアウトフィッターズ (NTO) は、Salesforceで夜間のデータ強化プロセスを実行する3つの外部システムの統合を検討しています。NTO には、次のセキュリティ要件と厳格な監査要件の両方があります。
1. 外部システムは最小特権の原則に従う必要があり、
2. 永続システムのアクティビティは監査に利用できる必要があります。
統合アーキテクトは、これらの統合のソリューションとして何を推奨する必要がありますか?
□ 3つの外部システム統合の共有統合ユーザー
□ 3つの外部システム統合用の共有接続アプリケーション
□ 外部システム統合ごとに一意の統合ユーザー
□ 外部システム統合ごとの接続アプリケーション
□ 外部システム統合ごとの接続アプリケーション
外部アプリケーションをSalesforceに統合する際、接続アプリケーションを利用します。
アクセス管理（権限やポリシーを設定する事で）を接続アプリケーションを通して行う事ができ
接続アプリケーションで統合したアプリケーションのログイン試行履歴は「ログイン履歴」にログとして残るので、監査にも利用可能です。
企業は、Salesforceから企業ファイアウォールの内側にある自社システムにデータを送信できる必要があります。データは一方向にのみプッシュする必要があり、リアルタイムで送信する必要はありません。平均ボリュームは1 日あたり200万レコードです。外部システムとSalesforce間の統合を構築する際に、統合アーキテクトは適切なオプションを選択する際に何を考慮する必要がありますか?
□ 大量のレコードがあるため、外部システムはBULK API Restエンドポイントを使用してSalesforceに接続する必要があります。
□ 大量のレコードがあるため、Salesforceは外部システムに対してREST API呼び出しを行う必要があります。
□ 大量のレコードがあるため、プラットフォームからレコードをステージングするにはサードパーティの統合ツールが必要です。
□ レコードの量が多いため、同時リクエストの数が外部システムへのREST API 呼び出しの制限に達する可能性があります。
□ 大量のレコードがあるため、プラットフォームからレコードをステージングするにはサードパーティの統合ツールが必要です。
APIコールアウトはリアルタイム通信、双方向に連携が可能ですが、大量データの連携には不向きです。
また、
・”データは一方向にのみプッシュする”
・”リアルタイムで送信する必要はありません”
と記載があるので、APIコールアウトを使用する必要が無い事がわかります。
サードパーティの統合ツール（CData、Asteria Worp等）は、
・大量レコードを扱える
・一方向のみに連携可能
・連携したい時のみ連携できる
・レコードをステージングできる
などの機能を備えているものがありますので、使用検討をすると良いでしょう。
サブスクリプションベースのメディア企業のシステムランドスケープでは、多くのサブスクライバーが複数のアカウントを保持し、複数回ログインする必要があります。SAML と OpenId をサポートする ID およびアクセス管理 (IAM) システムが最近実装され、セルフ登録とシングルサインオン (SSO) によって加入者のエクスペリエンスが向上しました。IAMシステムは Salesforceと統合して、新しいセルフサービスの顧客がSalesforce Community Cloud にすぐにアクセスできるようにする必要があります。Salesforce Community Cloud がセルフ登録とSSOをサポートする必要がある2つの要件はどれですか?
□ SAML SSO および登録ハンドラー
□ SAML SSO とジャストインタイムプロビジョニング
□ OpenId Connect 認証プロバイダーとジャストインタイムプロビジョニング
□ OpenId Connect 認証プロバイダーと登録ハンドラー
□ SAML SSO とジャストインタイムプロビジョニング
□ OpenId Connect 認証プロバイダーと登録ハンドラー
Amazon、Googleなどを使用したSSOをExperience Cloudサイトに実装したい場合、
認証プロバイダーの設定に、
・プロバイダータイプをOpenID Connectに指定
・登録ハンドラーを作成して指定
する必要があります。
また、ジャストインタイムプロビジョニングを使用すると、
SSOで初めてExperienceCloudサイトへログインする際に、SAMLアサーションを使用して、Salesforceユーザを自動作成してくれるため、セルフ登録の手間が省けます
Salesforceの顧客は、プラットフォームイベントを使用して、Salesforceインスタンスを外部のサードパーティの人工知能 (AI) システムと統合しました。AIシステムは、Salesforceが受け取った各リードの予測スコアを提供します。予測スコアを受信すると、リード情報が他のプロセスのプラットフォームイベントに保存されます。これが運用環境にロールアウトされると、プラットフォームイベントのトリガーが失敗します。統合コンサルタントは、この統合を監視するためにどのような種類の監視を検討する必要がありましたか?
□ Salesforceで作成されたリードの量を監視します。
□ プラットフォームイベントの定義がリードの定義と一致することを検証します。
□ パフォーマンスを監視するために、プラットフォームイベントトリガーのデバッグログを設定します。
□ Salesforceインスタンス全体で、1 時間あたりに作成されるプラットフォーム イベントの制限を監視します。
□ パフォーマンスを監視するために、プラットフォームイベントトリガーのデバッグログを設定します。
プラットフォームイベントトリガーはデバッグログにより監視する事ができる
ノーザントレイルアウトフィッターズは、注文が処理された場合に、既存の金融アプリケーションWebサービスに注文と品目を直接送信する必要があります。正確な請求を行うには、各注文が一度だけ財務アプリケーションに到達することが重要です。アーキテクトはどのようなソリューションを提案する必要がありますか?
□ トリガーは @future Apexメソッドを作成し、カスタムエラー処理プロセスを使用します。
□ トリガーは、カスタムエラー処理プロセスを使用してQueueable Apex メソッドを呼び出します。
□ ボタンを押すと同期コールアウトが呼び出され、エラーが発生した場合はユーザーが再試行を処理します。
□ サービスへのエラーの再試行を自動的に処理するアウトバウンドメッセージング。
□ トリガーは、カスタムエラー処理プロセスを使用してQueueable Apex メソッドを呼び出します。
複数注文が同時発生する事を想定して非同期処理にする必要があり、
“各注文は一度だけ到達する” という要件を考慮して、同一トランザクションに1ジョブ にする必要があります。
上記のように非同期Apexプロセスを制御したい場合は、キュー可能Apex（Queueable Apex）を使用します。
キュー可能Apexには「非同期トランザクションでSystem.enqueueJobを使用した場合、キューに追加できるジョブは1つのみ」という制限があるため、開発要件を満たす事ができます。
Lightning Webコンポーネントから外部エンドポイントへのコールアウトが失敗した場合、統合アーキテクトは最初に何を検証する必要がありますか?
□ エンドポイントURLが送信ファイアウォールルールに追加されたか。
□ エンドポイントURLがリモートサイト設定に追加されたか。
□ エンドポイントドメインがクロスオリジンリソース共有に追加されたか。
□ エンドポイントURLがコンテンツセキュリティポリシーに追加されたか。
□ エンドポイントURLがリモートサイト設定に追加されたか。
コールアウトの失敗が発生している場合、
リモートサイトの設定で外部エンドポイントが正しく設定されているか確認する事が推奨されています。
Apexからのコールアウトには設定は必須。
CORSはLWCから直接APIコールするなら必須かも。
顧客は、Bulk APIを使用して外部システムからSalesforceにデータをインポートします。これらのジョブのバッチサイズは2000で、並列モードで実行されます。「最大CPU時間を超えました」というエラーでバッチが頻繁に失敗します。バッチサイズを小さくすると、このエラーが修正されます。より小さいバッチサイズを使用する場合に考慮すべきオプションはどれですか? 答えを2つ選択してください
□ バッチサイズが小さいと、レコードロックエラーが発生する可能性があります。
□ バッチサイズが小さいと、同時API要求の制限を超える可能性があります。
□ バッチサイズを小さくすると、一括ジョブの実行に必要な時間が長くなる場合があります。
□ バッチサイズが小さいと、「同時実行バッチが多すぎます」というエラーが発生する可能性があります。
□ バッチサイズが小さいと、同時API要求の制限を超える可能性があります。
□ バッチサイズを小さくすると、一括ジョブの実行に必要な時間が長くなる場合があります。
20秒以上のAPI要求にはAPI同時要求数に制限があります。
バッチサイズを小さくした事により同時要求数が増えて、制限を超える可能性があるので注意が必要です。
また、バッチサイズには
・1バッチ5分以上かかるなら小さくする
・1バッチ数秒で完了するなら大きくする
のように適正なサイズがあります。
数秒で完了するバッチを小さくしてしまうと、むしろ時間がかかる可能性があるので考慮に入れましょう。
統合アーキテクトは、REST APIを使用して、取引先、連絡先、その他の関連情報を更新するソリューションを構築しました。データ量が増加したため、API呼び出しの消費量が増加し、制限を超える日もあります。一括更新を使用してAPI呼び出しの数を減らすことが決定されました。お客様は、アーキテクチャの変更を避けるために、引き続きREST APIを使用することを希望しています。1回のAPI呼び出しで最大200レコードを許可するには、統合アーキテクトはどのREST API複合リソースを使用する必要がありますか?
□ バッチ
□ 複合
□ Sオブジェクトツリー
□ SObjectコレクション
□ Sオブジェクトツリー
sObjectツリーは、ルートレコード内にそのデータ、およびその子レコードのデータを含める事ができる再帰的データ構造です。
sObjectツリーを使用してAPI連携を行うと、1回の要求でリクエストボディに最大200レコードを含める事ができます。
ノーザントレイルアウトフィッターズ (NTO) は、サービスを提供する34か国ごとに異なる配送サービスを使用しています。配送時間とコストを最適化するために、サービスは頻繁に追加および削除されます。営業担当者は世界中のすべてのNTO顧客にサービスを提供しており、顧客の国に有効なサービスの中から選択し、そのサービスから配送見積もりをリクエストする必要があります。アーキテクトはどの2つのソリューションを提案する必要がありますか?
□ プラットフォームイベントを使用して、配送業者固有のイベントを構築および公開します。
□ ミドルウェアを使用して、特定の配送サービスへの呼び出しを抽象化します。
□ ミドルウェアサービスを呼び出して、有効な配送方法を取得します。
□ 国の選択リストに依存する選択リストに配送サービスを保管します。
□ ミドルウェアを使用して、特定の配送サービスへの呼び出しを抽象化します。
□ ミドルウェアサービスを呼び出して、有効な配送方法を取得します。
“サービスは頻繁に追加および削除されます” とあるので、拡張性やメンテナンス性、監視等を考慮してミドルウェアを使用した統合を提案しましょう。
ミドルウェアを使用すると
・Salesforceからミドルウェアへ「地域情報」を合わせてリクエスト送信
・ミドルウェアはどの地域の配送システムへ送信するか振り分けを行う
こと（コールアウトの抽象化）ができて、ミドルウェアが配送システムからレスポンス（見積や配送方法等の情報）を取得してSalesforceへAPIで書き込む事が可能です。
ノーザントレイルアウトフィッターズのセールスオペレーションチームは、毎日新しいリードをインポートしています。統合された従来のテリトリー管理システムは、営業チームのメンバーがテリトリーに取り組む前に、テリトリーをリードに割り当てます。現在の統合では、遅延の問題が頻繁に発生します。統合パフォーマンスを向上させるためにアーキテクトが行うべき2つの推奨事項はどれですか?
□ 非同期BULK APIのバッチサイズを削減します。
□ 同期BULK APIのバッチサイズを削減します。
□ レガシーシステムは並列モードで送信する必要があります。
□ レガシーシステムはシリアルモードで送信する必要があります。
□ 非同期BULK APIのバッチサイズを削減します。
□ レガシーシステムは並列モードで送信する必要があります。
“遅延の問題” がBulkAPIの逐次（シリアル）モードでの実行だった場合、高速に処理できる並列モードで送信しましょう。
また、”遅延の問題” が並列モード（非同期BulkAPI）でのレコードロック競合の場合、バッチサイズを小さくする事でレコードロックを回避できる可能性があります。
Universal Containers (UC) は、世界的に管理トレーニングを提供する大手プロバイダーです。UCは、Salesforce学生コミュニティから生成された学生のコース登録データを学習管理システム (LMS) と同期するよう要求しました。履修登録データの更新はLMSに反映する必要があります。要件を満たすにはどの統合メカニズムを使用する必要がありますか?
□ アウトバウンドメッセージ
□ プラットフォームイベント
□ 変更データキャプチャ (CDC)
□ ストリーミングAPI
□ ストリーミングAPI
プラットフォームイベントは、少量データを非同期に他システムと連携する場合に使用し、
変更データキャプチャは、他システムにSalesforceの1オブジェクトだけ、かつ、該当オブジェクトのレコード全てを反映させる場合に使用しますが、問題文に “学生” の “コース登録データ”、”履修登録データ” とあるので、複数オブジェクトの登録と更新が必要で、大量データになる事が想定されるので誤りと判断できます。
上記のような制約が無く、Subscribe（更新があった場合だけ通信してデータ連携）できるStreaming APIが適しています
ノーザントレイルアウトフィッターズのSSL相互認証を使用している企業ポータルからSalesforceへの統合を確実にするためにアーキテクトは何を推奨すべきか?
□ [私のドメイン]とSSL/TLSを有効にします。
□ SSL/TLS相互認証を適用権限を設定します。
□ 自己署名証明書を生成します。
□ CA署名付き証明書を生成します。
□ SSL/TLS相互認証を適用権限を設定します。
外部システム（企業ポータル）→ Salesforceの通信に相互認証を設定する場合、API限定ユーザーに「SSL/TLS相互認証の適用」権限を設定する必要があります
Universal Containers (UC) は、Salesforceを含むさまざまなクラウドベースのアプリケーションと、いくつかのオンプレミスアプリケーションを所有しています。オンプレミスアプリケーションは、企業ネットワークの背後で保護され、外部システムへの外部アクセスは制限されています。UCは、オンプレミスアプリケーションからSalesforceにデータを公開して、より統一されたユーザーエクスペリエンスを提供したいと考えています。データは、Salesforceからリアルタイムでアクセスできる必要があります。このシステム要件を満たすために推奨されるアクションはどれですか? 答えを2つ選択してください
□ 会社のネットワーク上で、Salesforceから呼び出し可能なカスタムAPI を開発します。
□ MuleSoftをオンプレミスネットワークにデプロイし、外部向けAPIを設計してデータを公開します。
□ オンプレミスサーバーからETLツールを使用してバッチジョブを実行し、データをSalesforceに移動します。
□ ODBC文字列とVPC接続を介してオンプレミスデータベースに接続するアプリケーションをHerokuで開発します。
□ 会社のネットワーク上で、Salesforceから呼び出し可能なカスタムAPI を開発します。
□ MuleSoftをオンプレミスネットワークにデプロイし、外部向けAPIを設計してデータを公開します。
「さまざまなクラウドベースのアプリケーション」「いくつかのオンプレミスアプリケーション」とあるので、Mulesoftなどのミドルウェアを使用して各アプリケーションの統合を進めた方がメンテナンス性や拡張性、運用監視等の点から良いでしょう。
オンプレミスアプリケーション → Salesforceへデータ連携（リモートコールイン）する場合は、外部向けSalesforce APIを外部システムがコールできるようにする必要があります。
Salesforce → 外部アプリケーションへ連携（コールアウト）する場合は、Apex REST/SOAP APIによるカスタムAPIを開発してリモートプロセスを呼び出せるようにします。
Northern Trail Outfitters は、外部のMicrosoft Azure API Gatewayとの統合をセキュリティで保護する必要があります。どのような統合セキュリティメカニズムを採用する必要がありますか?
□ CA発行の証明書を使用して、双方向SSLで相互サーバー認証を構成します。
□ APIゲートウェイの承認エンドポイントを使用して接続アプリケーションを構成し、OAuth設定を構成します。
□ APIのみのユーザープロファイルを使用し、フェデレーションAPIアクセスで外部IDプロバイダーの使用を実装します。
□ 保存時の暗号化を使用して Salesforce Shieldを実装し、テナントの秘密を生成します。
□ APIゲートウェイの承認エンドポイントを使用して接続アプリケーションを構成し、OAuth設定を構成します。
外部APIゲートウェイへ認証を提供するためには、接続アプリケーションを使用します。
接続アプリケーションは、OAuthなどの標準プロトコルを使用して、外部アプリケーションをSalesforceに統合できるようにするフレームワークです。
統合アーキテクトが統合ソリューションとしてPlatform Eventを推奨する際に考慮すべき3つの考慮事項はどれですか?
□ イベント定義が削除されると、その定義は完全に削除され、復元できなくなります。
□ イベントモニタリングは、ログインやレポートの実行などのユーザー アクティビティを追跡するために使用されます。
□ AssetTokenEventストリームをサブスクライブして、OAuth 2.0認証アクティビティを監視します。
□ プラットフォームイベントのLightningレコードページを作成できません。
□ SOQLを使用したイベントメッセージはクエリできません。
□ イベント定義が削除されると、その定義は完全に削除され、復元できなくなります。
□ プラットフォームイベントのLightningレコードページを作成できません。
□ SOQLを使用したイベントメッセージはクエリできません。
ヘルスケア サービス会社は、安全なデータベースに5,000万件以上のレコードを保管する患者処方箋システムを維持しています。その顧客ベースとデータセットは急速に成長しています。同社は、次のポリシーが確実に施行されるようにしたいと考えています。
1. 識別可能な患者の処方箋は、会社の安全なシステムのデータベースにのみ存在し、暗号化されて保存されている必要があります。
2. 識別可能な患者の処方箋は、患者処方箋システムで明示的に許可された人のみが利用できるようにする必要があります。割り当てられた看護師と医師、患者、および患者によって権限を与えられた人々。
3. 検証および事前承認された個人または法人のみが利用できる必要があります。
これを可能にするために、同社は次の機能を提供します。
* 患者、看護師、医師、その他の人々向けに、数分以内に期限切れになる1回限りのIDトークンを使用します。
* 法人の証明書。
* RESTfulサービス。
同社には、患者、看護師、医師、その他の権限のある人向けの Salesforce Community Cloud ポータルがあります。限られた数の従業員が Einstein Analyticsで匿名化されたデータを分析します。統合アーキテクトが Community Cloud ポータルと Einstein Analytics に必要とする2つの機能はどれですか?
□ 転送中および保存中の暗号化
□ IDトークンデータストレージ
□ Einstein Analyticsの一括ロード
□ RESTfulサービスへのコールアウト
□ Einstein Analyticsの一括ロード
□ RESTfulサービスへのコールアウト
患者処方箋システムには
・”1回限りのIDトークン” → ワンタイムパスワード
・”法人の証明書” → 認証/セキュリティ設定
・”RESTfulサービス”
の機能があるとの事なので、
Salesforceコミュニティから患者処方箋システムを呼び出すために、RESTfulサービスへのコールアウトが必要になります。
また、Einstein Analyticsでデータ分析するためには患者データの取り込みを行わなければなりません。
そのため、患者処方箋システムのデータをEinstein Analyticsへデータ転送/データロードする機能も必要になります
ある企業は、さまざまなソースから集約されたトランザクションを表示する Lightning Webコンポーネント (LWC) を設計しています。現在のシステム状況は次のとおりです。
1. トランザクションは、さまざまなオンプレミスおよびクラウドベースのシステムを通じていつでも作成されます。
2. 必要なトランザクションはすべて、Salesforceのカスタムトランザクションオブジェクトにレプリケートされます。定期的に更新されるため、更新の間に必要なトランザクションのサブセットのみが含まれます。
3. ミドルウェアはパブリッシュとサブスクライブの対話をサポートし、オンプレミスおよびクラウドベースのシステムからトランザクションを取得できるRESTfulエンタープライズAPIを提供します。
同社は、LWCコンポーネントに表示される不完全なデータに関するユーザビリティの問題に対処したいと考えています。LWCが必要なトランザクションをすべて表示できるようにするには、統合アーキテクトは何を指定する必要がありますか?
□ カスタムオブジェクトレコードが変更されたときに、@wireアダプタを使用してLightningデータサービスに新しい値を表示させます。
□ Continuationクラスを使用してエンタープライズAPIを呼び出し、コールバックメソッドで応答を処理します。
□ LWCのJavaScriptコードから直接エンタープライズAPIを呼び出し、API応答の受信時にLWCを再表示します。
□ プラットフォームイベントを発行し、ミドルウェアにサブスクライブさせ、プラットフォーム イベントの受信時にカスタムオブジェクトを更新します。
□ Continuationクラスを使用してエンタープライズAPIを呼び出し、コールバックメソッドで応答を処理します。
現状は、LDSワイヤーアダプター（@wireアダプタ）で、カスタムトランザクションオブジェクトのレコードをLWCに表示している状況と考えられますが、この方法だと “データが不完全” だと言っているので、@wireアダプタを使用した選択肢は誤りと判断できます。
問題の根本原因は「データ不十分」という点なので、
データ表示するタイミングで、ミドルウェアにRest APIをコールアウトして最新の応答結果をカスタムオブジェクトに反映する必要があり、Continuationクラスを使用してREST Webサービスに対して非同期コールアウトを実行する必要があります。
ノーザントレイルアウトフィッターズは、見込み客から商談へのプロセスを使用してアカウントを作成するためのフロントエンドとしてSalesforceを使用したいと考えています。
1. 商談が成立して受注すると、Salesforceで注文が作成されますが、バックエンドERPシステムが注文のデータマスターになります。
2. 顧客は、注文の作成、保存期間内の注文が発送済み、支払い済みの注文などの注文処理のすべての段階をSalesforce内で確認できるようにしたいと考えています。これらのビジネス要件を満たすソリューションを設計する際に、統合アーキテクトがメッセージの耐久性について考慮すべき2つの点はどれですか?
□ 大規模イベントメッセージは24時間 (1日) 保存されます。
□ 大規模イベントメッセージは72時間 (3日) 保存されます。
□ Salesforce Eventバスをサブスクライブする場合、新しいイベントを表示できるように、値-1を指定してReplayIDが使用されます。
□ Salesforce Eventバスをサブスクライブする場合、古いイベントと新しいイベントを表示できるように、値-2を指定してReplayIDが使用されます。
□ 大規模イベントメッセージは72時間 (3日) 保存されます。
□ Salesforce Eventバスをサブスクライブする場合、古いイベントと新しいイベントを表示できるように、値-2を指定してReplayIDが使用されます。
ストリーミングイベントには、標準イベント（PushTopicイベント、汎用イベント）と大規模イベント（プラットフォームイベント、変更データキャプチャ）があり、
イベントメッセージは
・標準イベントの場合は24時間
・大規模イベントの場合は72時間
イベントバスに保存されます。
イベントバスに保存されたイベントメッセージは再実行オプションを指定してサブスクライブしますが、
その際、再実行オプションに「-2」を指定する事で、保存期間内の過去イベントと新規イベントを両方取得できるようになります。
ノーザントレイルアウトフィッターズ (NTO) は、Salesforce Lighting Experienceの参照項目を備えたネイティブの従業員向けモバイルアプリケーションを作成することを計画しています。モバイルアプリはNTOの Salesforce組織と統合する必要があります。この統合を実装するにはどの Salesforce APIを使用する必要がありますか?
□ REST API
□ REST API に接続する
□ ストリーミング API
□ ユーザーインターフェース API
□ ユーザーインターフェース API
モバイルアプリケーションでボタンを複数回クリックしてしまう事があると思いますが、そのような場合を考慮して冪等性が重要になります。
（冪等性とは、同一の要求が1回おこなれた場合でも複数回行われた場合でも、サーバー上のレコードは同じ状態のままになる事を言います。）
ユーザーインターフェースAPIを利用すると、冪等レコード書き込みを行うのでレコード重複を防止でき、モバイルアプリケーションにも適用できます
お客様はプラットフォームイベントソリューションを評価しており、同期/非同期のニーズに合わせてアウトバウンドメッセージングと比較/対照する際の支援を求めています。彼らは、3,000人の顧客がSalesforceでメッセージを表示すると予想しています。どちらのソリューションを選択するかを決定する際に、評価して強調すべき3つの考慮事項はどれですか?
□ プラットフォームイベントの同時サブスクライバーの数は2,000に制限されています。アウトバウンドメッセージング構成では、1つのメッセージで 100件の通知のみをSOAPエンドポイントに渡すことができます。
□ プラットフォームイベントとアウトバウンドメッセージングの両方で、イベントメッセージは1回だけ再試行され、順番に配信されます。Salesforce は、メッセージが重複して配信されないようにします。
□ プラットフォームイベントとアウトバウンドメッセージングはどちらも拡張性が高くなります。ただし、アウトバウンドメッセージングとは異なり、考慮すべきイベント配信およびイベント発行の制限があるのはプラットフォームイベントのみです。
□ メッセージのシーケンスはアウトバウンドメッセージングでは可能ですが、プラットフォームイベントでは保証されません。どちらも非常に高い信頼性を提供します。障害の処理と回復はSalesforceによって完全に処理されます。
□ プラットフォームイベントとアウトバウンドメッセージングはどちらも、非同期のほぼリアルタイムのニーズに対応する宣言型の手段を提供します。これらはリアルタイム統合には最適ではありません。
◻︎プラットフォームイベントの同時サブスクライバーの数は2,000に制限されています。アウトバウンドメッセージング構成では、1つのメッセージで 100件の通知のみをSOAPエンドポイントに渡すことができます。
◻︎ プラットフォームイベントとアウトバウンドメッセージングはどちらも拡張性が高くなります。ただし、アウトバウンドメッセージングとは異なり、考慮すべきイベント配信およびイベント発行の制限があるのはプラットフォームイベントのみです。
◻︎メッセージのシーケンスはアウトバウンドメッセージングでは可能ですが、プラットフォームイベントでは保証されません。どちらも非常に高い信頼性を提供します。障害の処理と回復はSalesforceによって完全に処理されます。
プラットフォームイベントのサブスクライバーの最大数は2000で、イベント制限があるのはプラットフォームイベントのみです。
アウトバウンドメッセージは、1つのSOAPメッセージに100件の通知を格納でき、キューに格納して順序保障するのはアウトバウンドメッセージだけです。
複数の国で事業を展開している大手消費財メーカーは、世界中の販売およびサポート業務にSalesforceを導入することを計画しています。これらには次のセキュリティ要件があります。
1. 各国の内部ユーザーは、ローカルのActive Directoryで認証される必要があります。
2. お客様は独自のログインを作成するか、Googleログインを使用できます。
3. パートナーは、決定される中央システムを通じて認証される必要があります。
4. 内部ユーザーは、ERPで保持されている資格情報を使用して中央ERPにアクセスできます。
5. 追加の内部システムは、販売およびサポートのビジネスプロセスのために Salesforceと統合されます。
統合アーキテクトは、このプロジェクトの統合ニーズを設計する際に、どの 3つの要件を評価する必要がありますか?
□ 内部ユーザー向けのサードパーティソリューションを使用して、顧客およびパートナー向けのSalesforceソリューションを評価します。
□ 社内システムのセキュリティ要件を評価し、その要件をサポートする統合方法を決定します。
□ 各国のユーザー向けのカスタム認証メカニズムの構築と顧客とパートナーのサポートを評価します。
□ 顧客とパートナーを含むすべてのユーザー認証をサポートするサードパーティのシングルサインオンソリューションを検討してください。
□ 顧客やパートナーを含むすべてのユーザのSalesforceネイティブ認証メカニズムを評価します。
□ 社内システムのセキュリティ要件を評価し、その要件をサポートする統合方法を決定します。
□ 各国のユーザー向けのカスタム認証メカニズムの構築と顧客とパートナーのサポートを評価します。
□ 顧客やパートナーを含むすべてのユーザのSalesforceネイティブ認証メカニズムを評価します。
要件を整理すると
①内部ユーザー → Active Directoryで認証
②顧客 → 独自ログイン or Googleログイン使用するか検討中
③パートナー → ERPにある資格情報（ID,PS）を利用して中央システムで認証
④営業、サポートのビジネスプロセスはSalesforceに統合
となります。
Salesforceには、
・SalesforceをIdP、SPどちらにする事も可能
・SAML SSOによるシングルサインオンも可能
・SalesforceユーザーでID,Pass管理可能
のようなネイティブ認証メカニズムが存在するので、
まずは、Salesforceのネイティブ認証メカニズムを使用して、全ユーザーの認証統合ができないか、評価＆検討を行いましょう。
次に、独自ログイン機能の要件に対しての評価と検討です。
・ワンタイムパスワードを用いた多要素認証
・生体認証
のような認証が各国で個別に必要になる場合は、カスタム認証メカニズムの構築が必要になるでしょう。
最後にビジネスプロセスの統合についてです。
・内部3rdパーティーシステムからビジネスプロセスをコールアウトするか?
・ミドルウェアを介して外部APIを呼び出すか
・相互認証が必要か
などのセキュリティ要件や統合方針に関しても評価検討が必要となります。
アーキテクトは、サービスがAPIを介してSalesforceにアクセスできるようにするソリューションを構築するように求められます。アーキテクトが最初にやるべきことは何ですか?
□ 既存のシングルサインオンを使用して統合を認証します。
□ 統合目的のみに特別なユーザーを作成します。
□ システム管理者プロファイルを持つ新しいユーザーを作成します。
□ 既存のネットワークベースのセキュリティを使用して統合を認証します。
□ 統合目的のみに特別なユーザーを作成します。
APIを介した統合の場合、セキュリティを考慮して、まず最初にAPI限定ユーザーを作成する必要があります。
