è stato un paio di rilasci da quando ho dovuto eseguire un'integrazione S2S, ma mi sono imbattuto in un problema imprevisto che spero che qualcuno possa risolvere in modo più efficace.Problema relativo all'aggiornamento dei campi di andata e ritorno da Salesforce a Salesforce
Ho due org, condivisione di contatti su S2S.
I contatti in ogni organizzazione hanno lo schema identico, sono campi standard più campi personalizzati. Ho riprodotto un caso base con due soli campi personalizzati: casella di controllo campo A, e il numero (18,0) campo B.
Org 1 pubblicarla campo A, e sottoscrive campo B.
Org 2 sottoscrive al campo A e pubblica il campo B.
Org 1 avvia tutto il flusso di lavoro S2S condividendo i contatti su Org 2 su S2S. Org 2 ha l'accettazione automatica attivata.
L'Org 2 ha un contatto prima del trigger di inserimento che utilizza semplicemente il campo A per calcolare il valore per il campo B. ad es. se il campo A è spuntato, popola il campo B con 2, se deselezionato, 0. (Questa è ovviamente una drastica semplificazione di quello che devo davvero fare, ma è il caso riproducibile di base)
Che tutto funzioni bene in Org 2 - i contatti si incontrano bene con il campo A, e vedo i risultati del campo vengono calcolati nel campo B.
Il problema è che il risultato - campo B - non viene automaticamente condiviso in Org 1 finché il prossimo aggiornamento dei contatti. Può essere semplice come la modifica di un campo non condiviso su quello stesso contatto, come "Descrizione", in Org 2 e quindi vedo immediatamente il valore calcolato in precedenza del campo B viene reimpostato su Org 1.
Presumo che ciò sia dovuto al fatto che, poiché il calcolo del campo B si verifica all'interno di Before Insert, la connessione S2S presuppone che la transazione di aggiornamento corrente sia stata eseguita solo da solo (posso vedere come questa logica avrebbe senso impedire l'aggiornamento S2S infinito loop).
Ho tentato innanzitutto di creare un aggiornamento del flusso di lavoro che ha aggiornato forzatamente un campo (nuovo, fittizio) condiviso quando il campo B è cambiato, ma non ha causato il flusso di aggiornamento, presumibilmente perché è nello stesso contesto di esecuzione che Salesforce ritiene esente dalla ricondivisione. Ho anche provato una regola del flusso di lavoro che ha reindirizzato il Lead alla coda di connessione quando il campo è stato modificato e non ha funzionato.
Ho quindi provato una dichiarazione di aggiornamento in un trigger AfterUpdate: se il campo condiviso viene aggiornato, ricaricare e aggiornare nuovamente l'oggetto condiviso. Anche questo non ha funzionato.
Ho trovato una soluzione, che è un metodo Future chiamato dal trigger AfterUpdate che ricarica e tocca qualsiasi record che ha il suo campo condiviso modificato dal trigger BeforeUpdate. Questo fa sì che i risultati del campo vengano visualizzati quasi in tempo reale nell'organizzazione di origine.
Questa soluzione funziona per me per ora, ma sento che DEVI mancare qualcosa. Fa sì che vengano eseguite più chiamate Future e DML di quanto dovrebbe essere necessario.
Qualcuno ha una soluzione più elegante per questo?
Mi piacerebbe restare con '@ future'. Se mi stavo mettendo nei panni dello sviluppatore per questa funzione, probabilmente non controllano gli aggiornamenti fatti in Org 2 ai campi pubblicati per timore sulla creazione di un loop infinito. Se non gestiscono quel caso, nessuna possibilità di loop, dev facile e avanti alla funzione successiva. Mi piace il '@ future' perché fa esattamente ciò che vuoi senza trarre vantaggio dagli effetti collaterali (che hanno la brutta abitudine di scomparire nelle versioni future senza preavviso) –