cancel
Showing results for 
Search instead for 
Did you mean: 

REST API Query Results

ybxdde
Star Contributor
Star Contributor

Can header (name of field) be added to results, in addition to index value?  Not sure why the actual field name isn't being returned.  

 

/ApiServer/onbase/core/documents/queries/{querty}/results - getting results of a built query
"displayColumns": [
{
"index": "0",
"values": [
"753476125X"
]
},

 

 

/ApiServer/onbase/core/documents/queries/{querty}/columns - retrieving the column definitions of a built query - this call has issues and fails 8 times out of 10, I cannot depend on this endpoint due to it's issues (I've heard it has a fix coming in EP5, but that doesn't help me now)
"items": [
{
"dataType": "Alphanumeric",
"heading": "ProNo",
"index": "0",
"keywordTypeId": "102",
"type": "Keyword"
},

 

Thanks, Diane

2 ACCEPTED ANSWERS

Justin_Carlson
Employee
Employee

Hi Diane, 

Thanks for the suggestion, unfortunately there is no way to add that piece of data into the results end point currently.  One of the reasons that heading, dataType, keywordTypeId, type, etc are not included currently was because if you have a large result set, having that information repeated with each result item will increase the response size quite a bit. For example, just including

"heading": "ProNo"

1000 times (if you had 1000 documents returned) came out to be about 18-20KB of text, so we are trying to limit the data returned with teach item.

 

We can certainly take this request and information into consideration going forward as we look to improve query execution.

 

Regarding the issues you are having with /ApiServer/onbase/core/documents/queries/{querty}/columns failing 8 out of 10 times, could you elaborate there (or are you already working with support)?

 

We are aware that this end point will take some time to execute (because currently it is re-executing the entire query on the server, even if you already got the results). But we don't expect it should be failing 80% of the time. It should be similar in execution (in time to execute, and success rate) with the results end point.

 

Thanks

View answer in original post

ybxdde
Star Contributor
Star Contributor

Would like to re-comment that it'd be nice to have an optional parm where the results could look something like this, where the 'heading' replaces 'index'.  With it being optional, those that are working with large responses could continue getting the index values rather than the keyword name values.

 

/ApiServer/onbase/core/documents/queries/{querty}/results - getting results of a built query
"displayColumns": [
{
"heading": "ProNo",
"values": [
"753476125X"
]
},

View answer in original post

3 REPLIES 3

Justin_Carlson
Employee
Employee

Hi Diane, 

Thanks for the suggestion, unfortunately there is no way to add that piece of data into the results end point currently.  One of the reasons that heading, dataType, keywordTypeId, type, etc are not included currently was because if you have a large result set, having that information repeated with each result item will increase the response size quite a bit. For example, just including

"heading": "ProNo"

1000 times (if you had 1000 documents returned) came out to be about 18-20KB of text, so we are trying to limit the data returned with teach item.

 

We can certainly take this request and information into consideration going forward as we look to improve query execution.

 

Regarding the issues you are having with /ApiServer/onbase/core/documents/queries/{querty}/columns failing 8 out of 10 times, could you elaborate there (or are you already working with support)?

 

We are aware that this end point will take some time to execute (because currently it is re-executing the entire query on the server, even if you already got the results). But we don't expect it should be failing 80% of the time. It should be similar in execution (in time to execute, and success rate) with the results end point.

 

Thanks

Yes I can see if you're doing a large query you wouldn't want the response size to be added to, however it'd be nice to have an optional parm we could pass that would return that information if desired.  I'm already having to make 3 endpoint calls just to do a simple query, now I have to add to that just to get the field names?  I'd much prefer a larger response than have to make a 4th endpoint call just so I can map the result fields based on their name vs hoping I have the right index/field matched properly.

 

Actually, if you could provide an optional parm that returned the field name instead of the index, that'd be great and save on response size too.  Not sure why you didn't do that to begin with, do people really want to know the index of the field being returned in the response?

 

I'm trying to covert a Java API wrapper that was written in-house to now use these REST APIs and be able to perform a multitude of types of queries that the applications request.  When trying to map the results back to them its next to impossible to standardize that index 0 is fieldX for example and having to make another call just to get that info which for now isn't dependable beings it fails so frequently (someone told me you guys already have a planned fix for it in EP5).

 

Thanks and look forward to future enhancements!  Diane

 

 

ybxdde
Star Contributor
Star Contributor

Would like to re-comment that it'd be nice to have an optional parm where the results could look something like this, where the 'heading' replaces 'index'.  With it being optional, those that are working with large responses could continue getting the index values rather than the keyword name values.

 

/ApiServer/onbase/core/documents/queries/{querty}/results - getting results of a built query
"displayColumns": [
{
"heading": "ProNo",
"values": [
"753476125X"
]
},