Qlik Sense cloud editions - Space out in cloud - Protect your data connections - Part 3

[Michael_Tarallo]

With the design work to introduce Spaces, available in Qlik Sense cloud deployments discussed in Part 1 and Part 2 of this series, today Fredrik Lautrup is back with Part 3 - sharing how his team added the ability to secure Qlik Sense data connections within the Spaces apps are created in.

With the introduction of spaces and the content life-cycle we have created a number of concepts and a way of working with content that we think a lot of our customers will be happy with. But not all customers are alike, we will always have customers that want to do more. Luckily the spaces concept with some of its more advanced space functionality allow for this flexibility to adapt to customers’ needs to work with and protect their data. If we start with the movements of apps and its relations to data, we have introduced the concept of space aware data files and data connections. This means that data files and data connections can be stored in spaces and referenced in different ways to its location. The permissions are always applying to the current user, but this might be used to build out some interesting structures.

So first let’s go through how this works in the data load editor......

Download the PDF attachment to learn more.

Want to experience Qlik Sense now - start your free trial here: https://www.qlik.com/us/trial/qlik-sense-business

[robert99]

@Michael_Tarallo 

@Fredrik

Are the names of these spaces right?

Shared Spaces (I think) is really (now) supposed to be used for a Development Space. Where a Team can work on an App. And when happy share to a Managed Space. So maybe rename this to >> Development (or Work) Space.

Whereas Managed Space is really the Shared (or sharing) Space. Where Apps when developed in the Development Space (or personal Space) are then copied to a Shared Space. The team can still work on the App in the development Space and when happy publish the changes to the Shared (Managed) Space. So maybe rename this to >> Shared (or Sharing) Space

So the above Part 3 really only applies to the development and personal Space

[Fredrik_Lautrup]

I'm not sure I follow your thoughts. Naming is always hard but in general thing about the spaces as 

• Personal spaces - for your exploration of data
• Shared spaces - for collaboration around data such as development but can also be casual sharing
• Manages spaces - for consumption and self-service of governed apps (read only with a controlled process for updating)

The blog post here is not about the different types of spaces but about how you reference data from within the app to spaces (independent of type). This is very applicable to managed spaces as well as you will have reloads happening here as well. I would argue that the content in the blog has one of its most important use cases including managed spaces, the demands to not use production data for development and not have to change the script when moving into production with production data.

[petrus]

This is great and I totally understand the main point here - no need to change the script while moving between envs. But from management perspective, you would have more data connections with the same name and one and only distinguish point is the different space name visible in management console, right?...Any ideas here? It seems to me just to have option1 (no changes in scripts, but hard to manage) and option2 (better managability to have one central data connection space, but need to change the script while migrating).

[Fredrik_Lautrup]

@petrus We recognise this problem and what we have today is a step that we can build on.

I also see some customers being creative in using what we already have to solve this problem. They put a config file (CSV/TXT) in the different spaces that they use to detect where they are and then build into the script the logic on what need to change depending on in what space the app resides. You could argue that it is a hack but might be suitable for some customers.

But I agree with you that what we have can be improved to make it even easier for you. 

[petrus]

@Fredrik_Lautrup thank you for answering this topic. I am interested more in this lifehack you mentioned. It means that each and every script begins with loading that specific config file using current space notation (lib://:Datafiles/config.txt) and base on the value there setting up the DCs within the rest of the script. Do I understand well? Feel free to reach me by personal message with some example if possible.

Thank you!

[Fredrik_Lautrup]

Yes, as you describe you have a config file in each space. You can then load the config into variables

config:
LOAD
Name,
Value
FROM [lib://:DataFiles/config.csv]
(txt, codepage is 28592, embedded labels, delimiter is ',', msq);

Let vtype = peek('Value',0,'config');
Let vspace = peek('Value',1,'config');

and after this you can use the variables as you need to tweak the script. If you now move the app it loads a new config.csv and you do not have to change the script.

[eiconsulting]

Hello Mike & QS Gurus

is there any chance to connect one App published under a DedicatedTenant to take via a "must_include" a Script contained into a GeneralTenant?

something to be locally included in each DedicatedTenant App like:  

$(Must_Include=[lib://https://myGeneralTenant.eu.qlikcloud.com:DataFiles\CommonScriptForAll.qvs]);

The reason of this is that we'd like to manage several DealersTenant by just mantaining a common script file we store in to the GeneralTenant...

Thanks in advance for your suggestions about how to manage this.

PS: we're using a QlikSense Cloud Saas solution

[Fredrik_Lautrup]

Tenants have a hard separation. You can not access things between tenants. 

What I'm not sure about but I'm sure someone else has tested is if it would be possible to put the script in a shared file connection (S3, OneDrive etc) that you then access from your different tenants. 

If this does not work you could probably do something with an automation that you trigger through a web hook that bring the script file into all tenants when the file gets updated. 

[CJ_Bauder]

@Fredrik_Lautrup nailed it - the file should be called from an external source such as a DB or Cloud source, and can be [included] from there. This carries the great benefit of also allowing source control and a more centralized means of access to the original script file vs. being in a singular tenant.