Plusieurs serveurs web dans une seule instance 4D

Traduit automatiquement de Deepl

Avez-vous déjà eu besoin d’utiliser plusieurs serveurs Web afin, par exemple, de diviser le code de votre application Web en plusieurs unités commerciales, de séparer le serveur Web de l’administrateur de celui de l’utilisateur ou d’exécuter une ancienne partie, qui n’est pas encore préemptive, dans une instance séparée, permettant à la partie principale de s’exécuter de manière préemptive ?

Si vous faites oui de la tête, alors continuez à lire car 4D v18 R3 vous permet de le faire … facilement.

Exemple de base de données

Manipulation du serveur webS

La nouvelle commande WEB server vous permet de gérer les serveurs web dans des objets séparés pour chaque serveur. Elle accepte également un paramètre facultatif pour définir le serveur à utiliser :

  • Web database server pour manipuler le serveur Web de la base de données actuelle (la base de données hôte ou la base de données du composant, selon l’endroit où la commande est appelée)
  • Web host database server pour manipuler le serveur web de la base de données hôte à partir d’un composant
  • Web request receiving server pour manipuler le serveur web recevant une requête, dans une méthode commune de gestion de serveur web par exemple.

Exécution d’un serveur web de composants

Pour des raisons de compatibilité, un serveur web de composant ne se lance pas tout seul même si son paramètre « Launch web server at startup » est activé.

Pour lancer le serveur Web du composant, vous devez d’abord instancier son objet serveur Web à l’aide de la commande WEB server(Web database server). Elle renvoie un objet permettant de gérer le serveur web composant : la manipulation du démarrage et de l’arrêt.

C_OBJECT($myComponentWebServer)
$myComponentWebServer :=WEB Server(Web database server)

Jetons un coup d’oeil à ses propriétés :

{
    "name": "HDI_WebServerObject_Component1.4dbase",
    "isRunning": false,
    "defaultHomepage": "indexComponent1.html",
    "rootFolder": "/PACKAGE/WebFolder/",
    "characterSet": 106,
    "debugLog": 0,
    "HSTSEnabled": false,
    "HSTSMaxAge": 63072000,
    "HTTPCompressionLevel": 1,
    "HTTPCompressionThreshold": 1024,
    "HTTPEnabled": true,
    "HTTPPort": 8080,
    "HTTPTrace": false,
    "HTTPSEnabled": true,
    "HTTPSPort": 4431,
    "inactiveSessionTimeout": 480,
    "IPAddressToListen": "0.0.0.0",
    "keepSession": true,
    "inactiveProcessTimeout": 480,
    "logRecording": 0,
    "maxConcurrentProcesses": 100,
    "maxRequestSize": -1,
    "maxSessions": 100,
    "sessionCookieDomain": "",
    "sessionCookieName": "4DSID",
    "sessionCookiePath": "",
    "sessionIPAddressValidation": true,
    "minTLSVersion": 3,
    "openSSLVersion": "OpenSSL 1.1.1d  10 Sep 2019",
    "perfectForwardSecrecy": false,
    "cipherSuite": "...",
    "certificateFolder": "/PACKAGE/WebCertificate/"
}

L’objet serveur web comprend également deux méthodes membres qui vous permettent de gérer le serveur web associé.

Démarrage et arrêt d’un serveur web

La méthode membre start permet de démarrer le serveur web. Si aucun paramètre n’est défini, il démarrera en utilisant les paramètres définis dans les préférences de la base de données.

WEB Server(Web host database server).start()

La méthode membre stop vous permet d’arrêter le serveur web.

WEB Server(Web host database server).stop()

Si vous voulez remplacer certains paramètres, il suffit de créer un objet contenant les noms des attributs correspondant aux paramètres que vous voulez définir avec les valeurs que vous voulez définir. Tous les autres paramètres utiliseront les paramètres actuels de la base de données.

C_OBJECT($myComponentWebServer;$options;$result)
$myComponentWebServer :=WEB Server(Web database server)
$options :=New object("HTTPPort";8081 ; "defaultHomepage" ; "myCompHomepage.html")
$result :=$myComponentWebServer.start($options)

Notez que vous ne pouvez pas modifier directement les paramètres, vous devez d’abord arrêter le serveur web avant de le démarrer avec de nouveaux paramètres.

Liste des serveurs web disponibles

La commande new WEB Server list renvoie une collection d’objets correspondant à tous les serveurs web disponibles pour la base de données hôte.

C_COLLECTION($webServers)
$webServers :=WEB Server list

Voici un exemple de résultat obtenu à partir d’une base de données exécutant son propre serveur Web et de deux composants exécutant leurs propres serveurs Web :

[
{"name": "HDI_WebServerObject_Host", ...}
,
{"name": "HDI_WebServerObject_Component1", ...}
,
{"name": "HDI_WebServerObject_Component2", ...}
]

Utilisation des méthodes WEB de la base de données

Les méthodes de base de données « On Web Connection » et « On Web Authentication » peuvent être invoquées dans la base de données qui reçoit la requête, comme cela a toujours été le cas avec les anciens serveurs Web de base de données hôte. Par exemple, si une requête web est envoyée au serveur web d’un composant et que cette requête ne correspond pas à une ressource existante, la méthode « On Web Connection » de ce composant est appelée. C’est à vous de traiter la demande et de répondre, comme c’est généralement le cas.

Qu’en est-il des journaux ?

Pour éviter de rechercher les journaux du serveur Web à plusieurs endroits, nous les avons conservés dans le dossier Logs de la base de données de l’hôte. Comme toujours, les journaux du serveur web de la base de données hôte sont stockés dans son dossier Logs et chaque composant possède son propre sous-dossier contenant ses fichiers journaux du serveur web.

Commandes Web héritées

Toutes les commandes Web héritées qui manipulent le serveur Web de la base de données hôte ciblent toujours la base de données hôte, même si elles sont appelées depuis un composant. La cible d’exécution de chaque commande Web héritée est expliquée dans la documentation.

Seul le nouvel objet serveur web peut gérer le serveur web du composant. C’est donc à vous de gérer les différents serveurs comme vous le souhaitez !

Avatar
- Product Owner -Damien Fuzeau a rejoint l'équipe 4D Product en février 2019. En tant que Product Owner, il est en charge de la rédaction des user stories, puis de leur traduction en spécifications fonctionnelles. Son travail consiste également à s'assurer que les implémentations de fonctionnalités livrées répondent aux besoins des clients.Damien est diplômé de l'Université de Nantes en génie logiciel. Il a passé plus de 23 ans dans son ancienne entreprise, d'abord en tant que développeur (découverte de 4D en 1997), puis en tant que responsable de l'ingénierie et architecte logiciel. Cette société est un partenaire OEM de 4D et a déployé des logiciels d'entreprise basés sur 4D pour des milliers d'utilisateurs, sur des centaines de serveurs. Damien est donc habitué au développement et au déploiement 4D dans un contexte multi-langues.