Modifications apportées à ACE 1.4 après le 9 novembre 2009
Sujet parent: Modifications apportées à ACE 1.4 après le 9 novembre 2009

Release Notes ACE 1.4

Release Note technicalframework GCE140
Type diffusion   Auteur Equipe Recherche et Innovation ACE
Révision 58   Date de création 29/02/2008

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

Ce socle se nomme 6.4.0 en référence à la version web qui est la cible de ce développement.

Cette version est destinée à être mise en production pour la version 6.4.0 correspondant à la version commerciale ACE 1.4.

Ce document est un condensé des nouveautés fournies par le socle.

Des guides utilisateurs plus complets sont disponibles sur certains sujets traités.

L'information contenue dans ce document est fournie sans garantie d'aucune sorte, explicite ou implicite. Elle est fournie à titre éducatif et devra être relue et validée en environnement de test avant utilisation en production. L'utilisateur doit s’assurer du caractère approprié du contenu de ce document à son usage particulier, et assume le risque de son utilisation.

Société : Aurea Titre : Release Note technique GCE140
Dernière modification : Sébastien MAILLARD Sujet : Release Note technicalframework GCE140
Temps de modification : 1698 Résumé :  
Nom du fichier   Release Note technique GCE140 v2.doc      
           
Liste de diffusion   Interne et externe      
           
           
           
           

1 Remarques importantes

Le fichier configurationdef.xml devient obligatoire en ACE 1.4 alors qu’il était optionnel en ACE 1.3. Son nom peut être piloté par un paramètre technique décrit dans un autre chapitre.

D’autre part, l’externalisation des paramètres techniques implique une mise en place systématique des fichiers type ACE.properties.xml.

L’option permettant de gérer plusieurs fichiers de configuration est désormais certifiée sur la ACE 1.4, XDME possède dorénavant la capacité de gérer plusieurs « conf » simultanément, ainsi que d’ouvrir plusieurs ensembles multi-configurations.

La signature des resolverClass a été modifiée, il convient donc de faire le nécessaire en cas de resolver spécifiques (non standards et développés sur site).

2 Externalisation du paramétrage technique

2.1 Objectifs

L’objectif est de découpler les paramètres « fonctionnels » des paramétrages « techniques » de l’application ACE. Ceci facilitera plusieurs axes :

Ce nouveau mode de fonctionnement annule et remplace le mode précédemment proposé en GCE130 qui représentait le premier lot de développement (ACE.properties), même si le concept est relativement similaire.

A ce titre, les paramètres techniques sont dorénavant définis dans un fichier XML possédant son propre schéma de validation (XSD).

Ce schéma porte l’ensemble de la documentation technique liée à chaque section et chaque paramètre. Il convient donc de s’y reporter pour avoir des informations détaillées.

2.2 Mise en place

On pourra trouver à la racine de l’application plusieurs fichiers de propriétés, on en aura par exemple un par environnement de déploiement. Le fichier de propriétés à exploiter au runtime sera défini par la ligne de démarrage de la JVM.

Exemple pour un mode « développement » :

Si le paramètre n’est pas passé sur la ligne de démarrage, le nom de fichier ACE.properties.xml est pris par défaut.

Impacts techniques :

Aucune moulinette automatique ne sera proposée pour migrer d’une ancienne version au nouveau mode de fonctionnement. ACE fournira 2 fichiers à titre d’exemple de configuration (un pour le mode développement, le second pour la mise en production). Il convient de se référer à la section détaillant les différents paramètres pour effectuer la migration en version140.

On notera aussi que le fichier de propriétés doit obligatoirement être présent, sinon l’application ne démarrera pas. Ceci afin d’éviter un comportement « hasardeux ».

2.3 Guide des paramètres

2.3.1 Paramètres déplacés de la configuration

Un certain nombre de paramètres étaient auparavant portés par le fichier de configuration, ils ont été déplacés dans le nouveau fichier de propriétés. Ceci permet de découpler naturellement la complexité fonctionnelle de l’application de sa définition technique.

Ce paramètres était numérique auparavant, il devient un attribut booléen (true ou false)

Préfixe du nom du fichier de présentation (pouvant inclure son extension), ce paramètre n’est utile que dans le cas ou le paramètre writeOnDisk est actif.

2.3.2 Définition des connexions XMLRpc

Elle a été supprimée elle aussi du fichier de configuration, la section a par contre été repris « telle quelle » dans le fichier de propriétés.

2.3.3 Définition du fichier log4j à utiliser

Ce paramètre était auparavant piloté par un paramètre du fichier web.xml.

2.3.4 Fichiers de présentation

On peut dorénavant piloter la génération des fichiers de présentation via l’élément writeOnDisk. Le nom du fichier généré est fonction de la valeur de chacun des éléments context, businessViewName, uuid, username, timegen.

L’élément prefix pilote le préfixe du nom du fichier de présentation à générer.

Avec le paramétrage ci-dessus, on obtient des noms de fichiers de ce type :

On notera que l’ordre dans lequel les différents attributs sont utilisés n’est pas pilotable.

2.3.5 Description des paramètres serveurs

2.3.5.1 Nom d’instance applicative

Nœud : /config/server/instance/egx/@name

Valeur : définit le nom de l’instance applicative, utilisé par les pools (la valeur de ce paramètre n’a pas d’incidence pour le moment mais il doit obligatoirement être défini).

2.3.5.2 Pilotage des caches application

Nœud : /config/server/cache/application

Valeur : true / false

Cache d'actions et de documents.

"true" signifie que tout objet chargé depuis le système de fichier est conservé en mémoire pour accélérer les temps de chargement. Cela a pour conséquence que les modifications apportées à des fichiers ne seront visibles qu'au prochain redémarrage de l’application.

La valeur "false" ne se justifie que pour une problématique de développement afin d’éviter de redémarrer le conteneur J2EE.

Les objets qui sont cachés :

2.3.5.3 Pilotage des caches de constructeurs de domaines

Nœud : /config/server/cache/constructor/domain

Valeur : true /false

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)

2.3.5.4 Pilotage des caches de chargements de classes

Nœuds :

/config/server/cache/class/applicationModule

/config/server/cache/class/class

/config/server/cache/class/viewObject

/config/server/cache/class/rowSet

Valeur : true / false pour chaque nœud

2.3.5.5 Pilotage des pools

Nœud : /config/server/pool/file

Valeur : nom de fichier de description des pools.

2.3.5.6 Pilotage de log4j

Nœud : /config/server/log4j/file

Valeur : nom du fichier de paramétrage LOG4J à utiliser (exploit_log4j.xml, develop_log4j.xml …)

Il sera possible dans une version ultérieure de changer le fichier LOG4J en cours d’exploitation, sans redémarrer le conteneur J2EE. Une console JMX pourra être exploitée à cet effet.

2.3.5.7 Pilotage des fichiers journaux.

Nœud : /config/server/log/workingDirectory

Valeur : Répertoire destinataire des fichiers journaux (LOG)

Ce répertoire contient les fichiers générés par le socle, ainsi que la journalisation applicative (fichier du flux de présentation, fichier de log).

Nœud : /config/server/log/traceData

Valeur : true / false

Traces datas globales à toute l'application et non pas à la session utilisateur.

2.3.5.8 Pilotage écriture des fichiers de présentation

Nœud : /config/server/xmlPresentationFile/writeOnDisk

Valeur : true / false

Pilote l’écriture des fichiers de présentation sur disque (doit être à false en production)

2.3.5.9 Préfixage des noms de fichiers de présentation

Nœud : /config/server/xmlPresentationFile/prefix

Valeur : Préfixe des fichiers de présentation

2.3.5.10 Pilotage de la composition du nom des fichiers de présentation

Nœud :

/config/server/xmlPresentationFile/presentationFileFormat/context

/config/server/xmlPresentationFile/presentationFileFormat/businessViewName

/config/server/xmlPresentationFile/presentationFileFormat/uuid

/config/server/xmlPresentationFile/presentationFileFormat/username

/config/server/xmlPresentationFile/presentationFileFormat/timegen

Valeur : true / false pour chaque paramètre

Le nom des fichiers de présentation peut être constitué dans l’ordre de :

2.3.5.11 Définition communication XMLRPC (lien vers le Client Serveur)

Partie technique. Ce nœud est utilisé dans le cadre de la gestion des éditions rapides. C'est le moyen de définir un lien vers les batchs sur le serveur de traitement (communication via protocole XMLRPC).

Nœud : /config/server/link_to_ACE/xmlrpc/client

Attributs sur le nœud xmlrpc :

Attributs du nœud client :

2.3.5.12 Pilotage de la connexion à la base :JDBC

Nœud : /config/server/link_to_business/business_session

Valeur : la chaîne de connexion JDBC permettant de se connecter à la base.

Seuls les ApplicationModule root se connectent au SGBD. Ce paramètre est optionnel, s'il n'est pas présent, la connexion est réalisée via les data-sources du serveur d'application.

Exemple : connection=jdbc:oracle:thin:soc1/password@oracle:1521:gnx

2.3.5.13 Pilotage de limitation des sessions Http

Nœud : /config/server/httpSession/limit

Valeur : true / false

Limitation du nombre de sessions http.

Nœud : /config/server/httpSession/limitByUuid

Valeur : true / false

Limitation du nombre de sessions http par UUID.

2.3.5.14 Gestion des timeout sur locks dans la base de données

Nœud : /config/server/lock/timeout

Valeur : valeur de temps donnée en secondes.

Pilote le temps au-delà duquel les demandes de lock sont considérées comme échues. Si la demande de lock n’a pu être satisfaite l’erreur « donnée verrouillée » est remontée par l’application. Cette erreur peut se produire en particulier lorsque des enregistrements sont verrouillés pendant un laps de temps important (passage d’un batch …)

2.3.5.15 Pilotage des timers applicatifs

Nœud : /config/server/timer_def/timer

Attributs des timers :

2.3.5.16 Pilotage de la plateforme BIRT

Nœud : /config/server/birt

Attributs :

2.3.5.17 Pilotage JMX

Nœud : /config/server/jmx

Attribut :

Suivant les cibles de déploiement, les 2 valeurs ci-dessous peuvent être pilotées :

Exemple pour OC4J :

2.3.5.18 Propriétés systèmes

Dorénavant, les paramètres systèmes peuvent être positionnés dans cette section en lieu et place de la ligne de commande de démarrage du conteneur J2EE. Ceci est réalisable exclusivement pour les paramètres liés à l’application ACE.

Exemple :

2.3.6 Définition des paramètres application

2.3.6.1 Définition du fichier descripteur des fichiers de configuration (environnement multi-conf)

Nœud : /config/application/configurationDefinition/definition

Valeur : Définition du fichier contenant les noms des fichiers de configurations et les noms des fichiers de libellés externes.

Le nom du fichier par défaut est configurationdef.xml, ce fichier est désormais obligatoirement présent à la racine du module web depuis la version140.

2.3.6.2 Pilotage relecture des fichiers de traductions

Nœud : /config/application/debug/translation

Valeur : true / false

Les fichiers contenant les libellés ne sont pas relus dans un fonctionnement normal de l’application, toutefois en mode debug (assimilé à un mode développement) il est possible de spécifier de relire ces fichiers lorsqu’une modification y a été apportée (vérification de la date/heure des fichiers sur le filesystem).

2.3.6.3 Pilotage rechargement du fichier de configuration

Nœud : /config/application/debug/configuration

Valeur : true / false

Définit la condition de relecture du contenu du fichier de configuration en mode debug ; en mode production le fichier de configuration n’est jamais relu. En mode multi-configuration, la vérification s’opère sur chaque fichier de configuration (vérification de la date/heure des fichiers sur le filesystem).

2.3.6.4 Pilotage de génération du nœud debug dans les fichiers de présentation

Nœud : /config/application/debug/debugNode

Valeur : true / false

Normalement, cette valeur doit toujours être à false, même dans un mode de développement. Il est du ressort d’un expert ACE de demander l’activation de cette trace supplémentaire.

2.3.6.5 Gestion des UUID

Noeud : /config/application/uuidManagement/uuidManage

Valeur : true / false

Activation ou désactivation de la gestion des UUID. La valeur par défaut est "true".

Si "true", alors on gère l’UUID par session. On reconnaît un utilisateur qui dispose d'un cookie ACE.

Tout poste client qui n'a pas le cookie ACE se verra doté d'un nouvel UUID personnel. Cela permet de gérer une session logique (concept permettant de suivre différemment chaque utilisateur non logué, donc "GUEST").

Si "false", désactive la gestion de la session logique. Cela ne supprime pas les cookies sur le poste client. Les cookies sont justes ignorés.

UUID = Unique Universal IDentifier.

Noeud : /config/application/uuidManagement/webmodule

Valeur : update = true / false

Mise à jour du champ WEBMODULE de la table UT_UUID, par défaut le champ n'est plus automatiquement mis à jour depuis la version140, ceci afin de ne pas être dans l’obligation de se relogguer lors du passage de l’utilisateur entre 2 modules web.

Nœud : /config/application/uuidManagement/checkId

Valeur : true / false

Vérification de la contrainte de continuité.

Dans chaque flux de présentation, il y a un attribut id qui est généré. Cet attribut dépend directement de l'état de la session http au moment de la génération du XML de présentation.

Lorsque cette option est activée, elle permet de vérifier qu'on ne tente pas d'appliquer une url qui n'est pas continue par rapport à l'état du serveur. Un identifiant de requête est ajouté au XML de présentation afin de garantir l'intégrité entre les états courants sur le serveur et ce qui est présenté à l'utilisateur.

Le XML de présentation contient une valeur correspondant à un checksum représentant l'état de l'application lors de la génération de la présentation. Toutes les URL doivent renvoyer cet identifiant pour assurer la continuité du traitement entre deux URL.

L'identifiant se trouve à l'emplacement suivant dans le XML de présentation : /layout_data/application_data/id

L'identifiant doit être renvoyé sous la forme d'un attribut nommé "id". Par exemple : id=531b02df

En cas de différence entre l'identifiant renvoyé sur l'url et l'identifiant attendu par le serveur, la requête courante est perdue et est remplacée automatiquement par la requête suivante : cinematic=display(0) et une erreur est ajoutée dans le XML de présentation.

Quand ce cas d'erreur se produit, cela signifie que l'utilisateur visualise une BusinessView qui n'est plus réellement la courante ou la même dans un état qui n'est plus celui du serveur.

L'effet du display(0) est d'afficher à l'utilisateur l'état réel du contexte pour le serveur dans le but de reprendre une cinématique valide.

L'utilisation de l'attribut "sourceview" sur l'url implique que l'attribut "id" n'est pas obligatoire.

Le tag représentant l'erreur se trouve dans le flux de présentation à l'emplacement suivant : /layout_data/error

2.3.6.6 Pilotage de l’authentification

Nœud : /config/application/authentification/declarative

Valeur : true / false

Utilisation du mode d'authentification externe (via un annuaire LDAP par exemple).

Nœud : /config/application/authentification/loginBusinessView

Valeur : BusinessView utilisée pour l'authentification de l'utilisateur par couple utilisateur/mot de passe (LOGIN). Cette valeur ne doit normalement jamais être modifiée.

Nœud : /config/application/authentification/defaultUserRecognize

Valeur : true / false

Login automatique.

La valeur par défaut est "true". Cet attribut n'a aucun sens si uuidManage est à "false". Si "true", alors le support de présentation est reconnecté pour l'utilisateur précédemment logué. Grâce à l'UUID stocké dans le cookie du navigateur, on reconnaît l'utilisateur précédemment logué et on le ré identifie automatiquement (à concurrence de la durée de vie du cookie). Si "false", alors on considère que toutes les sessions logiques sont associées à l'utilisateur GUEST.

Nœud : /config/application/authentification/loginRetry

Valeur : Nombre de tentative au login avant la désactivation de l'utilisateur (mise hors service dans la table UT_UTI).

2.3.6.7 Pilotage des contrôles applicatifs

Nœud : /config/application/control/maxFrameNumber

Valeur : Nombre maximum de contextes applicatifs par utilisateur (les contextes correspondent au paramètre frame passé sur les URL)

Nœud : /config/application/control/sessionControl

Valeur : true / false

Utilisation du contrôle de licence étendu

2.3.6.8 Pilotage des pdf

Nœud : /config/application/pdf/defaultPdfNbLine

Valeur : Nombre maximum de lignes à afficher lors de la génération d'un fichier PDF via le moteur FOP (batik)

2.3.6.9 Pilotage des options liées aux feuilles de style

Deprecated

Nœud : /config/application/presentation/forceSupport

Valeur : Forçage du support de présentation quel que soit le navigateur utilisé (navigateur), par exemple la valeur NAV/MIC correspond au support d’Internet Explorer.

Nœud : /config/application/presentation/forceLang

Valeur : Forçage de la langue afin de pointer toujours sur les mêmes feuilles de style (ex : FRA)

2.3.6.10 Découplage des supports de présentation et des langues

TODO.

Le support de présentation NAV/NET est invalide dorénavant et n’est plus supporté par le socle technique. Il est remplacé par le support NAV/FOX s’il s’agit du navigateur Firefox (certifié pour la GCE140) ou NAV/MOZ pour un autre navigateur Mozilla.

2.3.6.11 Pilotage des fusibles sur le nombre de rows

Nœud : /config/application/datasource/overallMaxFetchSize

Valeur : un entier ou la valeur -1 pour désactiver

Cet attribut défini le nombre de row que la méthode executeQuery s’autorise à fetcher depuis la couche métier.

Nœud : /config/application/datasource/maxRowForDestroy

Valeur : un entier ou la valeur -1 pour désactiver (valeur 1000 par défaut)

Cet attribut défini la politique de remise en pool d’un RowSet suite à l’appel de la méthode remove.

2.3.6.12 Pilotage du timeout des requêtes

Nœud : /config/application/datasource/queryTimeout

Valeur : un entier ou -1 pour désactiver (-1 est la valeur par défaut)

Cet attribut définit le temps en seconde que l’on autorise pour qu’une requête s’exécute.

2.3.6.13 Définition des « clients » WebServices

Ici s’effectue l’association entre le nom logique ACE d’un webservice externe (utilisé dans le fichier de configuration comme client webservice) et la localisation de son WSDL (donnant la signature du webservice).

Exemple :

< clientWebServices >

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

< clientWebService name =" Genki " wsdlURL =" http://192.168.103.212:8080/gcedelegate.business/GCEBLWebServicesBean?wsdl "/>

</ clientWebServices >

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

2.3.7 Pilotage des paramètres de développement

2.3.7.1 Pilotage de validation du fichier de configuration lors de son (re)chargement

Nœud : /config/design/configuration/schemaValidation

Valeur : true / false

Permet de ne pas valider le fichier de configuration par son schéma lors du chargement : interne ACE, la valeur doit toujours être à true (valeur par défaut si cette option n’est pas présente).

2.4 Mode développement

Le fichier ACE_developpement.properties.xml est paramétré pour réaliser les développements dans un conteneur OC4J standalone 10.1.3.

La ligne de démarrage de la JVM doit donc comporter le paramètre suivant :

Si le paramètre n’est pas spécifié, c’est le fichier ACE.properties.xml qui est utilisé (mode par défaut : mode production avec les caches actifs …)

Les 2 fichiers contiennent les commentaires décrivant chaque élément de cette section :

3 JMX

3.1 Présentation

JMX est un standard Java proposé depuis le JDK1.4, et proposant régulièrement des améliorations (JDK5 et JDK6).

Définition : Java Management eXtension permet une communication entre une console d’administration et une application par le biais de MBean (Management Bean). Les MBean sont définis par l’application et publiés sur le serveur d’application.

Exemples d’exploitation :

Chaque serveur d’application possède sa propre mise en place de console d’administration des MBean JMX. Ce document n’est pas là pour décrire le fonctionnement des serveurs d’application, mais pour indiquer l’ensemble des informations qui seront accessibles et/ou modifiables en GCE140.

On notera que les consoles d’administrations n’exploitent pas encore tout à fait les possibilités (étendues il faut le reconnaitre !) de JMX tel qu’il est défini par la communauté Java.

3.2 Mise en place et MBean disponibles

L’activation des MBean doit être faite à 2 niveaux :

Sur la ligne de commande de démarrage de l’application afin d’avertir la JVM et OC4J :

Et au niveau d’ACE.properties :

Suivant les paramétrages et les consoles utilisées, les arborescences de MBean sont très différentes (pas organisées de la même manière). Il a été choisi de se baser en standard sur celle proposée par OC4J d’Oracle.

On notera aussi qu’il n’y a pas de propagation des changements de paramétrage dans un déploiement en mode cluster. Ceci sera réalisé dans une version ultérieure.

3.2.1 Accès au fichier de configuration

Deux 2 types d’attributs sont présents :

Une opération :

3.2.2 Accès aux paramètres techniques

3.2.3 Accès au paramétrage fonctionnel

L’opération sert à demander un rechargement explicite du paramétrage fonctionnel.

3.3 Administration

Avec la version 140 apparait la possibilité de consulter/modifier des informations techniques via une console JMX. Les premières données disponibles concernent les sessions et la nouvelle gestion de pools. Cette gestion par JMX viendra s’enrichir au fur et à mesure des versions du produit.

Les MBeans d’ACE sont attachés à une racine commune qui contient le nom du WebModule.

Par exemple : ACE@GCE140-webbtoe

3.3.1 Activation générale

L’activation des MBean JMX demande au minimum le paramétrage suivant :

Dans ACE.properties.xml, positionner la configuration JMX de la façon suivante :

< server >

…

< jmx active =" true ">

< domainName name =" oc4j "/>

<containerType name =" j2eeType "/>

</jmx >

Si ces paramètres ne sont pas positionnés, aucun MBean JMX ne peut être visualisé. Dans la suite du document, il est considéré que ces attributs sont positionnés.

3.3.2 Les sessions http

3.3.2.1 Activation

Les MBeans liés à la création des sessions http sont toujours disponibles. Ils se trouvent sous le nœud Application.

3.3.2.2 Résultat

Ici deux sessions pour le WebModule btoe.

Le MBean fourni quelques informations sur la session sélectionnée :

Les sessions viendront s’enrichir au fils des versions. Les premiers MBeans disponibles par session sont ceux qui correspondent à la nouvelle gestion de pools.

3.3.3 Les Pools

La nouvelle gestion de pools permet la génération de MBean JMX consultables depuis la console JMX. Ces infos sont plus parlantes et plus complètes que celle fournis par VisuCache.

Le rapport fournis par VisuCache reste disponible mais est maintenant allégé. Seule la vue « via les BC4J » est disponible. La vue « par les pools » n’est plus disponible et est remplacé par les MBeans JMX.

3.3.3.1 Activation

Les MBeans JMX lié aux pools sont divisés en deux catégories et activable séparément.

Une première vue globale est fournies par le cleaner.

Une seconde vue plus détaillé fournie le contenu pool par pool.

Pour activer la gestion JMX des pools il faut positionner l’attribut active=’true’ sur les nœuds JMX suivants :

3.3.3.1.1 Au niveau général

Cela déclenche la création de tous les MBeans JMX de l’ensemble des pools pour toutes les sessions, hormis les MBeans des processus de nettoyage.

Dans la configuration des pools, l’attribut se situe au niveau suivant :

Dans la configuration pool.xml :

< attributes >

…

< jmx active =" true ">

< path name =" ACE " value =" Application "/>

</ jmx >

</ attributes >

3.3.3.1.2 Au niveau des cleaners

Cela déclenche la création des MBeans de tous les cleaners pour toutes les sessions. L’attribut à positionner se trouve à ce niveau ci :

Dans la configuration pool.xml :

< cleaner >

…

< jmx active =" true ">

</ jmx >

</ cleaner >

Remarque : les nœuds « path » ne sont pas actif en GCE140.

3.3.3.2 Exemples de résultats

Il y a plusieurs consoles disponibles sur le marché. Nous prenons comme exemple celle intégrée au serveur d’application Oracle.

Dans la console, le nœud Cleaner se positionne sous la session.

Le Bean PoolCleaner donne des informations techniques en temps réel sur le travail effectué par le cleaner de la session.

Les attributs numérotés de 12 à 15 ne sont alimentés que si les beans des Pools eux-mêmes sont actifs.

Quand l’ensemble des attributs active sont positionnés dans le fichier de configuration des pools, la vue des MBeans s’enrichis avec les pools d’ApplicationModule et de ViewObject

Les nœuds Cleaner et RootApplicationModule concerne le pool de SessionMetier qui est indépendant des sessions http.

Détail du pool d’ApplicationModule Root :

Détail d’un ViewObject dynamique DhabCha. Les différentes ViewObject d’un même type sont différencié par le numéro de l’objet.

Une explication plus particulière sur deux attributs :

Les attributs 07-locked et 08-unlocked donnent la liste des objets respectivement en cours d’utilisation et disponibles dans le pool. Les objets sont toujours référencés par leur clé de définition dans le pool. Ces attributs contiennent entre 0 et n valeurs selon l’état des pools.

Zoom sur l’attribut 7-locked

Une sélection sur une ViewObject génère les MBeans correspondants aux pools de RowSet, ci dessous un seul RowSet :

On retrouve les mêmes attributs que pour les ViewObjects.

Autre exemple d’une ViewObject avec 2 RowSet

L’attribut locked nous signale que les deux sont en cours d’utilisation et que les valeurs des clés sont :

Le Bean du cleaner signale qu’il y a 117 éléments en cours d’utilisation dans les pools de cette session et qu’ils sont tous en cours d’utilisation.

L’attribut containerTab donne une idée de ce qu’il y a dans les pools.

La lockedList donne les clés des éléments en cours d’utilisation, l’unlockedList donne les clés des éléments disponibles dans les pools.

Chaque ligne correspond à un pool.

Autre exemple : le pool de ViewObject JUt_UtiView.

On voit ici qu’il y a un grand nombre de RowSet. Il est possible de trouver des RowSet avec des clés identiques car la nouvelle gestion de pool autorise la conservation des doublons.

3.4 Exemples

Depuis JConsole :

Depuis MC4J :

Depuis la console Oracle AS :

4 BusinessFlow

Quelques nouveaux flux métiers font leur apparition afin de faciliter les développements et d’homogénéiser la couche de présentation et le paramétrage.

Les noms logiques définis dans le fichier de configuration sont les suivants :

4.1 Amélioration GENZON

Il est dorénavant possible de piloter un bornage sur les données complémentaires que l’on publie, ceci via les paramètres PZNDEB et PZNFIN.

Ces paramètres peuvent être dynamiques et profiter des fournisseurs de valeurs, on peut donc leur passer des valeurs du type :

Ces bornages sont « autonomes » : on peut aussi bien n’en spécifier aucun (mode de fonctionnement standard : on publie l’ensemble des données complémentaires), que de spécifier des bornages par valeur inférieure et/ou supérieure.

5 Nouveaux Solver

5.1 Fournisseur de noms de BusinessView

On appelle un « BusinessView provider », un fournisseur de nom de BV qui est implémenté via une Classe métier. C’est le principe de découplage habituel entre les couches socle et métier, afin de pouvoir développer ses propres implémentations en projet. L’implémentation de base est décrite plus bas dans le document.

Remarque importante : il s’agit d’une nouveauté disponible sur la version 1.4 mais non implémentée sur le produit standard à ce jour (sur la couche de présentation). Il est fortement conseillé de se faire aider par un expert ACE afin de mettre en place cette fonctionnalité.

5.1.1 Objectifs

Ils sont multiples :

A titre d’exemple, sur le module btoe standard, on a environ 80% des BusinessView gérant les événements qui sont communes. Cela permet de remonter certains développements techniques vers une couche de paramétrage fonctionnel.

5.1.2 Mise en place et activation

Ce type de fournisseur (businessViewModel) est défini avec la liste habituelle des solveurs. Son nom est toujours BUSINESSVIEW et ne pas être changé car c’est le point d’entré du socle technique pour savoir si on applique (ou pas une politique de fournisseur de noms de BusinessView).

Il s’agit d’un mode général à l’application, un nouvel onglet a été implémenté dans XDME afin de permettre le paramétrage :

L’activation passe par l’attribut Active qui doit contenir la valeur « true ».

5.1.3 Tables de paramétrage

Ce nouveau paramétrage est basé sur 2 nouvelles tables du MCD :

On distingue 2 types de BusinessView référencées dans la table UT_BV_DEF :

On notera que dans ce mode, la cible de paramétrage associée à la BusinessView est portée par la table UT_BV_DEF, aussi bien pour des BV fictives que pour des BV physiques.

D’autre part ces tables doivent être partagées au niveau du multi-entité (table MEV) et impose d’avoir des règles de nommage bien établies si le paramétrage (BDD) est partagé par plusieurs WebModules distincts.

Description de la table UT_BV_DEF :

Description de la table UT_BV_MODELE :

La description fonctionnelle de cette nouveauté est décrite dans la documentation PACK.

5.2 QueryCompletion

5.2.1 Objectif

Il s’agit d’une nouvelle mise en place dans le fichier de configuration qui permet de compléter une requête via un solveur métier. Ceci permet de garantir qu’une requête reste valide, quel que soit sont contexte d’utilisation (prise en compte des PPE pour compléter la requête en fonction des règles de gestion par exemple).

5.2.2 Mise en place

Dans XDME, les QCS (QueryCompletionSolver) sont définis avec les autres solveurs, leur type est « completion » :

On les implémente au niveau des ViewDef via une liste déroulante :

Comme pour tous les solveurs, ce sont des classes métiers dérivées de classes du socle technique, il est donc possible de développer ses propres QCS en projet.

On notera aussi qu’un QCS donné ne peut pas s’appliquer à n’importe quel objet, il faut que le prédicat qui sera automatiquement générée soit valide par rapport à son contexte.

5.2.3 Ordre d’application

Les QCS sont appliqués en amont des ResolverClass et ils ne génèrent que des compléments de requêtes bindés avec des « ? ». Cela signifie qu’on doit obligatoirement utiliser des ResolverClass qui bindent les requêtes, à savoir préférentiellement :

5.2.4 QCS fourni en ACE 1.4

Il en existe un seul fourni en standard à ce jour :

Il prend en compte les PPE suivants :

La requête finale générée peut donc être du type final :

MevPro.CODSOC = ? AND CODPRO = ? AND (CODBLOCAGE != ?) AND (TYPPRO = ? OR TYPPRO = ?) AND (NATPRO != ?)

5.3 Améliorations

Cette section relate des améliorations concernant les solver déjà implémentés en version 1.3.

5.3.1 Fournisseurs de valeurs : ValueProvider

Ce fournisseur est utilisé principalement dans les ViewLink.

Trois nouveaux espaces de nommages sont disponibles :

Exemples de syntaxe :

L’expression : CHP :Codpro permet de récupérer la valeur du champ chp :Codpro passé sur l’URL courante.

Liste des informations accessibles depuis l’espace de nommage SES :

Rappel des espaces de nommage auparavant disponibles :

Rappels des fonctions :

Exemples pour récupérer un CODSOC_PHY :

Sans segment : MEV:PRO

Avec segment dynamique : MEV:TIE.EXPR(PPE:TYPCLI.A1)

Remarque : les PPE de type TYPxxx sont traités de la même manière qu’au niveau de la session métier, à savoir que s’ils ne sont pas positionnés la valeur renvoyée est « xxx » dans notre exemple.

6 API technique de rendu

6.1 Description fonctionnelle

Cette API permet de générer le flux de présentation XML d’une BusinessView.

Le système se base sur la cinématique d’actions (la même que spécifié pour une URL) ; l’action par défaut étant forward(0). Ex : "forward(0,PRO1,COD);linePage(Produit,15,50)".

6.2 Limites de fonctionnement

6.3 Définition technique

6.4 Schémas descriptifs

BeanIn :

BeanOut :

6.5 Exemple de flux d’entrée

Voici un exemple d’un flux XML permettant la génération du flux de présentation de la BusinessView I_PRO_E_F.

La cinématique d’actions par défaut est utilisée, soit « forward(0) ;

la clé rétrieve utilisée est la clé par défaut ; celle-ci nécessitant les 2 paramétres chp:Codpro et chp:Nompro ;

la clé sort utilisée est la clé par défaut.

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

<BusinessViewRendererrenderXmlIn xmlns="http://www.ACE.fr/technicalframework/businesscomponent/applicationmodule/common" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ACE.fr/technicalframework/businesscomponent/applicationmodule/common BusinessViewRendererrenderXmlIn.xsd">

<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>

Sortie :

<egx_ws>

<bean_out>

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

<xmlpres>

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

<layout_data>

… flux de présentation habituel …

</layout_data>

</xmlpres>

</BusinessViewRendererrenderXmlOut>

</bean_out>

</egx_ws>

7 Nouveaux Pool

7.1 Objectifs

Il s’agit d’une fonctionnalité qui nous permettra de piloter beaucoup plus finement les pools, avec en corollaire une meilleure maitrise de la mémoire consommée sur une JVM :

7.2 Nouvelle implémentation des pools

7.2.1 Principe

Jusqu’à la version 1.3, les objets présents dans un pool sont détruits dans deux cas :

1. Lorsque le pool a atteint sa taille maximale et qu’un objet plus récent retourne dans ce pool, l’objet le plus ancien est détruit.

2. Lors de la destruction de la session http, l’ensemble des pools sont détruits avec tous les objets qu’ils contiennent.

On voit très vite les limites d’une telle gestion. Un pool qui n’atteint jamais sa taille maximal dont les objets ne sont plus utilisés consomme inutilement des ressources.

Le but est de permettre une gestion plus fine de la durée de vie des objets contenus dans les pools.

Pourquoi pas des pools du marché :

Les implémentations existantes ne répondent pas pleinement à notre besoin.

Les caractéristiques principales de notre implémentation sont les suivantes :

7.2.2 Le paramétrage :

Les caractéristiques des pools se paramètrent dans un fichier XML externe. Chaque pool a ses caractéristiques propres.

Le fichier défini les caractéristiques statiques de chaque pool. Dans configuration.xml, XDME associe un paramétrage de pool à un Objet BC4J.

Plusieurs types de BC4J partagent donc le même paramétrage de pool, mais ce sont des pools distincts.

Il est également possible de créer des pools directement par le code java. Les caractéristiques de ces pools seront dans ce cas figées.

7.2.3 Les types de pools

Différents types de pools sont disponibles. Actuellement linéaire bornée et circulaire à débordement.

7.2.4 Points d’entrées applicatifs

Points d’entrée applicatifs (listener) durant les différentes phases de vie de l’objet ;

7.2.5 Les usines d’objets

Les pools sont alimentés par des usines (factory) distinctes.

Les paramètres passées à la factory d’éléments proviennent soient de la configuration xml pour les objets simples, soit du code java pour les objets complexes. C’est la configuration qui fixe l’origine des paramètres et leur type.

7.2.6 Gestion des doublons

Possibilité pour un pool de contenir plusieurs instances d’un objet accédé par la même clé. LA gestion actuelle des pools ne permet pas cette gestion. Tout doublon qui retourne dans un pool est détruit.

7.2.7 Gestion d’ensemble de pools

Il est possible de regrouper les pools selon une clé unique. eGX exploite cette possibilité de la façon suivante :

7.2.8 Synchronisation

Les pools sont automatiquement synchronisés de façon unitaire.

Pour éviter les deadlock java, il est possible de fournir à un pool un objet de synchro externe.

7.2.9 Le nettoyage des pools

Chaque ensemble de pool dispose de son process de nettoyage (cleaner).

Ce process externe aux pools est affecté à la surveillance des éléments contenus dans chaque pool.

Le cleaner travaille selon des critères fixés par configuration.

Critères possibles pour le nettoyage :

La politique externe de nettoyage est :

La fréquence de nettoyage :

7.2.10 Temps de traitement du nettoyage

En plus de la période de scrutation et du réveil à la demande, il est possible de borner le temps à l’intérieur duquel le nettoyeur pourra effectuer son travail, dans le but de limiter les attentes synchronisées ou pour réserver le temps de nettoyage à des moments ou l’application est moins sollicité (entre deux requêtes par exemple)

7.2.11 Définition de groupes de pools

Il est possible d’associer les pools en groupes pour factoriser le paramétrage concernant le nettoyage et les listener.

7.2.12 Suivi des pools par JMX

Actuellement suivi de l’activité des différents pools par MBean JMX dynamiques. Dans une prochaine version, on pourra modifier la configuration via la console JMX.

7.2.13 Axes d’évolution

On peut imaginer des évolutions tels que :

La modification en temps réel de la configuration des pools par JMX

Une action en directe sur le contenu des pools

Une limitation non pas sur un nombre d’objet mais suivant une taille mémoire java autorisée.

Ou encore un auto-sizing des pools selon leur fréquence d’utilisation (on peut rêver, non ? J)

7.2.14 Activation des nouveaux pools

7.2.14.1 Principe

L’application conserve actuellement les deux gestions de pools. Néanmoins ces deux gestions ne peuvent pas cohabiter. L’activation de la nouvelle gestion se fait via le fichier ACE.properties.xml.

Lorsque les nouveaux pools sont activés, l’ancienne gestion des pools est désactivée. les BC4J doivent obligatoirement faire référence à une configuration de pool dans le fichier de paramétrage des pools sinon un message d’erreur signalant que l’ancienne gestion n’est pas disponible.

7.2.14.2 Exemple de configuration dans ACE.properties.xml

< server >

…

< pool active =" true ">

< file name =" pool.xml "/>

</ pool >

…

Nœuds Description
Server Nœud contenant le paramétrage lié au serveur.
nœuds fils pool Déclaration du paramétrage des pools.
attribut active

true : activation de la nouvelle gestion de pools.

false : Conservation de l’ancienne gestion des pools.
nœuds fils file Nœud de déclaration des fichiers de paramétrage des nouveaux pools. Déclarer autant de nœuds qu’il y a de fichier de paramétrage.
attributs name Nom du fichier de paramétrage des pools relatif au nœud file. L’emplacement de ce fichier est la racine du web-module, dans le même répertoire que les autres fichiers de paramétrage ee eGX.

7.2.14.3 Impact dans configuration.xml…

Pour que les objets BC4J soient gérés par les nouveaux pools, il faut faire le lien entre les déclarations de BC4J et les noms de pools déclarés.

Des nouveaux attributs optionnels sont disponibles sur les déclarations des objets BC4J.

7.2.14.4 … Sur business_session

L’attribut poolConfigurationName est le nom d’un pool déclaré dans pool.xml. Dans la nouvelle gestion de pool les attributs minInstance et maxInstance ne sont plus utilisés. La taille du pool est spécifiée dans le fichier de paramétrage des pools.

7.2.14.5 .. Sur les nœuds applicationmodule_def et applicationmodule

Le nœud applicationmodule_def définie la valeur par défaut du nom des pools d’ApplicationModule.

Le nœud applicationmodule permet de définir localement un autre nom de pool.

Comme pour le nœud business_session, nous trouvons l’attribut poolConfigurationName qui est le nom d’un pool déclaré dans pool.xml. Dans la nouvelle gestion de pool, les attributs minInstance et maxInstance ne sont plus utilisés. La taille du pool est spécifiée dans le fichier de paramétrage des pools.

7.2.14.6 …Sur viewobject_def

Le nœud viewobject_def définie les valeurs par défaut des noms des pools pour les ViewObject standards, les ViewObject dynamiques et les RowSet.

Trois nouveaux attributs :

Nœuds Description
Viewobject_def Nœud contenant le paramétrage lié à l’ensemble des viewobject
attributs stdViewObjectPoolConfigurationName Nom du pool des viewobjects dites standards. Attribut obligatoire. C’est une valeur par défaut valable pour l’ensemble des viewObjects standards. Peut être redéfini viewObject par viewObject. Fait référence à une configuration dans le fichier de paramétrage des pools.
dynViewObjectPoolConfigurationName Nom du pool des viewObject dites dynamiques. Attribut obligatoire. C’est une valeur par défaut valable pour l’ensemble des viewObjects dynamiques. Peut être redéfini viewObject par viewObject. Fait référence à une configuration dans le fichier de paramétrage des pools.
rowSetPoolConfigurationName Nom du pool de rowSet. . Attribut obligatoire. C’est une valeur par défaut valable pour l’ensemble des rowSet. Peut être redéfini viewObject par viewObject. Fait référence à une configuration dans le fichier de paramétrage des pools.

7.2.14.7 …Sur viewobject

Sur le nœud viewobject, il est possible de redéfinir localement un autre nom de pool de ViewObject et de pool de RowSet.

Nœuds Description
Viewobject Nœud contenant le paramétrage lié à l’ensemble des viewobject
attributs viewObjectPoolConfigurationName Nom du pool des viewobjects. Attribut optionnel. S’il n’est pas présent, c’est l’attribut sur viewobject_def qui est pris en compte. Fait référence à une configuration dans le fichier de paramétrage des pools.
rowSetPoolConfigurationName Nom du pool de rowSet. Attribut optionnel. S’il n’est pas présent, c’est l’attribut sur viewobject_def qui est pris en compte. Fait référence à une configuration dans le fichier de paramétrage des pools.

7.3 Aller plus loin dans la compréhension des pools

7.3.1 L’architecture des pools

Le graphique suivant illustre le concept interne des pools. Ce graphique est valable pour un ensemble de pools attaché à un client, un utilisateur par exemple.

Le PoolAccess est une façade pour accéder au PoolInternal, point d’entrée unique sur les pools.

Ce poolInternal contient les containers PoolContainer qui contiennent chacun un pool.

C’est le PoolInternal qui est le maître du cleaner.

7.3.2 L’architecture du fichier de configuration

La configuration des pools se base sur un schéma nommé pool.xsd.

Une documentation au format html issue du schéma est disponible.

7.3.2.1 Exemple de configuration d’un pool

< pool name =" businessSession ">

< attributes >

< type > linear </ type >

< timeToLive > unbounded </ timeToLive >

< maxCount > 10 </ maxCount >

< factory >

< classname > fr….applicationmodule.GnxRootApplicationModuleFactory </ classname >

< parameter type =" Internal ">

< internal name =" connection " classname =" java.lang.String "/>

</ parameter >

< parameter type =" Internal ">

< internal name =" lockingMode " classname =" java.lang.String "/>

</ parameter >

< parameter type =" Internal ">

< internal name =" DefFullName " classname =" java.lang.String "/>

</ parameter>

</ factory>

</ attributes>

</pool>

7.3.2.2 Quelques explications

< pool name =" businessSession ">

Le nom du pool est businessSession.

<type > linear </type >

C’est un pool linéaire

<timeToLive > unbounded </timeToLive >

Avec une durée de vie illimitée

< maxCount >10 </ maxCount >

La taille maximale du pool est de 10 objets.

< classname > fr….applicationmodule.GnxRootApplicationModuleFactory </ classname >

La factory est définie par un nom de classe

< parameter type =" Internal ">

< internal name =" connection " classname =" java.lang.String "/>

</ parameter >

Ainsi que par des paramètres. Ici un paramètre de type String alimenté par le code java.

8 Nouveau schéma configuration.xsd

8.1 Objectifs

Comme à toute nouvelle version d’ACE, le schéma évolue pour répondre à certains besoins identifiés, en particulier :

La suppression des éléments techniques est décrite dans le chapitre explicitant l’externalisation des paramètres techniques. En corollaire, la saisie des paramètres techniques a été supprimée de XDME.

8.2 Dépréciation d’un élément

Trois valeurs sont possibles pour l’attribut deprecation :

Cet attribut est positionné sur 3 éléments :

8.3 Commentaires

Cela permet d’ajouter de petits commentaires, bien entendu ce n’est pas prévu pour publier des romans ( !) ou dans un but de documentation complète.

8.4 depthCount

L’attribut depthCount devient optionnel sur le nœud ViewObject, à défaut la valeur prise en compte est celle définie sur ViewObjectDef (obligatoire).

Pour rappel, cet attribut influe sur le comportement de la publication des ViewLink Oracle. Plus la valeur est élevée, plus le niveau d’arborescence des ViewLink publiés sera élevé. Ce paramètre est donc à utiliser avec beaucoup de précautions pour éviter les effets de bords indésirables (grossissement inconsidéré du flux de présentation, requêtes passées à la base de données …).

8.5 Ordonnancement des View

Il devient possible de forcer l’ordre de montage des View composite contenues dans une ViewStruct. La valeur par défaut reste la même afin de ne pas perturber le fonctionnement de l’application : montage inversé, ce qui signifie que les View sont montée et donc exécutée dans l’ordre inverse de leur apparition dans XDME.

Le nouvel attribut se nomme order et se positionne au niveau d’une ViewStruct.

Remarque importante : depuis la ACE 1.3, l’ordre des champs et des View dans le flux de présentation est trié lorsqu’on se trouve en mode développement (cf. ACE.properties). L’ordre d’exécution des View peut donc être différent de ce que l’on retrouve dans le flux de présentation.

Exemple ordre « ascendant » : mode normal

8.6 Pilotage de maxFetchSize

Ce paramètre est un fusible et permet d’indiquer à une ViewObject le nombre maximum d’enregistrements (nombre de Row contenu dans un RowSet) que l’on souhaite ramener. Auparavant, cet attribut était uniquement présent dans la définition d’une ViewObject.

Afin d’apporter plus de souplesse lors des phases de développements, il est maintenant possible de repréciser une valeur au niveau de la définition des clés retrieve dans la section des ViewDef.

Dans les faits, cela autorise :

On note aussi que le paramètre fetchSize devient pilotable de la même manière que maxFetchSize.

Rappel : fetchSize permet de définir une optimisation sur le nombre de row que l’on va fetcher en une seule exécution. De manière opérationnelle, il devrait être fixé à la valeur 1 pour toutes les lectures sur une clé primaire (relation de cardinalité 1-1).

8.7 Optimisation mémoire

Actuellement, toute BusinessView dite « courante » (en gros une businessView par frame affichée) conserve ses objets métiers (ViewObject, ApplicationModule).

Une nouvelle option permet de libérer les objets métier en fin de transaction applicative (en fin d’URL) afin de les rendre disponible pour le traitement d’une autre URL.

8.7.1 Mise en application

Un nouvel attribut est disponible au niveau des View dans la ViewStruct : endOfRequest

Les valeurs possibles sont :

8.7.2 Restriction

Il est possible de libérer immédiatement un objet qui ne conserve pas d’état. C’est le cas quand la requête se contente d’afficher une donnée qui ne sera pas modifié, ou qui ne doit pas conserver une position courante.

Par contre, il ne faut pas libérer un objet qui est susceptible recevoir une action de navigation lors d’une prochaine requête (nextPage, nextLine, etc…)

8.8 « Client » WebServices

8.8.1 Nouveau nœud « client_def »

Les Client WebService sont déclarés dans la configuration sous forme d’un nouveau type : config/business/webservice/client_def/client

Exemple :

< webservice >

< client_def >

< client name =" GCEService " serviceName =" GCEService " servicePortName =" WSGCEServicePort " targetNameSpace =" urn:ACE "/>

< client name =" Genki " serviceName =" Gcedelegate_ws " servicePortName =" GCEBLWebServicesInterfRemoteEndpointPort " targetNameSpace =" urn:com.influe.ii.gcedelegate "/>

</ client_def >

</ webservice >

8.8.2 Nouveau type de « document »

Le Document est de type particulier :

fr.ACE.technicalframework.application.document.ClientWebServiceDocumentImpl

Il ne fait ni référence à une ViewObject, ni un ApplicationModule, mais à un ClientWebService.

Exemple :

< document_def >

< document name =" DwsGenki " class =" fr.ACE.technicalframework.application.document.ClientWebServiceDocumentImpl " clientwebservice =" Genki "/>

< document_def >

8.8.3 Nouveau type de clause « retrieve »

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

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

Exemple :

Pas de déclenchement (webServiceMethod= "")
< view_type name =" VueGenki " document =" DwsGenki ">

< retrieve >

< client_ws key =" NUL " resolverClass =" fr.ACE.technicalframework.application.resolver.DefaultClientWebServiceResolver " webServiceMethod =""/>

< client_ws key =" EXPORT " resolverClass =" fr.ACE.technicalframework.application.resolver.DefaultClientWebServiceResolver " webServiceMethod =" startExport "/>

</ retrieve >

< sort />

</ view_type >

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

< viewstruct >

…

< view name =" Genki " nbline =" 1 " type =" VueGenki ">

< view_link >

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

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

< param name =" String_1 " domain =" value " field =" 10 "/>

</ retrieve >

</ view_link >

< field />

</ view >

…

</ viewstruct >

9 Nouveaux resolverClass

9.1 Objectifs

Les nouveaux resolver sont disponibles depuis la version130 et sont standards à l’application. Ils permettent en particulier :

9.2 Nouvelles habilitations

Deux resolver déjà présents dans les versions précédentes implémentent l’utilisation des nouvelles habilitations. Il s’agit de :

Par contre le resolver suivant n’implémente pas les nouvelles habilitations, ceci pour une raison de dépréciation (resolver moins performant que ceux cités plus haut) :

SQLQueryResolverContexteUtilisateurHabilitation

9.3 Documentation des resolver de requêtes

9.3.1 Introduction

9.3.1.1 Définitions

Les resolver classes permettent de résoudre les clauses Where définies dans le fichier de configuration. Il en existe plusieurs types et doivent être utilisés à bon escient, on distingue principalement :

Les resolver sont invoqués dynamique par le socle technique (technicalframework), mais sont implémentés sur la couche métier. Il est donc possible de créer ses propres resolver classes spécifiques en fonction des besoins.

Le but des resolver étant de passer dynamiquement des paramètres aux requêtes, ils n’existent que pour les ViewObject (à fortiori pas pour les APIs).

9.3.1.2 Résolution de paramètres

Il existe 2 moyens de remplacer une inconnue par un paramètre avec les resolver :

Le plus simple est de prendre un exemple avec une requête simple qui attend 2 paramètres obligatoires :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ? and codpro= ?

Les paramètres (1 type numérique et 1 type caractère) prendront les valeurs suivantes :

En utilisant un resolver qui remplace les paramètres littéralement, on obtient la requête suivante :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc=1113 and codpro=’TX106’

En utilisant un resolver qui bind les paramètres, la requête reste la même et on va passer les paramètres à Oracle pour qu’il réalise le travail lui-même.

select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ? and codpro= ?

Bind #1 è 1113

Bind #2 è TX106

Alors pourquoi ne pas utiliser un resolver qui bind les paramètres systématiquement ? Simplement parce qu’on ne peut pas dans ce cas passer un opérateur en paramètre (LIKE, >= …). Par exemple, on ne pourrait pas résoudre les requêtes auxquelles on passe des bornes de dates avec des opérateurs. La requête suivante serait insoluble :

select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ? and codpro= ‘?’ and Datcre ? ‘ ?’ and Datcre ? ‘ ?’

Nota bene

 Paramètres littéraux

Dans ce cas, les paramètres de type VARCHAR2 doivent être entourés de quotes sinon la requête sera syntaxiquement erronée.

9.3.1.3 Optimisations et performances

Dans tous les cas, il est préférable d’exploiter les resolver bindant les paramètres, ceci pour 2 raisons :

Par contre dans le cadre de recherches multicritères, il est préférables d’utiliser les classes qui remplacent les paramètres littéralement afin d’obliger Oracle à parser la requête et trouver le chemin d’exécution optimum (explain plan).

Il arrive parfois qu’Oracle ne parvienne pas à trouver le meilleur plan d’exécution en particulier lorsque la requête met en jeu des tables partitionnées. Dans ce cas, le moteur de parsing travaille différemment (dans un cas, il dispose des valeurs dans les prédicats, dans l’autre le binding n’est effectué que lors de l’exécution de la requête).

Pour rappel, le cheminement est le suivant lors de l’exécution d’une requête :

9.3.2 Définition des resolver

9.3.2.1 Pour les objets métiers (BC4J)

n fr.ACE.technicalframework.application.DefaultWhereClauseResolver

Resolver BC4J

Pas de paramètres optionnels, pas de quotes entre ? èBIND

n fr.generix.metier.clauseWhere.BusinessWhereClauseResolver

Resolver BC4J

Résolution des crochets imbriqués en mode exclusif

Paramètres optionnels autorisés, quotes entre ? è LITTERAL

n fr.generix.metier.clauseWhere.BindWhereClauseResolver

Resolver BC4J

Résolution des crochets imbriqués en mode exclusif

Paramètres optionnels autorisés, pas de quotes entre ? è BIND

9.3.2.2 Pour les requêtes dynamiques

n fr.ACE.technicalframework.application.DefaultSQLQueryResolver

Resolver SQL Dynamique

Pas de paramètres optionnels, pas de quotes entre ? è BIND

n fr.generix.metier.clauseWhere.BusinessSQLQueryResolver

Resolver SQL Dynamique

Résolution des crochets imbriqués en mode exclusif

Paramètres optionnels autorisés, quotes entre ? è LITTERAL

n fr.generix.metier.clauseWhere.BindSQLQueryResolver

Resolver SQL Dynamique

Résolution des crochets imbriqués en mode exclusif

Paramètres optionnels autorisés, pas de quotes entre ? è BIND

9.3.2.3 Resolver étendus

Depuis la version 1.4, deux nouveaux resolvers sont disponibles. Ils autorisent le remplacement littéral de paramètres ainsi que le binding. Deux caractères différents sont utilisés suivant que l’on souhaite remplacer littéralement (@) ou binder ( ?).

Ce sont des resolver métiers, les règles habituelles sont utilisées lors des remplacements littéraux (mettre des quotes si la variable est du type VARCHAR et ne pas en mettre si c’est une expression numérique).

n fr.generix.metier.clauseWhere.BindLitteralSQLQueryResolver

Resolver SQL Dynamique

Résolution des crochets imbriqués en mode exclusif

Paramètres optionnels autorisés, @ pour le remplacement littéral et ? pour les bind

n fr.generix.metier.clauseWhere.BindLitteralWhereClauseResolver

Resolver BC4J

Résolution des crochets imbriqués en mode exclusif

Paramètres optionnels autorisés, @ pour le remplacement littéral et ? pour les bind

n fr.generix.metier.clauseWhere.BindLitteralOptionalSQLQueryResolver

Resolver SQL Dynamique

Résolution des crochets imbriqués en mode permissif

Paramètres optionnels autorisés, @ pour le remplacement littéral et ? pour les bind

n fr.generix.metier.clauseWhere.BindLitteralOptionalWhereClauseResolver

Resolver BC4J

Résolution des crochets imbriqués en mode permissif

Paramètres optionnels autorisés, @ pour le remplacement littéral et ? pour les bind

Ces resolvers sont à privilégier dans le cadre des requêtes avec paramètres optionnels, ceci pour plusieurs raisons :

9.3.2.4 Mode permissif

Exemple 1 :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

[ and nompro= ? [ or design1= ?]]

Les paramètres (1 type numérique et 1 type caractère) prendront les valeurs suivantes :

La requête devient :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

and nompro= ?

Exemple 2 :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

[ and nompro= ? [ or design1= ?]]

Les paramètres (1 type numérique et 1 type caractère) prendront les valeurs suivantes :

La requête devient :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

9.3.2.5 Mode exclusif

Exemple 1 :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

[ and nompro= ? [ or design1= ?]]

Les paramètres (1 type numérique et 1 type caractère) prendront les valeurs suivantes :

La requête devient :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

Exemple 2 :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

[ and nompro= ? [ or design1= ?]]

Les paramètres (1 type numérique et 1 type caractère) prendront les valeurs suivantes :

La requête devient :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ?

Ces règles sont valables quel que soit le nombre d’imbrication de crochets.

9.3.2.6 Clause « NULL »

Il existe une clause particulière qui permet de demander au socle de ne pas exécuter de requête : NullClause

Dans certains cas d’utilisation, on peut vouloir ne passer la requête que si tous les paramètres sont disponibles (cas de certaines recherches par exemple). Il suffit alors de définir une requête sans paramètres optionnels (entourés de crochets) et d’utiliser le ResolverClass suivant :

n fr.generix.metier.clauseWhere.BindLitteralNullClauseResolver

Resolver BC4J

Ce resolver prend en compte les jockers @ et ? suivant que l’on souhaite remplacer littéralement ou binder les paramètres.

n fr.generix.metier.clauseWhere.BindLitteralNullQueryResolver

Resolver SQL Dynamique

Ce resolver prend en compte les jockers @ et ? suivant que l’on souhaite remplacer littéralement ou binder les paramètres.

Exemple :

Select Codpro,Nompro,Typpro,Design1 from Pro where codsoc= ? and codpro= ?

Dans ce cas, la requête n’est pas exécutée.

10 Post-filtrage sur un RowSet

10.1 Périmètre d’application

Sont concernées les ViewObject standard et dynamique.

10.2 Principe

Cette fonctionnalité donne la possibilité d’appliquer un filtre supplémentaire à la « clause where » sur le résultat du select, y compris sur les attributs de type « transient », c'est-à-dire les attributs des ViewObject qui ne correspondent pas directement à des colonnes de table et qui ne peuvent pas être inclus dans la clause du select.

10.3 Mise en application

Ce filtre vient compléter les possibilités existantes du filtrage par Retrieve.

La définition de ce filtre se fait vue par vue

A l’image de la clause where, le paramétrage du filtre se compose d’un nom de clé, d’un résolverClass et d’une valeur.

L’alimentation des paramètres de la clause filtre se fait lors de la déclaration du ViewLink dans la ViewStruct. Ces paramètres sont optionnels, ils dépendent de la valeur de la clause définie dans le view_type associée.

10.4 Restriction

Le filtre post select n’est pas performant (reproduction du filtrage de prédicat du moteur Oracle au sein des BC4J), il doit être utilisé avec modération et à bon escient.

11 Résolution de clause « orderby »

11.1 Périmètre d’application

Sont concernées les ViewObject standard et dynamique.

11.2 Principe

Permettre la présence d’inconnues dans la clause orderby, afin de résoudre par exemple des clauses order by de la forme : order by (select chp1 from table1 where chp2 = @ and …)

11.3 Mise en application

Cette nouvelle fonctionnalité vient compléter la saisie existante dans la définition des clauses sort pour les types de vue.

Lors de la définition d’une orderby_clause, il est possible de saisir un resolverClass et une value. Le resolverClass est un nom logique vers un solver de type « sort »

L’implémentation a été réalisée dans XDME.

Lors de la définition du sort du ViewLink, il est possible de saisir les paramètres qui alimenteront les inconnues présentes dans la clause sort. On retrouve les types de paramètres habituel : public, business, value, solved.

11.4 Restriction

Les inconnues de la clause sort doivent être représentée sous forme de « @ » et non de « ? » car le binding de paramètres n’est pas toléré.

12 Client WebService

12.1 Principe

ACE est maintenant capable de communiquer avec des webservices externe à ACE ; aussi bien depuis la configuration que depuis les objets métiers Java.

Pour se faire, le socle fournit les composants de base pour mapper la couche basse de communication (via la bibliothèque Axis) à une utilisation ACE ; à savoir via la configuration et les objets métiers Java.

12.2 Utilisation depuis la configuration/style

12.2.1 Configuration

Basé sur un <clientWebService >, le document (de classe fr.ACE.technicalframework.application.document.ClientWebServiceDocumentImpl) fait le lien entre la vue et le Client WebService (attribut clientwebservice)

C’est la View qui a la responsabilité d’invoquer le webservice.

Comme tout autre type de vue, l’action retrieve positionne sur le document ClientWebService les paramètres ainsi que la méthode du webservice à déclencher.

Pour se faire, la résolution s’effectue via la clause retrieve de nouveau type (<client_ws>), utilisant le resolverClass spécifique fr.ACE.technicalframework.application.resolver.DefaultClientWebServiceResolver ; le nom de la méthode étant stocké dans l’attribut webServiceMethod.

L’action assimilate provoque l’exécution de la méthode du webservice.

12.2.2 Flux de présentation

Comme pour les autres types de document, une vue basée sur un document de type ClientWebService suit cette règle

Exemple :

…

< VueGenki type =" View " name =" Genki " total_business_row =" 0 " nbline =" 1 " numpage =" 1 " nbpage =" 0 ">

< Genki type =" ClientWebService " methodName =" startExport ">

C0A867D50089A585000001197BF0395DE78A1F3880000000

</ Genki >

</ VueGenki >

…

…

< VueGCEService type =" View " name =" GCEService " total_business_row =" 0 " nbline =" 1 " numpage =" 1 " nbpage =" 0 ">

< GCEService type =" ClientWebService " methodName =" assimilate ">

< egx_ws >

< bean_out >

< GCEServiceassimilateOut xmlns =" http://www.ACE.fr/metier/bc4j/integration/common ">

< result info =" CreationPoste ">

< eventHeaderKey >

< purchaseSale > A </ purchaseSale >

< type > CDA </ type >

< eventNumber > 200437 </ eventNumber >

</ eventHeaderKey >

< eventItemKey >

< purchaseSale >A</ purchaseSale >

< type > CDA </ type >

< eventNumber > 200437 </ eventNumber >

< itemNumber > 1 </ itemNumber >

</ eventItemKey >

</ result >

</ GCEServiceassimilateOut >

</ bean_out >

</ egx_ws >

</ GCEService >

</ VueGCEService >

…

12.3 Utilisation depuis les objets metier Java

Une nouvelle méthode est publiée sur l’interface fr.ACE.technicalframework.business.applicationmodule.common.GnxApplicationModule :

public GnxClientWebService createClientWebService(String clientWebServiceName) throws ApplicationModuleException;

Exemple :

GnxBusinessClientWebService genki = (GnxBusinessClientWebService)createClientWebService( "genki" );

try

{

genki.invoke( "startExport" , new Object[] { "10" });

}

catch (ClientWebServiceException e)

{

// Code Here

}

12.4 Corollaire

12.4.1 Refactoring Java

Metiertools\bin\template\template_j2ee1.4\WebservicePublicationImplementation.xdt

12.4.2 Refactoring Conf

13 Evolution des librairies

13.1 Le moteur de conception BIRT

C’est une application autonome basée sur le moteur Eclipse (RCP : Rich Client Platform).

C’est un fichier zip du type birt-rcp-report-designer-2_2_1_1.zip

13.2 Intégration du moteur d’exécution BIRT

Le moteur BIRT nécessite la présence des librairies associées. Ces librairies doivent être présentent sur l’application qui génère le rendu final via le moteur BIRT. Elles sont présente dans l’ear de livraison et se trouve sous WEB-INF, au même niveau que le répertoire lib contentant les jars applicatifs.

Ces librairies comprennent :

(fr.ACE.technicalframework.datatools.enablement.oda.xml_1.0.0.jar)

A titre d’exemple, voici une représentation de l’arborescence des packages :

14 Environnement d’exécution

14.1 Birt

14.1.1 Pour l’exécution d’eGX sans lancer d’édition BIRT

Ajouter dans WEB-INF\lib les jars suivants :

coreapi.jar

engineapi.jar

14.1.2 Pour l’exécution d’une édition BIRT

Sous WEB-INF\lib

com.ibm.icu_3.6.1.v20070417.jar

js.jar

flute.jar

org.w3c.css.sac_1.3.0.v200706111724.jar

Il faut en plus le moteur BIRT autonome, contenu dans un répertoire nommé Platform. L’emplacement de ce répertoire dépend du paramétrage d’ACE.properties.xml. Voir le chapitre sur l’intégration du moteur BIRT.

15 Divers

15.1 Flux de présentation

De nouvelles sections font leur apparition afin de fournir plus d’informations sur le contexte d’exploitation de l’application et/ou de faciliter le développement sur la couche de présentation (feuille de style).

15.1.1 Présentation des timers déclenchés

Les timers déclenchés pour une session utilisateur sont désormais visible dans le flux de présentation. Dans le BTOE, les timers sont déclenchés depuis la bannière. Le déclenchement est possible sous 2 conditions :

Pour rappel :

Nœud : /layout_data/application_data/logging

15.1.2 Clonage des nœuds error

Afin de faciliter le développement, les nœuds « error » sont clonés vers un nœud unique. Cela permet d’éviter les xpath « // » qui sont extrêmement coûteux dans les feuilles de style. Les nœuds « information » et « annotation » (utilisé par le document PL/SQL) sont eux-aussi dupliqués à cet endroit.

Nœud : /layout_data/application_data/messages/errors/error

15.1.3 Rendu du manifest

Cela fait suite à une demande des équipes projets : pouvoir facilement connaitre l’environnement sur lequel on utilise l’application. ACE étant une application J2EE, un répertoire META-INF contenant un manifest est systématiquement présent à la racine du module déployé. Ce manifest contient des informations de base (mais il est possible d’en ajouter de nouvelles via la tache ant qui permet de générer les ear), en particulier la date et le numéro de construction de l’ear.

L’intégralité des informations contenues dans le manifest sont reportées dans un nouveau nœud du flux de présentation. Il devient donc possible d’afficher ces informations depuis une feuille de style.

Exemple :

Manifest :

Manifest-Version: 1.0

Ant-Version: Apache Ant 1.6.5

Created-By: 1.5.0_12-b04 (Sun Microsystems Inc.)

Built-By: roa

Specification-Title: ACE ) Collaborative Entreprise

Specification-Vendor: ACE

Specification-Version: 140_J2EE1.4

Implementation-Title: ACE ) Collaborative Enterprise

Implementation-Vendor: ACE

Implementation-Version: 140_J2EE1.4_2

Generation-Time: 2008-02-17 13:27:40

Remarque : si le fichier n’existe pas, ce n’est pas considéré comme un cas d’erreur et rien n’est publié dans le flux de présentation.

Nœud : /layout_data/application_data/manifest/property

15.1.4 Propriétés « libres »

Il est possible d’exploiter des « informations libres » provenant du fichier de propriétés techniques. Le résultat est le suivant :

Le fichier de propriétés met en place des informations de la manière suivante :

Exemple d’application : définition d’un paramètre déterminant le type de fichier de paramétrage utilisé au runtime de l’application (mode production ou mode développement).

Nœud : /layout_data/application_data/properties/internal/misc

15.2 Noms des fichiers log

Le nom des fichiers logs générés sont désormais pilotables suivant 5 paramètres :

Cela permet :

D’autres informations sont fournies dans le chapitre concernant l’externalisation des paramètres techniques. On notera aussi que ces paramètres sont modifiables « à chaud » depuis la console JMX.

15.3 Séparation du moteur et du type de rendu

Des modifications de la configuration sont ajoutées pour séparer le moteur de rendu final et le type de rendu.

Il y a quatre moteurs de génération de rendu final :

Les modifications sont :

Les valeurs de couple moteur/type de rendu possibles

Anciennes dénominations Nouvelles dénominations
xml_pres xml_pres
chart chart/svg
xsl xsl/html
pdf fop/pdf
  fop/png
  fop/mif
  fop/svg
  fop/txt
  fop/xml
  birt/html
  birt/pdf

15.4 Moteur d’édition BIRT : Nouveau moteur de rendu

15.4.1 Présentation :

Le projet BIRT, Business Intelligence and Reporting Tools, propose un système de création de rapports pour les applications Web

Les deux principaux composants de BIRT sont un outil de conception de rapports basé sur Eclipse et un moteur d'exécution à installer dans un serveur d'applications J2EE.

15.4.2 Utilisation :

L'utilisation de BIRT peut se résumer de la façon suivante :

Chaque rapport est décrit dans un fichier (au format XML) de type .rtpdesign. L'éditeur associé à ce type de fichiers permet de construire graphiquement le rapport (à la façon d'un traitement de texte).

Le but d'un rapport est d'afficher des données. Pour chaque rapport, l'outillage de BIRT propose une vue 'Explorateur de données' qui permet la définition d'une ou plusieurs 'sources de données' (par exemple une base de données relationnelles) et d'un ou plusieurs 'jeux de données' extraits de la source de données (par exemple les champs renvoyés par une requête SQL). Les 'jeux de données' constituent les données à afficher. Dans le cas d’eGX, la source de données principale est le flux de présentation.

L'édition du rapport se fait en mode graphique en insérant les différents composants graphiques proposés (Texte, image, tableau, liste, graphique, ...). Les valeurs affichées par ces composants peuvent être soit statiques, soit extraites des 'jeux de données' (le flux de présentation) , soit calculées en utilisant des formules prédéfinies et des scripts écrits en JavaScript.

A tout moment, le concepteur du rapport peut demander son exécution directement à partir des menus de BIRT. La prévisualisation se fait au format HTML ou PDF.

La mise en exploitation se fait en déployant le rapport sur le serveur d'applications J2EE à l’image des feuilles de style classiques.

15.5 Déport de la génération du rendu

Afin d’alléger le serveur d’application « principal », il est possible de déporter la phase de génération du rendu sur un autre serveur d’application.

TODO : doc du schéma.

Dans la conf.

<render_application_def >

<render_application renderType =" xsl/html " url =" http://fx-hhareux:8888/GCE130/render/ServletRender "/>

</render_application_def >

Nouvelle action

<action name="render" class="fr.ACE.technicalframework.application.action.Render"/>

15.6 MaxFetchSize métier

Ce paramètre est dorénavant pilotable depuis la couche métier via la méthode setMaxFetchSize(int) portée par l’interface GnxViewObject.

Deux nouveaux attributs optionnels font leur apparition dans ACE.properties :

A noter :

15.7 Nouvelles règles d’écriture sur les fichiers XSL communs

Le fichier e-GX.xsl a été découpé afin de faciliter sa maintenance et sa lisibilité :

On notera aussi que la feuille de style recensant les templates de transformations pour les listes de valeurs à lui aussi été réécrit dans un but de performance et de maintenance.

Chacun de ces fichiers contient un cartouche explicatif fournissant les détails nécessaires au développement. Il convient aussi de se référer aux règles de développements de la couche de présentation.

15.8 Framework Ajax

Un framework Ajax est désormais disponible et utilisable depuis la GCE140, il permet en particulier :

Une documentation dédiée à cet effet est disponible.

15.9 Nouvelle action de cinematique/navigation

Une nouvelle action de navigation sur la ligne courante est proposée : setBusinessLine .

Description :

A l'image de l'action setLine qui prend en paramètre un nom de vue et un numéro de ligne (sur la page courante) pour se positionner, la nouvelle action setBusinessLine (même signature d'entrée que setLine) permet de passer le numéro de ligne absolu (attribut business_row_index dans le flux de présentation).

Déclaration dans le fichier de configuration :

< action name =" setBusinessLine " class =" fr.ACE.technicalframework.application.action.SetBusinessLine ">

< required >

< param name =" view " maxOccurs =" 1 " minOccurs =" 1 " type =" View "/>

< param name =" value " maxOccurs =" 1 " minOccurs =" 1 " type =" String "/>

</ required >

</ action >

15.10 XDME

Quelques travaux mineurs, donc indispensables ( !) ont été réalisés sur XDME. :

On notera que par défaut, le look & feel est dorénavant celui de Windows XP. Il est possible - néanmoins – de modifier le L & F parmi ceux proprosés.

Exemple de fichier jnlp :

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

<jnlp codebase="file:///F:/xdme/GCE140/" href="confeditor.jnlp">

<application-desc main-class="fr.ACE.tools.confeditor.ConfEditor"/>

<information>

<title>XDME ACE 1.4</title>

<vendor>ACE</vendor>

<homepage href="file:///F:/xdme/GCE140/"/>

<description>XDME ACE 1.4</description>

<icon href="ACE.jpg"/>

</information>

<security>

<all-permissions/>

</security>

<resources>

<j2se version="1.5+" max-heap-size="192m"/>

<jar href="confeditor.jar"/>

<jar href="ressources.jar"/>

<jar href="technical_framework.jar"/>

<jar href="xmlparserv2.jar"/>

<jar href="configjaxb.jar"/>

<jar href="OfficeLnFs_2.3.jar"/>

<jar href="looks-2.1.4.jar"/>

<jar href="PgsLookAndFeel-0.5.jar"/>

<jar href="ojdbc14.jar"/> <extension name="Jaxb" href="jaxb.jnlp"/>

<property name="javax.xml.parsers.DocumentBuilderFactory" value="oracle.xml.jaxp.JXDocumentBuilderFactory"/>

<property name="xdme.lnf" value="office"/>

</resources>

</jnlp>

15.10.1 Look & Feel

XDME intègre dorénavant un sélecteur de look’n feel. Il permet de choisir parmi différentes interfaces graphiques disponibles.

Le look’n feel « Window »

C’est pratique !

Le changement d’interface graphique ne requiert pas le redémarrage de XDME. Cela signifie qu’il est possible de changer de look’n feel à tout moment, sans avoir à sauvegarder la configuration en cours.

Le look’n feel sélectionné est automatiquement sauvegardé comme look’n feel favori. Cela signifie qu’au prochain démarrage de XDME, c’est le dernier look’n feel sélectionné qui sera utilisé !

Le look’n feel « Office »

Il y a le choix !

Les look’n feels actuellement supportés sont au nombre de 6 :

Par défaut, le look’n feel utilisé est « XP ». Il est possible de changer de look’n feel via le menu Edition > Changer d’interface.

On notera que kunstsoff.jar disparait du packaging et que 2 nouvelles librairies font leur apparition pour gérer les nouveaux L & F. Les fichiers de démarrage ont été modifiés en conséquence (jnlp).

Menu permettant de sélectionner un autre look’n feel

Problème(s) connu(s)

Le changement de look’n feel peut provoquer des incohérences d’ordre purement graphique. Il s’agit d’un bug Java connu. Cela n’affecte en rien les fonctionnalités de XDME !

Si des bugs graphiques apparaissent, la solution consiste simplement à quitter puis à relancer XDME.

15.10.2 Boutons de validation

Des boutons « OK » et « Annuler » ont été ajoutés dans l’éditeur de requête.

15.10.3 Sauvegarde

Les temps de sauvegarde ont été améliorés, un indicateur fait son apparition pour les opérations « longues ».

Un texte indique la phase de sauvegarde en cours (marshalling, écriture XML …)

15.10.4 Commentaires

Il devient possible de positionner des commentaires sur les éléments suivants :

Il n’est pas prévu de rendre ces commentaires traduisibles en fonction de la langue de l’utilisateur.

Exemple sur une ViewStruct :

15.10.5 Mémoire utilisée

La mémoire consommé est visualisable sur la barre d’état d’XDME. :

15.10.6 Vérification de la quantité de mémoire allouée à XDME

Qui n’a jamais eu la mauvaise surprise d’être bloqué lors de l’enregistrement d’un fichier de configuration pour cause de mémoire insuffisante ? Avec la nouvelle version de XDME, c’est désormais de l’histoire ancienne !

Sélection du fichier de configuration

Les origines du mal

Dans XDME, la phase la plus consommatrice en terme de mémoire est la sauvegarde. Il pouvait donc arriver que l’on parvienne à ouvrir puis à travailler sur un fichier de configuration et que l’on soit bloqué lors de la sauvegarde !

Barre de progression pendant la phase d’ouverture

Principes du contrôle

Désormais, XDME vérifie que la quantité de mémoire allouée est suffisante et ce dès la phase d’ouverture du fichier. Si ce n’est pas le cas, un message d’avertissement est remonté, ce qui permet de ne pas travailler inutilement sur la configuration.

La mémoire requise est de 20 Mo pour chaque 1 Mo du fichier de configuration. Par exemple, un fichier de 9 Mo nécessitera l’allocation de 180 Mo de mémoire à XDME.

Message d’avertissement en cas de mémoire insuffisante

Problème(s) connu(s)

Le ratio mémoire requise / taille du fichier fixé dans XDME est volontairement élevé afin de s’assurer qu’il sera possible de sauvegarder la configuration. Toutefois, il est peut arriver que la quantité de mémoire nécessaire soit en réalité inférieure à celle calculée par XDME.

Cela signifie qu’il est dans certains cas possible d’ignorer le message d’avertissement remonté par XDME. Attention, cela se fait à vos risques et périls !

15.10.7 Nouveautés de l’éditeur de Viewlink

Plusieurs innovations dans l’éditeur de Viewlink sont au programme :

A cette occasion, la fenêtre a fait l’objet d’un relooking offrant une meilleure lisibilité.

Nouvelle interface par onglets

Interface allégée

Les trois types de clauses bénéficient dorénavant chacun de leur propre onglet :

Les trois types de clauses étant paramétrables, chaque onglet se compose :

Des boutons OK et Annuler dont leur apparition, à ce titre la fermeture de la boite de dialogue via la croix ne sauvegarde pas les modifications apportées au ViewLink.

La nouvelle clause Filter

Viewer de requête SQL

Plusieurs améliorations ergonomiques ont été apportées sur ce composant :

Le nouvel onglet Filter

Clause Filter

Destinée à filtrer le résultat d’une requête SQL sur des champs de type « transient », la clause Filter fait son apparition dans XDME.

Dans l’onglet View, il existe désormais un onglet Filter actif uniquement pour les vues de type BC4J ou dynamique. Il permet de définir les clauses Filter de la View courante.

Au niveau de l’éditeur de Viewlink, il existe également un onglet Filter actif pour les mêmes types de vues. Il sert à associer une clé publique à une clause Filter donnée. A noter que la clé publique est à choisir parmi les différentes clés publiques définies au niveau des clauses Retrieve. Il est également possible de définir les paramètres de la clause sélectionnée.

Problème(s) connu(s)

Il est possible que certains bugs graphiques subsistent dans le visualiseur de requêtes SQL. Il s’agit malheureusement d’un bug Java connu. Ce problème peut disparaître en redimensionnant la fenêtre de l’éditeur de Viewlink.

15.10.8 WebServices

15.10.8.1 « Clients »

15.10.8.2 « Serveurs »

15.10.9 Divers

Les exceptions sont remontées de manière plus explicite lorsqu’il y a un problème lors de la sauvegarde. D’autre part, il devient impossible d’ouvrir un fichier de configuration dont la taille est inadéquate en regard de la mémoire maximum allouée à la JVM (paramètre Xmx).

Les boîtes de dialogue peuvent dorénavant être fermées au moyen de la touche « Escape » (fonctionnement habituel des fenêtres en environnement Windows).

15.11 Nouveau viewer SVG pour IE.

Adobe arrête le support et le développement de son viewer nommé SVGViewer en 2009. De plus, la dernière version n’est pas compatible windows VISTA.

ACE propose l’utilisation du plugin de l’éditeur Examotion.

Ce plugin, nommé RENESIS Player, est disponible à l’adresse suivante :

Les principales caractéristiques de RENESIS player sont

Technical Sheet

Mime Type(s): image/svg+xml, image/svg-xml
Others: Supports gzip compressed svg files (.svgz, svg.gz)
Data Embedding: Supports data protocol with base64-encoding
Platforms: Windows® XP-Vista, Windows Mobile® 6, MacOS X® Linux
Integration: ActiveX® Internet Explorer®, .NET®, Window File Explorer®
Supported Standards: SVG 1.1, XML 1.0, CSS 2.1, Ecmascript/Javascript

Des informations complémentaires ainsi qu’un support sont disponibles sur le site de l’éditeur Examotion : http://www.examotion.com

Sujet parent: Modifications apportées à ACE 1.4 après le 9 novembre 2009
Aurea Logo
Copyright © 2020. Aurea Software, Inc. ("Aurea")