Fonctionnalités applicatives
Appel de blocs PL/SQL
Concept
Le but est de pouvoir appeler des blocs PL/SQL à partir de la configuration et d’intégrer les résultats au flux de présentation.
Déclaration des blocs
Les blocs PL/SQL sont déclarés dans la configuration sous la forme d’un nouveau type. Ils sont liés à un type de vue au même titre que les ViewObject et ApplicationModule.
La définition de l’appel d’un bloc PL/SQL se fait de la façon suivante :
· key : clé publique de bloc PL/SQL.
· resolverClass : classe métier attachée. Cette classe permet la résolution des inconnues du ploc PL/SQL.
· value : le code pour appeler le bloc PL/SQL lui-même.
L’appel au bloc PL/SQL se trouve intégré dans la déclaration d’un type de vue, sous le nœud retrieve.
Exemple de configuration
< view_type name =" PLSQL " document =" PLSQL ">
< retrieve >
< plsql_bloc key =" TEST " resolverClass =" fr.ACE.technicalframework.application.DefaultPLSQLBlockResolver " value =" begin insert into roa values (?); end; "/>
< plsql_bloc key =" OT " resolverClass =" fr.ACE.technicalframework.application.DefaultPLSQLBlockResolver " value =" begin gxp_ot.pro_rec_fast(); end; "/>
</ retrieve >
< sort />
</ view_type >
< document name =" PLSQL " class =" fr.ACE.technicalframework.application.document.PLSQLDocumentImpl "/>
Cinématique d’exécution
La cinématique est du type
retrieve(),assimilate()
L’action retrieve() provoque la résolution des inconnues, l’action assimilate() provoque l’exécution du bloc PL/SQL.
L’appel est asynchrone, on n'attend jamais de résultat. Seule l'action assimilate() permet l'exécution. Un code retour éventuel est positionné dans le flux XML de présentation.
Intégration d’un flux métier.
Concept
Le principe est de pouvoir compléter le flux de présentation.
Le flux de présentation est actuellement construit à partir de deux sources distinctes :
· les ViewObject, en mode CRUD,
· Les DocumentRow, en mode API et bientôt en PL/SQL.
Maintenant, le métier aura la possibilité de générer son propre flux de présentation. Ce flux sera positionné au même niveau que la BusinessView, directement sous le nœud < layout_data >.
Cette nouveauté a des impacts sur 4 niveaux :
1. Des classes métier Java d’un nouveau type, présentes dans fr.generix.metier.businessflow. Ces classes fournissent des segments de flux XML.
2. De la configuration, afin de faire le lien entre les classes Java métier et le moteur (socle)
3. Les feuilles de styles, afin de prendre en compte le nouveau morceau de flux.
4. Et bien évidemment le socle qui, en interne, fait le lien entre les différents éléments.
Déclaration des BusinessFlow
La structure de la déclaration d’un type de BusinessFlow est la suivante :
name : nom du type de flux métier.
solverName : classe métier attachée. Cette classe permet la génération du flux métier. Nom logique. Fait référence à un Solver parmi les solver_def de type flow.
La définition d’un BusinessFlow est la suivante :
Name : le nom du BusinessFlow dans la BusinessView. Donne le nom du nœud de base dans le flux XML.
Type : nom logique vers le type de BusinessFlow
Expression : une expression logique qui permet de conditionner le flux. Cette expression est passée au solver attaché au BusinessFlowType.
Active : permet de désactiver la génération du flux métier.
A ceci s’ajoute des paramètres optionnels en nombre non limité :
parameter :name : le nom du paramètre, optionnel.
parameter :value : la valeur du paramètre.
Exemple de paramétrage
On retrouve le lien avec les deux classes Java et la déclaration des types de BusinessFlow :
< solver_def >
< solver_type name =" GENPEV " solverClass =" fr.generix.metier.businessflow.PevBusinessFlowImpl " type =" flow "/>
< solver_type name =" GENPPE " solverClass =" fr.generix.metier.businessflow.ParamBusinessFlowImpl " type =" flow "/>
</ solver_def >
< businessflow_def >
< businessflow_type name =" M_QTE " solverName =" GENPPE "/>
< businessflow_type name =" TYPFOU " solverName =" GENPPE "/>
< businessflow_type name =" GENPEV " solverName =" GENPEV "/>
< businessflow_type name =" GENPPE " solverName =" GENPPE "/>
</ businessflow_def >
Affectation
Un bussinessFlow peut être affecté au niveau général et/ou au niveau de chaque ViewStruct.
Au niveau général, la déclaration des BusinessFlow se fait sous le nœud properties. Un nouveau nœud <default_businessflow> permet de définir la liste des BusinessFlow valables pour l’ensemble des ViewStruct.
Au niveau des ViewStruct, la déclaration des BusinessFlow se fait sous le nœud ViewStruct. Un nouveau nœud <businessflow> permet de définir la liste des BusinessFlow valables pour cette ViewStruct.
Représentation dans XDME
Target dynamique
Concept
Globalement, il s’agit d’une nouvelle possibilité permettant dans de nombreux cas d’éviter de dupliquer des BusinessView. C’est une volonté de découplage entre la présentation et le paramétrage fonctionnel.
Exemple 1 : gestion des qui/quoi, une seule page (BusinessView + feuille style) et X cibles de paramétrage.
Exemple 2 : gestion des codes catégories dans le portail des ventes (I_VTE_F), 1 ensemble de BusinessView/Feuilles et X cibles de paramétrage
Utilisation
Exemple d’URL :
http://localhost:8888/GCE130/btoe/ServletControl?sourceview=I_CAFCAF_F&cinematic=forward(0)&frame=default&entity=1&target=VCLI&...
Dans notre cas, quelle que soit la cible de paramétrage définie dans la configuration sur la BusinessView I_CAFCAF_F, elle sera forcée à VCLI. On notera que la vérification d’habilitation se fait bien sur la cible VCLI.
Tris multiples
Concept
Il a été choisi une approche pragmatique, sans créer de nouvelle cinématique d’action. Le choix du tri final se fait en concaténant les clés publiques de tris et en les séparant par le caractère « | ».
Il n’y a pas de limite quant au nombre de tris que l’on peut proposer, si un tri n’existe pas (clé publique), il n’est pas pris en compte.
Exemple
cinematic=sort(0,-NOM|COD|TYP)
Couche de présentation
Un nouveau template centralisé sera disponible dans e-Gx.xsl afin de prendre en compte cette nouveauté sur la couche de présentation.
Resolver métier pour les paramètres de ViewLink.
Concept
Il existe à ce jour 3 types de paramètres que l’on sait passer dans les ViewLink du fichier de configuration :
· business : paramètre provenant du niveau de vue immédiatement supérieur (ou d’une vue de niveau supérieure si l’attribut viewName est utilisé)
· public : les paramètres provenant de l’URL
· value : directement la valeur du paramètre, on utilise ce type habituellement en projet une fois que le paramétrage est figé.
La ACE 1.3 propose une nouvelle façon de résoudre un paramètres qui va permettre de rendre le fichier de configuration complètement dynamique avec comme avantages principaux :
· Plus de valeur « en dur » alors qu’elles sont issues du paramétrage
· Allègement de la configuration
· Dynamisme lors de la mise en place pour les projets « in-run »
· Simplification des requêtes avec un gain de performances
· Nouvelles possibilités d’extensions vers la couche métier avec les « fournisseurs de valeurs »
Utilisation
Ce nouveau type de paramètre se nomme solved. Il est attaché à un solveur de valeur référencé par l’attribut solverName qui est un nom logique vers les déclarations de solveurs.
Différents solveurs sont disponibles pour répondre aux cas les plus courants. D’autres solveurs peuvent facilement être écrit et intégré par une déclaration dans la configuration.
Description des différents attributs :
· name : le nom « logique » du solver
· type : value ou active pour le cas qui nous préoccupe dans ce document
· solverClass : la référence à la classe Java
· value : la valeur par défaut (aucune utilisation ou exploitation pour le moment, cet attribut est réservé à un usage ultérieur)
Dans XDME, cette section est définie sous la forme d’un onglet général :
Exemple opérationnel
Voir le Guide utilisateur.
Prise en compte des périodes de validité pour le login utilisateur
Les champs DATDEB et DATFIN ont été ajouté sur la table UT_LOGIN. Ils sont dorénavant pris en compte lors de la phase de login de l’utilisateur. Les utilisateurs dont la date est échue ne sont pas pris en compte dans le calcul de licence. Cela permet donc de définir des utilisateurs temporaires.
8-D(n*V)
17-D
: un solver d’activation de la vue est paramétré
: verboseDetail vaut true sur cette vue
: API
: ViewObject utilisée en création (attribut create à true)
