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:
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):
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.