Zum Inhalt springen

Datummigration in Jitterbit App Builder

Übersicht

Die Datummigrationsfunktion von App Builder bietet Unterstützung für die Migration von Daten von einer Zeitzone zu einer anderen.

Warnung

Die Datummigration ist ein sehr leistungsstarkes Tool, aber auch potenziell gefährlich, da es alle ausgewählten DateTime-Spalten in der Datenquelle beeinflusst. Vorsicht und ordnungsgemäße Tests werden dringend empfohlen.

Empfehlungen

Die Datummigration wird für Entwickler empfohlen, die DateTime-Spalten von einer Zeitzone zu einer anderen konvertieren möchten.

Die ideale Zeitzone für die Datenquelle ist möglicherweise umstritten, aber die empfohlene Vorgehensweise besteht darin, alle Server und Datenquellen so zu konfigurieren, dass sie dieselbe Zeitzone verwenden. UTC ist wahrscheinlich die beste Wahl, da jede andere Zeitzone anfällig für Änderungen ist, wenn sich der Serverstandort ändert. Beachten Sie auch, dass Amazon-Instanzen standardmäßig UTC verwenden.

Ein weiterer wichtiger Punkt ist, dass die Konfiguration der Zeitzone des Datenbankservers so, dass sie mit der Zeitzone der Datenquelle übereinstimmt, sicherstellt, dass Aufrufe von 'Now()' den erwarteten Wert zurückgeben. Now() gibt die aktuelle Zeit gemäß der Datenbankzeitzone zurück.

Durch die Synchronisierung aller Zeitzonen der Datenquelle können Sie sich die Mühe sparen, DateTime-Daten von einer Zeitzone zu einer anderen zu konvertieren. Derzeit erfolgt dies nicht automatisch, kann aber in einer zukünftigen Version implementiert werden.

Einschränkungen und Vorbehalte

Obwohl DateTime-Spalten migriert werden, gibt es andere Aspekte der App Builder-Anwendung, die möglicherweise geändert werden müssen, einschließlich:

  • Hartcodierte DateTime-Werte in Regeln werden nicht angepasst. Wenn die Regeln where- oder select-Klauseln mit hartcodierten Daten enthalten, müssen diese manuell an die neue erwartete Zeitzone angepasst werden.
  • Alle Spalten, die DateAdd oder ähnliche Funktionen verwenden, um Zeitzonen manuell anzupassen, bleiben unverändert. Entwickler müssen diese manuell korrigieren.
  • MS SQL Server-Versionen vor 2016 unterstützen die Funktion AT TIME ZONE nicht. Daher wird die Datummigration mit einem Zeitzonen-Offset durchgeführt, der aus den Quell- und Zielzeitzonen zum aktuellen Zeitpunkt berechnet wird. Dies kann zu Problemen mit Zeitzonen führen, die die Sommerzeit nutzen.
  • Datenmigrationen werden in einer einzelnen Transaktion ausgeführt, wenn die App/Datenquelle über ein LP aktualisiert wird. Die Transaktion kann je nach Menge der zu migrierenden Daten ein Timeout aufweisen. Wenn dies der Fall ist, hilft das Festlegen eines längeren CommandTimeOut in der Verbindungsdatei, Timeouts zu vermeiden.

Datummigration konfigurieren

Führen Sie die folgenden Schritte aus, um eine Datummigration durchzuführen:

  • Navigieren Sie zu IDE > Zusätzliche Einstellungen > Datummigration
  • Klicken Sie auf + Migration im Bereich „Datenmigrationen"
  • Wählen Sie eine Datenquelle aus
  • Wählen Sie eine Quellzeitzone aus. Diese Einstellung wird bereits für Datenquellen mit einer nicht-Null-Zeitzone ausgefüllt.
  • Wählen Sie eine Zielzeitzone aus
  • Klicken Sie auf Speichern

An diesem Punkt sollte sich das rechte Seitenpanel mit allen DateTime-Spalten in der ausgewählten Datenquelle füllen. Von hier aus können Sie die Datummigrationeinstellungen für einzelne Spalten konfigurieren.

Wenn die Datenquelle keine Zeitzone festgelegt hat, werden Sie feststellen, dass Audit-DateTime-Spalten die Zeitzone des App Builder-Anwendungsservers als Quellzeitzone verwenden. Audit-Daten werden mit der Zeitzone des Anwendungsservers geschrieben, wenn die Datenquelle keine konfigurierte Zeitzone hat. Beachten Sie auch, dass App Builder die Spaltennutzungstypen AddedOn und ChangedOn verwendet, um zu bestimmen, ob eine Spalte als Audit-Daten betrachtet wird.

Nachdem Sie die einzelnen Spalten angepasst haben, können Sie mit den folgenden Schritten fortfahren:

  • Klicken Sie auf dem gleichen Bildschirm wie oben auf die Schaltfläche Migrieren im Bereich Datummigration.

Dies führt einen Hintergrund-Job aus, um alle konfigurierten Spalten zu migrieren. Die Datummigration wird innerhalb einer einzelnen Transaktion ausgeführt und sperrt dabei Tabellen. Sie sollten sicherstellen, dass der Datenverkehr auf dem Server minimal oder gar nicht vorhanden ist, um Blockierungen zu vermeiden.

Für jede migrierte Tabelle werden auch Änderungsverwaltungsschritte hinzugefügt.

Nach der Migration von Daten ändert sich der Status der Datenmigration in Complete.

Falls ein Fehler auftritt, wird die Datenmigrationstransaktion zurückgerollt und zusätzliche Protokolle finden sich im Verlauf der Hintergrund-Jobs.

Fehlerbehebung

Weitere Informationen zur Fehlerbehebung finden Sie im App Builder-Leitfaden zur Fehlerbehebung: