Using OE Data objects without the JSDO

Posted by on 16-Apr-2018 07:23

HI All 

I am looking for some advice here.

We have been developing back-end business entities using the OE Data Objects framework and now we are looking at the development of the UI.

The UI team have been shown the JSDO but are not to keen to implement as they do not want to tightly couple the UI app to Openedge / Progress.

I am looking for advice as to what are the issues of not using the JSDO, i can some see some straight away in terms of authentication, record management and data typing but any good examples would be great.

Also if someone explains at layer the prods: fields are used are they in the framework or in the OE Prodataset layer?



All Replies

Posted by Peter Judge on 17-Apr-2018 12:28

The JSDO component will do the client-side authentication and session management for you. Those things are still controlled by the server.
The JSDO still works over standard HTTP and consumes the Data Object Catalog which is a public API of the services; the catalog exposes business resources in a fairly prescriptive manner.
The JSDO makes working with data feel closer to ABL (working with datasets/temp-tables) – including knowing how and when to work with the prods: properties.  These control the before-imaging (change control) and some error handling of records in temp-tables in a dataset.  They are reasonably simple to figure out. In ABL, make sure you have before-tables defined with some change data and call WRITE-JSON() with the write-before-image flag set to TRUE. Basically there end up being up to 3 ‘sections’ in the JSON: one for the data as it is now, one for the data as it was before any changes, and one for errors.
Check out the ABL’s TRACKING-CHANGES, MARK-ROW-STATE and of course WRITE-JSON methods in the Help for information about each piece. There’s a short example of using them at
I thought there was some description of the JSON we produce from the WRITE-JSON() method at  but sadly not.

This thread is closed