A modern OpenEdge application is designed on OpenEdge Application Architecture (OEAA) principles, which prescribe isolating UI code, business logic code, data access code, etc, into separate layers. You start the design process by identifying APIs that are to be used by client applications and then determining the underlying software components.

OpenEdge Application Architecture (OEAA)

OpenEdge Application Architecture (OEAA) is the recommended way to design a Progress OpenEdge application.

OEAA consists of the following layers:

  • A Data Access layer that manages the retrieval of data from sources such as an OpenEdge database.
  • A Business Components layer that contains the core business logic.
  • A Service Interfaces layer that translates requests into a format that the Business Components layer can process.
  • An Enterprise Services layer that exposes the business logic to applications and services that exist beyond the bounds of the OpenEdge application.
  • A Presentation layer that contains the user interface.
  • A Common Infrastructure layer containing framework code to support the application business logic. The recommended way to develop components in this layer is to use a framework based on the Common Component Specification.

Common Component Specification

The Common Component Specification (CCS) is a specification which was driven by the OpenEdge community to define a prescriptive architecture to use when building enterprise business applications with OpenEdge. The CCS uses a service-oriented architecture (SOA) design in which application components provide services to other components through a communications protocol. The CCS resulted in a suite of object-oriented ABL classes which exist as part of the OpenEdge.Core.pl/apl procedure libraries. To learn more about these classes, see the OpenEdge ABL API Reference or the ABL Class, Interface, and Enumeration Reference.

API-first design

An API (short for Application Programming Interface) provides a set of functions or procedures that a client application can call on a server application. Modern applications are built API-first, which means prioritizing the concerns of the client application developer. You begin by visualizing your application as a set of services that can be easily consumed by client applications. Complexities in your business logic layer are managed in the service interface and hidden from the client application. This leads to a better developer experience and enables you to add new functionality later on with minimal disruption to existing integrations.

OpenEdge provides the ability to expose APIs to client applications through ABL services. You can think of an ABL service as comprising two layers—an API and a service interface. The API is the URI that a client application sends requests to. A service interface is the code that handles those requests and transforms them if needed, so that the underlying business logic layer can process them.

To learn more about developing APIs in OpenEdge, see API-first development.