Couche de persistance des objets service-simplicite

Bonjour,
la période de Noël approchant, je tente ma chance… :innocent:

Est-il envisageable que le socle Simplicité gère la persistance des données collectées dans le contexte des objets service-simplicité ?

Sans trop détailler, il s’agirait de pouvoir activer une fonction de copie/cache des données sur l’instance Simplicité consommatrice (a minima les champs clés et le row_id, et éventuellement d’autres champs de l’objet distant) de telle sorte que la copie de l’objet puisse être opérée “comme si l’objet était local” (mise en relation via des fk, présentation en pillbox, etc., recherches étendues aux propriétés liées, …).

Et comme je promets d’être sage et de finir les upgrade en 5.1 de toutes mes instances avant la fin de l’année, je vise la Lune : si en plus les stratégies de resynchro (en masse ou selon le journal de modifications éventuellement disponible sur l’instance hébergeant la référence) pouvaient être activées selon les besoins, ce serait génial!

Dans ce cas on est plus dans une recopie “batch” régulière des données que dans un objet “service” a proprement parler

Si le volume des données à répliquer n’est pas énorme ça peut se mettre en place facilement en paramétrant un objet à persistance locale et en le chargeant (totalement ou partiellement, par cron ou “à la demande”) via un search sur l’objet service (celui-ci n’étant pas accessible directement)

Le cas général d’un objet service “mixte” qui stockerait localement tout ou partie des données localement pour se présenter comme un objet local tout en étant un objet service est forcément complexe. Je pense qu’il est plus simple de gérer spécifiquement des cas simples que de vouloir gérer de manière générique les cas généraux.

oui, en effet, c’est ce que j’avais tout d’abord envisagé :

  • configuration locale (gestion manuelle) - ou réplication - du modèle de l’objet distant
  • implémentation locale (spécifique) d’une tâche cron de resynchronisation

J’étais de manière passagère passé en mode “le moins possible à ma charge” (un moment de faiblesse)…

Si les données sont juste des catalogues de données (sans autre FK en cascade…) un système de réplication des objets à J-1 est une bonne approche.

Il faut mettre les définitions des objets en commun dans un module à installer partout.
Ou alors créer des versions remote/simplifiées des objets distants synchronisés avec un action de synchro par cron, et les utiliser comme des objets locaux.

J’ai déjà fait cela dans un système où on devait avoir des infos client le temps de traitement d’un dossier et les supprimer à la fin du processus = pour des raisons de découplage front/back entre systèmes donc avec des données copiées localement (mais pas synchronisée car détruite à la fin du processus de quelques jours).

Merci beaucoup pour vos avis et conseils.
J’inscris donc le sujet dans mon backlog (mon Entrée de Charge Unique)…

Ce que tu vas faire pour certains objets me semble généralisable.

Le père-noël (qui habite à la cave) me chuchote que ton sujet est très intéressant car le besoin revient souvent dans une architecture distribuée. Il faudrait avoir des objets services persistants.

  • recopie locale des meta-data + création de la table via les mécanismes usuels
  • syncho périodique des données modifiées (diff sql ou via redolog)
  • limite : si l’objet référence d’autres objets distant “non service”, le lien ne sera pas copié
  • sinon on peut très bien imaginer remonter un modèle relationnel à charger dans l’ordre des dépendances.
  • ce serait du polling périodique, sinon on peut aussi voir comment un objet “master” pourrait faire du push au fil de l’eau (asynchrone) vers des instances “abonnées”, ce qui serait une autre approche plus propre (le polling global serait une sécurité en cas de pb de synchro unitaire).

On peut prévoir ça dans la 5.3 car la 5.2 va passer en release candidate sous peu.

1 Like