Discussion :

[Hemgé]

Bonjour

J'ai besoin de vos retours d'expérience et suggestions.

On étudie un projet avec
- exploitation dans un environnement Windows, en contexte mono- ou multiutilisateurs mais mono-site
- possibilité de consultation déportée sur appareils mobiles (PDA, tablettes, …), soit via accès à distance, soit plus probablement sur base d’une copie de la base de donnée (si individuelle) ou d’un sous-ensemble extrait de la base de données si partagée.
Pas de mise à jour déportée, mais cela finira par être demandé. (Dixit Sherlock Holmes à Watson)

Le système doit gérer
- des utilisateurs opérationnels, des utilisateurs administratifs et des administrateurs, avec une identification univoque et permanente des utilisateurs présents ou passés
- des droits d’accès en fonction du type d’utilisateur, de la nature de la donnée et du type d’action.
- des degrés de confidentialité variables en fonction de la nature de la donnée
- l’interdiction d’accès - à un ou plusieurs utilisateurs - à certains sets de données ou à une donnée spécifique dans un set qui leur est par ailleurs accessible
- la traçabilité indélébile de chaque accès aux données via le logiciel, que cet accès se fasse directement par un utilisateur sur site ou par voie électronique.
- la possibilité de restituer l’historique des versions successives d’une donnée (jusqu’à la rubrique) avec horodatage précis, auteur et contenu de la modification, renommage éventuel.
Les données peuvent être inactivées, mais jamais physiquement et définitivement effacées, et doivent pouvoir être réactivées à tout moment.

Donc une application sensible et ambitieuse au niveau de la confidentialité, de la protection et de l'audit des données.

Je vous soumets une double question à propos de la journalisation (oublions le reste, qui relève du détail ... !) :

La journalisation est disponible sous Windev et apparemment sous Windev mobile.
Sous réserve évidemment de se limiter aux fonctions H+.
Selon la documentation, elle n’est pas non plus disponible lors de l’accès d’une base via l’accès distant.

1. Quel est l’avis de ceux qui ont utilisé ou utilisent la journalisation de Windev ?

2. Si on envisage de renoncer aux fonctions H+ pour SQL, on peut aussi envisager PosgreSQL et éventuellement SQLite si on veut embarquer des copies.
Quid alors de la journalisation ?
SQLite ne propose rien à ma connaissance.
Que propose PosgreSQL que je ne connais pas ?
Faudrait-il tout développer dans cette hypothèse ?

Déjà merci pour vos retours,

Hemgé

[Arnaud B.]

Je réponds partiellement sur un point :
à ma connaissance, PosgreSQL ne possède pas en standard de fonctions de journalisation, en tout cas au sens où tu l'entends (traçabilité).
Pour info, on appelle cela des fonctionnalités de CDC (change data capture).

A l'inverse de MS SQL Server ou Oracle qui disposent de modules CDC, PG ne les intégère pas en standard, et il faut donc passer :
- soit par des triggers
- soit par des extensions qui se basent sur les tables internes de PG (par exemple : http://pgfoundry.org/projects/postgrescdc, je n'ai pas testé, je ne sais pas ce que ça vaut)

A savoir qu'avec des triggers, on peut déjà assez rapidement mettre en place du CDC, personnellement je l'ai fait avec Hyperfile, car j'avais constaté que la journalisation de Windev plantait parfois (en tout cas sur les versions <15 en HF Classic) après des modifications de l'analyse (pour être précis, la consultation de la journalisation n'était plus disponible pour les données datant d'avant la modification de l'analyse).

C'est peut être réglé depuis, je n'ai pas réessayé car je préfère désormais utiliser mon propre module de CDC, ce qui me permet de ne pas être dépendant d'Hyperfile, et notamment de pouvoir le réutiliser en cas d'utilisation d'un autre SGBD.

Concrètement, (de mémoire) tu peux par exemple faire 2 tables dans ta BDD :
- une table T_CDC_TABLECHANGE_TCH dans laquelle un trigger stocke tous les changements sur les tables (ajout, modif, suppr)
- une table T_CDC_ROWCHANGE_RCH dans laquelle un trigger stocke l'action effectuée sur la ligne et les valeurs de l'enregistrement avant modif ou suppr.

Difficultés à gérer :
- sous quelle forme stocker les valeurs des rubriques avant modif (xml, table contenant les noms logiques des rubriques ? mais comment gérer les changements de noms de rubriques dans l'analyse ?)
- comment restituer la consultation de l'historique sachant qu'une table peut avoir des tables liées et que l'on souhaite donc consulter l'ensemble des modifs effectuées à partir de l'enregistrement principal (piste : lire les cardinalités des liaisons et en déduire les tables liées concernées)

Cdlt, Arnaud.

[DelphiManiac]

Vu le niveau de sécurité que ton contact désire, les questions que je me pose :


1) Est-il raisonnable de partir sur une base HyperFile ?
2) Combien d'utilisateur d'Hyperfile ont vraiment déployé toutes les fonctionnalités dont tu as besoin, ne risque tu pas de rencontrer des bugs que personnes n'a vu, par manque d'une grosse utilisation de ces fonctionnalités ?
3) Est ce que PCSoft pourra s'engager à tes cotés pour garantir la sécurité de fonctionnement ?

Pourquoi ces questions ? j'imagine que le contact qui demande ce genre de fonctionnel, va demander par ailleurs une garantie de résultat et un engagement écrit de ta société, pourra tu vraiment l'assurer ?

Si le contact à une réelle compréhension de ces demandes (ce n'est pas une lubie suite à la lecture d'articles dans la presse), tu as intérêt a bétonner le dossier et ne pas chercher des bidouilles avec Hyperfile, posgress ou sqlite.

Concernant l'embarqué, vu le degré de sécurité demandé, oubli la possibilité d'embarquer une base sur le périphérique, un smartphone ça se vole et à moins que tu puisse garantir d'avoir un moteur de BDD sur smartphone qui te permette de crypter fortement les données, reste en mode connecté.

[Hemgé]

Merci à vous deux.

posgrescdc est encore trop frais (V1 en septembre 2013) et l'activité du site est quasi nulle, avec une doc et un manuel d'installation apparemment inaccessibles. Donc exit, mais merci quand même.

Pour info, un post sur Développez en nov 2010 : CDC sous PosgreSQL

Je dois encore explorer les autres pistes.

A bien relire la doc sur la journalisation dans Windev, on peut suivre les opérations "d'écriture" sur les fichiers (ajout, modification, suppression), mais pas les opérations de "lecture" au sens de la consultation à l'écran ou de l'impression d'une information.
Dans l'optique de l'audit des consultations, il n'est pas relevant que le journal des opérations liste tous les HLitSuivant effectués dans une recherche sur un critère, qui n'a peut-être abouti à aucun affichage et donc à aucune divulgation de l'information.
Il faudrait donc au moins suppléer à cette carence, puisqu'il est requis de savoir qui a consulté quoi et quand.

On va clairement devoir s'orienter vers de la cuisine interne.
Deux pistes d'orientation :
- un mix de techniques : notification par les programmes d'affichage et d'impression, associée à des triggers pour les "écritures"
- uniquement des notifications pour uniformiser le processus. Ce sera plus gourmand, mais comme la charge du système ne sera pas très lourde, cela ne serait pas pénalisant.

Je suis aussi réticent concernant l'embarqué, mais bon, c'est au client d'évaluer le niveau de risque qu'il veut assumer et le coût que cela entraînera.
Clairement, outre les problèmes de cryptage, il faudra également pouvoir supporter le traçage des consultations déportées et ensuite synchroniser le tout avec le système central.

[Arnaud B.]

Pour répondre à DelphiManiac, je trouve que ces fonctionnalités ne sont pas nécessairement des fonctionnalités "avancées", mais au contraire assez courantes pour des applications de gestion destinées à des entreprises de grande taille.

Si vous voulez vendre à une boite cotée un logiciel qui ne permet pas de tracer les modifications effectuées, vous n'êtes pas crédible 2 mn...

Dans mon domaine de prédilection (gestion de la paye), il n'est pas imaginable de ne pas avoir de traçabilité des opérations ou de ne pas pouvoir spécifier des droits au niveau data, c'est un peu des prérequis.

Hemgé, j'ai été amené à développer dans une application de gestion l'ensemble des fonctionnalités que tu as évoquées dans ton post initial avec HF :
- pour le change data capture, c'est tout à fait possible, mais effectivement, on ne peut pas tout gérer au niveau SGBD, et pour tracer la consultation, il sera plus simple de gérer au niveau applicatif ou alors d'activer un trigger de cdc uniquement lors de l'affichage du formulaire sur lequel on veut tracer la consultation (puis de le désactiver ensuite pour éviter de tracer des HLit inutilement). Mais d'une manière générale, il faut toujours essayer de traiter ça au niveau SGBD, c'est plus sûr et plus simple à maintenir
- pour la gestion des droits niveau enregistrement ou jeu d'enregistrement, rien n'est disponible dans HF (dans posgres je ne crois pas non plus, à vérifier). En revanche ça existe dans Oracle (et probablement dans MS Sql Server). Pour ma part, j'ai du coder ça coté applicatif, en donnant la possibilité de définir pour chaque utilisateur et chaque table des listes d'enregistrements accessibles ou pas sur les 3 opérations (read, update, delete). Ce qui me génère ensuite des clauses WHERE... IN ou NOT IN.. qui se rajoutent à mes requêtes permettant d'afficher une liste ou un formulaire. Et là on complexifie quand même pas mal le code...

Donc pour résumer :
- si on peut utiliser des fonctions intégrées au SGBD, c'est mieux et plus efficace, mais ça limite le choix du SGBD et ça implique de maitriser sa programmation (création de triggers, de rôles...) ce qui nécessite quand même un gros apprentissage si on débute dans l'administration de BDD.
- si on veut faire ça avec HF, c'est tout à fait faisable bien qu'un peu long à développer et on ne peut pas tout traiter au niveau SGBD, il faut un minimum de code côté client.

Cdlt.

[DelphiManiac]

Pour répondre à DelphiManiac, je trouve que ces fonctionnalités ne sont pas nécessairement des fonctionnalités "avancées", mais au contraire assez courantes pour des applications de gestion destinées à des entreprises de grande taille.

Si vous voulez vendre à une boite cotée un logiciel qui ne permet pas de tracer les modifications effectuées, vous n'êtes pas crédible 2 mn...

Dans mon domaine de prédilection (gestion de la paye), il n'est pas imaginable de ne pas avoir de traçabilité des opérations ou de ne pas pouvoir spécifier des droits au niveau data, c'est un peu des prérequis.
...

Désolé si mes propos ont été mal exprimés, mais je n'ai jamais laissé croire, même en sous-entendu, que ce sont des fonctionnalités dont il faut se passer (suivant le contexte). Par contre, que ce soient des fonctionnalités avancés, c'est un critère plus subjectif lié au domaine de l'application.

Ce que j'ai juste voulu dire :

1) Le client demande t-il cela pour un besoin réel ou une "lubie" suite à une lecture rapide de document parlant de traçabilité ou de sécurité.
2) Si la demande est réelle et critique, je ne ferais pas confiance, dans l'état de mes connaissances (autant le préciser avant un levé de bouclier), je ne ferais pas confiance, donc, aux outils fournis par PCSoft. Autant sur la partie BDD pure, ça tourne pas trop mal, encore que je n'ai jamais cherché à planter le serveur n'importe quand pour voir comment il survie, autant sur la question intégrité de la base dans un environnement critique, je suis bien plus circonspect.
3) Si la demande n'est pas réellement justifié, c'est un choix sur lequel je pourrais m'orienter.

Concernant le choix du traitement coté client ou serveur, la question n'a d'après moi aucun intérêt à être posé, c'est coté serveur obligatoirement. Les triggers dans windev, peuvent être soit des triggers développés coté client soit coté serveur, d'après toi, quelle solution doit on adopter ? D'autre part, la gestion des transactions n'est annoncé ACID qu'en version 19. Attendons la sortie de la version pour vérifier la qualité de la mise en place de ceci.

Explication sur les transactions dans les versions actuelles de HFSQL

Complément d'information suite à un test rapide, n'hésitez pas à me dire si j'ai fait une erreur dans le protocole de test :

- Un fichier, ID auto, Nom, Prénom
- 2 PC, P1 héberge le serveur HF C/S et l'application, P2 seulement l'application
- Une application qui se connecte sur une base sur P1, avec ce code sur un bouton

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
HCréationSiInexistant(Personne)
 
SI HTransactionInterrompue() ALORS
	Info("Transaction interrompue sur " + H.TrsPoste)
FIN
 
HTransactionDébut()
HRAZ(Personne)
Personne.Nom = "Toto"
HAjoute(Personne)
Info("coucou")
HTransactionAnnule()

et ce code sur un 2ième bouton :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SI HTransactionInterrompue() ALORS
	Info("Transaction interrompue sur " + H.TrsPoste)
FIN
 
POUR TOUT Personne 
	Trace(Personne.Nom)
FIN

- Je lance l'application sur P2, lors du info("coucou"), je coupe la connexion réseau pour simuler une panne, (panne carte réseau, panne alimentation, panne de n'importe quoi)
- Je lance l'appli sur P1, je clique sur le bouton 2, je peut voir l'enregistrement qui a été créé sur P2 et cela sans message d'erreur et tant que l'application sur P2 ne sera pas redémarré et le fichier réouvert je continuerais à voir cet enregistrement invalide, enregistrement qui va disparaître par magie dès que P2 va relancer l'application et ouvrir le fichier, si un jour il redémarre. Au mieux j'aurais pu avoir une alerte lors de l'instruction HTransactionInterrompue a condition bien sûr que j'exécute cette instruction très régulièrement (toutes les combien de ms ?) pour arrêter l'application sur l'ensemble des postes qui sont en train de lire des données invalides.

Rajoutant à cela une couche d'accès distant, soumis très régulièrement à des coupures réseau, ou une synchronisation avec une base embarquée qui va embarquer des données invalides, ça fait un jolie melting pot pour aller devant au procès.


Si mon protocole n'est pas erroné (j'ai testé plusieurs fois), ça ne me rassure pas trop :/

P.S.: Testé en Windev 17, si quelqu'un à une 18 pour tester ça serait bien.

[Arnaud B.]

Concernant le choix du traitement coté client ou serveur, la question n'a d'après moi aucun intérêt à être posé, c'est coté serveur obligatoirement. Les triggers dans windev, peuvent être soit des triggers développés coté client soit coté serveur, d'après toi, quelle solution doit on adopter ?

Attention, je n'ai peut être pas été clair.
Des triggers, c'est forcément côté serveur qu'il faut les implémenter.

Mon point portait sur la traçabilité des lectures (et non pas des update et delete).
Si on active un trigger qui trace toutes les lectures sur une table de la BDD, on risque d'être saturé avec des traces peu intéressantes.
Par exemple (et je prends un exemple trivial, peu importe), dans une application de CRM, une combo qui permet à l'utilisateur de sélectionner un Contrat va provoquer une lecture du fichier Contrat, mais ce n'est pas pour çela que l'utilisateur aura consulté l'intégralité des informations du fichier Contrat, ce qu'il n'est peut être pas autorisé à faire...
Donc dans ce cas là, il sera préférable d'activer le trigger (ou le module de CDC) uniquement à la demande, et sur des tables déterminées (par exemple, si l'utilisateur accède en lecture à la fiche détaillée du Contrat, là on trace la consultation), et donc cette activation sera a priori faite par du code applicatif côté client (par exemple à chaque affichage d'un formulaire détail).

D'autre part, la gestion des transactions n'est annoncé ACID qu'en version 19. Attendons la sortie de la version pour vérifier la qualité de la mise en place de ceci.

Explication sur les transactions dans les versions actuelles de HFSQL

Là on change de sujet, ce n'est plus un problème de journalisation (en tout cas au sens de traçabilité) qui était le sujet du post initial.
Mais c'est vrai que jusqu'à présent HF C/S ne supporte que le read uncommitted ("lecture sale") ce qui est un ENORME problème dans des applications avec une forte concurrence d'accès.
Donc de ce point de vue là, la v19 est une révolution.

Complément d'information suite à un test rapide, n'hésitez pas à me dire si j'ai fait une erreur dans le protocole de test :

- Un fichier, ID auto, Nom, Prénom
- 2 PC, P1 héberge le serveur HF C/S et l'application, P2 seulement l'application
- Une application qui se connecte sur une base sur P1, avec ce code sur un bouton

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
HCréationSiInexistant(Personne)
 
SI HTransactionInterrompue() ALORS
	Info("Transaction interrompue sur " + H.TrsPoste)
FIN
 
HTransactionDébut()
HRAZ(Personne)
Personne.Nom = "Toto"
HAjoute(Personne)
Info("coucou")
HTransactionAnnule()

et ce code sur un 2ième bouton :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SI HTransactionInterrompue() ALORS
	Info("Transaction interrompue sur " + H.TrsPoste)
FIN
 
POUR TOUT Personne 
	Trace(Personne.Nom)
FIN

- Je lance l'application sur P2, lors du info("coucou"), je coupe la connexion réseau pour simuler une panne, (panne carte réseau, panne alimentation, panne de n'importe quoi)
- Je lance l'appli sur P1, je clique sur le bouton 2, je peut voir l'enregistrement qui a été créé sur P2 et cela sans message d'erreur et tant que l'application sur P2 ne sera pas redémarré et le fichier réouvert je continuerais à voir cet enregistrement invalide, enregistrement qui va disparaître par magie dès que P2 va relancer l'application et ouvrir le fichier, si un jour il redémarre. Au mieux j'aurais pu avoir une alerte lors de l'instruction HTransactionInterrompue a condition bien sûr que j'exécute cette instruction très régulièrement (toutes les combien de ms ?) pour arrêter l'application sur l'ensemble des postes qui sont en train de lire des données invalides.

Rajoutant à cela une couche d'accès distant, soumis très régulièrement à des coupures réseau, ou une synchronisation avec une base embarquée qui va embarquer des données invalides, ça fait un jolie melting pot pour aller devant au procès.


Si mon protocole n'est pas erroné (j'ai testé plusieurs fois), ça ne me rassure pas trop :/

P.S.: Testé en Windev 17, si quelqu'un à une 18 pour tester ça serait bien.

Je n'ai pas testé, mais effectivement c'est très problématique.
Si HTransactionAnnule() ne fonctionne que sur le poste qui a lancé la transaction, ça ne sert pas à grand chose...
A moins que tu aies fait le test sur du HF Classic ? Auquel cas, les fichiers de transaction sont sur le poste client ce qui expliquerait ce comportement...

Cdlt, Arnaud.

[Arnaud B.]

Je rajoute une information importante concernant l'implémentation du change data capture par des triggers : c'est forcément beaucoup plus lent que des solutions s'appuyant sur les tables internes du SGBD (extensions, fonctionnalités intégrées au SGBD) .

Donc si on a une BDD fortement accédée, le cdc peut ralentir sérieusement les opérations et il faudra tester avant mise en production et notamment comparer avec les fonctions de journalisation intégrées au SGBD s'il y en a (fonction journalisation pour HF, fonctions intégrées pour Oracle et MS SQL Server...)

Cdlt, Arnaud.

[DelphiManiac]

Je n'ai pas testé, mais effectivement c'est très problématique.
Si HTransactionAnnule() ne fonctionne que sur le poste qui a lancé la transaction, ça ne sert pas à grand chose...
A moins que tu aies fait le test sur du HF Classic ? Auquel cas, les fichiers de transaction sont sur le poste client ce qui expliquerait ce comportement...

Cdlt, Arnaud.

Sur HF C/S

[Hemgé]

Merci pour vos interventions.

Concernant l’application étudiée
La charge du système sera relativement faible :
- soit on travaille en monoposte, soit on travaille en multiposte mais rarement en accès concurrents sur un même dossier (et alors plutôt concurrence d’un accès administratif et d’un accès en production)
- 5-7.000 dossiers annuels par producteur dont 2/3 sont des mises à jour avec un maximum de 10 producteurs et 2 administratifs actifs simultanément sur les systèmes multipostes
- consultation régulière de base de données externes et consolidation.
- recours à de nombreux fichiers et tables de référence.
Donc, le SGBD ne sera pas sollicité de manière très intense.

Concernant les contraintes
Il ne s’agit pas que de CDC, mais de contrôle d’accès, de suivi d’accès et de CDC.
On trouve des solutions de CDC mais pas de solutions associées répondant à ces trois problématiques.
En sus, Oracle et SQL server pour lesquels on a cité des solutions, sont clairement hors budget.

Ces contraintes sont courantes et quasi légales dans les milieux de la santé (hôpitaux où la création d’une police de la vie privée est prévue pour bientôt en Belgique, logiciels médicaux).
Elles deviendront de plus en plus la norme dès que la « vie privée des citoyens » sera concernée, en dehors de tout critère économique ou de protection de la propriété industrielle et du secret des affaires.

Dans le cas concerné, cette exigence est fondée sur ce type de considérations et l'évolution prévisible des contraintes légales ou jurisprudentielles.

Concernant la mise en place d’une solution
HyperFile peut-il rencontrer les besoins ?
Oui, si on se restreint aux ordres Hxxx, et qu’on ne recours pas à l’accès distant.

La journalisation complète (au sens Windev) permet le suivi des accès et modifications apportées aux fichiers.
La gestion granulaire de l’accès restera du domaine de l’application.
La question des transactions devra être réévaluée à la lumière de la version 19 (ou 20).
Les mobiles sous HF (ou SQLite accès natif) bénéficient de la journalisation.

Si on sort de ces conditions (SQL et/ou accès distants) et qu’on exclut les accès natifs, point de salut avec HyperFile.
Les gros SGBD ne répondent pas non plus en totalité aux besoins, n’ont pas nécessairement de solution embarquée et sont chers.

PostgreSQL est et reste(ra) totalement gratuit.
Il ne bénéficie pas d’une solution embarquée
Il a ses pour et ses contres, comme ses supporters et ses détracteurs, mais on ne va pas refaire le débat ici.
De même et puisqu’il s’agit en premier lieu de comparer avec HyperFile, contentons nous de convenir que son niveau de qualité et de performances équivaut au moins à celui de HF, que sa documentation est très complète et claire, et que la communauté des utilisateurs est réactive.

Pour la solution embarquée, SQLite semble une réponse tout à fait acceptable, en terme de gratuité, de disponibilité, de compatibilité SQL et de performances (sur une petite base).
Peut-être peut-on ou doit-on envisager SQL Server Compact Edition (CE) 4 si on envisage des mises à jour sur les bases embarquées (ce qui n’est pas encore à l’ordre du jour).

Consultation embarquée / accès distant
Le risque de perte et de consultation inappropriée des mobiles n'est pas pris en compte ici.

Outre que le journalisation HF ne fonctionne pas avec les accès distants, la consultation embarquée obligerait à gérer le suivi des accès sur le mobile et à intégrer ensuite ce suivi à l’historique général.

Une solution simple mais bancale serait de ne transférer sur le mobile que les dossiers inscrits au planning et dont on peut donc considérer qu’ils seront consultés (mais à quel degré ?), le processus de transfert vers le mobile valant lecture par l’utilisateur du mobile.
Cette solution serait aussi approximative que lourde : tout le dossier serait censé avoir été divulgué, alors que sa consultation sera partielle, et il faudrait alors archiver une image complète de chaque dossier transféré.
Bof bof.

[DelphiManiac]

Vu que les solutions ténors du marché ne semble pas pouvoir être retenu pour une question de budgets et vu les contraintes exposées, j'aurais tendance à proposer une solution de type WebServices.

Tout le contrôle d'accès et de journalisation serait fourni par le service intermédiaire, ce qui permettrait d'utiliser a peu prêt n'importe quelle base de données. Il faut tout de même une base solide qui résiste à une panne matérielle.

Il est vrai que ça ne résous pas le problème de la consultation des données hors accès réseau, mais cette demande me semble tellement décalé au vue des contraintes formulées que je pense qu'il serait raisonnable de la réfuter.

Si cette demande reste malgré tout d'actualité, cela ne remets pas en cause pour autant le choix du WebService, cela demande juste de développer un outil de synchronisation entre l'appli embarqué autonome et le service et d'étoffer l'analyse avec le client pour savoir quoi logger lors du transfert entre le service et la base embarqué. Normalement le client devrait pouvoir comprendre les contraintes techniques qu'il y a à déporter une partie de la base sur un périphérique hors ligne, du moins je l'espère pour toi.