Einführung in die EGL-Generierung und -Implementierung

Nachdem Sie den EGL-Quellcode geschrieben und getestet haben, wird der Java™-, JavaScript- oder COBOL-Code für eine Zielplattform generiert.

Sie können die Generierung durchführen, wenn die Workbench verfügbar ist, wie nachfolgend und in den folgenden Abschnitten beschrieben:

Alternativ kann die Generierung im EGL-Software-Development-Kit (SDK) erfolgen (siehe "Generierung mit dem EGL-Software-Development-Kit (SDK)").

Nach der Generierung einer Rich-UI-Anwendung oder optional eines Web-Service muss der Workbench-spezifische Schritt 'EGL-Implementierung' ausgeführt werden. Zuletzt ist möglicherweise der Schritt 'EGL-Vorbereitung' erforderlich, z. B. bei der Implementierung von COBOL-Code auf einer fernen Plattform.

In den nächsten Abschnitten wird der Gesamtprozess erläutert.

EGL-Entwicklung und -Debugging

Die effizienteste Vorgehensweise besteht darin, Code zu entwickeln, diesen Code zu debuggen und anschließend explizite Anweisungen zur Generierung und Implementierung der Ausgabe zu erteilen. Wenn Sie jedoch zum ersten Mal mit EGL arbeiten, möchten Sie möglicherweise die Standardeinstellungen der Workbench übernehmen, damit bestimmte Aspekte des Prozesses automatisch ausgeführt werden.

Die Codierung erfolgt zur Entwicklungszeit und das Debugging zur Debugzeit.

EGL-Kompilierung

Bei der Entwicklung von EGL-Quellcode in der Workbench reagiert die Schnittstelle auf Ihre Änderungen. Der EGL-Editor meldet beispielsweise einen Fehler, wenn Sie eine ungültige Funktion schreiben. Nach Behebung des Fehlers wird der Name der Funktion umgehend in der Ansicht 'Ausrichtung' angezeigt.

Wie reagiert die Workbench auf den Code - werden Fehler im EGL-Editor gemeldet und plötzlich Daten in einer anderen Ansicht angezeigt? Dieses Verhalten wird durch eine verdeckte EGL-Kompilierung ermöglicht, die den Quellcode in ein internes Format konvertiert, das später als Eingabe für den EGL-Generator verwendet wird.

Bei jeder Kompilierung wird geprüft, ob der Quellcode syntaktisch und semantisch korrekt ist. Die Gültigkeitsprüfung lässt zu, dass die Workbench auf Fehler reagiert. Die Gültigkeitsprüfung erfasst keine zielplattformspezifischen Fehler.

Der EGL-Compiler ist der Systemcode, der den Quellcode kompiliert. Die Kompilierung findet zur Kompilierzeit statt; dieser Prozess kann vom Benutzer jedoch nicht gesteuert werden.

Der EGL-Compiler ruft anderen Code zur Erstellung der generierten Ausgabe auf.

EGL-Build

Ein EGL-Build ist ein Prozess, der die EGL-Quellcodedateien kompiliert und die Ausgabe in einer Gruppe von Dateien speichert, die für Debugging und Generierung verwendet werden. Die Builddateien werden als IR-Dateien (IR - Intermediate Representation, Zwischendarstellung) bezeichnet. Die Dateispeicherung erfolgt zur Buildzeit.

Die Eingabe für einen Build ist immer eine gespeicherte EGL-Datei.

Die Workbench erstellt bei jeder Speicherung des EGL-Quellcodes einen EGL-Build. Sie übernehmen das Standardverhalten, wenn die Menüoption Projekt > Automatischer Build aktiviert ist. Der Build ist relativ schnell, da er inkrementell erfolgt und nur die IR-Dateien aktualisiert werden, die eine Aktualisierung erfordern.

Wenn Sie die Menüoption Projekt > Automatischer Build inaktivieren, stehen zwei andere Menüoptionen zur Auswahl:
  • Mit Projekt > Build für Projekt kann ein inkrementeller Build für ein bestimmtes Projekt angefordert werden.
  • Mit Projekt > Build für alle kann ein inkrementeller Build für alle Projekte im Arbeitsbereich angefordert werden.

Sie können auch einen EGL-Build ausführen, indem Sie auf die Menüoption Projekt > Bereinigen klicken und die Projekte für den Build angeben. In diesem Fall entfernt die Workbench automatisch die vorhandenen IR-Dateien und erstellt die gesamte Ausgabe. Wenn die generierte Ausgabe nicht erwartungsgemäß funktioniert, verwenden Sie die Option Bereinigen.

Mit den Buildeinstellungen der Workbench wird nicht nur der EGL-Build gesteuert. Insbesondere steuern diese Einstellungen den Java-Build, der den EGL-generierten und anderen Java-Quellcode (Dateierweiterung .java) umwandelt und die Ausgabe in Java-Bytecode (Dateierweiterung .class) speichert. Dieser Aspekt wird im nächsten Abschnitt näher erläutert.

EGL-Generierung

Die EGL-Generierung ist ein Prozess, der IR-Dateien akzeptiert und eine zielplattformspezifische Ausgabe generiert. Die Generierung beinhaltet eine Gültigkeitsprüfung, die sicherstellt, dass die Eingabe für die Generierung der Zielplattform entspricht. Diese Gültigkeitsprüfung ist die Quelle der meisten Nachrichten aus dem EGL-Generator.

Vor der Generierung müssen Sie Regeln für die Generierung der Ausgabe auf einer bestimmten Plattform angeben. Diese Regeln befinden sich in Buildabschnitten; diese Buildabschnitte sind XML-Definitionen, die beeinflussen, wie die Ausgabe generiert und für die nachfolgende Implementierung erstellt wird.

Der wichtigste Buildabschnitt ist der Builddeskriptor. Dieser Abschnitt gibt die Zielplattform an und referenziert gegebenenfalls andere Buildabschnitte.

Bei der Generierung müssen zwei Aspekte berücksichtigt werden:
  • Wenn es in der interaktiven Entwicklungsumgebung zu einem Build kommt, generiert die Workbench immer eine Ausgabe für den Debugge. Aufgrund der Tatsache, dass die Debugausgabe automatisch generiert wird, können andere Aspekte des Generierungs- und Implementierungsprozesses ignoriert werden, bis der Code Ihren Erwartungen entspricht.
  • Bei der Generierung von Ausgabe, die später in einer Produktionsumgebung installiert werden soll, kommen mehrere Optionen zur Anwendung. Zum Anzeigen dieser Optionen klicken Sie auf Fenster > Vorgaben und überprüfen das angezeigte Teilfenster, indem Sie auf EGL > Generierung klicken:
    • Das erste Kontrollkästchen ist Falls notwendig, vor Generierung der Ausgabe einen Build ausführen. Diese Einstellung ist von Bedeutung, wenn Sie explizit einen Generierungsschritt anfordern. Wenn Sie dieses Kontrollkästchen auswählen (Standardeinstellung), stellt die Workbench sicher, dass die IR-Dateien auf dem neuesten Stand sind, bevor die Ausgabe aus den IR-Dateien generiert wird.

      Die Verwendung der Standardeinstellung wird aus dem folgenden Grund empfohlen: Wenn die Workbench die IR-Dateien vor der Generierung der Ausgabe nicht aktualisiert, basiert die Ausgabe möglicherweise auf einer früheren Version der Logik.

    • Unter der Option Bei Build generieren befinden sich Kontrollkästchen für COBOL, Java und JavaScript. Wählen Sie ein Kontrollkästchen aus, um bei jeder Aktualisierung der IR-Dateien eine Generierung zu veranlassen. Die Einstellung ist in den folgenden Fällen von Bedeutung:
      • Die Einstellung Projekt > Automatischer Build ist aktiviert und eine EGL-Datei wird gespeichert. Oder:
      • Die Einstellung Projekt > Automatischer Build ist nicht aktiviert und Sie klicken auf Projekt > Build für Projekt oder auf Projekt > Build für alle. Oder:
      • Sie klicken auf Projekt > Bereinigen.

      Sie können die Kontrollkästchen inaktivieren, wenn Ihnen der folgende empfohlene Prozess zusagt: wiederholtes Schreiben, Build erstellen und Debuggen, wobei die explizite Generierung erst später im Prozess erfolgt.

      Eine Generierung beim Build findet bei Java oder JavaScript statt. Diese Einstellung setzt das Verhalten früherer EGL-Versionen fort. Wenn Sie als EGL-JSF-Entwickler beispielsweise die Standardeinstellung übernehmen, müssen Sie erst dann eine erneute Generierung veranlassen, wenn Sie auf Auf Server ausführen klicken.

      Die automatische Generierung wird für COBOL nicht angegeben, weil die Auswirkungen des Generierungsschritts bei COBOL in der Regel größer sind. Der Generierungsschritt überträgt in der Regel COBOL-Code für die nachfolgende Vorbereitung auf eine andere Maschine und dieser Schritt ist besonders zeitaufwändig.

    • Unter Generierungsmodus stehen zwei Alternativen für die Java- und die JavaScript-Generierung zur Verfügung:
      • main-Abschnitt und Zugehöriges generieren

        Für die COBOL-Generierung ist nur diese Option gültig.

      • Nach Abschnitt generieren

      Details hierzu finden Sie in 'Generierungsmodus'.

Die Primäreingabe für die Generierung besteht aus EGL-Quellendateien, in denen der Abschnitt bzw. die Abschnitte enthalten sind, die generiert werden. Eine weitere Eingabe ist ein EGL-Implementierungsdeskriptor. Der Implementierungsdeskriptor ist eine Datei, die detaillierte Informationen zur Implementierung von Services und Rich-UI-Anwendungen sowie zum Zugriff auf Services enthält. Der EGL-Implementierungsdeskriptor wird jedoch manchmal nicht während der Generierung, sondern in einem späteren Schritt verwendet. Details hierzu finden Sie im nächsten Abschnitt.

Bei Auswahl eines Projekts, eines Pakets oder einer Datei mit einem Abschnitt, für den ein Generierungsschritt möglich ist, können Sie mit der rechten Maustaste klicken und eine der folgenden Einträge aus dem Popup-Menü auswählen:
  • Mit Assistenten generieren. Diese Menüoption zeigt eine Liste der zu generierenden Abschnitte sowie den verwendeten Standardbuilddeskriptor an. Dieser Assistent kann zum Ändern des Builddeskriptors verwendet werden. Ferner können das Zielsystem sowie weitere häufig geänderte Builddeskriptoroptionen geändert werden.
  • Generieren. Diese Option startet den Generierungsprozess und verwendet den für die Datei, das Paket, den Ordner, das Projekt oder die gesamte Workbench angegebenen Standardbuilddeskriptor.

Ein Direktaufruf für diese zweite Option ist STRG-G. Der Direktaufruf ist verfügbar, wenn Sie mit einer Datei arbeiten, die einen Abschnitt enthält, der (in Anbetracht des aktuellen Generierungsmodus) generiert werden kann, oder wenn Sie mit einem Implementierungsdeskriptor arbeiten, der generiert werden kann.

Nach der Generierung von Java-Code findet automatisch ein Java-Build statt, wenn die Menüoption Projekt > Automatischer Build ausgewählt ist. Zur Vermeidung von Fehlern aufgrund von nicht aufgelösten Verweisen in der generierten Ausgabe findet der automatische Build erst nach dem Generierungsschritt und nicht jedes Mal bei der Speicherung einer Java-Datei statt.

Der EGL-Generator ist der Systemcode, der den Quellcode generiert. Die Aktivitäten des EGL-Generators finden zur Generierungszeit statt.

EGL-Implementierung

Die EGL-Implementierung ist ein Workbenchprozess, der EGL-generierte Ausgabe in ein Implementierungsziel schreibt. Dieses Implementierungsziel ist ein explizit angegebenes Projekt oder eine in einem Builddeskriptor angegebene Ausgabeposition. Das Schreiben dieser Ausgabe besteht aus zwei Schritten:
  • Generierung von Ausgabe in Übereinstimmung mit den Einstellungen im EGL-Implementierungsdeskriptor
  • Verschieben zuvor generierter Ausgabe, insbesondere das EGL-generierte JavaScript oder die EGL-generierten Web-Services

Der Implementierungsschritt ist für Rich-UI-Anwendungen erforderlich. Der Vorteil ist Effizienz: Mit einem Implementierungsschritt können Sie Code generieren und die Ausgabe mit einer einfachen Änderung an eines oder mehrere Implementierungsziele übertragen, ohne die Builddeskriptoroptionen ändern und die gesamte Ausgabe neu generieren zu müssen. Das Projekt selbst enthält die Details zum Servertyp und zur JEE-Stufe, die ansonsten im Builddeskriptor angegeben werden.

Rich-UI-spezifische Implementierungsdetails finden Sie in 'Übersicht über die Richt-UI-Implementierung'.

Der Implementierungsschritt ist für EGL-generierte SOAP-Services und EGL-REST-RPC-Services optional. Die genannten Vorteile für Rich-UI-Anwendungen sind für diese Web-Services wirksam, insbesondere wenn der Service auf einem JEE-kompatiblen Anwendungsserver ausgeführt wird. Bei der Implementierung von Web-Services für CICS ist der größte Vorteil jedoch die Konsistenz: für die Generierung der Ausgabe kann derselbe Prozess wie für die anderen Web-Services verwendet werden.

Der Implementierungsschritt ist bei der Generierung und Vorbereitung anderer EGL-generierter Ausgaben wie beispielsweise EGL-Services nicht vorhanden.

Die Implementierung erfordert die Angabe eines Implementierungsziels im Deskriptor. Zwei Varianten sind möglich:
  • Für EGL-generierte Rich-UI-Anwendungen und für Web-Services, die nur die Java-Generierung beinhalten, ist das Implementierungsziel ein explizit angegebenes Projekt.
  • Für EGL-generierte COBOL-SOAP-Services wird das Implementierungsziel durch Referenzieren eines Builddeskriptors angegeben:
    • Für COBOL-SOAP-Services, die unter z/OS CICS ausgeführt werden, gibt die Option genDirectory das Zielverzeichnis an; die nachfolgende Verarbeitung wird durch zusätzliche Einstellungen gesteuert. Details hierzu finden Sie in 'Web-Service unter CICS generieren und implementieren'.
    • Für COBOL-SOAP-Services, die unter IBM® i ausgeführt werden, gibt die Option genProject im Builddeskriptor ein Zielprojekt für die Java-Komponenten an. Details hierzu finden Sie in 'Besondere Hinweise zur Implementierung von COBOL-SOAP-Services unter IBM i'.

    Eine Übersicht der generierten Ausgaben und Laufzeitarchitekturen finden Sie in 'Übersicht über die EGL-Unterstützung für SOA'.

Gehen Sie zur Ausführung des Implementierungsschritts wie folgt vor: Klicken Sie mit der rechten Maustaste auf den Implementierungsdeskriptor oder ein übergeordnetes Projekt und klicken Sie dann auf die Option Implementieren.

Im Hinblick auf Services kann die Festlegung eines Implementierungsziels im EGL-Implementierungsdeskriptor vermieden werden. In diesem Fall gelten die folgenden Angaben:
  • Sie generieren den Implementierungsdeskriptor, wie dies in älteren Versionen von EGL der Fall war. Der Implementierungsdeskriptor kann auch indirekt durch Generierung eines Entwicklungsprojekts generiert werden.
  • Die nachfolgende Verarbeitung wird wie bereits erwähnt über die Builddeskriptoroptionen gesteuert.

Die Aktivitäten der EGL-Implementierungsfunktion finden zur internen Implementierungszeit statt. In der Dokumentation ist manchmal von der externen Implementierungszeit die Rede. Dabei handelt es sich um eine spätere Phase, in der die implementierbare Ausgabe in einer Produktionsumgebung installiert wird.

EGL-Vorbereitung

Die EGL-Vorbereitung ist der Prozess der Kompilierung und sonstigen Umwandlung von EGL-generiertem Java- oder COBOL-Code. EGL-generiertes JavaScript wird nicht vorbereitet.

Der Vorbereitungsschritt folgt der Generierung (bzw. Generierung und Implementierung) der Ausgabe in einem Verzeichnis. Die Vorbereitung findet unter der Kontrolle eines EGL-Buildplans statt. Dieser Buildplan ist eine XML-Datei und hat die folgenden Aufgaben:
  • Steuerung der Kompilierung von Java-Code oder:
  • Kompilierung und sonstige Verarbeitung von COBOL-Code auf einer Zielplattform. Die Verarbeitung kann Binding- und Linkbearbeitungsschritte beinhalten.

Die EGL-Vorbereitung findet zur Vorbereitungszeit statt. Weitere Details hierzu finden Sie in 'Vorbereitung der generierten Java- oder COBOL-Ausgabe'.


Feedback