XML feeds with search parameters?

27314

Hi all,

XML feeds are very useful, however it is not very efficient to download the entire iSheet to find the one(or more) records that I want to display on screen.

Has anyone found a workaround to leverage search parameters in the xmls feeds,? (similar to how advanced searches work)

Thanks,

  • David Corrin as far as I am aware there is no XML parameter that will filter the feed server side. This has been requested by other clients as well so I have brought it to the attention of Natasha Miller-Santos who is responsible for the iSheets module.

  • Thanks Imran Aziz. Natasha Miller-Santos it would be great if this was included in the suggested enhancements to the XML feeds that we had previously mentioned. I am very hopeful that xml feeds v2.0 exist somewhere in the pipeline as the original implementation hasn't been improved in years.

  • Thanks David Corrin for raising this, Imran Aziz is correct - we do have this request in our backlog ref: CFR-875, however, we've prioritised improving our API's higher than the XML feeds so creating a 2.0 version has been deferred. Moving forwards we will revisit the XML strategy as I have recently had another client mention other improvements we can add, therefore making the case for a v2.0 even stronger.

  • This would be a great addition. We too struggle with needing to filter out records after getting the entire result set, or creating unique views that incorporate their own filters.

  • I agree that it will be very useful feature to make views more efficient.

  • Natasha Miller-Santos Thank you for the update. Great to see a couple more people supporting this. That's a 100% growth in interest overnight!

  • Certainly required from my perspective as well.

  • I'd like to provide some comment to this thread, given our years of using Collaborate, and the customisations we've implemented to provide advanced features beyond Collaborate's OOTB capabilities.

    Firstly, if we are talking about using the ExportXML feed from within Collaborate (Home/Wiki), then improving the XML feeds is a waste of time, given it's fundamental limitations on some column types. We went down this road back in the V3 days, whilst also going down the RenderXML route to facilitate the searching capabilities (that you are seeking).

    Once V4 came along and the iSheet API's matured, we switched to using these instead, from within Collaborate, which we use together with our GraphQL wrapper around their API's (where we can extend/improve upon).

    The better approach would be that HighQ create an API within Collaborate to allow "page developers" to easily and securely obtain an API token for the current user, and to then be able to call the Collaborate iSheet (Search) API's. The results will have none of the limitations of ExportXML, and as a bonus you now have access to all the API functionality this user can perform, i.e. folder generation, silent iSheet item status changes, etc etc.

    Andrew

  • Andrew Quinn I agree with your suggestion. I have seen in other platforms, and perhaps this is considered insecure, where the user's access token is made available on the page. For example, add it to collaborateCommon? Only the user would have access to their own token.

  • Hey Andrew Quinn, agree that could be very cool and open up an entire world of possibilities! Based on the fact though that these xml feeds haven't improved in a long time (ever?), I don't think there is necessarily a push to spend effort in improving these a lot let alone create a brand new internal offering right now(Happy to be wrong though). With HighQ improving visualisations and their own internal pipes it would be good if we were allowed to leverage these as well (and even align the data feeds to be the same if not similar as how the API feeds it back). I agree that there are better and more powerful ways of doing things but I am just looking for a decent win now that doesn't deviate too much from their current offering and as such shouldn't be a massive effort for them to implement. I would hope ExportXml v2 would address a lot of those limitations. I would excited if they implemented something like you suggested as it would open it up massively but I would like to be able to do some additional things in the meantime while waiting for that.