Datumsmigration im Jitterbit App Builder

Übersicht

App Builder Die Datumsmigrationsfunktion von unterstützt die Migration von Daten von einer Zeitzone in eine andere.

Empfehlungen

Die Datenmigration wird für Entwickler empfohlen, die konvertieren möchten DateTime Spalten von einer Zeitzone in eine andere.

Die ideale Zeitzone für Ihre Datenquelle ist vielleicht umstritten, aber die empfohlene Vorgehensweise ist, Ihre Server und Datenquellen so zu konfigurieren, dass sie alle dieselbe Zeitzone verwenden. UTC ist wahrscheinlich die beste Wahl, da sich jede andere Zeitzone ändern kann, wenn sich der Serverstandort ändert. Beachten Sie auch, dass Amazon-Instanzen standardmäßig auf UTC eingestellt sind.

Denken Sie auch daran, dass die Konfiguration der Zeitzone Ihres Datenbankservers auf dieselbe Zeitzone wie Ihre Datenquelle sicherstellt, dass Aufrufe an 'Now()' gibt den erwarteten Wert zurück Now() gibt die aktuelle Zeit gemäß der Zeitzone der Datenbank zurück.

Indem Sie alle Zeitzonen Ihrer Datenquelle synchron halten, können Sie sich die Mühe der Konvertierung ersparen DateTime Daten von einer Zeitzone in eine andere. Derzeit geschieht dies nicht automatisch, es kann aber in einer zukünftigen Version implementiert werden.

Einschränkungen und Vorbehalte

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

• Festcodiert DateTime Werte in Regeln werden nicht angepasst. Wenn Ihre Regeln enthalten where oder select Klauseln mit fest codierten Daten müssen Sie diese manuell an die neue erwartete Zeitzone anpassen.
• Alle Spalten, die DateAdd oder ähnliche Funktionen zum manuellen Anpassen von Zeitzonen bleiben ebenfalls unverändert. Entwickler müssen diese manuell beheben.
• MS SQL Server Versionen vor 2016 unterstützen nicht die AT TIME ZONE Funktion. Daher wird die Datumsmigration 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 Sommerzeit verwenden.
• Datumsmigrationen werden in einer einzigen Transaktion ausgeführt, wenn Ihre App/Datenquelle über eine LP aktualisiert wird. Die Transaktion kann je nach der zu migrierenden Datenmenge ein Timeout aufweisen. Wenn dies geschieht, legen Sie eine längere Zeit fest CommandTimeOut in Ihrer Verbindungsdatei hilft, das Timeout zu verringern.

Konfigurieren der Datumsmigration

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

• Navigieren Sie zur IDE > Zusätzliche Einstellungen > Datumsmigration
• Klicken Sie im Fenster „Datumsmigrationen“ auf + Migration
• Wählen Sie eine Datenquelle
• Wählen Sie eine Quellzeitzone. Diese Einstellung ist für Datenquellen mit einem Wert ungleich null bereits ausgefüllt Time Zone.
• Wählen Sie eine Zielzeitzone
• Klicken Sie auf Speichern

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

Wenn für Ihre Datenquelle keine Zeitzone festgelegt ist, werden Sie feststellen, dass Audit DateTime Spalten verwenden die App Builder Zeitzone des Anwendungsservers als Source Time Zone. Auditdaten werden in der Zeitzone des Anwendungsservers geschrieben, wenn für die Datenquelle keine Zeitzone konfiguriert ist. Beachten Sie auch, dass App Builder verwendet die AddedOn Und ChangedOn Spaltennutzungstypen, um zu bestimmen, ob eine Spalte als Prüfdaten betrachtet wird.

Wenn Sie mit der Anpassung einzelner Spalten fertig sind, können Sie mit den folgenden Schritten fortfahren:

• Klicken Sie auf demselben Bildschirm wie oben auf die Schaltfläche Migrieren im Bereich Datumsmigration.

Dadurch wird ein Hintergrundjob ausgeführt, um alle konfigurierten Spalten zu migrieren. Die Datumsmigration wird innerhalb einer einzigen Transaktion ausgeführt und sperrt dabei Tabellen. Sie sollten sicherstellen, dass der Datenverkehr auf Ihrem Server minimal oder gar nicht vorhanden ist, um Sperren zu vermeiden.

Für jede migrierte Tabelle werden außerdem Schritte zur Änderungsverwaltung hinzugefügt.

Nachdem die Daten migriert wurden, ändert sich der Status der Datumsmigration in Complete.

Wenn ein Fehler auftritt, wird die Datumsmigrationstransaktion zurückgesetzt und zusätzliche Protokolle sind im Hintergrundauftragsverlauf zu finden.