Discussion :

[Lo²]

Bonjour à tous,

Nous sommes en train de réfléchir à l'intégration de modules sur une de nos applications via un composant ou bibliothèque (choix non fait pour le moment).

Nous sommes en phase de test sur la faisabilité et sommes tombés sur ce type de questionnement :
Notre application principale a un fichier client, un de nos modules va avoir besoin de ce fichier, qu'en est-il de l'analyse ?

1) Devons-nous faire une analyse distincte pour chaque projet ?
Si oui, nous avons testé et le fait qu'un fichier client soit présent dans les 2 analyses faits que le fichier client du module n'est pas lu et cela bloque même la possibilité de saisie dans une table.
Sommes-nous passés à côté de quelque chose ?

2) Devons-nous partir sur une analyse partagée ?
Pas encore testé mais techniquement je n'y vois pas de soucis, c'est plutôt sur le moyen terme, pour la maintenance.
Est-ce qu'il s'agit de la bonne méthode ?

Autre info : Les modules que nous souhaiterions intégrés, pourront possiblement être indépendant également.

Merci à tous pour vos lumières

[Voroltinquo]

Les 2 solutions se valent.

1)Analyse multiple
-Pour accéder à la table CLIENT, un HChangeRep fera l'affaire

2)Partage d'analyse
-Les Perso dossiers permettront d'alléger la lecture

[Lo²]

merci à toi Voroltinquo

Comme j'avais écris, nous avons rencontré un soucis sur la présence de 2 fichiers clients, dans 2 analyses différentes.
Je vais refaire des essais.

Pour les pers-dossiers, en effet, j'avais oublié que ça existait et donc facilitera la lecture.

[Lo²]

Après test, pas de problème rencontré donc nous avons bien ces 2 choix.
merci beaucoup Voroltinquo

[Voroltinquo]

De rien.
En ce qui concerne l'option des modules, je conseillerais les composants, ce pour 2 raisons:
1-On les retrouve facilement dans l'onglet "Asistants"
2-"Avertissement
A partir de la version 18, , l'utilisation de plusieurs bibliothèques n'est pas conseillée. Il est recommandé de remplacer les bibliothèques secondaires par des composants (internes ou externes). " cf https://doc.pcsoft.fr/fr-FR/?2030027. Je pense que d'ici quelques versions il sera impossible de les intégrer aux projets.

En ce qui concerne la réutilisation des composants .....

Bon dev

[Lo²]

oui merci, entre temps j'en suis arrivé à la même conclusion en tombant sur cet avertissement.

[R&B]

Les composant interne sont une solution adaptée à votre problématique.
Il faut alors utiliser le partage GDS pour les importer dans le projet hôte uniquement sur décision de votre part.
Par mesure de simplicité et de gestion, je vous invite à partager l'analyse.
En effet, chaque composant comportant sa propre connexion (une par analyse), cela soulagera vos accès au serveur.

L'achitecture recommandée est la suivante et réponds à une approche poo :

- Composants noyaux (accès BDD, gestion des erreur, gestion 'normale'...)
- Composants spécifique (spécifique pour un métier / un client), activés uniquement sur besoins.
- et entre les deux des composant d'interface qui assure la transmission des informations entre les spécifique et le noyaux (relations de BDD si le spécifique comporte sa propre analyse).

Ce faisant vous profiterez d'une grande modularité pour une ouverture maximale. Notez alors qu'en cas de nécessité, les composants de la couche spécifique peut embarquer leur analyse mais devront aussi gérer leur propre accès aux données.

Développez chaque composants interne dans un projet dédié afin pouvoir y ajouter une configuration pour procéder aux tests et améliorations sans toucher au projet principal.
un composant permet de rendre visible ou pas certains de ses éléments. Ce qui permet de limiter les points d'entrée du projet hote. on laisse généralement disponible la déclaration et les entrée sortie d'informations. Le reste étant à la discretion du composant.

[Lo²]

Merci R&B pour ces explications.

Si j'ai bien compris, un composant interne est forcément livré avec l'application hôte alors que nous souhaitons ne livrer nos modules qu'à la demande.
Cela nous permettrait également d'effectuer des corrections/améliorations sur les modules et ne livrer les mises à jours de ceux-ci qu'aux seuls utilisateurs de ces modules.

Est-ce que je fais fausse route ?

[R&B]

bonjour

Effectivement les composants internes, comme leur nom l'indique sont partie intégrante du projet livré.
Toujours est-il qu'en utilisant l'architecture présentée : noyaux - interfaces - spécifiques, il devient possible de n'activer les spécifiques qu'à la demande.
Cela peut prendre la forme d'une configuration, de la gestion de la licence ou les deux.

Les évolutions de composants peuvent être incluses dans les mises à jour du projet hôte des composants.
Je pense aussi qu'il est possible d'utiliser les patch pour des mises à jour "intermédiaires" appropriées au dépannage.

Un autre avantage des composant internes est de pouvoir les développer dans un projet dédié. Cela permet outre l'isolation, de mettre dans ce projet l'ensemble des tests possibles du composant sans polluer le projet hôte.

Mais au final, effectivement la distribution est incluse au projet hôte une fois ce dernier a été mis à jour de la nouvelle mouture du composant.

Si on n'est pas dans le système composant externe, il faut savoir qu'on partage aussi l'espace de nom et qu'alors, le nommage doit être capable d'isoler ce qui appartient à chaque composant afin d'éviter les conflits qui sont difficile à appréhender lorsqu'on assemble des composants externe. C'est aussi un aspect à prendre en compte sans que cela soit insurmontable : un petite règle dans les nommages et le tour est joué.