Der "MonitorImportJob" überwacht in regelmäßigen Abständen ein Importverzeichnis, das sich lokal auf dem Archiv-Server befindet. Wenn in diesem Verzeichnis Daten neu abgelegt werden, wird das Verzeichnis rekursiv nach import.job-Dateien durchsucht. Diese Dateien enthalten die Parameter für den Import. Die Dateien werden geprüft und die entsprechenden Sperren (import.lock) werden im Dateisystem angelegt. Die Dateien werden in der Import-Datenbank aufbereitet und geprüft, sodass die "ImportWorkerJobs" den Import asynchron und parallel ausführen können.

Wenn der "MonitorImportJob" neue Unterordner findet, werden diese Ordner eingelesen und verarbeitet. Wenn ein Auftrag eingelesen wird, erstellt der Job im Ordner eine import.lock-Datei. Diese Datei signalisiert, dass der Job in Verarbeitung ist und nicht mehr eingelesen werden muss. Der Job überprüft die Importdaten und erstellt in der Import-Datenbank einen Import-Auftrag mit dem Status "Pending". Der Job teilt die Daten für die Verarbeitung in kleinere Einheiten ("Chunks").

Ein Import besteht immer aus einer Job-Definition und aus Chunks. Die Chunks enthalten die Anzahl von Dokumenten, die importiert werden sollen.

Der "ImportWorkerJob" liest in regelmäßigen Abständen die Import-Datenbank nach Importen aus, die noch nicht verarbeitet wurden. Wenn neue Daten vorhanden sind, holt sich ein Worker einen Teil (Chunk) eines Import-Jobs, sperrt diesen Chunk und importiert alle enthaltenen Dokumente. Die Chunks werden nach Priorität und Erstellungszeitpunkt verarbeitet.

Nach der Verarbeitung wird der Status der Dokumente und des Import-Chunks in der Import-Datenbank aktualisiert. In das Monitoring-Protokoll wird ein Eintrag geschrieben. Fehlerhafte Dokumente werden markiert.

Der "ImportMaintenanceJob" kontrolliert in regelmäßigen Zeitabständen die Vollständigkeit der Massen-Importe. Wenn keine Fehler gefunden werden, werden die Daten, die nicht mehr benötigt werden, aus dem Dateisystem. Die Import-Auftragsdaten werden als archiviert markiert.

Wenn ein oder mehrere Fehler gefunden werden, wird eine E-Mail mit einem Fehlerbericht an die E-Mail-Adresse geschickt, die in der Konfiguration unter SystemSettings → DefaultSettings → Reporting konfiguriert ist.

Der "IndexerSchedulerJob" führt die Volltextindizierung durch. Die Volltextindizierung erfolgt nach dem Import asynchron, wenn dies definiert wurde. Der Archiv-Server erstellt beim Import in die "Indexjobber"-Datenbank Einträge, die von den Job-Instanzen abgearbeitet werden. Für jedes Dokument, das indexiert werden soll, ist in der "Indexjobber"-Datenbank temporär ein Eintrag vorhanden.

Wenn die Indexierung fehlschlägt, werden maximal 3 weitere Indexierungsversuche für das Dokument vorgenommen.

Der "IndexMigrationJob" migriert einen Elasticsearch-2.x-Index zu einem Elasticsearch-7-Index. Technisch wird der Elasticsearch-2-Index jedes Archivs im Mandanten iterativ zu einem Elasticsearch-7-Index migriert. Der Job wird so lange wiederholt, bis alle Dokumente in den Elasticsearch-7-Index migriert sind.

Während der Migration kann das Archiv ohne Einschränkungen genutzt werden. Pro Index wird ein temporärer Index angelegt. Der temporäre Index wird gelöscht, sobald die Migration abgeschossen ist. Archive, die sich in der Migration befinden, und Archive, die bereits migriert sind, erhalten den Konfigurationsparameter Migrated mit dem Wert InIndexMigration.

Der Job ersetzt zum Zeitpunkt der hundertprozentigen Migration automatisch den Elasticsearch-2-Index durch den Elasticsearch-7-Index. Ab diesem Zeitpunkt wird nur noch der Elasticsearch-7-Index genutzt.

Der "TransferJob" durchsucht die konfigurierten Archive nach Dokumenten, die älter sind als ein konfigurierter Zeitraum. Wenn genügend Dokumente für einen Transfer verfügbar sind (Container-Minimal-Größe), werden diese Dokumente in einen Container geschrieben und in den Zustand "endarchiviert" überführt.

Voraussetzung: In dem Archiv, das verarbeitet wird, ist ein Shard vom Typ ContainerBox vorhanden.

Der "LogArchiverSchedulerJob" archiviert Log-Einträge, die älter als ein konfigurierter Wert sind, als JSON-Struktur in einem Archivdokument. Wenn dies konfiguriert ist, erfolgt zusätzlich eine Volltextindexierung.

Der "RetentionJob" sucht in den konfigurierten Archiven nach Dokumenten, deren Standard-Ablaufzeit abgelaufen ist. Diese Dokumente werden gelöscht. Die Standard-Ablaufzeit wird über die Archiv-Eigenschaft Retention oder die Dokumenttyp-Eigenschaft Retention definiert.

Der Job "TempCleanup" räumt in regelmäßigen Zeitabständen das Verzeichnis auf, in dem die temporären Dateien gespeichert werden.

Der "ReplicaJob" überträgt alle Dokumente, die repliziert werden sollen, an die Fremdserver (ForeignServers) und führt alle Replikationen in lokale Archive aus.

Das Ziel einer Replikation ist Ausfall- und Datensicherheit. In einem Archiv mit einer Replika-Konfiguration wird bei jedem Schreibvorgang ein zufällig generierter Wert (Change Token) in das Dokument geschrieben. Wenn das Dokument korrekt repliziert wurde, ist der Change Token auch in der Replikation verfügbar. Das Change Token kennzeichnet die Gleichheit des Masters und der Slave-Replikation.

Wenn in der Archiv-Konfiguration die Eigenschaft Check replication aktiviert ist, wird zusätzlich eine Replikationsprüfung durchgeführt. Zudem kann für ein Archiv eine Replikationsprüfung durchgeführt werden. Bei der Replikationsprüfung werden das Master-Archiv und das Slave-Archiv miteinander verglichen.

Der "ImportConverterJob" konvertiert Import-Dateien in das JSON-Format. Die konvertierten Daten können nach der Konvertierung durch einen Standard-Datei-Import-Job archiviert werden. Der Konvertierungsvorgang umfasst keine inhaltliche Prüfungen der Daten.