Fehler bei Erzeugung PDF mittels PDF Print Plugin

Geändert am Tue, 09 Jan 2024 um 07:08 PM

Die Aktion PDF erstellen (Print-Service) ist fehlgeschlagen und im Protokoll wird request timed out als Fehlerursache ausgegeben.

Folgende Fehlermeldung ist im Log zu finden:

[ERROR] [2023-12-05T14:34:18.297+01:00] [36691f8a-5d57-4f31-8812-55d8270bedc8] console.error: Failed to load resource: net::ERR_CACHE_READ_FAILURE
  at https://mein-server.de/formcycle/form/includes/ressource?name=XSignature.js&plguuid=f1530d6a-31e6-4ecb-94a9-53ea020f5982&pid=1006&_nc=1700131199094:0:0

Das ist ein Fehler, welcher sporadisch auch schon auf anderen Systemen beobachtet wurde. Bisher trat dieser nur auf Windows-Servern mit Print-Service auf.

Zur Erklärung: Der Print-Service selber startet einen Chromium-Browser, in welchem das Formular geöffnet wird, um dann von dem Formular eine PDF-Datei zu erzeugen. Beim Aufruf des Formulars müssen auch CSS- und JavaScript-Dateien geladen werden. Browser haben einen Cache, um nicht jedesmal solche Dateien neu herunterladen zu müssen.

Die Fehlermeldung besagt nun, dass der Chromium-Browser seinen Cache nicht lesen konnte. Dies hat zur Folge, dass benötigte JavaScript-Dateien nicht geladen werden können. Damit kann das Formular nicht erfolgreich aufgerufen werden und kein PDF erzeugt werden.

Den genauen Grund, für die Ursache, ist nur schwer einzugrenzen. Es ist z.B. möglich, dass Windows oder andere Cleanup-Programme die Cache-Dateien im Temp-Verzeichnis löschen, wodurch der nächste Druckversuch fehlschlägt.

Folgende Möglichkeiten bestehen um dies zu vermeiden:

Im Workflow-Plugin für die Aktion im Workflow-Designer von formcycle gibt es in der aktuellen Version die Möglichkeit, die Anzahl der Wiederholungsversuche festzulegen. Wenn hier etwa 3 eingetragen wird, dann wird bei einem Fehler beim Drucken noch 2-Mal erneut versucht, den Druck durchzuführen. Da es meist so ist, dass der Chromium-Browser nach dem ersten Fehlschlag seinen Cache neu initialisiert, kann dies helfen, den Fehler zu vermeiden.
Am Print-Server gibt es beim Starten das Kommandozeilen-Flag "--isolatedBrowser". Bei jeder Anfrage zum Drucken eines Formulars wird dann ein neuer Browser geöffnet (ansonsten wird der gleiche Browser wiederverwendet und nur ein neuer Tab geöffnet). Es wird dann auch jedesmal ein neues User-Profile und Cache-Verzeichnis erstellt und nach Beendigung des Drucks wieder gelöscht. Solange Sie kein hohes Aufkommen haben (konstant mehrere Absendungen pro Sekunde), sollte das kein Performance-Problem darstellen.
Weiterhin gibt es am Print-Server noch das Kommandozeilen-Flag "--userDataDir". Hiermit kann das Verzeichnis für das User-Profile geändert werden, wo auch das Cache-Verzeichnis enthalten ist. Standardmäßig wird das Temp-Verzeichnis von Windows verwendet, was dann möglicherweise durch Windows oder andere Programme geleert wird. Dann würde es helfen, hier ein anderes Nicht-Temp-Verzeichnis festzulegen.

Diese 3 Möglichkeiten können auch parallel verwendet werden.

Beispiel zum Starten des Print-Servers mit beiden Einstellungen direkt über die Kommandozeile:

npm run server -- start --verbose=true --port=8090 --userDataDir=D:/formcycle/print-server/profile --isolatedBrowser

Bei Verwendung des Installations-Scripts für den Windows-Service muss der Print-Service zuerst gestoppt und deinstalliert werden, dann in den Dateien "install-windows-service.js" und "uninstall-windows-service.js" oben bei "scriptOptions" die Einstellungen hinzugefügt werden und der Service wieder installiert werden.