Neuerungen in Rational Business Developer Version 8.5

In diesem Thema werden die neuen Funktionen in Version 8.5 beschrieben.

Details zu den Funktionen, die nach dem ersten Release hinzugefügt wurden, werden auf der folgenden Seite aufgeführt:
Details zu Version 8.5:

Verbesserte Sicherheit für EGL REST-RPC-Services

Version 8.5 enthält eine neue Java-Runtime-Property: egl.service.rest.exception.debug. Diese Eigenschaft gibt an, ob die von EGL REST-RPC-Services zurückgegebenen Ausnahmebedingungen die größtmögliche Detailstufe enthalten.

In der Entwicklungsumgebung ist der Standardwert true und das vorherige Laufzeitverhalten wird nicht beeinflusst.

In einer implementierten Anwendung ist der Standardwert false; dies hat die folgenden Änderung im Laufzeitverhalten zur Folge: eine Ausnahmebedingung gibt nur eine Zeitmarke. eine Nachrichten-ID und eine Referenz auf das Anwendungsserverprotokoll zurück. Die folgenden Anweisungen gelten:
  • Diese Änderung ist in neuen Anwendungen vorhanden sowie in Anwendungen, die auf die die neue Version des EGL-Runtime-Codes migriert werden.
  • Ziehen Sie in Betracht, den Eigenschaftswert auf true zu setzen, wenn die Details, die möglicherweise zurückgegeben werden, frei von Sicherheitsverstößen sind, insbesondere dann, wenn Ihre Verarbeitung vom Inhalt der Fehlernachrichten abhängt.

Details zum Anwendungsserverprotokoll finden Sie im Eintrag für egl.service.rest.exception.debug in Beschreibung der Java-Runtime-Properties.

EGL-Unterstützung für andere Technologien

Ab Version 8.5 werden die folgenden Produkte unterstützt:
  • WebSphere Application Server Version 8.0 und 8.5
  • Apache Tomcat Version 7.x
  • JavaServer Faces (JSF) Version 1.1 in der folgenden Situation: Ihre JSF-Anwendungen laufen mit den JSF 1.1- oder 1.2-jar-Dateien auf Tomcat 6 oder höher.
  • 64-Bit-Linux-Plattform.
  • 64-Bit-Windows-Plattform.

Das Produkt toleriert Plattformen, für die ein Upgrade auf Java™ Runtime Environment Version 1.7 durchgeführt wurde. Ferner kann das Produkt mit IBM® Rational Team Concert Version 4.0 verwendet werden.

Die Rich-UI-Unterstützung für Dojo basiert nun auf Dojo Toolkit Version 1.7.

Rich-UI

Standardmäßig werden die folgenden Rich-UI-Systemprojekte verwendet:
  • Für EGL-Widgets, die nicht auf Dojo basieren: com.ibm.egl.rui_4.1.0
  • Für EGL-Dojo-Widgets: com.ibm.egl.rui.dojo.widgets_2.1.1
  • Für EGL-Dojo-Beispiele: com.ibm.egl.rui.dojo.samples_2.1.1
  • Für den lokalen Dojo-Laufzeitzugriff: com.ibm.egl.rui.dojo.runtime.local_1.7.2
Die folgenden Projekte unterstützen die Verwendung von CDN (Content Delivery Network):
  • Für Dojo 1.6.1:
    • Dojo-Laufzeitzugriff über Google: com.ibm.egl.rui.dojo.runtime.google_1.6.1
    • Dojo-Laufzeitzugriff über AOL: com.ibm.egl.rui.dojo.runtime.aol_1.6.0

    Diese Projekte stehen nur dann zur Verfügung, wenn Sie diese über das Produktinstallationsverzeichnis importieren.

  • Für Dojo 1.7.2:
    • Dojo-Laufzeitzugriff über Google: com.ibm.egl.rui.dojo.runtime.google_1.7.2
    • Dojo-Laufzeitzugriff über Yandex: com.ibm.egl.rui.dojo.runtime.yandex_1.7.2
Setup-Details sind verfügbar:
  • Anweisungen zum Importieren der Rich-UI-Systemprojekte finden Sie in Vom Produkt bereitgestellte Projekte importieren.
  • Wenn Sie ein Upgrade von einem der vorhandenen Rich-UI-Projekte auf ein neues Dojo-Laufzeitprojekt durchführen, muss das Upgrade auch für den EGL-Buildpfad in diesem Projekt durchgeführt werden. Details hierzu finden Sie im Abschnitt 'Überblick über Widget-Upgradetasks' in Übersicht über EGL Rich UI.

Wenn Sie ein Widget dem Rasterlayout hinzufügen, können Sie die Felder heightHint und widthHint eines gridLayoutData-Datensatzes verwenden, um eine Zellengröße vorzuschlagen. Details hierzu finden Sie in Rich-UI-Rasterlayout.

Beachten Sie, dass Version 8.5. nicht die Rich UI-Entwicklung auf einer 64-Bit-Linux-Plattform unterstützt. Einschränkungen bei externer Software verhindern momentan noch diese Unterstützung.

Änderungen an Builddeskriptoroptionen

EGL enthält nun die folgenden Builddeskriptoroptionen:
  • Für Java-Code gibt die Option validateBlankDateFields an, ob im folgenden Fall ein Fehler angegeben werden soll: Die Eigenschaft dateFormat ist für ein Feld in einem Textformat wirksam, der Benutzer hat das Feld jedoch als leer definiert. Details hierzu finden Sie in validateBlankDateFields.
  • Für Java-Code wird mit der Option byteArrayOperationsForStructuredRecords in manchen Fällen ein Leistungsvorteil erzielt, wenn definiert wird, wie generierter Java-Code Felder in strukturierten Datensätzen behandelt. Details hierzu finden Sie in byteArrayOperationsForStructuredRecords.
  • Für Java- und COBOL-Code gibt die Builddeskriptoroption v60NumWithDateBehavior an, ob das Verhalten von Zuordnungen von Num-Feldern auf Date-Felder das Verhalten erfüllt, das in EGL-Version 6 wirksam war. Details hierzu siehe v60NumWithDateBehavior.
  • Für COBOL-Code, betreffen die Optionen leftAlign, fillWithNulls und setFormItemFull Daten in Textformatfeldern, wie dies im VisualAge Generator der Fall war. Zuvor wirkten sich die Optionen in EGL nur auf Druckformatfelder aus. Details zu den Optionen finden Sie in fillWithNulls, leftAlign und setFormItemFull.

    Wenn Sie Ihre Textformate neu generieren müssen und die Feldmerkmale, die zuvor in in EGL wirksam waren, beibehalten wollen, setzen Sie die folgenden symbolischen Parameter auf NO: ALLOWTUILEFTALIGN, ALLOWTUISETFORMITEMFULL und ALLOWTUIFILLWITHNULLS. Details hierzu finden Sie in Vordefinierte symbolische Parameter, die vom Benutzer gesetzt werden können.

  • Für COBOL-Code gibt die Option v71AddBehavior an, ob der Effekt des Pluszeichens (+) in einem bestimmten Fall durch den Typ der Variablen bestimmt wird, der ein Ausdruck zugeordnet ist. Der Zweck liegt im Beibehalten von Code, der für die EGL-Versionen ab 6.0 bis 7.1 geschrieben wurde. Details hierzu finden Sie in v71AddBehavior.
Ferner können vorhandene Builddeskriptoroptionen mit neuen Werten definiert werden, wenn Sie eine der neu unterstützten Versionen von WebSphere Application Server oder Apache Tomcat verwenden:
  • Die Builddeskriptoroption serverType gibt den Typ des Webanwendungsservers an, in dem die Ausgabe implementiert wird. Details hierzu finden Sie in serverType.
  • Für Java-Code gibt die Builddeskriptoroption j2eeLevel die Java Enterprise Edition-Stufe auf dem Anwendungsserver an, auf dem ein EGL-Web-Service implementiert ist. Details hierzu finden Sie in j2eeLevel.

COBOL-Verarbeitung

Mit dem neuen symbolischen Parameter DUALMODE können Sie ein EGL-Programm einmal generieren und ein vorbereitetes Lademodul erstellen, das unter z/OS Batch und CICS ausgeführt wird. Details hierzu finden Sie in Einmalige Generierung für z/OS Batch und CICS.

Potentielle Änderung bei einer Verbindungseigenschaftendatei

Lesen Sie die Informationen in diesem Abschnitt, wenn Sie Eigner einer generierten Java-Anwendung sind, für die das Element callLink (in einem Verbindungsoptionsabschnitt) die folgende Eigenschafteneinstellung enthält: remoteBind=runtime.

Möglicherweise müssen Sie überprüfen, ob die Einträge in einer vorhandenen Verbindungseigenschaftendatei sich auf den Wert der Eigenschaft linkageKey und nicht auf den Namen des aufgerufenen Programms beziehen. Diese Situation tritt in den folgenden Fällen aus:
  • Eine call-Anweisung umfasst die Eigenschaft linkageKey.
  • Sie verwenden eine Verbindungseigenschaftendatei, um die Verbindungsdetails für diese Anweisung anzugeben.
  • Sie führen ein Upgrade auf die neueste Version des EGL Runtime-Codes aus.
Details hierzu finden die ein den eintragsspezifischen Informationen in Verbindungseigenschaftsdatei - insbesondere in den Details für programName und wildProgramName.

Feedback