Cette rubrique présente les nouvelles fonctions de la version 8.5.
Pour plus de détails sur les fonctions créées après l'édition initiales, consultez la page suivante :
Voici les détails sur la version 8.5 :
Sécurité accrue pour les services REST-RPC
EGL
La version 8.5 introduit une nouvelle propriété d'exécution Java :
egl.service.rest.exception.debug. La propriété définit si
les exceptions renvoyées par les services REST-RPC EGL comprennent le niveau de détails
le plus élevé possible.
Dans l'environnement de développement,
la valeur par défaut est true et le comportement d'exécution précédent n'est
pas affecté.
Dans une application déployée, la valeur par défaut est
false,
ce qui résulte en la modification suivante dans le comportement d'exécution : une exception
ne renvoie qu'un seul horodatage, un seul ID message et une seule référence au
journal de serveur d'applications. L'instruction suivante s'applique :
- La modification est présente dans les nouvelles applications et dans les applications
qui migrent vers la nouvelle version du code d'exécution EGL.
- Pensez à paramétrer la valeur de propriété sur true si les détails
susceptibles d'être renvoyés n'enfreignent pas les règles de sécurité, plus particulièrement
si votre traitement dépend du contenu des messages d'erreur.
Pour plus d'informations sur le journal du serveur
d'applications, consultez l'entrée pour egl.service.rest.exception.debug dans Description des propriétés d'exécution Java.
Prise en charge d'EGL pour d'autres technologies
La version
8.5 prend désormais en charge :
- WebSphere Application Server versions 8.0 et 8.5.
- Apache Tomcat version 7.x.
- JavaServer Faces (JSF) version 1.1, dans la situation suivante :
vos applications JSF s'exécutent avec les fichiers JSF 1.1 ou 1.2 jar sur Tomcat 6 ou version ultérieure.
- Plateforme Linux 64 bits.
- Plateforme Windows 64 bits.
Le produit accepte les plateformes mises à niveau vers Java™ Runtime Environment
version 1.7. Il coexiste également avec IBM® Rational Team Concert version 4.0.
En outre, la prise en charge de Rich UI pour Dojo est désormais basée sur le toolkit Dojo version
1.7.
Rich UI
Par défaut, les projets de système Rich UI
suivants sont utilisés :
- Pour les widgets EGL non basés sur Dojo : com.ibm.egl.rui_4.1.0
- Pour les widgets Dojo EGL : com.ibm.egl.rui.dojo.widgets_2.1.1
- Pour les échantillons Dojo EGL : com.ibm.egl.rui.dojo.samples_2.1.1
- Pour l'accès à l'environnement d'exécution Dojo local : com.ibm.egl.rui.dojo.runtime.local_1.7.2
Les projets suivants prennent en charge l'utilisation de CDN (Content
Delivery Network) :
Les informations de configuration suivantes sont disponibles :
- Pour des instructions sur l'importation de projets du système Rich UI, voir Importation de projets fournis par le produit.
- Si vous migrez vers un nouveau projet d'exécution Dojo
à partir de l'un de vos projets Rich UI existants, vous devez mettre à niveau le chemin de compilation EGL
dans votre projet. Pour plus de détails, reportez-vous à la section relative à la présentation des tâches de mise à niveau de widget : Présentation d'EGL Rich UI.
Lorsque vous ajoutez un widget à la disposition en grille, vous pouvez utiliser les champs heightHint et widthHint d'un enregistrement gridLayoutData pour proposer une taille de cellule. Pour les détails, voir Rich UI GridLayout.
Sachez que la version 8.5 ne prend pas en charge le développement Rich UI sur une plateforme Linux 64 bits. Cela est dû à des restrictions au niveau du logiciel externe.
Modifications apportées aux options de descripteur de compilation
EGL
inclut désormais les options de descripteur de compilation suivantes :
- Pour du code Java, l'option
validateBlankDateFields indique si une erreur doit être
identifiée dans le cas suivant : la propriété dateFormat est
appliquée pour une zone au format texte, mais l'utilisateur a défini cette zone sur vide. Pour les détails, voir validateBlankDateFields.
- Pour du code Java, l'option
byteArrayOperationsForStructuredRecords offre un avantage en termes de
performances dans certains cas, en définissant la manière dont le code Java généré traite les zones des enregistrements structurés. Pour les détails, voir byteArrayOperationsForStructuredRecords.
- Pour le code COBOL et Java,
l'option de descripteur de génération v60NumWithDateBehavior
définit si le comportement des affectations provenant des zones Num
vers les zones Date est conforme au comportement en vigueur dans EGL version
6. Pour plus d'informations, voir v60NumWithDateBehavior.
- Pour le code COBOL, les options leftAlign, fillWithNulls
et setFormItemFull affectent maintenant les données
dans les zones de formulaire de texte, comme précédemment dans VisualAge Generator. Auparavant dans EGL,
les options n'affectaient que les zones de formulaire d'impression. Pour plus d'informations sur les options,
consultez fillWithNulls, leftAlign
et setFormItemFull.
Si
vous avez des raisons de régénérer vos formulaires de texte et souhaitez conserver
les caractéristiques de zones en vigueur précédemment dans EGL, définissez
les paramètres symboliques suivants sur NO : ALLOWTUILEFTALIGN, ALLOWTUISETFORMITEMFULL
et ALLOWTUIFILLWITHNULLS. Pour les détails, voir Paramètres symboliques prédéfinis pouvant être définis par l'utilisateur.
- Pour le code COBOL, l'option v71AddBehavior
indique si, dans un cas spécifique, l'effet du signe plus (+)
est déterminé par le type de variable à laquelle une expression est affectée.
L'objectif est de conserver le code rédigé précédemment pour les versions d'EGL
ultérieures à la version 6.0 et jusqu'à la version 7.1. Pour les détails, voir v71AddBehavior.
En outre, vous pouvez affecter à des options de descripteur de compilation existantes de
nouvelles valeurs si vous utilisez une version de
WebSphere Application Server
ou Apache Tomcat nouvellement prise en charge :
- L'option de descripteur de compilation serverType
identifie le type de serveur d'applications Web dans lequel votre sortie sera déployée. Pour les détails, voir serverType.
- Pour du code Java, l'option de descripteur de
compilation j2eeLevel spécifie le niveau de Java Enterprise
Edition sur le serveur d'applications sur lequel un service Web EGL est déployé.
Pour les détails, voir j2eeLevel.
Modification potentielle d'un fichier de propriétés de liaison
Prenez connaissance de cette section si vous disposez d'une application Java générée pour laquelle un élément callLink (dans une partie Options de liaison) inclut le paramètre de la propriété suivante : remoteBind=runtime.
Il peut s'avérer nécessaire de vérifier si les entrées dans un fichier de propriétés de liaison sont liées à la valeur d'une propriété
linkageKey et non au nom du programme appelé. Cette situation se produit dans le cas de figure suivant :
- une instruction call inclut la propriété linkageKey ;
- vous utilisez un fichier de propriétés de liaison pour spécifier les informations de liaison pour cette instruction ; et
- vous mettez à jour la dernière version du code d'exécution EGL.
Pour des détails, voir les informations liées aux entrées dans
Fichier de propriétés de liaison, et plus particulièrement à
programName et
wildProgramName.