Best Practice - Writeback

This article gathers together examples of best practice in Vizlib Writeback Table and Vizlib Input Form, you can find a full list of all our support materials on the Introduction page for Writeback Table and Input Form.

Writeback: In this article, Writeback means Vizlib Writeback Table and Vizlib Input Form.

This topic contains the following sections:

Getting the Right Setup and Installation

Before you start, here's a few tips to make sure your setup and installation goes smoothly.

  • Check the Architecture Guide to find the best fit for your installation environment.

  • Server - we only recommend using serverless Writeback for small-scale data sets or use cases (e.g. a pilot for a project). For any live data sets (large or small-scale) you'll need to integrate Writeback with Vizlib Server, which offers more support in terms of security and backup.

  • Environments - you'll need a separate Writeback installation on each environment you're using (e.g. a test and a live environment need separate installations). It'll keep your test and live data apart and reduce the risk of any rogue updates or deletions.

  • Qlik Sense - Serverless Writeback is only available to users with Professional Qlik Sense licenses. When you use Writeback with a server, users with Analyzer licenses will have access as well. There's also limited support for Qlik SaaS, you can find fulldetails in our factsheet here. There is also limited support forQlik SaaS, you can find a summary of deploying Vizlib extensions with Qlik SaaS here.

  • Demo App - There's a Demo App you can download to help you get started with Writeback which you can download from the products page of the User Portal or the Demo apps gallery of the Vizlib site.

  • Errors - If you do get an error returned during setup, Writeback has a Known Issues article  with examples and advice on how to resolve them.

Writeback and Vizlib Server

If you're integrating Writeback with Vizlib Server, here are some tips to get you up and running.

  • Use the checklist in the Vizlib Server Prerequisites guide to gather any details you need for the installation, including requirements for SSL certificates.

  • Watch the video tutorial in the Installation guide to help understand the steps in the process.

  • Each setup has its own Configuration guide to help you integrate Vizlib Server with Qlik Sense.

  • Once you've completed the installation, there's a Database Backup and Recovery guide to help you handle any post-installation database changes.

How Writeback Works

If you're starting to work with Writeback, it can help to break the process down into steps. Here's an example of an update made in Vizlib Writeback Table.

  • User makes changes to a table or form.

  • User submits the change by clicking Writeback Table.

  • Vizlib Writeback Table attempts to save the change to the destination (e.g. file, database).

  • Application reloads (if reloads are configured).

  • Application data is refreshed and the changes are displayed.

You can find more information on reloads in our article here, and information on the Reload Task option here.

Writeback and Qlik Sense

Vizlib Writeback Table and Vizlib Input Form are built to extend Qlik Sense functions. Here's some tips about using Qlik Sense with Writeback.

  • Data Load Script - Use * (all) in the data load script for the step which specifies the columns to be loaded. This means you'll be able to add more columns without having to edit the script every time. There's more information about editing data load scripts here.

  • Column () Syntax / Expression Editor - If you're working with column syntax using column names as a reference, it's a good idea to use double quotes (e.g. Column("Slider")). Double quotes don't cause syntax errors in the Expression Editor, while all other options do e.g. single quotes. There's more information on best practice for Column() syntax here.

  • Using Variables in Expressions - You can use variables in Qlik Sense Expressions to extend Writeback settings. A good example is defining the writeback destination with Use Destination Expression in Server Settings, rather than selecting one from the drop-down. If you duplicate a sheet in Qlik Sense, the duplicate writes to the same destination by default. But if you use an expression to define the destination, you can add a condition for this setting which means only the original application will write the data to the production destination. Any copies update a destination in another location.

  • Section Access - If you're looking to start using section access in your data load script, Qlik Sense have a best practice reference which you can access here.

Writeback Performance

As you continue to use Writeback, it's a safe bet that the amount of data you work with will grow. Here are some tips for managing performance in Writeback.

  • Don't Overload your Sheets - Data for a Writeback visualization is processed using the Qlik engine. We've compiled some advice about improving performance in Qlik Sense here.

  • Integrate with Vizlib Server - server integrations for Writeback contain Writeback Audit functions to help you drill down into operation data, and configuration options for reload and writeback operations for destinations. You can find a full list of server integrations here.

  • Enable the Data Source Warning - If you're configuring your writeback table, and would like to be alerted to any changes that could disrupt table behaviour and potentially generate duplicate values (e.g. adding fields which come from tables in different data models), you can enable a Data Source Warning in the Appearance settings which will alert you to any potential duplicates and link to Best Practice instructions on how to avoid generating them.

  • Using an Index for Lookups - there are two lookup functions for Update or Delete writeback operations - Match rows by values references each column in the table, while Match rows by Primary Key references the primary key for each row. Choosing Match by Primary Key for larger datasets should help improve performance. You can find full details here.

    Selecting multiple rows while using the Writeback Table to filter new table rows

    The Writeback table maintains a copy of the modified rows. When working with large datasets, selecting a row clears the previously fetched rows. If you select the Writeback button and there are rows that were previously modified but are not present in the data page fetched after the selection change, the table will first re-fetch additional data pages before committing to the current page. This can significantly impact the total operation time, particularly when dealing with large datasets containing over ten thousand rows. The issue is compounded when there are numerous columns. As the number of cells to be processed increases, this leads to slower loading times and a higher likelihood of encountering the continuous loader for your data.