A gestão das conexões das aplicações cliente cobre os mecanismo pelos quais uma aplicação cliente fusionada se conecta ao servidor de destino, quando estiver em ambiente de produção, mesmo no caso de erro de conexão

Em bancos de dados binários, os mecanismos descritos nesta página só são ativados quando for marcada a opção Utilizar a nova arquitetura para os aplicativos implementados da página "Compatibilidade" das Propriedades do banco de dados (ver a seção Página Compatibilidade).

O procedimento de conexão para aplicações de cliente fusionados é compatível com casos onde o servidor dedicado não está disponível. O cenário de startup para uma aplicação cliente 4D é o seguinte:

1. Se uma informação de conexão for armazenada no arquivo EnginedServer.4DLink dentro da aplicação cliente, a aplicação conecta ao endereço de servidor específico
   Ou
   A aplicação cliente tentar conectar ao servidor usando o serviço de descoberta (baseado no nome de servidor,  transmitido na mesma subrede.
   Nota de compatibilidade: quando a opção de compatibilidade não for marcada (ver Compatibilidade  ), se acontecer uma falha, o diálogo "Server connection" é exibido diretamente.
2. Se isto falhar, o aplicativo cliente tenta se conectar ao servidor utilizando a informação armazenada na pasta de preferências de usuário do aplicativo (arquivo (lastServer.xml, ver último passo).
3. Se isto falhar, o aplicativo cliente mostra uma caixa de diálogo de erro de conexão.
   1. Se o  usuário clicar no botão Selecionar... (quando estiver permitido pelo desenvolvedor 4D no momento da geração do aplicativo, ver mais adiante), é mostrado a caixa de diálogo padrão "Conexão ao servidor".
   2. Se o usuario clicar no botao Sair, o aplicativo cliente é fechado.
4. Se a conexão for exitosa, o aplicativo cliente salva esta informação de conexão na pasta de preferências de usuário do aplicativo para seu uso futuro.

O procedimento completo é descrito no diagrama abaixo:

O último path de servidor usado e validado é salvo automaticamente em um arquivo chamado lastServer.xml na pasta de preferência de usuário da aplicação. Essa pasta é armazenada no seguinte local:

Nota de Compatibilidade: quando essa opção de compatibilidade não for marcada (ver Compatibilidade), a rota não é salva.

Este novo mecanismo aborda o caso no qual o  servidor de destino primário esteja temporariamente indisponível por algum motivo (em manutenção, por exemplo). Quando se produz este caso pela primeira vez, a caixa de diálogo de seleção do servidor é mostrada (se estiver permitida, ver adiante) e o usuário pode selecionar manualmente um servidor alternativo, cuja rota é salvada, se a conexão for realizada corretamente. Qualquer falta de disponibilidade posterior seria manejada de forma automática através da última informação da rota lastServer.xml.

Notas:

• Quando os aplicativos cliente não puderem aproveitar de forma permanente do serviço de detecção, por exemplo, devido à configuração de rede, mesmo assim se recomenda que o desenvolvedor indique um nome de host no momento da compilação usando a tecla IPAddress no arquivo BuildApp.xml. O novo mecanismo se ocupa apenas dos casos de não disponibilidade temporal.
• Pressionar a tecla Alt/Opción ao início do aplicativo cliente com o objetivo de mostrar a caixa de diálogo de seleção do servidor ainda pode ser usada em todos os casos.
• Para permitir vários clientes fusionados com o mesmo nome e na mesma máquina para conectar a seus próprios servidores, estabeleça a chave ClientUserPreferencesFolderByPath para True no momento da construção. Isso assegura que cada aplicação de cliente fusionado tenha sua própria pasta na pasta de preferências de usuário e que conecte ao servidor correto.

É possível escolher se quer mostrar ou não mostrar a caixa de diálogo padrão de seleção nos aplicativos clientes fusionados, quando o servidor não responder.

Neste caso, a configuração depende da opção de compatibilidade Utilizar a nova arquitetura para as aplicações implementadas (ver Compatibilidade) assim como também o valor da nova chave ServerSelectionAllowed XML na máquina onde se gerou a aplicação. Há três possibilidades:

• Visualização de uma mensagem de erro sem acesso possível a caixa de diálogo de seleção de servidor
  Funcionamento pré-determinado para os bancos de dados criados a partir de 4D v15 R4. A aplicação só pode sair. Este funcionamento se obtém com a seguinte configuração:
  
  • Opção Utilizar a nova arquitetura para as aplicações implementadas: selecionada
  • Chave ServerSelectionAllowed XML: valor False ou chave omitida

  

• Visualização de uma mensagem de erro com acesso possível à caixa de diálogo de seleção de servidor
  O usuário pode acessar a janela de seleção de servidor clicando no botão Selecionar .... Este funcionamento é obtido com a seguinte configuração:
  
  • Opção Utilizar a nova arquitetura para as aplicações implementadas: selecionada
  • Chave ServerSelectionAllowed XML: valor True

  =>

• Visualização direta da caixa de diálogo de seleção de servidor
  Comportamento legado em bancos de dados binários criados com versões anteriores a 4D v15 R4 (bancos de dados binários). É obtido com a configuração abaixo:

• Opção Utilizar a nova arquitetura para as aplicações implementadas: desativada
• Chave ServerSelectionAllowed XML: ignorada   

Note: Para saber mais sobre a chave ServerSelectionAllowed XML, veja sua descrição no manual 4D XML Keys BuildApplication.