Delta Socle ACE 1.4

Ce document résume les nouvelles fonctionnalités disponibles sur le socle technique pour la version ACE 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.

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 n’a pas encore la capacité de gérer plusieurs « conf » simultanément, cette option sera disponible ultérieurement sur cette version.

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 :

· Déploiement d’une application unique (développement, production …) : l’ear sera toujours le même, quelle que soit la plateforme support

· Centralisation des paramètres au niveau du socle technique

· Modification des paramètres techniques « à chaud » (application démarrée)

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.

Exmple pour un mode « développement » :

-DgceProperties=ACE_developpement.properties.xml

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 :

· Suppression de certains éléments de configuration.xsd vers ACE.properties.xsd

· Mise à niveau de la configuration (suppression des éléments devenus inutiles)

· Mise en place des mêmes éléments dans le nouveau fichier de propriétés

· Mise à niveau d’XDME (suppression de la gestion des paramètres 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 version GCE140.

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.

· cacheActive è /config/server/cache/application/@active

· traceLevel è /config/server/xmlPresentationFile/writeOnDisk/@active

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

· frameMaxNum è /config/application/control/maxFrameNumber/@value

· workingDirectory è /config/server/log/workingDirectory/@value

· xmlPresentationFile è /config/server/xmlPresentationFile/prefix/@value

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.

· defaultLoginBusinessView è /config/application/authentification/loginBusinessView/@name

· uuidManage è /config/application/uuidManagement/uuidManage/@active

· defaultUserRecognize è /config/application/authentification/defaultUserRecognize/@active

· checkId è /config/application/uuidManagement/checkId/@active

· declarativeAuthentification è /config/application/authentification/declarative/@active

· defaultPdfNbLine è /config/application/pdf/defaultPdfNbLine/@value

· sessionControlActive è /config/application/control/sessionControl/@active

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 :

· les feuilles de styles.

· les actions.

· les resolvers de clause retrieve ou de requête SQL dynamique.

· les documents.

· les définitions de ViewObject et ApplicationModule (BC4J).

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 :

· Nom du contexte applicatif

· Nom de la BusinessView

· Valeur de l’UUID

· Code utilisateur

· Heure de génération du fichier

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 :

· defaultClient : Client par défaut

· delay : Temps d'attente en ms entre deux scrutations de lecture de la réponse du serveur xmlRpc. Permet de limiter la consommation CPU (Voir attribut timeOut). Valeur par défaut de 10 ms.

· maxInstance : Nombre maximal par défaut d'instances dans le pool de xmlRpc.

· minInstance : Nombre minimal par défaut d'instances dans le pool de xmlRpc

· timeOut : Temps d'attente en secondes de la réponse du serveur xmlRpc. Représente la durée maximale de la boucle de scrutation de la réponse du serveur xmlRpc. Valeur par défaut de 5 s.

Attributs du nœud client :

· Name : nom du client

· Delay : comme pour le client par défaut

· timeOut : comme pour le client par défaut

· port : Port d'écoute du serveur xmlRpc.

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 :

· Name : nom du timer

· Active : activation du timer (valeur true / false)

· Precision : précision remontée par le timer

· Level : niveau de prise en compte des temps remontés

2.3.5.16 Pilotage de la plateforme BIRT

Nœud : /config/server/birt

Attributs :

· engineHome : définition de la localisation des librairies du moteur BIRT

· mode : standalone ou déporté

2.3.5.17 Pilotage JMX

Nœud : /config/server/jmx

Attribut :

· Active à true pour permettre l’utilisation des MBean fournis par le socle technique

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

· domainName

· containerType

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 version GCE140.

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 version GCE140, 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 :

-DgceProperties=ACE_developpement.properties.xml

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 :

· Modification de paramètres applicatifs « à chaud »

· Déclenchement de timers via la console et visualisation des données (graphiques ou non)

· Remontée d’alertes via un système de notifications (erreurs applicatives …)

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 :

· -Dcom.sun.management.jmxremote=true

· -Doc4j.jmx.security.proxy.off=true

Et au niveau d’ACE.properties :

· Se référer à la section de documentation correspondante

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 :

· Indicateurs de performance

· Informations de version

Une opération :

· Rechargement du fichier de configuration : permet de faire du développement avec les caches actifs par exemple !

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.

· DepHabBusinessFlowImpl è liste des dépôts habilités à l’utilisateur (prend en compte le PPE ACCDEP s’il est positionné)

· SocBusinessFlowImpl è liste des sociétés en service

· EtaEveBusinessFlowImpl è liste des codes états disponibles pour la cible de paramétrage (codeta, valeta et soleta) ainsi que pour les cibles représentant le même couple achvte/typeve dont la fonction est habilitée à l’utilisateur

· HabBusinessFlowImpl è publication de l’habilitation de l’utilisateur courant à une cible de paramétrage ou une BusinessView (dans le cas d’utilisation des nouvelles habilitations : PPE HAB_CS non présent). Cela permet de conditionner l’affichage des onglets par exemple

· TblCompletBusinessFlowImpl è publication de champs supplémentaires par rapport à TblBusinessFlowImpl (lib2, lib3, num1, num2, num3, dec1, dec2, dec3, FiltreTbl)

· TieBusinessFlowImpl è génération d’une liste de tiers dont le type est passé en paramètre

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

· GENDEPHAB è DepHabBusinessFlowImpl

· GENSOC è SocBusinessFlowImpl

· GENETA è EtaEveBusinessFlowImpl

· GENHAB è HabBusinessFlowImpl

· GENTBLC è TblCompletBusinessFlowImpl

· GENTIE è TieBusinessFlowImpl

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 :

· PPE:BORPZN.A1

· URL:maCodznDeDebut

· …

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

· Découpler les BusinessView de leur cible de paramétrage

· Ne plus être obligé de dupliquer l’intégralité des BusinessView lors de la création d’un nouveau type d’événement (on ne développe plus que par exception)

· Facilitateur de maintenance car il devient possible de mutualiser les BusinessView

· Permet de router une BusinessView sur une autre

· …

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 :

· UT_BV_DEF : liste des BusinessView de l’application

· UT_BV_MODELE : modèle de distribution des BusinessView

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

· Les BusinessView « réelles » ou « physiques » : définies dans le fichier de configuration

· Les BusinessView « fictives » : uniquement définies dans la table

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 :

· Celles du socle technique

· Celles dont le nom débute par BindLitteral*

5.2.4 QCS fourni en ACE 1.4

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

· fr.generix.metier.solver.ProduitQueryCompletionSolverImpl

Il prend en compte les PPE suivants :

· CODBLC

· TYPPR1

· NATPRO

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 ACE 1.3.

5.3.1 Fournisseurs de valeurs : ValueProvider

Ce fournisseur est utilisé principalement dans les ViewLink.

Trois nouveaux espaces de nommages sont disponibles :

· URL : tout paramètre provenant de l’URL

· CHP : tout paramètre ayant l’espace de nommage « chp : » sur l’URL

· SES : informations provenant de la session métier

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 :

· UTI : l’utilisateur courant, soi-même !

· LANG : la langue de l’utilisateur courant

· TARGET : la cible de paramétrage courante

· ENTITY : l’entité courante (société)

· CODEETBUTI : le code établissement de l’utilisateur

· FAMPDV : la famille PDV de la société sur laquelle on est connectée

· FAMSOC : la famille PDV de la société sur laquelle on est connectée

· LONGUEURCOMPTE : longueur compte finance

· MULTIETAB : gestion du multi-établissement (champ O/N)

· NIVSOC : la position de la société courante dans la hiérarchie multi-entités

· NIVUTI : le niveau de l’utilisateur (UT_UTI.NIV)

· SIGPDV : le sigle PDV

· SIGSOC : le sigle société

· P1EXCOD : Exercice par défaut de l'utilisateur

· P1EXCPP : Plan comptable de l'exercice

· P1EXDEB : Date début de l'exercice

· P1EXFIN : Date fin de l'exercice

· STATUTETBUTI : Statut de l'utilisateur en multi établissement (1=Mono, 2=Tout établissement, 3=Multi établissement)

· SUPERUSER : renvoie TRUE OU FALSE suivant que l’utilisateur est un super-utilisateur ou pas (paramétrage via le PPE ADMNIV)

Rappel des espaces de nommage auparavant disponibles :

· PPE : valeur d’un PPE

· PEV : paramétrage de la cible

· VLB : paramètre « business »

· VLP : paramètre « public »

· MEV : récupération du CODSOC_PHY d’un couple entité/segment

Rappels des fonctions :

· DECODE (valeur1, valeur2, resultat1, resultat2) – fonctionnement « SQL like »

· INSTR (valeur1, valeur2) – fonctionnement Java (String.indexOf)

· SUBSTR (chaine, pos1, pos2) – fonctionnement Java (String.substr)

· CONCAT (chaine1, chaine2 … chaineX)

· LPAD (chaine, valeur, longueur) – fonctionnement « SQL like »

· RPAD (chaine, valeur, longueur) – fonctionnement « SQL like »

· UPPER (chaine) – fonctionnement « SQL like »

· LOWER (chaine) – fonctionnement « SQL like »

· EXPR (expression) – permet de forcer un calcul d’expression

· NVL (chaine, valeur) – fonctionnement « SQL like », renvoie un espace si le contenu de la chaîne est vide.

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

· Cette API ne peut qu’obtenir de l’information ; pas de mise à jour possibles. Si on tente de le faire (utilisation d’une action modifiante du style create, propose, assimilate, …), le flux de présentation contiendra l’erreur "TF_E000319" (La cinematique '@' n'est pas conforme car elle génère une modification de données).

· Les définitions de BusinessView, ViewStruct, View, … doivent être disponibles dans le fichier de configuration.

6.3 Définition technique

· Package : fr.ACE.technicalframework.businesscomponent.applicationmodule.common

· ApplicationModule : BusinessViewRenderer

· Service : renderXml

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 :

· Mise en place de politiques de destructions des objets en fonction de paramètres (poids, temps de persistance en pool …)

· Possibilité de créer de nouvelles politiques via des classes Java

· Pilotage à chaud depuis une console JMX

· …

7.2 Nouvelle implémentation des pools

7.2.1 Principe

Jusqu’à la version ACE 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 ;

· en création

· en destruction

· en sortie de pool

· en retour en pool

· en invalidation

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 :

· Il y a un ensemble de pool dédié au pool de RootApplicationModule (SessionMetier). Cet ensemble ne contient donc qu’un pool indépendant des utilisateurs.

· Chaque utilisateur dispose de son ensemble de pools. Ces pools ne sont pas partagés entre utilisateur.

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 :

· Durée de vie maximales quelque soit l’activité de l’objet

· Temps de non utilisation de l’objet.

· Politique externe par le calcul d’un « poids » pour chaque objet du pool.

La politique externe de nettoyage est :

· soit globale à l’ensemble des pools,

· soit locale à un groupe de pool,

· soit locale à un pool.

La fréquence de nettoyage :

· Par période : Le nettoyeur passe selon une périodicité fixé.

· Par notification : Possibilité de réveiller le nettoyeur si la capacité d’un pool dépasse la taille fixée plus un overhead autorisé.

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 >

…

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 :

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.

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 dépréciation d’un élément (BusinessView, ViewStruct et ViewDef)

· Un commentaire (BusinessView, ViewStruct et ViewDef)

· depthCount devient optionnel

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 :

· Pas de valeur è comportement habituel

· deprecated è cet élément sera supprimé du fichier de configuration dans une version ultérieure, une information est logguée dans egx.log

· unusable è l’élément n’est plus utilisable et le socle technique remontera une exception (une page d’erreur) au runtime en cas d’utilisation

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

· BusinessView

· ViewStruct

· View (ViewDef)

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 :

· Une homogénéisation du nombre de lignes à ramener par requête définie (niveau plus fin que sur la ViewObject)

· Tout en évitant de déclarant une nouvelle ViewObject uniquement pour changer maxFetchSize

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 :

· nothing : rien de spécial ! c’est le comportement par défaut qui correspond au fonctionnement habituel.

· returnToPool : l’objet est renvoyé en pool à la fin du traitement de la requête applicative, c'est-à-dire jute avant son affichage. Cet objet est donc disponible pour les autres traitements de requêtes.

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 :

< 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 version GCE130 et sont standards à l’application. Ils permettent en particulier :

· D’utiliser en même temps des variables bindées (? ) et des remplacements littéraux (@ )

· D’être plus performant lors du décodage d’une requête comportant des paramètres optionnels

· De proposer un nouveau mode de fonctionnement (exemple : on ne passe pas la requête si un seul des paramètres obligatoires n’est pas renseigné)

· Et enfin de gérer différemment les imbrications des paramètres optionnels

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 :

· TiersHabilitation

· UtilisateurHabilitation

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 :

· Ceux qui s’appliquent aux BC4J

· Ceux qui s’appliquent aux ViewObjects dynamiques

· Ceux permettant de réaliser des actions bien spécifiques (ramener l’utilisateur connecté …)

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 :

· En remplaçant littéralement le paramètre

· En bindant le paramètre

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 :

· Codsoc è 1113

· Codpro è TX106

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 ? ‘ ?’

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 :

· Au niveau de la base de données, une requête bindée est toujours considérée comme identique par Oracle, quels que soient les paramètres qu’on lui passe. Une fois une requête parsée par Oracle, le plan d’exécution reste en SGA ce qui permet l’économie d’un nouveau parsing.

· Au niveau des pools d’instances sur le serveur d’application, le même principe est appliqué. Pour une requête donnée, on aura toujours une instance et éventuellement plusieurs rowsets si on a appliqué des paramètres différents à la requête è gain en mémoire et gain en CPU puisqu’on instancie moins d’objets

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

· Ils sont plus souples d’utilisation

· Ils résolvent les requêtes plus rapidement (optimisation au niveau Java)

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 :

· Codsoc è 1113

· Nompro è MON LIBELLE

· Design1 è null è le paramètre ne contient pas de valeur

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 :

· Codsoc è 1113

· Nompro è null è le paramètre ne contient pas de valeur

· Design1 è MA DESIGNATION

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 :

· Codsoc è 1113

· Nompro è MON LIBELLE

· Design1 è null è le paramètre ne contient pas de valeur

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 :

· Codsoc è 1113

· Nompro è null è le paramètre ne contient pas de valeur

· Design1 è MA DESIGNATION

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

· Codsoc è 1113

· Codpro è null è le paramètre ne contient pas de valeur

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.

· Nouveau type de document : ClientWebServiceDocument

· Nouveau composant Java : GnxClientWebService

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

· Déplacement des sources webservice « serveur » du package fr.ACE.technicalframework.application.webservice vers fr.ACE.technicalframework.business.webservice.server

· Modification des trains de compilation (template de publication des webservices) :

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

12.4.2 Refactoring Conf

· Déplacement des éléments de configuration des webservices serveur d’ACE dans le fichier de configuration :

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 :

· Le moteur Eclipse,

· Les plugins BIRT,

· Le plugin fournis par eGX

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

· Les plugins annexes utilisés par BIRT.

· Pour un poids d’environ 26 Mo.

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 :

· Sous OC4J

coreapi.jar

engineapi.jar

· Sous WAS

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

Sous WEB-INF\lib

· Sous OC4J

com.ibm.icu_3.6.1.v20070417.jar

js.jar

flute.jar

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

· Sous WAS

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 :

· Le niveau de l’utilisateur doit être supérieur à 89 (UT_UTI.NIV)

· Le tiers utilisateur (type de tiers personnel) doit avoir un média de type PHR renseigné.

Pour rappel :

· Data è trace des ordres SQL

· Timer è temps d’une requête http et temps des APIs

· XSLT è temps de parsing des feuilles de style

· View è temps de génération du flux de présentation

· Action è temps d’exécution des cinématiques d’action

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 :

· Nom de la BusinessView

· Nom du contexte applicatif (paramètre frame)

· Nom de l’utilisateur

· La date et l’heure

· L’UUID

Cela permet :

· De disposer de tous les fichiers générés, même lors d’une utilisation concurrente de l’application (en mode production par exemple ou sur un serveur de tests)

· De ne plus avoir à chercher le fichier de présentation qui nous intéresse lors d’un debug

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.

Les valeurs de couple moteur/type de rendu possibles

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 :

· overallMaxFetchSize è fusible (valeur -1 si infini : valeur par défaut) permettant de spécifier le maximum de row que l’on s’autorise à fetcher depuis la couche métier.

· maxRowForDestroy è fusible permettant de ne pas remettre en pool un RowSet dépassant la valeur précisée dans l’attribut (1000 par défaut), dans ce cas on le détruit directement afin de ne pas consommer de mémoire inutilement.

A noter :

· Il n’y a donc plus de limite sur le nombre de row que peut utiliser le métier, contrairement au pilotage fait dans le fichier de configuration

· Le paramètre fetchSize est « auto-piloté » sur la couche métier lorsqu’on travaille sur la clé primaire de la table (positionné à la valeur 1)

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

· ACE_template_match.xsl è templates nommés (GnxTable, GnxSort …)

· ACE_template_name.xsl è templates de transformations (dates, numériques …)

· ACE_global_variable.xsl è variables globales à l’application

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 :

· De réaliser des rafraichissements partiels de pages

· D’exécuter des URL de manière masquée (exemple : killSession …)

· D’alimenter en retour des champs visibles à l’écran (à la manière d’un mode C/S)

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

· Optimisations sur le temps de sauvegarde

· Les nœuds optionnels sont supprimés afin de limiter la taille de la conf

· Blindage lors de la sauvegarde (conservation du .bak contenant l’heure système en cas de problème)

· Limitation de la consommation mémoire

· Possibilité de visualiser la mémoire consommée

· Synchronisation montante avec la table UT_BV_DEF

· Liste de valeur sur la liste des solveurs de ViewLink

· Corrections de bugs mineurs et blindage du code

· La saisie des clauses Where et OrderBy pour les ViewObject (section exploitée par les WebServices)

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 »