JSDO: passing additional information on add/update

Posted by Akioma on 06-Jul-2015 00:49

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?

Thanks,
Mike 

All Replies

Posted by Mike Fechner on 06-Jul-2015 01:03

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.

 

Posted by Peter van Dam on 06-Jul-2015 03:26

Hi Mike Liewehr,

Check out the following thread:

community.progress.com/.../67353.aspx

-peter

Posted by agent_008_nl on 06-Jul-2015 04:14

Group Not Found

The requested Group cannot be found.

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

Posted by Akioma on 06-Jul-2015 04:55

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

Posted by Akioma on 06-Jul-2015 05:01

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?

Posted by Akioma on 06-Jul-2015 05:05

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...?!? :-)

Posted by Mike Fechner on 06-Jul-2015 05:08

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.

Posted by egarcia on 06-Jul-2015 05:47

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.

Posted by Peter van Dam on 06-Jul-2015 05:52

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.

-peter

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.

-peter

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?

Thanks

-Shelley

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!

-peter

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.

Thanks

-Shelley

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?

Thanks,

-peter

Posted by egarcia on 06-Jul-2015 06:11

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.

Thanks.

Posted by Shelley Chase on 06-Jul-2015 07:40

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?

Thanks

-Shelley

Posted by Akioma on 08-Jul-2015 11:57

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?

Thanks,

Mike

Posted by egarcia on 08-Jul-2015 13:26

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:

Access-Control-Allow-Headers=X-CLIENT-PROPS

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.

Thanks.

Posted by Akioma on 08-Jul-2015 15:12

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:

<filter-name>CorsFilter</filter-name>

<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>

<init-param>

 <param-name>cors.allowed.origins</param-name>

 <param-value>*</param-value>

</init-param>

<init-param>

 <param-name>cors.allowed.methods</param-name>

 <param-value>GET,POST,HEAD,OPTIONS,PUT</param-value>

</init-param>

<init-param>

 <param-name>cors.allowed.headers</param-name>

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

</init-param>

<init-param>

 <param-name>cors.exposed.headers</param-name>

 <param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials</param-value>

</init-param>

<init-param>

 <param-name>cors.support.credentials</param-name>

 <param-value>true</param-value>

</init-param>

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!

Mike

Posted by Michael Jacobs on 08-Jul-2015 15:28

You are reading the wrong documentation.  The CORS filter used in the rest service is not from Tomcat.

When changing the allowed headers property you have to input the full list of header names, including the defaults OpenEdge supplies for you.  You may also use a shortcut to append header names to the built in set by using a plus-sign (+) as the first character.  

Example: "+X-NEW-HEADER"

Mike J.



On Jul 8, 2015, at 4:13 PM, Akioma <bounce-Akioma@community.progress.com> wrote:

Reply by Akioma

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:

<filter-name>CorsFilter</filter-name>

<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>

<init-param>

 <param-name>cors.allowed.origins</param-name>

 <param-value>*</param-value>

</init-param>

<init-param>

 <param-name>cors.allowed.methods</param-name>

 <param-value>GET,POST,HEAD,OPTIONS,PUT</param-value>

</init-param>

<init-param>

 <param-name>cors.allowed.headers</param-name>

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

</init-param>

<init-param>

 <param-name>cors.exposed.headers</param-name>

 <param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials</param-value>

</init-param>

<init-param>

 <param-name>cors.support.credentials</param-name>

 <param-value>true</param-value>

</init-param>

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!

Mike

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by Akioma on 09-Jul-2015 05:15

Hi Mike,

when you say I am reading the wrong documentation, where do I find the right one..? :-)

Tried all kind of settings now, but with no success. :-(

Posted by Michael Jacobs on 09-Jul-2015 08:06

Good question.   After spending some time attempting to find such information in the OpenEdge documentation, I could not find it.   ( Perhaps someone else in the forum has and I just missed it )   In the meantime, I'm going to pass along a .pdf file with information about CORS, the support OpenEdge supplies, and configuration properties.  It is pretty raw information, but I hope it will help.
Mike J.

 
[collapse]
From: Akioma <bounce-Akioma@community.progress.com>
Reply-To: "TU.Mobile@community.progress.com" <TU.Mobile@community.progress.com>
Date: Thursday, July 9, 2015 at 6:15 AM
To: "TU.Mobile@community.progress.com" <TU.Mobile@community.progress.com>
Subject: RE: [Technical Users - Mobile] JSDO: passing additional information on add/update
Reply by Akioma

Hi Mike,

when you say I am reading the wrong documentation, where do I find the right one..? :-)

Tried all kind of settings now, but with no success. :-(

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Peter van Dam on 09-Jul-2015 08:27

LOL!

Do you have a similar document on IHybridRealm?

-peter

Posted by Akioma on 10-Jul-2015 02:56

Yep! Despite the version number of 0.1 the document helped a lot... :-)

With these properties in the OECORSFilter it is working for me:

<b:property name="messageHeaders" value="Accept,Accept-Language,Content-Language,Content-Type,X-CLIENT-CONTEXT-ID,Origin,Access-Control-Request-Headers,Access-Control-Request-Method,Pragma,Cache-control,X-CLIENT-PROPS" />

<b:property name="responseHeaders" value="Cache-Control,Content-Language,Content-Type,Expires,Last-Modified,X-CLIENT-CONTEXT-ID,Pragma,X-CLIENT-PROPS" />

Thanks,

Mike

Posted by Peter van Dam on 10-Jul-2015 03:17

Hi Mike,

We found that the following works as well:

            <b:property name="messageHeaders" value="+X-CLIENT-PROPS" />

            <b:property name="responseHeaders" value="+X-CLIENT-PROPS" />

That way you only have to specify what you want to add. Is a lot cleaner.

-peter

Posted by Michael Jacobs on 10-Jul-2015 04:32

Peter,

I found documentation while looking for something else.   This is in the 11.5 documentation set, OpenEdge Application Server: Administration.    Section VI for REST Administration covers both the CORS filter and has subsections for the OERealm feature support ( including IHybridRealm).  

This 2015 PUG Challenge presentation will go into more details and depth for the OERealm development:  210_OE_Realm_Auth_Process.pptx

- Mike J.

Posted by Peter van Dam on 10-Jul-2015 04:43

Hi Mike,

Thank you this already sheds a bit more light. We already studied the PUG presentation but it is only an example, like the OEBPM example in the official docs. But I missed this piece of documentation (because you don't find it if you search on Ihybridrealm, you must search on hybridrealm).

I will study this.

Thanks,

-peter

This thread is closed