Application

Pour utiliser le framework dans une application, il faut instancier au moins un cApplication. Voir l’exemple pour plus de détails.

La classe cApplication

Cette classe est instanciée dans le code de démarrage du projet avec, comme paramètre, le nom de l’application, son sous-répertoire de données dans C:\ProgramData et un indicateur permettant de lancer la trace dès le démarrage de l’application (ceci peut donc être désactivé facilement en cas d’intégration dans un webservice). Exemple :

gpclApp est un cApplication dynamique = allouer un cApplication("MonApplication","MonApplication\",Vrai)

Cette classe est donc globale au projet. Elle récupère quelques informations de son environnement (# de processus, répertoire de données standard, nom du projet, …) mais instancie aussi, dans son constructeur, d’autres classes détaillés plus loin dans la page :

  1. cTrace (pour tracer l’exécution du programme)
  2. cErreur (qui vient de cGénérique dont cApplication hérite)
  3. cAppParamètres (pour récupérer les paramètres d’exécution du programme)
  4. cLog (pour permettre de logguer les événements dans l’application)
  5. cUtilisateur (pour savoir qui utilise l’application)

Pour que ces autres classe puissent utiliser ce qui a dans cApplication sans devoir être lui-même passé en paramètre partout, le membre global _Application est affecté par lui-même dans le constructeur de la classe :  _Application = object

La classe cTrace

Cette classe permet de créer un fichier texte unicode (extension .txt) dans le répertoire de données standard (récupéré dans le constructeur de cApplication, habituellement C:\ProgramData\MonApplication) pour garder une trace de tous les passages dans les fonctions du framework et l’ouverture/fermeture des fenêtres. Ça rend beaucoup de services en cours de développement et permet d’identifier plus facilement un problème quand déployé.

Pour activer la trace, mettre le 3eme paramètre de cApplication à vrai comme dans l’exemple ci-dessus (cela permet de tracer l’initialisation du projet). Si ce paramètre est à faux, vous pouvez toujours activer la trace ainsi : gpclApp.m_pclTrace.p_bTrace = Vrai

La méthode TraceInitTexte permet de paramétrer l’emplacement (par défaut le répertoire de données, voir cApplication), la taille (par défaut 1Mo) et le nombre de fichiers de trace (par défaut 10) à garder. Pour tout garder, mettre ce dernier paramètre à 0. Il est également possible de formater les dates et heures écrites dans les fichiers.

Par défaut, la trace est active en mode test.  Autrement, plusieurs manières de l’activer (ou l’inactiver) :

  1. Dans l’instanciation de la classe cApplication (voir ci-dessus)
  2. Par la propriété cTrace.p_bTrace

L’appel d’une méthode a été ajoutée à toutes les méthodes (AjouteMéthode), les procédures (AjouteProcédure) et les propriétés du framework (AjoutePropriété). Ces trois méthodes AjouteXXX récupèrent les paramètres de leur fonction appelante et formate le tout avant l’écriture (ajoute la date, l’heure et la pile d’exécution) dans le fichier texte. Exemple :

Appel (voir ce qu’est cApplication._Application ci-dessus) :

cApplication._Application.m_pclTrace.AjouteMéthode()

Résultat dans le fichier texte :

22/02 14:32:47 1x cSourceDeDonnées.Liste:8 ¶1="*"¶2="ID_Level='02' AND ID_JobCat='C'"¶3="TITLE_IntFR"¶4=0¶5="" FEN_Groupe.PROCEDURE.CritèresRemplir:48, FEN_Groupe:1, FEN_Principale.BTN_Modifier:3

La structure d’une ligne de trace est différente en mode test et en exécution :

  • En mode test : la date est raccourcie, si plusieurs lignes sont identiques il n’y aura qu’une ligne avec un nombre d’exécutions (ci-dessus le « 1x »)
  • En mode exécutable : la date est au complet, le nombre d’exécution est remplacé par le nom de login et le numéro de processus

La classe cAppParamètres

Une application a parfois besoin de paramètres pour fonctionner. La bonne pratique veux que l’on mette ces paramètres à l’extérieur du logiciel, dans un fichier INI par exemple, et non en dur, tout simplement car ils sont susceptibles de changer (et qu’on ne veut pas redéployer l’application juste pour ça).  C’est, par exemple, le cas des paramètres de connexion aux données.

Pour initialiser l’accès aux paramètres, il faut lancer ParamètresCharge comme par exemple :

gpclApp.m_pclParamètres.ParamètresCharge(cAppParamètres.ETypeEmplacementParamètres.FichierIni,*,Vrai,"Abc123$")

Abc123$ étant une clé de cryptage pour les données sensibles (ex : les mots de passe).

Les paramètres peuvent se trouver indifféremment dans un fichier INI, un fichier JSON ou une base de données (base de registre et fichier XML à développer). Dans le cas d’une base de données, un entier de connexion doit être passé à la fin de ParamètresCharge avec une requête de lecture et une autre d’écriture.

Les paramètres lus sont alors mis dans un membre variant de la classe.  Peuvent ensuite être utilisées les méthode Lit et Écrit. Enfin, les paramètres peuvent être sauvés dans leur destination par la méthode ParamètresSauve.

Pour éviter la méthode ParamètresSauve, il est possible de paramétrer l’instantiation de cAppParamètre pour écrire dans la destination à chaque lecture. C’est le « vrai » en 3eme position du ParamètresCharge ci-dessus.

Dans le cas où une valeur, un paramètre ou même une section changent en cours de développement, les méthode MigreXXX permettent cette transition.

Les paramètres peuvent avoir des valeurs par défaut. Pour cela, il suffit d’appeler la méthode ValeurParDéfaut autant de fois que nécessaire avec, comme dernier paramètre, un indicateur pour crypter l’information sensible (par défaut le cryptage n’est pas fait). Exemple :

gpclApp.m_pclParamètres.ValDéfaut("SQLServer","Address","MonServeurSQL")
gpclApp.m_pclParamètres.ValDéfaut("SQLServer","User","Admin")
gpclApp.m_pclParamètres.ValDéfaut("SQLServer","Password","Tigidou",Vrai)
gpclApp.m_pclParamètres.ValDéfaut("SQLServer","DB","CRMTEST")

Quand on a besoin de l’adresse du serveur SQL dans le code, on utilisera : gpclApp.m_pclParamètres.Lit(« SQLServer », »Address »).  Le framework comprendra qu’il faut récupérer « MonServeurSQL » mais écrira également cette valeur dans le fichier INI (voir le 3eme paramètre de la méthode ParamètreCharge ci-dessus). Ainsi votre fichier INI est initialisé dès la première exécution de l’application. Notez qu’une valeur par défaut peut être mise directement dans la méthode Lit. Exemple :

gpclApp.m_pclParamètres.Lit("SQLServer","Address",Faux,"MonServeurSQL")

La classe cLog

La classe cLog permet de :

  1. garder une trace de l’exécution de l’application dans un fichier texte, une base de données ou le event log de Windows
  2. d’intercepter les boites de dialogue et leur réponse grâce à la collection de procédure COL_Log (Erreur, Info, Avertissement, Confirmer, OuiNon, OKAnnuler et Dialogue)
  3. d’intercepter les demandes d’impressions (via COL_Log également)
  4. d’avertir par courriel le département TI ou le programmeur d’un problème ou d’un plantage par LogInitCrash
  5. etc …

Pour que le Log fonctionne, il faut initialiser un ou plusieurs « moyens de communication » avec les méthodes LogInitCourriel, LogInitDatabase, LogInitEventLog et LogInitTexte en leur donnant, à chacun, leur moment de déclenchement selon 4 niveaux : action utilisateur, information, avertissement et erreur. Exemple, si l’on veut logguer des messages « informatifs » et d’erreur dans le fichier de log, LogInitTexte aura le paramètre coLogNiveauInformation+coLogNiveauErreur.

La méthode LogInitCrash est particulière. Elle permet de sauver et/ou envoyer par courriel les circonstances d’un plantage de l’application. Son appel est donc souvent la toute première ligne de l’initialisation d’un projet. Exemple :

cLog.LogInitCrash(Faux,"UnMotDePasse","moi@maCompagnie.com","","gmail.com",1).

En cas de plantage, un fichier compressé est créé (méthode wdz) et crypté (grâce au mot de passe UnMotDePasse) de sorte à ce qu’un utilisateur final ne puisse pas l’ouvrir. Ce fichier contient :

  • un fichier texte avec la version de l’application et de ses composants, un JSON de cApplication (et donc le détail du crash, les paramètres, les connexions au bases de données,…),
  • un fichier dump,
  • les 3 derniers fichiers de Log,
  • les 3 derniers fichiers de Trace,
  • 3 images de l’écran de l’utilisateur avant le plantage (application Windows). Ces dernières ont prises automatiquement par le framework à intervalle régulier (peut être désactivé, voir le dernier paramètres de LogInitCrash).

La classe cUtilisateur

Cette classe récupère, dès le départ, l’IP du poste, le nom de la machine et celui de l’utilisateur connecté. Ces informations servent notamment dans cErreur.

Si l’on veut aller plus loin et que l’utilisateur est sur un réseau d’entreprise, la méthode Lit permet de récupérer toutes ses informations de l’Active Directory (une connexion LDAP doit être faite au préalable). Toutes les informations sont alors accessibles par des propriétés : nom, prénom, adresse courriel, compagnie, l’état actif, le numéro de téléphone, …

Cette classe peut vérifier, grâce aux méthodes LoginXXX, que l’utilisateur peut s’authentifier correctement sur l’ADFS (attention, une page web s’ouvre à ce moment), sur le LDAP et sur le GroupWare utilisateur.  Chacun de ces logins récupèrent diverses informations. En relisant les propriétés, celles-ci sont programmées pour renvoyer l’information « la plus fiable » demandée. Exemple, si l’on appelle p_sAdresseCourriel, cette information n’est pas présente dans le GroupWare. Si une connexion LDAP a été faite, la valeur de retour viendra de là, sinon de la connexion ADFS si elle a été faite. L’ADFS, même s’il contient des données identiques au LDAP, est moins « fiable » (lire prioritaire) que le LDAP du fait de l’ouverture (intempestive ?) de la page web d’autentification.