Conseils pour l'écriture des processus (code)
Sommaire |
Ecriture de processus
Un processus (ou traitement) est une opération réalisée sur un ensemble d’objets.
Modélisation d’un processus
Il est commode d’implémenter les processus à l’aide d’une ou plusieurs classes non persistantes.
En général un processus comprendra :
- Une ou plusieurs classes non persistantes définies au cours de la modélisation.
- Un écran d’exécution réalisant l’interface utilisateur.
L’écran d’exécution du processus doit comporter un « dataset » portant sur la classe non persistante du processus. A l’ouverture de l’écran, une instance de cette classe est automatiquement créée par le framwork d’interface. Cette instance est responsable de l’exécution du processus.
Exemple
Processus de régularisation du lettrage
Les zones de sélection de la fenêtre se retrouvent dans les attributs et dans les rôles de la classe processus. Les autres attributs et rôles n’apparaissent pas dans la fenêtre mais sont utilisés dans le programme des fonctions et des règles. La fonction Executer() est exécutée lorsque le bouton Exécuter est actionné.
Fenêtre d’exécution du processus de régularisation du lettrage.
Ecrans d’exécution et contrôle du processus Un écran d’exécution doit au moins comporter les éléments suivants :
- Un composant « dataset » portant sur la classe non persistante implémentant le processus.
- Un composant « invoker » permettant de déclencher et contrôler l’exécution du processus.
- Un contrôle de déclenchement de l’exécution du processus, généralement un bouton.
L’écran peut comporter des éléments permettant au code métier du processus d’interagir avec l’utilisateur :
- Un contrôle affichant les messages émis par le code métier, généralement un contrôle de type mémo.
- Un contrôle « barre de progression » permettant d’afficher la progression de réalisation du traitement.
- Un contrôle de déclenchement permettant d’interrompre le processus, généralement un bouton.
Messages utilisateur, progression et interruption
Le framework offre un ensemble de services permettant au code métier d’interagir avec l’utilisateur.
Note : Il n’existe pas de service permettant l’ouverture de boîte de dialogue directement à partir du code métier. |
Gestion des transactions dans les processus
Dans un écran portant sur une classe non persistante la modification d’un attribut ne déclenche pas une transaction implicite. La transaction doit donc être gérée explicitement par le code métier du processus à l’aide des API de contrôle de transaction .
Voir La gestion des transactions
Contrôle des erreurs
Contrôle des erreurs d’exécution
Le code métier a la possibilité de gérer les erreurs d’exécution à l’aide d’un bloc d’exception ; il peut alors intercepter l'exception et émettre le message vers l'interface utilisateur.
Exemple
procedure doMiseAJourAxeAnalytiqueAPlat; try _SupprimerEspaces; _MajEspaces ; ClassManager.CommitLongTran; except ClassManager.RollBackLongTran; ProgressMessage('Erreur dans la mise à jour de l''axe analytique à plat') ; ProgressMessage(E.Message) ; Completed := False ; end;
Contrôle des erreurs métiers
Le ClassManager dispose de services pour contrôler le déclenchement des messages d'erreurs et d'alertes des règles.
Voir Contrôle du contexte de session
Déclenchement d’exceptions métier
Le code métier a la possibilité de lever des exceptions métiers qui permettent d’interrompre élégamment un traitement.
Raise ERule.Create
Exemple
begin ... if Assigned(deviseBR) and (deviseBR.CodeISO = 'FRF') then Result := 'F' else if Assigned(deviseBR) and (deviseBR.CodeISO = 'EUR') then Result := 'E' else raise ERule.Create('La devise de compte bancaire doit être FRF ou EUR'); ... end;
Prise en compte des droits utilisateurs
Les droits utilisateurs ajoutés dans l’administration permettent de poser des restrictions sur les données accessibles à l’utilisateur et sur les actions qu’il est autorisé à effectuer.
Cependant ces droits ne sont pas pris en compte automatiquement dans les processus pour deux raisons :
- La première est qu’il aurait été très difficile de le faire du fait que le processus peut écrire du code SQL directement à travers des curseurs.
- La seconde est qu’il aurait été très difficile d’assurer un fonctionnement cohérent des traitements, les droits pouvant affecter de manière imprévisible le déroulement normal d’un traitement.
Dans certain cas particulier il peut être néanmoins nécessaire de prendre en compte les droits dans certains processus, par exemple ceux effectuant des consultations de données. Pour ce faire une API a été ajoutée au langage de script permettant au code métier de récupérer les éléments de droits et de les appliquer dans le code métier.
En générale les droits de lecture se traduisent par des filtres qui doivent être appliqué aux différentes requêtes.
Voir aussi :
— Code métier — Développement DSM —