Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
mattgow
Contributor II
Contributor II

Best practices for spaces. Should we use data spaces?

With SaaS evolving quickly and my head in the "on premises" paradigm, I'm uncertain how to lay out our Spaces and content in the SaaS world.

We're not a gigantic/complex outfit. On premises we basically have ...

  • a utility "app" for each data source that periodically pulls new data into QVD files in folders on disk. All these apps live in one "stream" only used by load script developers.
  • we have a "Stream" for each business group to control who sees what
    • Apps in these streams are full of pretty graphs and they pull their data from the QVD files 

My instinct was to create a "Data Space" for each data source, put each utility app in there along with the qvd files, source connection etc.

However, it seems that maybe "Data Spaces" are really only meant for people who are using fancy pipelines rather than good ol' load scripts housed in apps. Is that true? The UI for data spaces really seems to be pushing me away from my original plan.

If data spaces aren't the best, should we used "Shared" or "Managed" spaces for our utility apps and our QVD files?

The utility apps are really just shells to hang scheduled reload tasks from... so perhaps we should ditch them entirely for automations? Automations can do scheduling and the load scripts could go in GitHub... but automations want to live in personal spaces which isn't what we are after.

Perhaps people know of some recipes for best practice in SaaS among smaller organisations like ours?

 

1 Solution

Accepted Solutions
Daniele_Purrone
Support
Support

Hi @mattgow ,

while it was decided to allow the usage of data spaces for general purposes, their main one is still to be used with QDI pipelines.

The main difference between shared and managed spaces is that the formers are mostly for collaborative development/staging purposes, while the latter are for publishing apps to end users (without the chance of editing the script).

Since the utility apps are, as you mentioned, not really end-user material, they probably should not be kept in managed spaces.

As you said, Automations currently only reside in personal spaces only... but this is going to change in the upcoming months, so you might want to wait until we allow publishing them to spaces (no ETA yet, but it is one of the prioritised new upcoming features).

 

Daniele - Principal Technical Support Engineer & SaaS Support Coordinator at Qlik
If a post helps to resolve your issue, please accept it as a Solution.

View solution in original post

2 Replies
Daniele_Purrone
Support
Support

Hi @mattgow ,

while it was decided to allow the usage of data spaces for general purposes, their main one is still to be used with QDI pipelines.

The main difference between shared and managed spaces is that the formers are mostly for collaborative development/staging purposes, while the latter are for publishing apps to end users (without the chance of editing the script).

Since the utility apps are, as you mentioned, not really end-user material, they probably should not be kept in managed spaces.

As you said, Automations currently only reside in personal spaces only... but this is going to change in the upcoming months, so you might want to wait until we allow publishing them to spaces (no ETA yet, but it is one of the prioritised new upcoming features).

 

Daniele - Principal Technical Support Engineer & SaaS Support Coordinator at Qlik
If a post helps to resolve your issue, please accept it as a Solution.
mattgow
Contributor II
Contributor II
Author

That's enough for me to work with for now, thanks @Daniele_Purrone 

I read that the ability to put qvd files into subfolders within a space might eventually be added... at that point we might get away with one space for all the ETL stuff/qvd files and then spaces for end users.

For now we'll make a shared space for each data source and go from there.