Introduction to EGL generation and deployment

After you write and test EGL source code, you generate Java™, JavaScript™, or COBOL code for a target platform.

You can generate when the Workbench is available, as described here and in the following topics:
  • "Generating from the workbench batch interface"
  • "Generating with an Ant script"

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.

EGL development and debug

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.

EGL compilation

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.

EGL build

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 Project > Build Automatically menu option. The build is relatively fast because it is incremental, updating only the IR files that require an update.

If you remove the check mark for the Project > Build Automatically menu option, two other menu options are available:
  • Project > Build Project lets you request an incremental build for a specific project.
  • Project > Build All lets you request an incremental build for all the projects in your workspace.

You also perform an EGL build when you click the Project > Clean 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.

EGL generation

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.

Consider two aspects of generation:
  • When a build occurs in the interactive development environment, the Workbench always generates output for the debugger. The fact that the debug output is automatically generated lets you ignore other aspects of the generate-and-deploy process until you are satisfied with your code.
  • Several options apply when you generate output that will ultimately be installed in a production environment. To see these options, click Window > Preferences and review the pane displayed by clicking EGL > Generation:
    • The first check box is If necessary, invoke a build before generating output. The setting is meaningful when you explicitly request a generate step. If you select the check box, as is the default, the Workbench ensures that the IR files are up to date before output is generated from the IR files.

      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.

    • Under Generate on build are check boxes for COBOL, Java™, and JavaScript™. You select a check box to cause a generation to occur whenever the IR files are updated. The setting is meaningful in any of the following cases:
      • Project > Build Automatically is in effect and you save an EGL file; or
      • The Project > Build Automatically is not in effect, and you click Project > Build Project or Project > Build All; or
      • You click Project > Clean.

      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.

      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.

    • Under Generation mode are two alternatives for Java™ and JavaScript™ generation:
      • Generate the main part and its associates .

        Only this option is valid for COBOL generation.

      • Generate by part.

      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.

When you select a project, package, or file that contains a part for which a generation step is possible, you can right-click and choose one of the following entries from the popup menu:
  • Generate With Wizard. This menu option shows a list of parts that will be generated, and shows the default build descriptor that will be used. You can use the wizard to change the build descriptor. You can also change the target system, and other frequently modified build descriptor options.
  • Generate. This option starts the generation process, and uses the default build descriptor you specified for the file, package, folder, project, or for the entire workbench.

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 Project > Build Automatically 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.

EGL deployment

EGL deployment is a Workbench process that writes EGL-generated output into a deployment target, which is a project you specify explicitly or an output location identified in a build descriptor. The writing of that output includes two actions:
  • Generating output in accordance with settings in the EGL deployment descriptor.
  • Moving output that was previously generated; in particular, the EGL-generated JavaScript™ or web services.

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.

Deployment requires that you specify a deployment target in the descriptor. Two variations are in effect:
  • For EGL-generated Rich UI applications and for web services that involve only Java™ generation, the deployment target is a project that you specify explicitly.
  • For EGL-generated COBOL SOAP services, you specify the deployment target by referencing a build descriptor: 
    • For COBOL SOAP services that run on z/OS® CICS®, the genDirectory option identifies the target directory, and additional settings control the subsequent processing. For details, see Generating and deploying a web service on CICS®.
    • For COBOL SOAP services that run on IBM® i, the genProject option in the build descriptor identifies a target project for the Java™ components. For details, see Special considerations for deploying COBOL SOAP services on IBM® i.

    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.

In relation to services, you can avoid setting a deployment target in the EGL deployment descriptor. In that case, the following details apply:
  • You generate the deployment descriptor, as was the case in earlier versions of EGL. You might generate the deployment descriptor indirectly, by generating the development project.
  • The build descriptor options control the subsequent processing, as noted earlier.

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

EGL preparation is the process of compiling and otherwise transforming EGL-generated Java™ or COBOL code. EGL-generated JavaScript™ is not prepared.

The preparation step follows the generation (or generation and deployment) of output into a directory. The preparation occurs under the control of an EGL build plan, which is an XML file that has the following uses:
  • To control the compilation of Java™ code; or
  • To compile and otherwise process COBOL code on a target platform. The processing can include bind and link-edit steps.

EGL preparation occurs at preparation time. For further details. see Preparation of generated Java™ or COBOL output.