5

S2S 統合を行わなければならなかったので、数回のリリースがありましたが、予期しない問題に遭遇しました。誰かがより効果的に解決できることを願っています。

S2S 経由で連絡先を共有する 2 つの組織があります。

各組織の取引先責任者には、標準フィールドとカスタム フィールドの同一のスキーマがあります。チェックボックス フィールド A と Number(18,0) フィールド B の 2 つのカスタム フィールドのみで基本ケースを再現しました。

組織 1 はフィールド A を発行し、フィールド B を購読します。

組織 2 はフィールド A を購読し、フィールド B を公開します。

組織 1 は、S2S 経由で連絡先を組織 2 と共有することにより、すべての S2S ワークフローを開始します。組織 2 では自動承認がオンになっています。

組織 2 には、単純にフィールド A を使用してフィールド B の値を計算する Contact Before Insert トリガーがあります。たとえば、フィールド A がオンの場合はフィールド B に 2 を入力し、オフの場合は 0 を入力します。私が本当にする必要があることですが、それは基本的に再現可能なケースです.)

組織 2 ではすべて正常に機能します。連絡先はフィールド A で正常に表示され、フィールドの結果がフィールド B に計算されることがわかります。

問題は、次の連絡先の更新まで、結果 (フィールド B) が組織 1 に自動共有されないことです。組織 2 で、同じ連絡先の「説明」などの共有されていないフィールドを編集するのと同じくらい簡単です。その後、以前に計算されたフィールド B の値が組織 1 にプッシュバックされることがすぐにわかります。

これは、フィールド B の計算が Before Insert 内で行われているため、S2S 接続が現在の更新トランザクションがそれ自体でのみ実行されたと想定しているためであると想定しています (無限の S2S 更新を防ぐために、このロジックがどのように理にかなっているのかがわかります)ループ)。

フィールド B が変更されたときに (新しい、ダミーの) 共有フィールドを強制的に更新するワークフロー フィールド更新を最初に作成しようとしましたが、それでも更新が逆流する原因にはなりませんでした。 -共有。また、フィールドが変更されたときにリードを接続キューに転送するワークフロー ルールも試しましたが、これも機能しませんでした。

次に、AfterUpdate トリガーで再更新ステートメントを試しました。共有フィールドが更新された場合は、共有オブジェクトを再読み込みして再更新します。それもうまくいきませんでした。

AfterUpdate トリガーによって呼び出される Future メソッドである解決策を見つけました。これは、BeforeUpdate トリガーによって共有フィールドが変更されたレコードをリロードしてタッチします。これにより、元の組織でフィールド結果がほぼリアルタイムで表示されます。

この解決策は今のところうまくいきますが、何かが欠けているに違いないと感じています。これにより、必要以上に多くの Future 呼び出しと DML が実行されます。

誰かがこれのためのよりエレガントなソリューションを持っていますか?

4

2 に答える 2

0

あなたがしていることよりも良い回避策はないと思います。将来のコールアウトの制限はかなり高いレベルに引き上げられていますが、それは心配する必要はありません。

あなたができる他のことは、(私たちはまだ同じコンテキストにいるので、これが機能するかどうかはわかりません) - 組織 1 - フィールド A が更新され、契約を発行することです。

組織 2 - 組織 2 で契約を更新する前。A が更新されている場合 - 新しいカスタム オブジェクトに契約の ID を保存します。新しいカスタム オブジェクトの更新後、指定された契約 ID のフィールド B を更新します。Bのアップデートが公開されます

于 2013-07-23T13:15:08.920 に答える