Fehler bei Erzeugung PDF mittels PDF Print Plugin

Geändert am Mo, 2 Sep um 4:00 NACHMITTAGS

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

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.

Inhalt

Fehler: Failed to load ressource (sporadisch auf Windows-Servern)

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.

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.

Fehlerbild: PDF-Druck braucht sehr lang und endet in Timeout

Sollte der Druck überhaupt nicht durchgeführt werden und immer in einem Timeout enden, dann sollten Sie in dem betroffenen Formular prüfen, ob JavaScript geladen wird oder CSS eingebunden wird, welche auf externe Ressourcen zugreifen.

Mögliche Ursache könnten sein

In CSS-Ressource wird das Logo mit absoluten Pfad eingebunden. Dieser kann von dem Print-Server aber nicht erreicht werden.
Lösung: Angabe der URL als relativen Pfad

Über JavaScript werden Daten von einem externen Server geladen.
Lösung: Über XFC_METADATA den requestType nicht gleich "print" abfragen, um so das Nachladen beim Druck zu verhindern

if(XFC_METADATA.requestType != "print") { 
    // TODO: Code ausführen, außer im Print 
}

Es werden eigene, externe Schriftarten eingebunden.
Lösung: Damit Schriftarten in den erstellten PDF-Dokumenten verwendet und eingebettet werden, ist es im allgemeinen nötig, dass diese auf dem Server auf dem formcycle bzw. das Print-Service-Plugin läuft installiert sind. Weitere Informationen zum Vorgehen finden Sie hier.