Zum Inhalt springen

Erfassen Sie Datenänderungen mit zeitstempelbasierten Abfragen im Jitterbit Design Studio

Anwendungsfall

Daten, wie Stammdatenänderungen oder neue Transaktionen, müssen von einer Quelle zu einem Ziel verschoben werden. Eine periodische Abfrage, die einem Zeitplan folgt, enthält eine Bedingung, die einen Zeitstempel verwendet, um die Datensätze aus der Quelle auszuwählen, die in das Ziel verarbeitet werden sollen.

Es gibt mehrere Überlegungen:

  • Dauerhafte Speicherung der Zeitstempeldaten
  • Vermeiden Sie eine „Endlosschleife“, bei der die von Jitterbit am Ziel vorgenommenen Änderungen übernommen und wieder auf die Quelle angewendet werden usw.
  • Isolierung beabsichtigter Änderungen von unbeabsichtigten Änderungen in der Quelle. So sollten beispielsweise durch einen Auslöser geänderte Daten nicht einbezogen werden, von einem Benutzer geänderte Daten jedoch schon.

Dieser Ansatz hat im Vergleich zu einem ereignisbasierten Push-Ansatz in Echtzeit Vor- und Nachteile.

  • Vorteile:
    • Wenn das Ziel nicht verfügbar ist, versucht die Quelle weiter, die Daten zu verschieben, bis dies abgeschlossen ist.
    • Kann den Zeitstempel „zurückverschieben“, um Wiederholungen zu ermöglichen
    • Kann relativ schnell loslegen
    • Einfachere Entwicklung und Prüfung durch die Verwendung kleinerer Datensätze.
    • Die Größe der zu verarbeitenden Daten kann besser kontrolliert werden.
    • Wenn ein „Zurückschreiben“ zur Quelle implementiert ist, können Sie die Integrationsaktivität von der Quelle zum Ziel verfolgen.
  • Nachteile:
    • Nur anwendbar, wenn ein Zeitstempel verfügbar ist oder eine Abfrage erstellt werden kann.
    • Polling/Abfragen können komplizierter sein als ereignisbasierte.
      • Ersteres erfordert einen Zeitstempel-Datenspeicher, Abfragen mit Bedingungen und möglicherweise anderen Filtern und reagiert empfindlich auf Schema in der Quelle. Im letzteren Fall empfängt Jitterbit einfach eine Payload. Solange sich dieses Schema nicht ändert, sind die Systeme lockerer gekoppelt, was aus Entwicklungssicht ein Vorteil ist.
    • Verschieben Sie den Verwaltungsaufwand für Integrationstools. Zum Beispiel, wenn Sie einen Fluss stoppen oder den Zeitplan in Jitterbit ändern/aktualisieren müssen, was eine Änderung der Softwarekonfiguration darstellt. Bei vielen Unternehmen ist das Vornehmen einer Änderung Teil eines softwaregesteuerten Prozesses und erfordert mehr Schritte. Bei einem ereignisgesteuerten Prozess wird die Änderung in der Quelle vorgenommen.
    • Da Zeitstempel normalerweise vom System generiert werden, berücksichtigen sie keine Geschäftsregeln, was dazu führt, dass Geschäftsregeln in die Middleware aufgenommen werden und umfangreiche Skripte erstellt werden müssen. Aus Sicht der Unternehmensarchitektur sollten Geschäftsregeln nur in den Anwendungen enthalten sein. Wie wir in diesem Beispiel sehen werden, gibt es umfangreiche Geschäftsregelskripte.

Beispiel

NetSuite abfragen, Salesforce aktualisieren

Anhang

JB Sync: Zeitstempel Script abrufen

Die Zeitstempel werden in SFDC gespeichert und eine Abfrage ruft die Synchronisierungs-ID und den Zeitstempel selbst ab. Beachten Sie, dass die Zeitstempel UTC sind und die Werte in einem Array zurückgegeben werden.

$result = SfLookupAll("<TAG>Salesforce Orgs/sysadmin@example.com</TAG>",
    "Select Id, Object_Last_Modified_Date_del__c from Jitterbit_Syncs__c where Object_Name_del__c = 'Ticket'");
$Jitterbit_SyncsId = Get($result,0,0);
$synctimestampticket = Get($result,0,1);

Sync_Time abrufen

Verwenden Sie eine Salesforce-Funktion, um die aktuelle Zeit abzurufen, die zum Aktualisieren des JB Sync-Datensatzes verwendet wird. Beachten Sie, dass dies vor der NS Abfrage und nicht nach dem SFDC-Upsert erfolgt, was die traditionellere Methode ist. Es wurde jedoch festgestellt, dass Datensätze übersehen wurden, da zwischen dem Zeitpunkt der Abfrage und dem Zeitpunkt des Abschlusses des Upserts Änderungen an der Quelle vorgenommen wurden. Es wurde entschieden, diesen Ansatz zu verwenden, auch wenn dadurch dieselben Datensätze in der Abfrage erfasst werden. Beachten Sie auch, dass es kein „Zurückschreiben“ in die ausgewählten Datensätze gibt, um sie basierend auf einem erfolgreichen Upsert in SFDC zu aktualisieren. Wenn dies implementiert würde, könnte eine Abfrage erstellt werden, die keine doppelten Datensätze erfasst.

$Sync_Time = GetUTCFormattedDateTime(
    LoginToSalesforceAndGetTimestamp("<TAG>Salesforce Orgs/sysadmin@example.com</TAG>","UTC"),"UTC",false);

Übergeben Sie die globale Variable synctimestampticket an die Abfrage

Anhang

Zuordnung

Eine Bedingung wird verwendet, um die Daten weiter zu filtern.

Anhang

Zustand

Die Anforderung bestand darin, bestimmte Standorte basierend auf Datumsangaben herauszufiltern, bis der bundesweite Rollout abgeschlossen war. Da die Abfrage nicht basierend auf den sich ändernden Datumsanforderungen filtert, wird innerhalb der Transformation eine Bedingung verwendet.

Die eingehenden Daten werden in das Operation geschrieben. Anschließend werden die internen IDs des Standorts überprüft. Wenn der Standort im Gültigkeitsbereich liegt, wird der Wert „Zuletzt geändert von“ des Datensatzes überprüft. Wenn dieser von Jitterbit erstellt wurde, wird er zum Überspringen markiert.

Da die LMB-Werte umgebungsabhängig sind, erfolgt anschließend eine Prüfung auf die aktuelle Umfeld.

Als nächstes wird der Datensatz mit einer Liste von Datumsbereichen verglichen, da Datensätze vor einer bestimmten Zeit ausgeschlossen sind. Wenn der Datensatz alle Tests besteht, wird er verwendet.

WriteToOperationLog(
"----------"+"\r\n"+
"Int id: "+searchResponse$searchResult$recordList$record.SalesOrder$internalId+"\r\n"+
"Ord id: "+searchResponse$searchResult$recordList$record.SalesOrder$tranId$ +"\r\n"+
"LMD: " +searchResponse$searchResult$recordList$record.SalesOrder$lastModifiedDate$+"\r\n"+
"Loc: " +searchResponse$searchResult$recordList$record.SalesOrder$location$internalId+"\r\n"+
"LMB: " +searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId+"\r\n"+
"Cust:" +searchResponse$searchResult$recordList$record.SalesOrder$entity$internalId);
If(searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==25||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==6||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==3||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==10||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==4||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==18||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==26||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==29||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==16||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==22||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==14||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==15||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==35||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==19||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==17||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==12||


 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==84,

 $loccheck = true,
 $loccheck = false);
//exclude changes in NS made by Jitterbit
If($loccheck && GetEnvironmentName()=='DEV',
 If(
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9836'||
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9837'||
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9838',
 $idcheck = false,
 $idcheck = true));
If($loccheck && GetEnvironmentName()=='PROD',
 If(
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='10780'||
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='10781'||
 searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId=='9631',
 $idcheck = false,
 $idcheck = true));
Case(
 $loccheck==false, $result=false;WriteToOperationLog("Skip loc"),
$loccheck==true && $idcheck == false, $result = false; WriteToOperationLog("Skip id"),
$loccheck==true && $idcheck == true,$result = true; WriteToOperationLog("Pass")
 );

// region & timestamp check
If($result == true && (searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==4||
 searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==26),
//check create date not before point in time when region went live. For these two regions, that is 2015-09-13T13:00:00Z
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-09-13T13:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("Colo Region ticket before 2015-09-13"))
);
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==18,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-09-20T13:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("Williston Region ticket before 2015-09-20"))
);
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==29,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-09-23T16:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("Caspar Region ticket before 2015-09-23")
 )
);
//AR
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==16,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-10-04T12:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("AR Region ticket before 2015-10-4")
 )
);
//DFW
If($result == true && searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==22||
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==14||
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==15||
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==17||
searchResponse$searchResult$recordList$record.SalesOrder$location$internalId==35,
//check create date not before point in time when region went live.
 If(Date(GetUtCFormattedDateTime(searchResponse$searchResult$recordList$record.SalesOrder$createdDate$,"UTC",false))
< Date(GetUTCFormattedDateTime("2015-10-11T08:00:00Z","UTC",false)),
 $result = false;
 WriteToOperationLog("DFW Region ticket before 2015-10-11")
 )
);
$result

Nachdem die Daten in eine temporäre Datei geschrieben wurden, wird Update Jitterbit Syncs aufgerufen:

Anhang

Anhang

Anhang

Abschließend wird die Operation A02 aufgerufen, wenn Datensätze zu verarbeiten sind.