REST Generic Service for the JSDO - Documents - Mobile - Progress Community

REST Generic Service for the JSDO

The REST Generic Service for the JSDO implements the Cloud Data Object (CDO) protocol using a REST Service instead of a Mobile Service.
This service only needs to be deployed once and can be used as a proxy to access data from multiple tables.

This example implements the following operations:
- catalog
- resource (READ)

The KendoUIGrid.html file included in the zip file shows how to use the Generic Service to access data in the Customer table.

This prototype should be a good starting point for anybody wanting to implement a generic / dynamic service.

The prototype only shows access with one database and only READ operations (it can use the filter parameter with a WHERE clause).

Some items for a future version of the Generic Service would be to support the rest of the CRUD operations, use the Abstract Business Entity introduced in 11.4 and also support the JSON Filter Pattern that we have for paging (with count support) and sorting. Also, support for custom Business Entities.

The prototype is a REST Service that implements a Generic Service that can be used from OpenEdge Mobile (JSDO), Kendo UI and Rollbase (via the OpenEdge Service Objects functionality).

The Generic Service generates the catalog for a table and gives access to its data.

The Generic Service provides the catalog and the data dynamically saving you from having to generate Business Entities for each table that you want to make available. From the client point of view, it looks like a Business Entity.

Please notice that even though the service behaves as a Mobile Service from the point of view of the JSDO, it is not a REST Service.

To use the Generic Service, you would just need to create a REST project in Progress Developer Studio and map the procedures "catalogForTable" and "readTable" to using the REST Resource URI Editor (Defined Services -> Edit):
/catalog/{tableName} --> catalogForTable
/catalog/{tableName}?filter={filter} ---> readTable

The input parameters are in the PATH and are mapped to the corresponding parameters in the procedure.
The output parameter jsonText should be mapped to the Body of the response.

Screenshots for readTable:

You can test the generic service (dynamic service) using a URL like the following:
To access the catalog:

To access the data:

Note: If you want a formatted version of the data that is returned, you can use the JSONLint web site to format it:

An instance of the Generic Service is available live at the oemobile demo machine.


URI for data:

An instance of the Generic Service is used in the examples for using Kendo UI:
- Example KendoUIBarChart.html.( )

White paper:

  • REST Generic Service for the JSDO

    Nice work Edsel! Concerning a future version support for datasets containing more than one table would be nice too. For the read I can imagine inputting a servicename and get the coupled datasetstructure from a db.

  • REST Generic Service for the JSDO

    Thank you, Stefan. I am glad that you like it.

    An idea on this area is to have a syntax to specify that you want a multi-table DataSet. For example: /catalog/Customer+Salesrep.

    The relations would be obtained from the schema. Alternatively, there could be a file to define resources.

  • REST Generic Service for the JSDO

    Hi Edsel,

    Sometimes the dataset relations are not so easy to get from the schema. What I do in my backend framework is maintain dataset structures (including relations) and databasetable relations in a separate database used by the framework (see for a small description, the sumary). These data are in a dataset in memory of the appserver session also, for quick access (no runtime reading of the metaschema for performancereasons). I image others have something like what I described in their framework also, or could create the tooling themselves. It would be great to have something easy customizable.

    Regards, Stefan.