DataObjectHandler with JSDO

Posted by Darren Parr on 03-Jul-2019 11:17

Hi

We've played with creating our own handlers for the JSDO. There doesn't seem to be any examples of webhandler code which processes anything but a GET. So I started looking at using the DOH and I can see how it works. To be honest I didn't see the benefit of writing our own to do the same job. We have a basic need to make use of our own dynamic catalog generation logic because the PDS doesn't support temp-tables defined like another table. We're interfacing with a legacy system on the back-end which utilises temp-tables in this way and we need to be able to pass our temp-tables to existent business logic.   

Does the DOH need the static json catalog? It seems to have a link in there and I'm a bit concerned this isn't going to work out.

Regards

Darren

Posted by Peter Judge on 03-Jul-2019 17:26

The GEN and MAP files are the same thing, basically; I'll call them the mapping file. GEN = "generated". If you have a GEN and a MAP file with the same name in the same (PROPATH) directory then the DOH will read the gen first and overlay the MAP contents. The GEN is intended to be changed only by PDSOE.
 
The schema section in the mapping file is not used by the catalog at all. It is used to build temp-table and/or datasets on the fly for passing into the methods in the E or other business logic.
 
Not sure what you mean by #3. The GET on the service's / was intended to replace the need for the GET /static/service.json catalog (as you can probably tell). I don't know if anyone/the JSDO is using it  so I think you could quite easily replace that GET / with your own operation.
 
 

All Replies

Posted by Peter Judge on 03-Jul-2019 14:52

The DOH does not require a catalog (or the JSDO client). The Catalog basically just describes the HTTP endpoints and payloads that are served.
 
There's doc on the DOH at docs.progress.com/.../Use-a-Data-Object-Handler.html which describes how to use it for non-Data Object Service uses.
 
There's a language issue (OCTA-3436) where the reflection methods that the DOH uses to figure out which method to call in your code cannot find TT's defined LIKE (it apparently has to do with the field and rpos ordering).
 
If you simply return temp-table data then this isn't a problem, but if you want to pass JSON data into methods that have such a temp-table, you'll have to change/update the definition.
 
There are some examples of using webhandlers at github.com/.../web_handler , include a couple for using the DOH.
 
 
 

Posted by egarcia on 03-Jul-2019 15:37

Hello Darren,

> We've played with creating our own handlers for the JSDO.

Could you provide more info on your goals?

The usage of Progress Data Services provides a prescriptive approach for working with REST services.

It can use either REST or WEB as the transport. The WEB transports corresponds to the DOH and gives you flexibility to handle HTTP requests programmatically.

In particular, you would use these services to work with the JSDO, either directly in JavaScript, Node.js or Kendo UI Builder.

If your intention is to work with the JSDO, the following dynamic service using WebHandlers could be useful:

- community.progress.com/.../2677

I hope this helps.

Posted by Darren Parr on 03-Jul-2019 16:50

Thanks. We can use a static temp-table and just map it over to the other version using buffer-copy prior to operations so we'll work with a static dataset for now. The fill and save-changes will work as expected.

We are sticking with data object services. That being said I've got some questions regarding use.

We're working in 12.0.

We have it read working OK for now with counts and JFP but not thorugh the DOH. Rather than write our own handlers, I've decided to make use of the DOH. It all fits OK as we're using data object services. We have a generated .gen file.

1. Do I need to take the .gen file and drop that into the <service>.map file or will the DOH look for the .gen file?

2. How important is the schema section of the .gen file as we need to customise the catalog generation?

3. Can I just take the default GET which returns the catalog of the file?

We need to customise the catalog a little to add some extra static configuration data for use by the client and to remove fields which the user has no right to see. There are also other tweaks to the catalog which we need.

Thanks

D

Posted by Darren Parr on 03-Jul-2019 16:52

We're using the JSDO and data object services with the web transport. We were only writing our own handlers before I discovered the existence of the DOH.

Posted by Peter Judge on 03-Jul-2019 17:26

The GEN and MAP files are the same thing, basically; I'll call them the mapping file. GEN = "generated". If you have a GEN and a MAP file with the same name in the same (PROPATH) directory then the DOH will read the gen first and overlay the MAP contents. The GEN is intended to be changed only by PDSOE.
 
The schema section in the mapping file is not used by the catalog at all. It is used to build temp-table and/or datasets on the fly for passing into the methods in the E or other business logic.
 
Not sure what you mean by #3. The GET on the service's / was intended to replace the need for the GET /static/service.json catalog (as you can probably tell). I don't know if anyone/the JSDO is using it  so I think you could quite easily replace that GET / with your own operation.
 
 

Posted by egarcia on 03-Jul-2019 19:26

The JSDO can use a static catalog or a dynamically generated catalog file.

The following sample code shows how to use WebHandlers to create a Generic Service for the JSDO. The sample only shows GET operations. However, you should be able to use the same structure to add support for other operations.

Link:

- community.progress.com/.../2677

In addition of working with dynamic code, you can also write static Business Entities to provide custom code.

I hope this helps.

Posted by egarcia on 03-Jul-2019 19:26

The JSDO can use a static catalog or a dynamically generated catalog file.

The following sample code shows how to use WebHandlers to create a Generic Service for the JSDO. The sample only shows GET operations. However, you should be able to use the same structure to add support for other operations.

Link:

- community.progress.com/.../2677

In addition of working with dynamic code, you can also write static Business Entities to provide custom code.

I hope this helps.

Posted by Darren Parr on 03-Jul-2019 22:25

[quote user="Peter Judge"]

The GEN and MAP files are the same thing, basically; I'll call them the mapping file. GEN = "generated". If you have a GEN and a MAP file with the same name in the same (PROPATH) directory then the DOH will read the gen first and overlay the MAP contents. The GEN is intended to be changed only by PDSOE.
 
The schema section in the mapping file is not used by the catalog at all. It is used to build temp-table and/or datasets on the fly for passing into the methods in the E or other business logic.
 
Not sure what you mean by #3. The GET on the service's / was intended to replace the need for the GET /static/service.json catalog (as you can probably tell). I don't know if anyone/the JSDO is using it  so I think you could quite easily replace that GET / with your own operation.
 
 [/quote]
Thanks.
When you say "overlay". What do you mean? Does the existence of the .map file supercede the .gen or is it doing some fancy matching up of the contents?
What part does the schema play in a typical interaction from the JSDO when it calls PUT which then runs the Update<table> method in the data object. We're passing a dataset to the handler from the client. Does it just pass it in as a handle without any checking to the data object or is it using its own schema defn in some way to  verify the incoming json? I guess my question is what requirement is there for the schema defn in the .gen and the catalog to remain in sync?
-D 

Posted by Darren Parr on 04-Jul-2019 14:50

I've got this working and it all seems ok. As we're using data object services, do we have to use the "pdo" extension? I'm wondering if instead of web/pdo/HelloService, we can just do /web/HelloService provided we configure the handler correctly

Posted by Ruben Dröge on 04-Jul-2019 16:54

If it's all about having a nice and clean URL, I would just use something like URL forwarding (replace/redirect) functionality of my webserver.

Posted by Darren Parr on 04-Jul-2019 17:37

[quote user="Ruben Dröge"]

If it's all about having a nice and clean URL, I would just use something like URL forwarding (replace/redirect) functionality of my webserver.

[/quote]

I know I could do that but it was more about understanding if the DOH uses whether "pdo" is in the URI to change its behaviour. 

Thanks

Darren

Posted by Peter Judge on 15-Jul-2019 17:16

You can leave it out, but you will have to change/add a new handle<n> property as appropriate.
 
handler42=OpenEdge.Web.DataObject.DataObjectHandler:/
 
 
 
If you want your own prefix, add it
 
handler43=OpenEdge.Web.DataObject.DataObjectHandler:/dp/
 
If you do that, you'll have to add some code in your session startup to tell the DOH that it should expect that prefix
               
assign OpenEdge.Web.DataObject.DataObjectHandler:HANDLER_PREFIX='dp'.
 
You don't need that code if you want an empty prefix (the DOH will try 'pdo' and nothing by default).
 
 
 
 
 

Posted by Peter Judge on 15-Jul-2019 20:35

All services, operations and schemas that are in the GEN file are loaded first, then they are replaced by any identically-named operations and schemas in the MAP file. It's a complete  replacement (not a patch/diff-applied) and not a removal, largely for simplicity..

Does that make sense?

This thread is closed