Nachdem Sie den EGL-Quellcode geschrieben und getestet haben, wird der Java™-, JavaScript- oder COBOL-Code für eine Zielplattform generiert.
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.
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.
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.
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 aktiviert ist. Der Build ist relativ schnell, da er inkrementell erfolgt und nur die IR-Dateien aktualisiert werden, die eine Aktualisierung erfordern.
Sie können auch einen EGL-Build ausführen, indem Sie auf die Menüoption 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.
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.
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.
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.
Für die COBOL-Generierung ist nur diese Option gültig.
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.
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 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.
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.
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.
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.
Die EGL-Vorbereitung ist der Prozess der Kompilierung und sonstigen Umwandlung von EGL-generiertem Java- oder COBOL-Code. EGL-generiertes JavaScript wird nicht vorbereitet.
Die EGL-Vorbereitung findet zur Vorbereitungszeit statt. Weitere Details hierzu finden Sie in 'Vorbereitung der generierten Java- oder COBOL-Ausgabe'.