Actions Customs et persistance de donnée

[jservajean]

Bonjour,

Je dois implémenter un système de référence unique (référence métier globale et unique), à utiliser comme valeur d'une méta-donnée, à la création d'un contenu (et ne peux pas m'appuyer sur l'ID du noeud).
Je pense m'orienter vers une classe java gérant la logique de création du numéro chrono, appelée à travers un webscript.

Et je souhaiterai donc avoir votre avis (ou conseils) sur l'implémentation de la partie stockage des données :

• Gestion des numéros de séquence avec une table Postgres, par ajout d'une table dans la base Alfresco actuelle, donc modification du schéma de départ. N'est-ce pas déconseillé ?


• Gestion toujours avec une table Postgres, mais dans une base de données indépendante de celle d'Alfresco. Dans ce cas précis, qu'est-ce qui est le plus simple :


• Attaquer la nouvelle base à travers un webservice appelé depuis un webscript ?


• Attaquer une datasource supplémentaire dans Alfresco pour pouvoir attaquer la nouvelle base ?

D'une manière générale, lorsqu'on a besoin d'ajouter des fonctionnalités tierces qui manipulent des données persistantes, quelle est la méthode recommandée ?

Merci

[rguinot]

S'il s'agit d'une référence possédant déjà un format métier particulier, il convient je pense d'avoir un système centralisé complètement externe à l'application qui génère ces numéros. ce système devrait exposer une API ReST qu'un web script pourrait consommer. Si +ieurs applications possèdent la logique de génération, il peut y avoir collision.  Plusieurs considérations peuvent entrer en ligne de compte comme la haute disponibilité de ce service, bonnes sources d'entropie pour le générateur aléatoire, …

Si le choix du format de  la référence est  libre, utiliser par exemple un UUID. dans ce cas pas besoin de services externes, il vous suffit de faire générer par l'application un nouvel UUID. Les chances de collision sont minimes :

"In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs." Source : Wikipedia

Assurez vous tout de même de la qualité de votre source aléatoire et du niveau d'entropie du système, comme pour la première solution.

[jservajean]

C'est un cas "métier"… pour être précis, je souhaite former un numéro séquentiel (au sens Oracle ou Postgre) basé sur la <valeurs de métadonnées> + <indice>.
De la forme AA_bb_001, AA_bb_002, etc, AA et bb étant des valeurs de deux métadonnées (liste de choix) sélectionnées au moment de la création du contenu, l'indice étant lui calculé.
Je m'orientais effectivement vers un WebScript.
La logique de l'incrément est étroitement liée au repository (aux instances créées en fait), je le vois plus comme une "extension" d'alfresco que d'un service complètement indépendant.

Les questions techniques que je me pose sont :
1 - gérer cette logique d'unicité via une(des) table(s) supplémentaires dans la bdd alfresco ? (je crois que c'est déconseillé, pour l'évolutivité)
2 - gérer cette logique d'unicité via une(des) table(s) dans une base de données externe, accédée via webservice REST + Webscript ? (ça paraît un peu lourd)
3 - la gérer dans un(des) fichier(s) à plat, stockés dans un répertoire accessible en écriture (celle-ci ne me plait pas beaucoup).
4 - la gérer dans un(des) fichier(s) stockés dans le Dictionnaire de données d'Alfresco (à première vue sympa car assez centralisé, mais n'est-ce pas proscrit ?).

Je crois que vous me conseillez la 2. Concernant celle-ci, pourquoi ne pas ajouter une datasource à alfresco et faire une requête BDD directe ? impossible ? contraire à l'archi d'alfresco ?

Concernant la 4, quelles sont les contre-indications d'après vous ?

Merci

[thmor]

La solution 4 a le mérite d'être totalement intégrée à l'outil. Vous pouvez gérer ce numéro séquentiel dans un fichier dans le dictionnaire de données. Il n'y a pas de contre indication. Vous pourrez incrémenter ce "chrono" par tous les moyens qu'offre Alfresco en natif (behaviour…). De plus ce numero sera accessible à l'extérieur via WebScript …

[jservajean]

Merci pour les conseils

[rguinot]

Je ne recommanderais pas les solutions 3 et 4, vous pourriez avoir des problèmes de concurrence des transactions si ce n'est pas très précautionneusement géré. En outre, je présume que ce type de numéro est utilisé par d'autres applications métier que celle-ci, d'ou ma suggestion d'en faire un service externe dédié, qui peut aussi être appelé indépendamment. La source de ces identifiants doit probablement être unique pour toutes les applications nécessitant de générer un de ces numéros

[jservajean]

Alors ce numéro chrono a vocation à n'être utilisé que pour les documents injectés dans alfresco.
Concernant la concurrence, il me semble que l'écriture dans le repository est atomique, donc si je me débrouille par exemple pour créer, avant de démarrer la transaction, un contenu vide du nom du dernier incrément, puis dans la transaction je crée le contenu dans le repository avec la référence complète (code + incrément), il ne doit pas y avoir de collision ..?
Par contre, il est vrai que ça revient à réimplémenter un système de séquences, qui serait sûrement beaucoup plus performant avec postgres…
A benchmarker…
D'une façon générale, il n'est de toute façon pas recommandé d'ajouter des tables à alfresco ? Il vaut mieux le faire dans une base indépendante (à travers ws-rest + webscript) ?