Enterprise Generation Language (EGL) is a development technology (IDE tooling and programming language) that lets you quickly write full-function applications that can be deployed in WebSphere Application Server, CICS, IMS, and z/OS batch. EGL enables developers, regardless of their experience with underlying run-time technologies, to quickly deliver enterprise data to browsers (in the future, support for other user interface types is likely to be added).
EGL, which is built on the technology of VisualAge Generator, offers several benefits:
Note: This lab exercise requires that the
following products are installed:
|
Later you will use the RETRIEVE SQL feature, which will create data item definitions based on the column definitions stored in relational database catalog. To identify which database and how to connect to that database, set the SQL database access information in the Preferences view.
___ 4. Create an EGL Definitions file
EGL definitions are stored in one of 3 file types: program file (extension .eglpgm), definitions file (extension .egldef), or build file (extension .eglbld).
- Program files contain a single top-level program part, which may embed functions and data parts for the program to reference. The name of the program file must match the name of the program part.
- A program file can import any number of definitions files, which also contain functions and data parts.
- A program file is written in EGL source format.
- A program file is what you test or generate.
- Definitions files contain any number of functions and data parts.
- A definitions file can be imported by program files or by other definition files.
- A definitions file is written in EGL source format.
- Build files contain any number of build parts, which determine how a program is generated and prepared.
- A build file can import other build files.
You will create an EGL definitions file called, AIS, to contain a DB2 record definition (account) to use when accessing the account table and a record definition (acctws) to use when communicating with the EGL server program. By having these records in a separate file, then one definition can be easily maintained and still shared by multiple programs - e.g. by a detail program and or by a list program. By storing all of the record definitions for the AIS database in a separate file, the database administrator could be given the responsibility to create and maintain this file for developers to use.
EGL provides 2 editors for defining and maintaining parts defined in a program file or a definitions file:
- The EGL Parts Editor provides a graphical interface for defining/editing EGL programs, functions, data parts, and build parts. For the new user, this editor is easier because it offers a fill-in-the-blank approach. We will also use it for a time-saving feature, RETRIEVE SQL, which will create, on the click-of-a-button, data item definitions for the account record based on the column definitions stored in relational database catalog. In the future, RETRIEVE SQL will be available in the EGL Source editor as well.
- The EGL Source Editor provides a language sensitive text editor, where you specify logic and data parts in a similar way to writing code in any procedural language. In this case, your work is in EGL source format. You will use this editor later when defining the record, acctws.
acctws is a working storage record, a temporary data area defined in a program or function. Later you will declare acctws to be the parameter data area in our server program. The client that calls the server program will pass the account # and the withdrawal amount in acctws. On return, the server program will pass the new account balance in acctws. To take advantage of copy support (cut and paste) and to explore use of an alternative editor, you will use the EGL Source Editor to define the acctws record.
By having the data areas defined first, code assist can help when inserting data references into a program's or function's logic. This is much faster and more accurate than doing so by hand.
Data areas must be both defined and declared in a program or function before any reference to them is valid. Since the records, account and acctws, are defined in another file, AIS.egldef, the IMPORT statement will link those definitions to our program.
These records can be declared as parameters or variables. Parameters are passed to a program or function from an external source, whereas variables are data areas internal to a program or function. In our EGL server program, the record, acctws, will be declared as a parameter and the record, account, will declared as a variable.
Note: Parameter name is what our logic will use to refer to this data area. TypeDef points to a corresponding data part definition that eventually (before testing or generating a program) must exist. Generally, Parameter name will be the same as TypeDef, but this is not required.
Note: Variable name is what our logic will use to refer to this data area. TypeDef points to a corresponding data part definition that eventually (before testing or generating a program) must exist. Generally, Variable name will be the same as TypeDef, but this is not required.
When writing the logic, code assist (Ctrl+Space) can help you code faster and with greater accuracy. For example, code assist shortens the time it takes to key EGL statements. By having the data areas defined first, code assist can help when inserting data references in the logic.
Script ScriptEndHere are the steps using code assist:
account.ACCT_NUMBER = acctws.ACCT_NUMBER;Here are the steps using code assist:
update account on exception ezertn(); endHere are the steps using code assist:
if (account not err) account.bALANCE = account.bALANCE - acctws.TXN_AMT; replace account on exception ezertn(); end acctws.balance = account.bALANCE; end
___ 1. Create an EGL Build file
The EGL server program can be tested independently of a web browser client and WebSphere application server. The EGL is generated into Java code and then debugged using the integrated EGL debugger of WSED. A build descriptor controls the generation of EGL into Java code. Build descriptors are stored in an EGL build file. The build descriptor will have these options set:
- debug=YES causes special files to be created for use with the debugger
- genProject and packageName indicate where the generated code will be stored
- J2EE=NO says to create code that does not require a J2EE container
- sqlDB identifies the database
- sqlJDBCDriverClass identifies the jdbc support classes to use
- system=WIN causes Java code to be generated for the Windows
___ 3. Generate Java code from account.eglpgm using the debug descriptor
___ 1. Create a Build Descriptor for Java code generation
Part of EGL’s power lies in its ability to generate code for many different runtime environments - Java for WebSphere and COBOL for CICS, IMS and z/OS batch. To enable you to control the generation of such code, EGL provides build descriptors. EGL’s Build descriptors are extremely flexible and can be used to define numerous aspects of how code generation should take place. You will create two build descriptors now that you will actually use in Part2. "win-java" will define how to create a set of Java class files to perform the EGL logic. "wrapper" will define how to create a Java wrapper file which will provide a connector to our EGL server program.
An EGL generated Java wrapper is a set of classes that acts as an interface between a servlet or Java program, on the one hand, and an EGL generated program, on the other. A java wrapper makes calling our EGL server quick and easy for a Java programmer. It provides methods to call the server and methods to get and set the parameter values. The java wrapper will marshall parameter data between java objects and record structures (for generated COBOL programs), convert data between ASCII and EBCDIC, and handle all communication. When you request that a program part be generated as a Java wrapper, EGL produces a wrapper class for each of the following:
The Java wrapper build descriptor will have these options set:
- The generated program
- Each record or structure that is declared as a parameter in that program
- linkage points to a set of options that describe how to call the EGL server program
- nextBuildDescriptor adds the option settings in another build descriptor to the options defined in this build descriptor such as genProject, genProperties, packageName.
- system=JAVAWRAPPER causes the Java wrapper classes to be generated
A linkage part defines how the generated java wrapper should invoke a called EGL program. A brief description of the options you will specify:
- location is the address where the server program executes
- package specifies the directory where the runtime Java classes can be found
- remoteBind=Generation causes the linkage information to be generated into the Java Wrapper, otherwise a linkage properties file must be provided at runtime
- remotePgmType indicates kind of program call conventions to use
By setting the default descriptors in the properties for a project, folder, or individual EGL program, then a build descriptor does not have to be specified for each generation request.