Nouveautés dans Rational Business Developer version 8.5

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) :
  • Pour Dojo 1.6.1 :
    • Accès à l'environnement d'exécution Dojo Google : com.ibm.egl.rui.dojo.runtime.google_1.6.1
    • Accès à l'environnement d'exécution Dojo AOL : com.ibm.egl.rui.dojo.runtime.aol_1.6.0

    Ces projets ne sont disponibles que si vous les importez à partir du répertoire d'installation du produit.

  • Pour Dojo 1.7.2 :
    • Accès à l'environnement d'exécution Dojo Google : com.ibm.egl.rui.dojo.runtime.google_1.7.2
    • Accès à l'environnement d'exécution Dojo Yandex : com.ibm.egl.rui.dojo.runtime.yandex_1.7.2
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.

Traitement COBOL

Le nouveau paramètre symbolique DUALMODE permet de générer un programme EGL une fois pour toutes et de créer un module de chargement préparé qui est exécuté sur un lot z/OS et CICS. Pour les détails, voir Génération une fois pour toutes pour les lots z/OS et CICS.

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.

Commentaires en retour