En tant que développeur 4D, vous avez peut-être déjà rencontré le besoin de développer des applications sans interface utilisateur graphique (GUI), autrement dit des applications headless. Auparavant, dans 4D, ce n’était pas tout à fait possible de le faire …. jusqu’à 4D v18 ! Dans ce billet de blog, nous allons passer en revue certaines des nouvelles capacités disponibles pour que vous puissiez rendre vos applications « headless » !
Pourquoi créer des applications sans tête ? Il y a plusieurs cas d’utilisation tels que simuler le comportement de Windows sur macOS, ou avoir le comportement d’un service Windows sans utiliser le gestionnaire de service, et ainsi de suite. Mais surtout, cela ouvre de nouvelles opportunités comme le développement de bots avec 4D.
Comment lancer une application 4D en mode headless ?
Vous pouvez désormais lancer une application 4D en mode headless via la CLI (Command Line Interface) avec le nouveau paramètre« headless« . Disponible pour tous les types d’applications : 4D, 4D Server, applications autonomes, distantes, fusionnées. Dans les exemples ci-dessous, le répertoire courant est le répertoire de l’exécutable.
Exemples pour macOS (lorsque le terminal est placé dans le dossier « Contents/MacOS » du bundle) :
| ./4D\ Server –headless MyDatabase.4DLink ./ »4D Server » –headless MyDatabase.4DLink ./4D –headless MyDatabase.4DLink ./MyBuiltRemoteApp –headless |
Exemples Windows :
| « 4D Server.exe » –headless MyDatabase.4DLink 4D.exe –headless MyDatabase.4DLink MyBuiltRemoteApp.exe –headless |
Nous avons ajouté un nouvel attribut « headless » à l’objet renvoyé par la commande Get application info . Il permet de coder plus facilement en fonction du mode d’exécution : avec ou sans interface.
Remarque: Désormais, lorsque vous exécutez une application en mode service sur les systèmes Windows, elle est automatiquement exécutée comme une application sans tête. En arrêtant le service, vous quittez l’application 4D de la bonne manière (par exemple, en utilisant l’action « Quit » dans le moniteur d’activité de macOS).
Que se passe-t-il pendant l’exécution ?
Vous vous demandez peut-être : « D’accord, c’est amusant, mais que se passe-t-il si une boîte de dialogue était censée apparaître ? ». Pour vous tenir informé de ce qui se passe lors de l’exécution, 4D active automatiquement les journaux de diagnostic lors de l’exécution en mode sans tête. Les journaux capturent toutes les interfaces utilisateur qui auraient pu être affichées et les enregistrent avec la balise [{applicationName}.HDLS].
Le comportement général est que 4D attrape les commandes qui tentent d’afficher quelque chose, enregistre un événement d’avertissement avec le nom de la commande et sa chaîne d’appel, et annule l’action. Il existe quelques cas particuliers:
- Si aucune licence n’est disponible, 4D l’enregistre dans le journal des événements système et les flux standard, puis quitte.
- Si la base de données doit être convertie, 4D l’indique dans le journal des événements du système et dans les flux standard, puis quitte.
- Si aucune base de données ou aucun fichier de données disponible n’a été trouvé, 4D le signale dans le journal des événements du système et dans les flux standard, puis quitte.
- Lorsque le débogueur doit être affiché, 4D enregistre une erreur et simule ensuite l’action « abandonner ».
- Lorsqu’une alerte apparaît, 4D enregistre et simule ensuite l’action « OK ».
- Lorsque la commande QUIT 4D est appelée, 4D enregistre et simule l’action « OK ».
- Lorsqu’une application fusionnée doit être mise à jour, un journal est généré, la mise à jour est effectuée et l’application redémarre en mode sans tête.
Exemple
Par exemple, une commande ALERT exécutée sur un serveur exécuté comme un service sous Windows n’arrête plus l’exécution du serveur. 4D détecte automatiquement la commande et écrit une ligne d’avertissement dans les journaux de diagnostic. Cela ressemble à ceci :
| 11 2019-07-11 18:53:52 [myTestDatabase Server.HDLS] WARN – (Alerte : étiquette d’alerte de test) [{« type » : « projectMethod », « name » : « myTestAlert », « line »:2, « database » : « myTestDatabase »}] |
Ce système a été créé pour vous aider à voir ce qui se passe dans vos applications headless, et à améliorer votre code (si nécessaire).
UTILISATION DES FLUX STANDARD DU SYSTÈME
Nous avons ajouté le nouveau sélecteur, Into system standard outputs, à la commande LOG EVENT afin que vous puissiez envoyer un texte aux flux standard stdout et stderr. Comme vous le savez peut-être, la commande LOG EVENT possède un paramètre facultatif« importance« . Ainsi, en fonction de l’importance de l’événement, la commande enverra le texte vers le flux stdout pour Information message et Warning message, et vers le flux stderr pour Error message.
Envoyez le texte à stdout:
LOG EVENT(Into system standard outputs; "Ceci est un texte pour stdout" ;Information message)
Envoyer le texte à stderr:
LOG EVENT(Into system standard outputs; "Ceci est un texte pour stderr" ;Error message)
Vous pouvez également utiliser des redirections pour les flux standard du système stdout et stderr afin de récupérer les informations générées par 4D et votre application. Par défaut, ces flux sont généralement dirigés vers la console, rarement vers l’écran, selon les paramètres du système. Par exemple, vous pouvez rediriger les flux standard vers des fichiers à l’aide des lignes de commande suivantes.
macOS :
| ./4D –headless MaDatabase.4DLink 1>stdout.txt 2>stderr.txt |
Windows :
| 4D –headless MaDatabase.4DLink 1>stdout.txt 2>stderr.txt |
Rappel pour les combinaisons de redirection de flux :
- 1>outputFile: le flux de sortie standard sera écrit dans le fichier au lieu de la sortie par défaut du système. Le fichier est automatiquement créé au lancement de la commande. S’il existe déjà, l’ancien contenu est effacé.
- 1>>outputFile: même comportement que la syntaxe précédente, sauf que si le fichier existe déjà, il s’ajoute au contenu du flux.
- 2>errorFile: le flux d’erreur standard sera écrit dans le fichier au lieu de la sortie par défaut du système. Le fichier est automatiquement créé au lancement de la commande. S’il existe déjà, l’ancien contenu est effacé.
- 2>>errorFile: même comportement que la syntaxe précédente, sauf que si le fichier existe déjà, il ajoute le contenu du flux.
- 2>&1: le flux d’erreur est fusionné avec le flux de sortie.
- 1>&2: le flux de sortie est fusionné avec le flux d’erreur.
Note: il est même possible d’utiliser la commande open pour exécuter un package 4D sur un système macOS, les flux seront générés par cette commande et non par l’application 4D !
Conclusion
Ces nouvelles avancées vous permettent de répondre aux exigences du système et créent également de nouvelles opportunités, comme les bots. À vous de combiner cela avec vos canaux d’intégration continue (CI) et de test continu (CT) pour votre usine logicielle. Votre seule limite est votre imagination !