Salesforce に対するバッチ処理連携に関する情報整理

検討すべき論点と用語整理

検討すべき事項

• スコープの定義

  • 対象のオブジェクト、項目、レコード
  • 処理方法、データ量、連携頻度

• Salesforce 管理者との認識

  • 認証方法の確認
  • セキュリティ要件の確認
  • API 利用量の確認
  • API 利用制限時のオペレーション確認

• データ連携アプリケーションの開発

  • ADF での実装

• 参考情報

  • 用語

用語整理

Salesforce REST API の検証環境と有益なトレーニング

Trailhead Playground という Salesforce の無償検証環境で検証を実施可能

• Trailhead Playground の管理 | Salesforce Trailhead

REST API を検証する際には Postman が有効であり、下記のトレーニングが参考になった。

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

Salesforce Developers Japan にて提供されている動画が参考になった

• Salesforce 認定Integration アーキテクト試験のポイント (youtube.com)
• Salesforceのデータ管理をマスターしよう！〜 認定データアーキテクト試験のポイント (youtube.com)
• 【機能紹介】Salesforceの共有設定をマスターしよう！ 〜 Sharing & Visibility - YouTube

データへの権限付与に関する有益なトレーニングである

• データセキュリティ | Salesforce Trailhead

最終更新日が 2022年ではあるが、連携パターンについて解説されている。

• 外部システムとの連携パターン｜セキュリティ・開発・運用｜Salesforce サクセスナビ

差分連携時の透かし列（基準列）

Salesforce のオブジェクト（RDB でいうテーブル）には下記のシステム列があり、差分連携を実施する際にはSystemModStamp列を利用できそう。

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

Salesforce のオブジェクトにはデフォルトで下記の列にインデックスが設定されている旨の記載があり、SystemModStamp列にも設定されている解釈できそうな記述となっている。

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

Salesforce REST API と Bukl API v2 の使い分け

データを書き込む際には、2000 件を目安に REST API と Bukl API v2 を使い分けることが推奨されている。

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

アクセストークンに取得方法

バッチ処理でデータ連携する際の認証には OAtuth 認証が利用することがあり、下記の方法がよく利用されているっぽい。 2 のOAuth 2.0 ユーザー名パスワードフローは現時点では非推奨っぽい。

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

*1 本認証を利用するには、接続アプリケーションにてEnable Client Credentials Flow（クライアントログイン情報フローを有効化）の設定を有効化する必要があります。

• OAuth 2.0 クライアントログイン情報フローの接続アプリケーションの設定 (salesforce.com)

*2 Salesforce のドキュメントにて下記のように非推奨である旨が記述されています。

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

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

また、Summer '23 以降に作成された組織ではデフォルトでOAuth ユーザ名パスワードフローが無効となっているため、有効化する必要があります。Developer Edition や Trailhead Playground でも同様であるため、注意してください。

引用元：新しい組織でデフォルトでブロックされる OAuth 2.0 ユーザ名パスワードフロー (salesforce.com)

下記については、Java や Python などのプログラム環境が必要であり、データ統合ツールでは利用できない場合がある。

1. サーバー間インテグレーション用の OAuth 2.0 JWT ベアラーフロー (salesforce.com)

取得したアクセストークンの無効化

バッチ処理の場合にはには、処理内で取得したアクセストークンは最後に無効化したほうがいいかも

• 不透明 OAuth トークンの取り消し (salesforce.com)

Salesforce へのデータ連携パターン

想定しているデータ連携パターン

1. UPSERT -> 外部 ID により標準オブジェクトに対する更新するケース *1
2. UPDATE -> Salesforce ID オブジェクトの特定の項目を変更するケース *2
3. INSERT のみ -> 特定ログのみを連携するケース *3
4. DELETE -> 不要となったデータを削除するケース *4

*1 特になし

*2 注意事項は下記

• 理論上データ連携パターンとして存在しているだけで実務上は必要ない可能性がある。

*3 注意事項は下記

• 理論上データ連携パターンとして存在しているだけで実務上は必要ない可能性がある。

*5 特になし

削除レコードの考慮

Salesforce では DELETE される可能性があり、その場合の考慮して DWH では削除フラグも含めて保持することを検討する

• 削除された項目を含む SOQL クエリを実行する | REST API 開発者ガイド | Salesforce Developers

API 利用時の注意事項

API の利用制限

概要

1. 同時 API 要求数
2. 24 時間あたりの合計 API 要求合計数
3. 要求サイズの制限

同時 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

要求サイズの制限

要求サイズに上限があることに注意が必要。

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