Profil-Priorisierung (Performance)
Unter bestimmten Umständen ist es sinnvoll, ein Profil priorisiert auszuführen, da z. B. wirklich zeitkritische Daten verarbeitet werden sollen. Nehmen wir nur mal an es kommt eine Meldung rein, dass ein bestimmter Kunde ab sofort in der Datenbank zu sperren ist und keine Aufträge mehr von ihm angenommen werden dürfen. Natürlich wird man solche Meldungen nicht zeitgesteuert abfragen, sondern ereignisgesteuert, z. B. über den FTP- oder den SMTP-Eingangsagenten. Dann geht das normalerweise auch sofort in die Verarbeitung.
Nun kann es aber vorkommen, dass gerade so viel zu tun ist, dass bereits alle Threads für die Profilbearbeitung belegt sind. Dann wird jeder neue Job in eine Warteschlange (Queue) gestellt, die dann der Reihe nach abgearbeitet wird. Sobald ein Profil-Lauf fertig ist, wird der nächste Eintrag der Queue in Angriff genommen. Und ausgerechnet jetzt ist diese Queue schon recht lang. Die Meldung, dass ein Kunde gesperrt werden soll, landet irgendwo auf Position 123 oder so. Sind nun ein paar richtig große Aufgaben dabei, kann das dauern. Für solche Fälle können Sie die Priorität eines Profils erhöhen. Der Hinweis sollte zwar überflüssig sein, aber: Nutzen Sie diese Möglichkeit so sparsam wie möglich, also nur da, wo es wirklich drauf ankommt, sonst führen Sie das ganze Konzept schnell selbst ad absurdum.
Eine weitere Einsatzmöglichkeit dafür wäre ein Profil, das Daten per FTP bekommt, nur leider immer mit demselben Dateinamen. Hier kann das Zusammentreffen mehrerer Umstände zu unangenehmen Effekten führen.
Das Fremdsystem stellt Datei xyz.txt per FTP ein.
Ihr System ist gerade gut ausgelastet und die Queue enthält einige Einträge. Der Auftrag landet also hinten dran in der Schlange.
Wenige Sekunden später kommen neue Daten, ebenfalls mit dem Namen xyz.txt. Leider ist noch nicht mal die erste Datei in Verarbeitung gegangen.
Was nun passieren kann, ist Folgendes.
Der FTP-Service nimmt die erste Datei entgegen, stellt sie ab und meldet, dass Datei xyz.txt in ihrem Verzeichnis zu verarbeiten ist.
Es wird ein Job generiert und in der Queue abgestellt.
Der FTP-Service nimmt wenige Sekunden später die zweite Datei entgegen, stellt sie unter demselben Namen ab und überschreibt dabei die erste. Wieder wird ein Job generiert.
Endlich kommt der erste FTP-Job in die Verarbeitung, liest die Datei, löscht sie und legt los. Dummerweise hat er den Inhalt der zweiten Übertragung in der Hand, der andere wurde ja überschrieben.
Der zweite FTP-Job kommt in die Verarbeitung und findet die Datei gar nicht mehr vor.
Im Extremfall kommen sogar beide Jobs noch dazu die Datei zu lesen und verarbeiten dieselben Daten. Aber so oder so, die Daten der ersten Übertragung sind verloren. An sich sollte man schon beim Einstellen der Daten dafür sorgen, dass nicht immer derselbe Dateiname verwendet wird. Oder wenigstens nicht binnen weniger Sekunden unterschiedliche Daten mit demselben Namen senden. Oder vor dem erneuten Upload erst mal nachsehen, ob denn die vorherigen Daten inzwischen weg sind, statt sie einfach zu überschreiben. Aber wenn sich das einfach nicht ändern lässt, können Sie mit einer Priorisierung des entsprechenden Profils zumindest die Wahrscheinlichkeit verringern, dass ein solcher Effekt auftritt.