Kopflose 4D-Anwendungen

Als 4D Entwickler sind Sie vielleicht schon einmal auf die Notwendigkeit gestoßen, Anwendungen ohne grafische Benutzeroberfläche (GUI) zu entwickeln, auch bekannt als Headless Applications. Bisher war dies in 4D nicht möglich …. bis 4D v18! In diesem Blogbeitrag gehen wir auf einige der neuen Möglichkeiten ein, mit denen Sie Ihre Anwendungen „headless“ machen können!

Warum kopflose Anwendungen erstellen? Es gibt mehrere Anwendungsfälle, wie z.B. die Simulation des Windows-Verhaltens unter macOS oder das Verhalten von Windows-Diensten ohne Verwendung des Dienstmanagers usw. Vor allem aber eröffnet es neue Möglichkeiten, wie die Entwicklung von Bots mit 4D.

Wie startet man eine 4D Anwendung im Headless-Modus?

Sie können jetzt eine 4D Anwendung im Headless-Modus über die CLI (Command Line Interface) mit dem neuen Parameter„headless“ starten. Dies ist für alle Anwendungstypen möglich: 4D, 4D Server, Standalone, Remote, Merged Applications. In den folgenden Beispielen ist das aktuelle Verzeichnis das Verzeichnis der ausführbaren Datei.

macOS Beispiele (wenn das Terminal im Ordner „Contents/MacOS“ des Bundles platziert ist):

./4D\ Server –headless MyDatabase.4DLink ./“4D Server“ –headless MyDatabase.4DLink ./4D –headless MyDatabase.4DLink ./MyBuiltRemoteApp –headless

Beispiele für Windows:

„4D Server.exe“ –headless MyDatabase.4DLink 4D.exe –headless MyDatabase.4DLink MyBuiltRemoteApp.exe –headless

Wir haben ein neues „Headless“-Attribut zum Objekt hinzugefügt, das von dem Get application info Befehl zurückgegeben wird. Es erleichtert die Programmierung in Abhängigkeit vom Ausführungsmodus: mit oder ohne Schnittstelle.

Hinweis: Wenn Sie jetzt eine Anwendung im Dienstmodus auf Windows-Systemen ausführen, wird sie automatisch als Headless-Anwendung ausgeführt. Wenn Sie den Dienst stoppen, wird die 4D Anwendung korrekt beendet (z. B. mit der Aktion „Beenden“ im macOS Aktivitätsmonitor).

Was passiert während der Ausführung?

Vielleicht fragen Sie sich: „Okay, das ist ja ganz nett, aber was passiert, wenn ein Dialog erscheinen sollte?“ Um Sie darüber zu informieren, was während der Ausführung passiert, aktiviert 4D automatisch die Diagnoseprotokolle, wenn es im Headless-Modus läuft. Die Protokolle fangen alle Benutzeroberflächen ab, die hätten angezeigt werden können, und protokollieren sie mit dem Tag [{Anwendungsname}.HDLS].

Im Allgemeinen fängt 4D die Befehle ab, die versuchen, etwas anzuzeigen, protokolliert ein Warnereignis mit dem Namen des Befehls und seiner Aufrufkette und bricht die Aktion ab. Es gibt ein paar Sonderfälle:

• Wenn keine Lizenz verfügbar ist, protokolliert 4D dies im System-Ereignisprotokoll und in den Standard-Streams und bricht dann ab.
• Wenn die Datenbank konvertiert werden muss, protokolliert 4D dies im Systemereignisprotokoll und in den Standardstreams und bricht dann ab.
• Wenn keine verfügbare Datenbank oder Datendatei gefunden wurde, protokolliert 4D dies im Systemereignisprotokoll und in den Standardstreams und beendet sich dann.
• Wenn der Debugger angezeigt werden muss, protokolliert 4D einen Fehler und simuliert dann die Aktion „Abbrechen“.
• Wenn ein Alert erscheint, protokolliert 4D und simuliert dann die Aktion „OK“.
• Wenn der Befehl QUIT 4D aufgerufen wird, protokolliert 4D und simuliert anschließend die Aktion „OK“.
• Wenn eine zusammengeführte Anwendung aktualisiert werden muss, wird ein Protokoll erstellt, die Aktualisierung durchgeführt und die Anwendung im Headless-Modus neu gestartet.

Beispiel

Ein ALERT Befehl, der auf einem Server ausgeführt wird, der als Dienst unter Windows läuft, stoppt die Serverausführung nicht mehr. 4D fängt den Befehl automatisch ab und schreibt eine Warnzeile in die Diagnoseprotokolle. Sie sieht folgendermaßen aus:

11 2019-07-11 18:53:52 [myTestDatabase Server.HDLS] WARN – (Alert: Test alert label)[{„type“: „projectMethod“, „name“: „myTestAlert“, „line“:2, „database“: „myTestDatabase“}]

Dieses System wurde erstellt, um Ihnen zu helfen, zu sehen, was in Ihren Headless-Anwendungen passiert, und Ihren Code zu verbessern (wenn nötig).

VERWENDUNG DER STANDARD-STREAMS DES SYSTEMS

Wir haben den neuen Selektor, Into system standard outputs, zum LOG EVENT Befehl hinzugefügt, so dass Sie einen Text an die Standardströme stdout und stderr senden können. Wie Sie vielleicht wissen, hat der LOG EVENT Befehl einen optionalen Parameter„Wichtigkeit„. Je nach Wichtigkeit des Ereignisses sendet der Befehl den Text an den stdout-Stream für Information message und Warning message und an den stderr-Stream für Error message.

Senden Sie den Text an stdout:

LOG EVENT(Into system standard outputs; "Dies ist ein Text für stdout";Information message)

Senden Sie den Text an stderr:

LOG EVENT(Into system standard outputs; "Dies ist ein Text für stderr";Error message)

Sie können auch Umleitungen für die Systemstandardströme stdout und stderr verwenden, um von 4D und Ihrer Anwendung erzeugte Informationen abzurufen. Standardmäßig werden diese Streams in der Regel auf die Konsole umgeleitet, selten auf den Bildschirm, abhängig von den Systemeinstellungen. Sie können die Standardströme beispielsweise mit den folgenden Befehlszeilen in Dateien umleiten.

macOS:

./4D –headless MyDatabase.4DLink 1>stdout.txt 2>stderr.txt

Windows:

4D –headless MeineDatenbank.4DLink 1>stdout.txt 2>stderr.txt

Hinweis für Stream-Umleitungskombinationen:

• 1>outputFile: Der Standardausgabestrom wird in die Datei geschrieben, statt in die Standardausgabe des Systems. Die Datei wird beim Start des Befehls automatisch erstellt. Wenn sie bereits existiert, wird der alte Inhalt gelöscht.
• 1>>outputFile: Gleiches Verhalten wie die vorherige Syntax, außer dass, wenn die Datei bereits existiert, der Inhalt an den Stream angehängt wird.
• 2>FehlerDatei: Der Standard-Fehlerstrom wird in die Datei geschrieben, statt in die Standardausgabe des Systems. Die Datei wird beim Start des Befehls automatisch erstellt. Wenn sie bereits existiert, wird der alte Inhalt gelöscht.
• 2>>errorFile: Gleiches Verhalten wie die vorherige Syntax, außer dass, wenn die Datei bereits existiert, der Inhalt des Streams angehängt wird.
• 2>&1: Der Fehlerstrom wird mit dem Ausgabestrom zusammengeführt.
• 1>&2: Der Ausgabestrom wird mit dem Fehlerstrom zusammengeführt.

Hinweis: Es ist sogar möglich, den Befehl open zu verwenden, um ein 4D Paket auf einem macOS System zu starten. Die Streams werden dann von diesem Befehl und nicht von der 4D Anwendung erzeugt!

Fazit

Mit diesen Neuerungen können Sie die Systemanforderungen erfüllen und auch neue Möglichkeiten schaffen, wie z. B. Bots. Es liegt an Ihnen, dies mit Ihren Kanälen für kontinuierliche Integration (CI) und kontinuierliches Testen (CT) für Ihre Softwarefabrik zu kombinieren. Ihre einzige Grenze ist Ihre Vorstellungskraft!