Sécurisation des données HFSQL

Si on veut "blinder" son code les fonctions WD Hajoute(), Hmodifie() et Hsupprime() nécessitent des tests après exécution. Ces tests sont nécessaires afin d'empêcher qu'une application continue à fonctionner avec des problèmes dans les données ... et fasse d'autres dégats plus loin.



Code "en dur" :




Tester les doublons et l'intégrité permet de garantir l'intégrité de la base. Ces tests doivent être faits lors de chaque opération de mise à jour.



Un peu mieux : l'écriture de fonctions


Bien entendu ce bout de code doit faire l'objet d'une fonction afin d'éviter d'écrire 15 lignes là où on pourrait en écrire une seule. Il sufft de reprendre le bout de code ci-dessus et de remplacer ARTICLE par un paramètre transmis à la fonction : PROCEDURE bModifie(sFichier)



Une procédure spécialisée dans la gestion de fichiers :


On peut donc écrire les trois fonctions de mise à jour : bAjoute(), bModife() et bSupprime(), ces trois fonctions testant systématiquement les erreurs et retournant un booléen.



Implémentation des transactions :


Cependant on peut aller plus loin en utilisant systématiquement les transactions. Les transactions permettent de mettre à jour les fichiers uniquement si l'intégralité du traitement a été réalisé avec succès.



Par exemple : je dois créer un entête de facture suite à la création de N lignes de factures. Que se passe t'il si le traitement se plante au beau milieu de l'écriture des lignes de factures ?



Et bien on va se retrouver avec des enregistrements de lignes de factures orphelins ! Il est possible que ça n'ai pas d'incidence ... mais il est aussi possible que ça "foutte la merde" dans un état, un calcul ou un traitement ! Combien de temps passé à rechercher ce genre de problèmes chez un client suite à un code de mise à jour mal ficelé ?



Avec l'utilisation des transactions soit tout est mis à jour, soit rien n'est mis à jour ! C'est noir ou blanc ... et pas gris clair.



Voici un exemple de code sans transaction (volontairement sans aucun test d'erreurs) :



Que se passe t'il s'il y'a une erreur lors de l'écriture de la 3ème ligne de détail ? L'appli va planter, toutes les lignes de détail ne seront pas écrites et le cumul de la facture ne sera jamais alimenté. Il s'agit là de code "passoire".



Le même traitement avec mise en place des transactions :



Certes avec la syntaxe windev native c'est plus long à écrire mais cette manière de faire GARANTIE la sécurité et l'intégrité des données. Comme je l'ai dis plus haut dans cet article, tout doit être mis en oeuvre pour éviter de devoir aller "bidouiller" les données chez les clients : perte de temps et insatisfaction client.



NOTE : le début et le fin de transaction doivent être placés le plus prêt possible du début et de la fin des opérations de mises à jour.

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

Description de la collection GF :


Préfixe des fonctions :


B = retourne un booléen

V = ne retourne rien



Fonctions de mise à jour de base :


Il s'agit du remplacement des fonctions natives (H...) avec les contrôles nécessaires après exécution (doublons, intégrité et erreur inconnue).



De plus en entrée de fonction on vérifie si une transaction est bien en cours, sans quoi on arrête le programme. Ce mécanisme permet de garantir qu'aucune mise à jour de base n'est faite sans avoir débuté une transaction.



bAjoute() : remplace le Hajoute()

bModifie() : remplace de Hmodifie()

bSupprime() : remplace le Hsupprime()



Fonctions de transactions :


vSetNomFichierTransaction () : permet d'initialiser le nom du fichier .TRS

bTransactionDebut() : débute la transaction.

bTransactionFin() : termine la transaction.

bTransactionAnnule() : annule la transaction.

vTransactionTermine() : termine la transaction (fonction interne à la collection)



NOTE : en cas d'erreur sur une fonction de mise à jour de fichier la fonction vTransactionAnnule() est appelée, il n'y a donc rien à coder dans la fonction ou méthode appelante, juste bien gérer l'interruption (avec RETOUR par exemple).

NOTE : En cas d'erreur lors du déclenchement d'opérations sur les transactions le programme est systématiquement arrêté.



Fonctions supplémentaires :


Ajoutées dans cette collection pour se simplifier la vie.



bSupprimeTout( , , ) : supprime tous les enregistrement d'un fichier ayant la valeur de clé transmise.

bExecuteRequete() : exécution d'une requête WD. L'erreur d'exécution est gérée dans la fonction.

vLitRechercheTrouve( , , ) : fonctionne de la même manière que le hLitRecherche() sauf que le programme est stoppé si on ne trouve pas la valeur recherchée. Si une transaction est débutée elle est annulée.



Un exemple :






NOTE : dans cet exemple il aurait été plus judicieux de faire le HlitRecherche() avant le début de transaction mais c'est pour illuster l'utilisation de GF.



Par :

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!