When you create a Business Entity class to define a Data Object resource using the New Business Entity wizard, it can define a resource with one of the following sets of standard Data Object operations for the selected data model:

  • A single Data Object Read operation (for a read-only resource)
  • A full set of Data Object CRUD operations
  • A full set of Data Object CRUD operations plus the Submit operation

If the selected data model is a ProDataSet with multiple temp-tables, it also defines a separate Invoke operation for each temp-table that is intended to read the table and return its records to a mobile app as a JavaScript object.

If you choose to include the Data Object Submit operation, along with the other standard CRUD operations using a ProDataSet, the wizard requires that your Business Entity inherit the OpenEdge.BusinessLogic.BusinessEntity abstract class. This abstract class includes protected generic methods that perform much of the work required to implement record change operations using the before-image support available in a ProDataSet. Note that inheriting this abstract class is only useful to implement a Data Object resource that you define to support before-imaging, and the wizard automatically defines all the standard and custom Invoke operations to use a ProDataSet with the data model that you have specified.

If you choose to include the Submit operation using only a single temp-table, the wizard does not allow your Business Entity to inherit the BusinessEntity abstract class, because this base class only supports a Submit operation using a ProDataSet with before-imaging. If you choose to use a single temp-table, note that there can be no before-image support, and you must design your own custom data management model to handle a multi-record CUD request for this single temp-table. Note that any client JSDO that accesses this temp-table resource must also follow the same custom data management model.

For a Business Entity created using the New Business Entity wizard, each Data Object CRUD and Submit operation is defined by a single VOID ABL method whose name is based on the operation name, whose code block is created based on the starting point for generating the Business Entity, and whose parameter list is tailored to reference the selected data model. The exact parameter list for each method is prescribed by the Data Object operation that it implements. The generated name for each method is a concatenation of the operation name with the name of the resource data model instance. For example, if the data for the resource is a ProDataSet named dsCustomer and the read operation is being defined, the method name is created as ReaddsCustomer( ).

The code block of the method for each Data Object CRUD and Submit operation is generated depending on the specified Business Entity data model and whether or not it inherits the BusinessEntity abstract class, as follows:

  • Setting a database table as the data model — Generates a complete code block to implement each method, whether or not the Business Entity inherits the BusinessEntity abstract class.
  • Setting a schema file as the data model for a Business Entity that inherits the BusinessEntity abstract class — Generates most of the code block. You have to add code to access the data-source and specify a record field skip-list for the read operation.
  • Setting a schema file as the data model for a Business Entity that does not inherit the BusinessEntity abstract class — Generates an empty code block. You have to add all of the code to implement each method.

Based on your Business Entity starting point, you must then add any additional code required to implement each Data Object CRUD and Submit operation according to OpenEdge Data Object functional requirements. Note that a resource that supports both Data Object CRUD and Submit operations with before-imaging has different coding requirements than one that supports only CRUD operations without before-imaging. For more information, see Coding ABL for Data Object operations.

Note: It is possible to define a Data Object resource with only CRUD operations that support before-imaging. However, without the use of the Submit operation to do multi-record transactions, most of the benefits of before-imaging support in the client JSDO are lost.

In addition, when the wizard is directed to generate a Data Object Service interface, both the first ABL statement in the file and each METHOD statement in the class are preceded by a set of annotations that start with the '@' character and specify how the class and each method is to be accessed and executed as a Data Object resource and operation. For example, the annotations indicate operation URIs and whether the Data Object resource supports before-imaging.

CAUTION: Use care when modifying any annotations in the ABL source file generated for a Business Entity. Doing so can make the resource inaccessible from clients (mobile apps) or otherwise fail to function. One case where you do need to modify these annotations in the source is for Business Entities you create for client access in the Telerik Platform using the JSDO dialect of the Kendo UI Datasource. For more information, see Updates to allow access by Kendo UI DataSources and Rollbase external objects.