Gestion de la connexion des applications clientes

La gestion des connexions des applications clientes recouvre les mécanismes par lesquels une application cliente fusionnée se connectera au serveur cible, une fois en environnement de production.

A compter de 4D v15 R4, ces mécanismes ont été modifiés afin d'offrir davantage de contrôle au développeur et plus de flexibilité en cas d'erreur de connexion.

Les mécanismes disponibles à compter de 4D v15 R4 décrits dans cette page sont activés uniquement lorsque l'option Utiliser la nouvelle architecture pour les applications déployées de la page "Compatibilité" des Propriétés de la base est cochée (cf. section Page Compatibilité).

Le processus de connexion des applications clientes fusionnées prend en charge les cas où le serveur dédié n'est pas disponible. Le scénario du démarrage d'une application cliente 4D est le suivant :

• L'application cliente tente de se connecter au serveur via le service de découverte (basé sur le nom du serveur, publié sur le même sous-réseau que l'application cliente).
  OU
  Si des informations de connexion valides sont présentes dans le fichier EnginedServer.4DLink à l'intérieur de son dossier, l'application cliente tente de se connecter à l'adresse du serveur spécifiée dans ce fichier.
  Note de compatibilité : Lorsque l'option de compatibilité n'est pas cochée (cf. paragraphe Compatibilité), en cas d'échec à ce stade, la boîte de dialogue standard "Connexion au serveur" est directement affichée.
• En cas d'échec, l'application cliente tente de se connecter au serveur à l'aide des informations présentes dans le dossier de préférences utilisateur de l'application (fichier lastServer.xml, cf. dernière étape).
• En cas d'échec, l'application cliente affiche une boîte de dialogue d'erreur de connexion.
  
  • Si l'utilisateur clique sur le bouton Sélectionner... (lorsqu'il été autorisé par le développeur 4D au moment de la génération de l'application, voir ci-dessous), la boîte de dialogue standard "Connexion au serveur" est affichée.
  • Si l'utilisateur clique sur le bouton Quitter, l'application client quitte.
• Si la connexion est établie avec succès, les paramètres de cette connexion sont sauvegardés dans le dossier de préférences utilisateur de l'application cliente, ce qui permettra de les réutiliser ultérieurement en cas de besoin.

Le chemin du dernier serveur utilisé est automatiquement sauvegardé dans un fichier nommé lastServer.xml placé dans le dossier de préférences utilisateur de l'application cliente. Ce dossier est situé à l'emplacement suivant :

Note de compatibilité : Lorsque l'option de compatibilité n'est pas cochée (cf. paragraphe Compatibilité), le chemin n'est pas sauvegardé.

Ce mécanisme permet de prendre en charge le cas où le serveur cible primaire est temporairement indisponible pour une raison quelconque (par exemple pour une opération de maintenance). Lorsque ce cas se produit pour la première fois, la boîte de dialogue de sélection de serveur est affichée (si elle est autorisée, cf. ci-dessous) et l'utilisateur peut manuellement sélectionner un serveur alternatif, dont le chemin est alors sauvegardé si la connexion est établie et validée. Toute indisponibilité ultérieure sera alors automatiquement prise en charge à l'aide des paramètres de connexion présents dans le fichier lastServer.xml.

Notes :

• Lorsque les applications clientes ne peuvent pas bénéficier du service de découverte, par exemple à cause de la configuration réseau, il reste recommandé que le développeur indique un nom d'hôte au lors de la génération de l'application à l'aide de la clé IPAddress dans le fichier BuildApp.xml. Le mécanisme de sauvegarde du chemin du dernier serveur est conçu pour les cas d'indisponibilité temporaire uniquement.
• Dans tous les cas, il est possible de maintenir la touche Alt/Option au démarrage de l'application cliente afin d'afficher la boîte de dialogue de sélection du serveur.

Vous pouvez choisir d'afficher ou non la boîte de dialogue standard de sélection de serveur sur les applications clientes fusionnées lorsque le serveur ne répond pas.

La configuration dans ce cas dépend de l'option Utiliser la nouvelle architecture pour les applications déployées (cf. paragraphe Compatibilité) ainsi que de la valeur de la clé XML ServerSelectionAllowed sur le poste qui génère l'application client/serveur. Vous disposez de trois possibilités :

• Affichage d'un message d'erreur sans accès possible à la boîte de dialogue de sélection de serveur
  Fonctionnement par défaut pour les bases de données créées à partir de 4D v15 R4. L'application peut uniquement quitter. Ce fonctionnement est obtenu avec la configuration suivante :
  
  • Option Utiliser la nouvelle architecture pour les applications déployées : cochée
  • Clé XML ServerSelectionAllowed : valeur False ou clé omise

  

• Affichage d'un message d'erreur avec accès possible à la boîte de dialogue de sélection de serveur.
  L'utilisateur peut accéder à la fenêtre de sélection de serveur en cliquant sur le bouton Sélectionner... Ce fonctionnement est obtenu avec la configuration suivante :
  
  • Option Utiliser la nouvelle architecture pour les applications déployées : cochée
  • Clé XML ServerSelectionAllowed : valeur True

  =>

• Affichage direct de la boîte de dialogue de sélection de serveur.
  Fonctionnement par défaut pour les bases de données converties. Ce fonctionnement est celui des versions précédentes de 4D. Il est obtenu avec la configuration suivante :
  
  • Option Utiliser la nouvelle architecture pour les applications déployées : non cochée
  • Clé XML ServerSelectionAllowed : ignorée

  

Note : Pour plus d'informations sur la clé XML ServerSelectionAllowed, reportez-vous à sa description dans le manuel 4D Clés XML BuildApplication.