A service interface consists of one or more procedure files that provide a layer of abstraction on top of core ABL business logic.

In the following example, the ABL class, Customer.cls, contains some business logic that needs to be exposed to a SOAP client application.
CLASS Customer: 

    METHOD PUBLIC CHARACTER GetCustomerName(INPUT iCustNum AS INTEGER):

        FIND FIRST Customer WHERE Customer.CustNum = iCustNum.
        IF AVAILABLE Customer THEN
            RETURN Customer.Name.
        ELSE
            RETURN "This customer does not exist".

    END METHOD.    

END CLASS.
The business logic returns a customer's name based on customer ID. To expose this functionality through a SOAP web service, you need to create a procedure, serviceInterface.p, that acts as a service interface. For example:
DEFINE INPUT PARAMETER iCustNum AS INTEGER NO-UNDO.
DEFINE OUTPUT PARAMETER cName AS CHARACTER NO-UNDO.

DEFINE VARIABLE oCustomer AS Customer NO-UNDO.

oCustomer = new Customer().
cName = oCustomer:GetCustomerName(iCustNum).

The service interface code must define input parameters that map to input data in SOAP request messages and output parameters that map to output data in SOAP response messages.

In the previous example, the service interface code contains an input parameter (iCustNum), whose value is supplied by the SOAP client application at runtime, and an output parameter (cName), whose value is determined by the ABL business logic (via the call to the Customer class) and then returned to the SOAP client application.

These input and output parameters are used to automatically generate request and response message schemas for the WSDL document of the web service.
Note: While the core business logic can be contained in ABL classes as well as ABL procedures, service interfaces must always be written as ABL procedures.

Session models and persistent and non-persistent procedures

PAS for OpenEdge supports two session models:
  • Session-managed—where the PAS for OpenEdge instance binds the client application to a single ABL session and processes all requests from that client in the same session until the connection is closed. This enables context information such as user login details to be maintained over multiple requests, removing the need for the client application to supply this information with each request.
  • Session-free—where the PAS for OpenEdge instance processes each request in its own session. In this case, each client request must contain all the information that is required by the web service to process the request.

Persistent procedures are used in session-managed connections to PAS for OpenEdge. A persistent procedure remains in memory until its ABL session terminates or a DELETE PROCEDURE statement is called, either from the client application or from the service interface code.

Non-persistent procedures are typically used in session-free connections to PAS for OpenEdge. A non-persistent procedure remains in memory (on the server-side) only until the RUN statement in a client program completes executing.

When you create a web service mapping file, you can set your service interface code to run as persistent or as non-persistent procedures. Before you develop your service interface code, you should identify what parts of your business logic need to be abstracted into persistent procedures and what parts can be run non-persistently.