Establishing standard coding practices is the first step to automating your OpenEdge development

Source control

Source control is an important part of a CI/CD pipeline, and it enables collaboration among software developers. Source control ensures that there is a single source of truth when it comes to the code. With multiple developers working on the same code, merging and managing their disparate changes can be confusing, and can cause errors and regressions. Using a development platform with a source control system mitigates the risk of developers overwriting others' changes, preventing many potential disasters.

There are a number of options for source control, including Roundtable TSMS, GitHub, GitLab, and Apache Subversion.

ABLUnit test framework

The ABLUnit test framework is used for unit testing ABL code. The framework is provided with Progress Developer Studio for OpenEdge, but it can also be used with projects outside of Progress Developer Studio.

For more information, see Learn About ABLUnit Test Framework in Progress Developer Studio for OpenEdge Online Help.

Architectural components

The following are the core set of logical components that make up an OpenEdge application. Additional logical components may also be included in your application:
  • Service interfaces
  • Business logic
  • Data stores
  • Common libraries, including $DLC

A service requires two components: an API and a service interface. In an OpenEdge application, an ABL WebApp provides the API, and the ABL service provides service interfaces. The service interface communicates and interprets requests from all aspects of the application and transforms the incoming data. The service interface is a translation layer that communicates requests to the appropriate business services through business logic. Service interfaces can also provide authentication, authorization, and error handling.

The business logic, data stores, and common libraries are the core pieces of the application, and are what is traditionally thought of as an application. Business logic is made up of things like master data maintenance, order entry, or tax calculations. Data is stored in one or more OpenEdge databases. Common or shared libraries contain generic code that is needed for an application. Configuration files for deployment, authorization, and authentication can also be considered core pieces of an appliaction.

Unit testing

Unit testing is the process of testing individual components of a software application to ensure that they work in isolation. This is the simplest stage of testing because it does not test an application as a whole; it tests individual sections of code. Unit testing is helpful when the code is being developed because it can catch issues very early. Unit testing is especially beneficial when it is automated because you can quickly determine if the code you just wrote is functional. If there are problems with the code, then you can make changes quickly.

API testing

API testing is a subsection of integration testing that focuses on ensuring that the APIs for your software are functioning correctly. APIs are tested individually, similar to unit testing, and in transactions to ensure they function properly in isolation and together. Notable API testing tools include Fiddler and Postman.

R-code

R-code is binary code that is created when OpenEdge compiles ABL code. R-code is a secure code format generated as r-code files (.r files) from ABL source code, whether encrypted or in plain text.

For more information, see R-code Features and Functions and R-code structure in Manage ABL Applications.

Procedure libraries

A procedure library (.pl file) is a collection of files and images that is used to package an ABL application. Procedure libraries are used to both efficiently store and efficiently execute r-code files and ABL code. You can use procedure libraries with many file types, such as .r, .wrx, .w, and .i files.

For more information, see Manage Procedure Libraries and Procedure library overview in Manage ABL Applications.

Encrypt source code with XCODE

The XCODE utility is provided with ABL, and enables you to encrypt your ABL source code. Encrypting your source code provides application security because users cannot read your application source code or make changes to it. XCODE uses less storage than r-code and is therefore much more portable, with the added benefit of still allowing compilation into r-code files.

For more information, see XCODE utility and Prepare to use XCODE in Manage ABL Applications.