REST API, TR_DATASERVICE_TABLES and Views

As of last November my understanding was that support for views through DataService was not yet enabled. That's about all I know about it though--hopefully somebody will be able to illuminate a little bit further, as I'm interested to know, too. 

We will be adding support for Views, although not sure at this point whether it will be in v12.0 or in v12.5

Thanks for the update, Chuck!

Hi

I get 

"Description": "Table 'LV_SC_APIS_EVENT_ARTIFAX_MATCH' was not found in schema 'dbo'.",

And I can see the view under the dbo schema

The v12.5 documentation says "The TR_DATA_SERVICE_TABLES table (added v11) is used to register custom tables and views as resources for the DataService service of the REST API."

Can anyone confirm or deny :) whether views should be acccessible in v12.5 ?

Thanks

Aryaguna

The service does not support views. This is likely a bug in the documentation.

-Sam

Hi Sam,

A documentation bug perhaps, but also a REST API bug?  I'm confident that 99.999% of all custom data that people are going to want to expose via the REST API will be views.

--Gawain

[duplicate]

Hi Gawain, thanks for the update! I will let the team know.

-Sam

Thanks Gawain, Samuel

I think a read-only views custom data feature would be extremely helpful to folks.

Having read-write is fraught with difficuties to make into a general case, but what about something like, this?

Specified in a separate table

TR_DATASERVICE_VIEWS

without the next_id... and probably regeistered_with... and subentites columns

I'd think that could be based around the exisiting code for TABLES fairly easily and be a great feature

But thanks for clarifying that it's not ready just yet :)

Aryaguna

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.