背景と応用シナリオ
Salesforce 統合エンジニアとして、私が日々直面する最も重要な課題の一つは、サイロ化されたシステム間のデータを統合し、顧客に関する統一されたビュー（360度ビュー）を構築することです。特に金融業界では、顧客情報がコアバンキングシステム、投資プラットフォーム、保険契約管理システムなど、複数のシステムに分散していることが一般的です。この情報の断片化は、ファイナンシャルアドバイザーが顧客の全体像を把握し、的確なアドバイスを提供することを困難にしています。
ここで Salesforce Financial Services Cloud (FSC) (Salesforce が提供する金融業界向けの専用クラウドソリューション) が強力な解決策となります。FSCは、顧客の世帯情報、金融口座、保険契約、ローンなどを一元管理するための精巧なデータモデルを提供します。しかし、このデータモデルの真価は、外部システムの正確なデータで常に最新の状態に保たれて初めて発揮されます。
本記事での応用シナリオは、ある大手銀行がFSCを導入し、顧客のウェルスマネジメントサービスを向上させるプロジェクトです。私の役割は、毎晩実行されるバッチ処理によって、銀行の勘定系システムから普通預金口座、当座預金口座、投資信託口座のデータを抽出し、FSCに統合するプロセスを設計・実装することです。この統合により、アドバイザーはSalesforceにログインするだけで、担当顧客の最新の資産状況をリアルタイムに近い形で確認できるようになり、よりパーソナライズされた、タイムリーな提案活動が可能になります。このプロセスを実現するために、Salesforceが提供する強力なAPI、特に Composite API を活用します。
原理説明
この統合を実現するための技術的な核心は、FSCのデータモデルを理解し、SalesforceのAPIを効率的に利用することにあります。
FSCの主要データモデル
今回の統合で中心となるFSCのオブジェクトは以下の通りです。
・Account (取引先): FSCでは、個人または世帯を表すために使用されます。Person Account (個人取引先) モデルが一般的に利用されます。
・Financial Account (金融口座 - API名: FinServ__FinancialAccount__c): 銀行口座、投資口座、クレジットカードなど、個別の金融口座情報を格納する中心的なオブジェクトです。勘定系システムから連携される口座データは、主にこのオブジェクトにマッピングされます。
・Financial Holding (金融資産 - API名: FinServ__FinancialHolding__c): 特定の投資口座（Financial Account）が保有する個別の金融商品（例：株式、投資信託）の詳細を格納します。Financial Accountオブジェクトの子オブジェクトとしてリレーションが結ばれています。
・Financial Account Role (金融口座の役割 - API名: FinServ__FinancialAccountRole__c): 特定の口座に対して、個人がどのような役割（例：所有者、共同所有者、受益者）を持つかを示す中間オブジェクトです。
統合の基本的な流れは、勘定系システムの口座データをFSCのFinServ__FinancialAccount__cオブジェクトに作成し、その口座に紐づく形で、所有者情報（FinServ__FinancialAccountRole__c経由でAccountへ）や、保有資産情報（FinServ__FinancialHolding__c）を関連付けていくことになります。
統合アプローチ：SObject Tree APIの活用
単純に1件ずつレコードを作成する場合、REST APIのエンドポイントをオブジェクトごとに何度も呼び出す必要があり、APIコール数を大量に消費し、処理時間も長くなります。例えば、1つの金融口座とその口座が保有する5つの金融資産を作成する場合、計6回のAPIコールが必要になります。
これを解決するのが SObject Tree API (/services/data/vXX.X/composite/tree/{SObjectAPIName}) です。このAPIは、単一のAPIリクエスト（1回のAPIコール）で、親子関係や関連関係にある複数のレコードを一度に作成することができる強力な機能です。JSON形式のリクエストボディ内でレコード間のリレーションを定義することで、Salesforce側でトランザクショナルにデータを作成してくれます。
今回のシナリオでは、親である「金融口座（Financial Account）」レコードと、子である複数の「金融資産（Financial Holding）」レコードを一つのJSONペイロードにまとめて送信します。これにより、API消費量を劇的に削減し、データの一貫性を保ちながら、パフォーマンスを大幅に向上させることが可能です。
示例代码
以下は、SObject Tree APIを使用して、新しい「投資口座（Investment Account）」を作成し、同時にその口座に紐づく2つの「金融資産（Financial Holding）」レコード（株式と投資信託）を作成する際のJSONリクエストボディの例です。このリクエストは POST /services/data/v58.0/composite/tree/FinServ__FinancialAccount__c のようなエンドポイントに送信します。
{
"records": [
{
"attributes": {
"type": "FinServ__FinancialAccount__c",
"referenceId": "FinancialAccountRef1"
},
"Name": "田中 太郎 投資口座 A",
"FinServ__FinancialAccountNumber__c": "INV-88776655",
"FinServ__Balance__c": 2500000,
"FinServ__Ownership__c": "Individual",
"FinServ__PrimaryOwner__c": "001xx000003DHP4AAO", // 実際の取引先(世帯)レコードID
"FinServ__RecordTypeName__c": "Investment", // レコードタイプAPI名
"Source_System_ID__c": "COREBANK-ACC-12345", // 外部システムのIDを格納するカスタム項目
"FinancialHoldings__r": {
"records": [
{
"attributes": {
"type": "FinServ__FinancialHolding__c",
"referenceId": "FinancialHoldingRef1"
},
"Name": "ABC Corp Stock",
"FinServ__Symbol__c": "ABC",
"FinServ__Shares__c": 100,
"FinServ__MarketValue__c": 1500000
},
{
"attributes": {
"type": "FinServ__FinancialHolding__c",
"referenceId": "FinancialHoldingRef2"
},
"Name": "Global Growth Fund",
"FinServ__Symbol__c": "GGF",
"FinServ__Shares__c": 50,
"FinServ__MarketValue__c": 1000000
}
]
}
}
]
}
コード詳細解説
-
attributes: このブロックは各レコードのメタデータを定義します。type: 作成するオブジェクトのAPI名を指定します。ここでは親がFinServ__FinancialAccount__c、子がFinServ__FinancialHolding__cです。referenceId: このリクエスト内でのみ有効な一時的なIDです。このIDを使って、同じリクエスト内の他のレコードからこのレコードを参照できます。ここでは親口座にFinancialAccountRef1というIDを付与しています。
-
Name,FinServ__FinancialAccountNumber__c, etc.: これらはFinServ__FinancialAccount__cオブジェクトの各項目に設定する値です。FSCの標準項目にはFinServ__という名前空間プレフィックスが付いています。 -
Source_System_ID__c: これはカスタム項目（External ID属性を付与することが推奨）で、勘定系システムの口座IDを保持します。これにより、将来の更新処理（Upsert）の際に、レコードを一意に特定するためのキーとして利用できます。Idempotency (冪等性 - 同じ操作を何度繰り返しても同じ結果になる性質) を担保するために非常に重要です。 -
FinancialHoldings__r: ここがSObject Tree APIの強力な部分です。__rサフィックスはリレーションシップ名を表します。これは、FinServ__FinancialAccount__cからFinServ__FinancialHolding__cへの子リレーションシップ（API名はFinancialHoldings）を指しています。このネストされたrecords配列内に子レコードの情報を記述することで、親レコードと同時に作成され、自動的に関連付けられます。
⚠️ 上記のコードは developer.salesforce.com のSObject Tree APIのドキュメントに記載されている構造に基づき、Financial Services Cloudのオブジェクトに合わせて作成したものです。FinServ__PrimaryOwner__c に指定するID (001xx...) は、事前に存在するAccountレコードのIDである必要があります。
注意事項
権限 (Permissions)
この統合を実行するAPIユーザーには、適切な権限が必要です。
・オブジェクト権限: FinServ__FinancialAccount__c, FinServ__FinancialHolding__c, Account などの関連オブジェクトに対する「作成」「参照」「更新」権限が必要です。
・項目レベルセキュリティ (Field-Level Security): APIで値を設定するすべての項目へのアクセス権限が必要です。
・API Enabled: ユーザーのプロファイルで「APIの有効化」権限がチェックされている必要があります。
・権限セット: Financial Services Cloud Standard などのFSC基本権限セットを割り当てた上で、インテグレーション専用のカスタム権限セットを作成し、必要な権限を最小限の原則で付与することが推奨されます。
API制限 (API Limits)
Salesforceには、24時間あたりのAPIリクエスト数に上限があります。大量のデータを扱うバッチ処理では、この制限を意識することが不可欠です。SObject Tree APIは、複数のレコード作成を1回のAPIコールにまとめるため、API消費量の削減に大きく貢献します。例えば、1000件の金融口座とそれぞれに平均3件の金融資産がある場合、個別APIコールでは4000回必要ですが、SObject Tree APIを使えば（1リクエストあたりのレコード数上限に注意しつつ）大幅に少ないコール数で済みます。
エラー処理 (Error Handling)
SObject Tree APIは、リクエスト全体が成功するか失敗するかのどちらかです。ただし、allOrNone パラメータをリクエストURLに追加することで挙動を制御できます（デフォルトはtrue）。
APIからのレスポンスには、作成されたレコードのIDや、エラーが発生した場合はその詳細が含まれます。統合プロセスでは、このレスポンスを正しく解析し、失敗したレコードやその原因をログに記録し、必要に応じて再試行ロジックやアラート通知を実装する必要があります。例えば、必須項目が不足している、データ型が違うなどのエラーが返されることがあります。
まとめとベストプラクティス
Salesforce Financial Services Cloudへの外部データ統合は、金融機関が顧客中心のサービスを提供する上で不可欠なステップです。統合エンジニアとして、このプロセスを成功させるためには、単にデータを移行するだけでなく、効率的で、スケーラブルで、堅牢なソリューションを構築することが求められます。
ベストプラクティス
- FSCデータモデルの深い理解: どのデータをどのオブジェクト、どの項目にマッピングするべきか、リレーションシップをどう活用するかを事前に徹底的に分析します。
- Composite APIの積極的な活用: SObject Tree APIやComposite API (SObject Collections) を利用して、APIコール数を最小限に抑え、パフォーマンスを最大化します。
- 冪等性の確保: 外部ID（External ID）を使用して、バッチ処理が複数回実行されてもデータが重複して作成されないように設計します。
- 専用の統合ユーザーの利用: 最小権限の原則に従い、API連携専用のユーザーとプロファイル、権限セットを用意し、セキュリティを確保します。
- データボリュームの考慮: 将来のデータ増加を見越して、バルク処理に対応できる設計を心掛けます。Platform Eventsなどのイベント駆動型アーキテクチャも、リアルタイム性が求められるシナリオでは有効な選択肢となります。
- 堅牢なエラーハンドリングと監視: 失敗は起こりうるものとして、詳細なロギング、再試行メカニズム、そして異常を検知した際の通知システムを必ず実装します。
今回紹介したSObject Tree APIは、FSCへのデータ統合における強力なツールの一つです。このAPIを適切に活用することで、Salesforce統合エンジニアは、ビジネスに真の価値をもたらす、信頼性の高いデータ連携基盤を構築することができるのです。
コメント
コメントを投稿