Vom Migrationstool der Version 7.0 nicht vorgenommene Änderungen

Bei der Migration auf EGL Version 7.0 nimmt das Migrationstool möglicherweise nicht alle erforderlichen Änderungen vor.

Nach der Migration des Codes auf Version 7.0 müssen Sie möglicherweise die in den folgenden Abschnitten beschriebenen Änderungen vornehmen:

Projekterstellungsprogramme umbenennen

Wenn Sie ein migriertes Projekt in einen Arbeitsbereich der Version 7.0 importieren, zeigt die Sicht der Generierungsergebnisse möglicherweise an, dass ein Abschnitt nicht generiert werden konnte, da ein Standardbuilddeskriptor fehlt; dies kann auch der Fall sein, wenn Sie einen Standardbuilddeskriptor festgelegt haben.

Zur Behebung dieses Problems aktualisieren Sie die Builder für das Projekt so, dass EGL Advanced Builder nach EGL Build Parts Model Builder und EGL Validation Builder aufgeführt ist.

Gehen Sie wie folgt vor, um die Erstellungsreihenfolge auf diese Weise zu bearbeiten:
  1. Klicken Sie in der Projektexplorersicht mit der rechten Maustaste auf das Projekt und dann auf Eigenschaften.
  2. Klicken Sie im Eigenschaftenfenster auf Builder.
  3. Wählen Sie auf der Builder-Seite EGL Advanced Builder aus.
  4. Versetzen Sie EGL Advanced Builder mithilfe der Schaltfläche mit dem Abwärtspfeil unter EGL Build Parts Model Builder und EGL Validation Builder.
  5. Klicken Sie auf OK.

Änderungen bei der Auflösung von Eigenschaften

Wenn Sie einen Abschnitt mit demselben Namen definieren, den auch eine EGL-Eigenschaft aufweist, löst EGL Referenzen möglicherweise in den Namen mit dem benutzerdefinierten Abschnitt auf, nicht in die EGL-Eigenschaft.

Länge zu DECIMAL-Typen hinzufügen

Wenn Sie eine Funktion stringAsDecimal migriert haben, fügt das Migrationstool möglicherweise eine Umsetzung zum DECIMAL-Typ hinzu, um das Verhalten des alten Codes beizubehalten. In diesem Fall müssen Sie manuell eine Länge hinzufügen.

Gehen Sie zum Beispiel vom folgenden alten Code aus:
myStringNumber string = "5";
myResult decimal(7,2);
myResult = stringAsDecimal(myStringNumber) + 5;
Das Tool migriert diesen Code wie folgt:
myStringNumber string = "5";
myResult decimal(7,2);
myResult = myStringNumber as decimal() + 5;
Fügen Sie eine Länge zum DECIMAL-Typ hinzu:
myStringNumber string = "5";
myResult decimal(7,2);
myResult = myStringNumber as decimal(7,2) + 5;

Variablen oder Funktionen umbenennen

Eine Variable und eine Funktion mit demselben Namen können nicht im selben Logikabschnitt enthalten sein. Benennen Sie die Variable oder die Funktion um.

Runde Klammern zu aufgerufenen Programmen hinzufügen

Programme, bei denen es sich um das Ziel einer Anweisung call handelt, müssen über eine Parameterliste verfügen. Diese Parameterliste kann leer sein, die runden Klammern, die die Parameterliste kennzeichnen, sind nun jedoch erforderlich.

Nicht mehr aktuelle Servicereferenzen entfernen

Das Migrationstool versucht, nicht mehr aktuelle Servicereferenzen aus Metadatendateien in den migrierten Projekten zu entfernen. Wenn eine der folgenden Bedingungen zutrifft, kann das Tool die Referenzen jedoch nicht entfernen:
  • Sie haben die optionale Komponente mit den IBM® WebSphere Application Server-Entwicklungstools nicht installiert oder Ihre Version umfasste IBM WebSphere Application Server und die zugehörigen Entwicklungstools nicht.
  • Sie generieren Java™-Code in ein Projekt, für das Sie das Migrationstool nicht ausgeführt haben.
In beiden Fällen müssen Sie veraltete Servicereferenzen manuell aus den Metadatendateien entfernen:
  • Wenn Sie bei EGL-Webprojekten Servicereferenzen manuell zur Webimplementierungsdeskriptordatei hinzugefügt haben, löschen Sie alle von EGL generierten Servicereferenzen aus der Datei und behalten Sie alle manuell hinzugefügten Referenzen bei. Wenn Sie keine Servicereferenzen manuell zur Datei hinzugefügt haben, müssen Sie die Datei löschen. In den meisten J2EE-Versionen lautet der Name der Webimplementierungsdeskriptordatei 'web.xml' und sie befindet sich im Ordner WebContent/WEB-INF des Projekts. In J2EE 1.3 lautet der Name der Datei 'webservicesclient.xml' und sie befindet sich an derselben Position.
  • Entfernen Sie entsprechend alle von EGL generierten Servicereferenzen aus den Dateien ibm-webservicesclient-ext.xmi und ibm-webservicesclient-bnd.xmi, die sich ebenfalls in WebContent/WEB-INF befinden. Wenn Sie keine Referenzen manuell zu diesen Dateien hinzugefügt haben, können Sie die Dateien löschen, dies ist jedoch nicht zwingend erforderlich.

Variablentypen in JSF-Handlern ändern

Wenn für eine Variable in einem JSF-Handler der Wert index für die Eigenschaft selectType festgelegt ist, muss diese Variable den Typ INT aufweisen.

Eigenschaft selectFromListItem verwenden

Wenn eine Variable über die Eigenschaft selectFromListItem verfügt, darf der Wert dieser Eigenschaft kein Datensatzarray bzw. kein Array primitiver Variablen innerhalb eines Datensatzes sein. Gültige Typen sind eine Datentabellenspalte bzw. ein Array primitiver Variablen außerhalb eines Datensatzes. Wenn Sie ein Datensatzarray oder ein Array primitiver Variablen innerhalb eines Datensatzes als Liste mit Auswahloptionen verwenden möchten, verwenden Sie die Eigenschaft selectedRowItem oder selectedValueItem.

Konsistente Datensatz- oder Arraytypen zum Abrufen und Festlegen von Attributen verwenden

Der Typ eines Datensatzes oder Arrays zum Empfangen des von den nachfolgend aufgeführten j2eeLib-GET-Funktionen zurückgegebenen Werts muss mit dem Typ übereinstimmen, den auch das Argument zum Festlegen des Attributs in den entsprechenden SET-Funktionen aufweist:
  • getRequestAttr()
  • getSessionAttr()
  • getApplicationAttr()

Der von getRequestAttr() zurückgegebene Wert muss denselben Typ aufweisen wie das Argument, das für setRequestAttr() verwendet wurde, um Laufzeitfehler zu vermeiden.

EGL Version 7.0 speichert nur die Geschäftsdaten des Objekts, um den Heapspeicherbedarf zu reduzieren.

Änderungen bei generierten Namen mit Unterstreichungszeichen

Der Algorithmus zur Beibehaltung eindeutiger Namen, wenn ein EGL-Name Zeichen enthält, die in Java-Namen ungültig sind, wurde geändert. Das Unterstreichungszeichen ('_') wird nun dem Hexadezimalwert für das ungültige Zeichen vorangestellt. Java-Namen, die aus EGL-Namen mit einem Unterstreichungszeichen generiert werden, enthalten nun den Hexadezimalwert 005.

Beispiel: EGL generiert die folgenden Java-Namen, die dem EGL-Namen 'under_score_test' entsprechen:
  • Version 6: under_score_test
  • Version 7: under_005fscore_005ftest

Dies führt nicht zu Problemen zwischen EGL-Programmen, wenn alle Programme in Version 7 neu generiert werden. Ein Nicht-EGL-Programm, das ein EGL-Programm aufruft, muss jedoch so geändert werden, dass es das neue Format für alle Namen verwendet, die Unterstreichungszeichen enthielten. Hierzu gehören auch Nicht-EGL-Clients von EGL-Services oder Jasper-Berichte.

Änderungen bei der generierten WSDL-Definition für Parameter für strukturierte Datensätze

Der Algorithmus für die Generierung der WSDL-Definition eines Serviceparameters liefert in Version 7 einen anderen Code für strukturierte Datensätze. Alle Clients, die den Service aufrufen, müssen so geändert werden, dass sie den Service mit dem neuen Parameternamen aufrufen.

Verhalten von Arrays als Funktionsparameter mit 'in' auflösen

Wenn Sie den Änderungswert in in einer Parameterdefinition für ein Array verwenden, muss der Argumentelementtyp mit dem Parameterelementtyp übereinstimmen.

Beispiel: Die folgende Sequenz ist in EGL Version 6 gültig, wird jedoch in Version 7 als ungültig gekennzeichnet:
function main();
  arrayArg CHAR(50)[ ] = ["A", "B", "C"];
  showArray (arrayArg);  // ungültige Anweisung in Version 7
end

function showArray (arrrayParm CHAR(100) [ ] in)
  i, iEnd INT;
  iEnd = size (arrayParm);
  for (i from 1 to iEnd)
    writeStdOut (arrayParm[i]);
  end
end

Der Änderungswert in für arrayParm bedeutet, dass für den Parameter beim Aufrufen der Funktion eine temporäre lokale Variable zugeordnet wird und das Argument der temporären Variablen am Funktionsbeginn zugewiesen wird. In Version 6 bewirkte die Zuweisung, dass eine Kopie des Argumentarrays erstellt wurde. In Version 7 stellt die Zuweisung eine Referenz auf das Array dar. Da Arrayzuweisungen in Version 7 zwischen Arrays mit demselben Elementtyp erfolgen müssen, wird der Aufruf von showArray() in main() in Version 7 als Fehler gekennzeichnet.

Für die Auflösung dieser Situation stehen zwei Möglichkeiten zur Verfügung:
  1. Verwenden Sie die Anweisung move, um eine temporäre Kopie des Arguments zu erstellen, die mit der Parameterdeklaration kompatibel ist:
    function main() ;
      arrayArg CHAR(50)[ ] = ["A", "B", "C"];
      	tempArrayArg CHAR(100) [ ];
    	  move arrayArg to tempArrayArg;
    	  showArray (tempArrayArg);
    	end
  2. Ändern Sie die Arrayelementtypen so, dass sie identisch sind und dass nicht bei jedem Funktionsaufruf ein neues Array erstellt wird. Im folgenden Beispiel werden die Elementtypen in STRING geändert, da die Kundenanwendungen in Java generiert werden, wobei der Typ STRING bessere Ergebnisse liefert als CHAR:
    function main();
      arrayArg STRING[ ] = ["A", "B", "C"];
      showArray (arrayArg);  // ungültige Anweisung in Version 7
    end
    
    function showArray (arrrayParm STRING[ ] in)
      i, iEnd INT;
      iEnd = size (arrayParm);
      for (i from 1 to iEnd)
        writeStdOut (arrayParm[i]);
      end
    end

Linkerweiterungen ändern

Links auf JSF-Seiten werden in forward to url-Anweisungen sowie in der Eigenschaft action für Variablen, die mit displayUse = hyperlink definiert sind, angegeben. Das Migrationstool von EGL Version 7 ändert die Linkerweiterung automatisch von .jsp in .faces, wenn die URL oder die Aktion als Literalwert angegeben ist, der auf .jsp endet. Diese Änderung muss manuell vorgenommen werden, falls der Linkwert nicht auf .jsp endet oder falls der Wert aus einer Variablen stammt, nicht aus einem Literal.

Builddeskriptoroption 'defaultDateFormat' ändern

Bei der Zeichenfolge-in-Datum-Konvertierung in Version 7 muss die Reihenfolge von Tag, Monat und Jahr in der Zeichenfolge identisch sein mit der Reihenfolge von Tag, Monat und Jahr in der Builddeskriptoroption defaultDateFormat. Informationen zu den Standardwerten, die verwendet werden, wenn diese Builddeskriptoroption nicht angegeben wird, finden Sie in defaultDateFormat (Builddeskriptoroption).

In Version 6 ging der Konvertierungsalgorithmus vom Format jjjjMMtt aus. Daher kann ein Datumswert wie '20050810' in Version 7 zu einem Fehler führen, es sei denn, Sie geben für die Builddeskriptoroption defaultDateFormat explizit den Wert jjjjMMtt an.

Builddeskriptoren für Druckformulare definieren

In VisualAge Generator und in EGL Version 6 stammten die Standarddezimal- und -trennzeichen für Druckformulare aus dem sprachabhängigen Optionsmodul, das für die Laufzeitinstallation angegeben wurde. Ab Version 7 bestimmen die Builddeskriptoroptionen decimalSymbol und separatorSymbol diese Zeichen. Ab Version 7 ist der Standardwert für die Option decimalSymbol ein Punkt und der Standardwert für die Option separatorSymbol ist ein Komma. Wenn diese Werte für Ihren Standort nicht korrekt sind, müssen Sie diese Builddeskriptoroptionen explizit festlegen.

Hinweise zu anderen Builddeskriptoroptionen

In den neueren Versionen von EGL wurden einige Builddeskriptoroptionen eingeführt, die sich auf das Verhalten auswirken, das sich im Laufe der Zeit geändert hat. Berücksichtigen Sie diese vor dem Hintergrund der jeweiligen EGL-Version, von der aus Sie die Migration durchführen:

Feedback