Partilhar recursos locais entre utilizadores com o Windows Remote Desktop Services

Tradução automática de Deepl

Esta nova funcionalidade melhora a gestão dos recursos locais das aplicações de Cliente 4D fusionadas com o Windows Remote Desktop Services. Vamos ver como.

O Windows Remote Desktop Services permite aos utilizadores abrir uma sessão Windows ou um RemoteApp, dentro e fora da rede da empresa. Ao fazer isto, os utilizadores podem ligar-se às suas aplicações de qualquer lugar através de uma ligação à Internet. Quando a aplicação não é optimizada para a utilização da largura de banda da Internet, os Remote Desktop Services são frequentemente utilizados para a limitar: não são trocados dados entre a aplicação e o servidor, mas apenas alterações no ecrã.

A arquitectura STANDARD

Quando uma aplicação de Cliente 4D se conecta a uma aplicação de Servidor 4D, é feita uma verificação para verificar se o código fonte da aplicação (código compilado, formulários, recursos externos, etc., normalmente chamados “recursos locais”) do lado do Cliente é o mesmo que o do Servidor. Se necessário, o código-fonte da aplicação é então descarregado do Servidor 4D pela aplicação incorporada do Cliente 4D e armazenado na pasta do utilizador:
\Utentes}{Users}{UserAccount}}AppData}Local}{ApplicationName}{ServerInformation}_ClientFolderSignature}
E.g. C:{Users}John Doe\AppData}Local}AppmyApp_192_168_2_134_19813_157\

Assim, quando vários utilizadores abrem a mesma aplicação Cliente 4D fundida num servidor Windows com Remote Desktop Services, os recursos locais são descarregados por cada utilizador na sua própria pasta de utilizador. Existe então uma cópia dos mesmos ficheiros em cada pasta de utilizador.

Uma nova arquitectura à sua disposição

Para melhorar o armazenamento e transferência de dados locais, a 4D desenvolveu uma nova opção para projectos no processo BuildApp para permitir a mutualização de recursos locais. É activada por esta nova chave XML BuildApp:
/Preferences4D/BuildApp/CS/ShareLocalResourcesOnWindowsClient

O comportamento herdado prevalece se a nova chave tiver um valor “Falso” ou estiver em falta.
E se esta nova chave tiver um valor “Verdadeiro”, a aplicação de Cliente 4D fusionada utilizará os recursos locais colocados neste caminho comum:
\ProgramData}{ApplicationName}{ServerInformation}_ClientFolderSignature}
e.g. C:\Dados do programamyApp_192_168_2_134_19813_157\

blank

Note-se que a pasta dos registos ainda é colocada na pasta do utilizador para evitar escritas simultâneas.

Processo de actualização

Os administradores do Windows Remote Desktop Services são muitas vezes fáceis com o processo de actualização da aplicação, mas queríamos lembrar as melhores práticas para a realização de actualizações. Um Administrador deve:
1. Desconectar todos os utilizadores que executam a aplicação de Cliente 4D fundida para actualização.
2. Proibir o acesso dos utilizadores à aplicação incorporada de Cliente 4D.
3. Actualizar a aplicação incorporada do Servidor 4D.
4. Se for activada uma actualização automática de cliente: na sessão do Administrador, iniciar a aplicação de Cliente 4D fundido e validar o processo de actualização automática. No final do processo, será lançada a aplicação Cliente 4D fundido, ligada à aplicação fundida Servidor 4D, e serão efectuadas actualizações automáticas de recursos locais na pasta partilhada.
5. Se a actualização automática do cliente for desactivada: na sessão do Administrador, actualize manualmente a aplicação Cliente 4D fundido e inicie-a para se ligar à aplicação fundida do Servidor 4D e efectuar actualizações automáticas de recursos locais na pasta partilhada.
6. Permitir o acesso dos utilizadores à aplicação cliente 4D fundida.
Este procedimento assegurará que os utilizadores não estejam a lançar várias instâncias da aplicação unida Cliente 4D, evitando escritas simultâneas aos recursos locais partilhados ou erros de direitos de escrita.

Tenha em mente

Não era uma boa prática adicionar/modificar/apagar ficheiros ou pastas na pasta de recursos locais devido a actualizações automáticas do Servidor. Isto é ainda mais verdade com este novo comportamento porque a pasta de recursos locais é partilhada entre utilizadores e muitas vezes só de leitura para utilizadores normais! É melhor utilizar a pasta Documentos do utilizador ou, eventualmente, a pasta de preferências do utilizador 4D.

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.