Takahiro Yonei @yonet77 TAOドライブ株式会社 SalesforceとHerokuのより良い関係を⽬指して （2章）

アジェンダ l このセッションの（想定）対象者 l SalesforceとHerokuについて l SalesforceとHerokuの組合せ⽅ l まとめ

⾃⼰紹介 l ⽶井 孝浩（よねい たかひろ） l TAOドライブ株式会社 エンジニア ü SalesforceとHerokuを組み合せたSIをメインにしてきました ü 今年で14期⽬となり、頑張って⽣き残りたいと思います l Salesforce DG (Tokyo)の初代リーダーです l 約2/3 Ranger です

SalesforceとHerokuについて

SalesforceとHerokuについて Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Saas Paas Iaas nSalesforce • Sales Cloud, Service Cloudなど、すぐ に使えるアプリケーションを提供して います。 • 独⾃⾔語またはNo Code / Low Code によるカスタマイズが可能。 ※ただ、プラットフォーム固有の制約 や、独⾃⾔語である点はやや不利なと ころもあります。 • No Code / Low Code / Pro Code のバ ランスを調整しながらカスタマイズす ることが重要です。

SalesforceとHerokuについて Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Saas Paas Iaas nHeroku • サポートする⾔語は幅広く、各⾔語で 形成されているエコシステムを利⽤で きるし、⾃由度が⾼いのが特徴です。 ただ、アプリケーションは⾃前で構築 する必要があります。 • Heroku Addonを利⽤することで、⾞ 輪の再発明を回避できます。 • サーバ / インフラをあまり意識しなく ても良く、アプリケーションのコアの 実装に集中できます。 • Pipeline, Github連携、Heroku CLI... など開発者体験は⾮常に良いです。

SalesforceとHerokuについて Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Saas Paas Iaas 互いの特性を理解し、 短所を補強し合って 効率よくシステムを 構築することが、 やはり⼤事だと思います。

SalesforceとHerokuの組合せ⽅（本題）

構成パターン - 今回の対象 nHerokuとSalesforceの構成としては、以下のようなパターンが挙げられますが 今回は「1」について掘り下げます # Heroku Salesforce 使⽤する主な技術 1 Webフロントエンド バックエンド REST API (Apex REST API) SOAP API GraphQL API Connect REST API Heroku Connect 2 データハブ バックエンド Bulk API Heroku Connect REST API SOAP API Salesforce Functions

構成パターン - フロントエンド＋バックエンド n2020年のセッションでは、このようなパターンについて紹介しました n今回、この構成におけるアップデートについてさらに掘り下げます

構成パターン - フロントエンド＋バックエンド n今回ご紹介する構成 ユーザ(a) 担当者 ユーザ(b) ユーザ(c) ※ ユーザの種類(a,b,c)によって サイトを分けています ユーザ管理

構成パターン - フロントエンド＋バックエンド n今回ご紹介する構成 フロント エンド バック エンド ユーザ(a) 担当者 ユーザ(b) ユーザ(c) ユーザ管理 ※ ユーザの種類(a,b,c)によって サイトを分けています

構成パターン - フロントエンド＋バックエンド nアップデートが必要となった背景 ü Auth0がAdd-onプロバイダとして撤退 l これまでIdPとして定番のAdd-onでしたが、リストから削除されました Ø Auth0を使う場合には、別途Auth0からの購⼊が必要 ü データ漏洩のリスク l 他のユーザのデータが漏洩しないよう、アプリケーション側でガードする仕組み （レコードレベルセキュリティ）が必要です Ø アプリケーション側で、何か漏れがあると重⼤事故が発⽣

構成パターン - フロントエンド＋バックエンド n対応策（1） ü Salesforce Identityサービスを利⽤ l 外部ユーザ向けとして提供しているSalesforce Customer Identityサービスを利 ⽤します • 顧客およびパートナーとのエンゲージメントを促進するためのサービス • パスワードレスログイン、セルフ登録、ヘッドレスID API ...などを提供 l 外部ユーザ向けのライセンスとして複数種が⽤意されており、制約や予算に従っ て適切なものを選択する必要があります • ライセンスの種類 » External Identity » Customer Community » Customer Community Plus » Partner Community など

構成パターン - フロントエンド＋バックエンド n対応策（2） ü Salesforceのデータアクセス管理機能を利⽤ l Salesforceの標準機能を利⽤することで、アプリケーション側での独⾃実装を回 避します l ただし、外部ユーザ向けのライセンスによって、使⽤できる機能が異なりますの で、要注意です。

構成パターン - フロントエンド＋バックエンド nユーザの登録/ログイン ü 各フロントエンドからSalesforce ヘッドレス ID API を使⽤ ヘッドレスID API ユーザ(a) 担当者 ユーザ(b) ユーザ(c) ユーザ管理 プロファイル(a) プロファイル(b) プロファイル(c)

構成パターン - フロントエンド＋バックエンド nユーザの登録/ログイン ü なぜヘッドレスID APIを使うのか？ l Experience Cloudサイトの画⾯を使わずに、提供しているサイト内で完結できる ようになります l すなわち、ユーザ登録画⾯/ログイン画⾯を⾃由に実装できるようになります ü ヘッドレスID APIを使ったユーザ登録の詳細 l （詳しくは昨年のアドベントカレンダーを参照ください） l https://qiita.com/yonet77/items/0b9f180381ed1ff21d93

構成パターン - フロントエンド＋バックエンド nヘッドレスID APIを使ったユーザ登録フロー例（⼀部抜粋） ① ② ① エンドユーザがやり取りするのは、外部 アプリケーションのみ ② 外部アプリケーションが、Salesforceと やり取りしてユーザを登録します

構成パターン - フロントエンド＋バックエンド nユーザ登録フローの構成 ① エンドユーザが⼊⼒した内容で、ユーザ 登録をリクエストします ② ワンタイムパスワードを使ってユーザ登 録を検証し、認証コードをリクエストし ます ③ 認証コードを使ってアクセストークンを リクエストします ① ② ③

構成パターン - フロントエンド＋バックエンド nデータの取得（ユーザ固有） ü ログイン時に取得したトークンを使って、直接Salesforceにリクエスト ü Salesforce側の共有ルール/共有セットに従って、アクセス可能なデータだけを取得 REST API Apex REST API ユーザ(a) 担当者 ユーザ(b) ユーザ(c) ユーザ管理

構成パターン - フロントエンド＋バックエンド nデータの取得（全ユーザ共通） ü Heroku Connectで同期したデータを取得 ü マスタ系のデータや、全ユーザへのお知らせ系のデータなど ユーザ(a) 担当者 ユーザ(b) ユーザ(c) ユーザ管理

その他 - 追加トピック(1) n Salesforceのライセンスについて

構成パターン - フロントエンド＋バックエンド n以下のヘルプより⼀部抜粋 https://help.salesforce.com/s/articleView?id=sf.users_license_types_communities.htm&type=5&language=ja https://help.salesforce.com/s/articleView?id=sf.users_license_types_external_identity.htm&type=5&language=ja ライセンス名 External Apps Customer Community Customer Community Plus Partner Community External Identity 取引先 参照/編集 参照/編集 参照/作成/編集 参照/作成/編集 参照/編集 取引先責任者 参照/作成/編集 参照/作成/編集 参照/作成/編集 参照/作成/編集 参照/作成/編集 商品 参照 参照 参照 参照 ？ 納⼊商品 参照/作成/編集 参照/作成/編集 参照/作成/編集 参照/作成/編集 参照/作成/編集 商談 N/A N/A N/A 参照/作成/編集 N/A カスタム オブジェクト 100個 10個 10個 10個(PRM SKU) 100個(External SKU) 10個 ロールと 標準共有 N/A N/A 可 可 N/A 共有セット 可 可 可 可 可

その他 - 追加トピック(2) nAuth0からの移⾏について ü Salesforceに移⾏する場合、外部ユーザだと既存のパスワードをそのまま移 ⾏することができないので、移⾏⽤の画⾯を挟むなどの追加対応が必要にな ります。 l Apexで外部ユーザを作成する際、パスワードを指定することができません。 ü 例えば、Salesforceへの初回ログイン時にはパスワードを再設定してもらう よう誘導する、など ü ユーザを移⾏する際に、ユーザ名が重複しないような⼯夫が必要 l ユーザが指定したメールアドレスだと別のSalesforce組織で、ユーザが 登録されているかも...

その他 - 追加トピック(3) nシステムの構成について ü今回のパターンでは、フロントがSalesforceとHerokuの両⽅にリクエストを投げる構成にしま したが... ユーザ(a) 担当者 ユーザ(b) ユーザ(c) ユーザ管理

その他 - 追加トピック(3) nシステムの構成について üバックエンドが、リクエストの内容によってSalesforce APIを使うか、Heroku Postgresを使う か振り分ける案もありました ユーザ(a) 担当者 ユーザ(b) ユーザ(c) ユーザ管理 APIアクセス

その他 - 追加トピック(3) nシステムの構成について ü"アーキテクチャとは、Googleで答えを⾒つけられないものだ。"

その他 - 追加トピック(3) nシステムの構成について ü"アーキテクチャとは、Googleで答えを⾒つけられないものだ。" ⽅式 フロントエンド バックエンド フロントエンドが両⽅ にアクセスする • 取得するデータによって、リ クエスト先を振り分ける必要 があり、実装上の複雑度が上 がりそう • バックエンドが停⽌しても、 salesforceが稼働してれば全て 停⽌する状況は避けられそう • リクエストを振り分ける必要 がなく、シンプルに実装でき る フロントエンドはバッ クエンドにだけアクセ スする • リクエスト先は1つとなるので、 実装は⽐較的シンプルになり そう • バックエンドを経由するので、 通信は⽐較すると遅くなる （かも） • リクエストをsalesforce / 内部 と振り分ける必要があり、実 装上の複雑度が上がりそう （その他の要因） • フロントエンドの種類 / バックエンドの種類 が今以上増えることはなさそう

その他 - 追加トピック(3) nシステムの構成について ü"アーキテクチャとは、Googleで答えを⾒つけられないものだ。" ⽅式 フロントエンド バックエンド フロントエンドが両⽅ にアクセスする • 取得するデータによって、リ クエスト先を振り分ける必要 があり、実装上の複雑度が上 がりそう • バックエンドが停⽌しても、 salesforceが稼働してれば全て 停⽌する状況は避けられそう • リクエストを振り分ける必要 がなく、シンプルに実装でき る フロントエンドはバッ クエンドにだけアクセ スする • リクエスト先は1つとなるので、 実装は⽐較的シンプルになり そう • バックエンドを経由するので、 通信は⽐較すると遅くなる （かも） • リクエストをsalesforce / 内部 と振り分ける必要があり、実 装上の複雑度が上がりそう （その他の要因） • フロントエンドの種類 / バックエンドの種類 が今以上増えることはなさそう 採⽤

まとめ l WebフロントエンドにHeroku, バックエンドにSalesforceという組合せ ü 社内業務⽤のシステムとしてSalesforceを活⽤する ü エンドユーザ向けには⾃由にデザインしたユーザ体験を実現させたいのでHerokuを 活⽤する といった組合せは、互いのメリットを伸ばし、デメリットを補うという点で良い組合 せだと考えます。 さらに、 ü Salesforceの外部ユーザ向けサービスを利⽤することで、認証基盤とレコードレベ ルセキュリティの両⽅を実現させる l ヘッドレスID APIを使って、ユーザ登録/ログインのユーザ体験をWebフロントだけで完 結できる l 標準のアクセス制御を利⽤することで、ユーザ固有のデータへのアクセスを制御 l ただし、ライセンスの選択にはよくよく検討が必要 をプラスすることで、Salesforceをさらに活⽤して、⾃由度の⾼いサービスを提供でき るようになると考えます。

END 引き続き、精進したいと思います...