概要

Salesforce と DWH のデータ連携の実施方法を整理します。

本記事のスコープ

Salesforce のオブジェクトを REST API 経由でデータの連携（Salesforce からのデータ読み込みとSalesforce へのデータ書き込み）を実施するための基本的な情報の整理と実施ステップを整理します。

Salesforce のインテグレーションのバッチデータの同期を行います。

引用元：パターンの概要 | インテグレーションのパターンと実践 | Salesforce Developers

Salesforce REST API と Salesforce Bulk API 2.0 経由で外部 ETL ツールにてデータ連携することを対象とし、バッチデータの同期のソリューションとして記述されている Salesforce 変更データキャプチャ機能は対象としません。

引用元：バッチデータの同期 | インテグレーションのパターンと実践 | Salesforce Developers

想定ロール

#	ロール	概要
1	Salesforce 管理者	Salesforce システム管理者。
2	データエンジニア	Salesforce と DWH とのデータ連携の実施者。
3	データ利用者エンジニア	Salesforce のデータ利用者。

データ連携に向けたステップ

1. データエンジニアが Salesforce を知る

データエンジニアが Salesforce とのデータ連携をスムーズに進めるために、 Salesforce の概念や用語を知ることが重要です。Salesforce には検証環境と学習コンテンツが無償で提供されている Trailhead を利用することがおすすめです。データエンジニアに Salesforce に関する知識がない場合には、Salesforce 認定アソシエイト資格試験の講座を受講することがおすすめです。

引用元：Trailhead | 楽しく学ぶ方法 (salesforce.com)

Salesforce サクセスナビというサイト上のコンテンツもとても有益です。

引用元：はじめてガイド｜Salesforce サクセスナビ

Salesforce の概要を把握後は、Trailhead にて提供されている Salesforce の REST API に関するトレーニングが参考となります。

Quick Start: Connect Postman to Salesforce | Salesforce Trailhead
プラットフォーム API の基本 | Salesforce Trailhead

YouTube に視聴できる Salesforce Developers Japan が提供している下記の動画も参考になります。

2. データエンジニアがデータ連携の要件を検討

検討事項

データ連携対象のオブジェクト、項目、及び、レポート
利用する API、データ量、連携頻度、及び、同時 API 利用数
データ連携ツールの仕様

データ連携対象のオブジェクト、項目、及び、レポート

Salsefoce では、オブジェクトレベル、項目レベル、及び、レコードレベルでデータセキュリティが設定されているため、データ連携対象のオブジェクト、項目、レコードを定義することが重要です。

引用元：Salesforceの用語を理解して、使う人にあった画面の設定を行う｜Sales Cloud｜Salesforce サクセスナビ

引用元：部署やチーム毎にみることができるデータを設定する｜Sales Cloud｜Salesforce サクセスナビ

レポートの項目によりデータ連携することも可能であり、その際に必要となる Report ID を下記のようなレポートで確認することがおすすめです。

引用元：Salesforce にて作成されているレポートの Report ID 等の情報を一覧化したレポートを作成する方法 #Salesforce - Qiita

利用する API、データ量、連携頻度、及び、同時 API 利用数

Saleforce における下記の API の利用制限を考慮して利用する API、データ量、連携頻度、及び、同時 API 利用数（実行時間が 20　秒以上の API の同時実行数）を検討する必要があります。

同時 API 要求数
24 時間あたりの合計 API 要求合計数

Salseforce 上に作成する接続アプリにて利用できる API のスコープを定義するために、利用する API を検討します。基本的にはAPI を使用してユーザーデータを管理 (api)というスコープで十分な可能性がありますが、その他の API を利用する場合には必要なスコープを検討してください。

引用元：OAuth トークンおよび範囲 (salesforce.com)

データ操作のパターンとしては下記のものがあり、どのように実装するかを検討する必要があります。

Salesforce からのデータ読み込み
- オブジェクト、あるいは、レポートからデータ読み込み
Salesforce へのデータ書き込み
- INSERT
- UPSERT
- UPDATE
- DELETE

Salesforce REST API と Salesforce Bulk API 2.0 の使い分ける基準として 2000 レコードの目安が提示されていますが、 DWH との連携を実施する場合には多数のオブジェクトから大量のレコードを抽出するため Salesforce Bulk API 2.0 を優先的に利用することが良さそうです。

Bulk API 2.0 の候補として、2,000 件を超えるレコードを含むデータ操作をお勧めします。これにより、Bulk フレームワークを使用する非同期ワークフローの準備、実行、管理を正常に行うことができます。2,000 レコード以下のジョブでは、REST (Composite など) または SOAP による「一括」の同期呼び出しを行うことをお勧めします。

引用元：Bulk API 2.0 と Bulk API の概要 | Bulk API 2.0 および Bulk API 開発者ガイド | Salesforce Developers

データ連携ツールの仕様

利用を想定しているデータ連携ツールにおける Salesforce への認証方法とネットワーク経路を確認します。

Salesforce への認証方法としては主に下記の方法があり、データ連携ツールにより自動化する場合には 1 を選択することが多いようです。

サーバー間インテグレーション用の OAuth 2.0 クライアントログイン情報フロー (salesforce.com)
特別なシナリオの OAuth 2.0 ユーザー名パスワードフロー (salesforce.com)
OAuth 2.0 Web Server Flow for Web App Integration (salesforce.com)

2 の方法の利用方法が記事としてよく投稿されていますが、現時点では非推奨の方法となっているようです。

重要セキュリティを強化するために、ユーザー名パスワードフローの代わりに、コード交換の証明鍵 (PKCE) を使用する OAuth 2.0 Web サーバーフロー、または OAuth 2.0 クライアントログイン情報フローを使用することをお勧めします。

引用元：特別なシナリオの OAuth 2.0 ユーザー名パスワードフロー (salesforce.com)

Salesforceでは、ユーザーや接続アプリに対してIP制限を設定できるため、Salesforceへのネットワーク経路を慎重に検討することが重要です。SaaS型のデータ連携ツールを利用する場合、ネットワーク経路が他のユーザーと共有されることが多いため、接続情報が流出した際にそのツールからデータが外部に漏洩するリスクを許容できるかどうかを確認する必要があります。

3. Saleforce 管理者にデータ連携方法のすり合わせ

検討事項

連携方針の認識合わせ
統合ユーザーと接続アプリの作成依頼

連携方針の認識合わせ

検討内容をデータエンジニアが Salesforce 管理者に説明し、連携方針の認識合わせを実施します。

インテグレーションユーザー、接続アプリ、及び、Sandbox 環境の作成依頼

連携方針に基づいて、インテグレーションユーザーと接続アプリの作成を依頼します。

4. データ連携アプリケーションの設計と開発

実装方針

基本的な検討事項

操作可能なレコードと項目の確認
差分連携方法の確立
DELETE を考慮した Salesforce からの読み込み

操作可能なレコードと項目の確認

Salesforce 管理者から提供された接続情報により、想定通りにオブジェクト、レコード、及び、レコードを取得できることを確認します。レコードの過不足については、データ利用者の判断が必要になる場合があります。

差分連携方法の確立

Salesforce から読み込む場合に差分連携を実施する場合には、オブジェクトのシステム列であるSystemModStamp列を基準列（ウォーターマーク列）として利用できそうです。

引用元：システム項目 | Salesforce プラットフォームのオブジェクトリファレンス | Salesforce Developers

Salesforce のオブジェクトにはデフォルトで下記の列にインデックスが設定されている旨の記載があるため、SystemModStamp列でフィルタリングしても性能上は問題なさそうです。

引用元：インデックス | 大量のデータを使用するリリースのベストプラクティス | Salesforce Developers

DELETE を考慮した Salesforce からの読み込み

Salesforce にて DELETE されたレコードは一定期間保持されてから物理削除されるため、定期的にデータ連携を実施して DELETE されたレコード（IsDeleted = True）を DWH に反映する必要があります。Salesforce Bulk API 2.0 ではqueryALL を指定することで、 DELETE されたレコードも連携されます。

レコードを削除しても Salesforce から完全に削除されるわけではなく、復元できるように 15 日間はごみ箱に置かれます。

引用元：レコードの削除 | Apex 開発者ガイド | Salesforce Developers

引用元：システム項目 | Salesforce プラットフォームのオブジェクトリファレンス | Salesforce Developers

Azure Data Factory で実装する方法

データ連携パターンの検討

データ連携パターンとして、下記の記事にて整理しています。Salesforce からのデータ読み込み方法が Salesforce をソースとした場合の記事であり、とSalesforce へのデータ書き込みが Salesforce をシンクとした場合の記事です。

5. データ連携アプリケーションの運用

検討事項

API の利用状況の監視
Hard Delete したレコードの対応

API の利用状況の監視

API を想定以上に利用していないことを確認します。

Hard Delete したレコードの対応

レコードが Hard Delete された場合には、 DWH に反映する必要があります。 Hard Delete を実施する場合には非定常オペレーションであることが予測されるため、データエンジニアも例外的な対応が必要となる場合があります。

関連情報

用語整理

#	Salesforce の用語	概要	備考
1	オブジェクト	RDB におけるテーブル。
2	レコード	RDB におけるレコード。
3	項目	RDB におけるカラム。
4	Salesforce ID	Salesforce が自動的に各レコードに割り当てる一意の識別子。
5	外部 ID	Salesforce 以外のシステムで割り当てる一意の識別子。
6	標準オブジェクト	Salesforceにデフォルトで含まれているオブジェクト。
7	カスタムオブジェクト	ユーザーが独自に作成するオブジェクト。	API で利用する際には末尾に`__c`がつく。
8	標準項目	Salesforceにデフォルトで含まれている項目。
9	カスタム項目	ユーザーが独自に作成する項目。	API で利用する際には末尾に`__c`がつく。

データ統合に利用するユーザーと接続アプリ

下記の記事を参考に、データ統合を実施するインテグレーションユーザーと接続アプリを作成します。

API の利用制限

API の利用制限に関する概要

API 利用時には下記の制限があります。

同時 API 要求数
24 時間あたりの合計 API 要求合計数

同時 API 要求数

20 秒以上の API 実行に対して下記のような制限があります。

引用元：API 要求の制限と割り当て | Salesforce Developer の制限および割り当てクイックリファレンス | Salesforce Developers

24 時間あたりの合計 API 要求合計数

API ごとに 24 時間あたりの合計 API 要求合計数の制限があります。

引用元：API 要求の制限と割り当て | Salesforce Developer の制限および割り当てクイックリファレンス | Salesforce Developers

引用元：Bulk API および Bulk API 2.0 の制限および割り当て | Salesforce Developer の制限および割り当てクイックリファレンス | Salesforce Developers