JSDO: passing additional information on add/update - Forum - Mobile - Progress Community

JSDO: passing additional information on add/update


JSDO: passing additional information on add/update

  • Hi,

    when doing a read operation on a BusinessEntity using the JSDO we can pass in any kind of parameters through the Filter parameter. 

    How can we achieve similar for the update/create operations?

    E.g. when doing a create of records in a treeview UI, there are some additional informations required which are not part of the actual dataset fields: e.g. the parent of the newly created record, should it be added as a child or as a sibling and so on. There are lots of similar usecases where the BusinessEntity needs additional information from the UI for create/update operations.

    In general I am wondering why those interfaces have been defined so limited. Having at least 1 char parameter like in the read would allow for much more flexibility...

    another question: is there a way to define some generic information in the JSDO which will be passed to the server with each request?

    If we would have to add that on or own where would be the best way to do it? ideally in a way sothat we are suited for upcoming enhancements of the JSDO?


  • The universal way to pass (additional) information especially for add to the backend are calculated fields.
    The frontend is typically the only party knowing such context data. But the frontend should not need to distinguish between what’s in your eyes payload and what is control data.
    So you can add calculated fields to those tables  – and handle them on the backend.


    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Hi Mike Liewehr,

    Check out the following thread:



  • Group Not Found

    The requested Group cannot be found.

    - See more at: community.progress.com/.../default.aspx

  • I cannot access those links, I always get a "Group not found" (even when logged in)

  • Mike,

    for certain use cases you are right, but there are definitely others where calculated fields are not the correct way.

    E.g. adding 5 rows in a tree structure, you would specify the parent/relation info only once, as part of the add() operation. There is no need to pass that as a field for each new row.

    In fact, if you would create an object model for a tree with an add method you would sure make the interface look something like this:

    add(parentId, SiblingOrChild, NodeData)

    wouldn't you?

  • after looking at the link I see there is a jsdo-esap group mentioned.

    How can I become a member of that group?

    And given the fact that the JSDO is openSource, why is there a private group anyway...?!? :-)

  • But that API is a client side API. The JSDO carries new rows to the backend. And nothing else. The parent record/node ID should be a field in the temp-table of new rows to be send to the server. I see your point about potential data redundancy. But that’s a price I take in this case for a clean interface.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Hello,

    When working with a DataSet with relationships, the JSDO by default will use the relationship for the add() API (and also for getData()).

    If you are using Submit, (saveChanges(true)), the changes are sent to the server using one request using the JSON before-image format. Your Business Entity can use the values in the relationship (by default) or if needed add ABL code to walk through the records and do additional processsing.

    Regarding the JSDO ESAP link. It points to a discussion to a generic way to send data to the server.

    (You can join by emailing early-software-admin@ progress.com and requesting access to "JSDO ESAP".)

    This group was created prior to the JSDO becoming Open Source. Perhaps, we need a new group for the Open Source development.

    Even though an ESAP is not active, there are there are still some conversations happening there.

    I hope this helps.

  • Hi guys,

    I was not aware that the other forum was closed. Here is a digest of the information discussed there.

    Note: the following works only with REST, not with a Mobile service.


    Hi Shelley,

    We have the need to pass context information from the client to the server and vice versa.

    We have been struggling for quite a while for this in combination with the JSDO (using Rest) and have not been able to come up with a clean solution so far.

    Ideally we would like to have Get/Set/DeleteContextProperty in the JSDO and have the plumbing take care of passing it to the server (where it can be accessed of course) and back to the client when needed.

    Is there a facility or proven pattern for this? How to others do this? Are we the only one with this requirement?

    And Mike, how have you solved your paging issue in the meantime? For paging it can be solved because that only needs to be implemented for GET, but our requirement is for all methods.


    Hi Peter,

    For the JSDO Session there is a property called xClientProps which was used internally for Rollbase. Coincidentally, we are looking at extending this so you can define your own set of name-value pairs and you can mark which ones to use during connection and which to put in the header on every request.

    The server and client can do anything they want with that information.

    Do you think this would meet your needs?



    Hi Shelley,

    We have done some experiments and we have found that we can already make use of xClientProps.

    At the moment we have created our own Property object with our own get/set/deleteProperty methods and are assigning that object to xClientProps and found that the JSDO properly takes care of passing that information in the header with every request.

    Upon returning from the server, however, progress.data.Session.xClientProps is NOT updated automatically with the corresponding value in the response header. We can work around that by subscribing to the after events but it would be better if the JSDO framework did that for us as well. Is that something you are looking at?

    Other than that we are quite happy with this mechanism as it is now!

    Thanks a lot for this helped us solve our issue already!


    Hi Peter,

    Yes, we areplanning to add the behavior that xClientProps being returned from the server would be automatically updated in the JSDO Session on the client.



    Hi Shelly,

    Here an additional note on this subject.

    We are switching from progress.data.session to progress.data.JSDOSession (using the latest JSDO 4.0.0-12 from gitHub) and found that the latter is almost equal to the first (except of course for the implementation of jQuery Promises) except that it does not seem to handle xClientProps at all at this time. (When we set the xClientProps property of the JSDOSession object, progress.jsdo does not create X-CLIENT-PROPS in the header with that value because it only does it for Session.xClientProps.)

    So for now we will try to add our own xClientProps handling in the way we expect you to implement it in the near future.

    Is that a good idea? Do you have any timings for the implementation of xClientProps in progress.data.JSDOSession?



  • Hello,

    Here is some information on the xClientProps.

    The xClientProps property is available for the Session object and is currently not documented. (It is used internally for Rollbase.)

    The xClientProps property is not available to the JSDOSession.

    We are planning to add new APIs to handle this type of context information and make it available to the JSDOSession.


  • All comments on the JSDO is expected to be in GitHub so people outside of OE could see them.

    Does you all believe there a reason to have a Progress only forum?



  • Hi,

    after setting the xClientProps on the session I get an Error:

    No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.akiomacloud.de' is therefore not allowed access. The response had HTTP status code 403.

    if I do not set the xClientProps everything works fine with exactly the same settings.

    In the spring settings I have set OECORS to "allowAll=true".

    Is there anything else I need to set?



  • Hello Mike,

    The server needs to return an "Access-Control-Allow-Headers" containing "X-CLIENT-PROPS" to accept the new header.

    Something like the following:


    Looking at the options for the OECORSFilter, it seems that you could use the responseHeaders option to send a response header back.

    Please give this options a try.


  • Hi Edsel,

    thanks for the info. I played around with the options but only get errors on tomcat startup.

    Is there some documentation available about the settings?

    My problem is, if I read through tomcat documentation it seems as the property names in OE have slightly different names. E.g. I found the following recommended settings:













     <param-value>Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers, Last-Modified</param-value>










    but cannot really match that to the OE properties:

                <b:property name="allowAll" value="false" />

                <b:property name="allowDomains" value="http://studio.progress.com,http://mobile.progress.com" />

                <b:property name="allowDomains" value="*" />

                <b:property name="allowSubdomains" value="false" />

                <b:property name="allowMethods" value="" />

                <b:property name="messageHeaders" value="" />

                <b:property name="responseHeaders" value="" />

                <b:property name="supportCredentials" value="true" />

                <b:property name="maxAge" value="-1" />

    Any help greatly appreciated!