Release Note socle technique GCE155

Ce document résume les nouvelles fonctionnalités disponibles sur le socle technique pour la version commerciale ACE 1.55.

Ce socle se nomme 6.1-55 en référence à la version web qui est la cible de ces développements.

1 Préambule

Cette nouvelle version présente plusieurs axes d'amélioration :

• Améliorations des performances techniques de l’application (vitesse pure et consommation mémoire)
• Apports fonctionnels du socle vers la couche de présentation pour faciliter les développements ou proposer de nouvelles manières de développer (ou nouveauté type I18N)
• Réorganisation complète de la couche de présentation pour séparer les sujets fonctionnels (et/ou développements clients) et ainsi faciliter les phases de migrations
• Un XDME refondu pour apporter encore plus de souplesse

2 Socle technique

2.1 Evolutions ACE.properties

2.1.1 Remarques importantes

La restructuration des web-modules effectuée sur la version 155 d’ACE provient notamment du besoin d’identifier les parties techniques communes à chaque application.

Il était donc naturel de voir le fichier ACE.properties évoluer en ce sens, selon deux parties :

• Une partie vraisemblablement commune à tous les web-modules d’une application déployée, la partie purement technique incluant
• la gestion des traces
• les références aux fichiers de configuration externes (log4j, pool, configurationdef)
• gestion authentification
• mapping des navigateurs
• …
• L’autre partie, qui peut différer sur un environnement, d’un web-module à l’autre :
• Définition communication XMLRPC
• Définition des alias de chemins pour la couche de présentation (nouveauté 155)
• Définition des clients web Services

Pour des raisons techniques, le fichier à été découpé en réalité en 4 parties :

• La partie principale se nommant toujours ACE.properties.xml composée de la partie commune à tous les web-modules déployés et incluant les 3 autres sous parties, nommées ci-après
• La partie dédiée à la définition des communications XMLRPC : ACE.properties.link_to_ACE.xml
• La définition des alias :

ACE.properties.alias.xml

• La définition des clients web Services :

ACE.properties.clientWebServices.xml

Le fichier ACE.properties est conservé à la racine du web-module.

Le principe de coexistence du fichier ACE_developpement.properties est également conservé, ils diffèreront tous deux, notamment au niveau de la génération des traces pour un environnement dit de développement par exemple, cependant, il est à noter que ces deux fichiers importeront les 3 mêmes fichiers (link_to_ACE, alias et clientWebServices).

2.1.2 Organisation

On voit ici les 3 nouveaux fichiers ACE.properties (alias, clientWebServices et link_to_ACE) au même niveau que le fichier principal.

Ces fichiers doivent se trouver à la racine du WebModule, ACE ne garantit pas le fonctionnement de l’application dans le cas contraire.

2.1.3 Contenu

2.1.3.1 ACE.properties.xml

Le fichier principal reste donc ACE.properties.xml (ou ACE_developpement.properties.xml) qui importe donc les 3 autres fichiers de la manière suivante :

On voit ici la définition des imports de ressources XML externes aux fichiers, avec une définition d’entité XML pour chaque fichier, exemple : link_to_ACE pour le fichier ACE.properties.link_to_ACE.xml (1ère ligne).

Chaque alias est repris dans le fichier au niveau nécessaire de l’import du XML contenu dans chaque fichier :

2.1.3.2 ACE.properties.alias.xml

2.1.3.3 ACE.properties.clientWebServices.xml

Exemple ici d’une configuration « absente » de clients Web Services, le fichier doit être vierge (pas de nœud vide !)

2.2 Mapping de cinématiques d’actions

2.2.1 Vulgarisation

L’intérêt de pouvoir gérer des mappings (correspondances) de cinématiques permet de simplifier le codage mis en œuvre au niveau de la couche de présentation côté feuilles de styles. En effet jusqu’à présent, il était nécessaire :

• d’être explicite dans la description de la valeur du paramètre d’action de cinématique (cinematic ) : ex : create(0);propose(0);assimilate();invalidate(Liste);display(0)
• De devoir parfois préciser une combinaison de plusieurs actions pour en réaliser une seule d’un point de vue fonctionnel : dans l’exemple fourni, on cherche seulement à créer un nouvel élément dans une liste.

Conséquences :

• Le code XSL/HTML sera plus lisible et plus facilement maintenable
• Le paramètre cinematic ne devient plus obligatoire au niveau du XSL (si une valeur par défaut est définie dans le fichier de configuration : soit au niveau général, soit sur la ViewStruct)
• La couche de présentation pourra choisir ses propres termes de cinématiques, indépendamment du socle
• On pourra donc définir une valeur « libre » du paramètre cinematic depuis la feuille de style, qui elle sera interprétée par le socle via une liste de mapping positionnée au niveau des ViewStruct dans le fichier de configuration pour lui fournir les correspondances de cinématiques.

Le mapping sera exploité par le socle technique via la définition des correspondances situées dans le fichier de configuration, au niveau de chaque ViewStruct (et un mapping général pour attribuer des cinématiques par défaut à l’ensemble des ViewStruct du fichier de configuration), ainsi :

• Comme nous l’avons déjà évoqué, la couche de présentation devient indépendante de ce pré requis du socle
• L’effort de maintenance des noms/combinaisons de cinématique sera centralisée et donc moindre
• Le socle pourra traiter des évolutions sans refactoring au niveau de la couche de présentation (XSL)

2.2.2 Principes de fonctionnement

2.2.2.1 Général

Il s’agit tout simplement d’exploiter un mécanisme de mapping traditionnel, à savoir une correspondance entre une valeur « logique » exploitée par la couche de présentation vers les actions de cinématiques définies.

Ex : dans une page de création, on pourra utiliser l’action « new » au niveau du XSL, cette valeur d’action sera substituée par le socle avant l’exécution des mécanismes de cinématiques, en fonction de la définition de mappings existant sur la ViewStruct de la requête, soit traditionnellement create(0);propose(0);assimilate();invalidate(Liste);display(0)

2.2.2.2 Définition d’un mapping

La définition des mappings de cinématiques se fera donc de manière interne au fichier de configuration (via XDME), à deux niveaux : global pour toutes les ViewStructs (seulement les actions n’utilisant pas des données relatives aux Views composites : ex le nom de la vue) ou au niveau de la ViewStruct.

2.2.2.2.1 Niveau général

La définition au niveau général est accessible depuis le bouton « Mappings de cinématique » dans la barre de menu d’XDME.

La grande majorité des requêtes étant traitée par l’action « forward » (pour initialiser l’affichage), on choisira de définir celle-ci comme action par défaut pour toutes les ViewStruct (voir copie d’écran).

On pourra également y définir des mappings généraux :

• new côté XSL, sera substituée par create(0);integrate(0); au niveau du socle
• del pour delete() …

2.2.2.2.2 ViewStruct

L’accès à ce panneau est situé sur la liste des ViewStruct, via un click droit, options « Mappings de cinématiques ».

Il reprend les mêmes principes de définition qu’au niveau général, mais c’est plutôt à ce niveau que l’on va bénéficier de la simplification/vulgarisation des termes de cinématiques devant être exploitées côté feuilles de styles :

• On pourra définir (en exemple) une action « générique » à utiliser côté XSL pour traiter l’affichage d’une page : dsp pour « display ».
• Et définir donc, au niveau de chaque ViewStruct la correspondance locale à ce terme « publique »
• Cela permettra encore de pouvoir modifier par exemple le tri par défaut d’une page du standard :
• Le tri par défaut est donné par un attribut de la ViewStruct, et est exécuté si aucune clé de tri publique n’est donnée à l’action « Sort »
• En surchargeant la ViewStruct, on a le choix entre modifier la valeur du tri par défaut au niveau de l’attribut ou spécifier au niveau du mapping la clé de tri souhaitée lorsque l’on demande un affichage « simple » (cas d’application également pour la demande d’un tri multiple en tri par défaut)

2.2.3 Exemple d’implémentation

2.2.3.1 Exemple sur une page liste /création

Chargement d’une page détail d’une TBL (liste des éléments et création d’un nouvelle ligne).

Appel depuis la page qui filtre les TBL :

Avant :

ACE 155 :

La cinématique n’est plus obligatoire sur l’url si on en a défini une par défaut (attribut @substitution) :

Et depuis le formulaire qui permet de créer une nouvelle ligne dans la liste du contenu de la TBL, on peut spécifier une action « logique » commune à n’importe quelle feuille de style puisque l’on spécifiera la cinématique de substitution au niveau de la VS :

• Remarque : si la feuille est commune à X BV, alors l’avantage de l’utilisation des mappings devient plus évident : plus besoin de spécifier dans le style la cinématique en fonction du contexte (nom de BV généralement) : on garde une valeur unique pour le paramètre cinematic , le mapping sera défini pour chaque VS.

2.3 Evolution du système d’authentification

Le schéma XSD d’ACE.properties a évolué vers une liste de valeur plutôt que l’activation/désactivation de l’authentification déclarative.

Pour activer le mode JAAS, auparavant (GCE140) on trouvait ceci dans ACE.properties :

< authentification >

< declarative active =" false " comment =" Utilisation du mode d'authentification via LDAP par exemple. "/>

< loginBusinessView name =" LOGIN " comment =" BusinessView utilisée pour l'authentification de l'utilisateur par couple utilisateur/mot de passe "/>

< defaultUserRecognize active =" true " comment =" Reconnaissance de l'utilisateur à la reconnexion via le cookie du poste client. "/>

< loginRetry value =" 5 " comment =" Nombre de tentative au login avant la désactivation de l'utilisateur "/>

</ authentification >

Depuis la GCE155, on déclarera de la manière suivante :

< authentication >

< mode value =" ACE "/>

< loginBusinessView name =" LOGIN " comment =" BusinessView utilisée pour l'authentification de l'utilisateur par couple utilisateur/mot de passe (uniquement concerné par l'authentification interne à ACE) "/>

< defaultUserRecognize active =" true " comment =" Reconnaissance de l'utilisateur à la reconnexion via le cookie du poste client. "/>

< loginRetry value =" 5 " comment =" Nombre de tentative au login avant la désactivation de l'utilisateur "/>

</ authentication >

2.3.1 Mod’ACE

Fonctionnement standard et habituel.

2.3.2 Mode JAAS

Fonctionnement basé sur JAAS, nécessite donc la mise en place d’un système externe en général basé sur une authentification LDAP.

2.3.3 Mode SSO

Nouveau fonctionnement : le nom de l’utilisateur doit être spécifié dans l’entête http des requêtes arrivant à notre Servlet (ServletControl). Le paramètre http est GNXUSERNAME.

Un produit tiers doit être capable d’alimenter ce paramètre bien évidemment, l’authentification est donc déléguée à un middleware.

• Si l’utilisateur demandé par le serveur d’authentification n’existe pas dans la table UT_LOGIN, une page d’exception est renvoyée à l’utilisateur (« utilisateur XXX inexistant » …).
• Si aucun utilisateur n’est passé dans le paramètre GNXUSERNAME de l’entête http, on considère que l’on se loggue à l’application en mode invité (GUEST ). Les habilitations habituelles ACE permettant (ou non) à l’utilisateur d’invoquer des fonctionnalités.
• Si l’utilisateur est existant dans la table UT_LOGIN d’ACE, on exploite les possibilités applicatives de manière habituelle.

Remarque : l’utilisateur connecté à l’application standard ACE est affiché dans la barre de titre du navigateur.

Le paramétrage du mode d’authentification étant porté par ACE.properties, il est global au fonctionnement du WebModule. Il n’est donc pas possible de se connecter en mode SSO et en mode « standard ACE » sur le même WebModule.

2.4 Mécanisme d’audit des pools.

2.4.1 Définition

On appel nouveau pool le mécanisme disponible depuis la 155, qui est activé via le ACE.properties.xml :

< pool active =" true ">

< file name =" configuration/pool.xml "/>

</ pool >

La configuration de ces pools est externalisée dans un fichier nommé ici pool.xml

2.4.2 Principe

Les pools sont capables de générer un rapport d’activité via LOG4J.

Cet outil n’est disponible que pour « les nouveaux pools ».

Ce rapport permet de connaitre l’activité de chaque pool et d’en déduire un paramétrage optimal pour UN scénario donné .

XDME devra prochainement intégrer ce rapport pour paramétrer de façon automatique les pools.

2.4.3 Configuration

Dans ACE.properties.xml : une propriété système active le mécanisme :

< systemProperties >

< property name =" auditPool " value =" true "/ >

</ systemProperties >

Dans le fichier de log4j utilisé, ajouter le couple logger et appender suivants :

< appender name =" AuditPoolAppender " class =" org.apache.log4j.RollingFileAppender ">

< param name =" File " value =" log/AuditPoolAppender.log "/>

< param name =" MaxFileSize " value =" 5MB "/>

< param name =" MaxBackupIndex " value =" 10 "/>

< layout class =" org.apache.log4j.PatternLayout ">

< param name =" ConversionPattern " value =" %m%n "/>

</ layout >

</ appender >

< logger name =" auditPool " additivity =" false ">

< level value =" info "/>

< appender-ref ref =" AuditPoolAppender "/>

</ logger >

2.4.4 Contenu du rapport

Ce paramétrage va générer un rapport nommé AuditPoolAppender.log qui contient des informations liées à chaque pool. Les informations disponibles sont basées sur les données suivantes :

• Nombre d’accès avec création.
• Nombre d’accès avec récupération de la donnée dans le pool.
• Nombre de destruction liée à l’obsolescence de la donnée stockée
• Nombre de destruction liée à un trop grand nombre de données dans le pool.
• Nombre de destruction lors de la destruction du pool, donc en fin de session.
• Liste des intervalles de temps entre deux appels au pool.
• Remarque : ce tableau est limité à 10 000 valeurs maximum. En cas de dépassement, l’indicateur (limitExceeded) est ajouté au log.
• Temps cumulé de la création pure de l’objet. (n’inclus pas le temps de lecture en base pour les RowSet par exemple)

Des valeurs sont calculées à partir de ces données :

Le séparateur entre les colonnes est le caractère $.

2.4.4.1 Composition du nom

Le nom du pool dépend de son type et des données.

Il est basé sur : le nom du pool + $ + identifiant.

L’identifiant dépend du pool :

• Pour un pool d’ApplicationModule

Le nom est du type : className.+ $ + adresse de la factory.

Exemple : mailto:fr.generix.technicalframework.businesscomponent.applicationmodule.LicenceManager$fr.generix.technicalframework.business.applicationmodule.GnxNestedApplicationModuleFactory@1ee3df">fr.ACE.technicalframework.businesscomponent.applicationmodule.LicenceManager$fr.ACE.technicalframework.business.applicationmodule.GnxNestedApplicationModuleFactory@1ee3df

• Pour un pool de ViewObject

Deux cas : si le pool de ViewObject est créé suite à la demande d’une View dans une ViewStruct :

Le nom est du type : nom ACE + $ + BV + $ + View + clé de retrieve publique

Exemple :

Dynamic$I_SEG_R$TypeSegment$DEF

Ces données permettent de retrouver le type de View et sa clé associée, afin de positionner les attributs poolable.

Si le pool de ViewObject est créé suite à la demande d’une API, le nom est du type :

Nom ACE + $ + nom de la classe mère de l’API.

Exemple :

Dynamic$GnxBusinessBufferedApplicationModuleImpl.java

Peut importe le nom de la classe. Cela permet de sa voir que cette ViewObject est demandée par une API

• Pour un pool de RowSet

On y retrouve les deux cas comme pour les ViewObject.

Si le pool est issu d’une demande d’une View dans une ViewStruct, le nom est du type

Instance de la Vo #nom ACE de la VO#clause where#clause orderby#$ + BV + $ + View + clé de retrieve publique

Exemple :

fr.generix.metier.bc4j.table.JRzoViewImpl@138f11c#JRzoView#MevTbl.Codsoc = ? AND lib2 = ? AND cletbl = ? AND num3 IN (1, 2, 4)#$I_SEG_R$Libelle$DEF

Si le pool est issu d’une demande d’une API, le nom est du type :

Instance de la Vo #nom ACE de la VO#clause where#$nom de la classe mère de l’API.

Exemple :

fr.generix.metier.bc4j.table.JRzoViewImpl@1b910b0#JRzoView#MevTbl.CODSOC = ? AND CODTBL = ? AND CLETBL = ?#null$GnxBusinessBufferedApplicationModuleImpl.java

2.5 Taille des flux de présentation

Il est possible de connaitre la taille des flux XML et de rendu final sans nécessairement générer sur le disque les flux en question.

L’activation se fait en 2 temps :

• Autoriser le socle à générer ces résultats.
• Récupérer ces résultats.

2.5.1 Activation

Cette autorisation se fait par l’intermédiaire d’ACE.properties.xml, section server/log/contents.

< log >

< contents >

< xmlPresentationSize active =" true "/>

< xmlPresentationNbNode active =" true "/>

< htmlPresentationSize active =" true "/>

</ contents >

</ log >

2.5.2 Récupérer ces résultats.

Le résultat est disponible via log4J. Il faut pour cela définir un Logger spécifique nommé renderSize. Ce logger utilisera un appender au choix.

Trois nouvelles valeurs provenant du MDC contiennent les données en question :

Exemple

< logger name =" renderSize " additivity =" false ">

< level value =" info "/>

< appender-ref ref =" TestAppender "/>

</ logger >

2.6 Tracer les locks BDD

Les traces sur les requêtes SQL de type select contiennent maintenant les locks « for update » posés par les BC4J en vue de mise à jour. Il est possible de modifier le formatage des lignes lues par un layout spécifique disponible dans ACE.properties.xml.

Le nom du layout est « lock »

Exemple de paramétrage :

< traceData active =" true ">

< layout value =" [%d]¤%5X{ELAPSE_TIME}¤%m%n " name =" lock "/>

</ traceData >

Remarque : la valeur par défaut pour ce layout est : [%d]¤%5X{ELAPSE_TIME}¤%m%n"

La visualisation des locks se fait sur 3 lignes de log.

Exemple de log :

[2009-10-21 14:59:49,863]¤ -¤[20125] (11) OracleSQLBuilder Executing Select on: PRO (true)

[2009-10-21 14:59:49,864]¤ -¤[20126] (1) Built select: 'SELECT CODPRO, (*)… FROM PRO JPro'

[2009-10-21 14:59:49,864]¤ -¤[20127] (0) Executing LOCK...SELECT CODPRO, (*)… FROM PRO JPro WHERE CODPRO=? AND CODSOC=? FOR UPDATE WAIT 10

(*) Les lignes sont volontairement tronquées ici pour simplifier l’affichage.

2.7 Nettoyage automatique des contextes périmés.

Afin de limiter la consommation mémoire, un mécanisme de destruction automatique des contextes est disponible à partir de la version155.

2.7.1 Principe

A chaque frame / appel Ajax correspond un contexte applicatif. Chaque contexte contient une BusinessView, dite BusinessView courante dans ce contexte. Ce qui permet de conserver le résultat des actions précédemment faite sur cette BusinessView. Par exemple page suivante sur le résultat d’une recherche.

La conservation de ces BusinessView est consommateur en mémoire car l’intégralité de la BusinessView est conservée en mémoire, y compris les résultats des lectures en base. Afin de diminuer cette consommation, la version155 ajoute la notion de nettoyeur de contexte.

Chaque BusinessView a une durée de vie sans activité fixée par configuration. La valeur par défaut est de 600 secondes.

A intervalle régulier, un nettoyeur va détruire les BusinessView qui ont dépassé ce délai, à condition que la BusinessView puisse être recréée pour que cela reste transparent pour l’utilisateur. Cette condition dépend des cinématiques exécutées avant que la BusinessView soit périmée.

2.7.2 Configuration

La configuration se répartie entre le fichier de configuration des BusinessView et le fichier de configuration des propriétés ACE.

2.7.2.1 Propriété BusinessView

Vue graphique

Pour chaque BusinessView, l’attribut idleTime (en seconde) permet de paramétrer la durée de vie sans sollicitation de la BusinessView.

Une valeur par défaut est disponible sur businessview_def.

Exemple de configuration

< businessview_def defaultRenderType =" xsl " executeQuery =" newBusinessView " idleTime =" 500 ">

< businessview name =" EDI " forwardOnly =" true " target =" UEDI " viewstruct =” EDI " idleTime =" 300 ">

< xsl fileRef =" {ROOT}/a_edition.xsl " lang =" UNK " support =" UNK "/>

</ businessview >

Dans cet exemple la durée d’inactivité autorisée est de 500 secondes, avec une valeur spécifique de 300 secondes pour la BusinessView EDI.

2.7.2.2 Propriété ACE.properties

Exemple de configuration

< context >

< cleaner active =" false " idleTime =" 100 "/>

</ context >

Dans cet exemple, le cleaner de Contexte passera toute les 100 secs, ceci à partir du moment ou le cleaner sera actif – bien entendu.

2.8 Nettoyage des caches des données métier

Il est possible de nettoyer (clear) une ou des collections de données métiers conservées dans des RowSet, même si ces RowSet sont contenus dans les Pools d’objets métier.

Deux possibilités pour piloter ces nettoyages :

• Systématique à la fin de chaque requête http
• A la demande.

2.8.1 Nettoyage systématique

Ce mode se paramètre via la configuration ACE.properties.xml.

Modélisation :

Une nouvelle section transaction fait son apparition :

• Exemple de code :

< transaction >

< clearCacheOnCommit active =" false "/>

< clearCacheOnRollback active =" true "/>

</ transaction >

clearCacheOnCommit : provoque, ou non, le nettoyage de l’ensemble des caches BC4J lors du commit. La valeur par défaut est false.

Remarque : Passer cette valeur à true va provoquer le nettoyage systématique des caches BC4J et par conséquent une dégradation des performances.

clearCacheOnRollback : provoque, ou non, le nettoyage de l’ensemble des caches BC4J lors du rollback. La valeur par défaut est true.

Remarque : Passer cette valeur à false ne va plus provoquer le nettoyage systématique des caches BC4J et par conséquent conserver des valeurs potentiellement erronées.

Il n’est pas conseillé de modifier les valeurs par défaut, ACE ne pourrait pas garantir le bon fonctionnement de l’application.

2.8.2 Nettoyage à la demande

Ce nettoyage se fait via de nouvelles actions du socle.

Déclaration des actions dans le fichier de configuration :

< action name =" clearViewObjectCache " class =" fr.ACE.technicalframework.application.action.ClearCache ">

< optional >

< param name =" viewObject " maxOccurs =" unbounded " type =" String "/>

</ optional >

</ action >

< action name =" clearCacheOnCommit " class =" fr.ACE.technicalframework.application.action.ClearCache ">

< required >

< param name =" clearCacheType " type =" Value " maxOccurs =" 1 " value =" onCommit "/>

</ required >

</ action >

< action name =" clearCacheOnRollback " class =" fr.ACE.technicalframework.application.action.ClearCache ">

< required >

< param name =" clearCacheType " type =" Value " maxOccurs =" 1 " value =" onRollback "/>

</ required >

</ action >

Remarque : Pour exécuter ces actions, l’utilisateur doit être habilité à la suppression.

La portée de ces actions est la requête en cours. La requête suivante ne tient plus compte de la demande, même si cette dernière n’a pas aboutie.

2.8.2.1 clearCacheOnCommit

Cette action provoque un nettoyage (vidage) de l’ensemble des caches de ViewObject lors de l’exécution du commit, si ce dernier à lieu. Quelque soit la position de cette action dans la chaine de cinématique, le nettoyage sera effectué lors du commit, à la fin de l’exécution de la requête.

Paramètre : cette action ne demande pas de paramètre.

Exemple de cinématique :

?cinematic=clearCacheOnCommit()&forward(0)

Remarque : Par défaut, il n’y a pas de nettoyage lors du commit.

Cette action provoque un nettoyage (purge) de l’ensemble des caches de ViewObject lors de l’exécution du rollback, si ce dernier à lieu. Quelque soit la position de cette action dans la chaine de cinématique, le nettoyage sera effectué lors du commit, à la fin de l’exécution de la requête.

Paramètre : cette action ne demande pas de paramètre

Exemple de cinématique :

?cinematic=clearCacheOnRollback()&forward(0)

Remarque : Par défaut, il y a nettoyage lors du rollback.

Cette action permet de purger immédiatement un, plusieurs ou tous les caches de ViewObject, quelque soit l’issue de la requête.

La purge est exécutée au même moment que l’action, donc sa place dans la chaine de cinématique n’est pas anodine.

Paramètre : cette action contient un paramètre optionnel du type multi-valeurs.

Paramètre non renseigné : purge de tous les caches

Paramètre renseigné : purge du ou des caches précisé.

Exemples de cinématique :

?cinematic=clearViewObjectCache()

?cinematic=clearViewObjectCache(maViewObject)

?cinematic=clearViewObjectCache(maViewObject1|maViewObject2)

Remarque : Le nom de la ViewObject est le nom complet, package compris.

2.8.2.4 Traces log4J associés

Lors de la purge, les BC4J laissent une trace du type :

2009-02-11 16:07:30,102¤[9844] (6656) Clearing VO cache for UtUuidView_18

2009-02-11 16:07:30,102¤[9845] (0) Clear QueryCollection in cache for VO UtUuidView_18

2009-02-11 16:07:30,102¤[9846] (0) Clearing VO cache for UtUuidView_38

2009-02-11 16:07:30,102¤[9847] (0) Clear QueryCollection in cache for VO UtUuidView_38

2.9 ViewLink sur assimilate pour API

2.9.1 Principe

Il est maintenant possible de définir un ViewLink de type assimilate afin de passer à une API des paramètres de type autre que « public » via les « fields ».

2.9.2 Configuration

Vue graphique :

Exemple de configuration :

< view name =" Tiers " nbline =" 1 " type =" VueTiers ">

< view_link >

< retrieve publicKey =" DEF " viewKey =" ONE ">

< param domain =" business " field =" Codsoc "/>

< param domain =" solved " field =" PEV:TYPTIE " solverName =" SOLVER "/>

< param domain =" public " field =" Sigtie20 "/>

</ retrieve >

</ view_link >

< view name =" CreerAdresse " nbline =" 1 " type =" VueCreerAdresse ">

< view_link >

< assimilate >

< param name =" tiers.typtie " domain =" business " field =" Typtie "/>

< param name =" tiers.sigtie " domain =" business " field =" Sigtie "/>

</ assimilate >

</ view_link >

< field >

< attribute name =" infoAdresse.typadr " public =" Typadr20 "/>

</ field >

La recherche d’une valeur pour alimenter le DocumentRow de l’api se fait dans l’ordre suivant :

• Recherche sur le ViewLink assimilate
• Si pas trouvé, recherche sur les fields .

Remarque :

• Comme pour toute saisie, il faut au moins un field de déclaré.
• La visibilité prise en compte est celle des fields . Si on place visible=false sur le nœud field , aucun champ de sortie de l’API ne sera visible dans le flux.

Dans le cas présent la cinématique à déclencher est la cinématique habituelle pour les services d’ApplicationModule (API pour la couche de présentation) : propose();assimilate()

2.10 Field multi-ligne

2.10.1 Principe

Afin d’éviter les longue liste répétitive d’attributs quasi identique. Il est dorénavant possible de déclarer les fields en notation récursive.

Cette notation est disponible aussi bien au niveau des déclarations des types de View que pour les View dans les ViewStruct.

Vue graphique :

On voit qu’un attribute peut contenir un ou plusieurs attribute.

Le nœud attribute contient un nouvel attribut : maxoccurs qui indique le nombre maximal d’occurrence pour ce niveau.

Remarque : il est possible de mettre la valeur unbounded. Cette valeur n’est à utiliser que si on ne connait pas le nombre maximal d’occurrence possible car les attributs seront crées à la volés, lors de leur réception via la requête ce qui est plus couteux et moins cadré car la view peut potentiellement recevoir plus d’occurrences qu’il ne le faudrait.

Il convient de noter que dans la nouvelle formalisation autorisée par le socle technique, l’indice généré commence à la valeur « 0 » et pas « 1 ».

2.10.2 Notation

L’écriture doit respecter une notation précise, aussi bien sur le nom des attributs que sur le nom public.

Sur le nom interne de l’attribut, l’indice est ajouté automatiquement en fin de chaque niveau intermédiaire.

Sur le nom public, chaque niveau est signalé par un « @ ». Les niveaux sont séparés les uns des autres par des « _ ». Il y a autant de «_@ » que de niveaux intermédiaires.

Les indices générés automatiquement commencent à 0.

2.10.3 Exemples

2.10.3.1 Exemple 1

Cette notation ci dessous

< attribute name =" selection " maxoccurs =" 2 ">

< attribute name =" valeur " maxoccurs =" 3 ">

< attribute name =" premier " public =" Premier_@_@ "/>

< attribute name =" dernier " public =" Dernier_@_@ "/>

</ attribute >

</ attribute >

Est équivalente à la notation :

< attribute name =" selection0.valeur0.premier " public =" Premier_0_0 "/>

< attribute name =" selection0.valeur0.dernier " public =" Dernier_0_0 "/>

< attribute name =" selection0.valeur1.premier " public =" Premier_0_1 "/>

< attribute name =" selection0.valeur1.dernier " public =" Dernier_0_1 "/>

< attribute name =" selection0.valeur2.premier " public =" Premier_0_2 "/>

< attribute name =" selection0.valeur2.dernier " public =" Dernier_0_2 "/>

< attribute name =" selection1.valeur0.premier " public =" Premier_1_0 "/>

< attribute name =" selection1.valeur0.dernier " public =" Dernier_1_0 "/>

< attribute name =" selection1.valeur1.premier " public =" Premier_1_1 "/>

< attribute name =" selection1.valeur1.dernier " public =" Dernier_1_1 "/>

< attribute name =" selection1.valeur2.premier " public =" Premier_1_2 "/>

< attribute name =" selection1.valeur2.dernier " public =" Dernier_1_2 "/>

2.10.3.2 Exemple 2 :

Dans l’application, on trouve ceci :

Ancienne écriture :

< attribute name =" optionEdition0.nom " public =" Nom_1 "/>

< attribute name =" optionEdition0.valeur " public =" Valeur_1 "/>

< attribute name =" optionEdition0.mode " public =" Mode_1 "/>

< attribute name =" optionEdition0.numero " public =" Numopt_1 "/>

< attribute name =" optionEdition1.nom " public =" Nom_2 "/>

< attribute name =" optionEdition1.valeur " public =" Valeur_2 "/>

< attribute name =" optionEdition1.mode " public =" Mode_2 "/>

< attribute name =" optionEdition1.numero " public =" Numopt_2 "/>

< attribute name =" optionEdition2.nom " public =" Nom_3 "/>

< attribute name =" optionEdition2.valeur " public =" Valeur_3 "/>

< attribute name =" optionEdition2.mode " public =" Mode_3 "/>

< attribute name =" optionEdition2.numero " public =" Numopt_3 "/>

< attribute name =" optionEdition3.nom " public =" Nom_4 "/>

< attribute name =" optionEdition3.valeur " public =" Valeur_4 "/>

< attribute name =" optionEdition3.mode " public =" Mode_4 "/>

< attribute name =" optionEdition3.numero " public =" Numopt_4 "/>

On peut l’écrire maintenant comme ceci :

Nouvelle écriture :

< attribute name =" optionEdition " maxoccurs =" 4 ">

< attribute name =" nom " public =" Nom_@ "/>

< attribute name =" valeur " public =" Valeur_@ "/>

< attribute name =" mode " public =" Mode_@ "/>

< attribute name =" numero " public =" Numopt_@ "/>

</ attribute >

A la différence que l’indice généré commencera à 0 et non à 1.

2.10.3.3 Exemple 3 :

Ancienne écriture :

< attribute name =" selection0.nomChamp " public =" Nomchp_0 "/>

< attribute name =" selection0.typeChamp " public =" Typchp_0 "/>

< attribute name =" selection0.critereSelection0.egale " public =" Egale_0 "/>

< attribute name =" selection0.critereSelection0.debut " public =" Debut_0 "/>

< attribute name =" selection0.critereSelection0.fin " public =" Fin_0 "/>

< attribute name =" selection0.critereSelection0.like " public =" Like_0 "/>

< attribute name =" selection0.lisVal " public =" LisVal_0 "/>

< attribute name =" selection0.ordreTri " public =" OrdreTri_0 "/>

< attribute name =" selection0.sensTri " public =" SensTri_0 "/>

…

< attribute name =" selection40.nomChamp " public =" Nomchp_40 "/>

< attribute name =" selection40.typeChamp " public =" Typchp_40 "/>

< attribute name =" selection40.critereSelection0.egale " public =" Egale_40 "/>

< attribute name =" selection40.critereSelection0.debut " public =" Debut_40 "/>

< attribute name =" selection40.critereSelection0.fin " public =" Fin_40 "/>

< attribute name =" selection40.critereSelection0.like " public =" Like_40 "/>

< attribute name =" selection40.lisVal " public =" LisVal_40 "/>

< attribute name =" selection40.ordreTri " public =" OrdreTri_40 "/>

< attribute name =" selection40.critereSelection0.sensTri " public =" SensTri_40 "/>

Nouvelle écriture :

< attribute name =" selection " maxoccurs =" 41 ">

< attribute name =" nomChamp " public =" Nomchp_@ "/>

< attribute name =" typeChamp " public =" Typchp_@ "/>

< attribute name =" critereSelection " maxoccurs =" 1 ">

< attribute name =" egale " public =" Egale_@_@ "/>

< attribute name =" debut " public =" Debut_@_@ "/>

< attribute name =" fin " public =" Fin_@_@ "/>

< attribute name =" like " public =" Like_@_@ "/>

</ attribute >

< attribute name =" lisVal " public =" LisVal_@ "/>

< attribute name =" ordreTri " public =" OrdreTri_@ "/>

< attribute name =" sensTri " public =" SensTri_@ "/>

</ attribute >

La différence se situe au niveau du nom public. Il faut tenir compte des différents niveaux.

Pour l’occurrence 10, L’attribut de nom public Egale sera :

< attribute name =" selection10.critereSelection0.egale " public =" Egale_0_10 "/>

Il prend en compte le niveau intermédiaire critereSelection, même si son occurrence n’est que de 1.

2.10.4 Particularité : collision entre les déclarations

Il est possible de déclarer des attributs récursifs au niveau view_type et view. S’i y a collision sur les niveaux intermédiaires, c’est le niveau déclaré sur la View dans la ViewStruct qui est pris en compte.

Exemple :

Déclaration sur la view_type

< attribute name =" selection " maxoccurs =" 2 ">

< attribute name =" valeur " maxoccurs ="3">

< attribute name =" premier "/>

< attribute name =" dernier "/>

</ attribute >

</ attribute >

Déclaration sur la View dans la ViewStruct :

< attribute name =" selection " maxoccurs =" 2 ">

< attribute name =" valeur " maxoccurs ="1">

< attribute name =" second " public =" Second_@_@ "/>

</ attribute >

</ attribute >

Le nombre d’occurrence pris en compte sont celle de la View dans la ViewStruct

Les attributs pris en compte sont l’ensemble des attributs

La fusion des deux déclarations donnera :

< attribute name =" selection " maxoccurs =" 2 ">

< attribute name =" valeur " maxoccurs ="1">

< attribute name =" premier "/>

< attribute name =" dernier "/>

< attribute name =" second " public =" Second_@_@ "/>

</ attribute >

</ attribute >

Il y a bien fusion des attributs, mais les occurrences prioritaires sont celles de la View dans la ViewStruct.

2.11 Client WebService

2.11.1 Objectifs

Le but de ce GMO est de guider à la mise en place d’appel Web Services externe à ACE.

Nous verrons :

• la configuration
• l’utilisation

2.11.2 Configuration

La localisation physique d’un Web Service est externalisée dans le fichier de paramétrage technique (ACE.properties) ;

Ici s’effectue l’association entre le nom logique ACE d’un Web Service externe (utilisé dans le fichier de configuration comme clientWebService) et la localisation de son WSDL (donnant la signature du web service) :

Exemple :

< clientWebServices >

< clientWebService name =" GCEService " wsdlURL =" http://localhost:8888/GCE140/services/gCEService?WSDL "/>

< clientWebService name =" GenkiXChanel " wsdlURL =" http://s-fr-re-xc-01:8080/xchanneldelegate.business/XChannelWSBridge?wsdl "/>

</ clientWebServices >

Remarque : Etant une URL, tous les modes d’accès connus sont possibles : http://, ftp://, file://, …

Les « clientWebService » sont déclarés dans la configuration de la façon suivante :

config/business/webservice/client_def/client

La définition d’un clientWebService depuis le WSDL est :

client.name = <Nom logique ACE>

avec lien entre le <Nom logique ACE> et l’adresse physique vers le WSDL défini dans le fichier ACE.properties.xml : /config/application/clientWebServices/clientWebService/@name

client.targetNameSpace = WSDL( /definitions/@targetNamespace)

client.serviceName = WSDL (/definitions/service/@name)

client.servicePortName = WSDL (/definitions/service/port/@name)

Pour chaque opération (client/operation_def/operation) à invoquer :

operation.name = WSDL (/definitions/portType/operation/@name )

operation.publicName = <Nom logique ACE : webServiceMethod>

operation.paramValue = <flux XML d’entrée attendu par l’opération>

Remarque : La norme W3C d’un WSDL prévoit la possibilité d’avoir plusieurs nœuds <service> ; cependant les implémentations actuelles n’en prenne qu’un en compte.

Exemple :

< webservice >

< client_def >

< client name =" GenkiXChanel " serviceName =" Xchanneldelegate_ws " servicePortName =" XChannelBridgeWSBusinessInterfRemoteEndpointPort " targetNameSpace =" urn:com.influe.ii.xchanneldelegate ">

< operation_def >

< operation name =" getListContact " publicName =" XChanelContacts " paramValue =" &lt;soapenv:Envelope xmlns:soapenv=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:tem=&quot;http://tempuri.org/&quot; xmlns:gen=&quot;http://schemas.datacontract.org/2004/07/ACE.CrossChannel.Contracts.Dto&quot;>&lt;soapenv:Header/>&lt;soapenv:Body>&lt;getListContact>&lt;tem:GetListContact>&lt;!--Optional:-->\[&lt;tem:idPoc>?&lt;/tem:idPoc>\]&lt;!--Optional:-->\[&lt;tem:listCrit>&lt;!--Zero or more repetitions:-->&lt;gen:ListCriteria>&lt;!--Optional:-->\[&lt;gen:CodeCriteria>?&lt;/gen:CodeCriteria>\]&lt;!--Optional:-->\[&lt;gen:CodeIdCriteria>?&lt;/gen:CodeIdCriteria>\]&lt;!--Optional:-->\[&lt;gen:CodeOperator>?&lt;/gen:CodeOperator>\]&lt;!--Optional:-->\[&lt;gen:Value>?&lt;/gen:Value>\]&lt;/gen:ListCriteria>&lt;/tem:listCrit>\]&lt;!--Optional:-->\[&lt;tem:idSearchType>?&lt;/tem:idSearchType>\]&lt;/tem:GetListContact>&lt;/getListContact>&lt;/soapenv:Body>&lt;/soapenv:Envelope> "/>

</ operation_def >

</ client >

</ client_def >

</ webservice >

Remarque : La valeur de l’attribut paramValue suit une notation quasi -équivalente aux requêtes SQL : \[ \] pour les champs optionnels ; @ pour la substitution de valeur.

Ci-dessous le même exemple via SoapUI (http://www.soapui.org) :

Ci-dessous le même exemple via XDME :

2.11.3 Utilisation

Il convient d’utiliser le document : RDI_WS

(fr.ACE.technicalframework.application.document.ClientWebServiceDocumentImpl )

Exemple :

< document_def >

< document name =" DocWsGenkiXChanel " classAlias =" RDI_WS " clientwebservice =" GenkiXChanel "/>

< document_def >

2.11.3.2 View/ViewStruct

Dans le même esprit que pour les VO Standard, les VO Dynamique, les blocs PL/SQL, le nouveau type de clause retrieve « webservice » permet de faire le lien avec la méthode du webservice.

Il convient d’utiliser le resolver : WS_CLAUSE

(fr.ACE.technicalframework.application.resolver.DefaultClientWebServiceResolver)

Remarque : L’équivalent de NullClause sur les VO Standard est la méthode <vide> ("") pour éviter l’activation du webservice.

Exemple :

< view_type name =" VueWsGenkiXChanel " document =" DocWsGenkiXChanel ">

< retrieve >

< client_ws key =" NUL " solverName =" WS_CLAUSE " webServiceMethod =""/>

< client_ws key =" LIST " solverName =" WS_CLAUSE " webServiceMethod =" XChanelContacts "/>

</ retrieve >

</ view_type >

Et un exemple d’utilisation dans une ViewStruct + View Link (usage habituel)

< viewstruct … >

…

< view name =" ListContact " nbline =" 1 " type =" VueWsGenkiXChanel ">

< view_link >

< retrieve publicKey =" ONE " viewKey =" NUL "/>

< retrieve publicKey =" DEF " viewKey =" LIST ">

< param domain =" business " field =" idPoc "/>

< param domain =" business " field =" CodeCriteria "/>

< param domain =" business " field =" CodeCriteria "/>

< param domain =" business " field =" CodeOperator "/>

< param domain =" business " field =" Value "/>

< param domain =" business " field =" IdSearchType "/>

</ retrieve >

</ view_link >

< field />

</ view >

…

</ viewstruct >

Cet exemple dans XDME :

2.11.4 Exemples de traces générées

[2009-06-24 11:52:37,531] DEBUG (fr.ACE.technicalframework.business.webservice.client.GnxClientWebServiceImpl) - invoke() : Invocation de l'opération 'calculaRetencoes' du ClientWebService 'mastersaf'

[2009-06-24 11:52:37,531] DEBUG (fr.ACE.technicalframework.business.webservice.client.GnxClientWebServiceImpl) - <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><ns1:calculaRetencoes soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://www.mcfox.com.br"><in0 href="#id0"/></ns1:calculaRetencoes><multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:DocFiscal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="http://www.mcfox.com.br"><cancelado xsi:type="soapenc:string" xsi:nil="true"/><cdTipo xsi:type="soapenc:string">E</cdTipo><descIR10 xsi:type="soapenc:string" xsi:nil="true"/><destinatario href="#id1"/><docFiscalTeste href="#id2"/><dtES

...

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:decimal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">300</multiRef><multiRef id="id8" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:decimal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">900001</multiRef></soapenv:Body></soapenv:Envelope>

[2009-06-24 11:52:37,531] DEBUG (fr.ACE.technicalframework.business.webservice.client.GnxClientWebServiceImpl) - getOperationName() : webServiceMethod : calculaRetencoes => operation : calculaRetencoes

[2009-06-24 11:52:45,720] DEBUG (fr.ACE.technicalframework.business.webservice.client.GnxClientWebServiceImpl) - <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><ns1:calculaRetencoesResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://www.mcfox.com.br"><calculaRetencoesReturn href="#id0"/></ns1:calculaRetencoesResponse><multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:DocFiscal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="http://www.mcfox.com.br"><cancelado xsi:type="xsd:string">N</cancelado><cdTipo xsi:type="xsd:string">E</cdTipo><descIR10 xsi:type="xsd:string" xsi:nil="true"/><destinatario href="#id1"/><docFiscalTeste xsi:type="xsd:boolean">true</docFiscalTeste><dtES xsi:type="xsd:dateTime">2009-05-27T22:00:00.000Z</dtES><dtEmissao xsi:type="xsd:dateTime">2009-05-27T22:00:00.000Z</dtEmissao><dtPagto xsi:type="xsd:dateTime">2009-05-27T22:00:00.000Z</dtPagto><emitente href="#id2"/><geraLog xsi:type="xsd:string">S</geraLog><idDocFiscal xsi:type="xsd:decimal">1</idDocFiscal><itensDocFiscal soapenc:arrayType="ns2:ItemDocFiscal[1]" xsi:type="soapenc:Array"><itensDocFiscal href="#id3"/></itensDocFiscal><log xsi:type="xsd:string">C&#xE1;lculo iniciado em:24/06/2009 11:52:45:511

Inicio:IPI.

Item:900001

Fim:IPI.

Inicio:ICMS.

Item:900001

Imposto do item 900001 = Valor Tribut&#xE1;vel(300.00) * Al&#xED;quota(18%) = 54.00

Fim:ICMS.

Inicio:COFINS.

Item:900001

Imposto do item 900001 = Valor Tribut&#xE1;vel(300.00) * Al&#xED;quota(7.6%) = 22.80

Fim:COFINS.

Inicio:PIS.

Item:900001

Imposto do item 900001 = Valor Tribut&#xE1;vel(300.00) * Al&#xED;quota(1.65%) = 4.95

Fim:PIS.

</log><mensagens xsi:type="soapenc:Array" xsi:nil="true"/><modelo xsi:type="xsd:decimal" xsi:nil="true"/><naturezaOperacao xsi:type="xsd:string" xsi:nil="true"/><numero xsi:type="xsd:decimal">200</numero><qtPesoBruto xsi:type="xsd:decimal" xsi:nil="true"/><qtPesoLiquido

...

xsi:type="xsd:decimal">0</vlOutros><vlPercentualMVA xsi:type="xsd:decimal" xsi:nil="true"/><vlPrecoControlado xsi:type="xsd:decimal" xsi:nil="true"/><vlReducaoIR xsi:type="xsd:decimal" xsi:nil="true"/><vlTributavel xsi:type="xsd:decimal">300.00</vlTributavel></multiRef></soapenv:Body></soapenv:Envelope>

2.11.4.2 ClientWebService.log

[2009-06-24 11:52:37,533] axis.AxisEngine DEBUG (HTTPThreadGroup-4) - Enter: AxisEngine::init

…

[2009-06-24 11:52:45,167] description.OperationDesc DEBUG (HTTPThreadGroup-4) - @9b9b81 added parameter >name: docFiscal

typeEntry: null

mode: IN

position: 0

isReturn: false

typeQName: {http://www.mcfox.com.br}DocFiscal

javaType: null

inHeader: false

outHeader: false

@1fe358a<total parameters:1

[2009-06-24 11:52:45,167] i18n.ProjectResourceBundle DEBUG (HTTPThreadGroup-4) - org.apache.axis.i18n.resource::handleGetObject(clientNoTypemapping)

…

[2009-06-24 11:52:45,350] message.SAXOutputter DEBUG (HTTPThreadGroup-4) - SAXOutputter.endDocument

[2009-06-24 11:52:45,350] client.Call DEBUG (HTTPThreadGroup-4) - <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><ns1:calculaRetencoes soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://www.mcfox.com.br"><in0 href="#id0"/></ns1:calculaRetencoes><multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:DocFiscal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="http://www.mcfox.com.br"><cancelado xsi:type="soapenc:string" xsi:nil="true"/><cdTipo xsi:type="soapenc:string">E</cdTipo><descIR10 xsi:type="soapenc:string" xsi:nil="true"/><destinatario href="#id1"/><docFiscalTeste href="#id2"/><dtES xsi:type="xsd:dateTime">2009-05-27T22:00:00.000Z</dtES><dtEmissao xsi:type="xsd:dateTime">2009-05-

…

xsi:nil="true"/><genero xsi:type="soapenc:decimal" xsi:nil="true"/></multiRef><multiRef id="id12" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:decimal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">300</multiRef><multiRef id="id8" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:decimal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">900001</multiRef></soapenv:Body></soapenv:Envelope>

[2009-06-24 11:52:45,350] client.AxisClient DEBUG (HTTPThreadGroup-4) - Enter: AxisClient::invoke

…

[2009-06-24 11:52:45,399] http.HTTPSender DEBUG (HTTPThreadGroup-4) - XML sent:

[2009-06-24 11:52:45,399] http.HTTPSender DEBUG (HTTPThreadGroup-4) - ---------------------------------------------------

[2009-06-24 11:52:45,399] axis.SOAPPart DEBUG (HTTPThreadGroup-4) - Enter: SOAPPart::saveChanges

[2009-06-24 11:52:45,400] http.HTTPSender DEBUG (HTTPThreadGroup-4) - POST /taxrt/services/TaxRules HTTP/1.0

Content-Type: text/xml; charset=utf-8

Accept: application/soap+xml, application/dime, multipart/related, text/*

User-Agent: Axis/1.4

Host: s-fr-li-bra-01:8080

Cache-Control: no-cache

Pragma: no-cache

SOAPAction: ""

Content-Length: 11031

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><ns1:calculaRetencoes soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://www.mcfox.com.br"><in0 href="#id0"/></ns1:calculaRetencoes><multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:DocFiscal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="http://www.mcfox.com.br"><cancelado xsi:type="soapenc:string" xsi:nil="true"/><cdTipo xsi:type="soapenc:string">E</cdTipo><descIR10

…

xsi:nil="true"/><genero xsi:type="soapenc:decimal" xsi:nil="true"/></multiRef><multiRef id="id12" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:decimal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">300</multiRef><multiRef id="id8" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:decimal" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">900001</multiRef></soapenv:Body></soapenv:Envelope>

[2009-06-24 11:52:45,548] http.HTTPSender DEBUG (HTTPThreadGroup-4) - HTTP/1.1 200 OK

[2009-06-24 11:52:45,548] http.HTTPSender DEBUG (HTTPThreadGroup-4) - Server Apache-Coyote/1.1

[2009-06-24 11:52:45,548] http.HTTPSender DEBUG (HTTPThreadGroup-4) - Content-Type text/xml;charset=utf-8

[2009-06-24 11:52:45,548] http.HTTPSender DEBUG (HTTPThreadGroup-4) - Date Wed, 24 Jun 2009 09:52:45 GMT

[2009-06-24 11:52:45,548] http.HTTPSender DEBUG (HTTPThreadGroup-4) - Connection close

…

[2009-06-24 11:52:45,550] http.HTTPSender DEBUG (HTTPThreadGroup-4) -

XML received :

[2009-06-24 11:52:45,550] http.HTTPSender DEBUG (HTTPThreadGroup-4) - -----------------------------------------------

[2009-06-24 11:52:45,550] axis.SOAPPart DEBUG (HTTPThreadGroup-4) - Enter: SOAPPart::getAsSOAPEnvelope()

…

[2009-06-24 11:52:45,553] encoding.DeserializationContext DEBUG (HTTPThreadGroup-4) - Exit: DeserializationContext::startElement()

[2009-06-24 11:52:45,553] encoding.DeserializationContext DEBUG (HTTPThreadGroup-4) - Enter: DeserializationContext::startElement(, cancelado)

…

[2009-06-24 11:52:45,720] i18n.ProjectResourceBundle DEBUG (HTTPThreadGroup-4) - org.apache.axis.i18n.resource::handleGetObject(endElem00)

[2009-06-24 11:52:45,720] encoding.SerializationContext DEBUG (HTTPThreadGroup-4) - End element soapenv:Envelope

2.12 Solver d’activation

Les solvers d’activation sont désormais exploités lors de l’exécution d’une BusinessView et plus uniquement lors de sa phase de montage (quand le paramètre sourceview est passé sur l’URL). Cela autorise un peu plus de souplesse, puisqu’on peut piloter l’activation d’une View via une expression qui prend en compte un paramètre d’URL.

2.13 Divers

2.13.1 Page d’exception générée par le socle technique

Gestion des exceptions techniques : HTML généré par le socle

Pour certains cas d’erreurs techniques levées par le socle, la couche de présentation bénéficie d’une page HTML générée en interne par le socle eGX : cette dernière a été aménagée de manière à pouvoir correspondre avec la feuille de présentation des erreurs techniques (exception.xsl) en termes de présentation.

Les styles ont été externalisés dans le ACE.css standard, et l’import du fichier CSS (pour les pages HTML gérées par le socle directement) est pilotable dorénavant depuis ACE.properties.xml.

La valeur par défaut demeure l’utilisation du ACE.css standard.

Les classes CSS utilisées sont « exception » définies pour les tags HTML « body », « table », « th » et « td ».

Afin de pouvoir utiliser un autre fichier css pour la présentation des erreurs techniques, il conviendra de spécifier le fichier CSS à utiliser via la clé (exeptionCSSLocation), dans ACE.properties.xml comme suit :

<config>

…

<application>

…

<internal>

<misc name="exceptionCSSLocation" value="path/fichierCss.css"/>

</internal>

</application>

…

</config>

3 Services WEB

3.1 Web services Document/Literal

3.1.1 Présentation

• Qu'est-ce qu'un Service Web ?

Il s'agit d'une technologie permettant à des applications de dialoguer à distance via Internet, et ceci indépendamment des plates-formes et des langages sur lesquelles elles reposent. Pour ce faire, les services Web s'appuient sur un ensemble de protocoles standardisant les modes d'invocation mutuels de composants applicatifs. Un projet qui passe notamment par l'élaboration de WSDL et de SOAP.

• Les modes d’invocation

La spécification des « Web Service Definition Language » (WSDL) propose l’attribut style permettant d’utiliser le protocole d’invocation rpc (mode d’invocation historique) ou document (mode d’invocation privilégié à l’heure actuelle). Lorsque l'attribut est défini sur le style document, le « consommateur » de service web comprend qu'il doit faire usage de schémas XML plutôt que d’utiliser les conventions d’appel de procédure distante.

• Avantages du style Document
• Les paramètres ne se limitent plus à des types « simples » (ou connu des 2 parties) : Possibilité d’utiliser toutes les fonctionnalités de XML pour décrire et valider un flux metier de données de haut niveau.
• Ne nécessite pas un contrat « rigide » : Si un service web est largement distribué, alors il est probable qu'un grand nombre d'applications s’appuient sur son document WSDL. Rien n’empêche de faire évoluer le schéma autorisé d’une méthode spécifique à partir du moment où l’ « ancien » format reste valide.
• Mieux adapté pour les traitements asynchrones
• Flexibilité accrue : En mode rpc , l’invocation revient à un échange d’objets (alors qu’en document , ça revient à un échange de l’état d’un objet en XML). En mode document, chaque partie est libre de la conception de l’objet (tant que l’échange est conforme au format convenu).

3.1.2 Evolution ACE

En plus d’être publié en mode « RPC/Encoded » (avec paramètre d’entrée de type « String » ; résultat de type « String », les Web services ACE sont aussi publiés en mode Document/Literal (flux d’entré/sortie XML ~ « type complexe »)

Remarque : Cela ne change en rien leur fonctionnement interne.

Ci-dessous un exemple du WS « businessViewRenderer », opération « renderXml », publication actuelle (String) ; http://...../services/businessViewRenderer :

< soapenv:Envelope xmlns:xsi =" http://www.w3.org/2001/XMLSchema-instance " xmlns:xsd =" http://www.w3.org/2001/XMLSchema " xmlns:soapenv =" http://schemas.xmlsoap.org/soap/envelope/ " xmlns:urn =" urn:ACE ">

< soapenv:Header />

< soapenv:Body >

< urn:renderXml soapenv:encodingStyle =" http://schemas.xmlsoap.org/soap/encoding/ ">

< String_1 xsi:type =" xsd:string "><![CDATA[ <egx_ws>

<ctx entity="1" language="FRA" target="MENU" user="DEMO" password="DEMO"/>

<bean_in>

<BusinessViewRendererrenderXmlIn xmlns="http://www.ACE.fr/technicalframework/businesscomponent/applicationmodule/common">

<context>

<entity>1</entity>

<identification>

<code>DEMO</code>

</identification>

</context>

<businessView>I_PRO_E_F</businessView>

<param name="chp:Codpro" value="AG100"/>

<param name="chp:Nompro" value=" CARTOUCHE%20HP%20610C/690C"/>

</BusinessViewRendererrenderXmlIn>

</bean_in>

</egx_ws> ]]></ String_1 >

</ urn:renderXml >

</ soapenv:Body >

</ soapenv:Envelope >

Ci-dessous le même exemple avec la publication Document/Literal ; http://...../services/literal/businessViewRenderer :

< soapenv:Envelope xmlns:soapenv =" http://schemas.xmlsoap.org/soap/envelope/ " xmlns:urn =" urn:ACE ">

< soapenv:Header />

< soapenv:Body >

< urn:renderXml xmlns =" http://www.ACE.fr/technicalframework/businesscomponent/applicationmodule/common ">

< ctx entity =" 1 " language =" FRA " target =" MENU " user =" DEMO " password =" DEMO "/>

< BusinessViewRendererrenderXmlIn >

< context >

< entity > 1 </ entity >

< identification >

< code > DEMO </ code >

</ identification >

</ context >

< businessView > I_PRO_E_F </ businessView >

< param name =" chp:Codpro " value =" AG100 "/>

< param name =" chp:Nompro " value =" CARTOUCHE%20HP%20610C/690C "/>

</ BusinessViewRendererrenderXmlIn >

</ urn:renderXml >

</ soapenv:Body >

</ soapenv:Envelope >

Impacts :

• Technique, migration de JAX-RPC vers JAX-WS (remplaçant de JAX-RPC):
• OC4J/OAS 10.1.3 ne prenant pas en charge nativement ce framework, la page de test de « Services Web » n’est plus disponible. Il convient donc d’utiliser un client Web service extérieur au serveur d’application. L’outil gratuit soapUI (http://www.soapui.org ) par exemple.
• Plus besoin d’installer l’outil JWSDP (il était nécessaire à la génération des Web services en mode RPC)

• Packaging :
• Disparition du fichier webservices.xml (descripteur de déploiement pour JAX-RPC)
• Apparition du fichier sun-web.xml (descripteur de déploiement pour JAX-WS)
• Modification de paramétrage du fichier web.xml :
• Ajout Listener (com.sun.xml.ws.transport.http.servlet.WSServletContextListener)
• Paramétrage de la servlet JAX-WS (com.sun.xml.ws.transport.http.servlet.WSServlet)
• Ajout des mappings des WS vers la servlet JAX-WS
• Ajout de nouveaux jars runtime :
• gmbal-api-only.jar
• jaxws-api.jar
• jaxws-rt.jar
• jsr181-api.jar
• management-api.jar
• policy.jar
• resolver.jar
• saaj-api.jar
• saaj-impl.jar
• sjsxp.jar
• stax-ex.jar
• streambuffer.jar

3.2 soapUI

Ci-dessous une annexe sur « comment tester des WS avec soapUI »

3.2.1 Installation

• Récupérer la distribution depuis http://www.soapui.org/
• Dézipper
• Positionner la variable d’environnement JAVA_HOME pour pointer vers une JDK6+
• Lancer soapUI par <soapUI>\bin\soapUI.bat

Remarque : Un projet « Hello World » est déjà présent J

3.2.2 Utilisation

• Création d’un nouveau projet « ACE »

• Ajout des WSDL souhaités :

• A chaque « Operation » du WSDL est créé une « Request »

< soapenv:Envelope xmlns:xsi =" http://www.w3.org/2001/XMLSchema-instance " xmlns:xsd =" http://www.w3.org/2001/XMLSchema " xmlns:soapenv =" http://schemas.xmlsoap.org/soap/envelope/ " xmlns:urn =" urn:ACE ">

< soapenv:Body >

< urn:renderXml soapenv:encodingStyle =" http://schemas.xmlsoap.org/soap/encoding/ ">

< String_1 xsi:type =" xsd:string "> ? </ String_1 >

</ urn:renderXml >

</ soapenv:Body >

</ soapenv:Envelope >

< soapenv:Envelope xmlns:soapenv =" http://schemas.xmlsoap.org/soap/envelope/ " xmlns:urn =" urn:ACE " xmlns:com =" http://www.ACE.fr/metier/bc4j/integration/common " xmlns:ser =" http://www.ACE.fr/technicalframework/business/webservice/server ">

< soapenv:Header />

< soapenv:Body >

< urn:assimilate >

<!-- Optional: -->

< com:ctx entity =" ? " language =" ? " target =" ? " user =" ? " password =" ? ">

<!-- Optional: -->

< ser:log >

<!-- Zero or more repetitions: -->

< ser:logger name =" ? " active =" true "/>

</ ser:log >

</ com:ctx >

< com:GCEServiceassimilateIn versionSpecification =" ? " versionImplementation =" ? ">

<!-- 1 or more repetitions: -->

< com:transaction >

<!-- Optional: -->

<!-- Optional: -->

< com:entity > ? </ com:entity >

<!-- Optional: -->

< com:identification >

< com:code > ? </ com:code >

</ com:identification >

<!-- Optional: -->

< com:target > ? </ com:target >

</ com:context >

<!-- Zero or more repetitions: -->

< com:businessEvent >

<!-- Optional: -->

…

< com:pricelistUnit > ? </ com:pricelistUnit >

<!-- Optional: -->

< com:currency > ? </ com:currency >

<!-- Optional: -->

< com:description > ? </ com:description >

</ com:inventoryTurnover >

</ com:transaction >

</ com:GCEServiceassimilateIn >

</ urn:assimilate >

</ soapenv:Body >

</ soapenv:Envelope >

• Exécution de la « Request »

Response

Request

Submit

• D’autres fonctionnalités sont aussi très intéressantes : TestSuite, MockService ou la « Generate Documentation » J

(D’où le bien fondé de la documentation dans les schémas)

(cf http://www.soapui.org/userguide/index.xml)

3.2.3 Glossaire

• JAX-RPC :

JAX-RPC (Java API for XML-based Remote Procedure Call) est une API permettant de créer des services et clients Web basés XML et RPC .

RPC (Remote Procedure Calls), ou appels de procédures à distance, est un système permettant à des clients d'exécuter des procédures sur des systèmes distants. Ces appels de procédures et les réponses retournées se font grâce au protocole HTTP et à SOAP (messages XML).

Attention ! Aujourd’hui remplacé par JAX-WS.

• JAX-WS :

JAX-WS (Java API for XML Web Services) est la nouvelle appellation de JAX-RPC.

JAX-WS est une technologie pour des réaliser des services web et clients en utilisant le language XML.

JAX-WS permet d'écrire en orienté message tout autant que des services web orienté RPC.

Pourquoi ce changement de nom ?

JAX-RPC ne convient plus à l'ensemble des concepts couverts.

Cet acronyme donne l'impression qu'il s'agit uniquement de technologies synchrones, relatives à l'appel de procédure à distance et non aux services web.

De plus l'intégration de JAXB 2.0, pose de nombreux problèmes de compatibilité avec JAX-RPC 1.1.

C'est ainsi l'occasion pour Sun de repenser, mettre à jour, améliorer et surtout rationaliser cette brique logicielle en utilisant les dernières nouveautés du langage lui-même, ainsi que les technologies développées en parallèle dans d'autres groupes de travail.

3.3 Nouveau moteur de rendu

Un nouveau moteur de rendu de type SVG est disponible. Il permet de dessiner des graphiques de type jalon.

3.3.1 Exemple de résultat

Le concept est identique à celui des graphique de type chart. Un fichier xml basé sur un schéma défini la structure du résultat qui est alimenté à partir du flux de présentation.

3.3.2 Configuration

La businessView dispose d’une nouvelle option de rendu : svg.

Un rendu svg se défini comme un rendu html ou chart :

Une documentation spécifique à ce type de rendu sera disponible ultérieurement sous forme d’un GMO.

4 Nouveautés « métier »

4.1 Nouveaux solver d’expressions

Le solver d’expression consiste en une refonte du mécanisme actuel de résolution des expressions intégré à ACE. Il autorise un langage « plus naturel » et vient se greffer en complément de l’existant afin de rester compatible avec les versions précédentes (GCE130 & GCE140).

4.1.1 Syntaxe

Ce solver bénéficie d’une nouvelle syntaxe, profondément inspirée de la syntaxe SQL.

4.1.1.1 Types simples

Le solver supporte les types simples suivants :

4.1.1.1.1 Chaîne de caractères

Une chaîne de caractères consiste en une suite de 0 à n caractères délimitée par des apostrophes. Contrairement à un langage comme Java, il n’y a pas de distinction entre un caractère simple et une chaine de caractères.

Exemples :

4.1.1.1.2 Nombre

Un nombre correspond à n’importe quel valeur numérique, qu’elle soit entière, décimale, positive ou négative. Contrairement à un langage comme Java, il n’y a pas de distinction entre int, long, float ou double.

Exemples :

Important : le séparateur décimal est forcément « . »

4.1.1.1.3 Booléen

Un booléen est soit vrai, soit faux. Il est représenté par les mots clés true et false.

Exemples :

4.1.1.1.4 Null

Le type null désigne une non-valeur.

Exemple :

4.1.1.2 Opérateurs

Le solver supporte les opérateurs classiques :

• Somme à +
• Soustraction à -
• Multiplication à *
• Division à /
• Modulo à %
• Et logique à &&
• Ou logique à ||
• Egalité à =
• Différence à !=
• Strictement inférieur à <
• Strictement supérieur à >
• Inférieur ou égal à <=
• Supérieur ou égal à >=

Les règles de priorités classiques s’appliquent entre ces opérateurs. Il est bien évidemment possible d’utiliser des parenthèses pour effectuer en priorité une opération.

Si le type des opérandes n’est pas compatible avec l’opérateur utilisé, une erreur sera levée (sous la forme d’une exception).

4.1.1.2.1 Exemples

Expression :

Résultat :

Expression :

Résultat :

Expression :

Résultat :

Expression :

Résultat :

Expression :

Résultat :

Les expressions suivantes provoquent toutes une erreur :

4.1.1.2.2 Cas de l’opérateur « + »

Tout comme en Java, l’opérateur + peut non seulement servir à additionner 2 nombres mais également à concaténer 2 chaînes de caractères.

L’opération à effectuer est déterminée en fonction du premier opérande :

• Si c’est une chaîne de caractères, l’opération sera une concaténation
• Sinon ce sera une somme

Expression :

Résultat :

Expression :

Résultat :

4.1.1.2.3 Comparaison de chaînes de caractères

Tout comme en SQL, la comparaison de chaînes de caractères s’effectue simplement en utilisant les opérateurs de comparaison.

Expression :

Résultat :

Expression :

Résultat :

Expression :

Résultat :

4.1.1.3 Fonctions

Les fonctions permettent d’effectuer un traitement particulier. Il en existe de multiples catégories qui seront présentées plus en détail dans le chapitre associé. La présente section ne vise qu’à présenter la syntaxe des fonctions.

Une fonction est de la forme :

Le nom de la fonction ne doit comporter que des lettres, des chiffres et des underscores. Il ne peut pas commencer par un chiffre.

Les paramètres sont séparés par des virgules. Il peut s’agir :

• Soit d’un type simple ;
• Soit d’une fonction (on parle alors de fonctions imbriquées) ;
• Soit d’une expression, c’est-à-dire une combinaison de types simples, d’opérateurs et de fonctions

Exemples :

4.1.2 Comparatif entre l’ancien et le nouveau solver

Il existe de multiples différences entre l’ancien et le nouveau solver. Les principales différences sont :

4.1.2.1 Le typage des données

Le nouveau solver permet de manipuler et de renvoyer des données de type chaîne de caractère, nombre, booléen et null.

Ces types de données sont clairement identifiés en termes de syntaxe. Ainsi il n’est pas possible de confondre le booléen true et la chaîne de caractères 'true'.

4.1.2.2 Les opérateurs

Les opérateurs permettent de combiner ou comparer des données en utilisant une syntaxe plus légère que les fonctions.

4.1.2.3 Les domaines et les fonctions

Les domaines (PPE, MEV, VLP…) de l’ancien solver sont remplacés par des fonctions spécifiques.

4.1.2.4 Les fonctions imbriquées

Avec l’ancien solver, si l’on souhaitait invoquer un domaine à l’intérieur d’un autre domaine, il fallait utiliser la fonction EXPR. La syntaxe du nouveau solver permet d’imbriquer nativement des fonctions les unes dans les autres.

Ainsi, on n’écrira plus :

Mais :

4.2 Référence des fonctions

Les fonctions permettent d’effectuer des opérations complexes au sein d’une expression comme par exemple récupérer la valeur d’un PPE ou extraire une partie d’une chaîne de caractères. Elles sont implémentées en Java.

Il existe plusieurs catégories de fonctions. Selon l’endroit où l’on utilise une expression, certaines catégories de fonctions peuvent ne pas être disponibles. Par exemple, les fonctions liées aux paramètres de ViewLink ne sont pas disponibles pour les expressions d’activation d’une vue composite.

4.2.1 Fonctions standards

Les fonctions standards sont disponibles pour toutes les expressions.

Signature :

Si la valeur de condition est true, la valeur de then est retournée, sinon la valeur de else est retournée.

Exemple :

Résultat :

4.2.1.1 Fonction NVL

Signature :

Si param_1 n’est pas null sa valeur est retournée, sinon c’est la valeur de param_2 qui est retournée.

Exemple :

Résultat :

4.2.1.2 Fonction EMPTY

Signature :

Si string vaut null, est vide ou n’est composée que de caractères d’espacement, la fonction retourne true, sinon elle retourne false.

Exemple :

Résultat :

4.2.1.3 Fonction NOT

Signature :

Si condition vaut true, la fonction retourne false, sinon elle retourne true.

Exemple :

Résultat :

4.2.1.4 Fonction ABS

Signature :

La fonction retourne la valeur absolue de number.

Exemple :

Résultat :

4.2.1.5 Fonction ROUND

Signature :

La fonction retourne un arrondi de number. Le paramètre decimals est facultatif. S’il n’est pas défini, number est arrondi à la valeur entière la plus proche, sinon number est arrondi avec le nombre de décimales spécifiées par decimals.

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.6 Fonction CEIL

Signature :

La fonction retourne la valeur de number arrondie à l’entier supérieur.

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.7 Fonction FLOOR

Signature :

La fonction retourne la valeur de number arrondie à l’entier inférieur.

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.8 Fonction MIN

Signature :

La fonction retourne le plus petit des nombres passés en paramètre.

Exemple :

Résultat :

4.2.1.9 Fonction MAX

Signature :

La fonction retourne le plus grand des nombres passés en paramètre.

Exemple :

Résultat :

4.2.1.10 Fonction AVG

Signature :

La fonction retourne la moyenne des nombres passés en paramètre.

Exemple :

Résultat :

4.2.1.11 Fonction TO_CHAR

Signature :

La fonction convertit param en chaîne de caractères.

Exemple :

Résultat :

4.2.1.12 Fonction TO_NUMBER

Signature :

La fonction convertit string en nombre.

Exemple :

Résultat :

4.2.1.13 Fonction TO_DATE

Signature :

La fonction convertit string en date selon le format spécifié. Le paramètre format est facultatif. S’il n’est pas défini, le format utilisé par défaut est 'yyyyMMdd'.

Le format de date doit être conforme à celui accepté par la classe SimpleDateFormat :

G

AD

y

1996

96

M

July

Jul

07

w

27

W

2

D

189

d

10

F

2

E

Tuesday

Tue

a

PM

H

0

k

24

K

0

h

12

m

30

s

55

S

978

z

Pacific Standard Time

PST

GMT-08:00

Z

-0800

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.14 Fonction UPPER

Signature :

La fonction converti tous les caractères de la chaîne string en majuscules.

Exemple :

Résultat :

4.2.1.15 Fonction LOWER

Signature :

La fonction converti tous les caractères de la chaîne string en minuscules.

Exemple :

Résultat :

4.2.1.16 Fonction SUBSTR

Signature :

La fonction renvoie la sous-partie de la chaîne string allant de from jusqu’à to. Le paramètre to est facultatif. S’il n’est pas défini, la fonction renvoie la sous-partie de string allant de from jusqu’au bout de la chaîne.

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.17 Fonction LIKE

Signature :

La fonction retourne true si la chaîne de caractères string correspond au patternfourni. Le pattern peut contenir les caractères % et ? qui ont le même rôle que leurs homologues SQL.

Exemple :

Résultat :

4.2.1.18 Fonction INSTR

Signature :

La fonction retourne la position de la première occurrence de pattern dans la chaîne de caractères stringen partant du caractère à la position from. Le paramètre from est facultatif. S’il n’est pas défini, la recherche est effectuée depuis le début de la chaîne.

Si le pattern n’est pas trouvé, la fonction retourne -1.

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.19 Fonction REPLACE

Signature :

La fonction remplace toutes les occurrences de pattern par subst dans la chaîne de caractères string. Le paramètre subst est facultatif. S’il n’est pas défini, les occurrences de pattern sont supprimées.

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.20 Fonction TRIM

Signature :

La fonction retire les espaces en début et fin de la chaîne de caractères string.

Exemple :

Résultat :

4.2.1.21 Fonction LPAD

Signature :

La fonction ajoute le caractère pad au début de la chaîne de caractères stringautant de fois que nécessaire de manière à ce que la longueur de la chaîne résultante soit égale à length. Le paramètre pad est facultatif. S’il n’est pas défini, des espaces seront ajoutés.

Si length est inférieure à la longueur de string, string sera tronquée à la longueur définie par length.

Exemple :

Résultat :

Exemple :

Résultat :

Exemple :

Résultat :

4.2.1.22 Fonction RPAD

Signature :

La fonction ajoute le caractère pad à la fin de la chaîne de caractères stringautant de fois que nécessaire de manière à ce que la longueur de la chaîne résultante soit égale à length. Le paramètre pad est facultatif. S’il n’est pas défini, des espaces seront ajoutés.

Si length est inférieure à la longueur de string, string sera tronquée à la longueur définie par length.

Exemple :

Résultat :

Exemple :

Résultat :

Exemple :

Résultat :

4.2.2 Fonctions métier

Les fonctions métier sont disponibles partout dans ACE. Elles se basent sur la session métier associée à un utilisateur.

Il est possible d’en définir de nouvelles via le fichier de configuration comme nous le verrons en détails dans la partie suivante. Cette section vise simplement à présenter les fonctions métier proposées par défaut.

4.2.2.1 Fonction PPE

Signature :

La fonction retourne le champ field du PPE param. Le paramètre field est facultatif. S’il n’est pas défini, la fonction vérifie si le PPE est défini et renvoie true le cas échéant, sinon false.

Exemple :

Résultat :

Exemple :

Résultat :

Exemple :

Résultat :

4.2.2.2 Fonction MEV

Signature :

La fonction retourne le code société physique correspondant au couple codent/ segment. Le paramètre segment est facultatif. S’il n’est pas défini, un espace est utilisé à la place.

Exemple :

Résultat :

4.2.2.3 Fonction PEV

Signature :

La fonction retourne la valeur du paramètre param. Les paramètres disponibles sont :

• ACHVTE
• TYPEVE
• CODETA
• VALETA
• SOLETA
• TYPTIE
• ACHVTO
• TYPEVO
• ETAEVO
• ACHVTS
• TYPEVS
• CODETT

Exemple :

Résultat :

4.2.2.4 Fonction PZN

Signature :

La fonction retourne l’entité pilotée par le PPE PZNsegment.

Exemple :

Résultat :

4.2.2.5 Fonction SES

Signature :

La fonction retourne la valeur du paramètre param dans la session métier. Les paramètres disponibles sont :

• UTI
• LANG
• TARGET
• ENTITY
• CODEETBUTI
• FAMPDV
• FAMSOC
• LONGUEURCOMPTE
• MULTIETAB
• NIVSOC
• NIVUTI
• SIGPDV
• SIGSOC
• P1EXCOD
• P1EXCPP
• P1EXDEB
• P1EXFIN
• STATUTETBUTI
• PARAMLANCEUR
• SUPERUSER
• BUSINESSVIEW

Exemple :

Résultat :

4.2.2.6 Fonction LCFGSOR

Signature :

La fonction retourne le champ field de la table Lcfgsor.

Exemple :

Résultat :

4.2.3 Fonctions liées à la requête HTTP

Ces fonctions sont contextuelles à la requête HTTP courante et sont fournies par le socle technique.

4.2.3.1 Fonction CHP

Signature :

La fonction retourne la valeur du CHP param.

Exemple :

Résultat :

4.2.3.2 Fonction URL

Signature :

La fonction retourne la valeur du paramètre d’URL param.

Exemple :

Résultat :

4.2.4 Fonctions liées à un paramètre de ViewLink

Ces fonctions sont contextuelles au paramètre de ViewLink courant et sont fournies par le socle technique.

4.2.4.1 Fonction VLB

Signature :

La fonction retourne la valeur du champ field de la vue parente.

Exemple :

Résultat :

4.2.4.2 Fonction VLP

Signature :

La fonction retourne la valeur du champ public field.

Exemple :

Résultat :

4.2.5 Macro-fonctions

Une macro-fonction est une fonction basée sur une expression. Cela permet, dans le cas d’une expression couramment utilisée, de ne pas avoir à la réécrire systématiquement.

Une macro-fonction peut prendre des paramètres, ce qui permet de faire varier l’expression sous-jacente.

Il est possible d’en définir via le fichier de configuration comme nous le verrons en détails dans la partie suivante. Cette section vise simplement à présenter la syntaxe des macro-fonctions.

4.2.5.1 Syntaxe

La syntaxe d’une macro-fonction est la même que celle du solver d’expressions. S’y ajoute simplement le caractère @ qui désigne un paramètre de la fonction.

Par exemple, une macro-fonction comprenant trois @ devra impérativement être appelée avec trois paramètres – le premier @ représentant le premier paramètre et ainsi de suite.

4.2.5.2 Exemples

Macro-fonction PPE_TYP :

Macro-fonction MEV_ADR (basée sur la macro-fonction PPE_TYP) :

Expression :

Résultat :

4.3 Utiliser le solver d’expression dans ACE

ACE est configuré pour proposer le mécanisme de résolution d’expressions à des endroits bien précis. Par ailleurs, il est possible de personnaliser le comportement du solver en y ajoutant ses propres fonctions.

Tout cela est centralisé dans le fichier de configuration.

4.3.1 Référencer une fonction métier

Comme nous l’avons vu dans la section précédente, plusieurs fonctions métier sont disponibles avec le solver d’expression. Ces fonctions sont référencées dans la section classalias_def de la configuration.

Déclaration de la fonction PPE :

Il est possible de référencer d’autres fonctions métier sur le même principe. La classe Java associée doit impérativement :

1) Hériter de la classe :

2) Posséder un constructeur respectant la signature :

3) Implémenter les méthodes :

4.3.2 Référencer une macro-fonction

Les macro-fonctions sont référencées dans la section macro_function_def de la configuration.

Exemple :

4.3.3 Solver d’expression dans les paramètres de ViewLink

Au niveau des paramètres de ViewLink, il est possible d’utiliser une expression basée sur :

• les fonctions standards
• les fonctions métier
• les macro-fonctions
• les fonctions liées à la requête HTTP
• les fonctions liées à un paramètre de ViewLink

Pour utiliser le nouveau solver d’expression, il faut sélectionner EXPR dans le menu déroulant de la colonne SolverName et écrire une expression valide dans la colonne Field.

4.3.4 Solver d’expression pour l’activation d’une vue composite

Il est possible de piloter l’activation d’une vue composite à l’aide d’une expression basée sur :

• les fonctions standards
• les fonctions métier
• les macro-fonctions
• les fonctions liées à la requête HTTP

Pour utiliser le nouveau solver d’expression, il faut sélectionner EXPR dans le menu déroulant du champ ActiveSolverName et écrire une expression valide dans le champ ActiveSolverExpression.

5 Couche de présentation

5.1.1 Travaux communs

5.1.1.1 Le web-module « common »

Un nouveau web-module « common » a été créé pour tester le fonctionnement autonome de ce qui doit être commun à tous les web-modules : il est l’image exacte du contenu des arborescences « common » de chaque web-module.

Le module de référence choisi pour initialiser ce module a été le « btoe ».

Le module « common » est constitué de :

1. une page de connexion à l’application ACE, le LOGIN

2. une mire d’accueil de l’application (celle du btoe : « I_MENU »)

3. la gestion des erreurs dans l’application : egx_EXCEPTION

4. toutes les ressources « techniques » XSL centralisées (fichier e-GX.xsl et consorts)

5.1.1.1.1 Planification sur ce module

Le contenu de ce module doit être reporté en intégralité au niveau des arborescences « common » de chaque web-module existant aujourd’hui.

Une phase de « nettoyage » doit être effectuée au niveau des doublons contenus dans les arborescences spécifiques des web-modules.

Enfin, un travail de refactoring pourra être effectué en dernier lieu sur ce module.

5.1.1.2 Conséquences du module « common »

5.1.1.2.1 Au niveau général

Un certain nombre de changements ont dû être opérés avec la production de ce « cœur » commun à tous les WM, ainsi :

• Grâce aux nouveautés offertes par le socle, il est désormais possible de définir 2 niveaux de code « commun » :
• Ce qui est commun uniquement au niveau du WM
• Ce qui est commun entre les WM (contenu du WM « common »)

Exemple :

Sous l’arborescence btoe/presentation/btoe (spécifique au WM btoe)

En parallèle, sous l’arborescence btoe/presentation/common, nous avons

Chacun de ces fichiers est importé quand nécessaire par le chemin définit via l’alias ROOT_XSL_MODULE.

Tel que définit dans le fichier ACE.properties.alias.xml, nous irons lire les fichiers « spécifiques » qui eux, se chargent d’importer les fichiers « common » (variable ROOT_XSL_COMMON), afin de pouvoir surcharger les templates « common » par une redéfinition locale.

NB : Ce principe peut s’appliquer également à toute feuille de style de type « écran » (exemple dans le chapitre dédié au travail sur le template GnxHead).

• Le fichier listes_valeurs .xsl a dû subir des modifications suivant ce principe, pour en extraire une partie commune à tous nos WM et des parties spécifiques suivant un découpage plutôt « fonctionnel ». (chapitre 2)
• Afin de pouvoir étendre la mutualisation du code au niveau des couches JS et CSS (chapitre 3), le template GnxHead a dû bénéficier de quelques ajouts, avec des conséquences sur le contenu technique des feuilles XSL et donc de nouvelles règles pour le développement.
• Découpage du fichier ACE.js ,
• les méthodes implémentant des contrôles sur les formats et les règles de gestions génériques ont été extraites dans un fichier ACE_controls.js ; ce dernier est importé depuis le GnxHead .
• Les méthodes générant les menus de type « explorateur » ont été extraites dans le fichier ACE_explorator.js

5.1.1.2.2 Btob

Le WM « btob » bénéficiant de sa propre charte graphique, doit importer son propre fichier ACE.css.

Pour ce faire :

• le fichier ACE.css issu de la 1 .4 a été placé dans l’arborescence btob/presentation/btob/css
• le fichier ACE.css « common » est bien présent dans l’arborescence btob/presentation/common/css
• le template « common » GnxHead , importe le fichier ACE.css « common », en premier lieu, puis, le ACE.css du btob, afin que les classes définies dans celui-ci écrasent la définition des classes « standard » localement au module btob.

5.1.1.2.3 Sce

Le WM sce à bénéficié des mêmes « arrangements » que le btob, avec en plus, un fichier ACE.js spécifique, là encore, comme pour le CSS, on applique les mêmes procédés techniques, décrits dans la partie 3 de ce document.

Les fichiers sce.css et sce.js ont été renommés en ACE.css et ACE.js, afin de conserver ce « parallélisme » technique, base de la bonne exploitation de la nouvelle organisation technique de la couche de présentation.

5.1.1.2.4 Ressources

Le WM n’étant pas un WM commercial, il n’a pas subit de refonte sur la couche de présentation (organisation des répertoires des XSL).

5.1.1.2.5 BtoeMobile

Le fichier i_global.xsl a été supprimé, sont contenu devant être définit dans les fichiers ACE_template_name.xsl, ACE_template_match.xsl et ACE_global_variable.xsl du module, respectivement suivant la nature de chaque bout de code.

5.1.1.2.6 SceMobile

Le fichier rf_entete.xsl a été supprimé, sont contenu devant être définit dans les fichiers ACE_template_name.xsl, ACE_template_match.xsl et ACE_global_variable.xsl du module, respectivement suivant la nature de chaque bout de code.

5.1.1.3 Opérations diverses

• Certaines améliorations de code ont été réalisées.
• Les comboBox d’opérateurs relationnels ont été retouchées : production dans ACE_template_name.xsl de 3 templates :

Toutes les feuilles utilisant des comboBox d’opérateurs relationnels font désormais appel à ce template « GnxListOperators », qui appelle les seconds, ceci dans le but d’uniformiser la manière de définir les opérateurs.

5.1.2 Listes valeurs

5.1.2.1 Découpage

• Le fichier listes_valeurs.xsl a été découpé selon 3 axes majoritaires dans sa production :
• Commerce (templates issus du btoe)
• Finance (templates de finance)
• Logistique (templates de sce)
• A cela, nous avons ajouté deux parties
• Paramétrage (contiendra les templates propres à la partie « exploitation » d’ACE, éditions, procédures, utilisateurs, fonctions …)
• Et tbl

5.1.2.2 Etat des lieux

Le fichier listes_valeurs.xsl est dorénavant supprimé, on ne pourra plus l’importer dans chaque feuille afin de bénéficier de l’ensemble des règles de transformation pour les nœuds alimentant des Combobox.Il a été découpé comme précisé plus haut, et laisse place aux nouveaux fichiers, pour lesquels, il faudra importer uniquement les fichiers contenant les templates nécessaires au développement.

Chacun de ces fichiers importe à son tour, son correspondant dans « common », exemple :

btoe/presentation/btoe/listes_valeurs.xsl

btoe/presentation/btoe/combo_tbl.xsl

Nous aurons dans btoe/presentation/common/combo_tbl.xsl le fichier de définition des templates pour les comboBox commun à tous les WM.

5.1.2.3 Règles éditeur AUREA

Afin de maintenir un bon niveau d’abstraction de ces fichiers, il est d’intérêt général qu’ils ne soient plus modifiés par les développeurs eux-mêmes, du moins pas sur les fichiers « common », tout nouveau template doit être fait localement à la page, puis porté au niveau du WM si on en déduit une utilisation générale, pour analyse en fin de version sur la nécessité de le remonté ou pas d’un niveau.

Si une définition est nécessaire localement à une page en cours de développement pour modifier une des règle communes, alors il n’est pas nécessaire de définir un mode à cette règle, elle écrasera naturellement la règle commune ; à moins que l’on veuille utiliser les deux règles en même temps, ne pas utiliser de « mode ».

Les attributs mode des templates doivent être insérés après le « match » afin de pouvoir trier les templates sur les noms de nœuds et non les modes.

Ne pas utiliser les nœuds business_data sur ces templates là (attention à l’utilisation des BusinessFlow, ces derniers ne génèrent pas ce nœud).

Tout template de transformation pour ComboBox doit utiliser un paramètre de sélection de valeur par défaut dans la liste, ce paramètre doit être nommé « select » afin de conserver une certaine harmonie dans toute l’application. (Toutes les pages one été corrigées en conséquence, nommages « EltCur » ou « selection » interdits !).

Les appels dans les pages sur les nœuds issus des BusinessFlow ne doivent pas se faire de la manière suivante :

<xsl:apply-templates select="/layout_data/businessFlow/TBL[@name='ctg']/JTblViewRow"/>

Mais plutôt comme ceci :

<xsl:apply-templates select="/layout_data/businessFlow/CTG/JTblViewRow"/>

Pour des raisons évidentes de performances, attention au nommage dans le fichier de configuration donc.

Pour tout template ajouté (localement, ou en commun sur le module), il faudra veiller à utiliser des xsl :value-of pour affichage des valeurs sans règle de transformation plutôt que des xsl :apply-templates (voir règle générale).

On rappelle également que les fichiers combo_xxx.xsl ne doivent pas être importés si :

• Pas de comboBox définie dans la page
• Tous les templates d’alimentation des comboBox sont définies dans la page

Plus généralement, on ne doit jamais importer de fichier si on n’utilise pas les templates qui y sont définis.

5.1.3 GnxHead et principes de surcharge

5.1.3.1 Modification du template GnxHead

Grâce à la production d’un module commun et au principe de surcharge des templates XSL, nous avons pu tirer profit des nouveautés implémentées dans le socle technique d’ACE afin de minimiser les écarts de code entre applications distinctes voire la production même de code pour appliquer des différences de fonctionnement.

Voici un exemple du GnxHead tel qu’il était définit pour le btob (btob/presentation/btob/ACE_template_name.xsl):

Il se distingue du template «common» avec l’import des JS et CSS spécifiques au module.

Afin de minimiser les opérations de comparaison de code dans le cadre d’application de patchs sur des fichiers « dérivés », nous avons implémenté les règles suivantes :

• Pour les CSS

• Pour les variables JS

• Pour les imports de JS

• Et au niveau du fichier ACE_template_name.xsl, définir donc les templates au niveau général « common » comme suit :

5.1.3.2 Utilisation des nouveaux templates

• Pour des raisons de performances et de cohérence, nous utilisons désormais des templates nommés plutôt que des templates de transformation sur le nœud racine du flux.
• Les templates « xxx.common.sheet » sont réservés aux feuilles de styles du module « common », et par extension aux feuilles XLS dans les arborescences « common » des différents WM .

Exemple, feuille d’exception d’ACE (géré dans « common »)

• Les templates « xxx.module » sont réservés pour ajouter des éléments js/css ou définition de variables JS au niveau général du WM, sur les fichiers communs du WM

Exemple, ACE_template_name.xsl du btob, qui doit, pour le module btob, surcharger les fichiers ACE.css et ACE.js de « common » :

Ceci a permis de supprimer la redéfinition complète du template GnxHead pour le btob présentée au début de ce chapitre.

L’extrait technique ci-dessus permet donc de remplacer avantageusement la redéfinition locale du template.

• Les « xxx.module.sheet » sont réservés aux feuilles de styles du module, pour y insérer localement des fichiers JS ou CSS supplémentaires (équivalent du mode « js » ou « css » actuel)

• Les modes « xxx.yyy.s » sont réservés pour les développements spécifiques chez les clients, ceci aura pour vocation de répondre au besoin de développer des spécificités JS ou CSS sans avoir à
• Toucher à la conf pour dériver vers une nouvelle feuille XSL
• Reprendre le code de la feuille XSL standard pour y faire des ajouts
• Une simple feuille XSL définissant le template js.module.sheet.s, avec l’import du fichier JS spécifique (même nom que le standard recommandé), contenant uniquement la méthode dont on doit modifier le comportement permettra de simplifier grandement le travail fournit et les efforts dans les phases de patches/merge.

NB : ce dernier mode est à apparenter au besoin de « surcharger » des fonctionnements du module « common » localement à un WM. Voilà pourquoi nous fournissons plusieurs niveaux d’abstraction des imports de fichiers.

5.1.4 Généralités : règles XSL

• Prendre en compte la nouvelle organisation de la GCE155 et des possibilités que cela offre (exemple fait sur le point 3)
• Prendre en compte les règles définies pour les ComboBox en 2
• A utiliser :
• Pour la gestion des erreurs métier, en GCE140 le template GnxError a été fournit avec description dans les release_notes, il doit être utilisé dans tout nouveau développement, il permet de simplifier la définition de l’apparition des messages et de centraliser la manière dont on doit les afficher. Ce template génère un tableau, il est donc primordial de respecter ou situer dans le code son appel.
• Idem pour le template GnxTextArea , utilisé pour l’affichage des textes libres (texte_libre.xsl à importer)
• Nouveau template GnxListNumbers , pour les ComboBox numériques
• Nouveau template GnxListOperators , pour les ComboBox présentant des opérateurs de comparaison
• Prendre en compte le nouveau découpage du fichier ACE.js
• Prendre en compte le renommage des variables IMG, CSS et JS pour localisation des ressources externes : IMG.HOME, CSS.HOME.COMMON et JS.HOME.COMMON
• Prendre en compte les nouvelles règles sur les imports locaux dans les pages (modes js.common, js.module …)
• Nommages des variables : utiliser des « espaces » de noms logiques, exemple, définition d’une variable pour mémorisation de valeur sur un PPE, aujourd’hui on peut avoir des exemples comme
• TYPFOU
• TYPTIE
• Si on utilise l’expression PPE:TYPFOU.A1, alors le code devient plus lisible, et on connait dès lors le contenu théorique de la variable et son utilisation logique ( on se sait pas par exemple si la variable TYPTIE provient du PEV, d’un PPE ou de l’url …), voici des exemple de nommages
• pev : PEV:NOM_CHAMP (PEV.TYPTIE par exemple)
• ppe : PPE:NOM_PPE.CHAMP (PPE.TYPFOU.A1)
• url : CHP:NOM_PARAM (si paramètre précédé de chp : sur URL)
• url : URL:NOM_PARAM (s’il s’agit d’un paramètre non interprété)
• objet : NOM_OBJET.NOM_CHAMP (exemples : UTI.NOM, EVE.NUMEVE, TIE.TYPTIE …)
• variable : VAR.NOM_VARIABLE si définition de variable qui ne correspond à aucun autre cas.
• L’utilisation des objets JTbl et dérivés est déconseillée voire interdite depuis la 130, il faut utiliser les BusinessFlow, avec les règles de nommages dont on a discuté dans ce document.
• On rappelle également, que l’utilisation d’apply-templates ne doit être utilisée que si nécessaire (pour les dates, les montants, … bref les champs nécessitant une transformation XSLT)

5.1.5 Templates majuscule et minuscule

Ces deux templates ont été supprimés, il convient dorénavant d’utiliser les fonctions :

• gnx:toUpperCase
• gnx:toLowerCase

5.1.6 Template GnxError

Ce template disponible depuis la version140 se doit d’être utilisé pour la gestion des messages d’erreurs levées par le métier dans les pages. Toutefois, on distingue plusieurs cas d’utilisation pour afficher les messages d’erreurs :

5.1.6.1 Remarque générale

Ce template a été créé depuis le clonage des nœuds error contenu dans le flux de présentation à un xpath unique.

Il permet d’afficher toutes les erreurs du flux, dans l’ordre de leur remontée par le métier, il réalise enfin un message d’alerte sous forme de fenêtre modale du premier message d’erreur de la liste.

Attention aux appels multiples sur ce template dans une même page, cela est même interdit, il en coulera une redondance agaçante de l’affichage des messages d’erreurs à l’écran.

5.1.6.2 Cas courant

Le cas le plus répandu est l’affichage simple dans un formulaire de modification, un tableau affichant les erreurs en liste, dans ce cas là, il suffit d’appeler simplement le template GnxError

Attention : le template ajoute un tableau dans la page, il conviendra donc de respecter le DOM HTML, à savoir ne pas appeler ce template entre deux lignes de tableau par exemple. L’appel du template doit être fait depuis le body, ou bien dans une balise HTML de type « td » ou autre similaire pour la mise en page correcte.

5.1.6.3 Cas des erreurs en liste

Le cas des tableaux de listes, permettant de faire des modifications de données en liste, présente la particularité de pouvoir insérer entre chaque ligne une erreur éventuelle sur le nœud de l’objet listé, dans ce cas là, on n’appellera pas le GnxError, on se contentera d’effectuer un test sur l’existence d’un nœud error (sur le « Row »), pour ajouter une ligne au tableau , avec une cellule (class= « error ») pour y afficher le message d’erreur.

5.1.6.4 Cas isolés d’identification du message

Parfois, i lest nécessaire d’afficher un message d’erreur en particulier, identifier fonctionnellement, dans ce cas là encore, le GnxError ne convient pas, on peut reprendre l’exemple du point précédent.

6 XDME

6.1 Interface générale

L’interface générale de XDME est globalement similaire aux précédentes versions. Cependant, certaines évolutions du logiciel ont donné lieu à de subtils changements.

Figure 1 : interface générale

6.1.1 Ouverture simultanée de plusieurs fichiers

Il est désormais possible d’ouvrir plusieurs fichiers de configuration simultanément. Les différents fichiers ouverts sont accessibles via une barre d’onglets située tout en bas de la fenêtre, juste au dessus de la barre d’état :

Figure 2 : liste des fichiers ouverts

Pour fermer une configuration, il suffit de faire « clic-droit / Fermer le fichier de configuration » sur l’onglet correspondant. Ou tout simplement d’utiliser le clic de molette.

Il est possible d’effectuer un copier/coller des éléments d’une configuration vers une autre. Il suffit pour cela de sélectionner un ou plusieurs éléments et de faire un « clic-droit / Copier » puis de se positionner dans la configuration de destination et de faire un « clic-droit / Coller ». Le raccourci clavier Ctrl-C/Ctrl-V est également disponible.

6.2 La barre d’outils

La barre d’outils permet de lancer toutes les actions liées à la configuration actuellement affichée. En d’autres termes, chaque configuration possède sa propre barre d’outils.

Figure 3 : éléments de la barre d'outils

Etant donné que plusieurs fichiers peuvent être ouverts simultanément, certaines options disponibles dans le menu (ex : « Enregistrer », « Recharger »…) ont été déportées exclusivement dans la barre d’outils. De cette manière, elles sont spécifiquement liées à la configuration correspondante.

Il est à noter que certains onglets du panneau principal ont été supprimés, ceci dans un but de lisibilité. Ils sont maintenant disponibles via des boutons de la barre d’outils, à l’extrême droite :

Figure 4 : flux métiers ouverts depuis la barre d'outils

Les éléments de la barre d’outils liés aux fichiers multi-configurations seront décrits en détail dans une autre section.

6.2.1 La barre de menus

La barre de menus permet de lancer toutes les actions qui ne sont pas spécifiquement liées à l’un des fichiers de configuration ouverts.

Figure 5 : menu Fichier

La principale nouveauté du menu Fichier réside dans la possibilité d’ouvrir les fichiers récemment ouverts. Le nombre de fichiers récents est configurable dans les options.

Figure 6 : menu Edition

Le menu Edition permet de choisir une nouvelle interface pour XDME. Un redémarrage peut être nécessaire pour une prise en compte totale de l’interface sélectionnée.

Figure 7 : menu Outils

6.2.2 La liste des éléments de configuration

Les éléments de configuration sont toujours représentés sous la forme d’une liste. Tous les onglets bénéficient maintenant des fonctionnalités de recherche et de filtrage de la liste :

Figure 8 : filtre appliqué sur la feuille XSL

Il est par ailleurs possible de mettre en surbrillance les éléments de la liste référencés dans les signets (ou bookmark) :

Figure 9 : éléments des signets surlignés

6.2.3 Le menu contextuel

Le menu contextuel sur les éléments de configuration a évolué par rapport à la version précédente :

Figure 10 : menu contextuel

Une fonctionnalité intéressante est la représentation XML. Elle permet de visualiser l’élément sélectionné au format XML, tel qu’il sera représenté dans le fichier de configuration :

Figure 11 : représentation XML d'une ViewDef

6.2.4 Les panneaux flottants

Il est possible de visualiser plusieurs éléments de configuration simultanément en les affichant dans des panneaux flottants. Il suffit pour ce faire de cliquer sur l’option « Ajouter en panneau flottant » dans le menu contextuel.

Les différents panneaux flottants ouverts sont tous accessibles depuis une barre d’outils dédiée située juste au dessus de la barre d’onglets des fichiers ouverts :

Figure 12 : un panneau flottant de BusinessView

On notera que les panneaux sont présents dans un objectif de visualisation. Ils seront à même d’évoluer ultérieurement afin de proposer cette fonctionnalité.

6.2.5 Info-bulle sur les cellules de tableau

Il est maintenant possible de visualiser dans une info-bulle la valeur d’une cellule de tableau dont le contenu est trop large pour être affiché (i.e. dont le contenu est tronqué par « … ») en passant la souris au dessus (cf. prochaine capture d’écran).

6.2.6 Interception des erreurs bloquantes

Un mécanisme d’interception des erreurs bloquantes a été implémenté : dès lors qu’un bug survient dans XDME, plutôt que de faire freezer l’application (ce qui entraine une perte irrémédiable de toutes les modifications effectuées depuis la dernière sauvegarde), il est détecté et affiché dans une boîte de dialogue spécifique.

Figure 13 : interception d’une erreur bloquante

La boîte de dialogue affiche un message d’erreur détaillé qui, une fois transmis à l’équipe technique ACE, permettra de faciliter la localisation et la correction du problème.

L’utilisateur peut alors quitter XDME proprement, après avoir sauvegardé son travail s’il le souhaite. Il peut également continuer à travailler, mais cette option n’est pas forcément recommandée car le bug peut être à l’origine de comportements erratiques.

6.3 Mode multi-configurations

Il est désormais possible d’ouvrir, de modifier et de sauvegarder les fichiers de type multi-configurations. Il suffit pour cela d’ouvrir le fichier listant les fichiers de configurations (i.e. configurationdef.xml).

Figure 14 : fichier multi-configurations

Une fois le fichier multi-configurations ouvert, il est possible de modifier les données des différents fichiers de configuration qui le composent. Par défaut, seuls 1) le fichier de plus haut niveau et 2) les fichiers topés en tant que fichiers clients (level=standard dans le fichier de configuration) sont modifiables.

Néanmoins, il est possible de choisir quels sont les fichiers modifiables en utilisant l’éditeur multi-configurations, accessible depuis la barre d’outils.

6.3.1 Sélection de la configuration active

La notion de configuration active est primordiale. Il s’agit de la configuration vers laquelle seront dérivés les éléments de configuration (idem pour les copies).

La configuration active est sélectionnable depuis le menu déroulant disponible dans la barre d’outils :

Figure 15 : sélection de la configuration active

6.3.2 Présentation des éléments multi-configurations

Un élément de configuration d’un fichier multi-configurations est représenté au moyen d’une icône indiquant le numéro du fichier de configuration duquel il est issu :

Figure 16 : éléments d'un fichier multi-configurations

6.3.3 Dérivation d’un élément de configuration

Dès lors que la configuration active est modifiable, il est possible d’effectuer une dérivation.

Pour cela, il suffit de sélectionner un ou plusieurs éléments et de cliquer sur l’option « Dériver vers… » du menu contextuel.

L’élément dérivé est représenté par l’icône :

Figure 17 : élément de configuration dérivé

On notera au passage qu’une icône en forme d’étoile vient rappeler qu’il s’agit d’un élément nouvellement créé.

6.3.4 Sauvegarde d’un fichier multi-configurations

Le lancement de la sauvegarde d’un fichier multi-configurations est identique à un fichier normal (bouton « Sauvegarder » de la barre d’outils).

Le fichier configurationdef.xml est sauvegardé ainsi que les fichiers de configuration topés comme modifiables.

6.3.5 Affichage des niveaux de configuration dans les tableaux

Les cellules des tableaux représentant un niveau de configuration sont maintenant affichées sous la forme d’un icône et non plus d’un simple nombre, comme pour les listes déroulantes.

Figure 18 : tableau des signets

6.3.6 Affichage du niveau de configuration des clauses

Un icône représentant le niveau de configuration est maintenant affiché devant les clauses d’une ViewDef. Par ailleurs, dans le récapitulatif des clés retrieve du panneau ViewStruct, le MaxFetchSize associé à chaque clé est affiché entre parenthèses.

Figure 19 : clauses Retrieve avec leur niveau de configuration

Dans l’éditeur de ViewLink, on retrouve également le niveau de configuration des clauses.

Figure 20 : combo de clauses Retrieve avec leur niveau de configuration

6.4 Editeur de ViewLink

6.4.1 Lancement de l’éditeur de ViewLink

L’éditeur de ViewLink peut être lancé de 2 manières différentes : soit en cliquant sur l’option correspondante du menu contextuel, soit en double-cliquant sur le pavé représentant la ViewDef :

Figure 21 : menu contextuel d'un pavé ViewDef

6.4.2 Interface de l’éditeur de ViewLink

L’interface de l’éditeur de ViewLink a été légèrement remaniée. Il est désormais possible d’éditer, en plus des clés Retrieve et Sort, les clés de type Filter :

Figure 22 : l’éditeur de ViewLink

La barre de titre de l’éditeur de ViewLink rappelle le nom de la ViewDef utilisée, le document associé ainsi que son type.

Lors de la sélection d’une clé, le ResolverClass (solver de type « query » = solver de requêtes) associé est affiché au dessus du viewer de requêtes SQL.

6.4.3 Liste des paramètres

Un outil de détection automatique des paramètres à partir de la requête SQL a été mis en place. Pour l’utiliser il suffit de cliquer sur l’option « Générer la liste des paramètres » du menu contextuel des paramètres.

Il est possible de modifier en masse le domaine des paramètres. Il suffit de sélectionner les paramètres à modifier et de faire apparaître le menu contextuel de modification en masse en cliquant sur la colonne « Domain ».

Enfin, une aide à la saisie (auto-complétion) est disponible dans le champ « Field » via le raccourci clavier « Ctrl + Espace ». La liste des propositions est basée sur les champs de la vue parente ainsi que sur les champs publics définis sur l’un des ViewLink de la ViewStruct.

6.4.4 Ouverture du testeur de requêtes depuis l’éditeur de ViewLink

Une option destinée à cet effet est disponible dans le menu contextuel du tableau des clés d’un ViewLink.

Figure 23 : testeur SQL dans l’éditeur de ViewLink

6.5 Vérification des éléments

Certains éléments du fichier de configuration peuvent bénéficier d’une vérification en masse, dans l’objectif de valider fonctionnellement la configuration (à contrario de la validation par le schéma qui à un objectif technique).

Ce mode de vérification prend en compte les fichiers de configuration multiples, on notera à ce titre que les vérifications n’ont de sens que sur un ensemble cohérent.

(*) Un nom est considéré comme valide lorsqu’il ne comporte que des caractères alphanumériques (donc hors espace, tiret, caractère accentué …)

6.5.1 Vérification des « BusinessView »

• Contrôle que la ViewStruct existe
• Le nom est-il valide (*) ?
• La cible de paramétrage est-elle renseignée ?
• Suppression des éléments de présentation (xslt …) pointant sur une BusinessView non défini
• Contrôle de la cohérence du support de présentation, de la langue et du fichier

6.5.2 Vérification des « ViewStruct »

• Vérification unitaire de chaque View composite, nombre de paramètres dans le ViewLink, cohérence des viewlink de type solved …
• Validation de la cohérence globale des clés publiques
• Le nom de chaque View est-il valide (*) ?
• La ViewDef existe t’elle ?
• Les BusinessFlow sont-ils correctement définis (si présents) ?
• Vérification des View dont le nom serait en doublon pour un niveau donné

6.5.3 Vérification des « ViewDef »

• Conformité du document par rapport au type de ViewDef
• Suppression de ce qui n’est pas conforme (clause d’API sur une ViewDef de type SQLQuery par exemple)
• Clés retrieve en doublon (plusieurs fois le même nom de clé trouvé)

6.5.4 Vérification des « Document »

• Validation de la cohérence par rapport au type (API, BC4J …)

6.5.5 Messages d’erreurs détaillés à la vérification des ViewStructs

Les messages d’erreurs remontés par la vérification des ViewStructs sont beaucoup plus détaillés. Par ailleurs, les clés de ViewLink de type « Sort » sont également vérifiées.

Figure 24 : message d’erreur détaillé

Ces messages sont également affichés sur les vue composites concernées dans une info-bulle :

Figure 25 : info-bulle d’une vue composite affichant des messages d’erreur

6.5.6 Vérification de la conformité des fields

Les fields d’une vue composite doivent être en conformité avec ceux définis dans le descripteur BC4J associé. Dans l’exemple ci-dessous, le champ « Profondeur » n’existe pas : il apparaît donc en erreur. Cette erreur sera également remontée lors de la vérification des ViewStruct.

Figure 26 : field non conforme

Un mécanisme d’auto-complétion (raccourci : Ctrl+Espace) est par ailleurs disponible. Il permet de faciliter la saisie des fields en se basant sur la liste des champs définis dans le descripteur.

Toujours concernant cette boîte de dialogue, il est maintenant possible de trier le tableau de droite selon les colonnes « (used) » et « (visible) ».

6.6 Divers

6.6.1 Connexions BDD multiples

Il est désormais possible de définir plusieurs connexions vers des bases de données différentes. La connexion utilisée dans le testeur de requêtes SQL et dans l’outil de synchronisation des BusinessView est celle affichée dans la fenêtre des options :

Figure 27 : définition des connexions aux BDD

Figure 28 : testeur de requête SQL

6.6.2 Calcul des dépendances croisées d’une ViewStruct

Une nouvelle option est disponible dans le menu contextuel des ViewStruct. Elle permet de déterminer les dépendances croisées d’une ViewStruct.

Figure 29 : menu contextuel d’une ViewStruct

Les dépendances croisées permettent de vérifier :

• quelles sont les BusinessView qui utilisent la ViewStruct sélectionnée
• quelles feuilles XSL sont associées
• si d’autres BusinessView utilisent ces feuilles de style
• quelles sont les ViewStruct associées à ces autres BusinessView
• quelles sont les dépendances croisées de ces ViewStruct (méthode récursive)

Une fois l’option sélectionnée, XDME calcule les dépendances croisées et les affiche dans un onglet spécial de la fenêtre des bookmarks.

Figure 30 : dépendances croisées d’une ViewStruct

6.6.3 Tri des éléments du fichier de configuration

A la sauvegarde du fichier de configuration, de nouveaux mécanismes de tri s’appliquent sur les éléments du fichier :

• Tri des solvers (par type puis par nom puis par classe)
• Tri des flux métiers par défaut (par type puis par nom puis par expression)

Figure 31 : liste des solvers

D’autres mécanismes de tri ont été ajoutés mais ils nécessitent d’être activés par une option (ils sont désactivés par défaut) :

• Tri des clés d’un ViewLink (par PublicKey)
• Tri des business flow d’une ViewStruct (par type puis par nom puis par expression)

Figure 32 : section enregistrement de fichier des options

Si ces options sont cochées, lors de la première sauvegarde du fichier de configuration, l’agencement des éléments risque d’être particulièrement bouleversé. Il est donc conseillé d’activer ces options en accord avec les différents intervenants qui travaillent sur ce fichier.

6.6.4 Web-service client

C’est dans l’onglet ClientWebService que l’on référence le WSDL et que l’on y associe la liste des méthodes.

Figure 33 : onglet ClientWebService

Dans l’onglet Document, on associe un document à un web-service client.

Figure 34 : onglet Document

Au niveau de la ViewDef associée, on peut définir des clauses basées sur le document. Pour chaque clause, il faut spécifier la méthode du web-service que l’on souhaite invoquer.

Figure 35 : sélection de la méthode du web-service

Dans la ViewStruct, une vue composite associée à la ViewDef basée sur un document de type web-service client est affichée avec un fond rose.

Figure 36 : vue composite web-service client

Enfin, au niveau de l’éditeur de ViewLink, on spécifie les paramètres associés à la méthode invoquée.

Figure 37 : édition du ViewLink

6.6.5 Options sur les clauses de ViewDef

Les options de renommage et d’ajout des dépendances d’une clause aux signets sont maintenant accessibles pour tous les types de clauses, y compris les clauses Sort. Par ailleurs, le champ Key est maintenant read-only de manière à éviter un renommage accidentel. En revanche, une option de renommage sans mise à jour des dépendances a été ajoutée.

Figure 38 : menu contextuel d’une clause de ViewDef

La fonctionnalité de recherche des clauses qui ne sont utilisées dans aucune ViewStruct examine également les clauses de type Sort.

6.6.6 Performances

La vérification des ViewStruct est plus rapide (gain d’environ 40 % sur btoe).

La vérification des feuilles XSL a également été améliorée : chaque feuille n’est contrôlée qu’une seule fois, même si elle est référencée par plusieurs BusinessViews. Verrouillage du document d’une ViewDef étendue

Afin d’éviter de fausses manipulations, si une ViewDef étend une ViewDef de niveau inférieur, il devient impossible de modifier le document associé (excepté en mode « super-utilisateur »).

Figure 39 : clauses Retrieve avec leur niveau de configuration

6.6.7 Génération du XPath d’un business flow

Une option destinée à cet effet est disponible dans le menu contextuel du tableau des business flow d’une ViewStruct.

Figure 40 : menu contextuel de génération du XPath

6.6.8 Menu déroulant pour la saisie de DefaultRetrieve et DefaultSort

Cette liste déroulante est alimentée avec la liste des clés publiques définies sur le ViewLink de la vue racine de la ViewStruct.

Figure 41 : menu déroulant pour la saisie de DefaultRetrieve

6.6.9 Affichage des éléments dépréciés dans les menus déroulants

Si un élément est déprécié, il est mis en évidence dans les menus déroulants.

Figure 42 : élément déprécié dans un menu déroulant

7 Evolutions techniques & déploiement

Ce chapitre regroupe les informations importantes concernant le déploiement de l’application et la mise en production d’un ear.

7.1 Introduction

L’application ACE (partie Web) est fournie aux clients via un EAR ciblé pour une plateforme de déploiement donnée (J2EE ou JEE).

L’interface unique existant entre l’applicatif et l’installation se trouve dans le fichier ACE.properties, le document présent n’a pas pour objectif de relater la phase de constitution de l’archive (ear) ni les descripteurs de déploiement.

7.2 Eclatement d’ACE.properties

GCE140

GCE155

Il existe toujours 2 ACE.properties distincts :

• ACE.properties.xml : utilisé pour les environnements de production
• ACE_developpement.properties.xml : utilisé pour les environnements de développement

Certaines sections ont été exportées vers 3 autres fichiers XML :

• ACE.properties.alias.xml : définition des alias de chemins, ceux-ci sont exploités par les imports de feuille de style
• ACE.properties.clientWebService.xml : définition des WebServices clients
• ACE.properties.link_to_ACE.xml : définition des serveurs de traitement

L’inclusion des fichiers supplémentaire se fait via la syntaxe XML habituelle :

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE application [

<!ENTITY link_to_ACE SYSTEM "ACE.properties.link_to_ACE.xml">

<!ENTITY alias SYSTEM "ACE.properties.alias.xml">

<!ENTITY clientWebServices SYSTEM "ACE.properties.clientWebServices.xml">

]>

< config xmlns:xsi =" http://www.w3.org/2001/XMLSchema-instance " xsi:noNamespaceSchemaLocation =" ACE.properties.xsd ">

Remarque : le fichier ACE_recette.properties.xml est un fichier de propriétés interne à ACE, il ne doit pas être utilisé en clientèle.

On notera au passage que les fichiers de configuration, ainsi que les descripteurs LOG4J ont été déplacés dans des répertoires spécifiques. Ils sont mappés via ACE.properties.xml et configurationdef.xml.

7.3 Paramètres de démarrage de la JVM

Certains paramètres de démarrage de la JVM ont été déportés dans les fichiers ACE.properties.xml, ils correspondent à ceux qui peuvent être initialisés par le socle technique et qui relève d’un domaine purement applicatif.

De fait, il n’est plus indispensable de positionner ces paramètres sur la ligne de commande de démarrage de la JVM.

Ces paramètres sont les suivants :

< systemProperties >

< property name =" SessionClass " value =" fr.ACE.technicalframework.business.applicationmodule.GnxSessionImpl "/>

< property name =" log4j.configuration " value =" default_log4j.xml "/>

< property name =" jbo.viewlink.consistent " value =" false "/>

< property name =" jbo.abstract.base.check " value =" false "/>

< property name =" jbo.use.pers.coll " value =" false "/>

< property name =" jbo.SQLBuilder " value =" oracle.jbo.server.GnxTraceOracleSQLBuilderImpl "/>

< property name =" jbo.debugoutput " value =" fr.ACE.technicalframework.log4j.GnxDiagnosticImpl "/>

< property name =" javax.xml.rpc.ServiceFactory " value =" org.apache.axis.client.ServiceFactory "/>

</ systemProperties >

L’ensemble des paramètres de démarrage de la JVM sont loggués dans egx.log (niveau LOG4J=INFO), voici un exemple :

• --------------------------------------------------

initLog4J() : Initialization of logging framework

initLog4J() : confFileName="develop_log4j.xml"

initLog4J() : loaded : "file:/F:/oc4j10134/j2ee/home/applications/GCE140/GCE140-webbtoe/develop_log4j.xml"

initLog4J() : end of init : logs are now written throw LOG4J appenders.

---------------------------------------------------- Locale settings

loadSettings() : Locale/DisplayLanguage ="English"

loadSettings() : Locale/DisplayCountry ="United States"

loadSettings() : Locale/DisplayName ="English (United States)"

loadSettings() : Locale/Language ="en"

loadSettings() : DecimalSeparator ="."

loadSettings() : GroupingSeparator =","

loadSettings() : PatternSeparator =";"

loadSettings() : ZeroDigit ="0"

• -------------------------------------------------- Loading ACE technical settings

loadSettings() : loading properties from ACE_developpement.properties.xml

loadSettings() : set system properties from ACE.properties file

loadSettings() : old value : birt.platform.log4j.filename="null"

loadSettings() : birt.platform.log4j.filename="log/platform.log"

loadSettings() : old value : birt.platform.log4j.level="null"

loadSettings() : birt.platform.log4j.level="debug"

loadSettings() : old value : SessionClass="null"

loadSettings() : SessionClass="fr.ACE.technicalframework.business.applicationmodule.GnxSessionImpl"

loadSettings() : old value : log4j.configuration="default_log4j.xml"

loadSettings() : log4j.configuration="default_log4j.xml"

loadSettings() : old value : jbo.viewlink.consistent="null"

loadSettings() : jbo.viewlink.consistent="false"

loadSettings() : old value : jbo.abstract.base.check="null"

loadSettings() : jbo.abstract.base.check="false"

loadSettings() : old value : jbo.use.pers.coll="null"

loadSettings() : jbo.use.pers.coll="false"

loadSettings() : old value : jbo.SQLBuilder="null"

loadSettings() : jbo.SQLBuilder="oracle.jbo.server.GnxTraceOracleSQLBuilderImpl"

loadSettings() : old value : jbo.debugoutput="fr.ACE.technicalframework.log4j.GnxDiagnosticImpl"

loadSettings() : jbo.debugoutput="fr.ACE.technicalframework.log4j.GnxDiagnosticImpl"

loadSettings() : old value : birt.platform.temporary.directory="null"

loadSettings() : birt.platform.temporary.directory="temp"

• -------------------------------------------------- Management Beans

….

Remarque : le paramètre jbo.max.cursors a disparu, sont utilité/efficacité n’ayant jamais été avérée.

Si un paramètre est défini en même sur la ligne de démarrage de la JVM et dans ACE.properties.xml, c’est la ligne de commande qui est prioritaire.

Remarque : depuis la version155, la JVM exécutant l’applicatif ACE doit être localisé en anglais. C’est un pré-requis obligatoire au bon fonctionnement d’I18N sur la couche de présentation.

Paramètres minimum à positionner sur la ligne de démarrage :

• -Duser.language=en -Duser.country=US : localisation de la JVM
• -Dlog4j.configuration=default_log4j.xml : fichier log4j par défaut (celui-ci est contenu dans le jar « socle technique »), il ne sert que lors de l’initialisation du framework LOG4J et permet de rediriger le démarrage de l’applicatif vers la console en cas de souci. Par la suite, c’est bien le fichier défini dansACE.properties.xml qui est utilisé.

Remarque : les fichiers ACE.properties.xml doivent obligatoirement se trouver dans le context-root du WebModule.

7.4 Mode d’authentification

Afin de supporter d’éventuels nouveaux mode d’authentification à l’application ACE, il a été décidé de positionner une liste de valeurs (ACE/JAAS/SSO) en lieu et place du booléen @declarativeAuthentification.

< authentication >

< mode value =" ACE "/>

< loginBusinessView name =" LOGIN " comment =" BusinessView utilisée pour l'authentification de l'utilisateur par couple utilisateur/mot de passe (uniquement concerné par l'authentification interne à ACE) "/>

< defaultUserRecognize active =" true " comment =" Reconnaissance de l'utilisateur à la reconnexion via le cookie du poste client. "/>

< loginRetry value =" 5 " comment =" Nombre de tentative au login avant la désactivation de l'utilisateur "/>

</ authentication >

Remarque : l’élément <authentification> a été renommé en <authentication> pour respecter le terme anglais.

7.5 Packaging

Pour des raisons exclusivement pratiques (partage de certaines librairies avec XDME en particulier), le packaging des jar a été simplifié :

• Un seul jar représentant le socle technique : technical_framework.jar
• Trois jars pour la couche métier : functional_abstraction.jar, functional_core_bc4j.jar et functional_descriptor_bc4j.jar

D’autre part, et afin d’éviter des conflits de classLoader dans certains environnements clients, le jar contenant le parser fourni par Oracle est renommé et sa signature est changé dans le nouveau délivrable :

8 Vulgarisation : pools & caches

8.1 Introduction

Le présent document a pour objectif de :

• Vulgariser la notion de cache et de pool.
• Spécifier où l’un et l’autre sont utilisés dans ACE
• Expliquer sommairement comment les paramétrer

8.2 Vulgarisation

Bien que les 2 concepts (cache et pool) servent à manipuler des objets, ils sont très différents et chacun a son usage ; tous 2 sont utilisés dans un environnement J2EE.

8.2.1 Définition

• Pool

Terme pour décrire un ensemble de ressources qui sont gérées par le groupement lui-même. Par exemple, un pool de connexion base de données. Quand une connexion est nécessaire, elle est obtenue à partir du pool et à la fin de l’utilisation, elle retourne dans le pool.

Un pool est une collection d’objets stateless

• Cache

Stocke des objets fréquemment utilisés, généralement parce que la recherche et/ou la création n'est pas trivial. Par exemple, pour accéder souvent à une table à partir d'une base de données, ou à des valeurs lues à partir d'un fichier sur le disque, il est plus efficace de les maintenir en mémoire et de les actualiser périodiquement (au besoin).

Un cache ne gère que la durée de vie des objets dans le cache, mais n'impose pas la sémantique de ce qui est maintenu dans le cache.

Un cache est une collection d’objets stateful

8.2.2 Quand utiliser quoi

La principale différence entre un cache et un pool provient de ce qu’ils contiennent : en d’autres termes, pour l’obtention d’un objet à partir d’un cache ou d’un pool, a-t-on besoin d’un objet spécifique, ou n’importe lequel fera l’affaire ?

• Si le besoin est d’obtenir un objet spécifique, chacun de ces objets maintient son état, d’où utilisation d’un cache .

• Au contraire, si n’importe quel objet peut faire l’affaire, les objets ne maintiennent pas leurs états, d’où utilisation d’un pool .

8.2.3 Performances

En termes de performance, voici un comparatif :

• Une demande d’objet « poolé » peut-être servie par n’importe quel objet dans le pool.
• Une demande d’objet « caché » ne peut-être servie que pour un objet spécifique dans le cache .
• Lors d’une demande d’objet, si tous les objets d’un pool sont utilisés, la demande doit attendre qu’un objet retourne dans le pool pour servir la demande.
• Si l’objet demandé dans un cache est utilisé quand il est demandé, la demande doit attendre ; et peut importe que d’autres objets soient disponibles dans le cache , ils ne correspondent pas au besoin.
• La taille d’un pool peut être fixe ou s’accroitre. Si un nouvel objet est demandé à partir d’un pool vide, un nouvel objet peut être créé et ajouté au pool .
• La taille d’un cache est généralement fixe (parce qu’il contient des objets spécifiques et la création d’un nouveau n’est pas toujours une option). Toutefois, si le cache est plein, et un nouvel objet doit être chargé en cache , un objet existant doit être supprimé du cache (activation & passivation)

8.3 Utilisation dans ACE …

8.3.1 Définition

• Caches

Maintiennent des objets partagés entre sessions Http

Une unique version est mise en cache et utilisée simultanément par ceux qui en ont besoin

On y trouve des objets indépendants de l’utilisateur

Certains sont actifs par défaut ; pour d’autres, l’activation est paramétrable globalement

Les caches sont « JVM »

• Pools

Lespools sont dédiés à un type d’objet (classe) et maintiennent une collection d’instances de ce type

Pour être utilisée, une instance sort du pool, ce qui la rend indisponible Þ pas d’utilisation simultanée possible

Les pools sont maintenus par la JVM mais la clé d’accès est généralement liée à la session utilisateur

Il y a deux types de pools :

• Des pools linéaires, avec une taille

> minimale ‘m’ : ‘m’ objets pré-instanciés et mis en pool

> Maximale ‘n’ :

• ‘n’ instances maintenues,
• impossible d’en obtenir plus au runtime (même si elles sont en cours d’utilisation et donc sorties du pool)
• Des pools circulaires, avec une taille unique ‘n’ :

> ‘n’ instances maintenues

> une n+1ème instance écrase la plus ancienne

> Il est tout a fait possible de distribuer plus de ‘n’ instances au runtime

8.3.2 Cartographie

• Caches
• Les feuilles de styles (sous forme fichier)
• Les imports de feuille de style (sous forme fichier)
• Les fichiers de paramétrage des graphiques
• Les fichiers de paramétrage SVG
• Les méta-définitions des objets et des composants métier (ViewObject, ApplicationModule, ClientWebService) ; les 2 1er étant toujours actifs
• Des objets utilisés pour la gestion interne (Sémaphores de ViewObject, Servlet, Birt Designer, Birt ReportEngine, ViewObject en doublons,Constructor domain, Classes, …)
• Des classes chargées dynamiquement et de façon répétitives (actions)

Circulaire :

• Les feuilles de styles sous forme Object JAVA

• Pools
• Linéaires : « Business » ApplicationModule, RootApplicationModule (SessionMetier), client XMLRPC.

Remarque 1 : Le pool d’application module « root » (ou « BusinessSetting ») est « JVM ». Il permet de définit un fusible lié aux nombres simultanés de session utilisateur actives

Remarque 2 : On ne trouve pas un pool d’instances d’ApplicationModule, mais :

• Un pool d’instances du composant de gestion de commandes,
• Un pool d’instances du composant de gestion de clients,

Remarque 3 : Il existe un pool d’application module « business » car leur création BC4J est « longue » (introspection au runtime). Il permet aussi de garantir un nombre maximal d’instance « vivante » et de mieux maitriser la quantité de mémoire utilisée ; le pool est « session »

• Circulaires :
• ViewObject ; la clé de recherche est :
• Type d’objet
• Clause where
• Clause orderby

Remarque : Il existe un pool de view object pour la même raison que le pool d’application module ; le pool est lié au « RootApplicationModule » : soit « session ». L’intérêt est aussi de maitriser le nombre d’instance maximun au runtime et la mémoire consommée.

• Rowset ; la clé de recherche se compose du jeu de valeurs pour les différents paramètres de la clause where

Un rowSet maintient un résultat d’accés à la base de données (un ensemble d’enregistrements) ; le pool est lié à une ViewObject (lié elle-même à un RootApplicationModule, lui-même lié à la session utilisateur. Il est « session »

L’intérêt est ici de ne pas relire les données depuis la base de données (c’est plus un cache qu’un pool !). Attention, par contre, de tomber dans le travers de tout mettre en mémoire ; sous peine de surconsommation mémoire et de désynchronisation par rapport à la base de données.

Remarque : En mode « new pool », les pools peuvent être paramétrés linéaire ou circulaire à la demande.

Un sémaphore permet de protéger une variable (ou un type de donnée abstrait) et constitue la méthode utilisée couramment pour restreindre l'accès à des ressources partagées (par exemple un espace de stockage) dans un environnement de programmation concurrente.

8.3.3 Vue générale

Ci-dessous une vue générale de l’utilisation des pools :

8.3.3.1 Exemple

Pour un type donné d’objet métier, retrouver le résultat d’une requête consiste à retrouver :

• Dans un premier temps, la requête « littérale » dans le pool circulaire d’objets métier
• Dans un second temps, un jeu de valeurs identiques dans le pool de résultats

8.3.3.2 Mise en garde

La mise en pool d’objets est guidée par la recherche de la performance globale de l’application.

Remarque : On parle ici de la performance de l’application en production ; soit en charge (et pas pour 1 utilisateur !!!)

Attention à ne pas tomber dans le travers de vouloir tout mettre en mémoire (pour gagner temps de lecture base de données) au détriment de la mémoire consommée pour maintenir tous ces enregistrements et du déphasage des données maintenues par rapport aux vraies valeurs dans la base de données.

Rappel : Un paramétrage de ce genre (pour les ViewObject) :

viewObjectBufferSize=5 (5 instances d’une table « métier » EVE par exemple)

rowSetBufferSize=3 (3 ResultSet par instance de ViewObject)

maxFetchSize=200 (200 enregistrements au maximum par ResultSet)

peut conduire (au plus lourd de la charge mémoire) à maintenir : 200 * 3 * 5 = 3000 enregistrements de base de données !

8.4 Configuration

La configuration s’effectue dans les fichiers ACE.properties.xml, configuration.xml et pool.xml

8.4.1 Caches

Le paramétrage (activation) s’effectue via le nœud /config/server/cache du fichier ACE.properties.xml

• Pour que les caches soient actifs :
• nœud /config/server/cache/application
• attribut active="true"
• INDISPENSABLE EN MODE PRODUCTION

• Paramétrage de la taille du cache circulaire de feuilles de styles :
• nœud /config/server/cache/xslCacheSize
• attribut value="<nombre de feuilles de styles>"
• Il n’est pas conseillé de mettre la valeur à 0 (pas de limite) sous peine d’une forte surconsommation en mémoire

• Remarque : Une feuille de style ACE consomme entre 1 et 3 Mo en mémoire !

• Activation du cache de constructeur lors de la création d’un nouveau domaine (exemple : mise à jour d’un champ sur lequel on crée un domaine BC4J) :
• nœud /config/server/cache/constructor/domain
• attribut active

• Activation des caches de classes :
• nœud /config/server/cache/class/class
• attribut active

8.4.2 Pools

8.4.2.1 Activation globale

• Activation globale des pools (ancien mode) : fichier ACE.properties.xml

• Pools Linaires d’application module :

nœud /config/server/cache/class/applicationModule ; attribut active

• Pools circulaires de ViewObject :

nœud /config/server/cache/class/viewObject ; attribut active

• Pools circulaires de rowSet :

nœud /config/server/cache/class/rowSet ; attribut active

• Activation globale des pools (« new pool ») : fichier ACE.properties.xml
• nœud /config/server/pool
• attribut active
• liste de fichiers de configuration : nœud /config/server/pool/file ; attribut name (chemin relatif par rapport au module + nom du fichier)

8.4.2.2 Paramétrage

De manière générale, il s’agit de spécifier des valeurs pour les attributs suivants (fichiers configuration*.xml) en mode « old » pool :

• Pools linéaires :
• minInstance : le nombre d'objets pré-instanciés
• maxInstance : le nombre maxima maintenu ET distribué par le pool
• Pools circulaires (encore appelés buffers circulaire)
• *BufferSize : maxima maintenu, sans limite de distribution

ou « pool_configuration.xml » pour le mode « new pool » :

• Pools linéaires :
• priority, maxCount, factory
• Pools circulaires :
• timeToLive, idelTime, emptyCleaning, priority, maxCount, factory, …

• Remarque : Voir les documentations techniques pour avoir le paramétrage « fin »

8.5 Paramétrage en mode « nouveaux pools »

8.5.1 Principe

En complément avec le paramétrage externe des pools déjà disponible en GCE155, il est possible de paramétrer plus finement les objets BC4J recyclés en pool.

8.5.2 Configuration

Deux attributs, poolable et poolConfigurationName sont disponibles sur plusieurs niveaux. Du niveau le plus général au niveau le plus fin, cet attribut est disponible sur :

8.5.2.1 viewobject_def

Valeur par défaut valable pour toutes les instances de ViewObject et les RowSet, quelles soient utilisées via la configuration ou via les API. Les attributs PoolConfigurationName permettent de fixer des valeurs par défaut pour les ViewObject et les RowSet.

Remarque : l’attribut @poolable fonctionne aussi bien en anciens pools qu’en nouveaux pools.

8.5.2.2 viewobject_def/Viewobject

Le nœud ViewObject évolue. L’activation se fait via l’attribut poolable. Les instances de RowSet ont leur propre paramétrage.

Récapitulatif des changements :

Valeur par défaut pour toutes les instances d’un type de ViewObject, quelles soient utilisées via la configuration ou via les API.

Remarque : l’attribut @poolable fonctionne aussi bien en anciens pools qu’en nouveaux pools.

8.5.2.3 viewobject_def/viewobject/rowset

Valeur par défaut pour toutes les instances de rowSet d’un type de ViewObject, quelles soient utilisées via la configuration ou via les API.

Remarque : l’attribut @poolable fonctionne aussi bien en anciens pools qu’en nouveaux pools.

8.5.2.4 view_def

8.5.2.5 view_def/view_type/retrieve/where_clause || sql_query

Valeur par défaut pour toutes les clés de retrieve.

Valeur pour une clé de where_clause precise.

Valeur pour une clé de sql_query precise.

8.5.2.6 Table de vérité partielle des attributs poolable.

Ce tableau défini des liens entres les valeurs de poolables sur les différents niveaux et leurs conséquence dans la gestion des objets en pool.

Toutes les combinaisons ne sont pas détaillées.

Le résultat est toujours donné pour le niveau le plus fin.

Remarque : Il est impossible de définir un pool de Vo pour soit le CRUD, soit les API. En réalité, c’est le même pool (pour une clé identique) qui est accédé dans les deux cas, d’où les lignes nommées « cas impossible ».

Si rowset/@poolable vide => factory de RS pour laisser la possibilité de créer un pool de RS.

Légende :

Pour la section Poolable :

De la forme A-B :

A concerne Poolable : 3 valeurs F, T ou . avec combinaison,

F : false et pas de valeur pour poolConfigurationName

B concerne le nom du pool : pas de valeur, V valeur.

Pour la section CRUD et API :

F : false : les objets ne sont pas gérés en pools.

T : true : les objets sont gérés en pools.

T(PK) : true pour les clés primaires.

9 Cinématiques d’action : document de référence

Ce chapitre présente les différentes actions fournies par le socle technique et introduit leur utilisation au sein du développement pour l’application ACE.

9.1 Présentation

9.1.1 Définition

Une action représente un évènement de cinématique, la combinaison adéquate des actions proposées par le socle permet de piloter les besoins amenés par l’IHM :

1. Afficher une page

2. Mettre à jour des données

3. Supprimer

4. Créer

5. Trier

6. Demander le rechargement d’une donnée modifiée par un autre processus (ou une autre requête)

7. Piloter le login de l’application

8. Supprimer une session ou bien plus finement un contexte applicatif maintenu par le socle.

9. Provoquer le nettoyage des caches à la demande

On peut donc combiner ces différentes actions en une seule requête et traiter différentes cinématiques :

• Mettre à jour avant d’afficher la page
• Créer, invalider le contenu d’une vue, la trier puis l’afficher …

9.1.1.1 Caractéristiques générales

Les actions peuvent être classées en deux groupes distincts :

• Les actions dépendantes , sont celles qui agissent sur les « Vues Métier » et dont l’ordre dans la combinaison a une importance primordiale sur le traitement global
• Les actions indépendantes , dont l’ordre à peu d’importance

Une action dépendante représente le traitement réalisé par le socle au niveau d’une « Vue Métier » sur les différentes vues la composant (on parle de Viewstruct), une action peut être dédiée à une vue en le désignant via son nom (cas des tris par exemple), c’est pourquoi, même si elles sont construites sur le même modèle, les actions présentent néanmoins des signatures différentes :

1. Action sans paramètre obligatoire (ex : assimilate())

2. Action avec paramètre obligatoire (ex : invalidate(NomVue))

3. Action avec paramètre obligatoire et optionnels(les optionnels sont systématiquement en dernière position) (ex : forward(0[,RETRIEVE] [,SORT] ) )

Une action indépendante représente un traitement sur la session utilisateur ou l’une de ses composantes.

• Les actions s’utilisent avec le paramètre « cinematic », elles sont séparées par « ; », la dernière action ne doit pas être suivie de « ; »

9.1.1.2 Particularités

La répétitivité des « actions » communément utilisées a amené l’élaboration d’actions particulières, dites « macro actions ». Ainsi, nous sommes à la fois en présence d’actions élémentaires, indissociables dans leur fonctionnement comme

• Retrieve(demande la sélection des clés d’exécution pour les vues composites)
• Sort(tri)

Et les macros actions, résultat de combinaisons de ces dernières, exemples :

• Init(retrieve+sort)
• Integrate(propose+assimilate)

Ces dernières peuvent à leur tour être combinées entre elles comme suit :

Forward (init+display, soit retrieve+sort+display, exécution des clés de retrieve – requêtes, puis tri et enfin positionnement de la BusinessView désignée en BV de travail ou « courante »)

9.1.1.3 Remarque

Le sujet traité ici impose des prés requis fondamentaux sur le fonctionnement d’une application WEB et des concepts propres au socle technique d’ACE évoqués de près ou de loin dans ce document.

A ce titre, nous allons en introduction détailler également :

• L’ordre d’exécution des Views composites dans une ViewStruct.
• L’application des cinématiques et leur exécution, qui représentent deux phases techniques bien distinctes.

9.1.2 ViewStruct

Une ViewStruct représente un arbre de Views composites, l’exécution de ces dernières est appliquée en fonction de la structure même de l’arbre.

En GCE155, les actions de cinématique sont exécutées lors de la génération du rendu (flux de présentation), ce qui implique de devoir exécuter une View (avec les actions qui lui sont destinées), pour obtenir la génération du flux de rendu et pouvoir passer au traitement de la View suivante.

Ceci nous amènera à voir le distinguo entre l’application des actions cinématiques et leur exécution, qui sont bien deux phases distinctes que nous présenterons par la suite.

9.1.2.1 Ordre d’exécution des Views composites

9.1.2.1.1 Compréhension générale

Voici un exemple de ViewStruct, schématisée par le rendu graphique proposée par XDME :

L’ordre d’exécution des Views va suivre deux axes de lecture :

• 1er sens, de la gauche vers la droite, en passant du niveau 1 à niveau 2, niveau3, etc … cf figure ci-après)
• Cet axe est « prioritaire » sur le second
• 2ème sens de lecture, du bas vers le haut, en arrivant sur un niveau, en provenance de la View « mère » (niveau n-1)
• Si une View possède une View « fille » sur un niveau inférieur, alors on interrompra la lecture du niveau « courant » (bas vers le haut), pour descendre sur la « branche » du niveau inférieur et reprendre le même mécanisme
• Pour le parcours du « bas vers le haut » d’un niveau, on va attribuer un caractère « prioritaire » pour les Views dites « indépendantes », caractérisée par l’absence de paramètre de type « business » passé au ViewLink
• Ex : une vue dédiée à faire de la création en CRUD est « indépendante », on ne lui passe généralement que des paramètres publiques (provenant de l’URL)
• Une API est considérée comme « indépendante » dans la majorité des cas, les paramètres sont le plus souvent publiques.
• On traite d’abord toutes les Views « indépendantes » du bas vers le haut, puis les Views « dépendantes », toujours dans le même sens.

9.1.2.1.2 Niveaux d’une ViewStruct : lire de gauche à droite

Nous avons réalisé plusieurs schémas pour avoir une application des deux axes de lectures évoqués.

Nous avons d’abord voulu représenter les fameux « niveaux » :

• Nous commençons logiquement par le niveau 1 en utilisant le 1er sens de lecture comme point de départ, aucune autre View n’est définie dans ce niveau, il n’y a donc pas de problème pour définir que ce sera « VueUtilisateur » qui sera exécutée en premier :
• nous passerons au niveau 2, exécuter les Views « filles » de « VueUtilisateur »
• une View indépendante est signalisée par l’icône « prise débranchée » dans XDME

9.1.2.1.3 Parcours d’un niveau : lire de bas en haut

• « SuiviBugetaire » et « DetailImputation » sont deux vues dites « dépendantes « dans notre exemple : elles utilisent toutes deux le paramètre « Codsoc » en « business », hérité de « VueUtilisateur ». Nous n’avons que des Views dépendantes sur ce niveau, on va donc simplement lire dans l’ordre 2, soit du bas vers le haut, « SuiviBugetaire » en premier.
• « SuiviBudgetaire » n’a pas de Views « filles », on passera à « DetailImputation »
• « DetailImputation » oui, après son exécution, on passera au niveau 3

Remarque : Si il y avait eu une Troisième View, au –dessus de « DetailImputation », on passerait quand même au niveau 3, après exécution de « DetailImputation », pour traiter la/les branches « filles » sur le niveau 3, pour revenir au niveau 2 par la suite, et continuer dans le sens d’exécution des Views (du bas vers le haut toujours).

9.1.2.1.4 Parcours d’un niveau : View indépendantes et Views dépendantes

• Sur l’illustration du niveau 3, on essaie d’appliquer l’ordre d’exécution du bas vers le haut, mais cette fois, le cas est peu plus complexe :
• « MontantBudgetaire » est une View indépendante, ou plutôt considérée comme tel (nous voulons plutôt généraliser la réflexion), car aucun paramètre de type « business » ne lui est appliqué, en réalité il s’agit d’une API. Etant la seule de ce type, elle sera exécutée en premier.
• On exécutera ensuite le groupe des Views dépendantes, nous gérons donc 2 « sous niveaux »

• En 2ème phase de l’exécution de ce niveau 3, on passe au Views « dépendantes », on commencera comme dans le cas précédent par « AxeAnalytique ».
• A la différence du niveau 2, « AxeAnalytique », en tant que première View exécutée sur ce niveau, possède une View « fille » : avant de passer à « FraisDivers », nous passerons par le niveau 4

• A la fin du traitement du niveau 3 (pour la dernière View), on a terminé ici le traitement complet de la ViewStruct
• C’est à la fin de ce niveau 3, que l’on aurait pu tenir compte de la remarque faite au niveau 2.

9.1.2.1.5 Exemples synthétiques

9.1.2.2 Application et exécution des cinématiques d’action

En GCE155, l’application des cinématiques d’action à subit une refonte : là ou on « exécutait » l’ensemble des actions pour toutes les Views, on distingue désormais la phase d’application et d’exécution.

L’application des cinématiques d’action tient à un « dispatch » du contenu du paramètre « cinematic » sur les Views concernées, via le nom de la View par exemple ou encore l’attribut « create » positionné sur la View pour le cas de « create ».

Les cinématiques n’étant pas applicable sur une View donnée ne sont pas ajoutées comme étant à exécuter par la suite sur cette même View.

L’exécution de ces cinématiques intervient par la suite, au moment de la phase de rendu de chacune.

9.2 Référentiel

Nous allons introduire ici la liste exhaustive des actions fournies par le socle technique pour l’application ACE, en présentant leur fonction première.

Nous allons découper cette présentation en trois parties selon cette logique :

• Les Actions Indépendantes.
• Actions Dépendantes, dédiées au déroulement des cinématiques de l’application et aux manipulations des données : celles qui travaillent sur les BusinessView
• Enfin, les « macro actions » qui reprennent les combinaisons d’actions les plus généralistes

Nous reprendrons plus en détail leur utilité ainsi que des exemples par la suite.

9.2.1 Actions indépendantes

Dans l’univers de notre application, il faut maîtriser les notions de session métier et contextes applicatifs pour comprendre l’utilité des actions qui seront présentées dans ce chapitre. Nous allons étudier ici les actions « indépendantes » qui ne sont pas liées dans leur utilisation à une BusinessView (hormis « login » cas particulier car liée à l’utilisation d’une API car les informations d’identification sont exploitées sur la couche métier).

• Remarque : dans une cinématique comportant plusieurs actions, quel que soit l’ordre des actions, celles-ci seront exécutées avant ou après la phase de rendu.

9.2.1.1 Gestion de l’authentification

L’application ACE permet de visualiser/traiter les données de la solution ACE aussi bien sur des écrans dits « publiques » que privés ; pour ces derniers, une authentification de l’utilisateur sera bien sûr requise (identification interne ou utilisation de JAAS pour identification via LDAP par exemple).

9.2.1.1.1 Login

L’action « login » permet à l’utilisateur de s’authentifier dans l’application.

• Syntaxe : login (viewRef)
• Paramètre obligatoire : viewRef : nom référence de la vue dans la ViewStruct de Login à l’application (d’autre part la BusinessView utilisée pour le login est définie dans le fichier ACE.properties.xml : loginBusinessView)
• Remarques :
• Login est une action dépendante, car liée à une API d’authentification, mais on la présente toute de même ici, vu son lien « spécifique » avec la session utilisateur.
• L’application permet toutefois d’utiliser des BusinessView « publiques » pour lesquelles l’authentification n’est pas nécessaire, une session métier est tout même allouée, le socle utilise exploite alors l’utilisateur « GUEST » pour l’ensemble des transactions.
• Cette cinématique n’a pas de sens lors d’une authentification externe (JAAS et SSO)

9.2.1.1.2 Logout

L’action « logout » permet à l’utilisateur de quitter sa session. Elle demeurera conservée (ex : jusqu’à écoulement du timeout de session), et pourra être récupérée en cas de reconnexion de l’utilisateur.

C’est donc là que joue l’intérêt d’utiliser un cookie pour avoir une connexion automatique de l’utilisateur à l’application et de récupérer sa session (à concurrence de la période de validité du cookie et de la gestion autorisée de l’UUID dans ACE.properties).

• Syntaxe : logout()
• Remarques :
• Si une demande de BV privée est faite après un logout (logout() ;display(0)), alors l’utilisateur sera « GUEST » et les informations de la page en dépendront
• Sur une autre URL, suite au « logout », la page de connexion à l’application est renvoyée
• Cette cinématique n’a pas de sens lors d’une authentification externe (JAAS et SSO)

9.2.1.2 Gestion de la session métier et des contextes applicatifs

Comme nous l’avons évoqué, une session utilisateur est composée de différents contextes applicatifs. Le maintient de ces contextes permet notamment de pouvoir travailler sur les données (écrans de mises à jour, de listes, de création…). Mais il apparaît nécessaire également de pouvoir supprimer ces contextes à la fermeture des écrans correspondants, ou bien de détruire complètement la session en quittant l’application.

9.2.1.2.1 killSession

L’action killSession permet de supprimer définitivement la session métier de l’utilisateur.

Elle est utilisée uniquement à la fermeture du portail principal d’ACE, qui équivaut à un abandon de l’application par l’utilisateur.

• Syntaxe : killSession()
• Remarque :
• L’action killSession est toujours exécutée en dernier lieu (quelle que soit sa position dans la chaîne du paramètre cinematic )

9.2.1.2.2 killContext

L’action killContext agit sur le même principe, mais ne détruit que le ou les contextes applicatifs ciblés. Ceci permet de réduire la consommation mémoire globale d’une session métier pour un utilisateur.

• Syntaxe : killContext(CtxRef)
• Paramètre obligatoire : CtxRef : le nom du contexte devant être détruit
• Remarque :
• Il est possible de détruire un groupe de contextes applicatifs en une requête en utilisant le caractère joker « % »

9.2.1.3 Gestion du paramétrage technique de l’application

Le socle a fournit également des actions permettant générer des traces de logging et de piloter l’activation/désactivation des ces différentes traces transversales (data et timers). Ces traces sont désactivées sur un environnement de production, ce paramétrage étant initialisé avec le démarrage de l’application, le socle a fournit de quoi les activer dynamiquement.

Elles demeurent utilisées à des fins de recherche d’informations purement techniques et ne sont pas employées au sein même des écrans dits « métiers ».

• Remarques :
• A partir de la version155, les timers sont également activables et ce, d’une façon plus fine mais globale à tous les utilisateurs via le fichier ACE.properties.xml , section « timer_def »

9.2.1.3.1 Trace_reload

L’activation des traces répond du paramétrage technique de l’application, l’action « trace_reload » permet néanmoins de relire dynamiquement ce paramétrage (fichier de configuration des timers, interne au fichier ACE.properties) initialisé au démarrage de l’application sur le serveur hôte, pour un environnement de production par exemple, afin de ne pas avoir à le redémarrer.

• Syntaxe : trace_reload()

9.2.1.3.2 Trace_enable

L’action « trace_enable » permet elle de désigner quelle trace doit être activée.

L’activation d’un timer est valable pour toute la session de l’utilisateur tant qu’elle n’a pas été expressément désactivée ou désamorcée par un mécanisme interne au socle (erreur grave par exemple).

• Syntaxe : trace_enable(traceRef)
• Paramètre obligatoire : traceRef
• Exemples
• trace_enable(data)
• trace_enable(timer)
• trace_enable(XSLTTimer)
• trace_enable(viewTimer)
• trace_enable(actionTimer)
• trace_enable(buildTimer)
• trace_enable(attrTimer)

9.2.1.3.3 Trace_disable

L’action « trace_disable » correspond à l’action contraire de la précédente.

• Syntaxe : trace_disable(traceRef)
• Paramètre obligatoire : traceRef

9.2.1.3.4 Properties_reload

Comme trace_reload, cette action permet de relire dynamiquement toute modification apportée au fichier ACE.properties.xml après démarrage de l’application.

• Syntaxe : properties_reload(traceRef)
• Remarque : depuis la version140, une console JMX permet de demander le rechargement.

9.2.1.3.5 clearCacheOnCommit

Cette action provoque un nettoyage (vidage) de l’ensemble des caches de ViewObject lors de l’exécution du commit, si ce dernier à lieu. Quelle que soit la position de cette action dans la chaine de cinématique, le nettoyage sera effectué lors du commit, à la fin de l’exécution de la requête.

• Syntaxe : clearCacheOnCommit()

9.2.1.3.6 clearCacheOnRollback

Cette action provoque un nettoyage (purge) de l’ensemble des caches de ViewObject lors de l’exécution du rollback, si ce dernier à lieu. Quelle que soit la position de cette action dans la chaine de cinématique, le nettoyage sera effectué lors du rollback, à la fin de l’exécution de la requête.

• Syntaxe : clearCacheOnRollBack()

9.2.1.3.7 clearEntityCache

Cette action permet de purger immédiatement un, plusieurs ou tous les caches d’EntityObject, quelle que soit l’issue de la requête.

• Syntaxe : clearEntityCache([EntityRef1[|EntityRef2]])
• Paramètre optionnel : EntityRef
• Non renseigné : purge de tous les caches
• Renseigné : clearEntityCache(EntityRef1) = purge du cache renseigné :

clearEntityCache(fr.ACE.technicalframework.businesscomponent.entityobject.UtUuid)

• Renseigné, multi-valeurs : clearEntityCache(EntityRef1|EntityRef2) = purge des caches renseignés

9.2.2 Actions dépendantes

Ce chapitre recense les actions de cinématiques utilisées dans le développement d’ACE, nous rappelons que nous présentons dans un premier temps seulement leur but premier, le fonctionnement de chacune sera plus approfondi par la suite avec des cas d’application.

Nous allons découper ce chapitre en deux parties principales, les actions élémentaires d’une part, puis les macros actions, qui reprennent donc les combinaisons classiques des premières.

• Il est important de maîtriser la notion de contexte applicatif abordée ici, on rappelle :
• Un contexte applicatif est créé/mis à jour par le socle pour chaque requête
• Le paramètre « frame » sur l’URL nomme pour le socle ce contexte (« default » si pas de paramètre)
• Au sein d’un contexte applicatif, on peut avoir plusieurs BusinessView :
• Les BV sont gérées en liste, chacune est donc adressée via son « index » de position dans la liste
• On introduit alors la notion de BV courante (par défaut, celle à l’index 0) : celle pour laquelle on aura une « présentation » des données, la page affichée dans le navigateur
• Ceci permet de pouvoir traiter n BV en une seule requête
• On utilise sur les URL les paramètres « sourceview » et « view » pour adresser la/les BusinessView par leur nom
• « sourceview » désigne implicitement la BV courante, on travaille sur une seule BV pour initialiser le contexte applicatif. Si il y avait précédemment déjà une BV courante, elle sera détruite et remplacée par celle nommée via « sourceview ».
• « view » est utilisé pour les cas ou l’on veut traiter plusieurs BV en même temps : cette notation ne supprime pas la BV courante si il y en a une pour le contexte de travail, elle permet de travailler sur la BV courante et les « nouvelles » données éventuellement au paramètre « view ». A l’issue du traitement, seule la BV courante sera conservée (on verra par la suite comment « forcer » la BV courante notamment via l’utilisation de la cinématique d’action « display »).

9.2.2.1 Les actions élémentaires : afficher une page

Au sein de même de ce « regroupement », nous distinguons des actions primordiales, celles qui servent à initialiser et « afficher » une page, et les autres, qui auront plus pour but de manipuler les données (tri, mise à jour, création, suppression …).

Les deux actions précisées ici sont les deux seules actions obligatoires à préciser pour l’affichage d’une nouvelle BusinessView pour un contexte applicatif donnée (nouveau ou écrasement du contenu de ce dernier).

9.2.2.1.1 retrieve

De part sa définition, une View est associée à un ensemble d’ordres combinant des critères de sélection. L’action « retrieve » permet d’activer cette sélection selon 2 modes :

• clé précisée en paramètre
• clé par défaut implicite définie dans la BusinessView

On rappelle les modes d’alimentation des différents critères mis en œuvres par la sélection des clés impliquée ici :

• public : le paramètre doit être présent sur l’URL, à défaut une erreur sera remontée par le socle
• business : le paramètre est hérité de la vue mère ou d’une vue sur un niveau supérieur du même arbre (le nom de la vue est précisé à ce moment sur le paramètre viewName )
• value : valeur saisie « en dur »
• solved : utilisation des solvers métier

• Syntaxe : retrieve(BVRef [,keyRef])
• Paramètre obligatoire : BVRef : la référence à la BusinessView pour laquelle on veut appliquer une sélection de clé publique pour l’exécution des requêtes pour chaque Vue la composant. Il s’agit ici de l’index de la BV représentant sa position dans la liste des BV pour le contexte applicatif (précisé sur l’URL via le paramètre « frame » : nous verrons comment cela s’utilise dans les cas d’applications)
• 0 est le plus souvent utilisé, on désigne alors la BV courante (utilisation du paramètre « sourceview »)
• 1, 2, …n , on utilise alors le paramètre « view » pour donner le nom de la/les BV à traiter dans la requête
• Paramètre optionnel : keyRef : le nom de la public Key pour la sélection des paramètres et de la retrieveKey au niveau des Vues ; optionnel, car au moins une clé public par défaut doit exister pour chaque ViewStruct pour utilisation si le paramètre n’est pas précisé.

9.2.2.1.2 display

L’action « display » est fondamentale dans sa compréhension. Elle représente l’opération minimale présente à chaque requête de cinématique : elle permet d’identifier la BusinessView « de travail » ou « courante » par contexte applicatif créé.

La BusinessView courante étant celle pour laquelle on obtiendra une « présentation » des données : la page affichée dans le navigateur, c’est également celle qui persistera dans le contexte applicatif une fois le traitement de la requête courante terminé.

Il important ici de maîtriser le concept de « contexte applicatif », ce que cela représente, nous pouvons avoir plusieurs BusinessView dans un contexte, « display », le plus généralement sert à définir quelle BusinessView devra être affichée : la courante à l’issue du traitement global des cinématiques.

Mais dans le cas ou on traite plusieurs BV sur une même requête, « display » aura un autre rôle : c’est elle qui va avoir un impact sur les actions « contextuelles », celles qui sont dépendantes des Views et qui ne peuvent travailler que sur la BV courante, nous verrons un peu mieux ce que cela veut dire lorsque nous reviendrons sur son utilisation.

• Syntaxe : display(BVRef)
• Paramètre obligatoire : BVRef : la référence à la BusinessView pour laquelle on demande donc son positionnement en BV courante, ici aussi on utilise son « index » de position dans le contexte applicatif. Nous verrons dans les cas d’application que l’on peut utiliser plusieurs fois « display » dans une même requête, afin d’exécuter certaines actions de manière « contextuelle » à une BV donnée (assimilate, invalidate, setLine, setPage …).
• Remarques :
• « display » est donc à utiliser lorsque l’on veut afficher une BV pour la première fois : si cette BV est déjà affichée et courante dans le contexte associé, alors « display » devient facultative. Une bonne pratique consiste néanmoins à rester le plus explicite possible dans la définition des cinématiques à traiter, tout en restant cohérent sur l’ordre des actions défini.
• Ou lorsque l’on travaille sur plusieurs BV, afin de pouvoir déclencher des actions « contextuelles » pour chaque BV et déterminer enfin celle à afficher à la fin du traitement.
• En cas de besoin d’un traitement du type : choisir la BV à afficher selon le résultat du traitement, il est possible d’écrire sa ou ses propres actions qui déclencheront, par code Java, l’action « display » sur la BV choisie.

9.2.2.2 Les actions élémentaires : manipuler les données

Nous avons vu quelles actions permettaient d’initialiser une page de l’application ACE, manque maintenant la présentation de celles qui permettent d’y manipuler les données et qui représentent toutes les possibilités offertes par notre solution.

9.2.2.2.1 create

L’action « create » sera utilisée pour les cas de création de données via des vues (CRUD), pour celles qui seront explicitement définies pour la création (positionnement attribut create de la vue dans la ViewStruct).

« create » seule ne permet pas de créer, elle permet seulement d’initialiser un Row vide dans un document pour pouvoir y faire de la mise à jour avec les valeurs envoyées depuis la page, via les actions que nous allons présenter ci-après : elle positionne la ou les Views en mode « création » et en attente des actions qui permettront la création effective, en accord avec l’application des bons paramètres attendus.

• Syntaxe : create(BVRef)
• Paramètre obligatoire : BVRef : la référence à la BusinessView pour laquelle on demande de pouvoir faire de la création sur toutes les Vues qui ont l’attribut « create » à « true ».

9.2.2.2.2 propose

L’action « propose » gère les buffers de saisie au niveau du DocumentLine (ex DocumentRow). Elle est le plus souvent suivie de l’action « assimilate » qui représente la mise à jour de ces données sur les objets métiers.

Elle correspond donc à une mise à jour des données du « Row » au niveau « Document».

Elle est, sur le même concept utilisée pour les traitements avec API.

• Syntaxe : propose (BVRef, [ViewRef])
• Paramètre obligatoire : BVRef : la référence à la BusinessView par son « index ».
• Paramètre optionnel : ViewRef : la référence à la View ciblée par l’action.

9.2.2.2.3 assimilate

L’action « assimilate » représente, comme évoqué, l’envoi des données depuis les DocumentLine vers sur les objets métiers et donc déclenchera au niveau de la couche métier les différents contrôles d’intégrité des données.

Elle est donc primordiale et directement concernée dans les opérations de mise à jour et création de données.

• Syntaxe : assimilate([BVRef], [ViewRef])
• Paramètres optionnels :
• BVRef : la référence à la BusinessView
• ViewRef : Nom de la vue
• Remarque : sans utilisation du paramètre « BVRef », on travaille sur la BV courante (et page courante) dans le contexte applicatif lié à la requête qui utilisera cette action. Nous verrons plus bas toute l’importance de cette remarque, mais on doit d’ores et déjà recouper avec le besoin d’utiliser « display ».

9.2.2.2.4 delete

L’action « delete » est impliquée dans les opérations de suppression de Row via les ViewObjects (on parle de suppression en CRUD). Pour Sélectionner les vues qui doivent effectuer une opération de suppression, le socle doit coupler avec la présence des paramètres publics nommant la vue et indiquant le numéro de ligne à supprimer au niveau des documents.

Pour les suppressions via API, l’action delete est inapplicable, on fonctionnera avec le couple « propose » et « assimilate ».

L’action « assimilate » représentant une « validation » de traitement n’est pas non plus concernée par le cas de la suppression, « delete » seule suffit.

• Syntaxe : delete([BVRef], [ViewRef])
• Paramètres optionnels :
• BVRef : la référence à la BusinessView
• ViewRef : Nom de la vue
• Remarques :
• l’utilisation de « delete » va de pair avec les paramètres sur l’espace de nommage « sel »
• sel :NomVue=on : activation de la suppression sur « NomVue »
• un delete ne doit jamais être passé avant un « propose(0) ;assimilate() », mais à la suite, afin de ne pas supprimer un Row pour lequel des champs de mise à jour sont passés sur l’URL

9.2.2.2.5 invalidate

L’action « invalidate » demande l’invalidation d’une vue et redéclenche l’exécution des requêtes afin de synchroniser le contenu du Document avec la base de données.

Elle doit être utilisée avec parcimonie, explicitement pour les cas ou les données doivent être rechargées (nouvel insert dans la base devant figurer dans une liste déjà chargée, modification de valeur d’un Row survenu par un autre traitement/dans un autre contexte).

• Syntaxe : invalidate(viewRef)
• Paramètre obligatoire : viewRef : Nom de la Vue pour laquelle on demande un « rechargement » explicite du RowSet (contenu).
• Remarques :
• On travaille sur la BV courante
• On peut demander plusieurs « invalidate » dans la même requête
• L’action « invalidate » sur une vue est propagée sur ses vues filles (donc si on veut invalider n Vues du même niveau il apparaît plus économe de le faire une fois sur la Vue mère)
• Le plus souvent, on utilise « invalidate » pour recharger le contenu d’une vue « Liste » :
• Si on fait un delete sur un Row de cette liste, alors « invalidate » ne dois pas être utilisée
• Si on fait une création de donnée : alors il faut faire une invalidate sur la liste pour voir apparaître le nouveau Row

9.2.2.3 Les actions élémentaires : naviguer dans les Document

Nous avons évoqué les actions qui permettent dans une première approche :

• d’afficher une page
• créer, supprimer ou recharger une donnée

Maintenant, nous allons présenter le dernier groupe, celles qui permettent de pouvoir naviguer dans les documents et donc de modifier le contenu d’un écran.

9.2.2.3.1 sort

Sur le même principe de fonctionnement que « retrieve », l’action « sort » permet d’activer les tris spécifiés pour chaque Vue par propagation de la clé de tri via un paramètre passé à l’action ou, à défaut, celle précisée comme clé par défaut dans la ViewStruct.

• Syntaxe : sort(BVRef [,sortRef])
• Paramètre obligatoire : BVRef : index de la BV à traiter.
• Paramètre optionnel : sortRef : ce paramètre est optionnel, comme pour retrieve, il existe un tri par défaut (non obligatoire) positionné sur la ViewStruct, et une clé par Vue nécessitant un tri.
• Remarques :
• Il est possible d’indiquer plusieurs clés de tri, concaténées et appliquées ensembles comme suit : sort(0,-NOM|COD|TYP)
• L’action sort peut travailler sur les autres BV que la courante
• L’utilisation seule de « sort » suffit pour une BV courante (pas la peine de faire un retrieve, display …)
• Le changement de clé de tri sur la BV courante, provoque un « invalidate » implicite, le contenu du RowSet sera rechargé.

9.2.2.3.2 Init

Depuis la GCE155, « init » devient une véritable « action » et non plus une macro action.

L’action « init » représente la combinaison de « retrieve » et « sort », elle demande donc simplement la sélection des clés de retrieve et des clés de tris pour les vues.

• Syntaxe : init(BVRef [,keyRef] [,sortRef]) = retrieve(BVRef [,keyRef]) ;sort(BVRef [,sortRef])
• Paramètre obligatoire : BVRef : index BusinessView
• Paramètres optionnels :
• keyRef : clé de retrieve
• sortRef : clé de tri
• Remarques :
• Init ne fait pas de display, init ne permet donc pas de passer la BV référencée en courante
• Init peut donc être utilisée seule sur une BV courante déjà affichée (changement de clé de tri et de clé de retrieve en même temps :
• Si on veut seulement changer de clé de retrieve pour une BV courante, alors l’action retrieve seule suffira
• De même, pour un tri, sort seule suffit si l’on veut changer seulement la clé de tri

9.2.2.3.3 setLine

Un des concepts du socle technique d’ACE, est d’affecter la propriété « current » à un Row, afin d’exécuter les Vues filles pour la ligne courante, dans une présentation « maître-détail » à l’écran (voir par ailleurs l’utilisation de la propriété verboseDetail des Views composites).

L’action setLine, permet de positionner cette propriété à « true » sur un Row à la fois par vue ; on travaille en relatif par rapport à la « page courante » (voir concepts de pagination dans ACE).

• Syntaxe : setLine(viewRef, index)
• Paramètres obligatoires :
• viewRef : Nom de la Vue
• index : indice du Row dans la page courante
• Remarque :
• On travaille sur la BV courante

9.2.2.3.4 firstLine, lastLine

Les actions « firstLine » et « lastLine » permettent de positionner en « Row courant » (voir point précédent) la première ou la dernière ligne de la page courante.

• Syntaxes : firstLine(viewRef) / lastLine(viewRef)
• Paramètres obligatoires :
• viewRef : Nom de la Vue
• Remarque :
• On travaille sur la BV courante et la page courante : si on a plusieurs page et que l’on souhaite atteindre la dernière ligne du RowSet, il faudra s’assurer de faire un lastPage avant.

9.2.2.3.5 previousLine, nextLine

« previousLine » et « nextLine » sont basées sur le même principe, relativement au « Row courant » dans la vue : « ligne précédente » et « ligne suivante ».

• Syntaxes : previousLine(viewRef, interval) : nextLine(viewRef, interval)
• Paramètres obligatoires :
• viewRef : Nom de la Vue
• intervalle : nombre de ligne séparant la ligne courante du Row cible
• Remarque :
• On travaille sur la BV courante

9.2.2.3.6 setBusinessLine

L’action « setBusinessLine » à la même finalité que l’action « setLine », à la différence que l’on travaille par rapport au Document complet, et non à la page (on pourra se baser sur l’attribut « @business_row_index » d’un Row) : positionnement absolu du curseur dans le Document.

• Syntaxe : setBusinessLine(viewRef, business_row_index)
• Paramètres obligatoires :
• viewRef : Nom de la Vue
• business_row_index : indice du Row par rapport au RowSet du Document
• Remarques :
• On travaille sur la BV courante
• L’attribut @business_row_index représente l’index du Row cible par rapport à sa position dans le RowSet : fonctionnement étendu de setLine.

9.2.2.3.7 setPage

Nous ne l’avons pas évoqué, mais cela fait partie des prés requis sur l’application pour comprendre ce document, une vue pouvant ramener une infinité de lignes, et pour des raisons évidentes, l’affichage étant limité à l’écran à un nombre défini de lignes, il était nécessaire de pouvoir naviguer sur le contenu global d’un document, comme si l’on feuilletait les pages d’un livre.

L’action « setPage » permet de définir quelle est la « page » courante dans le document, le groupe de Rows à traiter à l’écran (on avait déjà évoqué la limite de travail de certaines actions dans la page courante).

• Syntaxe : setPage(viewRef, index)
• Paramètres obligatoires :
• viewRef : Nom de la Vue
• index : index de la page cible
• Remarques :
• On travaille sur la BV courante
• Le Row courant après opération sera celui à l’indice dans la page précédente (si le Row courant était la deuxième ligne de la page, il en sera de même sur la nouvelle)

9.2.2.3.8 firstPage, lastPage

Comme pour les actions sur les lignes, « firstPage » et « lastPage » permettent d’affecter directement la première ou dernière page en page courante.

• Syntaxe : firstPage(viewRef) / lastPage(viewRef)
• Paramètre obligatoire : viewRef : Nom de la Vue
• Remarques :
• On travaille sur la BV courante
• Ceci équivaut à setPage, mais on se passe de préciser l’index exact
• Même comportement que précédemment pour le Row courant

9.2.2.3.9 previousPage, nextPage

De même, « previousPage » et « nextPage » demandent la page précédente ou suivante en relatif par rapport à la page courante.

• Syntaxe : previousPage(viewRef, intervalle) / nextPage(viewRef, intervalle)
• Paramètres obligatoires :
• viewRef : Nom de la Vue
• intervalle : nombre de ligne séparant la ligne courante du Row cible
• Remarque :
• On travaille sur la BV courante

9.2.2.3.10 linePage

L’action « linePage » permet elle, de redéfinir le nombre de lignes à afficher par page, depuis la couche de présentation, si on veut modifier la valeur positionnée sur la vue dans la ViewStruct ainsi que le MaxFetchSize pour la Vue ciblée.

• Syntaxe : linePage(viewRef [,rows] [,maxFetchSize])
• Paramètre obligatoire : viewRef : Nom de la Vue
• Paramètres optionnels :
• rows : nombre de ligne à afficher par page
• maxFetchSize : nombre de lignes maximum ramenées par la vue
• Remarques :
• On travaille sur la BV courante
• Une limite au nombre maximal de lignes existe toutefois, voir par ailleurs dans les propriétés techniques définies dans ACE.porperties.xml

9.2.2.3.11 scrollPage

L’action « scrollPage » sert à « décaler » d’un nombre de ligne passé en paramètre, le contenu de la page courante, mais sans en modifier son état :

« scrollPage » est une action à manipuler avec précaution : prenons l’exemple de son l’utilisation suivie de « nextPage » : on affichera la seconde page (par rapport à l’état initial) et non la troisième ou la suite de la visualisation courante avec le décalage de lignes. (scrollPage ayant affiché une partie de la seconde page, mais sans affecter l’état de la page 1)

• Syntaxe : scrollPage(viewRef , decalageLignes)
• Paramètres obligatoires :
• viewRef : Nom de la Vue
• decalageLignes : nombre de lignes à décaler
• Remarques :
• On travaille sur la BV courante
• On ne modifie pas l’état de la page courante
• L’unité est bien les lignes, l’effet se situe au niveau page

9.2.2.4 Les macros actions

Nous avons présenté les actions élémentaires permettant de traiter tous les besoins de cinématique, nous allons détailler en dernière partie du référentiel des actions de cinématique, les macros actions, qui représentent les combinaisons d’actions les plus courantes.

Nous rappelons que l’utilisation des macros actions est bien sûr préconisée en lieu et place des combinaisons des actions « élémentaires » lorsque c’est possible.

9.2.2.4.1 select

L’action « select » est composée de « retrieve » et « display », elle représente le traitement minimal affecté à l’affichage d’un page :

• sélection des clés de retrieve par Vue
• positionnement de la BusinessView demandée en BV « courante », pour rendu de l’affichage par le socle

• Syntaxe : select(BVRef [,keyRef]) = retrieve(BVRef [,keyRef]) ;display(BVRef)
• Paramètre obligatoire : BVRef : index BusinessView
• Paramètre optionnel : keyRef : clé de retrieve
• Remarques :
• On doit utiliser select lorsque aucun tri de donnée n’est nécessaire dans la BV appelée (on rappelle que les BusinessFlow ne sont pas concernés par les clés publiques de tris)
• On ne travaille pas forcément par rapport à la BV courante, donc on peut avoir plusieurs fois « select » si on travaille sur plusieurs BV en même temps
• L’action « select » est composée de display, elle permet donc d’affecter la BV demandée en BV courante

9.2.2.4.2 forward

L’action forward représente le couple « init » et « display », soit en réalité le triplet « retrieve », « sort » et « display ».

• Syntaxe : forward(BVRef [,keyRef] [,sortRef])

= retrieve(BVRef [,keyRef]);sort(BVRef [,sortRef]);display(BVRef)

• Paramètre obligatoire : BVRef : index BusinessView
• Paramètres optionnels :
• keyRef : clé de retrieve
• sortRef : clé de tri
• Remarques :
• « forward » permet de déclencher la sélection des clés de retrieve, des clés de tri et de définir la BV « courante » : si aucun tri de données n’est attendu, « select » devrait être privilégiée.
• Au sein d’une BV courante (par ex. pour un formulaire de modification), son utilisation ne garantit pas le bon fonctionnement de la page.

9.2.2.4.3 top

L’action « top » permet de déplacer la ligne courante d’un document au tout début du contenu de ce dernier au delà de la « page courante » : elle représente la combinaison « firstPage » et « firstLine » (on change d’abord de page pour obtenir la première puis la première ligne de celle-ci).

• Syntaxe : top(viewRef)
• Paramètre obligatoire : viewRef : nom de la vue

9.2.2.4.4 bottom

L’action « bottom » fait la même chose, dans l’autre sens.

• Syntaxe : top(viewRef)
• Paramètre obligatoire : viewRef : nom de la vue
• Remarque :
• Si la dernière page de la collection comporte un nombre de lignes plus petit que le nombre de lignes à afficher par pages, il apparaît un effet de bord identique à celui de « scrollPage » et le résultat produit est différent de « lastPage »

9.2.2.4.5 integrate

L’action integrate remplace le couple « propose » et « assimilate ».

• Syntaxe : integrate(BVRef) = propose(BVRef);assimilate()
• Paramètre obligatoire : BVRef : index BusinessView
• Remarque :
• « propose » et « assimilate » ne sont pas forcément associées à la suite dans le cas ou l’on veut travailler sur plusieurs BV en même temps :
• Si la BV courante représente une liste et que l’on veut ajouter une nouvelle donnée dans cette liste, on peut très bien réaliser ceci :

« view=BV_CREATION&cinematic=propose(1) ;display(1) ;assimilate() ;display(0)&frame=ctx »

• « view » est utilisé car on travaille sur plusieurs BV
• Implicitement, on est déjà sur la page de liste, en BV courante
• On appelle la BV pour laquelle on pourra faire de la création
• On utilise donc bien « propose » et « assimilate », mais avec un « display » entre les 2 : « display » permet de passer BV_CREATION en BV courante temporairement pour y faire « assimilate », puis on refait un display(0) pour rendre la BV qui était courante à nouveau courante : afficher la liste en fin de traitement
• On n’a pas introduit l’utilisation de « invalidate » ici volontairement afin de simplifier l’exemple, mais elle serait nécessaire afin de bien faire apparaître dans la liste la nouvelle lignée créée, et ce, après « display(0) », « invalidate » étant également « contextuelle » comme assimilate.

9.3 Utilisation

Nous avons dressé la liste des actions de cinématique proposées par le socle technique d’ACE, maintenant nous allons montrer les différents cas d’application en fonction des besoins réels dans l’application.

Nous ne présenterons pas dans ce contenu l’utilisation des les actions « techniques », celles-ci étant particulières et pas utilisées par les scénarii métiers (« login », « logout », « killSession » et « killContext » étant utilisées dans des méthodes JavaScript, leur implémentation est gérée de manière générique).

9.3.1 Rappels

En préambule aux cas d’application, nous allons rappeler les composants d’une URL pour l’application ACE et ce que cela induit pour les actions.

9.3.1.1 Le contexte applicatif

Nous avons vu que nous pouvions avoir plusieurs BV au sein d’un même contexte applicatif.

Le contexte applicatif comprend :

• un ensemble de BusinessView (1 à n)
• une cible de paramétrage, associée à la BV courante

Le contexte applicatif est identifié sur l’URL par son nom dont la valeur est portée par le paramètre « frame ». A défaut de cette précision, le nom « default » sera utilisé (il devient donc redondant d’utiliser « default » comme valeur pour nom de contexte dans le code).

L’utilisation du paramètre « frame » sur une URL, en l’absence de précision de nom de BusinessView permet de récupérer le contexte et de travailler par défaut sur la BV courante de ce même contexte.

Remarque : si aucune opération de mise à jour, suppression, création, tri, navigation n’est à prévoir dans la page appelée, alors il faut préconiser l’utilisation du contexte « default »

9.3.1.2 BusinessView

Nous venons de voir que le nom d’une BusinessView n’est pas obligatoire sur une URL : si l’on travaille sur une BV courante (page de modification par exemple), alors le paramètre « frame » seul suffira sur l’URL envoyée au serveur pour retrouver le contexte applicatif et donc la BV courante pour la requête.

Hormis ce cas particulier, nous devons préciser le nom d’au moins une BV au sein d’une requête, et pour ce faire, il existe deux paramètres utilisés par le socle, à des fins distinctes.

9.3.1.2.1 sourceview

Il s’agit du paramètre le plus souvent utilisé pour nommer la BV demandée via la requête.

Associé au paramètre « frame » sur une URL, il désigne implicitement que la BV sera la « courante » dans le contexte applicatif créé / mis à jour. Ceci implique que les cinematic alors utilisée s’adresseront à la « BV courante », comme « retrieve(0) », « sort(0) », display(0) …

« sourceview » ne permet que d’adresser une seule BusinessView par requête, d’où l’apparition du paramètre « view » pour répondre aux autres cas.

9.3.1.2.2 view

Nous venons d’en parler, « view » est utilisé pour les cas ou l’on souhaite travailler sur plusieurs BV dans un même contexte, ou bien lorsque l’on veut changer de page après une opération sur la page courante directement, sans avoir à utiliser des rechargements de pages.

La valeur du paramètre correspond à la ou les BV sur lesquelles on veut agir, séparées par des « ; ». Les BV seront identifiées par rapport à leur position dans cette chaîne, en partant de 1 (0 reste la référence à la BV courante).

9.3.2 Afficher une nouvelle BusinessView

La première étape pour le traitement des données, avant de présenter les cinématiques d’actions permettant de créer, mettre à jour ou supprimer, consiste à obtenir la présentation du résultat d’une BusinessView.

La première action à utiliser sur une nouvelle BV est « retrieve », et la dernière « display ».

9.3.2.1 Afficher une nouvelle page

Nous allons voir les différents cas représentés par l’affichage d’une nouvelle page.

Nous sommes ici dans le cas ou la BV attendue n’a pas encore été appelée pour un contexte donné, elle n’est donc pas courante.

On rappelle que les opérations minimales pour ces cas là sont « retrieve » et « display » ; on présentera toujours d’abord les actions élémentaires pour être le plus explicite, les macros actions doivent être néanmoins utilisées en priorité lorsque possible.

9.3.2.1.1 Ouvrir un portail

Les portails s’ouvrent normalement dans le contexte « default », il s’agit de BusinessView ne nécessitant pas de demeurer en mémoire, on n’aura pas de manipulations des données.

Le plus souvent, ouvrir un portail implique l’utilisation d’une BusinessView pour laquelle il y aura production d’une frameset en HTML, ces pages là dans la grand majorité des cas n’impliquent pas de trier les données : « retrieve » et « display » suffisent.

On utilisera donc :

• sourceview=BVRef
• select(0)
• Remarques :
• Comme on utilise « sourceview » le « display » est implicite pour rendre la BV « courante », on choisira néanmoins de rendre son utilisation explicite en utilisant l’action.
• On utilisera forward(0) pour les BV qui nécessiteront des tris
• On ne présente pas et ce, volontairement, l’utilisation des paramètres optionnels de « retrieve » ou « sort », pour utilisation des clés publiques définies dans la ViewStruct

9.3.2.1.2 Ouvrir un pop-up

Les pop-up de recherches s’ouvrent de la même manière qu’un portail, à la différence près que souvent ces pages là sont composées de Vues nécessitant des tris : il incombe que l’on utilisera donc le plus souvent forward(0) directement.

• Remarques :
• Les nouveautés du socle, notamment l’utilisation des BusinessFlow, ne sont pas concernées par l’activation des tris via clé publique, pour un pop-up composé uniquement de liste déroulantes alimentées par BF, select(0) suffit.
• Si la liste des éléments à rechercher fait partie de la même BV que le pop-up de recherche, alors il faudra utiliser « sort » au moins, depuis le formulaire de recherche, mais cela concerne le cas de travail dans une BusinessView courante, que nous verrons ensuite.

9.3.2.1.3 Afficher les pages du portail

Une fois le frameset généré en HTML, il est question d’afficher les pages composant le portail. Ces pages là sont le plus souvent :

• Une page de recherche
• Une page détail d’un élément pour modification

Là encore nous appliquerons la même logique que pour les cas précédents :

• On utilise sourceview
• On utilise « display » malgré la référence implicite de « sourceview »
• Aucune vue ne nécessitant de tri : select(0)
• Au moins une vue avec un tri par défaut : forward(0)
• On utilise un nom de contexte si possible unique, afin de pouvoir manipuler dans un second temps les données (API, modification, suppression, tri …)

9.3.2.1.4 Changer la page courante

Toujours dans le cadre d’un portail, il arrive que pour une frame que l’on associe souvent à une frame pour limiter le nombre de contextes créés, l’on veuille charger un autre contenu :

• Utilisation d’un lien / onglet
• Rechargement de la page suite à une opération de validation par exemple
• On bascule vers une nouvelle page après traitements dans la page courante

Pour les deux premiers exemples, on applique encore la même règle jusqu’à présent :

• Utilisation de sourceview et de select ou forward

Pour le troisième exemple, il existe deux écoles :

• La validation/modification des données se fait dans la page, puis la feuille de style identifie par le flux de données l’application de traitements et demande le rechargement dans le contexte courant d’une nouvelle BV :
• On utilisera un chargement simple de la nouvelle BV, en BV courante toujours avec « select » ou « forward »
• La validation ou modification des données se fait toujours dans la même page, mais on choisit de travailler sur plusieurs BV dans la même requête (on reprendra cet exemple pour les cas de création ou de mise à jour des données et le travail sur une BV courante)
• On utilisera donc cette fois le paramètre « view=BVCible »
• Pour la mise à jour ou utilisation d’API, on aura d’abord « propose(0) ;assimilate », en réalité il faut utiliser « integrate(0) » (les traitements se font sur la BV courante)
• On ajoute enfin « select(1) » ou « forward(1) » (si tri attendu). 1 fait référence à la première BV pour le paramètre « view », soit notre « BVCible », la nouvelle page à afficher.

9.3.2.2 Atteindre une nouvelle page avec traitements avant l’affichage

Nous avons vu le cas le plus simple, afficher une nouvelle page, avec les options par défaut « retrieve » et « sort ».

Maintenant nous allons voir quels sont les cas étendus, nécessitant des opérations particulières avant affichage de la page.

9.3.2.2.1 Sélection de Clé de retrieve autre que celle par défaut

• Utilisation de sourceview
• select(0,keyRef)

9.3.2.2.2 Sélection de Clé de tri autre que celle par défaut

• Utilisation de sourceview
• forward(0,keyRef,sortRef) si on veut combiner avec le point précédent
• retrieve(0) ;sort(0,sortRef) ;display(0) pour tri particulier et clé de retrieve par défaut

9.3.2.2.3 Création avant affichage

• Utilisation de sourceview
• retrieve(0);display(0);create(0);propose(0);assimilate()
• select(0) ;create(0);propose(0);assimilate()
• select(0) ;create(0);integrate(0)
• si création en CRUD
• select(0) ;create(0);integrate(0); invalidate(viewRef)
• si création en CRUD
• on ne tri pas forcément, le « invalidate » est présent afin de faire apparaître le Row nouvellement créé dans le RowSet d’une Vue « liste »
• select(0);integrate(0)
• si création via API
• le fonctionnement est similaire aux cas précédents, on ne reprend pas toutes la déclinaison des combinaisons possibles, il faut s’en inspirer.
• Remarques :
• « assimilate » travaille par défaut ici sur la BV courante, c’est pourquoi le « display » doit être fait avant.
• On parle bien d’ « assimilate », implicitement définie par « integrate »

9.3.2.2.4 Mise à jour avant affichage

• select(0);integrate(0)

9.3.2.2.5 Suppression avant affichage

• Utilisation de sourceview
• select(0);delete()
• forward(0);delete()
• suppression en CRUD
• select(0);integrate(0) / forward(0);integrate(0)
• suppression via API
• Remarques :
• L’utilisation de invalidate n’est pas nécessaire avec « delete() », on n’a pas besoin de recharger le RowSet puisque la suppression se fait nécessairement dans ce dernier
• On aurait pu également présenter des combinaisons avec des tris ou autres opérations, mais cela alourdirait la compréhension de cet exemple
• L’utilisation de « delete » va de pair avec l’utilisation de « sel : viewRef=on».

9.3.2.2.6 Modification d’un Row avant affichage

• Utilisation de sourceview
• select(0);integrate(0)
• Remarques :
• On peut utiliser forward(0) au lieu de select si l’on doit trier les données avant la modification
• Les display(0) ou forward(0) après « integrate » sont interdits, cela n’a pas de sens et peux même provoquer des disfonctionnements.

9.3.2.2.7 Fixer le Row courant avant affichage

• Utilisation de sourceview
• select(0);setLine(params)
• on travaille sur la page courante (la première par défaut)
• select(0);firstLine(params)
• select(0);lastLine(params)
• select(0);setBusinessLine(params)
• select(0);top(params)
• …
• Remarques :
• En règle générale on affecte la BV cible en BV courante avant de pouvoir travailler sur les Row « courants »
• Se référer aux définitions des différentes actions pour la liste des paramètres à passer

9.3.2.2.8 Fixer une page « courante » avant affichage

• Utilisation de sourceview
• select(0);setPage(params)
• …
• Remarques
• Comme pour les opérations sur les Rows, il faut d’abord positionner la BV en « courante »

9.3.3 Travailler sur la BusinessView « courante »

Nous avons vu les différents cas d’utilisation et les possibilités offertes par la solution appliquées à l’affichage d’une page. Nous allons étudier maintenant ces mêmes possibilités mais dans un cadre d’utilisation qui diffère quelque peu : la page est déjà affichée, et nous travaillons sur la BV courante.

Nous avons vu que l’action « display » servait notamment à positionner une BV en « courante », c’est pourquoi dans les exemples qui vont suivre, nous ne verrons plus les mêmes combinaisons d’actions que précédemment, et nous étudierons les finesses de l’utilisation de plusieurs BV dans une même requête.

L’utilisation du paramètre « frame », soit du contexte applicatif donne toute son importance ici, puisque dans la majorité des cas, le nom de la BV ne sera plus fournit sur l’URL.

• retrieve(0) n’est plus utilisé (sauf si un changement de clé de retrieve est voulu)
• display(0) ne doit plus être utilisé
• par extension, select(0) non plus
• ni forward(0)

9.3.3.1 Travail uniquement sur la page courante

Nous allons voir ici les différentes opérations probables pour recharger un contexte avec une présentation différente : nous travaillons à chaque fois sur la même BusinessView déjà chargée.

• Remarque :
• il faut toutefois prendre la précaution de rappeler les paramètres publics nécessaires à la bonne exécution de la requête

9.3.3.1.1 Changer de clé de retrieve

Pour présenter des données différemment en fonction de règles métier par exemple, il est parfois nécessaire d’activer une clé de retrieve plutôt qu’une autre.

• Le nom de la BusinessView n’est plus nécessaire : il faut simplement rappeler le paramètre « frame » avec la valeur du contexte courant, correspondant à la frame (au sens HTML) de travail
• retrieve(0,keyRef) suffit

9.3.3.1.2 Changer d’ordre de tri

On applique la même logique de fonctionnement que pour retrieve

• sort(0,sortRef)
• init(0,keyRef, sortRef) : si l’on veut changer de clé retrieve et de clé de tri

9.3.3.1.3 Créer

• create(0);integrate(0)
• Création en CRUD
• integrate(0)
• création via API
• Remarques :
• Si le Row créé doit apparaître dans un RowSet de la page courante, alors il conviendra d’utiliser « invalidate » après la cinématique de création.

9.3.3.1.4 Mettre à jour

• integrate(0)
• Mise à jour en CRUD
• Remarques :
• Inutile (comme souvent observé) d’utiliser display, invalidate ou forward. Les deux premiers sont superflus, et le dernier peut amener des disfonctionnements (utilisation des clés de tri par défaut, alors que le tri « courant » est autre)

9.3.3.1.5 Supprimer

• delete()
• suppression en CRUD
• integrate(0)
• suppression via API
• Remarques :
• Dans le cas d’une suppression via API, si la page courante liste des données dont l’une est supprimée, alors un « invalidate » peut être nécessaire. La suppression en CRUD en différente, le cas usuel visant à supprimer « sur la liste », la ligne disparaît du RowSet, le rechargement de ce dernier n’est pas nécessaire.

9.3.3.1.6 Changer de Row courant

• setLine(params)
• setBusinessLine(params)
• nextLine(params)
• …
• Remarques :
• Cela ne diffère que très peu finalement des cas où l’on souhaite réaliser ces opérations avant affichage de la page

9.3.3.1.7 Changer de « page courante »

• scrollPage(params)
• linePage(params)
• ….
• Remarques :
• Même comportement que pour le travail sur le Row courant

9.3.3.1.8 Recharger la page

Il est très fréquent dans un scénario de devoir recharger une page : ajout d’un poste dans une commande.

• La création d’un poste se passe dans une frame (au sens HTML) dédiée
• On n’y fait généralement que integrate(0)
• Après création du poste, la feuille de style demande le rechargement de la frame des postes, pour y visualiser l’ajout
• Comme le contexte des postes est créé et maintenu en mémoire (nécessité due aux opérations de tris sur les colonnes, suppression des lignes, modifications…), il n’est pas nécessaire de demander le rechargement de cette page via « forward(0) » comme c’est souvent le cas, un simple « invalidate » sur la Vue des postes suffit à rafraîchir cette page car :
• La frame des postes correspond à un contexte pour lequel la BV courante est la page affichant les postes, donc pas de « retrieve » ni de « display » nécessaires.
• En principe on ne souhaite pas changer le tri « courant » ; forward(0) utilisera le tri par défaut, et donc un tri différent de celui potentiellement choisi par l’utilisateur
• Invalidate demande simplement le rechargement du RowSet par rapport aux dernières opérations demandées sur l’avant dernière requête (dernier tri, dernière page demandée …).

9.3.3.2 Travail sur plusieurs BV

On l’a vu, pour ce faire il faut utiliser le paramètre « view », et lui donner en valeur la liste des BusinessView à traiter, dans l’ordre voulu.

Les cas d’utilisation sont :

• Travail sur la BusinessView courante, et affichage d’une autre
• Travail sur une autre BV, puis afficher à nouveau la page courante
• Ou tout autre forme de combinaison, mais les deux exemples cités permettront d’orienter correctement tout cas spécifique.

9.3.3.2.1 Travail sur la BV courante et afficher une nouvelle page

Les différents traitements possibles sur la BV courante ont été vus dans le chapitre précédent, nous ne reprendrons pas l’exhaustivité des cas d’illustrations, nous allons nous baser sur le cas le plus courant probablement : mettre à jour des données et passer à une autre page dans le scénario.

• Utilisation du paramètre « view=BVCible »
• Implicitement on travaille sur la BV courante : le paramètre frame doit rester « invariable »
• integrate(0);select(1)
• integrate(0) fait de la mise à jour sur la BV à l’indice 0 : la courante
• select(1) fait un retrieve puis display sur la BV à l’indice 1, la première BV dans la valeur affectée au paramètre « view »
• le résultat est bien une mise à jour sur la BV courante (page affichée pour l’utilisateur) et une l’affichage de la BV suivante sera rendu.

9.3.3.2.2 Travail sur une autre BV et continuer d’afficher la page courante

Prenons l’exemple suivant : on veut créer une nouvelle ligne (via API) dans une liste affichée à l’écran, et faire apparaître cette nouvelle donnée dans la liste.

Il existe bien deux manière pour réaliser ceci :

• Dans la grande très majorité des cas, on a choisi de créer un Row dans la BV courante, puis de réafficher la page après réactualisation de la Vue « liste » : on est dans le cas d’une création sur la page courante, comme en 3.3.1.3, soit integrate(0);invalidate(VueListe)

• La seconde manière de faire aurait permis de simplifier la ViewStruct gérant la liste des données d’une part, et de rendre disponible sous forme de « service » une ViewStruct dédiée uniquement à faire de la création pour d’autres scénarii.

Nous allons voir comment on implémente cela :

• view=BVCreation
• select(1) ;integrate(1) ;display(0) ;invalidate(VueListe)
• si l’on créé en CRUD, penser à ajouter create(1) avant integrate
• 1 fait référence à « BVCreation »
• On est obligé de faire retrieve pour la nouvelle BV encore inexistante dans le contexte
• On fait un display(1) également pour pouvoir utiliser assimilate() sur la BV « 1 », retrieve+display=select.
• On souhaite rester sur la page courante, il faut donc refaire display mais sur « 0 » cette fois (select(1) à positionné la BV « 1 » en courante)
• L’ « invalidate » sert simplement à recharger le RowSet de VueListe.
• Remarque : pour une suppression, l’invalidate n’est pas nécessaire, même si on travaille sur une autre BV (propre au fonctionnement des BC4J)

9.3.4 Utiliser Ajax

L’utilisation d’Ajax permet de ne pas réafficher la page courante pour en modifier son contenu, toutefois l’opération est similaire à « afficher une nouvelle BusinessView » car le socle doit fournir la présentation du résultat du la requête, et les requêtes « Ajax » se feront par préconisation toujours dans un autre contexte que la page « courante ».

10 LOG4J : Document de référence

10.1 Objectif

Ce document a plusieurs objectifs :

• Définir les concepts de LOG4J.
• Montrer son intégration dans le mode web
• Présenter les paramétrages proposés par le mode web
• Proposer différents paramétrages types pour illustrer son utilisation.

10.2 Présentation de LOG4J

10.2.1 Le concept

LOG4J est un framework de trace. Ce framework répond d'un point de vue très générique et paramétrable à la problématique des traces.

Ce qui permet notamment de paramétrer

• ce que l'on veut tracer (Logger ),
• le support qui recevra la trace (Appender )
• et la mise en forme de la trace (Layout )

Ce framework Open Source existe depuis octobre 1999 et est utilisé dans de grands projets Open Source.

10.2.2 Les briques de base

Le concept de Log4J se compose de trois briques de base :

• logger qui représentent des catégories de traces, caractérisées par :
• un nom : qui peut être hiérarchique, similaire aux package et à la classe émettrice de la trace (fr.ACE.technicalframework.application.ServletControl ), ou autonome (activiteTimer). Par défaut tous les messages envoyés à un logger fils sont envoyés à son père.
• un niveau (ALL, TRACE, INFO, DEBUG, WARN, ERROR, FATAL, OFF) optionnel car un logger hérite du niveau de son père.
• appender qui représentent des destinations de trace (console, fichier, composants d'IHM, sockets, destinations JMS, journal d'événements de NT, démons Unix Syslog ou autre). Par ce biais on peut également tracer de manière synchrone ou asynchrone. Les appender référencent :
• layout qui définit le format d'écriture d'un appender (syntaxe à la printf du C)

10.2.3 L’articulation entre les briques LOG4J

• Voici une illustration de l’articulation entre les briques :

Le code JAVA fait appel à un logger pour générer une trace. Ce logger transmet la demande à un ou des Appender/Layout pour mettre en forme et écrire la trace dans le support de sortie.

Pour faciliter la lecture et utiliser un mot français, nous utiliserons le terme "trace" pour désigner cette idée.

10.2.4 Les niveaux de trace :

• TRACE: Niveau le plus fin. Messages orientés pour l'utilisation des développeurs, couramment utilisés pendant la phase de développement du produit.

• DEBUG : Message d’informations destinées au développement et au support du produit, lors de la phase de recherche d’anomalie chez les clients ou en interne.

• INFO: Messages d'informations utiles telles que changement d'état, connexion d'un client, identification d'un utilisateur, etc.

• WARN: Un problème ou un conflit a eu lieu, mais il n'est pas bloquant pour la continuité du traitement. Cependant, cela peut être le début d'une erreur plus grave.

• ERROR: Un problème a eu lieu, mais n'est pas bloquant. Le système continuera de fonctionner.

• FATAL: Un événement a causé l'arrêt complet du système. Ce niveau indique qu'un administrateur doit redémarrer le système et corriger la cause de l'arrêt.

10.2.5 Illustration des concepts de base

10.2.5.1 Les logger

Cette vision graphique des logger montre les deux types :

• Tout d’abord les logger ayant un nom hiérarchique (on reconnaitra l’arborescence de quelques package du technicalframework ),
• Puis des traces nommées, dites "transversales" pour répondre à des besoins particuliers, nommée ici *Timer

10.2.5.2 Les Appender, layout et niveaux de traces

Dans l'exemple de trace suivant, chaque ligne de trace comprend la date, le niveau et le message. C'est extrait d'une trace générée par un appender de type fichier texte. Le contenu de cette trace est obtenu grâce au layout.

[2003-06-12 15:00:17,141] WARN - GnxViewObjectImpl.clearcache() : Fin trace de clearCache.

[2003-06-12 15:00:17,141] DEBUG - BusinessFacade.checkConnectionDataBase : tentative de reconnection.

[2003-06-12 15:00:17,297] DEBUG - BusinessFacade.checkConnectionDataBase : reconnection de la session métier.

[2003-06-12 15:00:17,297] DEBUG - BusinessViewProxy.setTransactionState : BVname=W_MENU_F;valeurTransac=2

[2003-06-12 15:00:17,328] INFO - TraceReload.execute() : chargement de file:/C:/Oracle/OC4J902/Complet/j2ee/home/default-web-app/SocleTechCourant/btoc/develop_log4j.xml

[2003-06-12 15:01:52,516] FATAL - Processus.initCaches() : Mode de gestion des caches : false

10.3 Paramétrage et intégration de LOG4J

10.3.1 Reprise de l'existant

Avant l’utilisation de LOG4J, le mode web utilisait un système de trace basique à deux niveaux non configurable.

Avant la GCE130, toutes les traces java n’étaient pas encore passées sous LOG4J. Elles correspondaient à un logger nommé "log_deprecated".

A partir de la GCE130, toutes les traces utilisent le framework LOG4J.

10.3.2 Emplacement du fichier de configuration de log4J

Le framework de trace (Log4j) est paramétrable par un fichier de configuration qui accompagne la livraison du logiciel.

Pour des raisons de déploiement sur site, l'emplacement privilégié pour placer le fichier de configuration du mode web est la racine du web module. L’emplacement et le nom du fichier se spécifie dans le fichier de paramétrage technique ACE.properties.xml, section log4j.

Exemple de configuration :

< log4j >

< file name =" log4j/exploit_log4j.xml "/>

</ log4j >

Pour le mode web, il a été retenu la version XML du fichier de configuration.

Nous allons voir le contenu de ce fichier. Il possède des éléments indispensables au bon fonctionnement du framework LOG4J ainsi que des particularités propre au mode web.

10.3.3 Les logger

Il y a un logger par défaut qui doit toujours être disponible, c'est le logger root.

10.3.3.1 Le logger root

Les autres logger sont fils de ce root. Donc toutes les traces qui ne trouvent pas leur logger correspondant iront dans le logger root ou le premier logger correspondant dans la hiérarchie des logger.

• Exemple de définition du logger root :

< root >

< level value =" error "/>

< appender-ref ref =" egxAppender "/>

</ root >

• Description des nœuds et attributs :

• Exemple de définition d'un logger autre que root :

< logger name =" activite " additivity =" false ">

< priority value =" debug "/>

< appender-ref ref =" activite "/>

< appender-ref ref =" egx "/>

</ logger >

• Description des nœuds et attributs :

Afin de dispatcher les traces dans différents supports (différents fichiers log par exemple), il faut définir des logger. Le nombre de logger n’est pas limité.

10.3.3.2 Les logger transversaux

En plus des "traditionnelles" traces d'informations ou d'anomalies écrites au fur et à mesure de l'exécution du code, le mode web met à disposition 18 traces transversales divisibles en 3 groupes :

Les traces « data »

Les traces « timer »

Les autres traces.

10.3.3.3 Les logger de type data

Ces logger permettent de suivre les requêtes SQL exécutées en base ou dans les caches de résultat.

Il y a séparation entre chaque type de requêtes : select, update, insert, delete. Les select sont eux-mêmes séparés en deux logger : les select issus des ViewObject standards et ceux issus des ViewObject dynamiques.

10.3.3.4 Les logger de type timer

Ce graphe illustre l’enchainement et les chevauchements éventuels des timers.

Global Request Timer

Servlet initParam Timer

Servlet Uuid Timer

Servlet GetPro. Timer

Request Timer

Auth. Timer

Parsing Request Timer

Build BV Timer

Build View Timer

Processus Listener Timer

Trans. Timer

action Timer

xmlPres Begin Timer

Business Flow Timer

view Timer

buildVO Timer

buildAM Timer

API Timer

Render Output Timer

xslt Timer

Servlet Init Header Timer

Servlet Flush Out Timer

1-D

2-D 3-F

4-D

5-F

6-D 7-F (*7)

8-D

11-D 12-F

15-D 16-F

23-D

24-F (BV) 25-D (VS)

9-D 10-F(*0) 17-D 18-F(*0)

13-D 14-F 21-D 22-F

19-D 20-F (*1)

67-F

62-F

40-D 41-F

29-F

26-F (VS) 27-D (n*V) 28-F (n*V)

38-D 39-F 54-D 55-F 60-D 61-F

42-D 43-F 52-D 53-F

30-D 37-F

44-D 45-F

46-D 47-F (*5)

48-D 51-F (*6)

31-D (*2) 32-F 49-D 50-F

33-D (*3) 34-F

35-D 36-F (*4)

56-D 59-F

57-D 58-F

63-D 64-F

65-D 66-F

Légende :

D : début du chrono

F : fin du chrono

1, 2, .. Ordre de déclenchement/arrêt des chronos.

Exemple :

30–D début du chrono d’une action

31-D début du chrono de création d’une ViewObject

32–F fin du chrono de création d’une ViewObject

29–F Fin du chrono démarré en 23-D

BV : objet BusinessView.

VS : objet ViewStruct

n*V : construction de n objets View. (Correspond aux nombres d’objets dans la ViewStruct)

(*0) Les listener de Processus peuvent être plusieurs et exécuter des traitements provoquant la construction de composant ViewObject.

(*1) API du socle.

(*2) Construction de ViewObject si action retrieve demandée. (rappel : forward contient retrieve)

(*3) Si Document de type APIDocument

(*4) Si action assimilate sur une API

(*5) Autant de ligne que de businessFlow

(*6) suivent les rowFieldTimer, non représenté ici.

(*7) En cas de nouvelle session http, provoque la création et l’utilisation de BC4J.

10.3.3.5 Les loggers transversaux divers :

10.3.4 Les appender

LOG4J met à notre disposition un nombre considérable de supports de sortie pour les traces.

10.3.4.1 Les Appender disponibles

Seul les ConsoleAppender, RollingFileAppender, DailyRollingFileAppender et LF5Appender ont été utilisés par le socle technique.

Remarque : il est possible d’écrire son propre appender. C’est une classe java qui respecte l’interface org.apache.log4j.Appender.

Diagramme de classe de quelques appender :

10.3.4.2 Principe de définition d'un appender

< appender name =" nomDuappender " class =" org.apache.log4j.NomClasseappender ">

< param name =" nomDuParam1 " value =" valeurDuParam1 "/>

< param name =" nomDuParam2 " value =" valeurDuParam2' "/>

…

< param name =" nomDuParamN " value =" valeurDuParamN "/>

</ appender >

Description des nœuds et des attributs :

10.3.4.3 Le paramétrage des appender de base

Nous ne présentons que les appender de type écriture dans un fichier. Pour plus d'informations, se référer à la documentation de Log4J.

10.3.4.3.1 Fileappender

Exemple de paramétrage :

< appender name =" egx.log " class =" org.apache.log4j. Fileappender ">

< param name =" File " value =" log/egx.log "/>

< param name =" Append " value =" true "/>

< param name =" ImmediateFlush " value =" false "/>

</ appender >

Les paramètres disponibles :

10.3.4.3.2 RollingFileappender

Particularité :

Fait un backup du fichier courant quand ce dernier a atteint une taille limite.

Exemple de paramétrage :

< appender name =" egx.log " class =" org.apache.log4j.RollingFileappender ">

< param name =" File " value =" log/egx.log "/>

< param name =" MaxFileSize " value =" 2MB "/>

< param name =" MaxBackupIndex " value =" 5 "/>

</ appender >

Les paramètres disponibles :

10.3.4.3.3 DailyRollingFileappender :

Particularité :

Fait un backup selon une périodicité fixée par un pattern.

Exemple de paramétrage :

< appender name =" egx.log " class =" org.apache.log4j.DailyRollingFileappender ">

< param name =" File " value =" log/egx.log "/>

< param name =" DatePattern " value ="'.' yyyy-MM-dd "/>

</ appender >

Les paramètres disponibles :

10.3.5 Les layout

Les layout sont utilisés pour paramétrer le format du flux de sortie. Un layout est toujours associé à un appender.

10.3.5.1 Les Layout disponibles

10.3.5.1.1 Le Patternlayout

Nous présentons le layout le plus utilisé : le Patternlayout.

Sa configuration est proche du traditionnel "printf".

Exemple de paramétrage d'un appender et de son layout associé :

< appender name =" egx.log " class =" org.apache.log4j.DailyRollingFileappender ">

< param name =" File " value =" log/egx.log "/>

< param name =" DatePattern " value ="'.' yyyy-MM-dd "/>

< layout name =" org.apache.log4j.Patternlayout ">

< param name =" ConversionPattern" value =" [%d] %-5p (%t) - %m%n "/>

< /layout >

</ appender >

Le paramètre disponible :

10.3.5.2 L’alimentation du layout :

Les informations disponibles pour alimenter la valeur du paramètre ConversionPattern ont deux origines distinctes :

• Les données standards fournies par LOG4J
• Les données spécifiques fournies par le mode web.

10.3.5.2.1 Les données standards LOG4J :

Tableau des données standards fournies par LOG4J

Exemples de pattern utilisant les données standards log4J :

< layout class =" org.apache.log4j.Patternlayout ">

< param name =" ConversionPattern " value =" %d %-5p [%t] %c %C{3} (%F:%L) - %m\n "/>

</ layout >

< layout name =" org.apache.log4j.Patternlayout ">

< param name =" ConversionPattern" value =" [%d] %-5p (%t) - %m%n "/>

< /layout >

< layout class =" org.apache.log4j.Patternlayout ">

< param name =" ConversionPattern " value =" %t %-5p %c{2} - %m%n "/>

</ layout >

10.3.5.2.2 Les données spécifiques eGX.

En plus des données standards proposées par log4J, le mode web met à disposition des données spécifiques via le MDC (Mapped Data Context).

On peut voir le MDC comme un dictionnaire de données, dépendantes de la session mais pas directement du code qui génère la trace. Au moment du formatage de la trace, le layout va piocher dans le MDC pour compléter la trace.

Les clés d’accès dans le dictionnaire MDC sont des mots clés écrits dans le layout sous la forme suivante :

%X{MOT_CLE}

L’ensemble des données présent dans le MDC n’est pas disponible/valide à tout moment. Par exemple, vouloir connaitre le nom de l’application module en dehors de la trace API_TIMER n’a pas de signification. Les valeurs fournies par le MDC à ce moment là sont soit incorrectes (la dernière valeur chargée, peut-être lors d’une précédente requête), soit non renseignées.

• Remarque sur les informations liées à la taille des flux.

Pour des raisons de performances, par défaut ces informations ne sont pas alimentées.

L’activation de ces informations se fait via le fichier ACE.properties.xml, nœud log/contents

< log >

< contents >

< xmlPresentationSize active =" true "/>

< xmlPresentationNbNode active =" true "/>

< htmlPresentationSize active =" true "/>

</ contents >

</ log >

• Exemples de pattern utilisant les données standards LOG4J et les données accessibles via le MDC :

< layout class =" org.apache.log4j.Patternlayout ">

< param name =" ConversionPattern " value =" [%d] %-5p (%t) - %m %X{UUID} %X{USER} %X{ENTITY} %X{TARGET}%n "/>

</ layout >

< layout class =" org.apache.log4j.Patternlayout ">

< param name =" ConversionPattern " value =" [%d] %-5p (%t) - %m %X{USER} %X{APPMODULE} %X{VIEWOBJECT} %X{DATA}%n "/>

</ layout >

10.4 Les filtres

Log4j donne la possibilité de définir des filtres sur les traces afin d'affiner leurs sélections. Plusieurs filtres peuvent être associés à un appender. Ils seront alors appliqués séquentiellement aux traces.

10.4.1 Les filtres disponibles

10.4.2 Exemples de filtres

10.4.2.1 Filtres sur contenu

Les traces contenant la chaîne ServletControl dans la section message ne passent pas. Les autres sont "neutres" et envoyées aux filtres suivants.

< filter class =" org.apache.log4j.varia.StringMatchFilter ">

< param name =" StringToMatch " value =" ServletControl " />

< param name =" AcceptOnMatch " value =" false " />

</ filter >

Les traces contenant la chaîne ServletControl dans la section message sont écrites dans le log. Les autres sont "neutres" et envoyées aux filtres suivants.

< filter class =" org.apache.log4j.varia.StringMatchFilter ">

< param name =" StringToMatch " value =" ServletControl " />

< param name =" AcceptOnMatch " value =" true " />

</ filter >

10.4.2.2 Filtres sur niveaux

Ne laisse pas passer le niveau DEBUG. Les autres niveaux sont neutres et envoyés au filtre suivant.

< filter class =" org.apache.log4j.varia.LevelMatchFilter ">

< param name =" LevelToMatch " value =" DEBUG "/>

< param name =" AcceptOnMatch " value =" false "/>

</ filter >

Ne Laisse passer que le niveau FATAL. Les autres niveaux sont neutres et envoyés au filtre suivant qui est un DenyAllFilter. Ils sont supprimés par ce dernier.

< filter class =" org.apache.log4j.varia.LevelMatchFilter ">

< param name =" LevelToMatch " value =" FATAL "/>

< param name =" AcceptOnMatch " value =" true "/>

</ filter >

< filter class =" org.apache.log4j.varia.DenyAllFilter "/>

Ne laisser passer que les niveaux INFO et FATAL. Les autres niveaux sont supprimés par le DenyAllFilter.

< filter class =" org.apache.log4j.varia.LevelMatchFilter ">

< param name =" LevelToMatch " value =" INFO "/>

< param name =" AcceptOnMatch " value =" true "/>

</ filter >

< filter class =" org.apache.log4j.varia.LevelMatchFilter ">

< param name =" LevelToMatch " value =" FATAL "/>

< param name =" AcceptOnMatch " value =" true "/>

</ filter >

< filter class =" org.apache.log4j.varia.DenyAllFilter "/>

Ne laisse pas passer les niveaux qui sont en dehors de l'intervalle INFO - ERROR, compris.

Les niveaux de INFO à ERROR, bornes comprises, sont envoyés dans la trace quelque soit la valeur des filtres positionnés après celui là.

< filter class =" org.apache.log4j.varia.LevelRangeFilter ">

< param name =" LevelMin " value =" INFO "/>

< param name =" LevelMax " value =" ERROR "/>

< param name =" AcceptOnMatch " value =" true "/>

</ filter >

Ne laisse pas passer les niveaux qui sont en dehors de l'intervalle INFO - ERROR, compris.

Les niveaux de INFO à ERROR, bornes comprises, sont neutres et envoyés au filtres suivants.

< filter class =" org.apache.log4j.varia.LevelRangeFilter ">

< param name =" LevelMin " value =" INFO "/>

< param name =" LevelMax " value =" ERROR "/>

< param name =" AcceptOnMatch " value =" false "/>

</ filter >

10.5 Action !

10.5.1 Rechargement du fichier de configuration Log4J

Le rechargement du fichier de configuration Log4J, c'est-à-dire la prise en compte par le moteur, se fait sans arrêter l'application. Ce rechargement se fait via une action du socle.

• Configuration de l'action :

< action name =" trace_reload " class =" fr.ACE.technicalframework.application.action.TraceReload "/>

• Exemple d'URL :

cinematic=trace_reload();display(0)

10.5.2 Activation/Désactivation des traces

10.5.2.1 Activation/désactivation par requêtes ACE

La trace transversale activite est toujours active (à condition que le logger correspondant soit présent dans le fichier de paramétrage). Par contre, pour des raisons de performances, les traces de type "data" et "timer" ne sont pas actives au lancement de l'application (sauf par demande explicite dans le fichier ACE.properties.xml). Elles sont activables et désactivables à la demande via des actions. L’activation de ces traces est valide pour la session en cours.

• Configuration des actions

< action name =" trace_e nable " class =" fr.ACE.technicalframework.application.action.TraceEnable ">

< required >

< param name =" loggerName " type =" String "/>

</ required >

</ action >

< action name =" trace_disable " class =" fr.ACE.technicalframework.application.action.TraceDisable ">

< required >

< param name =" loggerName " type =" String "/>

</ required >

</ action >

• Exemple d'URL

10.5.2.2 Activer et désactiver les traces timer

cinematic=trace_enable(nomDuTimer);display(0)

cinematic=trace_disable(nomDuTimer);display(0)

Valeurs possibles de nomDuTimer:

10.5.2.3 Activer et désactiver la trace data

cinematic=trace_enable(data);display(0)

cinematic=trace_disable(data);display(0)

10.5.3 Activation/désactivation par paramétrage.

Il est possible d’activer les différents timers/data via le fichier ACE.properties.xml. Dans ce cas, les traces sont actives en permanence pour l’ensemble des sessions, et donc des utilisateurs.

Le fichier contient l’ensemble des timers disponibles :

< timer_def >

< timer name =" globalRequestTimer " active =" true " precision =" us " level =" us " comment =" Temps global de l'exécution de la requête, avec les traitements annexes. "/>

< timer name =" requestTimer " active =" true " precision =" us " level =" us " comment =" Temps d'éxécution de la requête pur, sans les traitements annexes de Servlet. "/>

< timer name =" servletInitParamTimer " active =" true " precision =" us " level =" us " comment =" Temps de récupération des paramètres d'URL. "/>

< timer name =" servletUuidTimer " active =" true " precision =" us " level =" us " comment =" Temps de gestion de l'UUID. "/>

< timer name =" servletGetProcessusTimer " active =" true " precision =" us " level =" us " comment =" Temps de récupération/création du Processus par la Servlet. "/>

< timer name =" authentificationTimer " active =" true " precision =" us " level =" us " comment =" Temps d'exécution du processus d'authentification. "/>

< timer name =" parsingRequestTimer " active =" true " precision =" us " level =" us " comment =" Temps de parsing de la requête ACE. Inclu la construction de la BusinessView. "/>

< timer name =" buildBusinessViewTimer " active =" true " precision =" us " level =" us " comment =" Construction de la BusinessView "/>

< timer name =" buildViewTimer " active =" true " precision =" us " level =" us " comment =" Construction d'une View dans la ViewStruct. "/>

< timer name =" buildViewObjectTimer " active =" true " precision =" us " level =" us " comment =" Construction d'une ViewObject "/>

< timer name =" buildApplicationModuleTimer " active =" true " precision =" us " level =" us " comment =" Construction d'un ApplicationModule "/>

< timer name =" processusListenerTimer " active =" true " precision =" us " level =" us " comment =" Temps d'exécution des différents listener de Processus. "/>

< timer name =" actionTimer " active =" true " precision =" us " level =" us " comment =" Temps d'exécution de l'action "/>

< timer name =" APITimer " active =" true " precision =" us " level =" us " comment =" Temps d'exécution de l'API. "/>

< timer name =" transactionTimer " active =" true " precision =" us " level =" us " comment =" Temps d'exécution des différentes étapes sur le transaction. "/>

< timer name =" timer " active =" true " precision =" us " level =" us " comment =" Commande générale. Demande d'éxécution des timers request et API "/>

< timer name =" xmlpresBeginTimer " active =" true " precision =" us " level =" us " comment =" Temps de génération du flux de présentation complémentaire à la BusinessView. "/>

< timer name =" viewTimer " active =" true " precision =" us " level =" us " comment =" Temps de construction du flux de présentation d'une View dans la ViewStruct. Provoque aussi le déclanchement des RowfieldTimer "/>

< timer name =" XSLTTimer " active =" true " precision =" us " level =" us " comment =" Temps d'application de la feuille de style pour le rendu HTML. "/>

< timer name =" renderOutputTimer " active =" true " precision =" us " level =" us " comment =" Temps complet de génération du flux de sortie. Inclu le XSLTTimer. "/>

< timer name =" servletInitHeaderTimer " active =" true " precision =" us " level =" us " comment =" Temps de mise à jour du header HTTP. "/>

< timer name =" servletFlushOutTimer " active =" true " precision =" us " level =" us " comment =" Temps de mise à jour du flux de sortie de la Servlet. "/>

< timer name =" betweenLog4JTimer " active =" true " precision =" us " level =" us " comment =" Chrono intermédiaire, mesure le temps entre chaque chrono. "/>

< timer name =" data " active =" false " precision =" us " level =" us " comment =" Mesure le temps d'exécution des requêtes SQL. "/>

</ timer_def >

11 Migration vers GCE155 : remarques

11.1 @nbline optionnel

Cet attribut est désormais optionnel. S’il n’est pas présent au niveau d’une View composite (dans une ViewStruct donc), c’est alors le maxFetchSize qui est pris en compte.

Ceci n’est - bien entendu - valable que pour des View pointant sur des ViewObjects (dynamique ou pas) puisque (par exemple) les Documents pointant sur un service (API) ne disposent pas d’un maxFetchSize (aucun sens technique).

11.2 Alias de classes

L’ensemble des classes utilisables dans le fichier de configuration ont été déportées dans une nouvelle section classalias_def.

Cela bénéficie surtout aux resolverClass de requêtes (type=query comme on peut le voir sur le schéma ci-dessus).

La phase de migration des configurations clients vers la GCE155 automatise le traitement sur les requêtes spécifiques. Néanmoins, cela ne peut prendre en compte que les resolverClass fournis par ACE (dont le nom est connu est associé à un nom logique). Il conviendra donc de faire le travail manuellement si des resolverClass spécifiques ont été développés sur site.

11.3 Supports de présentation

Le schéma du fichier de configuration a été modifié afin que les supports de présentation se trouvent désormais sous chaque BusinessView.

Exemple de définition :

< businessview name =" I_TBL_TP_AFF_M " target =" TP_AFF " viewstruct =" TBL_D ">

< fop fileRef =" {ROOT_XSL_MODULE_NAV}/i_table_modification.xsl " fileRefFO =" {ROOT_XSL_MODULE_FOP}/FO_TBL_standard.xsl " lang =" UNK " renderType =" pdf " support =" UNK "/>

< xsl fileRef =" {ROOT_XSL_MODULE_NAV}/i_table_modification.xsl " lang =" UNK " support =" UNK "/>

< /businessview >

11.4 Impact sur le métier java spécifique client

Afin d’harmoniser le plus possible les APIs métiers, la version155 exploite dorénavant JAXB 2.2 en lieu et place de JAXB 1.0+Enhydra.

En conséquence de quoi, des APIs développées en clientèle ne fonctionneront plus, il est alors conseillé de se rapprocher d’ACE (Conseil & Service) afin d’effectuer la migration des composants métiers de ce type.

D’autre part, certaines signatures ont été ajoutées afin d’instancier plus facilement une ViewObject ainsi qu’un ApplicationModule et il est préconisé de les utiliser.

Il conviendra alors de se conformer aux documents concernant les règles de développement de la GCE155.

11.5 Internationalisation : I18N

Il est fortement conseillé de lire les documentations fonctionnelles & techniques concernant ce sujet. En effet, un client qui souhaite internationaliser ses propres développements devra prévoir une analyse sur ce sujet, certaines moulinettes existent mais une bonne partie doit être réalisée manuellement.

12 Lexique

WM : Web-module applicatif

VS : élément technique du fichier de configuration, ViewStruct

BV : élément technique du fichier de configuration, BusinessView

BF : élément technique du fichier de configuration, BusinessFlow

VUCS : abréviation pour nommer la View « VueUtilisateurCourantSociete »

Document : notion qui permet de découpler le socle technique du support de persistance (BC4J, API …). Cela autorise la sauvegarde des états de saisie (bufferisation) depuis l’IHM avant de déclencher les traitements métiers ou autres …