Maîtrise du pattern d'importation

Introduction

Les éditions récentes de la ligne 1000 n'autorisent plus l'utilisation de rôle abstrait, et comme un certain nombre d'importations exploitent la classe abstraite TImportDonnee, dans un certain nombre de situations où le rôle liste n'était pas préchargé en mémoire, le Framework se relevait incapable de retrouver les données via ce type de rôle. Pour remédier à cette situation, dans ce cas précis, on pouvait utiliser un curseur afin d'obtenir les données.

A partir de la version 7.00, pour se prémunir de ce genre de situation, le pattern a été revu afin que l'on n'utilise plus la classe abstraite TImportDonnee, afin de faire disparaître ce rôle abstrait.

Pour parvenir à ce résultat, comme chaque session d'importation est typé et dérive de la classe de base TSessionImportation, un nouveau rôle liste de type composition pointe vers sa classe de données d'importation, avec la particularité de conserver les mêmes noms que le rôle abstrait.

A ce stade, un avantage de taille : chaque session dispose donc de données explicitement identifiées, et comme finalement le nom de rôle reste le même, au niveau SQL les attributs existants de la classe abstraite ne changeant pas, il n'y a pas besoin de faire de changement de données.

On a profité de ce changement de pattern également afin de supprimer l'utilisation de cette classe abstraite TImportDonnee non seulement sur les classes utilisatrices, mais également sur quelques classes qui en héritaient sans aucune utilisation ni aucun besoin, ceci afin d'assainir le modèle : cas généralement des classes de conversions introduite dans la version 6.20.

De plus, par exemple dans le cas d'importation des remises bancaires comme pour les relevés divers, a été introduit le séquençage des rôles listes afin de pouvoir traiter les objets dans l'ordre où ils ont été reçus, voir l'annexe à ce sujet pour plus de détail.

Important : L'ancienne classe TImportDonnee a été maintenue afin de détecter les utilisations qui peuvent encore exister dans d'autres développements, sachant que cette classe obsolète n’a plus qu'une unique règle afin de provoquer une erreur d’exécution si on essaye de l'instancier.

Cette classe a été supprimée dans la version 8.00 car elle n'avait plus lieu d'être.

Mise en œuvre du nouveau pattern d'importation

Décrivons maintenant le protocole nécessaire à mettre en œuvre afin de bénéficier de ce mécanisme. On doit obligatoirement, pour des raisons de simplicité et de compatibilité, prendre une session qui dérive de la classe de base TSessionImportation.

• Chaque session doit :
  • Déclarer un rôle liste de type composition ImportDonneeList de la classe d'importation.
  • Surcharger la règle de dérivation Derivation_classNameImport afin de définir la classe de données d'import.
  • Surcharger la méthode IGetImportDonneeList afin de retourner le rôle liste correspondant.
  • La session peut également optionnellement surcharger la nouvelle méthode ISupprimerImportDonnee qui contient actuellement un curseur de suppression génétique supprimant les données de la session, méthode annulant et remplaçant les anciennes méthodes donc une qui exploitait un broker, que l'on doit éviter au maximum désormais d'utiliser. N'utiliser cette possibilité que si votre traitement le nécessite vraiment.

• La classe d'importation associée doit :
  • Implémenter la nouvelle interface IImportDonnee.
  • Avoir le rôle référence sur la session nommé SessionImportation, c'est ce que l'on appelle dans cette situation un rôle réciproque.
  • Renseigner la méthode IGetSessionImportation qui retourne SessionImportation.
  • Renseigner la méthode ISetSessionImportation qui positionne la session d'importation.

Note : Si on désirerait traiter des données d'importations hybrides, il faudrait alors fournir une classe racine.

Exemple d'un cas d'utilisation de l'ancien pattern d'importation

Exemple d'un cas d'utilisation du nouveau pattern d'importation

Exemple de code pour l'implémentation de la session TSessionImportationPieceFacture

//Function IGetImportDonneeList():IImportDonneeList;
begin
  Result := ImportDonneeList;
end;
 
//procedure Derivation_classNameImport:boolean;
begin
  Result := 'TImportPieceFacture';
end;

Exemple de code pour l'implémentation de la classe d'importation TImportPieceFacture

On remarquera que cette partie de code est généralement la même pour l'implémentation de chaque classe d'importation.

//Function IGetSessionImportation():ISessionImportation;
begin
  Result := SessionImportation;
end;
 
//Procedure ISetSessionImportation(aSessionImportation:ISessionImportation);
begin
  SessionImportation := aSessionImportation;
end;

Remarques

Remarque concernant l'utilisation du nouveau pattern

Actuellement, si on n'utilise pas un curseur pour récupérer le rôle liste ou réciproque, étant donnée que désormais le rôle a été déplacé de la session racine TSessionImportation vers par exemple TSessionImportPieceFacture, on ne peut plus accéder directement à ce rôle ou à son attribut réciproque oidSessionImportation, il est indispensable de s'en prémunir.

Pour cela, dans la mesure du possible, il faut utiliser directement dans notre exemple TSessionImportPieceFacture.

Au cas où on devrait malgré tout travailler avec la classe de base TSessionImportation, on peut manipuler l'attribut réciproque oidSessionImportation via un PropAsVariant, méthode utilisée par exemple par le processus de base d'importation TProcessusImport ou pour le moteur d'importation obsolète TProcessusIntegrFichier.

Remarque concernant le plan de test

Félicitations, vous venez de migrer votre processus d'importation, maintenant il nous reste à vérifier que l'on n'a rien oublié.

L'import est réputé fonctionner s'il respecte les règles suivantes :

• L'importation doit se dérouler sans aucun problème pour les éléments corrects.
• L'importation doit rejeter dans la session d'import les éléments problématiques pour les traitements supportant la notion de reprise.
• De même, la visualisation de ces éléments en erreur doit toujours être opérationnel si cette fonctionnalité existait précédemment.

Pour simplifier, une importation fonctionnelle dans la version 6.50 devra se comporter de la même façon sous les versions suivantes, hormis modification possible des exigences naturellement.

Annexes

Le séquençage et son implémentation

Il existe une possibilité offerte par le Framework qui est d'utiliser un incrément : pour cela on doit déclarer un attribut entier sur les objets de la liste, dans mon cas indexRole, de préciser l'incrément et de ne surtout pas oublier de cocher la case "Ce rôle est ordonné sur l'attribut de tri".

A partir de ce moment, tout ajout à la liste avec l'instruction de rôle explicite AddRef provoquera l'incrément de ce compteur, et dès lors que l'on parcourera ce rôle, l'ordre de tri ne sera plus oid mais indexRole, sachant qu'une limitation du Framework sur l'attribut de tri dans le cas est limité à un unique attribut, même si la requête SQL générée utilisera bien comme tri indexRole,oid.

Actuellement, ce mécanisme a été rendu disponible pour les importations basés sur TSessionImportation par l'ajout de l'attribut indexRole mais n'a pas été implémenté puisque le moteur de format outils se prémunit des problème de séquencage par tirage immédiat de l'oid.

Pour mémoire, si on ne respecte pas la méthode de création, il incombera au programmeur soit d'alimenter lui-même l'index rôle, soit d'utiliser un rôle provenant par exemple d'un curseur, avec tri explicite genre UpdStamp,indexRole,oid afin de s'affranchir de cette limitation.

Exemple déclaration de rôle

Exemple diagramme métier

Référence croisée des sessions importations et des classes d'importations

— Importation (patterns) — Développement DSM —