We have two environments (TEST and PROD) to publish dashboards to. Data for those envs resides on the same RDBMS server, 1 schema per env. And we want to publish 1 dashboard to 2 envs, so that 1 dashboard looks at TEST schema, and the other looks at PROD schema.
That's the approach we came up with, but it's not working as expected: we can not find a way how to deploy Tableau dashboard to 2 envs (and use 2 separate schemas) without actually maintaining 2 versions of the same dashboard (one for TEST and one for PROD).
So either we chose a bad deployment strategy for Tableau, or we're doing smth wrong with it. Could anybody please share your experience on how to deploy Tableau dashboards to separate envs without having to manually edit dashboard for every env? Or what's the problem with our approach?
You didn't specify your RDBMS in the question so my answer will make a broad statement that may not necessarily apply in your specific case.
I think you've chosen a poor approach for your testing and production database environments. Normally, test and prod are on completely separate database instances and in many cases, separate servers. Having them together on the same instance or server means you are using up production hardware resources during testing, with the possibility of locking up the server because of run away queries against the non-production schema. With a single instance, it would be very easy to bring your production instance down inadvertently or maliciously without even being logged into the production schema.
Your better approach is to have two separate database instances: one for test, one for prod. The two instances could be on the same server but are isolated db instances. Both instances have the same users and same schemas. Then you can easily point your Tableau data sources to the respective instances without needing to update your workbooks or keep two copies of each workbook. For example, if you are using Oracle, keep the TNS aliases the same on both Tableau servers but alter the connection details in tnsnames to point to either the test or prod db server.
Your situation sounds like mine. I need to publish exact same report to different environments using different server/database configuration. This is what I do:
Maintain single source of truth, which is production version.
Create an utility converting report to different environments. You can also do it manually as following:
Save your workbook (Tableau file) as .twb
Open twb file with any text editor. It is xml like. Tableau creates connection and renders graphic from this information.
Text search for username, server, port ... You will see all your configuration information here.
Replace those information by target environment information.
Save and open it again using Tableau Desktop and publish.
If you have automation tool like Jenkin, you can develop one click solution for deployment using Tableau commands.
Related
My question is kind of similar to this question, but not quite :
Hide a marklogic database to specific user (permissions)
Background - up until now, developers who use database X were all admins on the server ( this is a historic config that we have recently inherited ), but now we want to have new developers added to the server who definitely wont be admins, and who will have a new database Y added to the server.
What we want to do is have several groups of developers using the same MarkLogic 10 server, but have it so developer group X can only work in their database X, and Developer group Y can only work in database Y. We dont care if they can see all databases on the server.
Does this mean we have to apply permissions to every document in every database to do this, or can we control this via a roles that limit access to specific databases?
Can someone suggest the right way to achieve this please?
Thanks in advance.
You have two tools to work with:
Granular privileges which allow you limit the scope of a privilege to a specific resource (such as database or forest)
Document permissions unique to documents reflective of their respective set of intended users on each database as you already mentioned
However, in my experience, I've generally found this use case is better served by having many small dev clusters rather than one large one as resource contention (one app team pushing CPU to 100%) can become too much of an issue. It is pretty quick and painless to spin up and tear down dev clusters on AWS or Azure. Or, if you're self-hosting, you could look at running multiple MarkLogic Containers on a single host.
I am working on Tableau Server where I have say, three solution environments viz. Development Staging and Production.
I have created workbooks in Development environment and each workbook use many data sources.
For instance lets say I created the workbook Account Workbook and I have used these two data sources Dev-DataSource1 and Dev-DataSource2. I have other data sources available like Stage-DataSource1, Stage-DataSource2, Dev-DataSource3, Stage-DataSource3 etc.
The problem I am facing is while moving workbooks from Development to Staging environment, the data sources remains the same.
So continuing with the same instance if I move Account Workbook to Staging from Development environment, Account Workbook still uses the same data sources Dev-DataSource1 and Dev-DataSource2. I want it to use the Stage-DataSource1 and Stage-DataSource2 .
This might be a very trivial question or maybe a bad design, but I have created so many workbooks such that creating them again might take loads of time, so please refrain from asking me to recreate those workbooks again. If there is no other way other than that then do tell me.
Thanks in advance
Can you not just edit the data sources, for instance from Dev-DataSource1 to Stage-DataSource1?
I assume they have the exact same structures, field names, etc?
Right click on the data source and click "Edit". When in the data source page, pull in table(s) from
the new datasource and replace the one(s) that are there. If you have joins you may need to recreate them. If you have custom sql you just need to change your sql to point to the new table(s).
You will need to refresh your data sources. It should recognize the fields assuming they are exactly the same as before.
If you need to edit the connection, you can do that as well (if you need to point to a different server, etc.)
Make sure you have a backup of your workbook in case something goes wrong.
It may also be worth your time to look into the Tableau Python document API: https://github.com/tableau/document-api-python
This would allow you to do (some/all?) of what are describing programmatically.
I am working on an internal reporting dashboard project . There are majorly 3 roles/level to internal reporting dashboard like higher management, project management etc.
And the breakdown of information for every role/level is different as compare to other roles.
For internal reporting dashboard we have to create a database ( lets say D - SQL SERVER) whose data will be coming from 3 databases ( Lets say A,B,C) after integrating them.
For now as per my research, we can directly link database D using Tableau Live Connection in Tableau Desktop ( Professional ed) and use it to create a dashboard.
To host that workbook for users, I can use Tableau Online for publishing and to make data visible according to the roles I can use filters to restrict the data.
Now my questions are:
1. Will this workflow will be right ? Am I missing any step or process that I would need to cater.
2. How will the changes reflect in the dashboard once it is published ? Lets say if I have to add any filter/ parameter in the dashboard. Do I need to make the changes on the workbook using Tableau Desktop and automatically changes will be reflected ?
or do I have to host it again on Tableau Online ? Please educate me on this too.
Thanks for assistance I have attached a purposed workflow image too.
Regards,
Manail Pasha
WORKFLOW IMAGE
If your system is not a transactional database, I would avoid a live database connection. I would recommend a data extract that combines data blending techniques to create a data extract a.k.a .tde file.
I would publish a dashboard with user filters that enable row-level security via filters and ensure users could only see certain data.
Here is a diagram that I would follow if I were you.
To add filter/ parameter either you can do it from the desktop and publish it to Tableau online or login to online and add the filter/ parameter from the edit mode and Save it, it will get reflected if you do anyone of the above mentioned method.
If your data is frequently changing, i would recommend to go on with Live Connection, Extract refresh can be done on incremental, but the appropriate fields needs to chosen to do it( you should also consider, how to handle negated entries ). It all up-to you to decide to go on with Extract or Live
We are in the process of building a cluster for our hosted services at work, the final product will be used to host multiple separate services. We are in the middle of deciding on how we want to setup our databases. We are running a postgresql database server which all services in the cluster will use. The debate right now is whether to give each service its own schema in a single database or to give each service its own database.
We just aren't sure which is the better solution for us. None of our services have a common structure and data does not need to be shared. What we are more concerned about is ease of use.
Here's what we care most about, we are really hoping for an objective vs opinion based answer.
Backups
Disaster recovery - all services vs individual
Security between services
Performance
For some additional information, the cluster is hosted within AWS with our database being an RDS instance.
This is what PostgreSQL official docs says:
Databases are physically separated and access control is managed at the connection level. If one PostgreSQL server instance is to house projects or users that should be separate and for the most part unaware of each other, it is therefore recommendable to put them into separate databases. If the projects or users are interrelated and should be able to use each other's resources they should be put in the same database, but possibly into separate schemas. Schemas are a purely logical structure and who can access what is managed by the privilege system.
Source: http://www.postgresql.org/docs/8.0/static/managing-databases.html
Disaster recovery - all services vs individual
You can dump and restore one database at a time. You can dump and restore one schema at a time. You can also dump schemas that match a pattern.
Security between services
I presume you mean isolation between databases and isolation between schemas. The isolation between databases is stronger and more "natural" for developers concerned with "ease of use". For example, if you use one database per service, every developer can just use the public schema for all development. This might seem "easier" than adding schemas to the search path, or "easier" than using schema.object when programming.
It depends in part on how you manage privileges for the roles you use for development, and on how you manage privileges in each database or schema. You can change default privileges.
Performance
I don't see a measurable difference. YMMV.
Domains are virtual view of a data source that presents the data in business terms, allows for localization, and provides data-level security. ADomain is a metadata layer that provides a business view of the data accessed through a data source
this is domain definition as in Jaspersoft reporting tool.
I am currently given the task to build or come with a design to create some domains in tableau.. (like in jaspersoft)
examples of domains in jaspersoft
In jaspersoft when you click on a domain : ex customer domain: you will see the list of tables (that are selected)
How to do the same in tableau?
Please guide me on this..
The meta data layers in Tableau are quite lightweight compared to other BI tools, which is ofter a plus, but seems to fight against your assigned task.
Usually the best approach in Tableau is to learn to use the tool well, build visualizations for your business domain, test and refine them, and then later focus on factoring out common meta-data as your Tableau projects grow. That tends to work better than insisting on a big meta data design up front approach.
Still as you learn to use Tableau, the features that you'll want to understand related to your question are everything about data connections (which define how to connect to a data source, and the fields, data types, calculations, groups, sets, field roles etc). You can start with a data connection in a single workbook and then save the connection separately (typically on the server) so that it can be shared among multiple workbooks (to reduce duplication). You can also use Tableau Server like a proxy for your database.
For security, you can look into the groups and access controls provided by Tableau Server, along with user filters.
Some of the features you ask about might be more properly relegated to the database server, such as by defining common views visible to different users.