Allgemeines Problem mit Massendaten (Speicherüberlauf)

Bei der Arbeit mit Massendaten kann es notwendig sein, aus den Quelldaten Untermengen zu separieren, die dann einzeln verarbeitet werden, um einen Speicherüberlauf oder extrem lange Verarbeitungszeiten zu vermeiden.

Bisherige Lösung (und deren Beschränkung)

Eine Möglichkeit das zu lösen, besteht darin, die Quelldaten durch geeignetes Parsen in einem ersten Profil in mehrere Datenblätter aufzuteilen und dann über einen Antwortweg (in Kombination mit der Option Pro Datenblatt Antwortwege ausführen) ein weiteres Profil aufzurufen, in dem dann die Verarbeitung der jeweiligen Untermenge stattfindet.

Neue Lösung (Bereichsgrenzen und Tokenliste)

Diese Klasse ist für solche Fälle gedacht, bei denen die Bereichsgrenzen für die Untermengen erst durch Berechnung in Phase 3 aufgebaut werden können. Die Aufteilung der Daten in Untermengen anhand der übergebenen Bereichsgrenzen erfolgt dann erst in einem Folgeprofil.

Dazu wird das Folgeprofil (siehe Parameter target) mehrmals mit den selben Quelldaten (wie empfangen einstellen im Antwortweg), aber fortlaufenden Bereichsgrenzen aufgerufen. Die Bereitstellung der geeigneten Bereichsgrenzen erfolgt in einer Profil-Variable (siehe Parameter parameters) als Tokenliste innerhalb der Phase 3 vor dem Aufruf der Klasse. Die Klasse ruft ein Folgeprofil so oft auf, wie die Tokenliste Token hat. Bei jedem Aufruf wird an die entsprechende MSG_CALL_-Variable des Folgeprofils nur der aktuelle Token übergeben.

Festplattenüberlauf verhindern (Backup-Dateien)

Bei jedem Aufruf des Folgeprofils werden die selben Quelldaten übergeben. Wenn es sich dabei um Massendaten handelt, besteht die Gefahr des Überlaufs der Festplatte, weil jeder Job des aufgerufenen Profils diese Daten als Backupdatei speichert. Es ist daher ratsam, die Aufbewahrungszeit der Backupdatei auf 0 Tage einzustellen, damit diese unmittelbar nach erfolgreichem Lauf gelöscht wird.

Verwendeter Message-Typ

Die Abarbeitung des Antwortweges (in dem diese Klasse verwendet wird) ist ein Gesamtvorgang, innerhalb dessen die mehreren Aufrufe des Folgeprofils erfolgen. Die Verwendung synchroner Messages (siehe Parameter msgtype) ist nicht zu empfehlen, weil hier ein nicht genau definierter Zustand eintritt, wenn nach erfolgreichen Aufrufen ein weiterer Aufruf des Folgeprofils zum Fehlerabbruch führt.

Wir empfehlen den Message-Typ persistent, weil dann die Jobs des Folgeprofils strikt nacheinander abgearbeitet werden können (siehe Option Profil darf nur in einer Instanz laufen). Bei paralleler Abarbeitung der Folgeprofil-Jobs besteht sonst wieder das Risiko des Speicherüberlaufs.

Counter-Variable

Weiterhin kann eine Counter-Variable definiert werden (siehe Parameter counter), deren Wert an die entsprechende MSG_CALL_-Variable des Folgeprofils übergeben wird.

Diese Counter-Variable (falls sie definiert ist) wird vor einem Aufruf des Folgeprofil zuerst geleert erhält dann die Nummer des aktuellen Aufrufs.

Falls (bei synchroner Message) ein Abbruch durch einen Fehler im Folgeprofil erfolgt, enthält der Counter die Nummer des letzten Aufrufs.

Encoding

Das Encoding der Daten wird, abhängig vom Inhaltstyp, in das Profil-Encoding des Folgeprofils umgewandelt.

Die einzige Ausnahme ist der Inhaltstyp wie empfangen (nicht "wie empfangen, entpackt"), bei dem die Backupdatei des Jobs byteweise als Backupdatei des Folgeprofils kopiert wird. Dabei wird die Umwandlung in ein Encoding übersprungen. Für die Verarbeitung rein binärer Daten empfehlen wir daher diesen Inhaltstyp.

Verkettung von Antwortwegen

Bei der Verkettung mehrerer Antwortwege (bei Erfolg/bei Fehler in Antwortweg Nr.) ist zu beachten, dass die Variable mit der Tokenliste (Parameter parameters) nach Ausführung des Antwortweges wieder den in Phase 3 definierten Inhalt mit der vollständigen Tokenliste hat, obwohl an das Folgeprofil nur jeweils der aktuelle Token übergeben wurde.