JSDO not working as advertised - Forum - OpenEdge Development - Progress Community
 Forum

JSDO not working as advertised

This question is answered

I'm experimenting with using the JSDO to communicate with a business entity I've setup on my PASOE instance.  I'm not using any sort of fancy frameworks - just plain old HTML with the JSDO included as JavaScript. The business entity is based on a single table.  It's not customized at all - just what gets automatically generated with the wizard in 11.7.4.

In doing so, I'm seeing that the actual behavior of the JSDO doesn't square up with the documentation.

For instance, the documentation says you can do a fill() and then access the resulting data by accessing the temp-table name as a property of the jsdo object.

For example, if your jsdo reference were myJSDO, and the temp-table is ttWebUser, then the docs say you can access myJSDO.ttWebUser.foreach().

I'm getting data back from my BE, but the jsdo object doesn't have a ttWebUser property. 

Question 1:  Is there any special trick to getting the jsdo to put the data into a property named like your temp table?

The jsdo object does have a foreach property, but it doesn't come back with a single table record for each iteration.  Instead it returns a "JSRecord" object that then has a "data" property, which then has my dataset in it, and my dataset has my temp-table and its data.  It has the whole thing.  On each iteration.  If I console.log() the record that comes into the foreach function, it's showing this:

Question 2: What in the world is going on here?  Why would a foreach return the entire dataset?  Why would the resulting JSRecord object not have fields defined in it like the documentation says it does?


Does anyone have a really simple example of using a jsdo with plain old JavaScript to access a BE's methods?  Maybe a tutorial out there that doesn't involve mobile development or Kendo?

Verified Answer
  • After some discussion with Edsel, I was able to get past this problem.

    Looking at my .json catalog file, the Business Entity did not have a schema listed.  The element highlighted below was not there:

    Edsel asked me to look at the top of my BE's .cls file at this annotation:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").

    Even though it's in my propath, adding the full relative path within my project was needed:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").

    Once I fixed that and edited my defined service that included this BE. (Just open and save - no changes needed) It began to correctly include "schema" in the catalog, and a fill() call resulted in the jsdo object having a ttWebUser property that I can access.

    Best I can tell, this problem must have happened when I moved my BE from the "appserver" directory to the "openedge" directory in my PAS project.

    One problem down.  Thanks Edsel!

  • The problem turned out to be that my service catalog, the .json file, did not have a "schema" section in it for my BE.

    In my BE, at the top of the file, my annotation looked like this:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").

    But it needed to look like this:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").

    Once I fixed it and then opened and saved the service definition, it deployed a new catalog that included the "schema" element:

    Once that was in place, the JSDO began to act correctly as documented.

    Thanks Edsel!

All Replies
  • Hello,

    > Question 1:  Is there any special trick to getting the jsdo to put the data into a property named like your temp

    > table?

    No, there is no special trick. It should work just fine with BEs and catalog files generated with PDSOE.

    The BEs use a prescriptive approach.

    > Question 2: What in the world is going on here?  Why would a foreach return the entire dataset?  Why would

    > the resulting JSRecord object not have fields defined in it like the documentation says it does?

    Could you share the signature of your READ method and the corresponding catalog .json file?

    What version of the JSDO are you using?

    Where are you downloading the JSDO from?

    Are you downloading it from npm ( www.npmjs.com/.../jsdo-core )?

    Older versions of the JSDO used jQuery Promises and the promises used a signature like this "(jsdo, success, request)".

    Recent version of the JSDO use JS (ES6) Promises and the promises use (object) as the signature.

    (The new version has a mode that allows usage of jQuery Promises if desired.)

    > Does anyone have a really simple example of using a jsdo with plain old JavaScript to access a BE's

    > methods?  Maybe a tutorial out there that doesn't involve mobile development or Kendo?

    Here are some examples:

    - oemobiledemo.progress.com/.../example001.html (JavaScript Promises)

    - oemobiledemo.progress.com/.../example013.html (jQuery Promises)

    The wiki in GitHub also has an example:

    - github.com/.../Using-the-JSDO-component-with-plain-HTML-and-JavaScript

    I hope this helps.

  • After some discussion with Edsel, I was able to get past this problem.

    Looking at my .json catalog file, the Business Entity did not have a schema listed.  The element highlighted below was not there:

    Edsel asked me to look at the top of my BE's .cls file at this annotation:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").

    Even though it's in my propath, adding the full relative path within my project was needed:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").

    Once I fixed that and edited my defined service that included this BE. (Just open and save - no changes needed) It began to correctly include "schema" in the catalog, and a fill() call resulted in the jsdo object having a ttWebUser property that I can access.

    Best I can tell, this problem must have happened when I moved my BE from the "appserver" directory to the "openedge" directory in my PAS project.

    One problem down.  Thanks Edsel!

  • The problem turned out to be that my service catalog, the .json file, did not have a "schema" section in it for my BE.

    In my BE, at the top of the file, my annotation looked like this:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="bewebuser.i").

    But it needed to look like this:

    @progress.service.resource FILE(name="BEWebUser", URI="/BEWebUser", schemaName="dsWebUser", schemaFile="Ingrid/PASOEContent/WEB-INF/openedge/bewebuser.i").

    Once I fixed it and then opened and saved the service definition, it deployed a new catalog that included the "schema" element:

    Once that was in place, the JSDO began to act correctly as documented.

    Thanks Edsel!

  • The "not respecting PROPATH for schema" issue is a  feature we expect to ship in the next 12.x release. Its (intenral) id is OPENEDGE-1115 (File holding the schema should be searched in PROPATH).
     
    You (in the y'all sense) can provide feedback on this and other features in the CVP forums.
     
  • Peter, what's a "CVP forum"?

  • The Customer Validation Program has a number of forums (for various components/features).  An intro to the CVP is at community.progress.com/.../38559
     
  • And if you've not joined, that post reads
     
    Congratulations!
    If you are reading this you joined our Customer Validation Program and may be wondering what exactly is this all about.
    The OpenEdge product team is looking for more opportunities to interact with our partners and customers to help develop better understanding of their needs, use cases and priorities. We want to build products that drive value and can be quickly and confidently adopted.
    Our product development is organized into multiple scrum teams, each led by a Product Owner, and our development activities are arranged into quarterly Program Increments. As we make incremental progress towards future releases you can expect to hear from Product Owners, Product Managers, Architects, User Experience Designers and others in Engineering. We will share with you what we are working on, ask you for your feedback, offer surveys, invitations for live demos, and more. We will also post content in this group and give you the opportunity to test our prototypes, preview versions of products, and provide immediate feedback.
    On behalf of Progress OpenEdge organization I am excited to welcome you to CVP and I hope it will be fun and beneficial to all of us.
     
    Oleg Kupershmidt
    Director of Product Management
     
    P.S. Please keep in mind that everything you will see and hear as a member of Progress OpenEdge CVP is subject to terms which you accepted, including non-disclosure. If at any time you wish to review these terms, the link to them is posted on the right hand side on the home page.