Erfassen Sie Datenänderungen mit Quellfeldwerten in Jitterbit Design Studio

Anwendungsfall

Ähnlich wie Erfassen von Datenänderungen mit zeitstempelbasierten Abfragen, anstatt einen Zeitstempel zu verwenden, um zu verarbeitende Daten abzurufen, fragt dieses Muster nach dem Wert in einem Feld. Normalerweise verwendet die Quelle Trigger oder Regeln, um zu ändernde Datensätze zu identifizieren, und ändert den Wert in einem Feld (wie „Bereit zum Senden“) von „false“ in „true“. Die Abfrage in Jitterbit verwendet dieses Feld in der Bedingung. Der Vorteil gegenüber der Verwendung von Zeitstempeln besteht darin, dass das Quellsystem seine internen Geschäftsregeln verwendet, um zu bestimmen, welche Daten verschoben werden sollen. Zeitstempel allein erfordern häufig zusätzliche komplexe Filterung, um der Geschäftslogik gerecht zu werden.

Beispiel

In diesem Fall verwenden sowohl Quelle als auch Ziel ein Ready_To_Sync- und ein Sync_Error-Feld. Wenn dieses Ziel einen Sync_Error aufweist, sollte kein Update durchgeführt werden und der Quelldatensatz sollte aktualisiert werden, damit er überprüft und behoben werden kann. Wie wir sehen werden, erfordert diese Art der gegenseitigen Synchronisierung Vorprüfungen vor der Aktualisierung sowie Erfolgs- und Fehlerpfade.

Zuerst prüft das Script, ob Daten abgerufen werden können. Dies ist die Operation, die den Zeitplan enthält. Als Nächstes wird eine Abfrage ausgeführt, um die restlichen Daten abzurufen. Dabei werden zwei Prüfungen durchgeführt. Wenn eingehende Daten ungültig sind, wird eine Aktualisierung gestartet. Außerdem wird eine Suche nach einem Feld im Ziel durchgeführt. Das wichtigste Erfolgsszenario besteht darin, dass Daten in NetSuite aktualisiert und Schlüsseldaten zurück in das Ziel geschrieben werden. Das Fehlerszenario besteht darin, dass der Zieldatensatz als Synchronisierungsfehler gekennzeichnet wird und nicht aktualisiert werden kann. Diese Informationen werden dann zurück in die Quelle geschrieben.

Überprüfen Sie zunächst, ob Daten zum Abrufen vorhanden sind. Verwenden Sie dazu ein einfaches SFLookup, das nur einen einzigen Datensatz zurückgibt. Wenn nichts zurückgegeben wird, starten Sie die Ereigniskette nicht. Aus Entwicklungssicht kann es hilfreich sein, diesen Ansatz zu wählen, anstatt sich auf die Abfrage in der SFDC Abfrage selbst zu verlassen, da Sie die IDs in der Abfrage erfassen und die Datensätze überprüfen können. Darüber hinaus wird die SFDC- Abfrage nur aktiviert, wenn sie etwas zu tun hat. In der Abfrage wird geprüft, ob Ready_to_Sync wahr ist und ob ein Sync_Error-Feld leer ist. Das RTS-Feld wird mit internen Triggern auf wahr gesetzt und wird durch den „Write-Back“-Prozess geändert.

soql =
"SELECT Id FROM Account WHERE (Account_Status__c like '%Active%' or Account_Status__c like '%Terminated%' or Client_ID__c != null) AND NetSuite_Id_original__c != Null and Ready_to_Sync__c = true and Sync_Error__c = Null and (Sync_Error_Code__c < 1 or Sync_Error_Code__c = Null)";
result = SfLookup("<TAG>Salesforce Orgs/companyname(Sandbox)</TAG>",soql);
If(Length(result)>0,RunOperation("<TAG>Operations/03 SF->NS Update Customer/0301 Query SF Accounts</TAG>"))

Vorausgesetzt, es wird mindestens ein Datensatz ausgewählt, wird 0301 gestartet. Die Transformation validiert ein Feld und ruft 0199 nach einem Muster auf, das dem von Bedingte Verarbeitung von Zieldatensätzen ähnelt.. Außerdem wird der NetSuite Zieldatensatz auf seinen Status „Bereit zur Synchronisierung“ geprüft. Beachten Sie, dass RTS_Status manuell zum vom Assistenten generierten Dateiformat hinzugefügt wurde.

//Check if NS record's Ready to Sync Status. If false, can update. But if true, then have a sync error. Do not update and set source SFDC record's Sync Error to '1'
RunOperation("<TAG>Operations/03 SF->NS Update Customer/0302 Check NS Customer RTS Check</TAG>");
WriteToOperationLog("NSCheckResult: "+$NSCheckResult);
//Need to know in advance the RTS status. If have any with RTS Status = false, then process the NS Update. If all records have RTS status = true, then skip the NS Customer Update and only run the Account Update.
//Use $arrNsCheckResult to store the values, then can check array to see if any are false, in which case can run the NS Customer Update
Set($arrNSCheckResult,$NSCheckResult,-1);
$NSCheckResult

Der Operation 0302 wird die NetSuite-ID übergeben.

Durch die Transformation kann die Operation das Abfrage auswerten.

Beachten Sie, dass eine einfache Flatfile-Struktur verwendet wird.

WriteToOperationLog("Id: "+searchResponse$searchResult$recordList$record.Customer$internalId+" RTS val: "+searchResponse$searchResult$recordList$record.Customer$customFieldList$Ready_To_Sync$value$);

If(searchResponse$searchResult$recordList$record.Customer$customFieldList$Ready_To_Sync$value$==true,$NSCheckResult=true,$NSCheckResult=false)

Im nächsten Operation führen wir diese Prüfung aus. 0304 wird ausgeführt, um das Update auf NetSuite durchzuführen, und 0306 wird bei Fehlerbedingungen ausgeführt.

// To handle edge case if all the NS records returned are RTS = true
RunOp=false;
WriteToOperationLog("arrNSCheckResult: "+$arrNSCheckResult);
count=Length($arrNSCheckResult);i=0;
While(i<count,
If($arrNSCheckResult[i]==0,RunOp=true);
i++);

If(RunOp,RunOperation("<TAG>Operations/03 SF->NS Update Customer/0304 Update NS Customer</TAG>"));
//Run this regardless
RunOperation("<TAG>Operations/03 SF->NS Update Customer/0306 Prep RTS Error</TAG>");

In 0306 lesen wir das Quellziel und filtern Datensätze heraus, die nicht verarbeitet werden müssen.

0304 aktualisiert das NetSuite-Konto und verwendet die Antwort, um eine Datei mit den RTS- und Fehlercodeinformationen zu erstellen.

Die Bedingung wird immer als wahr ausgewertet. Der Hauptzweck besteht darin, die SFDC-ID zur späteren Verwendung in der Transformation zu erfassen und auch NS-Fehlermeldungen zu erfassen, wenn Erfolg falsch ist. Bedingungen können auf diese Weise verwendet werden, um die Vorverarbeitung einzelner Datensätze zu ermöglichen.

$NSCustId="";
$errormessage="";
If(jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$isSuccess== true,
WriteToOperationLog("Success NS Id: "+FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId
));
//If success run op to update SFDC record
$SFCustId = $CustIdList[SourceInstanceCount()-1];
$NSUpdateMessage = FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$statusDetail#.message$);
$NSCustId = FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId
);
WriteToOperationLog("Success SFDC Id is :"+ $SFCustId);
WriteToOperationLog("Netsuite Update Message :"+ $NSUpdateMessage);
);

__

If(jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$isSuccess== false,
$errormessage="NS Data Error: "+GetEnvironmentName()+" "+
FindByPos(SourceInstanceCount(),
jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId)+ " Message: "+
SumString(jbroot$jbresponse$updateListResponse$writeResponseList$writeResponse.status$statusDetail#.message$,".",false);
$SFCustId = $CustIdList[SourceInstanceCount()-1];
WriteToOperationLog($errormessage);
);

true

Und schließlich aktualisiert 0305 SFDC. Die Anforderung hier war, dies mithilfe eines Massenupdates für eine möglichst schnelle Verarbeitung zu tun. Dies ist ein Teil-Screenshot: