Múltiplos servidores, um recurso local partilhado

Tradução automática de Deepl

Pode haver alturas em que poderá ser necessário que os utilizadores se liguem a muitas instâncias da mesma aplicação do servidor fundido. Quando isto acontece, a aplicação cliente resultante da fusão descarrega tantos recursos locais como as ligações ao servidor. Mas se a pasta de Recursos do seu servidor for enorme, isto pode ser um grande desperdício de tempo, volume e rede! Felizmente, 4D v18 R5 tem uma solução para este cenário!

A ligação da sua aplicação remota a vários servidores, como descrito na figura acima, resulta na obtenção desta pasta de Recursos locais no sistema:

blank

Em vez de utilizar a demorada pasta Recursos do servidor, tem a possibilidade de partilhar a mesma pasta de Recursos local entre todos estes servidores estritamente idênticos.

Aplicações REMOTE legadas

Uma nova chave buildApp está à sua disposição para partilhar a pasta local de Recursos:

<BuildApp>
<CS>
<ClientServerSystemFolderName>myApp</ClientServerSystemFolderName>

Ao ligar-se a um servidor, a informação do servidor é substituída pela cadeia de caracteres que se define ao construir a aplicação. Mantemos a chave final para lhe permitir utilizar tantas aplicações remotas quantas desejar no mesmo computador. A pasta local Recursos tem agora este aspecto:

blankPode sempre ligar-se ao servidor utilizando o diálogo de login incorporado. Neste caso, a pasta de cache que é utilizada já não é a pasta composta pela sua informação personalizada (nome da aplicação, IP, e porta), mas a que foi definida quando a aplicação foi construída.

DIÁLOGO REMOTO de ligação à alfândega em execução

Neste post do blogue, aprendemos como utilizar uma base de dados de ligação em vez do diálogo de ligação 4D legado nas suas aplicações remotas fundidas. O comportamento é baseado na utilização de um ficheiro 4DLink personalizado com o comando OPEN DATABASE.

Pode definir o nome da raiz dos recursos locais usando o novo nome_de_pasta_chave de cache no ficheiro 4DLink.

Usando o mesmo exemplo que no post do blog anteriormente mencionado, aqui está o trecho de código de um diálogo de selecção de servidor onde Form.selectedServer contém a informação do Servidor 4D:

Se (Form.selectedServer#Null)
C_TEXT ($xml)
C_OBJECT ($link)
$xml :="<?xml version=\"1.0\" encoding=\"UTF-8\"?><database_shortcut is_remote=\"true\" server_database_name=\"FA_RemoteConnexionServ\" server_path=\""+Form.selectedServer.IP+": "+Form.selectedServer.portID+"\" cache_folder_name=\""+Form.selectedServer.customCacheFolder+"\"/>"
$link :=Folder(fk user preferences folder).file("server.4dlink")
$link .setText($xml)
OPEN DATABASE ($link.platformPath)
Terminar se

Tenha em mente

Se modificar o seu pacote de aplicação de servidor, a actualização automática dos recursos locais será realizada para cada pacote diferente. Mas desde que todos os seus pacotes de aplicação de servidor sejam estritamente idênticos, os recursos locais são descarregados apenas quando necessário: na primeira ligação ao servidor!

Avatar
• Proprietário do produto - Damien Fuzeau entrou ao time 4D Product em fevereiro de 2019. Como Proprietário do Produto, está a cargo de escrever as histórias dos usuários e depois traduzi-las em especificações funcionais. Seu papel também é garantir que a implementação da funcionalidade entregue cumpra com as necessidades do cliente. Damien é formado em engenharia de software pela Universidade de Nantes. Trabalhou mais de 23 anos em sua empresa anterior, primeiro como desenvolvedor (descobrindo 4D em 1997), e mais tarde como gerente de engenharia e arquiteto de software. Essa empresa é um Partner OEM de 4D e lançou softwares empresariais baseados em 4D para milhares de usuários em centenas de servidores. Portanto Damien está acostumado ao desenvolvimento e lançamento de 4D em contextos multilinguais.