Paramétrage et développement spécifique

Introduction

Lors de la mise en place d’ADONIX X3, deux niveaux d’intervention sur le produit sont possibles.

Le premier niveau est celui des paramétrages, qui peuvent jouer de façon importante sur l’ergonomie du progiciel et sur ses fonctionnalités ; le deuxième est le niveau des développements spécifiques.

La caractérisation des fonctions relevant de chaque niveau n’est donc pas liée à leur complexité relative, mais elle se fait de la façon suivante :

• Le paramétrage se caractérise par le fait qu’il n’est en principe pas impacté en cas de changement de version mineure ou de patch applicatif.  Ceci signifie qu’il n’y a pas d’effort de protection à faire pour le rendre pérenne. Les opérations de paramétrage sont accessibles, pour un utilisateur ayant le profil ADMIN de l’administrateur, dans les menus nommés Paramétrage, Exploitation, et dans les sous-menus qui en dépendent.
• Le développement doit être pérennisé par l’emploi de mesures particulières (règles de nommage, utilisation de codes activité dédiés) qui nécessite de ce fait des efforts complémentaires. Les règles à respecter pour que les développements soient pérennes sont définies dans un document annexe. Les opérations de développement sont accessibles, pour un utilisateur ayant le profil ADMIN de l’administrateur, dans les menu nommé Développement, et dans les sous-menus qui en dépendent.

La conséquence de ceci est que les solutions à base de paramétrage sont en principe moins contraignantes, du point de vue de la maintenance, et doivent être préférées, quand cela est possible, aux développements spécifiques.

Par ailleurs, une classification des opérations de paramétrage peut être faite, selon leur degré de difficulté et leur accessibilité à des utilisateurs avancés. Il en est de même pour les opérations de développement. Cette classification est faite dans la suite de ce document.

Le paramétrage peut conduire à une génération automatisée de code, mais ceci est transparent pour l’utilisateur. Il suppose dans certains cas une connaissance limitée du langage, dans la mesure où on peut utiliser des formules de calcul (un peu l’équivalent de formules Excel™) ; mais un assistant permet de simplifier leur création. De fait, on peut considérer qu’il existe un niveau simple de paramétrage et un niveau plus complexe. Certaines opérations de paramétrage nécessitent en effet des compétences de développement.

Le développement peut impliquer ou pas l’écriture de code utilisant l’AGL ADONIX. Là encore, on peut déléguer certaines opérations de développement se faisant sans écriture de code à des consultants non programmeurs, à condition d’être précautionneux sur leur pérennisation.

L’écriture d’états Crystal Reports™ peut s’apparenter à du paramétrage, mais elle suppose une bonne connaissance de la base de données d’ADONIX X3. La présence d’aides en ligne sur la structure de la base (MCD, dictionnaire en ligne) doit simplifier la connaissance de cette structure. Reste que certains états (ceux qui mettent à jour des flags d’édition) supposent l’écriture de code ADONIX, et que par ailleurs la mise à jour du dictionnaire des états est également un acte de développement (relativement simple).

Opérations relevant du paramétrage

Dans le menu de paramétrage, on trouve des sous-menus fonctionnels dépendant du progiciel en technologie X3. Ces menus correspondent effectivement à du paramétrage en général simple. Les sous-menus Utilisateurs, Paramètres généraux, Exploitation méritent une caractérisation des fonctions qui s’y trouvent. Le menu Structure générale correspond à un paramétrage simple, c’est aussi le cas du menu Workflow, dont le seul paramétrage complexe est celui des règles de Workflow.

Mise à jour de paramètres simples

Ces fonctions mettent simplement à jour des paramètres ou des données dans la base. Leur mauvaise mise en œuvre peut avoir des conséquences fonctionnelles, mais rien n’est normalement irréversible. Ces fonctions sont les suivantes :

La fonction de mise à jour des paramètres généraux (ADPVAL) est un cas particulier : c’est clairement une fonction de paramétrage, mais la modification inconsidérée de certains paramètres du superviseur (chapitre SUP) et surtout du moteur (chapitre ADX) peut être très dangereuse.

Paramétrages de second niveau

Ces paramétrages peuvent être considérés comme plus complexes pour plusieurs raisons :

Ils peuvent impliquer, pour être opérants, une phase de validation ou de génération de code. Ceci implique une revalidation en cas de copie de dossier à dossier. Même si des contrôles de validité sont faits dans ces paramétrages, un mauvais paramétrage peut, dans des cas limites, provoquer des erreurs à l’exécution du progiciel.

Entrent dans cette catégorie les fonctions suivantes :

Tous les paramétrage de transaction de saisie (dans tous les modules) entrent aussi dans cette catégorie (on crée des écrans et des sources de traitements à partir du paramétrage).

Une autre raison de complexité est que certains paramétrage peuvent supposer de la part de l’utilisateur une connaissance de la base de données, car on va définir comme critères des champs de cette base. Cette catégorie, qui peut être un peu plus complexe à paramétrer, peut aussi impliquer une génération de code associée.

Entrent dans cette catégorie les fonctions suivantes :

Enfin, certains paramétrages peuvent nécessiter le recours à des formules de calcul (qui peuvent être guidés par des assistants de paramétrage), ou nécessiter la connaissance d’un contexte (nom de l’écran à paramétrer). La connaissance de la structure de la base, du langage des formules de calcul, et du contexte technique de façon plus générale est souvent utile voire nécessaire pour réaliser ces paramétrages.

Entrent dans cette catégorie les fonctions suivantes :

Il est important de noter que, parmi ces opérations de paramétrage, certaines, lorsqu’elles sont mal faites, peuvent provoquer des dysfonctionnements des objets cibles :

• La personnalisation des objets peut aboutir à un dysfonctionnement de l’objet, par exemple si on ne place pas dans la liste gauche de l’objet tous les champs composant la clé principale de cet objet.
• Une définition erronée des statistiques, surtout si elles sont définies en temps réel, peut provoquer des erreurs à l’exécution des créations et mises à jour, empêchant ainsi le fonctionnement de l’objet de départ.
• La création de requêtes, qui crée à la fois un écran, des traitements, peut dans certains cas aboutir à des requêtes erronées lorsque les liens sont donnés sous forme explicite.

Par ailleurs, l’optimisation base de données (GESANX) suppose de bonnes connaissances techniques en gestion des bases de données ; un mauvais paramétrage peut aller à l’encontre de l’objectif recherché, à savoir améliorer les performances en exploitation.

Paramétrages particuliers

Deux séries de fonctions constituent des cas particuliers, mais sont du paramétrage :

La gestion des dossiers (GESADS), qui a des incidences importantes sur l’exploitation et nécessite, du moins quand on crée le dossier d’exploitation, une certaine expertise technique.

La gestion des pièces automatiques (GESGAU) qui nécessitent une bonne connaissance à la fois du langage et du contexte, qui aboutissent à une génération de code et qui, si elles sont mal paramétrées, aboutissent à la création de pièces comptables déséquilibrées qui ne seront pas intégrées.

Développements spécifiques

D’une façon simple, est développement spécifique tout ce qui relève, dans les menus standard du profil ADMIN, des entrées de menu Développement. L’autre manière de caractériser le spécifique est de dire qu’il nécessite le recours à au moins un code activité commençant par X, Y ou Z pour être pérennisé. Selon que le recours au langage de développement est ou n’est pas nécessaire, on peut considérer qu’il y a deux niveaux de difficulté.

Spécifiques simples

Ces spécifiques ne supposent pas un niveau d’expertise plus grand que les fonctions précédentes (dans certains cas, ils sont même plus simples que certaines fonctions complexes ci-dessus). Il ne s’agit pas forcément de fonctions, mais dans certains cas de l’utilisation limitée de certaines fonctions.

L’assistant de paramétrage Toolbox décrit ces spécifiques simples et la manière de les réaliser.

Dans tous les cas, la première règle à observer est la pérennisation de ces développements. Si ceci n’est pas fait, une revalidation quelconque de dossier va conduire à leur perte. Ceci suppose la définition et l’activation d’au moins un code activité commençant par X, Y ou Z, et l’adoption d’une normalisation des noms sur les éléments créés.

Les opérations dont on peut considérer qu’elles rentrent dans cette catégorie sont les suivantes :

Les fonctions marquées d’une astérisque peuvent être considérées comme faciles à mettre en œuvre sous certaines conditions. L’ajout de champs supplémentaires à des tables et des écrans existants, la création d’objets simples, d’écrans simples, de fenêtres et de fonctions par création d’objets sont des conditions simplificatrices de mise en œuvre.

Certaines fonctions de développement ressemblent, par leur facilité de mise en œuvre, à du paramétrage, mais peuvent être extrêmement dangereuses, car elles mettent à jour des données avec un minimum de contrôles et parfois de façon massive. Ce sont les fonctions suivantes :

En effet, la définition de transactions système (GESAMI) pour mettre à jour des champs en masse est très dangereuse si elle est faite sur des champs calculés ou ayant des contraintes d’intégrité qui peuvent être mises à mal par cette fonction. Les fonction de maintenance permettent de même de faire fi des contraintes d’intégrité.

On peut par ailleurs considérer que ce qui se trouve dans les utilitaires nécessite un niveau de connaissance de type « spécifique léger », même si certaines fonctions sont potentiellement dangereuses et doivent être bien comprises dans leur utilisation. Ceci inclut :

Les utilitaires de vérification (UTIBASE, ETAFIC, VERSYMB, AVERSION)

Les utilitaires de validation (VALDICO, ACOPDIC, ACOPTRS, ACOMPOBJ, AVALAFC, VALMENU, GENMSKTRT, COPTRT, GENMENULOC)

Les utilitaires de maintenance de dossiers (CHDOS, DEVERROU, RAZDOS, IMPDOS)

Les utilitaires de recherche (RECHACT, RECHTYP, RECHACI, RECHMESS, RECHTXT)

Les utilitaires de sauvegarde (DOSEXTRA, DOSINTEG)

Les utilitaires de gestion de patches (PATCH, APATCH, GESAPT, APATCHA)

Les utilitaires divers (AMIEXE, SYSTEME, LECTRACE, EXETRT, VISULIC, PSADX, ADXD, GENTXTTRA, MODCPT, ADELETE, RECUPLNK, ACTIVLNK).

Spécifiques complexes

Ces spécifiques supposent une connaissance approfondie du langage de développement, et donc un profil développeur affirmé. Sont notamment concernées toutes les fonctions de développement précédentes, lorsqu’elles agissent sur des écrans générés, toutes les fonctions où un point d’entrée est utilisé, toutes les fonctions où il est nécessaire d’écrire du code L4G adonix (par exemple dans un écran complexe). Les opérations qui peuvent être complexes sont :

• La définition des types de données (GESATY), les écrans (GESAMK), les fenêtres (GESAWI), les fonctions (GESAFC), les objets (GESAOB), dès lors que ces fonctions sont utilisées dans des cas complexes
• Les consultations (GESACN), les actions et fonctions liées  (GESACT,  GESASU, ADOTRT) car le recours au code adonix est nécessaire dans tous les cas.
• Les états dès lors que des traitements préliminaires doivent être réalisés.