Open Client applications require that non-ABL developers and ABL developers design the application together. Like two contractors working on the same home, they must plan and communicate their specifications so that the finished application works seamlessly for their users.

The following considerations must be agreed upon ahead of time:

  • Client type
  • Session type
  • Business logic
  • Data format
  • Security model

Identify the client type

Each client type requires a different proxy to be generated. Additionally, each client type has recommendations for best coding practices. For that reason, once the client type is determined, both the Open Client developer and ABL developer need to review the content specific to each client type to raise awareness about what is and is not possible for each type.

  • .NET Open Client development
  • Java Open Client development

Identify the session type

The session type for a client connection determines how context is or is not shared between the client and server code. Clients connect to the application server using one of two session types, session free or session managed. Open Clients have this same option.

Session free means that a client is not bound to a single session. Subsequent requests from a client can be handled in different agent session.

Session managed means that a client is bound to a single session. Context is maintained between client requests. Subsequent client requests are handled in the context of the same session. Coding for session managed requires more effort to maintain this context.

A PAS for OpenEdge instance can respond to both session managed and session free client requests. When you generate your proxies, you choose the type of session management for your Open Client interaction. A PAS for OpenEdge instance includes the client run-time licensing needed to execute the r-code.

Identify business logic

ABL developers control how much of the underlying ABL code is exposed to the Open Client developers. For this reason, it is important to have discussions around what is needed to build the proxy between the client and server logic. If all the necessary procedures and functions are not exposed in the process, then the testing phase takes longer. ABL developers are required to regenerate proxy files until all the necessary ABL code are exposed in the proxy.

Identify data types to use

A key feature of the Open Client is support for relational data exchange. This feature allows ABL ProDataSets and temp-tables to be passed between the server and the client application which uses the data in its native environment.
Table 1. Data type mappings
ABL Data type Maps to .NET Maps to Java
ProDataSet parameter (DATASET or DATASET-HANDLE data type) ADO.NET DataSet object ProDataGraph object which is an implementation of the Java Service Data Objects (Java SDO) DataGraph interface
ProDataSet parameter (DATASET or DATASET-HANDLE data type) Temp table parameter (TABLE or TABLE-HANDLE data type) ADO.NET DataTable object

Developer can choose to map to:

  • An OpenEdge ProDataGraph object, as the wrapper for a single temp-table
  • SQL ResultSet object for backwards compatability

Identify the security model

Since communication occurs between clients and the application server using HTTP, both development teams should agree upon the security model they implement. For data in transit, securing the HTTP requests using HTTPS is highly recommended. Additionally, user authentication and authorization techniques help to limit user access to only those parts of the application that meet their specify user or group permission. For details regarding recommendations for securing your applications see the Security content.