A JSDO is an instance of the progress.data.JSDO JavaScript class that you create to access exactly one Data Object resource provided by a Data Object Service. As described in Run-time architecture and data access, a Data Object resource provides access to either a single-table or a multi-table resource. The exact type of resource that a Data Object provides depends on the Data Object Service and the data model selected to create the resource. A Data Object resource is created with a set of standard operations to access its data model. These can include a standard set of Create, Read, Update, Delete (CRUD), and Submit operations, or only a single Read operation, depending on the options chosen to create the Data Object resource. In any case, the same basic set of Data Object operations access the data for every Data Object resource regardless of the data model it supports. The server API that implements these operations have prescribed signatures that depend on the type of data model selected for the Data Object resource. For an OpenEdge resource, this server API consists of ABL routines running on an OpenEdge application server.

The prescribed relationship between the standard Data Object operations and the data model of a Data Object resource allows the JSDO class to provide a corresponding set of standard JavaScript methods that implicitly map to the standard operations of a Data Object resource, no matter what data model it supports. In addition, for every JSDO, the internal structure of JSDO memory reflects the schema of the particular data model supported by the Data Object resource. Therefore, the standard methods of a JSDO work on the data in its JSDO memory according to the schema defined for the resource data model.

The basic unit of data for a Data Object resource is the table record, which is represented in JSDO memory as a JavaScript record object (progress.data.JSRecord class). The standard Read operation returns a set of records from the server for one or more tables, depending on the data model. The set of records that the Data Object Read operation returns depends on the implementing API routine and an optional filter parameter that you pass to it from the mobile app. The standard Create, Update, and Delete operations of a Data Object resource operate on one table record per server request, according to the implementation of the corresponding API. The Submit operation can operate on an OpenEdge ProDataSet resource for which before-imaging is enabled, for any number of created, updated, and deleted OpenEdge temp-table records per server request. Thus a Submit operation can support multi-record transactions with created, updated, and deleted records. The corresponding standard JSDO methods call these operations accordingly, loading temp-table records into JSDO memory from the server, or creating, updating, and deleting records on the server from posted changes to the record objects in JSDO memory.

A Data Object resource can also support custom Invoke operations which can be implemented by the server API, depending on the Data Object Service and resource. For an OpenEdge resource, the ABL routine that implements an Invoke operation can have any signature defined with supported ABL data types (see Data type mappings for Data Object Services). A JSDO created for a Data Object resource with Invoke operations has corresponding custom JavaScript invocation methods that map to each Invoke operation. Calling an invocation method on the JSDO calls the implementing server API routine, passing the required input parameters and returning its output parameters and any return value to the mobile app with no direct effect on JSDO memory. The mobile app can do whatever it needs to do with the results of an invocation method, including merging any returned data with JSDO memory, as appropriate.

Note: For more information on coding the ABL routines that implement the Data Object operations for an OpenEdge resource, see the information on Data Object Services in Develop ABL Services.