Rally Software

 View Only
  • 1.  Viewing errors from WSAPI calls in the SDK

    Posted Sep 10, 2018 11:58 AM

    Related to my other posting on getting errors when having too big of a filter, I'm now getting an error that wasn't early (and there was no code change).  However, I have no visibility to what the error is, I just get success=false.

     

    Ext.create('Rally.data.wsapi.artifact.Store', {
    models: ['PortfolioItem/Capability'],
    autoLoad: true,
    pageSize: 10000,
    filters: [
    //{ property: 'Children', operator: 'containsany', value: capabilities }
    { property: 'DirectChildrenCount', operator: '>', value: '0' },
    { property: 'Parent', operator: '!=', value: null },
    { property: 'Parent.PreliminaryEstimateValue', operator: '>=', value: '0'}
    ],
    fetch: ['FormattedID', 'Name', 'PreliminaryEstimate', 'Children', 'PlannedStartDate', 'PlannedEndDate',
    'PreliminaryEstimateValue', 'Project', 'Parent', 'Tags', 'Tag'],
    hydrate: ['Project', 'Tag', 'Parent', 'Children'], 
    sorters: [{ property: 'FormattedID', direction: 'ASC' }],
    listeners: {
    scope: this,
    load: function (store, capabilities, success, eOpts) {
    console.log('We got capabilities back - Woohoo!');
    deferred.resolve([releases, features, capability_hash, capabilities, initiative_hash]);
    }
    }
    });

     

    Did I ask for too big of a page size?  How do I see errors that come back from this?



  • 2.  Re: Viewing errors from WSAPI calls in the SDK
    Best Answer

    Broadcom Employee
    Posted Sep 10, 2018 05:02 PM

    Hi Sheridan,

     

    The store load function indeed returns the success code. However (and also as related to what Kyle mentioned in the previous thread), we can't guess if the problem is the result size. It could be.

     

    My advise to you are two-fold:

    1. Simplify your code, start with a filter that has just one result, then a few, and then scale it up with every attempt until you get to your original filter. It will give you a sense if the code is okay at all, if even few results can work or if you have issues that are other than the result size.

     

    2. Side-by-Side with your app building, you may want to use tools such as Postman and issue the WSAPI query with this filter to see the result. The WSAPI is underneath the SDK and if you will find it's not working with WSAPI then it may be a data issue. So, in other words, you may want to try to figure out if the issue is with the SDK itself or with the data returned by the query.

     

    So, I'll use a combination of both these methods to try to isolate this. I hope this helps.

     

    Sagi



  • 3.  Re: Viewing errors from WSAPI calls in the SDK

    Posted Sep 10, 2018 11:53 PM

    The frustrating part is that the query worked fine and suddenly didn’t… without any code change.  Other queries worked fine – just this one returned errors.  I know the .NET/Java toolkits give you some messages in the payload you can work with and thought it would be the same in the app SDK.



  • 4.  Re: Viewing errors from WSAPI calls in the SDK

    Posted Sep 11, 2018 12:27 AM

    After several tries – I narrowed it down to the Project fetch.  Weird that it would just stop working.



  • 5.  Re: Viewing errors from WSAPI calls in the SDK

    Broadcom Employee
    Posted Sep 12, 2018 12:10 PM

    Hi Sheridan,

    Thanks for letting us know you figured out the Project fetch caused the problem. Did you make progress since then? Is this working at this point? Shall we mark this thread as 'answered'?

     

    Sagi