A Progress Data Object Service is a web service built using a supported transport (currently, REST) and a Data Service Catalog. This service runs in a web application on a web server. The Progress Data Service Catalog is a JSON file that describes the schema for one or more Data Object resources and the operations that can be invoked on these resources by the client. A Data Object resource represents a set of data on a server that can be accessed by the client using specific operations supported by that resource. This set of data can include either a single table or multiple tables containing one or more records of data. A Data Object operation reads or writes resource data, or otherwise executes business logic associated with the resource, in a single network request. The possible schema and operations for a given resource depends on the type of its Data Object Service, which can be (currently) either OpenEdge or Rollbase.
A Progress Data Object provides access to a single resource provided by a Data Object Service and consists of both a server and client Data Object that exchange resource data over the web as JSON. The server Data Object is an object that implements the schema of the resource and its supported set of operations. The client Data Object consists of a set of JavaScript classes and objects known together as the JavaScript Data Object (JSDO). The classes and objects of the JSDO allow the client app to create one or more JSDO instances to access one or more Data Object resources provided by a Data Object Service. A single JSDO instance provides access to a single resource using a login session (JSDO login session) that the JSDO establishes in the web application hosting the Data Object Service that provides its resource.
The classes and objects of the JSDO include:
progress.data.JSDO class — Allows you to create and manage a JSDO instance for a given Data Object resource and to execute supported operations on that resource. These operations are accessed as JSDO methods that hide all the details of the JSON encoding/decoding and REST protocols used to invoke these operations over the web.
progress.data.JSDOSession class — Allows you to asynchronously create a JSDO login session in the web application that hosts a given Data Object Service and to access the Data Service Catalog, which is typically hosted by the same web application.
progress.data.JSRecord class — Represents a single record of data associated with a Data Object resource that is stored in the memory of the JSDO instance.
progress.data.Session class — As an alternative to the JSDOSession class, allows you to either synchronously or asynchronously create a JSDO login session in the web application that hosts a given Data Service and to access the Data Service Catalog, which is typically hosted by the same web application.
progress.ui.UIHelper class — Allows you to dynamically bind JSDO data to a JavaScript UI using certain supported UI frameworks.
request object — Returns the results of a single operation on the server Data Object and its resource.
In order to create a JSDO instance, the client app first reads the Data Service Catalog in order to configure the instance with the schema and operations that are specifically supported by the specified Data Object resource. Note, again, that a given Data Object Service and its Catalog can support one or more single-table and multi-table resources from which the client can create JSDO instances. The types of resources that a Data Object Service can support depends on the capabilities of the data server that the Data Service is created to access. You can then create a given JSDO instance to access any particular single-table or multi-table resource that the specified Data Object Service supports.
The types of resources and operations that are available in this release of Progress Data Object Services include those supported by:
An OpenEdge application server — Single-table resources based on Advanced Business Language (ABL) temp-tables or single-table and multi-table resources based on ABL datasets (ProDataSets). In addition to one or more temp-tables, a ProDataSet resource can also support OpenEdge before-imaging, as does the JSDO instance that accesses it. Each resource is implemented on the server by an OpenEdge Business Entity, which is an ABL procedure or class-based object (the server Data Object) that encapsulates the resource schema and its supported operations. A JSDO instance created for an OpenEdge Data Object Service can therefore provide access to either a single temp-table resource and its operations or a single ProDataSet resource and its operations.
The Data Object operations on OpenEdge resources can include any or all of Create, Read, Update, and Delete (CRUD), Invoke (which allows the client to directly invoke ABL business logic on the application server), and for ProDataSet resources that support before-imaging, Submit, which can batch multiple CUD operations with complex transaction management. Any JSDO that accesses an OpenEdge resource can accept or reject the results of individual CUD operations based on record change errors returned from the server. If it uses a Submit operation to access a ProDataSet resource that supports before-imaging, the JSDO can accept or reject all record changes involved in a single transaction that is synchronized with the server.
A Rollbase server — Single-table resources based on Rollbase objects. A Rollbase object thus implements the server Data Object that encapsulates the schema and supported operations for a given single-table resource. The available Rollbase object resources provided by a given Rollbase Data Object Service are those in a Rollbase view from which the Data Object Service is created. A JSDO instance created for a Rollbase Data Object Service can therefore provide access to a single Rollbase object resource and its operations only.
The Data Object operations on Rollbase resources can include Create, Read, Update, and Delete (CRUD), and Invoke (which allows a client to access Rollbase objects that are related to the single Rollbase object resource for which the JSDO instance is created). Note that Rollbase resources do not support before-imaging or Submit operations. A JSDO instance that accesses a Rollbase resource can accept or reject individual CUD operations based on each record-change error returned from the server.
A JSDO supports a few basic methods for preparing and invoking supported operations on Data Object resources. Once you have established a JSDO login session and created a JSDO instance to access a given Data Object resource, you can load the JSDO (JSDO memory) with data from the resource, modify the data in JSDO memory, update the resource with these JSDO memory modifications, and perform other business logic using the following basic JSDO methods:
fill( ) — Calls a Read operation on the resource to initialize and load data (in the form of record objects) into JSDO memory.
add( ), assign( ), or remove( ) — A basic method that creates, updates, or deletes (respectively) an individual record object in JSDO memory.
saveChanges( ) — Depending on the resource, the record objects currently changed in JSDO memory, and how you invoke it, either this method individually calls one or more Create, Update, and Delete (CUD) operations on a single record object of the resource, with each operation sent to the server one record-change request at a time, or this method calls a single Submit operation that updates the resource with all the current record object changes in JSDO memory in a single request to the server. If the resource supports before-imaging, the results of multiple record object changes from a Submit operation can also be handled as a batch in JSDO memory. If the resource does not support before-imaging, the results of any single CUD or Submit operation can only be handled one record object at a time in JSDO memory.
Invocation method — A custom-named JSDO method that calls an Invoke operation and returns the results of a corresponding routine that executes on the server. A JSDO can have as many invocation methods as routines that are supported by the resource for remote access on the server. For OpenEdge resources, the names of these methods are determined by the ABL Business Entity developer, who maps each invocation method to an ABL routine that the method remotely calls on the Business Entity. For Rollbase object resources, the names of these methods are automatically generated by Rollbase for any invocation methods that need to be defined for access by a JSDO. Rollbase maps each such invocation method to a Rollbase server method that reads and returns the data from a given Rollbase object that is related to each Rollbase object resource. For all resources of a given Progress Data Object Service, the mappings for invocation methods are defined in the Data Service Catalog. Note that any data returned from an invocation method is not automatically added to JSDO memory, but can be used either to update existing record objects in JSDO memory, or to add new record objects using the JSDO add( ) or addRecords( ) method.
In addition, the JSDO provides numerous properties, methods, and events that support the execution and management of these basic methods for modifying the data in JSDO memory and invoking resource operations. For more information, see Using JSDOs to create mobile and web clients.
progress.data.JSDO class — Allows you to create and manage a JSDO instance for a given Data Object resource and to execute supported operations on that resource. These operations are accessed as JSDO methods that hide all the details of the JSON encoding/decoding and REST protocols used to invoke these operations over the web.