JSDO Filtering - Forum - Mobile - Progress Community

JSDO Filtering


JSDO Filtering

  • Hi,

    I am encountering an issue with Filtering on the JSDO. When I apply a filter on the Kendo Datasource, the Filter value is not being passed into my API. If I interogate the JSO object in the console, I can clearly see that the Filter stream is there. If I also use Fiddler2, I can see the URL also holds the filter stream. However, on the API read method, the Filter value is always empty (? value).

    I have stripped the code out and placed into a basic html script:

    $(function() {

    function createGrid() {
    // select the "grid" div with jQuery and turn it into a Kendo UI Grid
    // all Kendo UI widgets use a DataSource to specify which data to display
    dataSource: {
    type: "jsdo",
    serverFiltering: true,
    filter: [{ field: "Company", operator: "eq", value: 9996 },
    { field: "BatchID", operator: "eq", value: "GL000049" }
    transport: {
    jsdo: "NL09",
    tableRef: "eGLJournal"
    error: function(e) {
    console.log('Error: ', e);
    height: 650,
    // setting up most of the grid functionality is as easy as toggling properties on and off
    groupable: true,
    sortable: true,
    reorderable: true,
    resizable: true,
    selectable: true,
    pageable: {
    refresh: true,
    pageSizes: true,
    pageSize: 10,
    buttonCount: 5
    columns: [
    { field: 'Company', title: 'Company', width: 100 },
    { field: 'BatchID',title: 'Batch', width: 100 },
    { field: "DocumentID", title: 'Document ID', width: 100 },
    { field: "DocumentNumber", title: 'Document No', width: 100 },
    { command: ["edit"], title: "&nbsp;", width: "250px" }


    Fiddler2 Result after running:

    The API Read Method:

    @openapi.openedge.export(type="REST", useReturnValue="false", writeDataSetBeforeImage="true").
    @progress.service.resourceMapping(type="REST", operation="read", URI="?filter=~{filter~}", alias="", mediaType="application/json").
    @openapi.openedge.method.property (name="mappingType", value="JFP").
    @openapi.openedge.method.property (name="capabilities", value="ablFilter,top,skip,id,orderBy").
    LOG-MANAGER:WRITE-MESSAGE ("Fetch GL Batch Journals Filter: " + STRING(filter), "NL09").


    As can be seen from the above section of code, I am outputting details to a log file. The contents of the log file always read as:

    [16/04/19@10:14:00.853+0100] P-010928 T-008984 1 AS-7 NL09 ReadNL09
    [16/04/19@10:14:00.853+0100] P-010928 T-008984 1 AS-7 NL09 ?

    Has anyone come across this before? 

    I can get around the issue by using an Invoke Method and passing in a JSON Object with the filtering values, but ideally I would prefer to use the proper read method passing in the Filter Values.


  • Forgot to add to the original post:

    If I use a straight forward URL request:

    .......NL09?filter={"ablFilter":"Company = 9996 and BatchID = 'GL000049'"}

    then my API Read filter variable contains the above values....

  • Hi,

    I tried with the following code, its work for me.

    I removed the serverFiltering: true, and specified the filter condition.

           $(document).ready(function () {

    function createGrid() {


                   dataSource: {

                       type: "jsdo",

                       transport: {

                           jsdo: "CartBE"


    filter: { field: "CUSTID", operator: "eq", value: "k1"},    

                       error: function(e) {}


                   reorderable: true,

                   resizable: true,

                   sortable: true,

                   editable: 'inline',

                   columns: [

                                         { field: 'NAME', width: '100px' },

                                           { field: 'TYPE', width: '100px' },

    { field: 'QUANTITY', width: '100px' },

                       { command: ['edit', 'destroy'], title: ' ', width: '200px' }



  • Hi,

    Yes tried that before and it does work on the Basic Script - but the filter field value still comes out in the log file as '?'.

    If I reinstate my original code (using a structured AngularJS service) then the filtering does not work.

    The filterObject would be:

    var objFilter = [{ field: "Company", operator: "eq", value: 9996 },

    { field: "BatchID", operator: "eq", value: e.BatchID }


    and the Process Method:

    this.getJSDOFilterData = function (resourceName, resourceTable, resourceFilter) {

    var deferred = $q.defer();

    var dataDS;


    dataDS = new kendo.data.DataSource({

    type: "jsdo",

    //serverPaging: true,

    serverFiltering: true,

    //serverSorting: true,

    pageSize: 20,

                //filter: resourceFilter,

    filter: { field: "Company", operator: "eq", value: 9996 },

    transport: {

    jsdo: resourceName,

    tableRef: resourceTable,

    countFnName: "count"


    requestEnd: function (e) {




    error: function (e) {

    console.log('Error: ', e);





    return deferred.promise;


    Notice that for simplicity, I have hard coded a 'filter' value and also note that It's using a Kendo DataSource. Regardless of whether I comment out the serverFiltering, the filtering does not work as mentioned previously.

  • One thing that seemed unusual was the Fiddler screenshot.

    Can you check Fiddler for the working use case (when you try from the browser) and compare the two?

    I was surprised to see that the "filter=" was on the JSESSIONID line separated by a colon. I expected it in its own queryString parameter line.

    I am not sure why that is happening

  • Hello,

    The screenshot that you included shows that the value of JSESSIONID has the text for the filter.

    Notice that the string has ";" instead of "&" to separate the values.

    This makes the two parts be the value for JSESSIONID, instead of recognizing filter as a separate parameter.

    I believe that there is a bug logged.

    Is your intention to have JSESSIONID in the URL?

    (I am guessing you might be doing this to share the session for AJAX calls but I am not sure.)

    The issue with the filter does not occur if JSESSIONID is passed as an HTTP only cookie which is the default.

    Please let us know how this impact you. Perhaps, you would be ok using a custom version of the library with a fix.

    I hope this helps.

    P.S; For those looking for an example:

       oemobiledemo.progress.com/.../example014b.html shows the usage of the filter option.

  • Hi,

    I'm also surprised to see the 'filter' on the JSESSIONID.

    I have cleared my cache and re run a couple of tests.

    here are screen shots of the results within Fiddler2




    I'm using Form Authentication (using JSDO) and within my AngularJS config area I have 

    $httpProvider.defaults.withCredentials = true;

    I have not generated any code to manipulate the URL and certainly not appended the filter.

    It is not my intention to have the JSESSIONID in the URL and have not implemented it in code (maybe because of the withCredentials)!!!!

    As far as I am aware, I am using the default behaviour of the JSDO.

    I have no issues with using a custom version of the library (if I knew what to change)Smile

    I have run through debugging and not really seen any clues as to why the filter is ? when hitting my API.

    Hopefully I've answer the above and made sense....

    By the way, I'm still using JSDO 4.2.0.

  • HI Martyn, this is our fix to a similar issue:


    Not sure, if Progress is going to fix the bug that Edsel mentioned in a similar way.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Hi Mike,


    I'll apply the change and see how it goes.

    Looking like there are going to be multiple versions of the JSDO!!! I found an issue earlier with filter values holding a single quote.

  • Yes, that issue came up on Friday. There is a workaround in our repo for that as well. Just check the most recent version.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Thank you for the feedback.

    It is not my intention to have the JSESSIONID in the URL and have not implemented it in code (maybe because of the withCredentials)!!!!

    The JSESSIONID is generally handled as an HTTP only cookie. It is handled internally by the web browser and it is not available in JavaScript. You would be able to see it with Fiddler2 since it looks at the network traffic.

    The JSESSIONID would be used in the URL if cookies are disabled on the web browser or if the configuration for Tomcat is so that http-only is false.

    Please check the settings for cookies in your web browser (interestingly one of the screenshot showed two JSESSIONID cookie).

    Also, check the setting for  <session-config> in web.xml - it should have <http-only>true</http-only>.

    This setting is the default ... I would expect it to be used even if it is commented out.

    FYI, version 4.2.0 is the latest version of the JSDO.

    BTW, the fix that Mike mentioned is the same fix that would be in the custom version that I mentioned.

    The issue is that the code is adding ";" when it should use "&".

    I hope this helps.

  • Hi Ed,

    About to run some tests using Mike's fix :)

    I'll check those settings that you mentioned.

    Shall update once I've ran a few tests....

    Thanks for all the speedy responses....

  • Hi Mike and Ed,

    Just completed running several tests. That fix works like a charm (including filters with a single quote).

    Once again, many thanks.

  • Regarding the question about why the JSESSIONID is present at all in the URL: in addition to the reasons Edsel mentioned, one possibility is that the Web application is configured to send an X-CLIENT-CONTEXT-ID header in responses (you do this in the oeablSecurity---.xml or appSecurity---.xml file by setting the OEClientPrincipalFilter's ccid property to true). When that happens, the JSDO session management code adds the X-CLIENT-CONTEXT-ID header to future requests, AND adds the value as JSESSIONID to the URL, but doesn't do it correctly. As Edsel said, there is a bug logged and it is scheduled to be fixed.