Objet métier dans les sources Diva

Owned by Bertrand Littel
Last updated: 18/03/2024
8 min read

Objet métier : généralités

Principe

Les objets métiers sont des modules diva qui ont pour vocation a gérer les données d'une table de l'ERP.

Chaque objet métier a un niveau indiqué par un TAG au début du source.

Plus le niveau est élevé, plus l'objet métier propose de fonctionnalités. Les dénominations sont issues de l'alphabet grec (de ALPHA a ZETA).

Objet métier : nouveau moteur import-export tableur

Principe

Un nouveau moteur 'a5ppimpexp_sql.dhop' d'import-export tableur a été développé afin d'avoir un mécanisme 'universel objet métier'. Ainsi, lorsque l'objet métier d'une table de l'ERP.

Les objets a partir du niveau DELTA sont éligibles d'un import tableur. Le niveau ZETA permet de gérer les notes et fichiers joints.

Le visuel reprend le principe de l'ancien moteur d'import-export tableur:

Il faut MARQUER LES LIGNES a exporter.

L'option “Les données peuvent être mises en cache” ne fonctionne que pour un objet métier ZETA qui permet la mise en cache.

Ensuite l'utilisateur peut choisir les tables à traiter.

La feuille tableur comporte un onglet par table et un onglet NOTICE.

L'onglet NOTICE apporte de nombreuses informations via l'objet métier, notamment les valeurs des cases à cocher et multi-choix (en valeur et en texte), ainsi que la valeur par défaut marquée par («) ou les champs obligatoires marqués par (*). Egalement la VALEURESPACE qui permet d'indiquer que l'on veut VIDER un champ.

Lorsque l'objet métier traite les NOTES:

  • L'import peut importer des notes en CREATION uniquement (pas de modification de notes, uniquement création de note lors de la création ou modification d'une entité). Il faut indiquer le nom ODBC : NUMERONOTE ou le nom de la colonne.

  • L'export écrit le texte brut de la note dans la colonne.

Lorsque l'objet métier traite les FICHIERS JOINTS:

  • L'import peut attacher des fichiers joints en CREATION uniquement (pas de modification de fichier joint, uniquement création de lors de la création ou modification d'une entité). Il faut indiquer le nom de la colonne : JOINT

  • L'export écrit les noms des fichiers joints dans la colonne.

 

 

Remarques :

  • L'état actuel des objets métier ne permet pas de traiter les rubriques.

  • Un indicateur dans l'objet métier indique si la table peut être importée ou non par tableur.

 

 

Objet métier : gestion des notes

Principe

La gestion de notes dans les objets métiers se fait un deux phases :

  • Description des 'notes' (ou texte) dans l'objet métier pour donner des caractéristiques à ces notes (indiquer quel est le champ de note, son CE associé, l'objet,…)

  • Chez l'appelant qui affiche ou saisi des notes pour gérer l'interaction

La phase 'Description' se fait par des fonctions à implémenter dans l'objet métier:

  • Indiquer les champs 'notes' dans la Get_xxx_FieldProperties

  • Ajouter une fonction Get_xxx_FieldNoteProperties qui donne des propriétés spécifiques aux notes

  • Ajouter une fonction par note gérée Get_xxx_FieldNote_yyyy

La phase 'Chez l'appelant' va dépendre du niveau de complexité et de rendu de la note : selon que la note est gérée en fenêtre superposée, en affichage rtf dans le masque, en saisie rtf dans le masque.

L'appelant va positionner des appels à des fonctions de gestion de note (saisir, afficher,…) en indiquant un code interne de gestion de note. C'est donc l'appelant qui indique avec quelle note il travaille. La première utilisation à l'exécution va déclencher la lecture des propriétés de gestion de note, puis un module de gestion de note objet métier va prendre en charge la saisie, consultation, affectation de notes. Lors de la sauvegarde, le passage par le moteur sql de preinsert/preupdate/postdelete va utiliser toutes les données connues pour

attribuer/modifier/supprimer une note via le champ prévu et le champ indicateur CE associé, sans que l'appelant ait à les gérer.

Il s'agit, chez l'appelant, de bien distinguer le code diva qui gère la NOTE DE L'ENTITE de celui qui gère le CONTENU d'une NOTE POINTEE PAR L'ENTITE. Exemple : affichage d'une adr Par défaut la gestion de note est en mode 'affichage/saisie par fenêtre superposée'.

Description dans l'objet métier

1. FieldProperties

La fonction d'extension du dictionnaire Get_xxx_FieldProperties doit positionner l'attribut FieldIsNoteNumber = true pour le/les champ(s) qui contient(ent) une note.

Exemple:

Cette propriété va ensuite faire appel à une fonction pour donner des attributs spécifiques à la note.

2. Get de la note

On aura 2 constantes

La première doit donner un code interne unique dans tout l'ERP pour identifier la note dans l'entité. On lui donnera comme valeur : NOMDELATABLE_NOMDUCHAMPNOTE (car une même table peut avoir plusieurs champs)

Le seconde doit donner le nom d'objet. On lui donnera comme valeur : NOMDELATABLE ou le nom historique.

(Attention, 32 caractères maximum)

Puis chaque note doit avoir une fonction Get_xxx_FieldNote_yyyy où yyyy est le NOMDUCHAMPNOTE sous la forme suivante

3. FieldNoteProperties

C'est une procédure Get_xxx_FieldNoteProperties qui donne, pour chaque nom de champ indiqué dans le FieldProperties, les attributs liés à la gestion de la note (objet, champ CE associé, code interne).

Les attributs sont : la fonction de la note de l'étape 2, les constantes de l'étape 2, et le nom du champ qui contient le CE de la note.

4. Effet

La mise en place de ces fonctions dans l'objet métier rend immédiatement opérationnel l'import/export de notes via tableur ou xml.

L'utilisation chez un appelant (zoom, programme) nécessite l'appel aux fonctions de gestion de notes du module A5PMCHK001.

Cas d'une note en affichage fenêtre superposée

C'est le cas général d'un zoom qui gère une entité qui contient une note.

Exemple GTTMCHKT006 et GTTZ046

Le code à mettre chez l'appelant:

  • Déclarer A5PMCHK001.dhop

  • ZoomCreationRes doit faire appel à

A5_ChkNote_Flush() ou un appel à chaque note individuelle via la fonction

A5_ChkNote_Flush(Get_xxx_FieldNote_yyy())

  • ZoomModificationRes doit faire appel à

A5_ChkNote_Flush() ou un appel à chaque note individuelle via la fonction

A5_ChkNote_Flush(Get_xxx_FieldNote_yyy())

  • ZoomConsult lors du traitement de la touche d'affichage de note (K_SF6 en général) doit faire appel à

A5_ChkNote_Display(RSduZoom.xxx,Get_xxx_FieldNote_yyy())

  • ZoomArret lors du traitement de la touche de saisie de note (K_SF6 en général) doit faire appel à

A5_ChkNote_Input(RSduZoom.xxx,Get_xxx_FieldNote_yyy())

XmeToolbarSetButtonInfo(IdOutilZoom,“NOTE”, Condition(RSduZoom.CeNote=OUI, “<BITMAP>NOTE” ,“<BITMAP>NOTE_N”))

Remarques:

  • le module a5pmnotejoint ne sert plus dans le zoom

  • les anciennes instructions Note_debut, Note_Reinit, Note_chargement, Note_suppression ne servent plus

  • l'attributions/modification du numéro de note est fait par a5pmchk001 lors du passage dans le moteur sql

  • le champ CE est modifié dynamiquement à l'appel de A5_ChkNote_Input permettant d'utiliser sa valeur pour les bitmaps

Cas d'une note avec saisie RTF dans le masque

Exemple GTTMCHKT041 et GTTZ081

Le code à mettre chez l'appelant:

  • ZoomDebut doit faire appel à (pour indiquer un comportement de note différent que la fenêtre superposée)

;zoom spécial : la note est saisie dans le masque du zoom

A5_ChkNote_SetMode_MasqueAppelant(Get_xxx_FieldNote_yyy())

  • ZoomCreationRes doit faire appel à

A5_ChkNote_Flush() ou un appel à chaque note individuelle via la fonction

A5_ChkNote_Flush(Get_xxx_FieldNote_yyy())

Si le zoom permet la duplication il faut également :

If Zoom.Action = ZOOM_DUPLICATION

A5_ChkNote_PrepareDuplication(RSduZoom.yyy, Get_xxx_FieldNote_yyy()) EndIf

  • ZoomModificationRes doit faire appel à

A5_ChkNote_Display_ZoomMasqueAppelant(RSduZoom.xxx,Get_xxx_FieldNote_yyy())

  • ZoomAvantConsult doit faire appel à

A5_ChkNote_Display_ZoomMasqueAppelant(RSduZoom.xxx,Getxxx_FieldNote_yyy())

Remarques:

  • le module a5pmnotejoint ne sert plus dans le zoom

  • les anciennes instructions Note_debut, Note_Reinit, Note_chargement, Note_suppression, Note_Maj_Etat_Charge ne servent plus

  • l'attributions/modification du numéro de note est fait par a5pmchk001 lors du passage dans le moteur sql

  • le champ CE est modifié dynamiquement à l'appel de A5_ChkNote_Input permettant d'utiliser sa valeur pour les bitmaps

  • mw.rtfnom cest toujours utilisé pour l'affichage rtf de la note

Objet métier : gestion des fichiers joints

Principe

Le mécanisme est strictement similaire aux notes. Le terme NOTE est remplacé par ATTACH.

 

 

Objet métier : centralisation des fonctions de réservations d'entité

L'objet métier contient les fonctions de réservations d'entité de la table qu'il porte. Les autres réservations sont inchangés.

Le passage en objet métier entraîne une harmonisation des règles de nommage. Ainsi les fonctions existent sur le même schéma selon les règles suivantes:

  • Reservation_XXX_YYYY(XXX,err,f) correspond à une gestion de réservation par enregistrement XXX complet

  • Res_XXX_YYYY(champ1,err,f) correspond à une gestion de réservation par champ de la réservation uniquement

  • YYYY reflète l'action (réserver, libérer, …) : Lock ou UnLock ou Share ou Shift

  • La chaîne de réservation est construite à un endroit unique : Get_XXX_Reservation

Exemples:

Attention, cela implique que toutes les anciennes fonctions de réservation sont probablement renommées, mais sont écrites sous la même forme.

Objet métier : mise en cache d'une entité

Certaines entités (=tables) peuvent proposer la mise en cache des données afin de permettre à un appelant d'accélérer la lecture de données.

 

Mise en oeuvre dans l'objet métier

(Exemple : GTTMCHKT020) La mise en oeuvre passe par:

  • L'ajout d'une fonction 'Set_xxx_Cache_Mode' qui permet d'activer le cache pour l'entité. Cette fonction fait simplement appel a une fonction commune.

 

  • L'ajout d'une fonction 'Put_xxx_Cache_Data' qui permet d'ajouter un enregistrement au cache (pour permettre à l'appelant de lire en boucle des éléments et les placer en cache). Cette fonction fait simplement appel a une fonction commune.

 

La modification de l'écriture de la fonction LOAD.

 

  • Un premier test pour déterminer si le cache est actif ou non

  • Si le cache est actif, positionnement de la clé primaire pour la recherche d’existence dans le
    cache

  • Recherche dans le cache, et retour à 0 si trouvé dans le cache

  • Sinon, lecture de l'enregistrement, puis mise en cache en cas de réussite

Remarques:

  • La mise en cache fonctionne pour une entité complète (allcolumns=true) ou non; chaque 'mode' ayant son propre cache

  • Seuls les éléments existants sont mis en cache (pas de cache sur les recherches en échec)

  • Seules les fonctions suivantes bénéficient du cache : Load_xxx, Give_xxx

Mise en oeuvre chez l'appelant

Un programme de consultation peut par exemple, dès le début du programme, activer le cache sur les entités considérées comme 'statiques' pendant la durée du programme.

Objet métier : inter-compagnie

Principe

L'inter-compagnie utilise pleinement les objets métiers. Voir la page dédiée à l'inter-compagnie et la documentation “Divalto Généralités Inter-compagnies.docx” pour plus de détails.