4.4-00 : release note du socle technique (version 2.0)

• Le XML de présentation n'est plus complété par des ViewRow vides s'il n'y a plus de données.
• Pas de screen_data quand il n'y a pas de saisie.
• • screen_data vide signifie une saisie vide.
  • pas de screen_data signifie pas de saisie.

Cette modification a pour origine une incohérence dans la génération du xml de présentation en v4.3.2. En effet, nous utilisions le nom Oracle de la ViewObject au lieu du nom paramétrer dans le fichier de configuration.

La mise en place de cette modification implique peut de changement, néanmoins il faut en être conscient pour appréhender certaines modifications à réaliser dans les feuilles de styles.

Avant la mise à disposition du paramétrage des ViewLink Oracle, le seul moyen de ne pas afficher les ViewLink était de définir deux fois une même ViewObject dans le fichier de configuration :

<viewobject name="SUt_FcgView" defFullName="fr.generix.metier.bc4j.utilisateur.JUt_FcgView" maxFetchSize="200" depthCount="0"/>

<viewobject name="JUt_FcgView" defFullName="fr.generix.metier.bc4j.utilisateur.JUt_FcgView" maxFetchSize="200"/>

Comme les deux ViewObject sont définies sur la même ViewObject, il s'agit du même nom de tag dans le flux de présentation.

En v4.4.0, on obtient dans un premier cas un tag nommé "SUT_FcgView", et dans un second cas un tag nommé "JUT_FcgView".

Pour prendre en compte ce changement, il faut supprimer la ViewObject "S*" et modifier la définition des view qui utilisaient la ViewObject "S*". La modification consiste à faire pointer cette view sur la ViewObject "J*" et de paramétrer la visibilité des ViewLink Oracle sur cette View. (cf. 0)

Un nouvel attribut optionnel est disponible sur la définition d'un ViewLink ACE dans le fichier de configuration.

Cet attribut se nomme "verboseDetail" et peut prendre la valeur "true" ou "false".

Cet attribut définit la politique de génération du XML de présentation pour ce ViewLink.

Cet attribut est exploité si et seulement si la view est une View dépendante. Rappelons au passage qu'une View est dépendante si un de ses paramètres de clause retrieve fait parti du domaine "business".

verboseDetail="false" (valeur par défaut) et la View est dépendante : le XML de présentation ne contient que le XML correspondant au détail de l'élément courant de la View maître.

verboseDetail="true" et la View est dépendante : le XML de présentation contient le XML correspondant aux détails de toutes les lignes visibles de la View maître.

exemples :

avec verboseDetail="true"

< view >

< viewrow > valeur_1

< view >

< viewrow > valeur_1.1 </ viewrow >

< viewrow > valeur_1.2 </ viewrow >

< viewrow > valeur_1.3 </ viewrow >

</ view >

</ viewrow >

< viewrow current =" true "> valeur_2

< view >

< viewrow > valeur_2.1 </ viewrow >

< viewrow > valeur_2.2 </ viewrow >

< viewrow current =" true "> valeur_2.3 </ viewrow >

</ view >

</ viewrow >

< viewrow > valeur_3

< view >

< viewrow > valeur_3.1 </ viewrow >

< viewrow > valeur_3.2 </ viewrow >

< viewrow > valeur_3.3 </ viewrow >

</ view >

</ viewrow >

</ view >

avec verboseDetail="false"

< view >

< viewrow > valeur_1 </ viewrow >

< viewrow current =" true "> valeur_2

< view >

< viewrow > valeur_2.1 </ viewrow >

< viewrow > valeur_2.2 </ viewrow >

< viewrow current =" true "> valeur_2.3 </ viewrow >

</ view >

</ viewrow >

< viewrow > valeur_3 </ viewrow >

</ view >

La saisie dans une View de détail mérite d'être développée. Si on saisie dans une View de détail, c'est qu'elle possède au moins un champ public. Rappelons que le moyen de rendre une View non saisissable est de ne pas définir de champs public sur cette dernière.

Si l'attribut "verboseDetail" vaut "true", dès qu'il y a une saisie sur cette View, cet attribut est ignoré et le XML de présentation est généré comme si "verboseDetail" était positionné à "false".

Ceci est dû à un compromis pour les performances d'eGX. Vouloir faire une saisie dans une View de détail et continuer à afficher le XML de présentation pour toutes les lignes de la View maître est structurellement impossible sans des pertes de performances inacceptables.

Résumé :

Sur une View de détail, si on désire afficher tous les détails de toutes les lignes de la View maître et faire de la saisie, il faut savoir que dès qu'il y aura un propose(), il n'y aura plus que le détail de l'élément courant du maître qui sera affiché et la saisie aura lieu dans cette collection de lignes.

Puis, après un assimilate() (quand il n'y aura plus de saisie en cours) la view reprendra son comportement initial et affichera tous les détails de toutes les lignes de la View maître.

Sur une View de détail, si on désire toujours afficher tous les détail de toutes les lignes de la View maîtres, il faut définir l'attribut "verboseDetail" à "true" et ne pas définir de champs publics pour cette View. Donc, cela se "paye" par l'impossibilité de faire une saisie.

La validation d'informations saisies apporte éventuellement un retour indiquant un refus d'accepter les valeurs proposées par l'utilisateur.

Ces informations d'erreurs seront disponibles sur chaque élément pouvant faire l'objet d'une vérification métier. Il s'agit donc des RowField, des ViewRow et au niveau général de la page pour une erreur technique.

Le XML d'erreur est contenu dans un tag nommé "error" qui est inséré à tous les endroits cités précédemment lorsqu'une vérification métier indique une erreur.

exemples :

• <errror>JBO_EXCEPTION</error>
• <errror>ID_ERROR</error>

La problématique de la gestion des messages fera l'objet d'une SFG pour le socle technique v5.0.0.

remarque : ceci interdit de définir un champ ayant pour nom "error". Car il serait impossible de le différencier de l’élément XML "error" représentant une erreur.

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 urls doivent renvoyer cet identifiant pour assurer la continuité du traitement entre deux urls.

L'identifiant se trouve à l'élément suivant dans le XML de présentation :

/layout_data/application_data/id

L'identifiant doit être renvoyé, sur l'url, 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 il s'agit de la même BusinessView dans un état qui n'est plus en phase avec le 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.

Dans les améliorations potentielles, nous imaginons fournir un "gestionnaire d'exceptions". Ce dernier permettra de gérer les cinématiques d'exceptions en général et englobera ce cas d'erreur avec tous les autres. Cela permettra de faire autre chose que display(0) qui n'est pas paramétrable en version 4.4.0.

L'utilisation de l'attribut "sourceview" sur l'url implique que l'attribut "id" n'est pas obligatoire. Si l'attribut "id" est présent sur une même url que l'attribut "sourceview", l'identifiant sera ignoré.

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

/layout_data/error

• signature : logout()
• fonctionnalité : permet de se dé-identifier en cours de session. L’utilisateur devient GUEST. Néanmoins, la session logique n’est pas supprimée et l’utilisateur pourra de nouveau être reconnu automatiquement lors d'une prochaine session.

Si, à la suite d'une url qui contient l'action "logout", on se trouve sur une BusinessView privée, alors la BV privée sera affichée avec les informations liées à l'utilisateur "GUEST".

Dès la prochaine URL, si on tente d'atteindre une BV privée, il y aura une nouvelle demande de login.

C'est au concepteur de scénario d'imaginer s'il désire ce fonctionnement ou non. En effet, il est plutôt utile de terminer la chaîne d'action comprenant un "logout" par un "display" vers une BusinessView publique.

Pour supprimer l'identification automatique lors de la prochaine session de travail, ajouter le paramètre suivant sur l'url :

userRecognize="false"

L'attribut "defaultUserRecognize" de /config/application/properties est un booléen définissant si l'instance d'eGX gère l'identification automatique ou non.

• "true" = l'instance gère l'identification automatique.
• "false" = l'instance ne gère pas l'identification automatique.

Attention :

L'attribut booléen "uuidManage" de /config/application/properties définit si la gestion d'une session logique est activée pour l'instance d'eGX. Ce qui donne le tableau de compatibilité suivant entre les différentes valeurs de userRecognize et uuidManage

URLs de test pour le "R" du CRUD, puis le "U" (modification des ages de plusieurs clients avec une erreur)

1) sourceview=Clients&cinematic=display(0)&entity=1

2) cinematic=propose(0);display(0)&chp:AGE-1=25&chp:AGE-2=102

3) cinematic=assimilate();display(0)

URLs de test pour le "C" du CRUD (création d'un client)

1) entity=1&sourceview=Clients&cinematic=create(0);display(0)

2) cinematic=propose(0);assimilate();display(0)&chp:No=5000&chp:NOM=Test_creation_1&sel:VueClient-1=ON

Création d'une information, on sélectionne la ligne 1 pour la création.

URLs de test pour le "C" du CRUD (création de deux clients)

1) entity=1&sourceview=Clients&cinematic=create(0);display(0)

2) cinematic=propose(0);assimilate();display(0)&chp:No-1=5000&chp:NOM-1=Test_creation_1&sel:VueClient-1=ON&chp:No-2=5001&chp:NOM-2=Test_creation_2&sel:VueClient-2=ON

Création de 2 informations, on sélectionne les 2 lignes concernées.

Il n'y a pas de suppression en cascade pour les maître/détail.

URLs de test pour le "D" du CRUD (suppression d'un client)

1) entity=1&sourceview=Clients&cinematic=display(0)

2) cinematic=delete();display(0)&sel:VueClient=1

Suppression d'une information, on sélectionne la ligne 1 pour la suppression.

URLs de test pour le "D" du CRUD (suppression de deux clients)

1) entity=1&sourceview=Clients&cinematic=display(0)

2) cinematic=delete();display(0)&sel:VueClient-1=ON&sel:VueClient-2=ON

Suppression de 2 informations, on sélectionne les 2 lignes concernées.

Les deux graphes suivants représentent l'ordre d'écriture recommandé sur une cinématique.

Cette recommandation est basée sur l'étude de la combinatoire possible des actions, sur les effets indésirables associés à certaines combinaisons et sur les limites du cahier des charges du socle technique v4.4.0. Dans une version future du socle, ces règles d'écriture pourraient être vérifiées automatiquement.

Un cookie permet d'identifier automatiquement un utilisateur qui s'est précédemment identifié.

Cela permet d'éviter à un utilisateur qui le souhaite, et qui s'est déjà identifié au moins une fois, de ne plus être obligé de passer systématiquement par l'écran de login à chaque nouvelle session.

< link_to_presentation >

< http >

< cookie name =" UUID " cookieName =" UUID " maxAge =" 10000 " path =" / "/>

</ http >

</ link_to_presentation >

Le tag "link_to_presentation" se trouve au niveau /config/application dans le fichier de configuration.

L'attribut depthRowCount qui représente la profondeur d'affichage d'un ViewLink Oracle dans le XML de présentation d'une ViewObject peut avoir la valeur zéro.

Cela signifie qu'on ne veut voir apparaître aucun ViewLink Oracle dans le flux de présentation pour une ViewObject donnée.

Avant d'utiliser cette particularité, nous recommandons fortement de prendre connaissance du paragraphe 0 (Les champs de type ViewLink Oracle.) qui propose le moyen de paramétrer finement les ViewLink Oracle.

Tout répertoire relatif (donc qui ne commence pas par un '/') est basé relativement au répertoire correspondant au répertoire "root http" de l'application.

Dans le cas de tests, si on désire faire référence à un répertoire absolu, il faut utiliser la syntaxe suivante : /c:\mon_rep\xsl\modele

Le '/' en début de chemin indique que c'est un chemin absolu et qu'il ne faut pas insérer le répertoire "user.dir".

exemple d'un répertoire root http :

E:\oc4j\j2ee\home\applications\egx-app\egx-webapp

Pour le cas du paramétrage des feuilles de styles, il existe un attribut "rootPath". Cet attribut peut être utilisé de trois façon :

• non défini : si la référence sur la feuille de style est un chemin relatif, alors c'est la règle générale qui s'applique.
• défini avec un chemin relatif : ce chemin relatif s'ajoute au chemin défini par la règle générale.
• défini et commençant par un "/" : il devient la référence pour les feuilles de styles relatives.

L'attribut "/config/application/properties@cacheActive" est une attribut booléen optionnel.

La valeur par défaut est "true".

Cet attribut permet de désactiver l'utilisation des caches.

Conséquences :

• baisse de performance
• rechargement systématique des définitions de ViewObject, ApplicationModule et feuilles de style.

Remarque : cette désactivation ne concerne pas les pools qui sont toujours actifs.

L'instanciation de certains objets peut-être pénalisante pour les performances générales. On peut citer l'instanciation des ViewObject et des ApplicationModule.

Pour cela, le socle prend en compte les instances qui ne sont plus utilisées et les récupère au lieu de les détruire afin de les réutiliser lors d'un prochain besoin d'instanciation. Le stockage des instances se fait dans un pool.

Afin de limiter la consommation mémoire associée à l'utilisation de pools, il faut définir des garde-fous permettant de limiter la capacité des pools.

ViewObject et ApplicationModule

Deux nouveaux attributs sont obligatoires sur viewobject_def et applicationmodule_def. Il s'agit de minInstance et maxInstance.

Ce sont les valeurs par défaut qui s'appliqueront à tous les ViewObject ou ApplicationModule concernant la gestion de leur pool. Ces attributs définissent respectivement le nombre minimal d'instances et le nombre maximal d'instances dans le pool.

Cette valeur par défaut peut être modifiée spécifiquement pour chaque ViewObject ou ApplicationModule en renseignant les même attributs directement dans l'élément de définition de la ViewObject ou de l'ApplicationModule.

L'attribut "minInstance" définit un nombre d'objets pré-instanciés. Il faut savoir que si on définit une valeur élevée, le premier chargement d'un objet sera long, car il faudra construire beaucoup d'objets. Pas de panique, ce chargement à lieu la première fois qu'on utilise l'objet, pas à chaque nouvelle session utilisateur.

L'attribut "maxInstance" définit un nombre maximal d'instances de la classe concernée par le paramétrage. Une fois cette valeur maximale atteinte, un message d'erreur sera généré indiquant qu'une limite est dépassée et l'objet ne sera pas instancié.

BusinessSession

Il faut définir les attributs minInstance et maxInstance sur l'élément business_session.

• minInstance définit le nombre de session pré-instanciées à la construction du pool.
• maxInstance définit le nombre maximal de session utilisateurs possibles sur l'instance d'eGX.

Ces deux attributs sont optionnels. S’ils ne sont pas présents, des valeurs par défaut (minInstance=0, maxInstance=5) sont prises en compte pour BusinessSession.

Une ViewObject définie dans le cadre d'eGX peut contenir beaucoup de ViewLink Oracle. Cependant, selon les cas d'utilisation, tous les ViewLink Oracle ne sont pas nécessaires.

C'est pourquoi, on peut paramétrer la visibilité des ViewLink Oracle par le fichier de configuration.

Ce système a été étendu au paramétrage de la visibilité des champs, qui peuvent éventuellement déclencher des calculs inutiles dans certains cas de ViewStruct.

Les macros actions prennent en compte et interprètent les paramètres de types pointeurs.

Un paramètre d'action de type "Pointer" permet de passer en paramètre à un action un nom de champ afin de représenter la valeur saisie pour ce champ.

Les paramètres de type "Pointer" ne peuvent faire référence qu'aux champs se trouvant dans l'espace de nommage "chp:".

Les numéros de lignes sont pris en compte.

Exemple de macro action avec un paramètre de type pointeur :

< action name =" p_retrieve ">

< required >

< param type =" BusinessView " name =" businessView "/>

</ required >

< optional >

< param type =" Pointer " name =" key "/>

</ optional >

< action_ref name =" retrieve ">

< param_ref name =" businessView " ref =" businessView "/>

< param_ref name =" key " ref =" key "/>

</ action_ref >

</ action >

exemple d’URL associée :

sourceview=CommandesParClient&cinematic=p_retrieve(0,P1);display(0)&chp:P1=clientKey

sourceview=CommandesParClient&cinematic=p_retrieve(0,P1-3);display(0)&chp:P1-3=clientKey

Avec le socle 4.4.0, on peut initialiser un APIDocument via une action "retrieve", comme pour les RowDocument.

Cette initialisation ne pouvant passer par une requête SQL, il s'agit d'invoquer un service qui permettra d'initialiser le contenu de la View associée à l'APIDocument.

Ce point est développé dans le document "Initialisation_des_documents_440.doc".

Le constructeur de AbstractAPIDocumentRow a changé. A présent, le constructeur de AbstractAPIDocumentRow est :

public AbstractAPIDocumentRow(APIMethod amp)

Ce qui implique que le constructeur des classes qui dérivent de AbstractAPIDocumentRow est modifié dans ce sens.

Par ailleurs, la classe AbstractClauseResolver a été renommée en AbstractWhereClauseResolver. Donc la classe BusinessWhereClauseResolver est impactée par cette modification.

GnxBusinessApplicationModuleImpl ne doit plus dériver de GnxApplicationModuleImpl, mais de GnxPooledApplicationModuleImpl. De plus, il y a deux paramètres supplémentaires dans le constructeur qui sont le nombre minimal d'instances et le nombre maximal d'instances.

Il existe deux feuilles de style qu'il faut appliquer au fichier de configuration pour passer de la version 4.3.2 à la version 4.4.0. Ces feuilles de style automatisent le travail lourd qui consiste à renommer systématiquement certains éléments. Cependant, les points de détails difficiles à automatiser, tels que mettre à jour les noms des actions, ou corriger un valeur d'attribut, sont laissés sous le contrôle du gestionnaire du fichier de configuration.

Le schema XML fourni avec la version permet de valider la structure du fichier de configuration par rapport à la version cible.

Dans le package fr.ACE.technicalframework.application.action, des classes d’action changent de nom pour correspondre aux nouveaux noms des actions :

Veiller à bien supprimer les anciennes classes et à faire pointer la définition des actions sur les nouvelles classes.

De nouveaux éléments à insérer dans le fichier de configuration.

< action name =" delete " class =" fr.ACE.technicalframework.application.action.Delete "/>

< action name =" logout " class =" fr.ACE.technicalframework.application.action.Logout "/>

< action name =" invalidate " class =" fr.ACE.technicalframework.application.action .Invalidate "/>

Aucun traitement automatique n'insère ces nouvelles définitions. Si elles sont absentes, il faut les recopier. Pour la description des actions, voir le document de description des actions.

Ces nouvelles ViewObject sont utilisées par les ApplicationModule du socle technique dans le cadre d’une correction liée à une anomalie de fonctionnement des BC4J (bug n°66 : chargement concurrent de ViewObject).

Nota : Ces ViewObject sont ajoutées automatiquement dans le fichier de configuration par l’application de la feuille de style convert_conf_432_vers_440_part2.xsl

Les nouvelles définitions :

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

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

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

Rappelons que le partage de document sert à partager l'état courant et les éventuels états de saisie entre les View qui partagent le document.

Si on partage tous les documents d'une application, toutes les View partagent les états courants et les états de saisie, mais se rechargent à chaque modification dans la moindre View.

Rappelons aussi qu'il n'est pas possible de partager un document dans sa propre ViewStruct.

Avant JDeveloper 9.0.2.760, il n'était possible de définir que des ViewLink Oracle qui retournent un RowSet. A partir de la version 9.0.2.760 de JDeveloper, il est possible de spécifier qu'un ViewLink Oracle ne retourne qu'une seule valeur. Si on positionne cette option, le ViewLink Oracle ne retourne qu'un Row. Cela pose un problème pour la génération du XML de présentation. C'est pourquoi, il est indispensable avec le socle 4.4.0 de laisser les liens n->n et de ne pas définir de lien n->1.

Exemple de xml de présentation d'un ViewLink :

< CmdeViewLink type =" ViewLink ">

< CmdeView type =" ViewObject ">

< CmdeViewRow >

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

< business_data > 1 </ business_data >

</ No >

< Datecmde precision =" 20 " type =" VARCHAR ">

< business_data > 27-03-2002 </ business_data >

</ Datecmde >

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

< business_data > 1 </ business_data >

</ Noclient >

< LgCmdeView type =" ViewLink ">

< LgCmdeView type =" ViewObject ">

< LgCmdeViewRow >

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

< business_data > 1 </ business_data >

</ Nocmde >

< Produit precision =" 20 " type =" VARCHAR ">

< business_data > produit__1 </ business_data >

</ Produit >

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

< business_data > 3 </ business_data >

</ Qte >

</ LgCmdeViewRow >

< LgCmdeViewRow >

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

< business_data > 1 </ business_data >

</ Nocmde >

< Produit precision =" 20 " type =" VARCHAR ">

< business_data > produit__2 </ business_data >

</ Produit >

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

< business_data > 5 </ business_data >

</ Qte >

</ LgCmdeViewRow >

</ LgCmdeView >

</ LgCmdeView >

</ CmdeViewRow >

</ CmdeView >

</ CmdeViewLink >