営業担当者の管理にセールスフォースを使い始めたいのですが、現在のシステムに残しておきたい連絡先に関するビジネス機能もあります。
私が見る限り、それは双方向の同期が必要になるということですか? つまり、Salesforce で何かが変更された場合は、システムで更新する必要があり、その逆も同様です。
私は、途中で座って失敗したメッセージを再試行できる何らかのメッセージング製品を提案しています. たとえば、1 つまたは他のサービスがダウンしている場合です。
プロジェクトのマネージャーはシンプルに保ちたいと考えており、リアルタイムのポイントツーポイント コールではなくメッセージを使用するのはやり過ぎだと感じていますが、それがなければ、私たちは苦痛の世界に陥ることになると感じています.
双方向同期を試みた経験のある人はいますか (実際、一方向でも同じリスクに悩まされていると思いますか?)
あなたの洞察に感謝します..
あなたのシステムについて話すことはできませんが、Salesforce API については、データ レプリケーションgetUpdated()用に設計されたとのgetDeleted()呼び出しを見てください。SOAP API ドキュメントには、それらを効果的に使用する方法について詳しく説明するセクションがあります。
Jitterbit を使用して、Salesforce と課金システム間の双方向同期を実現しています。Salesforce には最終更新日フィールドがあり、請求システムにもあります (システムにこれが必要です。そうでない場合は、SQL ストレージのテーブルにタイムスタンプ フィールドを追加してください)。唯一重要なことは、キーの 1 つをプライマリ (SF_ID または他のシステムのキー) として選択し、競合の解決に使用される別のシステムでそのキー フィールドを作成することです。プロセスは単純で複数のステップがあり、変更されたすべての SF データをフラット ファイルにロードし、変更されたすべてのセカンダリ システム データを別のフラット ファイルにロードし、共通のキー フィールドで 2 つのファイルを比較して競合を探し、競合があれば管理者に通知し、伝播します。競合しないすべての変更を別のシステムに適用します。
2 人のユーザーが同時に編集した場合、競合が発生して手動で解決するか、"last-saved-wins" の結果が得られます。
また、新しい規定に対応する必要があります。SF 側では更新の代わりに upsert を使用し (上記で選択したものに応じて外部キーまたは SF キーを使用)、反対側ではシステムに依存します。