Druckreihenfolge bei Hintergrundbuchungen – Die Analyse einer Analyse

Oftmals sind die Anforderungen an eine Druckausgabe vielfältig. Lieferscheine müssen an Drucker A, Rechnungen an Drucker B gesendet werden. Zusätzlich müssen die Originale auf Geschäfts- und die Kopien auf Normalpapier gedruckt werden und dementsprechend verschiedenen Druckerschächte angesteuert werden. Die Definition des Zieldruckers für den jeweiligen Beleg ist einfach, auch die Anpassung um verschiedene Druckerschächte anzusteuern ist simpel zu realisieren. Allerdings gibt es dabei zwei Hürden zu nehmen. Zum Einen die Tatsache, dass die Schachtsteuerung sich auf physikalische Seiten bezieht und zum Zweiten, dass wir in Beleg-Reports meist mit dem CopyLoop arbeiten, welcher mehrere (definierbare) Kopien eines Berichts erlaubt, aber sich in der Ausgabe natürlich von den physikalischen Seitenzahlen unterscheidet.

Eine Rechnung mit 3 Seiten und 2 zusätzlichen Kopien hat insgesamt 9 physikalische Seiten, während die logische Seitenzahl natürlich 3 lautet – allerdings 3 Mal (Original + 2 Kopien). Selbstverständlich muss beim Ausdruck auch die Reihenfolge korrekt eingehalten werden, ansonsten laufen die Bearbeiter irgendwann Amok. Bei einem Batch-Druck verkompliziert sich das Ganze noch mehr, da wie oben geschrieben für die Ansteuerung des Druckerschachts nur die physikalische Seitenzahl genutzt werden kann. Welche Möglichkeiten hat man nun, dieses Problem zu umgehen? Die simpelste Variante ist, die Berichte zu duplizieren (jeweils als Original und Kopien) und in der Berichtsauswahl für die verschiedenen Vorgänge diese Berichte in der gewünschten Reihenfolge zu hinterlegen. Weiterhin werden in der Druckerauswahl die Belege entsprechend für die jeweiligen Drucker und Schächte (geringfügige Anpassung) konfiguriert.

Wer es etwas eleganter möchte, der kann die Steuerung der Kopien (und vor allem den Text “KOPIE”) über andere Anpassungen durchführen, beispielsweise durch eine zusätzliche Spalte Kopie in der Tabelle “Report Selections” und Nutzung einer SingleInstance-Codeunit. Es gibt sicherlich weitere Möglichkeiten das zu erreichen, aber darum soll es hier nicht primär gehen.

Nun kann es aber los gehen: Auftrag erstellen, Zeilen erfassen, Buchen und drucken…

• Lieferschein 1 Original
• Lieferschein 2 Original
• Rechnung 1 Original
• Lieferschein 1 Kopie
• Rechnung 2 Original
• Lieferschein 2 Kopie
• Rechnung 1 Kopie
• Rechnung 2 Kopie

Toll… Erster Versuch und gleich daneben… Der Werni, der Kollege des Buchers, hat auch gebucht. Die Belege sind also schon in der korrekten Reihenfolge gedruckt worden, aber durcheinander, also die vom Werni und seinem Kollegen quasi abwechselnd…

Was nun tun? Was passiert hier und wie kann man das Durcheinander umgehen? An dieser Stelle kam nun Microsoft mit ins Boot im Rahmen einer Anfrage an den technischen Support. Das Grundverhalten war schnell erklärbar, da ja zwei mehr oder weniger gleichzeitige Buchungen durchaus öfter mal vorkommen. Beim Buchen und drucken auf mehreren Arbeitsplätzen, hängt es von der Geschwindigkeit des Mitarbeiters und dann primär von der Größe der jeweiligen Belege ab, da diese in der Codeunit 82 entsprechend der Tabelle “Report Selection” abgearbeitet und gedruckt werden. Geschieht dies parallel, dann drucken die verschiedenen Prozesse quasi zeitgleich und je nachdem, welcher Bericht zuerst abgeschlossen ist, reiht sich in der Druckwarteschlange vorne ein.

Aber wie lösen? Auch das war nach kurzer Analyse relativ klar. Unser Vorschlag: Nutzung des Features “Hintergrundbuchung” (siehe auch How to- Background Post with Job Queues) der Aufgabenwarteschlange. Dabei werden, das ist die Eigenart einer Warteschlange, die Buchungsaufträge nacheinander ausgeführt und es findet keine Parallelverarbeitung statt.

Beim Buchen und drucken wird, nach entsprechender Konfiguration im Reiter “Hintergrundbuchung” in der “Debitoren & Verkauf Einrichtung”, das Dokument nur freigegeben und - mit der konfigurierten Kategorie (VKBUCH) - als Datensatz in die Tabelle “Aufgabenwarteschlangenposten (Job Queue Entry)” gestellt.

Die Aufgabenwarteschlangenposten wiederum, werden von einer aufgabenwarteschlange abgearbeitet, deren Kategorienfilter konfiguriert ist, die Kategorie VKBUCH abzuarbeiten.

Hier wird eine entsprechend konfigurierte Aufgabenwarteschlange (VKEKBUCH) mitgeliefert, während die Aufgabenwarteschlange “STANDARD” im Auslieferungszustand nur Aufgaben verarbeitet, die keine Kategorie konfiguriert haben:

Diese Warteschlangen werden, wenn entsprechend konfiguriert, automatisch vom NAS gestartet und harren dann der Dinge (Aufgaben) die können mögen.

Aber zurück zum eigentlichen Thema: Das Ergebnis der Nutzung von Hintergrundbuchungen im Zusammenhang mit der Aufgabenwarteschlange war, dass es zunächst gut aussah. Alle Belege wurden in richtiger Reihenfolge gedruckt und das Problem damit gelöst. Allerdings, das zeigte sich nach einigen Tagen, gab es im Test durchaus noch Ausrutscher. Es schien, als würde alles korrekt ablaufen, aber zwei arbeitswütige Mitarbeiter schafften es durchaus gelegentlich, sich gegenseitig die Druckreihenfolge zu zerstören.

Ein weiteres Telefonat zeigte dementsprechend, dass es nicht ausreicht, nur die Hintergrundbuchungen zu nutzen. Denn, wie eine erneute Analyse des Verhaltens ergab, die Berichte selbst werden in der Codeunit 82 per REPORT.RUN() aufgerufen, also asynchron. Es ist damit nicht sichergestellt, dass bei zwei schnell abgearbeiteten Buchungsvorgängen die Ausdrucke in korrekter Reihenfolge durchgeführt werden. Die Buchung dauert oftmals nur wenige 1-3 Sekunden, der Druck länger. Da in der Codeunit 82 der Ausdruck allerdings nur gestartet aber nicht auf dessen Beendigung gewartet wird, können hier ebenfalls Störungen der Reihenfolge auftreten. Lösung: Im Falle von Hintergrundbuchungen (GUIALLOWED = FALSE), werden die Berichte in der Codeunit 82 synchron gestartet. Damit ist nun wirklich sichergestellt, dass ein Buchungsjob erst nach der Buchung und nach Drucken aller Belege beendet und ein weiterer gestartet wird.

Ende der Geschichte? Mitnichten! Einige Zeit später kam der Partner wieder auf uns zu mit dem Problem, dass die Ausdrucke im Produktivsystem immer noch in falscher Reihenfolge erfolgten und mehrere Vorgänge jeweils vermischt werden. Wie kann das sein?

• Codeunit 82, REPORT.RUNMODAL()? Check!
• Hintergrundbuchung aktiviert? Check!
• Aufgabenwarteschlange VKEKBUCH korrekt konfiguriert? Check!
• Druckereinstellungen korrekt? Check!

Eine Fernwartungssitzung ergab keine neuen Erkenntnisse und Weihnachten nahte. Auch wenn der Kunde mit diesem nervigen Verhalten kaum leben konnte, so vertagten wir uns auf das neue Jahr. Im Januar dann, bekamen wir die Datenbank des Kunden zur Analyse. Geht ja fix: Datenbanksicherung zurückspielen, Dynamics NAV Serverdienst für die Datenbank konfigurieren und einen Benutzer anlegen. Fertig, läuft! Als erfahrener Engineer weiß man, dass Aufgabenwarteschlangen primär auf Hintergrundsitzungen basieren und der NAS letztendlich nur diese Hintergrundsitzungen ansteuert. Also wird abschließend, nach Prüfung der Konfiguration, der Drucker gestoppt und dann die Aufgabenwarteschlange “VKEKBUCH” gestartet. Über zwei bzw. drei offene Clients wird gleichzeitig gebucht. Das Ergebnis: Alles einwandfrei. Die Druckaufträge wurden alle in korrekter Reihenfolge an den (angehaltenen) Drucker gesendet:

Was kann der Unterschied zwischen der Produktivumgebung und meiner Testumgebung sein, dass dort (bei gleicher Datenbank), das Problem auftritt und hier nicht?

• Einrichtung der Aufgabenwarteschlange VKEKBUCH? Ausgeschlossen!
• Sonstige Einrichtung/Anpassung? Ausgeschlossen!
• Druckereinrichtung? Ausgeschlossen!

Ein Entwickler zieht sich zu Zeiten der Ungewissheit gerne zurück und prüft noch einmal die zugrunde liegende Programmierung. Beim Start des NAS werden alle Mandanten durchlaufen und für jeden Mandanten dann alle Warteschlangen gestartet, die entsprechend konfiguriert sind.

Da sichergestellt ist, dass ein Job abgearbeitet wird, bevor der nächste verarbeitet wird (ergibt sich wieder aus dem Code), fällt das als möglicher Grund aus. Ist es möglich, dass die Aufgabenwarteschlange eines anderen Mandanten die Hintergrundbuchungen abarbeitet? Theoretisch schon, da ja Hintergrundaufgaben auch in einem anderen Mandanten gestartet werden können, das ist aber in diesem Fall nicht gegeben.

Also noch einmal einen Schritt zurück: Beim Start des NAS werden alle Mandanten durchlaufen und für jeden Mandanten dann alle Warteschlangen gestartet, die entsprechend konfiguriert sind. Ein Gedanke schleicht sich in meinen Kopf. Ich kontrolliere die Aufgabenwarteschlangen-Protokolleinträge der Kundendatenbank. Dazu blende ich mir zusätzlich den Aufgabenwarteschlangencode ein um zu sehen, welche Warteschlange die Verarbeitung durchgeführt hat:

Jetzt wird es interessant. Codeunit 88, die die Hintergrundbuchung durchführt, wurde sowohl von der Warteschlange VKEKBUCH als auch von STANDARD aufgerufen. Über Warteschlangengrenzen hinweg ist natürlich eine gleichzeitige Abarbeitung möglich und findet auch statt. Ein Blick in die Konfiguration der Aufgabenwarteschlange STANDARD der Kundendatenbank offenbart das folgende Bild.

Das sieht beinahe genau so aus wie im Bild weiter oben, abgesehen von dem fehlenden leeren Kategorienfilter. Ein leerer Filter bedeutet, dass diese Warteschlange für alle Kategorien herangezogen wird und dementsprechend auch die Hintergrundbuchungen abarbeitet. Zwei gleichzeitig arbeitende Aufgabenwarteschlangen für eine Kategorie ziehen aber eine Parallelverarbeitung nach sich, was sich dann unter anderem im Effekt der in “falscher Reihenfolge” erstellten Druckaufträge äußern kann. STANDARD wird mit einem Leer-Filter ausgeliefert, also ''.

Die Konfiguration des Leer-Filters '' war letztendlich auch die Lösung des Problems und die Druckreihenfolge war von da an sichergestellt. Aus diese Art können zwei einfache Anführungszeichen bzw. deren Fehlen eine ziemlich aufreibende Auswirkung haben. Der Kunde ist nun aber glücklich mit der Lösung, Buchungsvorgänge dauern aus Sicht des Anwenders nur Millisekunden (Bereitstellung zur Hintergrundbuchung) und nun passt auch die Reihenfolge.

Neben den technischen Hintergründen und der einfachen Anpassungen zum Sicherstellen der Druckreihenfolge habe ich in diesem Fall vor allem eines gelernt: Spätestens bei Vorliegen der Datenbank wäre eine lokale Reproduktion des Problems ganz einfach möglich gewesen, wenn “der erfahrene Engineer” sich an alle Informationen und vor allem die Einrichtung gehalten hätte. Die Warteschlange manuell zu starten war sicherlich einfach, aber letztendlich nicht das tatsächliche Szenario und in diesem Fall vor allem nicht zielführend!

Ich werde diesen Fall sicherlich lange Zeit in Erinnerung behalten und mich zukünftig strikter an die tatsächlichen Gegebenheiten halten. Manchmal vergisst oder übergeht man eventuell Kleinigkeiten, die aber dann genau das Problem verdecken. Happy Analyzing!

Carsten Scholling

Microsoft Dynamics Germany
Microsoft Global Business Support (GBS) EMEA

Email: cschol@microsoft.com
Microsoft Connect: https://connect.microsoft.com
Online Support: https://www.microsoft.com/support
Sicherheitsupdates: https://www.microsoft.de/sicherheit

Microsoft Deutschland GmbH
Konrad-Zuse-Straße 1
D-85716 Unterschleißheim
https://www.microsoft.de

Comments

• Anonymous
  January 16, 2014
  Das ist echt ein super Beitrag. Man spürt förmlich, das Wechselbad der Gefühle. Erst funktionert es, dann wieder nicht. Nächte Programmänderung. Dann funktioniert es wieder und dann wieder nicht. Und dann baut man ein Testsystem auf und vergisst nur eine Kleinigkeit. Und sucht sich zu Tode, obwohl nur eine Benutzereinstellung gefehlt hat. Möchte nicht wissen, wie viel Zeit das ingesamt angefallen ist...

• Anonymous
  January 29, 2014
  Hallo Andreas, ja, Sie haben Recht :) Wenn auch das obige eine Zusammenfassung eines längeren Prozesses ist, so war die Dramaturgie, auch bei mir, die ganze Zeit zu spüren. Es waren schon einige Stunden die sowohl ich, als auch einer meiner Kollegen letztendlich investiert haben. Aber auch hier gilt: Das Resultat entschädigt für so Manches, wenn es letztendlich auch nur aus zwei einfachen Anführungszeichen bestand. Carsten Scholling