Fehlerprüfung und Vorgangserzeugung

Allgemeine Hinweise

Im Rahmen der sogenannten Aposteriori-Prüfung, d.h. "im nach hinein" abgekürtzt auch Aposti genannt, werden aller Meldungen regelmäßig auf "Vollständigkeit und Widerspruchsfreiheit" geprüft und im Falle von Widersprüchen oder fehlenden Gegenmeldungen werden Fehlervorgänge zu einzelnen Meldungen und Meldungspaaren erzeugt. Diese werden oft auch als "Meldekettenfehler" bezeichnet und können in der Entität VORGANG betriebsbezogen abgerufen werden.

Wenn fehlende Meldungen eingehen oder Widersprüche korrigiert werden, werden die zugehörigen Fehlervorgänge dann beim nächsten Prüflauf wieder storniert und sind damit hinfällig.

Ziel

Die Aposti-Prüfung (auch: Plausi Phase II) hat zur Aufgabe, die Lebensläufe jedes Tieres in der Datenbank zu überprüfen und bei Fehlern diese in die Tabelle VORGANG zu schreiben. Die Regionalstellen müssen für ihr jeweiliges Bundesland die Vorgänge über eine Delta-Abfrage holen und veranlassen, daß die Fehler korrigiert werden. Das Aposti-Prüfprogramm berücksichtigt die Korrektur eines Lebenslaufes bei jedem Lauf, indem es die Fehler des korrigierten Lebenslaufes mit den alten schon gespeicherten vergleicht und dabei nicht mehr gültige Fehler storniert und neue Fehler ergänzt. Alle anderen Vorgänge, die nicht zur Aposti-Prüfung gehören, bleiben davon unberührt.

Arbeitsweise

Grundsätzlich bietet das Aposti-Programm die Möglichkeit, entweder einen gegebenen LOM-Bereich oder LOMs aus einer Datei zu rechnen. In beiden Fällen werden nachfolgende Prüfungen der Tier-Lebensläufe in verschiedenen Abschnitten abgearbeitet. Anzumerken ist, daß die 'alte Version' des Aposti-Programmes am 4.1.2001 zuletzt gelaufen ist und ab dem 18.1.2001 die neue.

	Vorab-Ohrmarkenprüfung der schon vorhandenen Einträge in der Vorgangstabelle Damit Änderungen am LomCoder auch in der Vorgangstabelle greifen (im konkreten Fall war es die Aufhebung der Datumsprüfung für saarländische Ohrmarken), wird vor der Überprüfung des Lebenslaufes die Ohrmarke geprüft. Ist sie korrekt und war zur Ohrmarke ein Eintrag in der Vorgangstabelle vorhanden, dann wird dieser storniert. Wird ein LOM-Bereich gegeben, so wird dieser komplett am Stück abgearbeitet statt bei jeder gefundenen Ohrmarke einzeln. Diese Prüfung gab es im alten Aposti-Programm nicht.
	betroffene Tiere ermitteln (betrifft nur LOM-Bereichsabfrage; im anderen Fall sind die LOMs bereits bekannt :-) Aus TIERBETR werden die seit dem letzten Lauf geänderten Ohrmarken ermittelt. Vor der aktuellen Version war es so, daß diese Meldungsabfrage um 10 Tage in die Vergangenheit verschoben war, was dazu führte, daß kürzlich gemachte Änderungen garnicht erfaßt wurden. In TIERBETR stehen zusätzlich Einträge, die in der Zukunft gesetzt wurden, die durch diese Abfrage auch mit erfaßt werden. Mehr dazu bei der Vorgangsprüfung.
	sämtliche Tierdaten zur LOM ermitteln Hier sind zwei Varianten eingebaut worden, um eventuell einen Performancegewinn herauszuholen, da dies der rechenintensivste Teil seitens der Datenbank ist. Beide Varianten holen grundsätzlich zu einem Tier (LOM) aus den Tabellen ERSTERF, GEBURT, EUEIN, IMPMARK, ABGANG, ZUGANG, TOD, SCHLACHTUN und AUSFUHR die Informationen Ereignisdatum, BNR15, SYS_VON, SYS_BIS und SYS_STAT. Diese werden dann unsortiert (bzw. so wie sie von der Datenbank kommen) in einer TierMeldungen-Liste gespeichert. Die zwei Varianten legen die Art der Datenabfrage auf die genannten Entitäten fest. Die eine holt sich alle Daten über ein einziges großes UNION-Select aus der Datenbank und die andere mit neun separaten Selects. Rein performancemäßig ist der UNION einen kleinen Tick schneller.
	Sortieren der Tiermeldungen Die alte Meldungssortierung von Herrn Hankewitz wurde durch die von Herrn Hartmann ersetzt, die auch bei der Einzeltierverfolgung verwendet wird. Grob gesagt wird zunächst nach Ereignisdatum sortiert, dann nach Betriebsnummer und schließlich nach Entität. Anschließend werden passende Pärchen gebildet, d.h. z.B. ZUGANG+ABGANG oder ZUGANG+SCHLACHTUNG etc. Diese Pärchen werden nun erneut in den übrigbleibenden alleinstehenden Meldungen einsortiert.
	Vorgänge generieren Anhand des sortierten Lebenslaufes werden Vorgänge generiert. Es wird immer die aktuelle mit der vorhergehenden Meldung zur Prüfung auf Konsistenz herangezogen. Die erzeugte Vorgangsliste wird anschließend noch von den Vorgängen befreit, die Dummy-Betriebsnummern betreffen. Schlussendlich wird die Ohrmarke selbst geprüft und im Fehlerfalle als Plausi 9500 angehängt.
	Entscheidungskriterium 1: Lebenslauf schon korrekt Ist der Lebenslauf des Tieres bis zur aktuellen Sekunde korrekt, dann gehe sofort zur Vorgangsbehandlung über. Ist er es nicht, berücksichtigen wir die 10-Tage-Meldefrist.
	Kürzen des Lebenslaufs Da der 'lange' Lebenslauf Fehler enthielt, könnte es sein, daß diese Fehler in den letzten 10 Tagen gemacht wurden und davor alles korrekt ist. Wir ermitteln daher eine kurze Tiermeldungsliste, indem wir jedes Ereignis von heute bis vor 10 Tagen weglassen. Die neue Liste wird erneut sortiert.
	Vorgänge des kurzen Lebenslaufes generieren Dies geschieht analog dem oben beschriebenen Verfahren.
	Entscheidungskriterium 2: Kurzer Lebenslauf unterscheidet sich vom langen Unterscheidet sich die Vorgangsliste des kurzen Lebenslaufs von der des langen, dann gewährt man der Ohrmarke einen zeitlichen Aufschub und behandelt sie wie einen Lebenslauf, der in den letzten 10 Tagen keine Fehler erzeugt hat. Es wird dann mit der Vorgangsliste des kurzen Lebenslaufs zur Vorgangsbehandlung übergegangen, wobei dort die Vorgänge entfernt werden, die in der Vorgangsliste des langen Lebenslaufes nicht mehr auftauchen würden. Unterscheiden sich beide Vorgangslisten nicht, dann übergibt man der Vorgangsbehandlung die Vorgangsliste des langen Lebenslaufs, da in den letzten 10 Tagen tatsächlich keine fehlerhaften Meldungen vorhanden sind.
	Zeitlichen Aufschub einer Ohrmarke speichern Damit Aposti später weiß, welcher Ohrmarke es mal einen zeitlichen Aufschub gegeben hat, wird diese mit der Dummy-Betriebsnummer des betroffenen Bundeslandes in TIERBETR gespeichert. Als DATA_VON-Timestamp erhält es das Datum 10 Tage nach dem Ereignisdatum, d.h. es kann weit in der Zukunft liegen. Beispielsweise bekommt eine Meldung mit einem Ereignisdatum von gestern demnach 9 Tage Aufschub und wird solange berücksichtigt, bis dieser Zeitpunkt überschritten wird. Diese Information wird deswegen in TIERBETR gespeichert, damit sie zu Beginn bei der Abfrage der betroffenen LOMs erfaßt werden kann. Die TIERBETR-Meldungen in der Zukunft kommen mit anderen Abfragen und Meldungen nicht in Konflikt, um gleich die Bedenken auszuräumen.
	Gewählte Vorgangsliste verarbeiten Am Ende der Prüfung wird die gewählte Vorgangsliste mit den bereits in der Vorgangstabelle gespeicherten Vorgänge zur Ohrmarke verglichen. Vorhandene Meldungen bleiben erhalten, neue Meldungen werden gemeldet und nicht mehr vorhandene werden storniert. Zudem werden bestätigte Meldungen berücksichtigt und trotz Fehlervorgang aus der Vorgangstabelle storniert.

Vielleicht noch eine amüsante Anmerkung: Das Aposti-Programm ist so schnell, dass es durch das Rausschreiben der Protokolldatei ausgebremst wird. Dieses brauche ich jedoch als Überwachung, um zu sehen, ob alles fehlerfrei lief.

Zeitplan

Der hier genannte Zeitplan ist derzeit gültig.

An folgenden Tagen und Zeiten läuft Aposteriori regelmäßig (seit dem 18.1.2001).

	Montags, ab 22 Uhr
	Mittwochs, ab 22 Uhr
	Freitags, ab 22 Uhr

In diesen Zeiten sollten bitte keine Abfragen auf die Vorgangstabelle und auch keine großen Meldejobs vorgenommen werden (würde sonst zu eventuell zu größeren Behinderungen führen).

Je nach Dauer werden die Zeiten eventuell tiefer in die Nacht verschoben, um die Hauptlast von den Abendstunden wegzubringen.

Zurück zum Anfang