Alternatively, you can generate in the EGL software development kit (SDK), as described in “Generation using the EGL Software Development Kit (SDK).”
After you generate a Rich UI application or, optionally, a web service, you fulfill a Workbench-specific step called EGL deployment. Last, a step called EGL preparation might be required; for example, when you are deploying COBOL code on a remote platform.
The next sections outline the overall process.
The most efficient practice is to develop and debug your code and then give explicit directions to generate and deploy your output. However, when you begin working with EGL, you might accept the default settings of the Workbench so that aspects of the process occur automatically.
Coding occurs at development time, and debugging occurs at debug time.
As you develop EGL source code in the Workbench, the interface responds to your changes. For example, the EGL editor signals an error if you write an invalid function. After you fix the error, the name of the function is immediately displayed in the Outline view.
How does the Workbench respond to your code, signaling errors in the EGL editor and suddenly displaying data in a different view? Those behaviors are made possible by a hidden EGL compilation, which converts your source code to an internal format of a kind later used as input to the EGL generator.
Each compilation validates whether the source code is correct syntactically and semantically. The validation lets the Workbench respond to errors. The validation does not catch errors that are specific to a target platform.
The EGL compiler is the system code that compiles your source code. Compilation occurs at compile time, but you do not control this aspect of the process.
The EGL compiler invokes other code to create generated output.
An EGL build is a process that compiles your EGL source-code files and stores the output in a set of files that are used for debugging and generation. The built files are called intermediate representation (IR) files. The file storage occurs at build time.
The input for a build is always a saved EGL file.
By default, the Workbench does an EGL build each time you save your EGL source code. You accept the default behavior by leaving a check mark for the menu option. The build is relatively fast because it is incremental, updating only the IR files that require an update.
You also perform an EGL build when you click the menu option and indicate which of your projects to build. In that case, the Workbench immediately removes the existing IR files and builds all the output. When the generated output is not working as you expect, try the Clean option.
The Workbench build settings control more than the EGL build. In particular, they control the Java build, which transforms your EGL-generated and other Java source code (file extension .java) and stores the output in Java bytecode (file extension .class). The next section revisits this detail.
An EGL generation is a process that accepts IR files and generates output that is specific to a target platform. Generation includes a validation step to ensure that the input to generation is appropriate to the target platform. This validation step is the source of most messages from the EGL generator.
Before generation, you provide rules for generating output to a specific platform. The rules are in build parts, which are XML definitions that affect how output is generated and how output is built for subsequent deployment.
The most important build part is the build descriptor. That part identifies the target platform and references other build parts as appropriate.
The default setting is recommended for the following reason: if the Workbench does not update your IR files before output is generated, the output might be based on a previous version of your logic.
You can clear the check boxes if you are comfortable with the following, recommended process: write, build, and debug repeatedly, leaving an explicit generation for later in the process.
By default, a generate on build occurs for Java or JavaScript. This setting continues the behavior of previous versions of EGL. For example, if you are an EGL JSF developer, your acceptance of the default setting means that you do not need to remember to regenerate before you click Run on server.
The automatic generation is not specified for COBOL because, in most cases, the effect of the generate step is greater for COBOL. The generate step usually transfers COBOL code to another machine for subsequent preparation, and that step is particularly time consuming.
Only this option is valid for COBOL generation.
For details, see “Generation mode.”
The primary input to generation are EGL source files that include the part or parts being generated. Another input is an EGL deployment descriptor, which is a file that gives details on deploying services, deploying Rich UI applications, and accessing services. However, the EGL deployment descriptor is sometimes used, not during generation, but during a later step. The next section gives details.
A shortcut for that second option is to click CTRL-G. The shortcut is available when you are working on a file that includes a part that can be generated (given the current generation mode) or when you are working on a deployment descriptor that can be generated.
After you generate Java code, a Java build occurs automatically if the menu option is in effect. To avoid errors that would result from unresolved references in the generated output, the automatic build occurs only after the generation step is fulfilled rather than each time a Java file is saved.
The EGL generator is the system code that generates your source code. The EGL generator does its work at generation time.
The deployment step is necessary for Rich UI applications. The benefit is efficiency: your use of a deployment step means that you generate code and then push the output to one or another deployment target with a simple change, rather than changing build descriptor options and regenerating all the output. The project itself includes the details on server type and JEE level, which are details that are otherwise specified in the build descriptor.
For deployment details that are specific to Rich UI, see “Overview of Rich UI deployment.”
The deployment step is optional for EGL-generated SOAP services and EGL REST-RPC services. The benefits mentioned for Rich UI application are in effect for those web services, especially when the service runs in a JEE-compliant application server. However, when you are deploying web services for CICS®, the main benefit is consistency: you can use the same process for producing output as is available for your other web services.
The deployment step is not present when you generate and prepare other EGL-generated output such as EGL services.
For an overview of the generated outputs and the runtime architectures, see “Overview of EGL support for SOA.”
To fulfill the deployment step, do as follows: right-click the deployment descriptor or an enclosing project and then click the Deploy option.
The EGL deployer does its work internal-deployment time. The documentation sometimes refers to external-deployment time, which is a subsequent stage, when the deployable output is installed in a production environment.
EGL preparation is the process of compiling and otherwise transforming EGL-generated Java or COBOL code. EGL-generated JavaScript is not prepared.
EGL preparation occurs at preparation time. For further details. see “Preparation of generated Java or COBOL output.”