Múltiplos servidores web numa única instância 4D

Alguma vez precisou de utilizar múltiplos servidores web para, por exemplo, dividir o seu código de aplicação web em várias unidades de negócio, ou separar o servidor web do administrador do do utilizador ou executar uma parte antiga, ainda não preparada para a utilização preventiva, numa instância separada, permitindo que a parte principal corra de forma preventiva?

Se estiver a acenar com a cabeça sim, então continue a ler porque 4D v18 R3 permite-lhe fazê-lo… com facilidade.

Exemplo de base de dados

Manipulação de servidores webS

O novo WEB server permite a gestão de servidores web dentro de objectos separados para cada servidor. Também aceita um parâmetro opcional para definir qual o servidor a utilizar:

• Web database server para manipular o servidor web da base de dados actual (a base de dados anfitriã ou a base de dados de componentes, dependendo de onde o comando é chamado)
• Web host database server para manipular o servidor web da base de dados anfitriã a partir de um componente
• Web request receiving server para manipular o servidor web que recebe um pedido, num método comum de gestão de servidor web por exemplo.

EXECUÇÃO de um servidor web componente

Por razões de compatibilidade, um servidor web componente não se lança a si próprio, mesmo que o seu parâmetro “Launch web server at startup” esteja activado.

Para lançar o servidor web componente, deve primeiro instanciar o seu objecto servidor web utilizando o WEB server(Web database server) comando. Retorna um objecto que lhe permite gerir o servidor web componente: a manipulação do início e paragem.

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

Vamos dar uma vista de olhos às suas propriedades :

{
    "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/"
}

O objecto servidor web também inclui dois métodos de membros que lhe permitem gerir o servidor web relacionado.

Iniciando E DESENVOLvendo um servidor web

O método de membro start permite-lhe iniciar o servidor web. Se nenhum parâmetro for definido, começará a utilizar as definições definidas nas preferências da base de dados.

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

O método de membro stop permite-lhe parar o servidor web.

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

Se quiser substituir algumas definições, basta criar um objecto contendo os nomes dos atributos correspondentes às definições que pretende definir com os valores que pretende definir. Todas as outras definições utilizarão as definições actuais da base de dados.

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

Note que não pode alterar directamente as definições, primeiro tem de parar o servidor web antes de o iniciar com novas definições.

Listagem dos servidores web disponíveis

O novo comando WEB Server list devolve uma colecção de objectos correspondente a todos os servidores web disponíveis para a base de dados anfitriã.

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

O seguinte é um exemplo de resultado de uma base de dados que corre o seu próprio servidor web e dois componentes que correm os seus próprios servidores web:

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

UTILIZANDO BANCO DE DADOS Métodos WEB

Os métodos de base de dados “On Web Connection” e “On Web Authentication” podem ser invocados na base de dados que recebe o pedido, como sempre fez com os servidores web de bases de dados anfitriãs antigas. Por exemplo, se um pedido web for enviado para um servidor web componente e este pedido não se enquadrar num recurso existente, chama-se o método “On Web Connection” deste componente. Cabe-lhe a si tratar do pedido e responder, como é normalmente o caso.

E os registos?

Para evitar a procura de registos do servidor Web em múltiplos locais, mantivemo-los na pasta Logs da base de dados anfitriã. Como sempre, os registos do servidor web da base de dados anfitriã são armazenados na sua pasta Logs e cada componente tem a sua própria subpasta contendo os seus ficheiros de registo do servidor web.

Comandos web legados

Todos os comandos web legados que manipulam o servidor web da base de dados anfitriã continuam a ter como alvo a base de dados anfitriã, mesmo que sejam chamados a partir de um componente. O alvo de execução de cada comando web legado é explicado na documentação.

Apenas o novo objecto do servidor web pode manipular o servidor web do componente. Portanto, cabe-lhe a si gerir os diferentes servidores como quiser!