DataObjectHandler with JSDO - Forum - OpenEdge Development - Progress Community
 Forum

DataObjectHandler with JSDO

This question is answered

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

Verified Answer
  • 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
  • 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.
     
     
     
  • 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.

  • 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

  • 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.

  • 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.
     
     
  • 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.

  • 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.

  • 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.
     
     

    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 
  • 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

  • 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.

  • 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.

    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

  • 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).
     
     
     
     
     
  • 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?