4.5-00 : release note du socle technique (mars 2003)

L'intégration dans le flux de présentation des messages d'erreur et d'information évolues.

Les messages s'intègrent dans le flux au même titre que les données. Ils sont structurés de la façon suivante :

< typeMessage code =" codut_mes "> libellé </ typeMessage >

Exemple de xml incluant une Error suite à une mauvaise saisie :

< Age precision =" 38 " type =" NUMERIC ">

< business_data > 90 </ business_data >

< screen_data > 120 </ screen_data >

< error code =" TF_E100000 "> RowDocumentRowField.setBusiness() : Interception d''une Exception Oracle : ClientViewRowImpl.setAge() : pas plus dun siècle. </ error >

</ Age >

IMPORTANT : ceci interdit de définir un champ ayant pour nom "error" ou "information". Car il serait impossible de les différencier des éléments XML "error" et "information" .

L'attribut "maxFetchSize" définit les nombre maximum de lignes qui peuvent être chargées par une ViewObject. Cependant, il est possible que la requête sur les données rapporte plus d'informations que la limite fixée par maxFetchSize.

Nous avons ajouté un nouvel attribut sur le xml de présentation qui n'apparaît que lorsque les nombre de lignes sélectionnées en BDD est supérieure à "maxFetchSize".

Cet attribut se nomme "business_row_count". Sa valeur est un numérique qui donne, à titre indicatif, le nombre réel de lignes sélectionnées dans la base.

Cet attribut ne doit pas être confondu avec celui qui existe déjà, et qui continue d'être renseigné dans tous les cas : "total_business_row".

La traduction des Message et des Exception demande les modifications suivantes dans le fichier de configuration :

Ajout d'une nouvelle ViewObject UtMesView qui accède à la table ut_mes:

< viewobject name =" UtMesView " defFullName =" fr.ACE.technicalframework.businesscomponent.viewobject.UtMesView " maxFetchSize =" 20 " depthCount =" 0 "/>

Ajout d'un nouvel ApplicationModule MessageManager qui s'occupe de la lecture et de la traduction des Message en base:

< applicationmodule name =" MessageManager " defFullName =" fr.ACE.technicalframework.businesscomponent.applicationmodule.MessageManager " sessionType =" statefull "/>

Le socle technique utilise l'implémentation Sun de JAXB.

Oracle a également sa propre implémentation qui ne fonctionne pas au moment de la livraison du socle 4.5.0. Pour éviter des conflits lors de l'exécution du mode web, il est indispensable de faire deux modifications dans l'environnement OC4J :

• désactiver les fichiers jar suivant :

%OC4J_HOME%\j2ee\home\jaxb-rt-1.0-ea.jar

%OC4J_HOME%\j2ee\home\jaxp.jar

Ces fichiers peuvent être renommés ou supprimés. Dans le cas du renommage, il est important que l'extension ne soit plus "jar".

• Modifier fichier de démarrage de OC4J. Il doit contenir l'option suivante :

• Djavax.xml.parsers.DocumentBuilderFactory=oracle.xml.jaxp.JXDocumentBuilderFactory

Si ces modifications ne sont pas appliquées, vous obtiendrez une exception de sécurité du type "sealing violation".

extrait de la documentation Java de Sun :

Etant donné que eGX nécessite l'utilisation du parser Oracle v2, le fait de paramétrer la variable d'environnement sur la Factory du parser Oracle garanti que nous chercherons toujours le parser Oracle v2 indépendamment de l'algorithme standard de Sun indiqué ci-dessus.

Un nœud fils du nœud properties concerne la gestion des pools de ViewObject.

Selon la valeur de l'attribut, le pool de ViewObject sera global (les ViewObject crées par le socle seront toutes "attachées" à l'ApplicationModule root) ou local à chaque ApplicationModule qui fait la demande de création de ViewObject.

Représentation graphique du nœud pool

Description des nœuds et des attributs :

Exemple de configuration

< properties . . . . >

< public_businessview >

< businessview > LOGIN </ businessview >

</ public_businessview >

< visible bc4jViewLink =" false " field =" true "/>

< pool >

< viewobject only_root =" true "/>

</ pool >

</ properties >

La taille des libellés dans ut_mes est actuellement limitée à 55 caractères (taille du champ ut_mes.libut_mes). Cette limite évoluera pour la version 4.5.00. Au 20/01/2003 la nouvelle taille n'est pas encore fixée. Cette évolution n'est, pour l'instant pas réalisée. Elle le sera avant la fin des developpements 4.5.0.

Au 17/03/03, il est plannifié (pour fin Mars) d'écrire une SFG sur le sujet des messages afin de soumettre l'évolution à l'équipe Généat. Si UMES n'évolue pas pour la version 4.5.0, la structure de base sera tout de même modifiée pour augmenter la longueur d'un libellé eGX.

Au 16/04/03, on peut affirmer que libut_mes sera augmentée jusqu'à 80 caractères pour eGX.

A chaque parsing du fichier de configuration, son contenu est validé par le schéma. C'est la structure qui est validée et non la cohérence du paramétrage.

Remarque : la première validation se fait très tôt lors du démarrage du serveur l'application. S'il y a une anomalie, elle apparaîtra dans la console du serveur d'application.

Cette servlet est documentée dans VisuCache_guide_utilisateur_v4.4.0_1.0.doc.

En effet, cette servlet existe aussi dans la version 4.4.0 du socle technique.

Il est possible de définir un maître-détail du type suivant :

La configuration sera définie de telle façon que les champs du "retrieve" du détail sont alimentés par les champs de retour de l'invocation d'API.

Exemple d'utilisation : une API de création et une ViewObject donnant le détail de ce qui vient d'être créé.

Exemple :

Une API de création d'événement donne en retour les champs clés de l'événement créé.

Le "retrieve" du détail contient des champs "business" alimentés par les champs clés de l'événement créé.

Une même requête permet alors la création de l'événement par l'API et sa visualisation par la ViewObject.