es ein paar Releases, seit ich eine S2S Integration zu tun haben musste, aber ich lief in ein unerwartetes Problem, das hoffentlich jemand effektiver lösen kann.Salesforce-zu-Salesforce Roundtrip Feld Update-Problem
Ich habe zwei Orgs, die Kontakte über S2S teilen.
Kontakte in jeder Organisation haben das identische Schema, es sind Standardfelder plus benutzerdefinierte Felder. Checkbox Feld A und Number (18,0) Feld B.
Org 1 veröffentlicht Feld A, und abonniert B.
Org 2 abonniert Feld: Ich habe einen Basisfall mit nur zwei benutzerdefinierten Feldern reproduziert
Org 1 initiiert alle S2S-Workflow Feld A und Feld
B. veröffentlicht durch die Kontakte 2 teilen über S2S Org. Org 2 hat automatisches Annehmen.Org 2 hat einen Kontakt vor Einfügen-Trigger, der einfach Feld A verwendet, um den Wert für Feld B. z. Wenn Feld A aktiviert ist, füllen Sie Feld B mit 2, wenn deaktiviert, 0. (Dies ist natürlich eine drastische Übervereinfachung von dem, was ich wirklich tun muss, aber es ist der Basis-Fall.)
Das funktioniert alles gut in Org 2 - Kontakte kommen gut mit Feld A, und ich sehe die Feld Ergebnisse in Feld B berechnet werden.
Das Problem ist, dass das Ergebnis - Feld B - wird nicht automatisch wieder auf Org 1 bis das nächste Kontaktupdate. Es kann so einfach sein, wie ich ein nicht-geteiltes Feld auf demselben Kontakt, wie "Beschreibung", in Org 2 bearbeite, und dann sehe ich sofort den zuvor berechneten Wert von Feld B zurück zu Org 1.
Ich gehe davon aus, dass, weil die Berechnung von Feld B innerhalb eines Before Insert erfolgt, die S2S-Verbindung annimmt, dass die aktuelle Update-Transaktion nur von ihr selbst durchgeführt wurde (ich kann sehen, wie diese Logik sinnvoll wäre, um eine unendliche S2S-Aktualisierung zu verhindern) Schleifen).
Ich habe zuerst versucht, ein Workflow-Feldupdate zu erstellen, das ein (neues, dummy) freigegebenes Feld zwangsweise aktualisiert hat, wenn Feld B geändert wurde, das aber das Update nicht zurückfließen ließ, vermutlich weil es sich im selben Ausführungskontext wie Salesforce befindet von der Wiederveröffentlichung ausgenommen zu sein. Außerdem wurde eine Workflowregel ausprobiert, die das Lead zurück an die Verbindungswarteschlange weiterleitete, wenn das Feld geändert wurde, und es hat auch nicht funktioniert.
Ich habe dann versucht, eine erneute Update-Anweisung in einem After-Update-Trigger - wenn das gemeinsame Feld aktualisiert wird, neu zu laden und neu Update das gemeinsame Objekt. Das hat auch nicht funktioniert.
Ich habe eine Lösung finden, die ein zukünftiges Verfahren durch die After-Update-Trigger genannt, die neu geladen und berühren jeden Datensatz, der sein freigegebenes Feld durch die VorAktualisierung Trigger geändert hatte. Dies führt dazu, dass die Feldergebnisse in der ursprünglichen Organisation nahezu in Echtzeit angezeigt werden.
Diese Lösung funktioniert für mich für jetzt, aber ich fühle mich wie ich etwas verpassen muss. Es verursacht viel mehr Future Calls und DML als ausgeführt werden sollte.
Hat jemand eine elegantere Lösung dafür?
Ich würde bei '@ future' bleiben. Wenn ich mich für diese Funktion in die Rolle des Entwicklers stelle, wird wahrscheinlich nicht nach Updates gesucht, die in Org 2 für veröffentlichte Felder gemacht wurden, da es Bedenken hinsichtlich der Erstellung einer Endlosschleife gab. Wenn sie diesen Fall nicht behandeln, keine Loop-Möglichkeit, einfacheres Dev und weiter zum nächsten Feature. Ich mag das '@ future', weil es genau das tut, was du willst, ohne die Vorteile von Nebenwirkungen zu nutzen (die die schlechte Angewohnheit haben, in zukünftigen Veröffentlichungen ohne vorherige Ankündigung zu verschwinden) –