Delta Socle ACE 1.6.0 (release note)

Ce document résume les nouvelles fonctionnalités disponibles sur le socle technique de la version ACE 1.6.0.

Ce socle se nomme 7.0, dorénavant les versions du socle technique sont découplées de la version d’ACE afin d’apporter plus de souplesse quant aux développements de cette couche.

Comme à chaque nouvelle version, des travaux de fond ont été réalisés dans l’optique de limiter encore plus la consommation mémoire, ainsi que d’améliorer les performances brutes de l’application.

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 Nouveau versioning du socle technique

1.1 Introduction

1.1.1 Objectifs

Le découplage du socle technique du reste de l’application ACE a plusieurs objectifs :

· Pouvoir livrer un nouveau socle technique (au sens version) sans délivrer le reste de l’application

· Permettre la réalisation de spécifiques clients sur la version courante sans avoir à modifier une version précédente

· Proposer à l’avant-vente des nouveautés techniques bien amont de la sortie d’une version ACE

De fait, le rythme de sortie des versions du socle devient indépendant du rythme figé par ACE, cela permet de réagir beaucoup plus rapidement à l’ensemble des demandes.

Dans les faits, une version d’ACE pourra se baser sur plusieurs versions du socle technique. Un changement de version majeur sur le socle technique indiquera une incompatibilité sur les versions ACE précédentes (exemple : un changement de structure d’une table utilisée par le socle).

1.1.2 Limitations

La matrice de compatibilité sera fournie par l’équipe socle, sous la forme d’un document de ce type. Il s’agira d’un release note technique directement lié à une version du socle donnée.

Tant que possible, nous éviterons des modifications structurelles sur le fichier de configuration afin de ne pas passer par une phase de migration des dites configurations (via l’outil XDME). Le cas échéant, une modification structurelle impliquera une version majeure du socle et une non compatibilité avec les versions ACE antérieures.

Dans le même ordre d’idée, deux choses peuvent être rédhibitoire pour conserver une compatibilité ascendante :

· Des changements de signatures de constructeurs, méthodes … au niveau java du socle vers le métier

· Des mises à jour de version de librairies tierces (BC4J, parseur Oracle …)

1.1.3 Point de vue marketing

« Socle technique » est un nom interne, l’ensemble des éléments techniques permettant le fonctionnement d’ACE est ainsi appelé « eGX Technology ».

Ceci afin de bien différencier le point de vue fonctionnel (ACE) du point de vue technique de l’application « eGX Technology » est la brique technique sur laquelle se repose l’application ACE.

1.2 Eléments versionnés

Le socle technique courant est la version 7.0.

L’ensemble des opérations décrites dans ce chapitre sont des opérations manuelles, il n’est pas prévu à ce jour de proposer de migration automatique via un outil (comme c’est le cas avec XDME pour les fichiers de configuration par exemple).

L’écriture des schémas XSD a été homogénéisée afin que tous portent un espace de nommage distinct. Cette nouveauté est principalement liée à XDME, ceci permet de générer des beans JAXB dans des packages distincts.

L’attribut de version du socle technique est obligatoire sur l’ensemble des schémas (sinon les fichiers XML correspondant ne valident pas), il est systématiquement porté par l’élément racine du fichier XML : @egx_release .

Sa valeur est une restriction dans le schéma, il est donc impossible de se tromper.

1.2.1 ACE.properties

Le schéma doit être changé, les fichiers XML correspondant à ce schéma doit être mis à jour obligatoirement afin de prendre en compte les nouveaux paramétrages par défaut.

Nom du schéma XSD : ACE.properties.xsd

1.2.2 ConfigurationDef

Le schéma doit être changé, les fichiers XML correspondant à ce schéma doit être mis à jour obligatoirement afin de prendre en compte les nouveaux paramétrages par défaut.

On notera que de nouveaux attributs optionnels ont été ajoutés :

@active : permet de lire le fichier correspondant (true par défaut)

@module : permet de définir un niveau d’étanchéité lorsqu’on « empile » les modules fonctionnels au sein d’un même WebModule

Nom du schéma XSD : configurationdef.xsd

1.2.3 Dictionnaires

Le schéma doit être changé, les fichiers XML correspondant à ce schéma doit être mis à jour obligatoirement afin de prendre en compte les nouveaux paramétrages par défaut.

Nom du schéma XSD : trad.xsd

1.2.4 Pool : nouveaux pool

Le schéma doit être changé, les fichiers XML correspondant à ce schéma doit être mis à jour obligatoirement afin de prendre en compte les nouveaux paramétrages par défaut.

Nom du schéma XSD : pool.xsd

1.2.5 Configuration

C’est le schéma des fichiers de configurations qui porte la compatibilité entre une version du socle technique et des versions d’ACE. A ce titre, la version ACE contenue dans la configuration devient donc une liste restrictive en terme XSD.

De fait, et c’est l’exception qui confirme la règle, l’attribut @egx_release est optionnel sur la configuration.

Nom du schéma XSD : configuration.xsd

1.3 Point de vue opérationnel

L’ensemble des fichiers décrits dans le chapitre précédent font partis intégrante du socle technique en terme de fonctionnement, c’est la raison pour laquelle ils doivent être changés et valides.

Ensemble d’éléments à prendre en compte pour changer de version de socle technique :

· Les jars du socle :

o technicalframework.jar

o butterfly.jar

· Les schémas XSD + modification des fichiers XML correspondant

· XDME : généré à partir du XSD du fichier de configuration, cet outil doit donc forcément suivre l’évolution

Le socle technique vérifie que les fichiers XML lus dont dans la bonne version, l’application ne démarre pas si toutes les conditions ne sont pas remplies à 100%. Ceci permettra de se prémunir d’oublis ou de non respects des règles explicitées.

1.4 Matrice de compatibilité

1.4.1 Socle technique 7.0

Compatible avec les versions ACE suivantes :

· GCE155

· GCE1.6.0 (version native)

2 Monitoring des JVM

2.1 Objectifs

Suite à une demande collégiale de la part des différents acteurs exploitant l’application ACE (clients, partenaires, AVV …), une solution toute nouvelle fait son apparition afin de prendre en compte 2 points principaux d’administration :

· Possibilité de demander des rechargements de certaines tables de paramétrage (PPE …)

· Monitoring périodique de la consommation mémoire et récupération des informations environnementales de l’AS

Important : il s’agit uniquement d’avoir une vision transversale et applicative de l’ensemble des instances de JVM ACE, en aucun cas cela ne vient substituer à des outils fournis par les serveurs d’applications eux-mêmes, voire des outils tiers.

2.2 Moyens mis en œuvre

La base de données constitue le seul moyen d’avoir une vision partagée d’un environnement de production (en tout cas d’un point de vue applicatif). De nouvelles tables ont donc été ajoutées afin de mettre à jour ces informations environnementales.

Les 2 tables concernées sont automatiquement créées lors du démarrage des JVM. Les indexes se trouveront donc forcément dans le tablespace par défaut du schéma ACE. Il convient de les déplacer sur le tablespace idoine en fonction de la mise en place de la BDD.

2.2.1 Rechargement des tables de paramétrage

Script DDL [1]

create table ut_prg

/* Process Reloading Guarantee */

(codsoc integer,

utimod varchar2(8),

datmod varchar2(8),

flag_tf integer,

flag_bs integer,

jvm_id varchar2(128),

as_id varchar2(128),

ip varchar2(256),

server_name varchar2(256)

) ;

alter table ut_prg add constraint ut_prg_idx1 primary key (codsoc, jvm_id, as_id) ;

Description de la table

Tableau 1 : UT_PRG
Champ	Description
codsoc	Non significatif : toujours à 0
datmod	La date de création de l’enregistrement
utimod	L’utilisateur ayant créé l’enregistrement (normalement GUEST)
flag_tf	Flag permettant de demander un rechargement lié au socle technique
flag_bs	Flag permettant de demander un rechargement lié à la session métier
jvm_id	UUID de la JVM : change a chaque démarrage de la JVM, cela permet de conserver une traçabilité
as_id	Identifiant de l’instance de l’AS
ip	L’adresse IP du serveur d’application (IPv4)
server_name	Le nom canonique du serveur d’application

Rechargement du socle technique : flag_tf

Bit 0 : rechargement des fichiers de configuration (nop[2])

Bit 1 : rechargement d’ACE.properties

Bit 2 : rechargement de LOG4J

Bit 3 : vidage du cache de feuilles de style (nop)

Bit 4 : forçage de la mise à jour de la table de monitoring

Rechargement de la session métier : flag_bs

Bit 0 : paramétrage fonctionnel (PPE, PEV, UT_FCG)

Bit 1 : paramétrage des stocks (OSK, ASK, CSK)

Bit 2 : nouvelles habilitations (UT_BV_HAB)

Bit 3 : définition des BV (UT_BV_DEF)

Bit 4 : définition des modèles de BV (UT_BV_MODELE)

Bit 5 : définition des liens entre BV (UT_BV_LINK)

Exemple d’utilisation :

update ut_prg set flag_bs=3, flag_tf=16;

commit;

On demande un rechargement du paramétrage fonctionnel (PPE … + stocks) et d’ACE.properties sur l’ensemble des JVM pointant sur la base de données.

Important : afin de ne pas générer de contention inutile sur cette table, il convient de faire la mise à jour et de la valider (commit) directement dans la foulée.

Cette table est lue systématiquement lors de chaque URL, à l’instar de la table UT_UUID. Cela n’a aucun impact sur les performances, le temps mesuré sur un simple PC portable est inférieur à la ms.

2.2.2 Monitoring

Script DDL

create table ut_dma

/* Dynamic Monitoring Application */

(codsoc integer , utimod varchar2(8), datmod varchar2(8),

jvm_release varchar2(128),

jvm_id varchar2(128),

as_id varchar2(128),

jvm_local varchar2(16),

user_id varchar2(128),

os_name varchar2(256),

os_version varchar2(256),

ip varchar2(256),

server_name varchar2(256),

datheu_dem varchar2(19),

datheu_maj varchar2(19),

log_dir varchar2(256),

mem_xmx integer ,

mem_mps integer ,

mem_used integer ,

ACE_properties varchar2(256),

sm_count integer ,

avg_time1 number,

avg_time2 number,

avg_time3 number,

avg_time4 number,

egx_release varchar2(32),

ACE_release varchar2(32)

) ;

alter table ut_dma add constraint ut_dma_idx1 primary key (codsoc, jvm_id, as_id);

Description de la table

Tableau 2
Champ	Description
codsoc	Non significatif : toujours à 0
datmod	La date de création de l’enregistrement
utimod	L’utilisateur ayant créé l’enregistrement (forcément GUEST puisque le traitement est « socle »)
jvm_release	La version de la JVM utilisée au runtime (ex : 1.6.0_23-b05)
jvm_id	UUID de la JVM : change a chaque démarrage de la JVM, cela permet de conserver une traçabilité
as_id	Identifiant de l’instance de l’AS [3]
jvm_local	La localisation de la JVM : doit être absolument à en_US pour ACE
user_id	L’utilisateur (au sens OS ayant démarré la JVM)
os_name	L’OS utilisé (ex : Windows 7)
os_version	La version de l’OS (ex : 6.1 correspond à la version DOS sous Windows)
ip	L’adresse IP du serveur d’application (IPv4)
server_name	Le nom canonique du serveur d’application
datheu_dem	Date de démarrage[4]
datheu_maj	Date de dernière mise à jour de la table par la JVM
log_dir	Le répertoire de destination des logs ACE (et timers)
mem_xmx	La mémoire maximum utilisable par la JVM (correspond au paramètre –Xmx de la JVM)
mem_mps	La mémoire maximum définie pour le chargement des classes Java (XX:MaxPermSize)
mem_used	Mémoire utilisée au moment du monitoring (purement indicatif)
ACE_properties	Le ACE.properties utilisé ou null s’il s’agit de la valeur par défaut (ACE.properties.xml)
sm_count	Le nombre de sessions métiers en instance dans la JVM (nop)
avg_time1	Nop
avg_time1	Nop
avg_time1	Nop
avg_time1	Nop
egx_release	La version eGX Technology (différente d’ACE_release à compter de la GCE1.6.0)
ACE_release	La version ACE

La table de monitoring est mise à jour périodiquement par l’ensemble des JVM pointant sur la base de données si le paramétrage l’autorise (ACE.properties). Ceci est réalisé via un Thread autonome qui maintient un RootApplicationModule (donc attention à la limite fixée dans le fichier de configuration de plus haut niveau car on en consomme donc un systématiquement). A noter que la connexion JDBC n’est pas maintenue sur ce thread afin de ne consommer la connexion « qu’au besoin ».

L’unité d’œuvre de la période de scrutation est la seconde, il ne semble pas très utile de descendre à une unité plus faible (genre ms …).

2.2.2.1 Exemple de requête multi-jvm

select c.* from ut_dma c

where (c.as_id,c.datmaj) in (

select as_id,datmaj

from ut_dma b

where b.datmaj=(select max(datmaj) datmaj

from ut_dma a

where a.as_id=b.as_id)

group by as_id,datmaj)

order by c.datmaj desc;

2.2.2.2 Calcul de AS_ID

Ce champ permet de déterminer l’instance de JVM en fonction du serveur d’application. Quatre cas sont pris en compte :

· WebLogic 11g : paramètre weblogic.Name

· Oracle AS 10g : paramètre oracle.ons.indexid

· JBoss : nom du répertoire final définissant user.dir

· Indéterminé : dans ce cas, c’est le nom du serveur qui est utilisé

2.2.3 APIs de gestion

Un ApplicationModule a été créé au niveau du socle technique afin de proposer des services de gestions. L’ensemble des services a aussi été publié sous forme de WebServices afin de proposer un accès via des outils tiers.

Pour des raisons évidentes, cet ApplicationModule est « final », il ne peut donc pas être surchargé de manière spécifique.

D’autre part, il n’est pas prévu de créer des DocumentRow afin de rendre ces services disponibles sur la couche de présentation.

2.2.3.1 Service : updateReload

Permet de mettre à jour la table UT_PRG, l’attribut active ne sert pas pour le moment mais est obligatoire è passer la valeur à true

2.2.3.2 Service : manageReload

Permet de provoquer les rechargements explicites en fonction des valeurs trouvées dans la table UT_PRG. L’attribut active ne sert pas pour le moment mais est obligatoire è passer la valeur à true

2.2.3.3 Service : updateMonitoring

Permet de mettre à jour la table UT_DMA, l’attribut active ne sert pas pour le moment mais est obligatoire è passer la valeur à true

Les champs mis à jour sont les suivants :

· DATHEU_MAJ

· MEM_XMX

· MEM_USED

2.2.3.4 Service : retrieveMonitoring

Permet de récupérer les informations contenues dans la table UT_DMA.

Remarque : la table UT_DMA est lue intégralement, le bean de sortie de l’API renvoie donc l’intégralité des informations contenues dans cette table.

2.3 Mise en place

Cette nouveauté est aussi disponible en ACE 1.55.

A noter : la création des tables est faite directement par le socle technique sur la version GCE155 afin d’éviter de passer des trains d’alter table sur une version en production. Il reste à la charge du client de repositionner les indexes sur le tablespace de son choix, ainsi que de calculer correctement les statistiques.

2.3.1 Partie applicative

De manière exceptionnelle, le schéma d’ACE.properties a été modifié en GCE155. Il s’agit d’un élément optionnel donc sans impact sur un environnement déjà existant. Par contre il convient d’avoir le schéma à jour pour déclencher la fonctionnalité (et que le XML valide bien le schéma, sinon l’application ne démarrera pas).

Le délai spécifié est en secondes.

2.3.2 Utilisation via WS

Exemple depuis SOAPui :

Flux d’entrée pour le mode « retrieve » en littéral :

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

<soapenv:Header/>

<soapenv:Body>

<urn:retrieveMonitoring>

<com:ctx entity="1" language="FRA" target="MENU" user="XXX" password="YYY"/>

<com:MonitoringManagerretrieveMonitoringIn>

<com:active>true</com:active>

</com:MonitoringManagerretrieveMonitoringIn>

</urn:retrieveMonitoring>

</soapenv:Body>

</soapenv:Envelope>

Exemple d’URL d’accès au WSDL :

http://localhost:8888/GCE1.6.0/services/literal/monitoringManager?WSDL

La valeur active=true est « décorative » mais elle est néanmoins indispensable au bon déclenchement des WebServices présentés ici.

Services disponibles :

· retrieveMonitoring : retourne un flux de description de la table UT_DMA

· manageReload : demande explicite de rechargement en se basant sur la table UT_PRG

· updateReload : mise à jour de la table UT_PRG

· updateMonitoring : mise à jour de la table de monitoring (UT_DMA) è champs DATMAJ & MEM_USED

A noter : le monitoring (suivant le paramétrage d’ACE.properties) est déclenché aussi bien sur les WebModules IHM que sur le WebModule WS. Par contre les principes de rechargement du paramétrage (basé sur la table UT_PRG) ne sont pas disponibles à ce jour sur le module WS (viendra dans une prochaine version du socle technique).

3 Nouveaux compteurs

Ce Document a pour objectif d’expliciter la mise en place du paramétrage permettant de limiter la contention sur les compteurs ACE au strict minimum (contention de lock sur la BDD : table UT_CPT).

3.1 Rappels

Il existe à ce jour 2 modes de gestion des compteurs dans ACE :

· Utilisation de la table UT_CPT (mode classique)

· Utilisation de séquences Oracle (via PPE SEQORA)

L’interface Web propose l’utilisation de ces 2 modes, ainsi que les batchs.

Pour des raisons de performance pure, ainsi que pour éviter la contention sur la table UT_CPT (lock Oracle dont le temps maxi autorisé est pilotable dans ACE.properties : voir les Releases Notes technique à ce sujet) les séquences Oracle proposent une alternative séduisante dans la plupart des cas.

Malheureusement, les séquences ne sont pas à même de gérer les trous de numérotation, ce qui est rédhibitoire dans certaines situations, en particulier sur les factures/avoirs à cause de la législation (un trou dans la numérotation doit pouvoir être justifiée).

Ce nouveau mode de gestion étant piloté par un service d’ApplicationModule, il est donc disponible nativement pour l’IHM Web, ainsi que les WebServices ACE.

3.2 Nouveau mode de fonctionnement

Ce mode sera forcément spécifique à une base de données Oracle, ceci n’est pas un point bloquant car ACE n’est certifié que sur cet environnement.

L’objectif est double :

· Limiter la contention sur UT_CPT au strict minimum

· Gérer la table des trous afin de pouvoir utiliser un numéro de compteur n’ayant pas été consommé

Le pilotage sera réalisé au niveau le plus fin via un nouveau PPE CPTORA (compteur Oracle), ainsi qu’une fonction stockée Oracle qui sera chargée de lire la table des trous, puis UT_CPT si aucun trou n’a été trouvé. Cette fonction permet l’utilisation d’une transaction séparée (AUTONOMOUS TRANSACTION) et ainsi de pouvoir commiter la gestion du compteur dans UT_CPT sans avoir à gérer cela dans la transaction appelante (ACE en l’occurrence).

3.2.1 Création du paramètre

Il faut d’abord créer le nouveau PPE CPTORA dans la base de données, soit par SQL, soit via le portail de configuration (I_CONF_F) :

INSERT INTO PARAM (CODSOC, DATMOD, UTIMOD, CODPAR, LIBPAR) VALUES (1, '20110115', 'GNC', 'CPTORA', 'Compteur basé du fct Oracle');

commit;

3.2.2 Création de la fonction stockée

Puis créer la fonction stockée (SQL*Plus, SQLDevelopper …) :

create or replace

function ACE_counter(p_codsoc NUMBER, p_counter VARCHAR2, p_utimod VARCHAR2, p_datmod VARCHAR2)

return number is pragma AUTONOMOUS_TRANSACTION;

r_ut_cpt ut_cpt%rowtype;

r_trou trou%rowtype;

v_isTrou BOOLEAN;

v_numcpt NUMBER;

cursor c_trou(p_codsoc INTEGER, p_codcpt VARCHAR2, p_indsup VARCHAR2) is

select *

from trou

where codsoc = p_codsoc

and codcpt = p_codcpt

and indsup = p_indsup

order by numcpt

for update wait 10;

begin

-- Rappel : une demande de lock en "nowait" génère l'exception suivante si le row est déjà locké :

-- ORA-00054: ressource occupée et acquisition avec NOWAIT ou temporisation indiqué

-- ORA-06512: à "SOC3.GNX_COUNTER", ligne 42

-- 00054. 00000 - "resource busy and acquire with NOWAIT specified"

-- *Cause: Resource interested is busy.

-- *Action: Retry if necessary

-- java.sql.SQLException: ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

-- ORA-06512: at "SOC3.ACE_COUNTER", line 44

-- Existe-t'il un trou que l'on peut récupérer ?

begin

open c_trou(p_codsoc, p_counter, 'N');

-- On récupère uniquement le 1er enregistrement trouvé si c'est possible

fetch c_trou into r_trou;

if (c_trou%notfound)

then

v_isTrou := false;

else

v_isTrou := true;

v_numcpt := r_trou.numcpt;

end if;

close c_trou;

-- Si un trou a été trouvé, on le consomme en passant son indicateur à 'O'

if (v_isTrou = true)

then

update trou

set indsup = 'O'

where codsoc = p_codsoc

and codcpt = p_counter

and numcpt = v_numcpt;

end if;

exception

-- soit on a trouvé un trou, soit on ne peut pas locker l'enregistrement auquel cas on utilise le mécanisme classique.

when others then v_isTrou := false;

end;

-- Pas de trou : on récupère une nouvelle valeur depuis UT_CPT.

if (v_isTrou = false)

then

begin

select * into r_ut_cpt

from ut_cpt

where codsoc = p_codsoc

and codut_cpt = p_counter

for update wait 10;

-- La bonne valeur à renvoyer : la valeur courante.

v_numcpt := r_ut_cpt.valut_cpt;

-- Incrémentation du compteur.

update ut_cpt

set valut_cpt = r_ut_cpt.valut_cpt + r_ut_cpt.icr, datmod = p_datmod, utimod = p_utimod

where codsoc = p_codsoc

and codut_cpt = p_counter;

end;

end if;

-- La transaction doit être validée, même si on récupère l'information depuis la table des trous : ceci est lié

-- au principe des transactions autonome dans Oracle.

commit;

return v_numcpt;

end;

On notera que l’on tente de poser un lock sur les tables TROU et UT_CPT avec une durée maximum de 10s, il est possible de modifier ces valeurs dans le cadre du projet (en rouge italique dans le code ci-dessus).

3.2.3 Paramétrage

Il ne reste plus qu’à positionner le PPE CPTORA sur la fonction concernée, à titre d’exemple depuis le portail de configuration I_CONF_F :

Par défaut, le PPE CPTORA utilise la fonction stockée ACE_COUNTER, mais il est possible d’utiliser une autre fonction répondant aux mêmes paramètres d’entrées en pilotant son nom dans le L1 du paramètre.

3.2.4 Remontées d’erreurs

Le métier ACE remontera une erreur ERR_LOCK si la fonction stockée ne parvient pas à récupérer un numéro de compteur dans UT_CPT. Ce cas est normal .

Les erreurs Oracle trappées dans ce cas là sont ORA-30006 ou ORA-00054 suivant le mode de locking de la fonction stockée (WAIT ou NOWAIT) :

// java.sql.SQLException: ORA-30006: resource busy; acquire with WAIT timeout expired

// ORA-06512: at "SOC3.ACE_COUNTER", line 44

// java.sql.SQLException: ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

// ORA-06512: at "SOC3.ACE_COUNTER", line 44

Exemple de copie d’écran (non contractuel car issu de la version GCE155) lorsque l’enregistrement est verrouillé :

Afin de conserver une trace permanente des erreurs de locking, la trace positionnée dans egx.log est en niveau INFO (log4j), par exemple :

[2011-01-17 10:45:41,876] INFO (fr.ACE.technicalframework.business.applicationmodule.GnxNestedApplicationModuleProxyImpl) -

<ns2:GestionEvenementcreerEvenementOut xmlns:ns2="http://www.ACE.fr/metier/bc4j/evenement/common" xmlns:ns3="http://www.ACE.fr/metier/bc4j/analytique/common" xmlns:ns4="http://www.ACE.fr/metier/bc4j/produit/common" xmlns:ns5="http://www.ACE.fr/metier/bc4j/tarif/common" xmlns:ns6="http://www.ACE.fr/metier/bc4j/tiers/common" xmlns:ns7="http://www.ACE.fr/metier/bc4j/service/common" xmlns:ns8="http://www.ACE.fr/metier/bc4j/catalogue/common" xmlns:ns9="http://www.ACE.fr/metier/bc4j/table/common" xmlns:ns10="http://www.ACE.fr/metier/bc4j/contrat/common" xmlns:ns11="http://www.ACE.fr/metier/bc4j/stock/common" xmlns:ns12="http://www.ACE.fr/metier/bc4j/queque/common" xmlns:ns13="http://www.ACE.fr/metier/bc4j/logistique/common" xmlns:ns14="http://www.ACE.fr/metier/bc4j/ecriture/common" xmlns:ns15="http://www.ACE.fr/metier/bc4j/structure/common" xmlns:ns16="http://www.ACE.fr/technicalframework/business/service/common" xmlns:ns17="http://www.ACE.fr/technicalframework/businesscomponent/applicationmodule/common" xmlns:ns18="http://www.ACE.fr/metier/bc4j/transport/common" xmlns:ns19="http://www.ACE.fr/metier/bc4j/utilisateur/common" xmlns:ns20="http://www.ACE.fr/metier/bc4j/commun/common">

<ns16:error>

<ns16:code>ERR_LOCK</ns16:code>

<ns16:paramList>UT_MES/1/CDV</ns16:paramList>

</ns16:error>

<ns2:contexte/>

<ns2:evenement>

<ns20:codsoc>1</ns20:codsoc>

<ns2:achvte>V</ns2:achvte>

<ns2:typeve>CDV</ns2:typeve>

</ns2:evenement>

<ns2:tiers>

<ns6:typtie>CLI</ns6:typtie>

<ns6:sigtie>BRCLI101</ns6:sigtie>

</ns2:tiers>

<ns2:sigdep> </ns2:sigdep>

<ns2:dateve> </ns2:dateve>

<ns2:datexp> </ns2:datexp>

<ns2:datliv> </ns2:datliv>

</ns2:GestionEvenementcreerEvenementOut>

4 Pilotage des entêtes de réponses

4.1 Préambule

4.1.1 Définition :

Les champs d'entête de réponse véhiculent certaines informations complémentaires concernant cette réponse, et qui ne peuvent être mentionnées dans la ligne d'état. Pour une réponse http par exemple, ces champs donnent des informations sur le serveur lui-même, les actions à mener par la suite pour accéder à la ressource demandée…

4.1.2 Remarques importantes

· ACE intègre un pré-paramétrage des entêtes de réponses au niveau de son fichier de configuration technique « configuration_base.xml ». Le paramétrage fourni avec la version ACE 1.6.0 est issu des éléments techniques déjà présents dans les versions précédentes d’ACE (ex : meta tags pour les pages HTML définis dans le template « GnxHead »).

· Les éléments à inclure dans la réponse sont organisés par groupe ; il existe des groupes prédéfinis correspondant à chaque moteur de rendu (ex : CHART, XSLT, FOP, SVG et BIRT), cette liste de groupes est extensible via le fichier de configuration.

· Les éléments définis dans le fichier de configuration via un groupe seront ajoutés à la réponse comme suit :

· De manière globale, si la transformation effectuée pour une requête donnée correspond à un moteur de rendu pour lequel le groupe associé par défaut comporte des éléments paramétrés à inclure

· Si on a défini un groupe d’informations personnalisé, et que ce dernier est associé à la requête (information portée au niveau du fichier associé à la BusinessView dans le fichier de configuration)

· Un élément d’entête est ajouté à la réponse si la valeur du paramètre correspond à une chaîne non vide.

4.2 Utilisation

4.2.1 Dans XDME

Sur la barre de menu dans XDME.

4.2.2 Définition des éléments

On utilise un groupe prédéfini (1 par moteur de rendu exploité par le socle ACE) ou bien on peut définir son propre groupe dynamiquement ici.

On implémente chaque élément à inclure dans la réponse.

4.2.3 Pré-paramétrage ACE 1.6.0

· XSLT, pour le moteur de rendu XSLT, le plus utilisé dans ACE

· Ce paramétrage interne au fichier de configuration correspond à ce qui existait précédemment au niveau de l’entête des pages HTML générées :

· CHARTT, pour le moteur de rendu CHART, exploité pour certains graphiques « SVG ». Il s’agit d’un cas particulier pour répondre à un besoin propre à IE9

4.2.4 Extension des groupes prédéfinis

· Bien que la transformation de la feuille de style mise en évidence ici soit rattachée par défaut au moteur XSLT, on inclura bien dans la réponse les éléments définis au niveau du groupe positionné ici

4.3 Visualisation de la réponse

On pourra s’appuyer sur les consoles des navigateurs pour exploiter la lecture de ces informations là.

Affichage sous IE9, d’un SVG, génération depuis le moteur de rendu CHARTT

5 Web Services

5.1 Contexte d’exécution

Un webservice s’exécute toujours dans un contexte fonctionnel défini (entité, cible de paramétrage, …) que ce soit implicite (via la configuration) ou explicite (ou outrepassé) via le flux.

5.1.1 Configuration

Ci-dessous, des pointeurs vers les éléments de la configuration :

· le nœud config/business/webservice/server_def dans la configuration :

· l’attribut config/application/link_to_business/root_applicationmodule/@endOfSession dans la configuration :

5.1.2 Flux

Il est possible de spécialiser le contexte d’exécution par appel : c’est le rôle du nœud facultatif ctx.

· Chaque attribut défini le paramétrage (ou écrase celui de la configuration).

· Si user est positionné, password doit l’être aussi.

· endOfRequest défini la gestion de fin de contexte fonctionnel (RootApplicationModule) au WS à adapter ; valeurs possibles : returnToPool, destroy .

Rappel :

o returnToPool : les instances SessionMetier (RootApplicationModule) retournent dans le pool qui leur est dédié, avec les pools qu’elles maintiennent elles même Þ

aucune libération mémoire à la fin d’une session http (WS).
Lorsqu’une instance déjà utilisée est attribuée à un nouvel utilisateur, le risque est important de compléter de manière notable les différents pools déjà existants (et donc augmenter de manière significative la signature mémoire) si la cinématique déclenchée diffère fortement de ce qui avait préalablement été effectué
Par contre, intérêt de réutiliser les données déjà à disposition Þ gain de performance.
destroy : les instances sont abandonnées et disparaissent avec les Þ
libération mémoire complète à la fin d’une session http
Mode forcément moins performant, mais qui assure la « fraicheur » des données au plus proche de la base de données

· Nœud log : permet d’activer des traces comme on peut le faire avec l’action de cinematic trace_enable()

5.1.3 Exemple

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

xmlns:urn="urn:ACE"

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

xmlns:ser="http://www.ACE.fr/technicalframework/business/webservice/server">

<soapenv:Body>

<urn:assimilate>

<ser:log>

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

</ser:log>

</ctx>

</identification>

</context>

<info>

<key>

<identifier>AGFOU001</identifier>

</key>

</thirdparty>

<info>

</info>

</expense>

</info>

</header>

</businessEvent>

</transaction>

</GCEServiceassimilateIn>

</urn:assimilate>

</soapenv:Body>

</soapenv:Envelope>

5.2 Limitation du nombre de traitements

Cette fonctionnalité permet de limiter le nombre de flux Web Service traités en parallèle.

5.2.1 Objectifs

5.2.1.1 Introduction

ACE est capable de traiter plusieurs flux webservice en parallèle comme il est capable de gérer plusieurs sessions utilisateurs interactives. Bien sûr, la charge admissible par le système est fonction des capacités techniques de la machine (cf le paramétrage du nombre de Session/RootApplicationModule dans la configuration).

En interactif, l’utilisateur est averti graphiquement de l’atteinte de la limite du nombre de Sessions lors de sa tentative de connexion. Il peut donc agir en conséquence.

En mode Webservice (équivalent d’un mode « batch »), c’est l’EAI qui « injecte » les flux. C’est à lui de réguler le débit, de traiter les retours, …

5.2.1.2 Evolution

L’évolution consiste à aider l’EAI dans son travail de régulation de débit d'exécution en parallèle de flux webservices.

Une fois cette fonctionnalité activée, le nombre maximum de flux traités en parallèle sera égal au nombre de RootApplicationModule défini dans la configuration (bridage non actif par défaut dans la configuration pour rester compatible avec l'existant, soit : génération d'une erreur une fois la limite du système atteinte)

En plus de ce bridage, une autre évolution consiste à spécifier un nombre maximum de flux potentiellement en attente (au delà de la limite système), ceci pour « absorber » un pic de flux à traiter :

· Sans limitation du nombre de flux en attente, le système peut accepter un pic de flux (en les traitants dans la limite citée plus haut) sans surveillance du nombre de flux encore à traiter. L'inconvénient majeur est de ne pas se rendre compte de l'engorgement du système avec des délais de prise en compte des flux de plus en plus long (c'est le mode par défaut en place si le bridage est actif).

· Avec limitation du nombre de flux en attente, au delà du nombre admissible par le système + taille de la file d’attente de flux, le système génère une erreur d'atteinte de limite.

Remarque : l'activation de cette file d'attente de flux donnera forcément l'impression à l'émetteur du flux d'une lenteur anormal du système dès lors que le nombre de flux maximum admissible simultanément est déjà en cours de traitement.

5.2.2 Mise en place

Tout se passe dans le fichier ACE.properties :

Activation du bridage :

config/server/webservices/limit/@active = true

Taille de la file d’attente :

config/server/webservices/limit/@overallParallelProcessing = 25

Mettre ici la taille de la file d’attente désiré ou -1 pour ne pas spécifier de limite (c’est la valeur par défaut).

5.2.3 Exécution

Pas de bridage :

Fonctionnement actuel : au-delà de la limite, génération du faultCode/faultString habituel dans le flux webservice retour

Avec bridage :

En mode DEBUG, trace dans EGX.LOG indiquant le nombre d’unité d’exécution libre et le nombre de traitements en file d’attente.

Sans limitation de file d’attente, pas de retour dans le flux webservice retour tant que le traitement n’est pas effectué

Avec limitation et au-delà de la taille de la file d’attente, retour dans le flux : Le nombre maximum d'exécutions parallèle en attente <ici la taille de la file d’attente> de webservices est atteint. Revoir le paramétrage.

5.3 Gestion de la transaction

5.3.1 Objectifs

5.3.1.1 Introduction

A chaque invocation de webservice ACE, ACE obtient un contexte fonctionnel (la SessionMetier) pour exécuter les requêtes à la base de données (exécutées « physiquement » ou récupérer depuis les pools).

La fin du traitement gère la transaction : commit ou rollback (en cas d’erreur). Puis le contexte fonctionnel est détruit ou remis en pool (selon le paramétrage : destroy/returnToPool)

En mode webservice, c’est le client WS (en général un EAI) qui « injecte » les flux ; à savoir : autant les « SOAP Enveloppe » que les headers HTTP.

5.3.1.2 Evolution

L’évolution consiste à exécuter plusieurs webservices (les uns à la suite de l’autre) dans le même contexte fonctionnel & transactionnel (BDD). Exemple : crudManager.crud + gCEService.assimilate + businessViewService.execute => COMMIT ou ROLLBACK piloté par l’injecteur de webservice.

Remarque importante : rollback automatiquement généré sur la transaction en cas d’erreur WS, c’est au client WS de gérer sa remontée d’erreurs.

Contrainte : le contexte fonctionnel étant associé à une JVM (pas sérialisable), de cette contrainte découle que l’exécution des WS dans le même contexte s’exécute tous dans la même JVM .

5.3.2 Fonctionnement

5.3.2.1 Principe

a) Avant l’exécution du bloc fonctionnel de flux WS, l’EAI indique au système le début de transaction : il déclenche le WS de gestion de transaction : TransactionManager.begin ;

b) En retour, l’EAI stocke l’identifiant de session http pour les futures invocations (cf la remarque ci-dessus) ;

c) En fin de bloc fonctionnel, l’EAI déclenche le WS de gestion de transaction : TransactionManager.commit() ou TransactionManager.rollback().

Dès l’activation d’une transaction globale, le contexte fonctionnel (la SessionMetier) utilisé pour tous les WS ne peut retourner en pool classiquement (entre 2 appels ws). Dès lors, le système le maintien (rattaché à la session HTTP). Il ne pourra ainsi par être recyclé pour un autre bloc de traitements fonctionnel.

Remarque : en fin de transaction globale (ou pour une transaction « implicite »), c’est le mode de gestion habituel qui intervient (mixage des 2 modes possible), pour rappel :

Fichier de configuration :
- /config/application/link_to_business/root_applicationmodule/@endOfSession
- returnToPool ou destroy
  
  Attention : Il y a rollback implicite sur erreur fonctionnelle ou technique détectée è Fermeture transaction

5.3.2.2 Webservices

Avant toute chose, il convient de paramétrer le client WS en mode « maintien de session http ».

· Hello proxy = new HelloService().getHelloPort();<br />

((BindingProvider)proxy).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY ,true);

Exemple sur soapUI :

begin : Ouverture d’une transaction fonctionnelle.

Exemple de flux d’entrée :

<soapenv:Header/>

<soapenv:Body>

<urn:begin>

<com:ctx entity="1" language="FRA" target="VCDV" user="DEMO" password="DEMO">

<ser:log>

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

</ser:log>

</com:ctx>

<com:TransactionManagerbeginIn/>

</urn:begin>

</soapenv:Body>

</soapenv:Envelope>

Remaque : nœud CTX facultatif

Flux de sortie attendu :

Flux d’erreur sur « begin » si une transaction globale est déjà active :

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

<soapenv:Body>

<ns1:beginResponse xmlns:ns1="urn:ACE">

<ns2:error label="beginTransaction() : Une transaction est déjà en cours." xmlns:ns2="http://www.ACE.fr/technicalframework/business/service/common">

<ns2:code>TF_E000018</ns2:code>

<ns2:paramList>beginTransaction()</ns2:paramList>

</ns2:error>

<state>failure</state>

</TransactionManagerbeginOut>

</ns1:beginResponse>

</soapenv:Body>

</soapenv:Envelope>

commit : commit en base + fermeture transaction globale.

Exemple de flux d’entrée :

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

<soapenv:Body>

<ns1:commitResponse xmlns:ns1="urn:ACE">

<state>success</state>

</TransactionManagercommitOut>

</ns1:commitResponse>

</soapenv:Body>

</soapenv:Envelope>

Flux de sortie attendu :

PS : Plus de JSESSIONID (normal : la session http n’existe plus)

rollback : rollback en base + fermeture transaction globale.

Exemple de flux d’entrée :

<soapenv:Header/>

<soapenv:Body>

<urn:rollback>

<com:TransactionManagerrollbackIn/>

</urn:rollback>

</soapenv:Body>

</soapenv:Envelope>

Flux de sortie attendu :

PS : Plus de JSESSIONID (normal : la session http n’existe plus J)

Flux d’erreur sur « commit » ou « rollback » si une transaction n’est pas démarrée :

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

<soapenv:Body>

<ns1:rollbackResponse xmlns:ns1="urn:ACE">

<ns2:error label="endTransaction() : La transaction n'est pas démarrée." xmlns:ns2="http://www.ACE.fr/technicalframework/business/service/common">

<ns2:code>TF_E000019</ns2:code>

<ns2:paramList>endTransaction()</ns2:paramList>

</ns2:error>

<state>failure</state>

</TransactionManagerrollbackOut>

</ns1:rollbackResponse>

</soapenv:Body>

</soapenv:Envelope>

5.3.3 Mise en place

(index.xml) : Optionnellement, ajouter les liens vers les 2 références

Style <i>RPC</i> :

<li><a href="transactionManager">transactionManager</a></li>

Style <i>Document</i> :

<li><a href="literal/transactionManager">transactionManager</a></li>

configuration :

services/configuration_services.xml : Définir l’application module dans la configuration.

<applicationmodule_def maxInstance="25" minInstance="1" poolConfigurationName="nestedAm">

…

</applicationmodule_def>

WEB-INF :

sun-jaxws.xml : fichier à compléter.

<endpoint

name="transactionManager"

implementation="fr.ACE.technicalframework.businesscomponent.applicationmodule.WSTransactionManagerImpl"

url-pattern="/transactionManager"/>

<endpoint

name="transactionManagerLiteral"

implementation="fr.ACE.technicalframework.businesscomponent.applicationmodule.WSTransactionManagerImplLiteral"

url-pattern="/literal/transactionManager"/>

web.xml : fichier à compléter.

<servlet-mapping>

<servlet-name>jaxws-servlet</servlet-name>

<url-pattern>/transactionManager</url-pattern>

</servlet-mapping>

<servlet-mapping>

<servlet-name>jaxws-servlet</servlet-name>

<url-pattern>/literal/transactionManager</url-pattern>

</servlet-mapping>

lib : mettre à jour les jars technical_framework.jar et technical_framework_ws.jar

wsdl :

Nouveaux fichiers : TransactionManager*.wsdl
xsd :

· Nouveau fichiers : fr\ACE\technicalframework\businesscomponent\applicationmodule\common\TransactionManager*.xsd

6 Fichiers de configuration

6.1 Notion de ViewStructRef

Une nouvelle possibilité est offerte dans la configuration afin de mutualiser certaines parties des ViewStruct. Deux objectifs à cela :

· Meilleur taux de réutilisation des développements

· Maintenance facilité

Cette fonctionnalité est accessible dans XDME, on introduit la notion de ViewStruct composite. Une ViewStruct composite ne peut pas être utilisée tel quel, elle est forcément le composite d’une autre ViewStruct, au même titre qu’une View « classique ».

6.1.1 Définition

Elle se définit donc comme une ViewStruct classique, mais l’attribut composite est positionné à true.

Extrait XML :

Le premier niveau de View ne peut pas comporter de ViewLink, c’est forcément la ViewStruct maitre qui définit les paramètres à passer à cette View.

Exemple d’une ViewStruct composite définie :

On voit clairement qu’il n’y a pas de ViewLink sur le premier niveau de View, grâce à l’icône signalétique correspondant.

Fragment XML complet de cette ViewStruct composite :

<view_link verboseDetail="true">

</retrieve>

</view_link>

<view_link verboseDetail="true">

</retrieve>

</view_link>

</view>

<view_link verboseDetail="true">

</retrieve>

</view_link>

</view>

</viewstruct>

6.1.2 Utilisation dans une ViewStruct

Un nouveau panneau de sélection fait son apparition : sous le panneau de la liste des ViewDef, il contient l’ensemble des ViewStruct composites disponibles.

L’ensemble des View définissant la ViewStruct composite est entourée par un cadre en pointillés. Il convient ensuite de définir les paramètres (ViewStructRef) à passer au 1er niveau de View.

Fragment XML de la ViewStruct finale :

<view_link>

</view_link>

<view_link>

</retrieve>

</view_link>

<viewstruct_ref type="EVP_EVL_EVS">

<view_link>

</retrieve>

</view_link>

</viewstruct_ref>

</view>

</viewstruct>

6.2 Définition des configurations

6.2.1 Définition des champs pour l’IHM

Une nouvelle section fait son apparition dans configurationdef.xml, elle permet de lister des fichiers XML définissant des caractéristiques de champs.

Cela autorise la mutualisation des longueurs de champs au travers de l’ensemble des feuilles de style.

Cette possibilité existe, mais n’est pas encore exploitée dans le standard ACE.

A l’instar des fichiers de configurations et des dictionnaires de libellés, il est possible de définir ses propres dictionnaires de champs.

Exemple du dictionnaire minimaliste fourni en standard de la version GCE1.6.0 :

Il existe une extension du parseur Oracle afin de rendre disponible cette fonctionnalité dans les feuilles de style. La syntaxe est la suivante :

gnx:fieldLength(‘nom_du_champ’)

Bien entendu, l’espace de nommage gnx doit être défini dans l’entête de la feuille de style.

6.2.2 Etanchéité des modules fonctionnels

L’objectif est de pouvoir continuer à cloisonner les feuilles de styles (et uniquement les feuilles de styles) pour qu'une feuille de style finance par exemple soit isolée des feuilles de style du btoe.

Cette nouvelle possibilité intervient car les WebModules btoe, finance et sce seront regroupés au sein d’un WebModule unique dans la prochaine version d’ACE. Néanmoins la fonctionnalité est déjà présente en GCE1.6.0.

6.2.2.1 Le principe de fonctionnement

Pour cela on indique dans le fichier des alias les différentes possibilités de dérivation suivant le module.

Extrait de ce que l’on retrouvera sur la prochaine version d’ACE :

…

< policy name =" ROOT_XSL_ACE " module =" translation ">

< mapping value =" {ROOT_PRESENTATION}/translation "/>