An ABL service exposes the functionality contained in the business logic layer as APIs for client applications to consume. Each service is bound to one of the following PAS for OpenEdge transports—REST, WEB, SOAP, or APSV. You can create multiple services for the same business logic, each serving a specific type of client application.

Create REST services

REST services are the preferred way to integrate ABL business logic with client applications. REST services are scalable and easier to develop because they use standard HTTP request and response mechanisms.

The REST and WEB transports in PAS for OpenEdge enable you to develop REST services; however, Progress recommends using the WEB transport because it provides more flexibility and supports all HTTP content types.

To create an ABL service based on the WEB transport, you use a web handler as the service interface. A web handler is a custom ABL class that inherits the OpenEdge.Web.WebHandler class and contains methods that map to HTTP verbs (HandleGet(), HandlePost()). When you create the service, you define a list of URIs that get associated with the web handler. At runtime, when a client application makes a request to a URI, the request is passed to the associated web handler and processed by the method that corresponds to the HTTP verb used in the request (GET, PUT, POST, or DELETE).

For more information, see the topic Use a WebHandler in the Develop ABL Services documentation.

Create Progress Data Object services

Progress Data Object services are specially configured services that use either the WEB or REST transport to enable client access to OpenEdge data and operations. Although Data Object services can be used by a variety of web and mobile client applications, they are optimized for use with JavaScript Data Object (JSDO) clients. The JSDO is a client-side library whose purpose is to provide an easy-to-understand API for querying, creating, updating, and deleting Progress Data Objects and invoking server-side business logic.

For more information about creating ABL services, see Develop services in the Develop ABL Services documentation. For more information about JSDO, see Overview of Progress Data Objects, Services, and Catalogs in the Develop Progress Data Objects documentation.

Write ABL procedures to manage request and session context

You may want your application to handle the context in a client request before the request is processed by an ABL service. Context is any data that must persist over several interactions between a client application and the service. This includes things like the user profile, role information, and language preferences. In PAS for OpenEdge, you can manage request and session context by writing event procedures—procedures that are triggered by events such as session startup or shutdown, session connect or disconnect, and agent startup or shutdown.

PAS for OpenEdge provides two application models for client applications to communicate with a PAS for OpenEdge instance: session-free and session-managed. In a session-free model, each request from a client is processed in an independent session by PAS for OpenEdge. Context that must be maintained over several requests must be supplied with each request. Conversely, in a session-managed model, multiple client requests can be handled within the same session.

For more information about managing context, see Programming for a PAS for OpenEdge application model in Application Development with PAS for OpenEdge.

Deploy ABL services to PAS for OpenEdge for testing

After you develop ABL services in your OpenEdge project, you can test them either by deploying the services to a PAS for OpenEdge instance in your local OpenEdge development environment or as part of a CI/CD pipeline, where the services are packaged into a web application and deployed to a remote PAS for OpenEdge instance.

A Progress Developer Studio for OpenEdge installation includes a development version of PAS for OpenEdge that you can use for testing. This video provides an overview of using PAS for OpenEdge in Progress Developer Studio for OpenEdge:

Application migration from OpenEdge AppServer to PAS for OpenEdge

If you migrate your application from OpenEdge AppServer (classic AppServer) or the WebSpeed Transaction Server to PAS for OpenEdge, you must make a few code and property changes. For more information about these changes, see Learn About Migrating Classic AppServer Applications to PAS for OpenEdge in Migrate Classic AppServer Applications to PAS for OpenEdge.