Hébergement schizophrène?

Bonjour,

Je développe une base en Client-Serveur implantée dans les hôpitaux.
Jusqu’ici, la base était hébergée par l’hôpital sur un de ses propres
serveurs.

Elle est constituée de 3 dossiers :

  • un dossier ‘Vigident_Serveur’ produit par le générateur
    d’application
  • un dossier ‘Vigident_Local’ qui contient tout ce qui est propre à
    cet hôpital notamment le fichier de données .4dd
  • un dossier ‘Vigident-Client’ qui est installé sur les postes clients.

Lors des mises à jour :

  • le dossier ‘Vigident_Server’ est remplacé.
  • au 1° lancement, 4D Server met à jour les Data
  • au 1° lancement d’un client, son dossier ‘Vigident-Client’ est mis
    à jour.

Rien que du classique, je crois.

Actuellement, les hôpitaux sont contraints de se regrouper en Groupements Hospitaliers de Territoire (GHT)
ce qui fait que des entités juridiques séparées vont devoir partager des données.
L’hôpital principal du GHT (dit “Hôpital support”) devrait, logiquement, héberger les données communes du GHT
mais un hôpital n’a le droit d’héberger que ses propres données. Les données devront donc être hébergées par une société ayant l’agrément (juridique et technique) très contraignant d’“Hébergeur de santé”.
Dans mon cas, cette obligation s’applique au dossier ‘Vigident_Local’.

Mon problème est donc de savoir comment placer mes 2 dossiers ‘Vigident_Serveur’ et ‘Vigident_Local’.

  • répartis : ‘Vigident_Serveur’ à l’hôpital et ‘Vigident_Local’ chez l’hébergeur ?
  • groupés : ‘Vigident_Serveur’ et 'Vigident_Local chez l’hébergeur ?

Comme 4D Server est beaucoup plus qu’un serveur de données, je lui fait :

_ gérer une connexion

  • émettre des mails
  • déclencher des impressions

Cela plaiderait pour la solution répartie, mais n’y a t-il pas d’inconvénients (performances ?) à ce que que 4D Server s’exécutant sur un serveur de l’hôpital gère des fichiers .4DD .4Dindx, .4DIndy situés à des centaines de km sur un autre serveur chez l’Hébergeur ?

C’est la plus sûr façon d’effondrer les performances de l’applications 4D Server. Le risque d’instabilité du réseau et de déconnexion est très grand et dès lors les problèmes seront rapidement insurmontables. Les administrateurs vont te maudire :wink:

Donc AMHA il faut oublier ce type de solution.

Le fichier de données doit être accessible, de façon rapide et stable. Un storage distant ne répond pas du tout à cette définition. Encore moins s’il se situe à des centaines km.

Merci beaucoup Maurice. C’est exactement l’avis que je cherchais.

Tu me conseilles donc de mettre Appli et données chez l’hébergeur.
Cela rapproche donc 4D Server de ses données mais cela l’éloigne des 4D Client.
La stabilité et la performance entre 4D Server et ses données sont donc plus critiques qu’entre 4D Server et ses 4D Client.
C’est bien cela ?

Exactement !

: Bernard VACHE

Tu me conseilles donc de mettre Appli et données chez l’hébergeur.
Cela rapproche donc 4D Server de ses données mais cela l’éloigne des
4D Client.
La stabilité et la performance entre 4D Server et ses données sont
donc plus critiques qu’entre 4D Server et ses 4D Client.
C’est bien cela ?
Oui, et c’est normal, un serveur de données doit absolument avoir ses données “au plus près”. Pour te donner une idée, j’ai eu une fois un serveur devenu subitement “grave plus lent qu’avant” : c’était tout bêtement le fichier historique qui avait été placé par erreur sur un volume partagé du réseau local. Partant de là, le 4dindx ou le 4dd à pétaouchnok(*) du serveur, c’est garanti incurable. Alors que le serveur éloigné des clients, ça se soigne.

(*) voir tataouine (**)

(**) voir perpète

(*) voir https://www.google.com/maps/place/Tataouine,+Tunisie/@32.9778573,10.2140073,10.55z/data=!4m5!3m4!1s0x1254b7596be92873:0xd94cf811d4ad762d!8m2!3d32.9210902!4d10.4508956tataouine> (**)

En revanche Pétaouchnok ne figure pas sur Google Earth. :smiley:

Par contre, on y trouve la fameuse https://www.google.com/maps/place/Ouarzazate+45000,+Maroc/@30.9355035,-7.0026296,31632m/data=!3m2!1e3!4b1!4m5!3m4!1s0xdbb104077422057:0x26b3cb529b37ab00!8m2!3d30.9335436!4d-6.937016Ouarzazatémourir>, mais ils ont fait sauter la fin.

Merci à Maurice, Bertrand et Arnaud pour avoir éclairé le choix stratégique que j’ai à faire

Bonjour Bernard,

Je te recommande de t’approcher de 4D Service si tu veux obtenir des recommandations d’architecture.

Ils ont des experts qui pourront te proposer des avis éclairés. Tu pourras ainsi t’adosser à leurs recommandations et éviter de t’orienter vers une solution qui serait une voie sans issue.

Je pense que vu l’importance de ton client ce sera tout bénéfice pour tes affaires.

De mon côté je suis ravi de la collaboration d’AJAR avec 4D service jusqu’à ce jour.

mes 2 choc’

" La prospérité montre les heureux, l’adversité révèle les grands. "
– Pline le Jeune

Merci Maurice.

Peux-tu me donner un moyen de contacter 4D Service ? (Mail…)

Tu trouveras un lien tout en bas de cette page :

https://fr.4d.com/4d-professional-services

“Obtenez des conseils personnalisés
Demandez à être contacté par un expert 4D, à l’écoute de vos besoins et qui vous proposera la solution la mieux adaptée à votre projet.”

Merci Maurice.

J’ai suivi ton conseil et j’ai eu un entretien très enrichissant avec Olivier MAROLLEAU.

Bonne journée

Bonjour,

Parmi mes activités, j’ai depuis 10 ans celle de médecin de l’hébergeur auprès d’un Hébergeur agréé et aussi certifié de données de santé, Claranet e-santé pour ne pas le nommer.

Mes estimés collègues développeurs 4D ont précisé les bonnes conditions techniques necessaires pour héberger une solution 4D pour les hôpitaux.

Il y a un autre volet, celui de la sécurité et de la compliance au référentiel de certification de l’hébergement de santé, en principe l’HDS est la pour aider ses clients sur ces points qui ne sont loins d’être évidents.

Il faut être particulièrement vigilant sur la sécurité (versions des serveurs patchs de MAJ, ports ouverts dans les firewalls) mais aussi sur le contrôle et la traçabilité des accès des utilisateurs.

Les opérations de maintenance avec accès direct à la base peuvent être compliquées par les contraintes de l’HDS

Ceci pour dire qu’un hébergement HDS n’est pas aussi simple qu’un hébergement banal, et que la compliance HDS est assez technique

Je suis a votre disposition si vous avez des questions sur ces points

Bonne Journée

Paul Mandebrojt

Bonjour Paul,

Merci beaucoup pour ces précisions.
Cela confirme et détaille ce qu’Olivier MAROLLEAU de 4D Services m’avait indiqué.

Ravi d’avoir un avis aussi pertinent “de l’intérieur” et je retiens ta proposition de te contacter pour que tu me conseilles face aux difficultés que je ne manquerai pas de rencontrer.

Bien cordialement