Each Response Table should have a Timestamp column, to allow for removing outdated responses.Įssentially, every Response Table will resemble the following:.The table should have an INDEX on the Response ID column to allow for efficient filtering.This can even be true across Response Tables, if there are multiple Web Services called at a time. Multiple rows of data for each Response should all have the same Response ID. Each Response Table needs a Response ID column to store a unique, non-sequential ID per response.If you need to combine together several Web Service responses together for effective analysis, you can either do that in your transformation process and store them together, or store them each to separate Response Tables. There must be one Response Table per expected Web Service response.They must be defined ahead of time and exist permanently in the RDBMS, so that Tableau Desktop or Server can connect to them as Data Sources.Defining the Response Table(s)įor this architecture, the Response Table(s) in the RDBMS must meet the following conditions:
#Tableau reader live connection full#
This solution allows for taking advantage of the speed, optimizations, and security layers built into Web Services, while also giving Tableau a relational system with full ODBC compliance to query. I want to point out a major difference from other solutions: You are only storing responses to individual Web Service Requests, not trying to pull all of the information from the Web Service. To insure that a user only sees their given Response, a simple Calculated Field should be placed as a Data Source Filter: =
You connect the workbook to a given response by setting a Tableau Parameter, which I will refer to as the Response ID Parameter. Tableau will connect to this Response Table like any other Live Data Source. Solution: Transform the Web Service response into tabular format, then insert into a relational database table.Įvery response, after it is transformed, will be stored in a Response Table in the RDBMS system.
#Tableau reader live connection how to#
If you know how to do Steps 1, 2 and 3, can just as easily insert the rows of tabular data into a relational database table as an Extract file. Insert the rows of data into the tables in the Tableau Extract (Hyper, previously TDE).Create a Table Definition (schema) for the Extract table(s).Transform object-oriented responses into tabular form.You can go read deeply about object-relational mapping and object-relational impedance mismatch, but the short version is that everyone has to do work to figure out how to transform an object-oriented response into a tabular form.ĭue to this requirement, when you build a Tableau Web Data Connector, it must follow this exact set of steps: Often, Web Services data is returned in more of an Object-Oriented format. Tableau expects data be in a tabular, relational format (Rows of data with well-defined Columns). Using a Relational Database to Store Web Service Responses However, Tableau’s ability to connect live to a wide range of relational data sources allows us to construct an alternate architecture for accessing Web Services responses “live”:
Tableau provides a Web Data Connector technology which helps individual analysts retrieve data from Web Service Data Sources, but current design does not account for data sets to vary depending on the user looking at the workbook, something essential for scalable and secure Tableau Server reports. Tableau falls in this category (I don’t care about any others, but it’s not an issue exclusive to Tableau). There is one major implication to this architectural decision though - BI systems that expect a relational model and SQL-compliant querying capabilities do not have a native, natural way to handle these data responses. There are many reasons for adopting this architecture, and I’m here neither to recommend or pass judgement. In the majority of cases, the result is a set of RESTful endpoints returning JSON object data, but for the purposes of this article, any variation that involves HTTP requests and responses in a “web-friendly” response format (JSON / XML) will be referred to as “Web Services”. Many organizations have begun standardizing on a “Web Services” layer for access to reporting data, often with a restriction on directly connecting to the underlying data stores that power the Web Service responses.
0 kommentar(er)
