Summary

This page provides guidelines for Write-Back administration and management from a technical perspective. It is meant to be used by technical users and system administrators that will be responsible for the Tableau Extension.

How is Write-Back deployed?

Overall Architecture Diagram

Write-Back Manager

• This tool is used to make the whole configuration process for Write-Back as well as managing the services and settings.  This is also where license management is done or any other administration task.
• It is used only by the Write-Back system administrators and the login is done with an OS user from the machine.
• Each Write-Back installation has its own Write-Back manager deployed on the same machine allowing to manage that instance.

Write-Back (Server)

• Tableau extensions are web-based and deployed on a separate application server from the Tableau Server. This means that Write-Back should be placed side by side with your Tableau Server, ideally on a separate machine. Users will interact with the Write-Back server either on the Tableau Desktop or on Tableau Server, the behaviour is very similar as even on the Tableau Desktop extensions are executed on an embedded browser.
• The Write-Back server location is defined on the Tableau dashboard by adding a trex file. This is the file that tells Tableau where is the Write-Back server, since Write-Back runs on your environment you should always select my extensions and locate the file that is provided after finishing the installation process. Bear in mind that all Creators that will build a dashboard with Write-Back need to have the corresponding trex file in hand.

Dataset Tables

• Write-Back acts as SQL engine storing the data submitted by users on tables. Whenever a Creator makes a new configuration on Write-Back a table is provisioned on the Write-Back database. This database is provided by Write-Back on a basic configuration but can easily be switched to your own database by applying the configuration on Write-Back Manager.
• Since a table is created for each dataset it is advisable to have Write-Back configured to use a separate schema or database inside your database system. This way the Write-Back environment is more contained avoiding issues and you always know for sure that every table has the same origin. In order to achieve this, a database user with full permissions on the schema is configured on the Write-Back back-end. You should also have a read-only database user that can be leveraged by Tableau Creators to build dashboards with data sources pointing at Write-Back data. Write-Back table structure only changes if the configuration is changed so bearing this in mind you can leverage this fact by following our Back-end Manual Data Procedures and apply ETL, store procedures or any other mechanism on top of the Write-Back tables.

• By writing to a separate dataset and with the audit mechanism we are sure that, even though we are giving freedom for the Creators and Explorers to be creative and use Write-Back in different ways, the original data is never touched and we can always keep track of who did what. This detailed audit trace can be very important for different reasons:

  • Along time users might introduce inaccurate inputs, and you want to know what was the original submission

  • Any possible mistakes that might arise can always be fixed, no data is overlapped

  • To ensure compliance, you know who did what 

• That is why a separate dataset is the best choice since the extension is fully managing it Write-Back can ensure all the premises above despite user actions

Data Warehouse

• Your existing data will reside on a separate schema or even a separate database and thus you will need to blend it with Write-Back data by leveraging different mechanisms:
  • Tableau
    • Data blending can be used to associate the Write-Back dataset entries with existing data, the fields chosen from the source sheet can be used as linking fields. For more information check the Tableau documentation. While being easy to use this can have an impact on performance as the joins are done in memory on Tableau. 
    • Relationships and Data source joins allow combining data from different tables that might even be on different databases and thus connect the dataset with exiting data. For more information check the Tableau documentation. If you have all data on the same database this option is easy to apply and performance should not be affected, Tableau will push the joins to the database. 
  • Database
    • Create database views. Your existing data will reside on a separate schema or even a separate database and thus you will need to blend it with Write-Back data by leveraging different mechanisms.
• For more details check our Why Writing to a Separate Dataset? article on the Knowledge Base.

Back-end Data Processes

• While Write-Back does not provide, OOTB, any backend processes it is possible for technical users to implement them. These processes can be responsible for automatic tasks such as:
  • Pre-populating datasets, for instance with a basis for forecasting
  • Cleaning, old data or not relevant anymore
  • Synchronizing with other databases, for instance with an analytical database 
• These can be implemented in different ways using:
  
  • Database
    
    • Use database triggers that, based on the Write-Back dataset, update or insert data on other tables. 
    • Using stored procedures
  • Extract Transform and Load (ETL)
    • In your organization, an ETL tool might be used for other purposes and be re-used here to update or insert data on other tables. 

• Please be aware that these mechanisms can overlap existing data that might not be recoverable without restoring a database backup, use them wisely implementing any particular validations required to ensure no data is lost inadvertently. There will be a delay in making the data available but these techniques can improve performance while the data is being read on the dashboards. 

• For more technical details please check the section Back-end Data Processes.

Security

• Since Write-Back runs on a separate server we need to ensure that security is also applied here. Write-Back supports multiple authentication mechanisms including single sign-on technologies allowing to match the security on the Tableau Server and simplify maintenance always keeping users synchronized. 
• For authorization, you should resort to Tableau Server security ensuring that dashboards with Write-Back configured are only accessible by users that are entitled to submit information. 

How Write-Back works

1. Creator and explorers users open Tableau Desktop and add the extension component to a dashboard that will be used to input data. This dashboard contains not only the extension but also a sheet that is used as a source to drive the data to which the user can add information. After adding the extension object, a trex file should be chosen, this is the file that tells Tableau where is the Write-Back server, since Write-Back runs on your environment you should always select my extensions and make sure that all Creators have the corresponding trex file in hand.
2. The user configures Write-Back by specifying the additional fields and types as well as the table where the data set is going to be persisted. When he clicks on submit, this information is sent to the Write-Back backend.
3. The Write-Back backend is responsible to manage the configurations as well as creating the new data set. This means dynamically creating the tables that will support the data set.
4. The power user publishes the dashboard to the Tableau Server ensuring that only the right users have permissions to see the dashboard and consequently be able to input data.
5. Tableau Server users can now select existing data and append additional data through the extension, as for example comments or forecast deltas.
6. The backend is responsible to insert the data submitted by the user on the data set configured.
7. The data stored can then be used as any regular data source configured on Tableau Desktop, either live or as an extract.
8. 3.1 and 6.1 happen just after the corresponding action is done and correspond to auditing all actions done by users. Audit information is kept on a separate table.