OpenEdge Development

OpenEdge Advanced Business Language (ABL), developed by Progress Software Corporation, is a high-level programming language specifically designed for building robust business applications with integrated database capabilities.

OpenEdge ABL supports both procedural and object-oriented programming, allowing developers to structure applications with efficiency and flexibility.

This structure provides a modular, maintainable approach to development, allowing for clear separation between application logic, interface design, reusable components, and compiled outputs

OpenEdge ABL’s multi-file structure is integral to its functionality. The language organizes code into specific file types, each with a distinct role in application development and management:

.p – Procedure files
.w – GUI and procedure files
.i – Include files
.cls – Class files
.r – Compiled files

**Procedure Files -*.p**

WHAT?

External and internal procedures:

External Procedures: In Progress 4GL/ABL, an external procedure, typically a .p file, is a standalone procedural file containing one or more statements and this is the smallest unit of code that Progress can compile and execute. Notably, an external procedure does not require a specific keyword or header to define it. Multiple internal procedures (entry points) can be defined within an external procedure file, each providing specific functionalities that can be individually accessed within that file.

Internal Procedures: Internal procedures are named blocks of code within an external procedure file, accessible only within the file they’re defined in. While they are run similarly to external procedures, they do not require the .p file extension when called, making them more efficient for internal, file-specific tasks.


/* external procedure mainProgram.p */
//internal procedure procl
procedure proc1:

message "In proc1".

end procedure.

//internal procedure proc2
procedure proc2:

message "In proc2".

end procedure.

WHY?

OpenEdge ABL’s structure, including its file types and use of internal and external procedures, allows developers to break down applications into manageable, reusable components, which simplifies maintenance and development.

Internal Procedures: Useful for structuring code within a single file, making it easier to understand and manage.

External Procedures: Allow the same logic or functions to be reused across multiple programs, minimizing code duplication and making updates easier since changes in an external procedure file apply universally..

HOW?

Create a procedure file:

Run an internal and external procedure:


/* External Procedure File: helloWorld.p */
/* Internal Procedure */
procedure sayHello:
    display "Hello, World!".
end procedure.

**GUI and procedure files – *.w**

WHAT?

In OpenEdge ABL, .w files are primarily used for creating graphical user interface (GUI) elements in applications, though they can also contain procedural logic. They combine the visual design of an interface with the underlying code to manage user interactions, allowing developers to design screens, menus, forms, and other UI components.

GUI Components: These files often include buttons, text fields, labels, and other interactive elements that make up the user interface. .w files use an event-driven model, meaning specific actions trigger the execution of procedural code. Event-Driven Procedures: The procedural code within .w files is typically structured as procedures that respond to events (clicks, selections, or data entry).

WHY?

The purpose of .w files in OpenEdge ABL is to provide a clear separation between application logic and user interface design, making it easier to manage both aspects independently. By centralizing all GUI elements in .w files, developers can easily modify the user interface without impacting the underlying business logic.

HOW?

Create a .w:

Examples of widgets:

Code Block Headers: Using clearly marked sections, such as Definitions, Frame Definitions, Control Triggers, and Internal Procedures, organizes code into logical
sections, making it easier to locate specific functionality.
Descriptive Comments: The comments explaining each procedure’s purpose (enable_UI, disable_UI), as well as the purpose of each trigger, help future developers
understand the intention behind each block.
Event Handlers and Main Logic Separation: Triggers (such as END-ERROR and WINDOW-CLOSE) are separate from the main logic block, allowing the file to handle
user inputs and window closures in a clean, isolated manner.

**Include files – *.i**

WHAT?

In OpenEdge ABL, include files (.i files) are files that contain reusable code snippets, definitions, or declarations that can be shared across multiple program files. They are essentially templates or modular code blocks that can be “included” in other files to avoid code duplication. .i files are similar to header files in other programming languages, as they allow commonly used definitions and logic to be centralized in one location.

Content: Include files can contain variable declarations, procedure definitions, constants, or even reusable code blocks that need to be accessed in multiple places.
Syntax: The contents of an .i file are inserted into a program using the INCLUDE statement.

WHY?

The purpose of include files is to promote code reusability in OpenEdge ABL applications. Using .i files offers several benefits:
Reduced Code Duplication: Instead of rewriting the same variables, constants, or code blocks in multiple files, include files allow the code to be written once and included wherever needed.
Improved Maintainability: Centralized code makes it easier to manage and update.
Simplified Code: By removing redundant definitions and consolidating them into include files, the main program files are shorter and easier to read.

HOW?

How to create an include file:

Create an include file includeExample.i
Include this file in the external procedure/class where you need to use.



/* includeExample. */
define temp-table ttFields no-undo
  field FieldName as character
  field FieldValue as character



/* External Procedure File: helloWorld.p */ 
includeExample.i}|
procedure sayHello:
  display "Hello, World!".
end procedure.

{includeExample.i}: This statement includes the contents of includeExample.i in helloWorld.p. The code from includeExample.i will be “copied” into helloWorld.p at this
point.

**Class files – *.cls**

WHAT?

In OpenEdge ABL, class files (.cls files) enable object-oriented programming (OOP), allowing developers to create classes that define objects with specific properties and
methods. Class files introduce concepts like encapsulation, inheritance, and polymorphism, supporting more modular and scalable code.
Content: Class files contain class definitions, including properties (variables), methods (procedures or functions), and constructors for initializing objects.
Syntax: Each .cls file defines one class and includes CLASS and METHOD definitions to structure its data and behavior.

Protocol for class hierarchy and reference

WHY?

Class files provide a framework for creating organized, reusable, and maintainable code structures. They are particularly useful in larger applications where OOP principles
improve development efficiency and code quality.
Modularity and Reusability: Classes enable the encapsulation of related data and behaviors into a single structure, which can then be reused across the application.
Encapsulation: Properties and methods in a class are contained within that class, reducing the chance of errors and unintended interactions.
Inheritance: Classes can inherit from other classes, allowing developers to extend or customize functionality without rewriting code, promoting code reuse.
Improved Maintainability: Classes provide a clear and organized way to manage code, making it easier to update and debug.

HOW?

Define the Class in a .cls File:



class src.classFolder.classExample:

   /* Data Members */
   define private variable id as integer no-undo.
   define public property Name as character no-undo get. set.

   /* Default Constructor */
   constructor public classExample ():
      super().
      assign
        id = 0.
   end constructor.

   /* Parameterized Constructor */
   constructor public classExample (input pID as integer, input pName as character): 
      super(). 
      assign
        id = pID
        Name trim (pName).
   end constructor.

   /* Public Method */
   method public character GetInfo():
        return "ID: " + STRING (id) + ", Name: + Name.
   end method.

   /* Private Method */
   method private void UpdateID (input newID as integer):
      assign
        id = newID.
   end method.

   /* Destructor */
   destructor public classExample ():
   /* Cleanup code here */
   end destructor.

end class.

Data members store data that each instance of the class will hold. They are typically defined as properties or variables and can be public or private, depending on whether
you want them accessible outside the class.
Constructor: Constructors are special methods called when an instance of a class is created. They initialize the class’s data members and set up the initial state of the
object. A class can have multiple constructors with different parameters to support various ways of initializing objects.
Default Constructor: Sets id to 0.
Parameterized Constructor: Allows setting id and Name upon object creation, allowing more flexible initialization.
Methods: Methods define the actions that an instance of the class can perform.
Properties with Custom Accessors: Properties can be defined with custom GET and SET methods, allowing you to control how the data is accessed and modified.
Destructor: A destructor is an optional method that performs cleanup when an object is deleted or goes out of scope.

**Compiled files – *.r**

WHAT?

A .r file is the compiled output of an ABL source code file (such as .p, .w, .i, or .cls). When ABL source code is compiled, the resulting binary file has the .r extension. .r files
are platform-independent executable files used by the OpenEdge runtime environment to execute ABL applications.

WHY?

.r files play a critical role in the OpenEdge ABL development and deployment process due to the following reasons:
Performance Optimization: Since .r files are pre-compiled, they can be executed directly by the runtime environment, reducing the overhead of compiling code at runtime
and improving application performance.
Code Protection: By distributing only .r files, developers can protect their source code, as the .r file does not contain the original source code logic, only the compiled binary
instructions.
Simplified Deployment: Since .r files are executable, deploying an application becomes as simple as transferring the .r files, reducing the need to manage and transfer full source files.

HOW?

To work with .r files in OpenEdge ABL, you follow these steps:
Compile the Source Code to Generate .r Files: You can compile .p (procedure files), .w (GUI files), .cls (class files), and other source files into .r files.
Deploy and Execute .r Files: Once the .r file is generated, it can be deployed across platforms as part of the application. OpenEdge’s runtime engine directly loads and runs
.r files, making deployment straightforward.
Run an .r File: Use the RUN command to execute an .r file just like a .p file.

In conclusion, OpenEdge ABL offers a structured, powerful framework for developing business applications by combining procedural and object-oriented programming with database integration. Its modular file types — such as procedure files (.p), GUI files (.w), include files (.i), class files (.cls), and compiled files (.r) — enable efficient, maintainable, and reusable code. Each file type fulfills a specific role, ensuring a clear separation between data, logic, and interface. This organized structure simplifies development, deployment, and maintenance, making OpenEdge ABL an adaptable solution for scalable business applications.