Any environment with more than on developer will quickly lose consistency of attributes across the environment. Agreeing standards as part of developer onboarding, and validating these before app acceptance is very important.
An example set of naming conventions is discussed below. This assumes a common directory structure similar to a Qlik Deployment Framework (QDF) model.
The QDF helps to organise application components
The example below follows a concept of one common container (for data and files which aren't app specific), and a hierarchy of product (one or more applications developed for a specific purpose) followed by customer (a standalone version of those applications, loaded with different data).
The resulting directory structure is therefore Root > Product > Customer.
This is particularly common in OEM and SaaS deployments where deployment and config of applications is automated and physical separation of resources is desirable.
QlikApplicationData (available via a UNC path)
- common
-- shared
--- 1_application
--- 2_etl
--- 3_qvd
--- 4_...
-- <customer1>
--- ...
-- <customer2>
--- ...
- <product1>
-- ...
- <product2>
-- ...In this model, we benefit from improved consistency when using a simple set of rules for naming elements both in the QMC and within apps.
Consistent naming in the QMC
Adopting standards in the QMC will help reduce the maintenance burden when adding, updating or removing application components. Administrators and users should be able to see 'at-a-glance' what a resource is intended for.
App and Stream Names
Take a decision whether to include the Product Name (which could refer to a group of apps which might be published into a stream) in the App Name, as well as in the Stream Name.
If you've got a group of Finance apps which are based on GL data, you might want to name a stream "Finance" and set app names like "General Ledger", "Month End Reconciliation", etc, excluding "Finance" from each app name.
Given the limited real estate in the Qlik Sense Hub for app names, shorter can be better if you've already specified the product name or app group in the stream name. The App Description can then be tailored to provide the remaining context to business users.
Concepts:
- Simpler is better - no long app names, no "technical" jargon (like versions, owners, etc)
- Provide a description on every app. At a minimum, tell the user what data the app pulls from, it's intended audience, it's purpose, and any limitations or caveats in the data or the way the data is presented
- Use a common or familiar app thumbnail. This could be tailored by product, and include the name of the app with a small icon to match its purpose (e.g. a book for a General Ledger app)
Content Libraries
Where there is shared content outside of an app, the content library name should align with the product. A convention such as "
Hence a library containing country flags (for use with an extension like Climber Cards) used across multiple customers and apps in a "Customer Analytics" product would be named "CustomerAnalytics_CountryFlags", rather than just "CountryFlags".
Making the name specific to the product (and if needed, to the customer or app) means it's easier to catch dependencies when migrating apps between environments, and to update existing deployed applications without impacting other products or customer deployments.
Data Connections
Data connections should be specific to a container, and provide a common path which can also be used to ensure developers (and full self-service users who can create/edit apps) can only access the connections they need.
The convention here should include:
- the type of data connection
- the product
- the customer
- the location within the container it's pointing to
For ease of sorting, these follow a slightly different convention to other object naming:
So, if we had a product called "Customer Analytics" and a customer called "Acme", we would employ two data connections by default. One specific to the customer, and one specific to the product:
- CustomerAnalytics_Acme_Dir_Root (points to /
- CustomerAnalytics_Shared_Dir_Root (points to /
If we needed to create a REST connection to a Google Analytics API, we might create a connection called:
- CustomerAnalytics_Acme_REST_GoogleAnalytics (this could be specific to that customer as it might use their credentials)
Tasks
These only concern administrators, but they should include some basic terms in the name which explain what that task does at a glance.
Consider a simple tiered ETL process for the "Customer Analytics" product for the "Acme" customer, which has the following three components:
- Extract application (CustomerAnalytics_Acme_Extract)
-- Transform application (CustomerAnalytics_Acme_Transform)
--- Dashboard application (Customer Analytics)
The first app is triggered daily, while the others are triggered upon completion of the last. An example of task naming would be:
Trigger can be D (daily), W (weekly), T (on task trigger), etc. The order will be dependant on where it is in the task chain.
So, for our examples:
- CustomerAnalytics_Acme_D_0_Extract
-- CustomerAnalytics_Acme_T_1_Transform
--- CustomerAnalytics_Acme_T_2_DashboardLoad
Consistent naming in applications
During application development, consider defining standards for most elements within the app.
Sheet names and descriptions
Keep them short but descriptive. Avoid using technical jargon and consider taking out unnecessary words like "Dashboard", "Analysis" or "Report" to keep them succinct.
Variables
Variable naming is important, especially if you're using them for passing expressions into the apps.
If you're using the QDF, employ the appropriate scope prefix (vG, vL, etc), and agree a common structure to follow this.
An example would be:
v
Some examples:
- vG_Color_Header_LightBlue - for a global colour used in all headers
- vL_Expression_Sum_Sales - for a app-specific expression used to provide the sum of a sales field
Other variable types could include:
- Selector (used for flags in the data model, or based on user selections)
- Dimension (used to specify a normal or calculated dimension)
- Conn (used for data connections)
- Set (used for components in set analysis)
- Date (used for date flags and comparisons)
- Agg (used for defining aggregation fields)
More will appear as you continue developing - starting somewhere is better than randomly naming each time!
Note: Renaming Data Connections
Qlik Sense data connections created through the browser (in the data manager or data load editor) automatically append '(
To strip the username, head to /qmc/dataconnections/ and update the name. Any open apps will need to be closed (i.e. all browser tabs closed) before the renamed connection can be used.