11
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

HerokuAdvent Calendar 2020

Day 21

Salesforce 認定 Heroku Architecture デザイナー試験の個人的な躓きポイント

Last updated at Posted at 2020-12-20

こんにちは。Heroku Advent Calendar 2020 の 21日目のエントリになります。

はじめに

Salesforce 認定 Heroku Architecture デザイナー の対策を進めています。

日本語のガイド: https://tandc.salesforce.com/examguide_cert_heroku_architecture_designer.pdf

このエントリを書いている 2020年11月時点で 3回落ちていますので、次は4回目の挑戦になります。
1回目は2019年8月のベータ試験の時代に英語で受験(正答率:58%)、
2回目は2020年11月に日本語で受験(正答率:68%)。
3回目も2020年11月に日本語で受験(正答率:65%)。

ボーダラインは 72% ですので、あと一息です。次こそ合格するべく、苦手な単元を整理していきたいと思います。

苦手な単元

2回目の試験結果を見ると、ボーダラインに達していない単元が4つありました。

  1. [50%] Data(データ)
  2. [66%] Security(セキュリティ)
  3. [66%] Architecting Applications(アプリケーションのアーキテクチャ構築)
  4. [66%] Integrations(インテグレーション)

3回目の試験結果を見ても、ボーダラインに達していない単元が4つありました。しかも2回目と入れ替わってるものもある:frowning2:

  1. [66%] Heroku Platform(Heroku プラットフォーム)
  2. [60%] Data(データ)
  3. [58%] Heroku Enterprise(Heroku Enterprise)
  4. [55%] Integrations(インテグレーション)

試験中は結構自信ありで回答していたため、重要なところで勘違いしていると思われます。
受験ガイドの試験範囲を見ながらキーワードを深掘りしていきます。

1. Heroku Platform

出題内容

  • スラッグ作成時のビルドパックの役割など、Heroku でのアプリケーションの構築およびリリースに関する基本事項を理解していることを示す。
  • トラフィックのピーク時でも高いパフォーマンスのスケーラブルなソリューションを設計する。
  • Elements Marketplace で入手したアドオンやその他のコンポーネント(ビルドパック、Heroku ボタン)を使用してソリューションを設計してリリースする。

スケーラブルなソリューション

トラフィックのピーク時の対処法

  • Auto Scaling させる。
    • Private Space Runtime の private dyno にする。
    • Common Runtime の Performance tier の dyno にする。
      • Performance tier : performance-mperformance-l
  • Manual Scaling する。
    • Resource タブから手動で Standard tier または Performance tier の dyno (Professional dyno) にする
  • Dyno Type を変更するときの考え方
    • Vertical Scaling:standard-1x から standard-2x に変更すると、プロセス/スレッドの最大値が 2 倍になる。
      • 更に読み取り専用のフォロワーデータベースを作成してアプリに参照させることを検討する。
    • Horizontal Scaling:standard-1x から performance-m に変更すると、プロセス/スレッドの最大値が 64 倍になる。
    • Free / Hobby / Standard はインスタンスが共有されている。
    • Performance / Private はインスタンスが独立している。

時間のかかるバックグラウンドタスク

  • バックグラウンドジョブ、キューイングシステム、時間指定のあるジョブは Worker dyno にする。
  • 長時間のタスクを分離するために Heroku Redis のキュー に追加する。
  • 一時的なバックグラウンド処理は One-off dyno にする。

Elements Marketplace

  • アドオンのマーケットプレイスにあるのは、アドオン、ビルドパック、ボタンの 3 つ。
  • アドオンによっては Available だが Installable in Private Space でないリージョンがある。

2. Data

出題内容

  • Heroku Postgres の知識 (データ処理、セキュリティ、フォロワーデータベースを使用する一般的なユースケースなど) を示す。Dataclips のユースケースを説明する。
  • Apache Kafka on Heroku を使用して、アプリケーション、サービス、機能間のストリーミング通信を促進するソリューションを設計する。
  • Heroku Redis を使用してソリューションを設計する。
  • 必要に応じて、サードパーティのアドオンやアドオン共有を取り入れられることを示す。

Heroku Postgres

  • プランは Dyno に似ている:hobbystandardpremiumenterprise の 4 つ。
  • 1つのデータベースを複数のアプリで利用して良い。

フォロワーデータベース

  • 目的
    • リーダー - フォロワー設定による読み取りスループットの向上
    • ホットスタンバイによる追加の可用性
    • レポーティングデータベースとしての役割
    • シームレスな移行とアップグレード
  • Hobby tier では作成不可。
  • アプリ横断でフォロワーデータベースを作成可能。
  • フォロワーに対するフォロワーデータベースは作成不可。
  • 自動フェールオーバー(リードデータベースが利用不可となった場合、フォロワーデータベースが自動的にリードデータベースになる)が必要な場合、Heroku Postgres の Premium tier または Enterprise tier を契約する。
  • データベースをアップグレードしたい場合
    1. フォロワーデータベースを上位プランで作成する
    2. アプリをメンテナンスモードにする
    3. フォロワーデータベースをリードデータベースに昇格させる
    4. アプリを再開する

フォークデータベース

  • フォロワーデータベースにてフォロー解除 heroku pg:unfollow することでフォークデータベース(その時点までに受け取ったすべてのデータを含むフル読み取り/書き込みデータベース)となる。
  • 本番データを利用したテストに利用できる。

Dataclips

  • Heroku CLI または Heroku Dashboard 経由でアクセス可能。
  • 共有可能リンク URL へのアクセスは Heroku ログインユーザ以外も可能。
  • Shield tier の Heroku Postgres には Dataclips 作成不可。
  • Dataclips の JSON URL に対する GET リクエストにおいて Cross-Origin Resource Sharing をサポートする。

Apache Kafka on Heroku

  • 概要
    • Producer は Broker にデータ(streams of messages)を書き込む。
    • Consumer は Broker からデータを読み取る。
    • データは Topic に格納される。
    • Topic は Partition に分割される。
    • Partition 内の message の順序は保証される。
    • Partition 間の message の順序は保証されない。
  • AWS Private Link​ を使用して、AWS VPC と、Private Space​ または Shield Private Space​ にプロビジョニングされた Apache Kafka on Heroku アドオンの間の安全な接続を作成する。

Heroku Redis

  • ユースケース
    • Job Queues
    • Caching
    • Session Storage
  • Heroku Redis 自体には、SSL などのメカニズムでネットワーク上を通過するデータを暗号化する機能はない。
    • Dyno と Heroku Redis インスタンスの間に SSL トンネルを作成するために、Stunnel buildpack をインストールする。
  • Private Space の Heroku Redis インスタンスにアクセスするには、Heroku Redis CLI コマンドを使用する。
  • Shield Private Space の Heroku Redis には外部接続不可。
  • AWS Private Link​ を使用して、AWS VPC と、Private Space​ または Shield Private Space​ にプロビジョニングされた Heroku Redis アドオンの間の安全な接続を作成する。
  • インスタンスがストレージ制限に到達した場合、​キー追い出しのポリシー ​を見直す。

サードパーティのアドオン

  • Marketing Cloud Connector
    • REST API と SOAP API で Marketing Cloud と連携する

アドオン共有

  • heroku addons:attach​ コマンドを使用して、単一の Heroku Postgres データベースを複数のアプリ間で共有可能。

3. Security

出題内容

  • Heroku を利用してさまざまなセキュリティ認証を取得するアーキテクチャを構築する。
  • 適切なユースケースに Heroku Private Space Peering や VPN Connections を推奨する。
  • アプリケーションを Private Space Runtime で実行すべきか、Common Runtime で実行すべきかを提案する。

セキュリティ

  • カスタムドメインで SSL (Secure Sockets Layer) を有効化する方法
    • Automated Certificate Management
      • Common Runtime
      • SSL は無料。
      • 無料の Let's Encrypt の TLS (Transport Layer Security) 証明書を利用できる。
      • 証明書は自動更新。
    • Heroku SSL
      • 有償の dyno で無料の SSL。
      • 自前で購入した TLS 証明書を利用できる。
      • 証明書は自前で更新必要。
      • TLS プロトコルを拡張した SNI (Server Name Indication) を利用するので、古いブラウザはサポート対象外。
    • SSL Endpoint
      • Common Runtime で有償の SSL。
      • Private Spaces Runtime で無料の SSL。
      • 古いブラウザもサポート対象。
      • TLS 1.0 や 1.1 を無効化できる。
  • Private Spaces と Shield Spaces のアプリ
    • SNI を使うために TLS 接続が必要
    • クライアントとの TLS 接続をやりとりするために使用する暗号スイートを選択できる。
      • spaces-tls-salesforce:Salesforce の TSL ガイドラインに準拠
      • spaces-tls-modern:TSL 1.2 のみ
      • spaces-tls-legacy:レガシーで必要な場合のみ
      • spaces-strict-tls:非推奨
    • Trusted IP でアプリへの外部からのアクセスを制限できる。
      • Space あたりデフォルトで 20 個まで
  • SSO
    • SAML 2.0 に準拠
    • セッションは 8 時間続く
    • Account レベル及び Team レベルで SSO 設定が可能。
  • Keystroke Logging
    • Shield Private Spaces のみで利用できる。
    • Private Space の作成後に Private Space Logging を有効にすることはできない。
  • Internal Routing が有効化されたアプリ
    • アプリ作成時に有効化する必要がある。
    • 外部からアクセスできない。
    • 同じ Space 内のアプリからアクセスできる。
      • そのアプリに対して Trusted IP で外部からアクセスすることで間接的に Internal Routing が有効化されたアプリにもアクセスできるようになる。
    • VPC Peering 接続済みのネットワークからアクセスできる。
    • VPN 接続済みのネットワークからアクセスできる。
  • ログ
    • Heroku Postgres のベースバックアップと書き込みログは同じリージョンに格納される。
    • アプリケーションログは US リージョンに格納される。
      • Shield Private Spaces であれば、Private Space Logging で同じリージョンを選択できる。
    • Heroku Postgres のバックアップスナップショットは US リージョンに格納される。
    • Dataclips は US リージョンに格納される。
    • アドオン製品がどこにデータを格納するかを Heroku 側でコントロールしない。
  • Shield Postgres
    • Trusted IPs for data は対応していない。
    • Heroku Dataclips は対応していない。
    • PB Backup PGBackups は対応していない。 :writing_hand: 2023/09/08 修正

相互 TLS vs Private Link

  • Heroku Postgres
    • 相互 TLS で AWS VPC 以外からも接続できる
    • Private Link で AWS VPC のみから接続できる
    • Private Space 及び Shield Private Space に対応する。
  • Heroku Kafka
    • Private Link で AWS VPC のみから接続できる
    • Private Space 及び Shield Private Space に対応する。
  • Heroku Redis
    • Private Link で AWS VPC のみから接続できる
    • Private Space 及び Shield Private Space に対応する。

Heroku Private Space Peering vs VPN Connections

  • Private Space Peering
    • Private/Shield Dyno と AWS VPC (Virtual Private Cloud) の間を Private ネットワークで通信する。
    • CIDR (Classless Inter-Domain Routing) を利用する。
      • IPv4 CIDR ブロック及び RFC1918 CIDR ブロック。
      • VPC の CIDR は Private Spaces の CIDR をオーバーラップできない。
  • Private Space VPN Connection
    • Google Cloud VPN や Azure VPN で利用する。
    • 正式には Azure VPN とは互換性がないとされているが、自己責任であれば手順がある。
    • Public インターネットを介して通信されるが、IPsec (Security Architecture for Internet Protocol) で暗号化される。
    • イントラネット内だけで使えるアプリ、のような使い方ができる。
    • Private/Shield Space ごとに 1 VPN のみ設定できる。
  • Private Spaces
    • HIPPA, PCI

Heroku Enterprise の Role と Permission

  • Team
    • Admin
      • すべてのアプリに対する完全なアプリレベルの権限​
      • 新しい Private Space を作成する
      • Private Space を破棄する
    • Member
      • Viewer の上位権限
      • Enterprise Team に属する新しいアプリを作成する
      • 個人のアプリを Enterprise Team に移動する
      • 作成したアプリやチームに移動したアプリに対して任意の操作を実行する
    • Viewer
    • Collaborator
      • App の Manage​ 権限を持つユーザー
      • Enterprise Team の Admin​ ロールを持つユーザー
  • Account
    • View
    • Manage
      • ​Teams タブからの Enterprise Team の管理
      • アカウントメンバーの管理 (アクセス許可の追加、削除、編集)
      • ​Settings タブの機能の使用 (SSO の設定および管理、監査ログのダウンロード)
    • Billing
      • ​Usage タブの機能の使用 (使用状況ファイルのエクスポート)
    • Create
      • Enterprise Team の作成、名前変更、削除
  • App
    • View
    • Deploy
      • コードをフェッチする
      • コードをプッシュする
      • 環境設定を表示および編集する
      • 無料のアドオンを追加および削除する
      • One-off dyno を実行する
      • リリースをロールバックする
    • Operate
      • 環境設定を表示および編集する
      • 無料および有料のアドオンを追加および削除する
      • One-off dyno を実行する
      • アドオン設定を管理する
      • アプリを再起動する
      • リリースをロールバックする
      • プロセススケーリングとスタックを管理する
    • Manage
      • アプリにユーザーを追加する
      • アプリ上の任意のユーザーにアクセス許可を割り当てまたは編集する
      • アプリへのアクセスを制限する
      • アプリの名前変更または削除を行う
      • アプリを転送する
      • カスタムドメインを管理する

4. Heroku Enterprise

出題内容

  • Heroku Enterprise の機能を使用して、システムのアーキテクチャをどのように向上させられるのかを示す。
  • Heroku Private Spaces または Common Runtime を適切に使用するネットワーキングソリューションを推奨する。
  • Heroku Shield のコンプライアンス機能について説明する。
  • Enterprise Teams の機能について説明する

Private Space Runtime vs Common Runtime

  • Dyno
    • Common: Free, Hobby, Standard, Performance
    • Private: Private
    • Shield: Shield
  • データロードテスト
    • Common: 10,000 件以上の場合は Heroku 社へ連絡が必要。

Private Spaces Runtime

  • Region
    • アイルランド:Dublin
    • 日本:Tokyo
    • ドイツ:Frankfurt
    • オーストラリア:Sydney
    • アメリカ:Oregon、Virginia
  • デフォルトリージョンは、Virginia
  • Internal Routing が有効化されたアプリとの接続
    • Private Spaces 内のアプリ間
    • VPC ネットワーク間
    • VPN ネットワーク間
  • Stable Outbound IPs
    • Private Spaces 内のアプリとサードパーティ製品や会社のネットワークと繋ぐ
    • Private Spaces ごとに 4 つの Outbound IP
  • Trusted IP 範囲
    • Private Spaces ごとに 20 個

Common Runtime

  • Standard-1x Standard-2x : 最大 100 dyno までスケーリング
  • Performance-m​ Performance-l : 最大 10 dyno までスケーリング
  • インターネットに公開されたアプリをホストする。
  • 外部サービスへの Outbound リクエストが可能。要求元の IP アドレスは指定できない。
  • リージョンは、EuropeUnited States の2つ。
  • デフォルトリージョンは、United States
  • 1 秒あたり 10,000 個のリクエストを超える場合は Performance dyno にする。Heroku サポートの許可も必要。
  • Web dyno から Worker dyno へ直接アクセスすることはできない。間に Heroku Redis を入れてキューイング。

Heroku Shield のコンプライアンス

  • Common Runtime & Heroku Private Spaces: ISO 27001, 27017, 27018 SOC 1, 2, 3
  • Heroku Shield Private Spaces: ISO 27001, 27017, 27018 SOC 1, 2, 3 HIPAA PCI DSS Level 1
  • クレジットカード業界のデータセキュリティ基準は PCI DSS
    • Shield Heroku Postgres は OK。
    • Shield Heroku Connect / Apache Kafka on Heroku Shield / Heroku Shield Redis は NG。
    • Common Runtime も Heroku Private Spaces も NG。
  • 医療に関する個人情報は HIPAA
    • Shield Heroku Postgres / Shield Heroku Connect / Apache Kafka on Heroku Shield / Heroku Shield Redis は OK。
    • Common Runtime も Heroku Private Spaces も NG。

Enterprise Teams

  • 使用可能なアドオンリスト
    • Admin 以外のユーザは、利用可能なアドオンホワイトリストにないアドオンをインストールできない。
    • 途中から有効化した場合、その前にインストールしていたアドオンは直ちに停止することはないが、再インストールはできない。

IdP が Salesforce の場合の SSO

  • Heroku Enterprise のみ。
  • Salesforce アカウントの Email が、既存の Heroku アカウントの Email で既に使われている場合は、ユーザプロビジョニングできない。

概要手順

  1. Salesforce で SAML IdP としての設定 を実施する。
  2. Salesforce から IdP metadata をダウンロードする。
  3. Heroku の settings タブ > Setup SSO から IdP metadata をアップロードする。
  4. Enable SSO をクリックする。
  5. SSO 情報をコピーする。
    1. Heroku Login URL
    2. Heroku Entity ID
    3. ACS URL
  6. Salesforce の接続アプリケーションの Web App Settings に転記し、Enable SAML をクリックする。

5. Architecting Applications

出題内容

  • Twelve-Factor App 方法論を適切に使用したアーキテクチャを推奨する。
  • Apache Kafka on Heroku を使用して、マイクロサービスアーキテクチャを構築するためのオーケストレーションレイヤを作成するソリューションを構成する。

Twelve-Factor App 方法論

I. コードベース

バージョン管理されている1つのコードベースと複数のデプロイ

  • コードベースとアプリは 1:1 にすること。
    • :x: 複数のコードベースを作る
    • :x: 複数のアプリが1つのコードベースを共有する

II. 依存関係

依存関係を明示的に宣言し分離する

  • 暗黙的な依存関係を前提とした実装をしない。
  • たとえば Node.js であれば package.json にすべて記載する。

III. 設定

設定を環境変数に格納する

  • コードベースは同じだがデプロイ時に環境ごとに異なる値を設定する。
  • コードベースと設定は分離する。
  • OSS の開発をしているとして、そのコードベースを public にしても良いかどうか?
    • public にしたくないセンシティブな情報が設定情報となる。
    • Herokuでは Config Vars に格納する。

IV. バックエンドサービス

バックエンドサービスをアタッチされたリソースとして扱う

  • アプリはローカルサービスとサードパーティサービスの区別をつけないようにする。
  • Heroku であれば、Config Vars で相手の接続情報を特定できるようにする。

V. ビルド、リリース、実行

ビルド、リリース、実行の3つのステージを厳密に分離する

  • ビルド:コードリポジトリをビルドと呼ばれる実行可能な塊へと変えること。
    • 可変な部分はなるべくビルドステージで吸収する。
  • リリース:ビルドと呼ばれる実行可能な塊と設定を結合して実行環境ですぐにでも実行できるようにすること。
    • 可変な部分はなるべくリリースステージに残さない。
  • 実行:リリースに対してアプリのいくつかのプロセスを起動することでアプリを実行環境で実行する。
  • リリースには固有のリリース ID が発行され、ロールバックできる必要がある。

VI. プロセス

アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する

  • ステートレス1:システムが現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される方式。 同じ入力に対する出力は常に同じになる。
  • ステートフル2:システムが現在の状態を表すデータなどを保持しており、その内容を処理に反映させる方式。同じ入力に対する出力が常に同じとは限らず、内部の状態次第で変わることがある。
  • 複数のプロセスは、お互いに競合を起こさないようにメモリやストレージを共有しない。
  • 永続化が必要なデータは、ステートフルなバックエンドサービス(データベース)に保持するようにする。
  • アプリの規模が大きくなる場合、複数のサーバーで動作するようにする。
    • Herokuであれば、複数の Dyno で動作する
  • コードはステートレスに実行され、ファイルシステムをキャッシュとして扱う。
    • 一時的であればファイルシステムを使ってよい。

VII. ポートバインディング

ポートバインディングを通してサービスを公開する

  • アプリは完全に自己完結していなければならない。
  • 実行環境へ Web サーバランタイムを注入することに頼らない。
  • ポートバインディングの方法によって、あるアプリケーションが他のアプリケーションにとってのバックエンドサービスになれる。

VIII. 並行性

プロセスモデルによってスケールアウトする

  • 個々のワークロード(作業負荷)の種類をプロセスタイプに割り当てる。
    • HTTP リクエストは Web プロセスによって処理する。
    • 時間のかかるバックグラウンドタスクは Worker プロセスによって処理する。
    • 垂直にスケールすることができない。並行にスケールする。
  • プロセスは決してデーモン化するべきではないし、PID ファイルを書き出すべきではない。
  • OS のプロセスマネージャーに頼ることで、ログなどの出力ストリームを管理する。

IX. 廃棄容易性

高速な起動とグレースフルシャットダウンで堅牢性を最大化する

  • グレースフルシャットダウン:
    • Web プロセスの場合、サービスポートのリッスンを中止し、処理中のリクエストが終了するまで待ち、シャットダウンする。
    • Worker プロセスの場合、処理中のジョブをワーカーキューに戻す。
  • 即座に起動・終了することができる。
    • プロセスの突然の死に対して堅牢である。
    • 起動時間を最小化することで、リリース作業やスケールアップのアジリティが高くなる。
      • Heroku の Web プロセスでは割り当てたボートにバインドするのに60秒以上かかってはならない。
    • クラッシュはサービスだけでなく、システムで処理する必要がある。

X. 開発/本番一致

開発、ステージング、本番環境をできるだけ一致させた状態を保つ

  • 時間のギャップを小さくする:開発者が書いたコードは数時間後、さらには数分後にはデプロイされる。
  • 人材のギャップを小さくする:コードを書いた開発者はそのコードのデプロイに深く関わり、そのコードの本番環境での挙動をモニタリングする。
  • ツールのギャップを小さくする:開発環境と本番環境をできるだけ一致させた状態を保つ。
  • Heroku Flow を活用する。

XI. ログ

ログをイベントストリームとして扱う

  • ログは、すべての実行中のプロセスとバックエンドサービスの出力ストリームから収集されたイベントが、集約されて時刻順に並べられたストリームである。
  • アプリの出力ストリームの送り先やストレージについて一切関知しない。ログファイルに書き込んだり管理しようとするべきではない。
  • 実行中のプロセスはイベントストリームを stdout (標準出力)にバッファリングせずに書き出す。
  • Heroku には Logplex というログの収集エンジンがある。収集後は Papertrail などのアドオンも利用できる。
    • Shield Private Spaces のみで利用できる Private Space Logging では Logplex を利用していない。
      • Space 内のアプリケーション、Heroku Postgres データベース、および Heroku システムサービスからのすべてのログイベントが 1つ のログキャプチャ記録先に転送される。
    • Logplex は US リージョンのみであるため、厳しいコンプライアンス要件がある場合は Private Space Logging を利用する。
    • Logplex は、保管用ではなくログメッセージを照合してルーティングするように設計されている
      • 最新の 1,500 行のログを保持
      • 1 週間後に期限切れ

XII. 管理プロセス

管理タスクを1回限りのプロセスとして実行する

  • 1 回限りの管理プロセスは、アプリの通常の長時間実行されるプロセスと全く同じ環境で実行されるべきである。
  • 管理用のコードは、同期の問題を避けるためにアプリケーションコードと一緒にデプロイされるべきである。

Apache Kafka on Heroku

  • 開発には Heroku CLI のプラグイン heroku-Kafka が必要。

複数アプリ間のデータ連携

  • Basic: Kafka はマルチテナントで Common Runtime にプロビジョニングされる。
    • Common Runtime のアプリ、Virginia および Dublin の Private Spaces のアプリと連携できる。
    • Kafka Basic トピックおよびコンシューマーグループには、アドオンに関連付けられた一意の接頭辞が必要。
      • 接頭辞がない場合、コンシューマーはメッセージを受信できない。
  • 専用: Kafka は Common Runtime / Private Spaces / Shield Spaces を選んでプロビジョニングできる。
    • 異なるリージョンのアプリと連携できる。

機密性の高いデータを連携して良いか

  • Apache Kafka on Heroku Shield であれば、HIPAA に準拠。
  • Apache Kafka on Heroku は ISO 27001, 27017, 27018 SOC 1, 2, 3 に準拠。
    • 一般的な個人情報であれば OK。

6. Integrations

出題内容

  • Heroku Connect を適切に使用するアーキテクチャ (外部 ID の正しい使い方など) を推奨する。
  • Heroku アプリケーションを Salesforce Lightning プラットフォームに統合する手法を推奨し、特定の手法を適用すべき状況を理解する。

インテグレーションのパターン

  • Salesforce のデータを Heroku へ連携
    • Heroku Connect
    • Platform Event
    • Heroku アプリから Salesforce API へ GET リクエスト
    • Apex から Heroku API へ POST リクエスト
  • Heroku のデータを Salesforce へ連携
    • Heroku Connect
    • Salesforce Connect (Heroku External Objects)
      • Heroku Connect のプロビジョニングは必須。データ同期は不要。
    • Canvas アプリ
    • Heroku アプリから Salesforce API へ POST リクエスト
    • Apex から Heroku API へ GET リクエスト

Heroku Connect

  • Salesforce API のコール回数は消費しない。
  • Heroku :arrow_right: Salesforce
    • 読み書きは後勝ち
  • Salesforce :arrow_right: Heroku
    • Streaming API でニアリアル更新が可能
    • Polling 間隔はデフォルト 10秒
  • Shield Heroku Postgres の暗号化は、クレジットカード情報 PCI DSS、医療に関する個人情報 HIPAA に対応。
  • マージ書き込みでは SOAP API のみサポート。

双方向同期の際の外部 ID の使い方

  • 一意性の保証
    • Salesforce のオブジェクトに GUID として外部ID項目を追加し、それをマッピングエディタで一意識別子​として設定する。
    • 自動採番項目を一意識別子に使用しない。
  • 順序付き書き込みアルゴリズムが設定されていて、2,000 ~ 10,000 件連続した同じ DML の場合、Bulk API が同期に使用される。

Salesforceのオブジェクト項目が削除された場合

  • Heroku Connect のマッピングが削除されていない場合、エラーが発生し同期が完了しない。
  • Heroku Connect のマッピングを削除すると、同期が再開される。

Heroku Connect 以外

  • Salesforce API
    • B2C Commerce API で B2C Commerce Cloud と連携する
  • Salesforce Connect
  • Platform Event
  • External Service
  • Anypoint Platform

参考文献

試験勉強で利用したサイトです。

さいごに

Salesforce Platform Advent Calendar 2020 にもエントリしてます。ぜひご覧ください。

それではまたお会いしましょう。

おまけ

4回目の試験の結果は...合格:sunny:
※2020年05月に日本語で受験(正答率:82%)。

  1. IT 用語辞典

  2. IT 用語辞典

11
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?