Try OpenEdge Now
skip to main content
Web Services
Creating OpenEdge REST Web Services : Data Object Services : Coding Business Entities to implement Data Objects : Coding ABL routines to implement a Data Object resource
Coding ABL routines to implement a Data Object resource
When you create a Data Object resource in Developer Studio for OpenEdge, you can either create a new class to implement the resource using the New Business Entity wizard or you can use the Define Service Interface wizard to create the resource from an existing ABL class or external procedure coded to run as a singleton. Using either of these wizards, you can define ABL routines that implement one or more operations for a single Data Object resource. You can also create a new Business Entity by creating an Express Data Object project, which creates a fully-implemented Data Object Service containing a single Data Object that provides access to a ProDataSet with a single temp-table based on a selected OpenbEdge database table.
Note: Express Data Object Services can only be built for an OE Web Server (Tomcat) for access to a classic OpenEdge AppServer.
The two basic options that you must define for any class or procedure that implements a Data Object resource include the data model and the Data Object operations that the class or procedure supports. As described previously (see Overview of Data Object Services), a Data Object resource can support a single data model that is managed by the standard operations of a Data Object: Create, Read, Update, Delete (CRUD), and Submit. This data model can be the ABL definition for a single temp-table or a single ProDataSet that contains one or more temp-tables, including any data-relations defined for them.
If you want to use the Submit operation with a ProDataSet, the temp-tables of the ProDataSet must also define before-tables to support before-imaging; you can then take advantage of built-in ProDataSet support for managing complex data transactions. If you want to use the Submit operation with a single temp-table, there is no before-image support, and you must develop your own model for managing multi-record updates to an OpenEdge database.
In a ProDataSet resource with related (parent-child) temp-tables, you might want to define the data-relations between them using the NESTED option, especially if you pass this ProDataSet data as output from Invoke operations to which the client must respond. Nesting allows the data in the response from the Invoke operation to be more easily inspected and managed by the client, because the child table records are all grouped and nested under each related parent table record.
In the Developer Studio wizards, you can select the data model from any temp-tables and ProDataSets that are defined in the class or procedure file, or in another external file that you specify. Once completed, the wizard, if directed, inserts the selected data definition in the main block of the class or procedure based on the data model that you select and creates empty stubs for resource operation methods that you can use to implement the Business Entity class that is created. If you create a Business Entity class as part of an Express Data Object project (for classic OpenEdge AppServer deployments only), you select a single table from an OpenEdge database as your data model, which generates the corresponding definition for a ProDataSet with a single temp-table. In this case, OpenEdge creates an entire initial implementation for all the resource operation methods created in the Business Entity.