REST API, TR_DATASERVICE_TABLES and Views

I was trying to use this functionality today for a view in 12.5.1 and it appears to still not work. That's no problem, I can do what I need to do in a stored procedure but it was a little frustrating. The documentation specifies views as working so I spent about an hour trying to figure out what I was doing wrong until I found this post. No big deal, but perhaps change the documentation until it's resolved?

http://www.tessituranetwork.com/help_system_v125/content/system_tables/tr_data_service_table.htm (Table Name – The name of the table or view in the database that is being exposed by the service.)

Is there any news on this?  Just starting work on my first bit of integration using REST and was planning on using views.  It's definitely going to complicate things if I can't.

Thanks,
Sarah

To get around using views I set up stored procedures, used post to process them, and grabbed the results that way. It's actually not much more work than using a view. The setup processes are about the same and the call to REST isn't any more complicated - POST instead of GET. It all gets broken down by your json or XML the same though. I'm guessing that's why this hasn't really been fixed.

It'd be great to know that they didn't work in the first place *cough* update the documentation *cough* but I can't see any real advantage to using a view over a stored procedure in this case. 

Hi Cliff

I'm assuming your call is a POST custom/execute with a sproc id from tr_local_procedure? That's what I ended up doing.

If you've got a better way to do this I'd love to know !

Call me a purist - call me whatever for that matter - 
but I find this POST sproc 'antipattern' unnecessarily cumbersome and obscure for information retrieval.
You need to know the details of what the sproc id points to to know what the call is doing, rather than being able to describe the purpose of the call in the TR_DATASERVICE_TABLES. (eg perfinfos which would be the reference to the view (/table)
For example

GET TessituraService/Custom/perfinfos?inv_no=92242

which seems self-documenting rather than

POST TessituraService/Custom/Execute
with a POST body to include the sproc if number and parameters:
{
"Parameters": "@inv_no=92242",
"ProcedureID": 7587
}

I've got used to it, but a bit like I get used to the sound of an electric drill.

:)

Hi there! You are correct, I'm using a stored procdure with the custom post call. 

I'm probably oversimplifying but in my mind I have to make a call to the API, the API responds with results, and I use them. The processes/steps just seem so similar to me as to not really make a difference. 

Actually, now that I think of it, the view is actually more work with the same results. For the view you would need to set up every column with the TR_DATASERVICE_TABLES and then adjust them any time the requirements changed. With the stored procedure option you can change it on the fly and adjust your code to account for the new data points.

The stored proc call is a little more cumbersome but I think it may actually be more flexible especially should you you need to add or remove data points. 

Hi there! You are correct, I'm using a stored procdure with the custom post call. 

I'm probably oversimplifying but in my mind I have to make a call to the API, the API responds with results, and I use them. The processes/steps just seem so similar to me as to not really make a difference. 

Actually, now that I think of it, the view is actually more work with the same results. For the view you would need to set up every column with the TR_DATASERVICE_TABLES and then adjust them any time the requirements changed. With the stored procedure option you can change it on the fly and adjust your code to account for the new data points.

The stored proc call is a little more cumbersome but I think it may actually be more flexible especially should you you need to add or remove data points.