| Les mises à jour de la documentation / Version 4.1-4.5 | |
| date | auteur | version | modif |
| 10/04/03 | TIF | 1.0 | · modification pour l'installation par rapport à LOG4J. |
| 04/06/03 | CAF | 1.0 | · Ajout d'infos pour le paramétrage de Log4J et sur l'attribut "deconnectFrequency". |
| 13/06/03 | TIF | 1.0 | · Ajout de jbo.initpoolsize=0 et jbo .maxpoolsize =0 |
| 17/06/03 | TIF | 1.0 | · Ajout de détails pour les modifications de l'installation. |
| 03/07/03 | TIF | 1.0 | · Modification de la gestion de la trace des clearcache |
| 27/08/03 | TIF | 1.0 | · Ajout clés de retrieve/sort pour la BV courante. |
| 02/09/03 | CAF | 1.0 | · Nouvelles traces SQL : insert, delete, update |
| 05/09/03 | CAF | 1.0 | · Prise en compte de l'entité dans la gestion du login. |
| 22/09/03 | TIF | 1.0 | · modification du plan pour nouvelle structure du flux de présentation. |
Ce socle est le résultat de l'écrasement du socle 4.5.0 de Mars 2003 par le socle 5.0.0 lors de la fin des développements de la gestion des traces et des pools de connexion BDD.
Ce socle conserve le nom de version 4.5.0 en rapport à la version d'eGX qui correspond à sa mise en production,
Cette version est destinée à être mise en production pour la version 4.5.0 du mode web.
Le socle technique utilise l'implémentation LOG4J version 1.2.8.
log4j-1.2.8.jar
Attention : ce fichier de démarrage devient spécifique à la version 4.5.0. Pour continuer de lancer OC4J pour les autres versions, il faut conserver une copie du fichier de démarrage précédent.
Le nom du fichier de paramétrage de LOG4J sera paramétrable par les variables d'environnements de la servlet, comme c'est déjà le cas pour le fichier de configuration d'eGX.
fichier : web.xml
< web-app >
< description > web Application </ description >
< context-param >
< param-name > egx_context_url </ param-name >
< param-value />
</ context-param >
< context-param >
< param-name > egx_traceconf_path </ param-name >
< param-value > default_log4j.xml </ param-value >
</ context-param >
< context-param >
< param-name > egx_configuration_path </ param-name >
< param-value > configuration.xml </ param-value >
</ context-param >
< context-param >
< param-name > egx_instance_name </ param-name >
< param-value />
</ context-param >
< servlet >
…
…
</ web-app >
fichier : orion-web.xml
< orion-web-app deployment-version =" 9.0.2.1.0 " jsp-cache-directory =" ./persistence " temporary-directory =" ./temp " internationalize-resources =" false " default-mime-type =" application/octet-stream " servlet-webdir =" /servlet/ ">
< context-param-mapping name =" egx_traceconf_path "> develop_log4j.xml </ context-param-mapping >
< context-param-mapping name =" egx_configuration_path "> configuration.xml </ context-param-mapping >
< context-param-mapping name =" egx_instance_name "> instance_SocleTechCourant </ context-param-mapping >
< virtual-directory virtual-path =" / " real-path =" ../../../default-web-app/egx450/btoc "/>
< resource-ref-mapping name =" jdbc/eGX-DS " location =" jdbc/OracleSoc1CoreDS "/>
</ orion-web-app >
La gestion des traces nécessite l'ajout d'un ApplicationModule et de trois actions.
Modèle de configuration :
< applicationmodule name =" AdminManager " defFullName =" fr.ACE.technicalframework.businesscomponent.applicationmodule.AdminManager " sessionType =" statefull "/>
< action name =" trace_reload " class =" fr.ACE.technicalframework.application.action.TraceReload "/>
< action name =" trace_enable " class =" fr.ACE.technicalframework.application.action.TraceEnable ">
< required >
< param name =" loggerName " type =" String "/>
</ required >
</ action >
< action name =" trace_disable " class =" fr.ACE.technicalframework.application.action.TraceDisable ">
< required >
< param name =" loggerName " type =" String "/>
</ required >
</ action >
Ce nouvel attribut de l'élément "business_session" permet de paramétrer la fréquence de déconnexion au SGBD.
| Valeurs | Signification |
| none | Pas de déconnexion automatique. |
| session | Déconnexion à la fin de la session http. |
| request | Déconnexion à la fin du traitement de chaque requête. Voir les limites ci dessous. |
< business_session defFullName =" fr.generix.metier.bc4j.parametrage.SessionMetier " lockingMode =" pessimistic " sessionType =" statefull " minInstance =" 1 " maxInstance =" 25 " deconnectFrequency =" request "/>
Cette gestion de la fréquence de déconnexion est principalement utilisée dans le cadre de la gestion des pools de connexion.
Rappel :
Deux modes de connexion à la base sont disponibles dans eGX:
Pour des raisons de performance, il y a une incompatibilité de paramétrage entre une fréquence de déconnexion trop rapide et le paramétrage par chaîne de connexion.
| type de connexion | Fréquence demandée | none | session | request |
| data source | none | session | request | |
| chaîne de connexion | none | session | session | |
En cas de paramétrage incohérent, la trace contiendra un message d'information.
La taille maximum des libellés des messages est de 80 caractères. (taille du champ libut_mes)
Exemple de résultat :
<VueSociete type= "View" name= "Societe" total_business_row= "12" nbline= "999" numpage= "1" nbpage= "1" retrieve_key= "ONE" sort_key= "ASC" >
Un fichier par frame dans le répertoire "log".
ex : Presentation_<nom_de_frame>.xml
selon trois fréquences : none, session, request.
cinematic=trace_reload();display(0)
trace timer
cinematic=trace_enable(timer);display(0)
cinematic=trace_disable(timer);display(0)
trace data
cinematic=trace_enable(data);display(0)
cinematic=trace_disable(data);display(0)
A chaque fois qu'un clearcache est appelé sur une ViewObject eGX, il y a une trace qui représente la pile d'appel dans le fichier de log.
Afin d'affiner le contenu de la trace, une nouvelle catégorie a été ajoutée dans le fichier develop_log4j.xml :
<category name= "fr.ACE.technicalframework.business.viewobject.GnxViewObjectImpl" >
<level value= "warn" />
<appender-ref ref= "egx.log" />
</category>
Si le niveau est à "warn", vous ne verez que les clearCache produits par des méthodes métier.
Si le niveau est à "debug", vous verrez tous les clearCache, y compris ceux qui sont produits par l'effet de l'utilisation de l'attribut "deconnectFrequency".
En plus des traces de type select déjà disponibles, il est maintenant possible de tracer les ordres de type insert, update et delete.
Pour rendre ces traces SQL disponibles (donc activables par l'action trace_enable(data)), il est nécessaire de préciser un nouveau paramètre dans le script de démarrage : jbo.SQLBuilder
Les valeurs possibles de ce paramètre sont :
| Valeurs | Classe instanciée. | Description |
| OracleSQLBuilderImpl | Classe Oracle.Valeur par défaut | |
| Oracle | OracleSQLBuilderImpl | Classe Oracle. SQL Oracle sans trace |
| SQL92 | SQL92SQLBuilderImpl | Classe Oracle. SQL92 sans trace |
| oracle.jbo.server.GnxTraceOracleSQLBuilderImpl | GnxTraceOracleSQLBuilderImpl | Classe eGX. SQL Oracle avec trace |
| oracle.jbo.server.GnxTraceSQL92SQLBuilderImpl | GnxTraceSQL92SQLBuilderImpl | Classe eGX. SQL92 avec trace |
Exemple de paramétrage :
Le paramétrage consiste en trois nouvelles catégories :
| Catégories | Description |
| CreateViewObjectData | Trace les ordres SQL de type "insert" |
| UpdateViewObjectData | Trace les ordres SQL de type "update" |
| DeleteViewObjectData | Trace les ordres SQL de type "delete" |
Elles viennent en complément des catégories STDViewObjectData et DYNViewObjectData qui ne tracent que les ordres SQL de type "select".
Une nouvelle entrée est disponible : SQL_PARAM_PRIMARYKEY. Cette entrée est renseignée systématiquement dans le cas des ordres SQL insert, update, delete. Elle a principalement un sens dans le cas de l'ordre insert et est présente à titre d'information dans le cas des ordres delete et update.
Récapitulatif des entrées alimentées selon les catégories de type *ViewObjectData
| entrées du MCD/ Catégories | STD… | DYN… | Create… | Update… | Delete… |
| APPMODULE | X | X | |||
| VIEWOBJECT | X | X | |||
| SQL_QUERY | X | X | X | X | X |
| SQL_PARAM | X | X | X | X | X |
| SQL_PARAM_PRIMARYKEY | X | X | X |
La gestion du login prend maintenant en compte l'entité lors de ses accès à la base de données. Cette amélioration demande la présence d'un nouveau paramètre dans la cinématique de login.
En plus des paramètres username et password, il faut y joindre le paramètre entity. Cela implique des modifications dans les clients du login : la configuration et la feuille de style.
<viewstruct name= "LOGIN" defaultRetrieve= "ONE" >
<view name= "Societe" nbline= "999" type= "VueSociete" >
<view_link>
<retrieve publicKey= "ONE" viewKey= "ALL" />
</view_link>
<view name= "Login" nbline= "1" type= "VueLogin" >
<field>
<attribute name= "username" public= "USER" />
<attribute name= "password" public= "PASSWORD" />
<attribute name="entity" public="ENTITY"/>
</field>
</view>
</view>
</viewstruct>
http://localhost:8888/egx450/btoe/ServletControl?cinematic=login(Login)&frame=default&id=848d2bd&entity=1001&chp:USER=LEE&chp:PASSWORD=KIKOUYOU&chp:ENTITY=1001
Les liens multi-entité de la table ut_login doivent être correctement définis au même titre que la table ut_ uti (via la fonction GSOC d’ACE).
En cas de changement d'entité, l'utilisateur est considéré comme étant non identifié dans cette nouvelle entité. La première BusinessView privée demandée déclenchera la phase de login.
Pour des raisons d'incompatibilité, le contenu de la table ut_uuid doit être purgé. Dans le cas contraire, des anomalies lors de la lecture de la table des utilisateurs sont susceptibles de se manifester.