Hello everyone and welcome to the first edition of Support Techspert Thursdays for 2021.

My name's Troy Raney and I’ll be your host for today's session. Today's presentation is: Optimizing Qlik Sense SaaS Apps with the App Analyzer.

Our presenter today is one of the architects behind the App Analyzer: Daniel Pilla. Dan please tell us a little bit about yourself and what we're going to be talking about today.

 

Yeah, absolutely. Thanks Troy. So again, my name is Dan Pilla. I’m a principal analytics platform architect; previously enterprise architect at Qlik. I’ve been here for roughly six years at this point and my expertise lies within the architecture frameworks, integration topics as well as our cloud strategy at Qlik.

The presentation today, what we want to go over is just a high level: What is the App Analyzer; kind of where it came from and why was it created. We'll walk through a high-level demo; kind of paging through each sheet to show some of its capabilities and highlight a couple of examples. Along the way we'll talk about how it's configured. I’ll actually show a short little demo of that. We'll highlight a couple of troubleshooting issues, though hopefully you shouldn't have to deal with many. And then lastly, we'll talk about a couple of things to remember; some resources and of course how and where to get the application itself.

 

Can you start by explaining for us, yeah, what the App Analyzer is?

 

Yeah, no, absolutely. So we'll go over a very quick high-level overview, but ultimately the application it's a direct port from the App Metadata Analyzer, per Qlik Sense Enterprise on Windows. This application is actually, or its predecessor is actually shipped with the Windows product. You can find it with the additional applications like the Reloads Monitor, the Sessions Monitor for the Windows platform. And given that the API endpoint was the same in our SaaS platform, it seems like an obvious first choice for a monitoring application to port over. Now the data present in the application is pretty much identical across both platforms, and you're able to get the app base RAM footprint. That's the RAM footprint of the app opening from disk, so without any users or session cache. That's actually a direct quota that we’ll talk about in just another slide. In the SaaS platform, we'll talk about the peak reload RAM. So the maximum amount of RAM the application takes to reload, and then there's a number of other metrics. Like the table and field RAM, the overall row counts of the tables, cardinality, and then the presence of data islands, and synthetic keys, along with circular references that can kind of give you some hints on the integrity of the application itself.

 

What are some example use cases for it?

 

When to use it, there’s obviously a myriad of different times that you might want to come in. But at least at a high level: number one, just tracking of app RAM size against tenant quota. We'll talk about the quotas on additional slide but this is going to be a key metric that you will need to monitor in SaaS. We’ll talk about anomaly detection and again it can be used for identifying potentially problematic applications. As well as, of course, optimizing. These tend to go hand-in-hand. Lastly then data modeling standardization and best practices. So kind of: holding all of your developers to a certain bar and making sure that you're preventing any potential problems in the future for your end users.

 

Dan, does this come pre-installed as a part of the SaaS tenant?

 

At this point in time, it does not come pre-installed. So we'll talk about the configuration but you will need to grab this application from Qlik community and import it into your tenant. The good news is: it's just an app; and it should only take about 10 minutes to configure.

 

Nice. So you're going to show us a demo now; and what tier of SaaS are you about to demo from?

 

Good point. So I want to bring up, just to add a little color in context because not everyone on the call might be aware of the you know what the tiers are and what the standard quotas are and so forth. So we’re going to be demoing from a tenant that just has the standard tier enabled. What that means is: out of the box everyone gets this. There's no additional charge for this whatsoever. It's kind of baked-into the standard license, is that the base RAM quota per application is five GB by default. And again that's excluding all users excluding all caching and so on. It's just, if you were to open the application in RAM; how much does it take? And that is one of the default quotas in the SaaS tenant. There's no horizontal limit so you can open as many applications as you want that are under five GB. You can have as many users on them as you want. No limit from a horizontal scaling perspective.

There is also a quota of peak RAM reload it's 3x what the base RAM uh quota is. So ultimately when you reload the application, 99% of the time you should be under this quota of 15 GB for a maximum reload RAM. However, you know if you’re doing a mountain of joins, or auto generates, or auto numbers; you know there is the potential to hit this, however it is quite unlikely. But the application will highlight this; will track it; so, there's no guesswork. The application will illustrate all of these quotas for you.

 

And what happens if someone tries to use an app that goes above these quotas? Like a base RAM quota of an app that's above that; will it even upload?

 

It will. It, well, it depends. I don't want to get too deep into that. But you could have an application that; let's say, two gig on disk, that you could upload. And it might break, you know in a week or two. As you start to reload it, right? You can upload one that's right before.

 

Yeah.

 

But there are recent improvements in the upload service. So it now should check the RAM on import; and actually, from a distribution perspective, be smart enough to say that ‘Hey, this application won't open in RAM.’ So I know that actively product management and R&D are working to make that a better and better user experience; to potentially, you know, suggest that you might need an additional tier. And there's more “smarts” going into that in the future.

 

Okay, cool.

 

This is just the standard tier. There are additional tiers. So if you did want to upload an application that's 10 gigabyte on disk, 20 gigabyte on disk. I can say that almost every single corporation I’ve worked with has at least one that's larger than, you know five gig in base RAM. We do have additional tiers that can serve up to 50 gig applications in RAM. So please do contact sales, if you are interested in that. There are additional paid offerings.

 

Can you quickly explain how Qlik stores data?

 

Yeah absolutely. I did want to pull this up, because I will be directly mentioning symbol tables and data tables. And if you haven't seen this slide, or if you're not really into Qlik data modeling; you might not know what that is. So keep in mind that if I were to pull in a simple table; let's say, just region and sales. That the way that Qlik actually stores this data under the hood is in bit stuffed pointers. So you will actually see the symbol tables and the data tables illuminated inside of the app metadata analyzer. So you can get a concept of how much memory does an individual field take as part of the data model. And then how much memory does an individual table take as part of the data model. So just kind of keep this in the back your mind as I go through the demo; as that this inherently is how we store data. And that that becomes pretty apparent when we actually look at the application itself.

 

It's great to see it visualized like this.

 

No more PowerPoint. Let's actually hop into the presentation here. Now I’ve already imported the App Analyzer. Note that there is a version here, because we are continuously releasing new versions. For now let’s just open it up, and we'll do a demo of the front ends before we walk through the back end.

So right now we're looking at the dashboard sheet. On the left hand side, you can see a number of the thresholds. The top two are the most important that you'll want to pay attention to throughout the application. That's the quotas for the standard tier. And what I’m doing is: I’m giving you an alert at the 80 % threshold of that quota. Note that is configurable. You could swap that to 60%, if you wanted to be more conservative in the load script. And it's saying that you've got four applications that have basically exceeded the threshold. That are at least nearing the quota. As well as peak reload RAM that we've actually got one that's exceeded that 80% mark of the quota.

You can use this along with other sheets to track, to see apps that are encroaching up to that quota. So you can make sure that, you know, they're rectified before they will no longer open within the tenant.

 

I love how it identifies potential issues. What else are we looking at here?

 

Across the top you can see the number of KPIs. This is just helpful from a pure inventory perspective, quite frankly, to see how many apps you have in your environment; how many tables across each individual app. I can select, you know, any arbitrary application. I can then see all of the tables; the total table RAM footprint; the number of fields; and there are many other additional thresholds that you can set in the load script.

For example, you know, I don't want applications to contain more than 150 fields or I don't want an app to contain more than 100 million records. Just from a sheer best-practices standpoint, all of those are adjustable.

Now I actually want to take this moment to call out an example here. So, I’ve clicked on a single application. Note that it’s pretty much completely capped. It's at our base RAM quota; from a peak reload RAM perspective, it's okay. But you know, at some point in time in the very near future, it's no longer going to open on this tenant. I can then see that I’ve got a line item table that's taking about a little over a gig in memory, and then I’ve got some comment fields it appears as if that take a very large amount of space. So one individual field is over one gigabyte in RAM. I could pretty much drop down to 80% if I just dropped that individual field.

Now in the Windows world this would just be considered, you know, optimization. In the SaaS world, this is going to keep your apps running at no additional charge; so it becomes even more important.

I can then take a look at another application here, that's my optimized version. If I select that app, you can now see that I’ve dropped all of the comment fields. I actually dropped eight comment fields. I dropped down from 5 GB to 1.7 GB, and that was just eight fields. And let's say that you know, you probe your users; you interview them to see ‘are these fields that you're actually using?’ ‘Are these critical to your analysis?’ You know, obviously before you drop them. But you might not have ever known that they had consumed that much memory. This makes it very very easy to do some pretty simple optimization.

 

That's a dramatic improvement. That's really impressive.

 

Yeah, and I can say that we have one customer example: they had an 18 GB app on disk. This is obviously in the Windows world. They used this application to drop, I think it was a total of 5 fields, and they optimized a few time stamps. They dropped it down to 10 GB in RAM. So they shaved 8 out of 18 GB off from just changing a few different fields. Especially once you start to hit high data volumes; little things like that can make a really big difference.

Now I want to clarify something. Those red lines that kind of make a dramatic impact; are those system thresholds? Or are those just sort of ‘best practices,’ ‘this is what we recommend’ thresholds?

 

Yeah. No, that's a great question. So these are arbitrary, you know, system administrator thresholds. They’re rough, kind of default lines in the sands, but you don't have to use them truly as guide points. In SaaS, roughly the 100 million record is actually probably a rough ballpark, quite frankly for the SaaS tenant. These are intended to say you know; as developer, I know what data sources my users are going against. I don’t want someone pulling in half a billion records. I don’t want them loading in 400 fields into an application with a select star. Or I don’t want them to have 100 tables in their application. They're more meant to be guide posts that an administrator can set up and then monitor you know, what developers aren't following their definition of best practices. So those are intended to be customized.

 

And does the number of users affect the RAM performance?

 

From this app's perspective, no. That's actually a really good distinguishing point. This is only looking at the data model, without any users. So, it's just pure application. This threshold of 5 GB excludes all user activity. It's simply for the data model.

 

Okay, can you walk us through the rest of the sheets?

 

Yeah, absolutely. So, if we go over to the threshold analysis sheet. So, let's assume that you've you know, selected an application. You can then see all of the details for the individual tables, the individual fields. You've got some additional thresholds that are set in here. Again, the number of field records, field cardinality, table number of records, as well as you know number of fields. I believe the setting here is 150. So, just more detail. Same general metrics that you would see on the dashboard sheet, just a different way of looking at it.

From the app RAM to quote up perspective, this is my favorite sheet from like a tenant inventory; to see where my apps stand today, and realistically you know, should I be considering additional capacity in my tenant, right? If I see that I’ve got a pretty heavy %age of apps that are at 60% + of my tenant, it might be time right to look into having additional capacity. Or maybe, should I be looking into something like On-Demand App Generation, or Dynamic Views to start thinning out my data models. Either or could be good routes. But really it's looking to see what %age of all of my applications sit within what %age of base RAM footprint of my quota, as well as peak reload RAM of my quota.

Now note, you might have you know some applications; for example, this one that has a pretty high peak RAM, but relatively low base RAM. This could be from using you know, monolithic QVDs that take a lot of RAM to buffer. It could be that you're using two dozen auto-numbers right in your in your script that takes just a lot of overhead. More than likely I’d say, 90% + of the time, this quote is going to trip before this one will.

If we go over to this sheet. This should look familiar to some users, especially from the Windows world. I’m focusing kind of heavily on ownership here, as well as a little bit on garbage collection. So, I do want to call out this visualization in the top right, where you can see: A) some apps that have never been reloaded on the tenant, and then other ones that haven't just been run in a really long time. So it might even be worthwhile; make a selection here, see if there's trends in ownership. See what spaces they belong to, and see you know, are all of these applications actually necessary? So it does have the capability to do a little bit of garbage collection within the tenant.

I’ll leave this to you on what you want to do with this. You could of course, go in and select ‘I want to see trends by users of you know synthetic keys,’ by data islands, by number of fields; and you could actually start to develop potentially users that might need training.

 

Now this is probably the most complex sheet, at least from an analysis standpoint; and what it's capable of doing. This has been running for quite a while, so I’m going to filter this to pretty recently. And I have some applications here that I wanted everyone to specifically take a look at. So, I’ve set up a few applications here that are reloading every night. And they're growing on at least what I intended to be a 1%, 2%, 5%, 50% growth rate; so you could see a few trends here. On the left-hand side, all of these buttons will change the actual metric that it's running. So, if I select this app that's growing at a rate of 50%, I can expand this and I can see that you know; daily I’m increasing at a rate of 50%. You could then anticipate potentially when this number is going to hit 5 GB, which would be within this week, more than likely. If I flip that metric to go ahead and look at peak RAM, you can note I’m actually really close. And because of this, I’m using auto-number; I’m using auto-generate within that script. You will actually hit the peak RAM threshold before you would the base RAM. But this becomes very simple to you know, come in and you could tie alerts to this. Because I don’t want to have downtime of this application.

 

Yeah, this is great! You can really see trends and anticipate problems before they happen.

 

Exactly! And if you go ahead and click on total rows too; now I can see where hey, if I stayed under that 100 million benchmark that my you know, sysadmin had set, likely wouldn't have to worry about either of those base RAM thresholds. But it can still be that nice guidepost that you can pretty confidently say that you'll be able to stay under a certain threshold. So you'll have to kind of play with that a little bit, and use this application to see how applications profile with your own data sets.

 

Lastly you can take a look at reload time as well; which is handy. This can be nice to see hey, is it potentially on the sheer data volumes from Qlik's perspective? Or is it potentially my database is taking longer? Or I’m using a rest API and that's taking longer? It'd be interesting to actually be able to track those trends from a reload time perspective as well. I hope that at least sheds a little bit of light on what this application does.

 

Yeah, it's an amazing amount of information on how the tenant is performing overall; analyzing specific apps and helping admins find ways to optimize and improve. Now, since it's not pre-installed, what's necessary to set it up?

 

Yeah. Let's go ahead and take a look at the data load editor. I promise it's not too daunting in this application. So this is you know, exactly what you'll see when you pull in the application from Qlik community, and we'll show that in just a moment. You're just going to see 4 variables. And I’ve tried to outline you know, there's a full walk-through guide, so you don't have to use the comments in the load script. But I did comment out everything, so you should actually be able to just follow it from here if you had to. Note at the top, it does require Tenant Admin. And you will have to have the Developer role, because you will need to use the REST Connector, which requires an API key. To get an API key, you have to be a developer. You have to be a Tenant Admin, because obviously you have to be able to see all of the applications, and we of course want you to be able to get everything in the tenant.

 

That makes sense.

 

The first is just as simple as possible. I actually forget what my URL is. I’m going to: ‘ea-hybrid-qcs-internal.’ Our region is ‘US.’ That can be one of a few different regions. Now this set REST Connection; I want you to notice one thing. First notice that there's just a ‘:’ so I’m actually sitting in the Monitoring Apps Dev space. So, if I wanted to fully qualify that, it would look something like this. The ‘:’ is for a relative path; so if I was moving this across spaces, and I had a data connection named ‘REST for App Analyzer’ across multiple spaces, I could move the app freely without having to worry about the actual qualified space name. So, that's more of a tip and a trick, quite frankly.

 

That's a great tip.

 

I’m going to name this ‘Delete Me,’ because I don’t want to muddy-up my tenant. But we're going to create one really quickly. So, we're going to create a new REST Connection. I can search for REST. Now the tenant URL; again, this is all in the guide, ‘qcs-internal.us.qlikcloud.com’ So, that's my tenant. And we can put in any arbitrary API endpoint. I’m going to use ‘/API/v1/items.’

Now below, you only have to fill in one query header; and that's ultimately for your API key. So, the query header is ‘authorization.’ And then you'll put in the word ‘bearer’ space and your token. I’m going to simply paste that from my clipboard. But if I go back over, I can see ‘bearer’ space and the token. Name this ‘Delete Me,’ because that's what I said it was going to be called. I’ll test my connection. Connection has succeeded. So, now you can see that connection, because I’m in the Monitoring Apps Dev space. This relative path will pick it right up. Below that, this application incrementally loads. So, you don't have to pull all of your applications every single time. It'll do it since the they've been last reloaded; which is the only time the metadata actually changes for the applications. I’m just going to put them right in the Data Files for this space. So, you can just do ‘:data files.’ Alternatively, you can store them in S3, Azure, Blob, Google Drive; wherever you store your data. The last one here, we'll talk about in in just a moment. But it's used for troubleshooting, so you can ignore that for now.

But let's go ahead and hit ‘Load.’

 

Does this take a long time to reload?

 

It does not. So, even on some fairly large tenants; we're talking about minutes. This already has the incremental QVDs that you can see sitting in Data Files, so it's only going to pick up you know, a few applications since it's been last reloaded. But I believe on this tenant, which has roughly 100 apps; it's roughly 30 seconds or so. But we're talking minutes.

 

In which space would you recommend this app be in? Should this be in a shared space?

 

Yeah. I always recommend that if an application is going to be published out that it begin in a shared space. It's always easier to start in a in a shared space. And then I typically, as my convention states, I’ll name something you know, ‘REST for App Analyzer,’ and I’ll have my Dev version, and then I’ll have a Prod version of that same connector that lives in my managed space. It's different from a Windows perspective. From you know, having a Dev tier and a Prod tier and a QA tier and a Test tier. In the world of SaaS, you can do that with spaces. So, I usually just qualify them in whatever “tier” they are, and I always use Shared spaces for that.

 

So, what would happen if an app that the App Analyzer is reading from suddenly gets deleted? Would that cause any problems?

 

Yeah, no. It's a great tee-up for this Error Mode. So, from a troubleshooting perspective, 100%. If you're in a very large active tenant, where even if you're doing you know, programmatic testing; that's where it's going to come up, especially within our own R&D tenant it comes up quite commonly there. You might see a ‘404’ or two. And the reason being is: once the application reloads, it does a GET of all applications across the tenant. And then it iterates over every metadata endpoint for every app. Now if one of those apps vanishes in the middle of the reload process, it's going to say ‘Hey! I can't find this application.” Which is a 404. So, once you've configured the app, it's generally considered just a good practice to set the Error Mode to 0 for the application, if you know it's functional of course, to kind of steamroll over those errors as they come up.

Just note that if this is set to Error Mode; and you're steam rolling over those errors. And at some point in time you know, your API key expires. It's going to steamroll over those errors too, and you're no longer going to be able to update your application appropriately. So, in conjunction with that, because this is the other place that the app could fail; when you create an API key, and you set your expiration date for that API key, put a reminder in Outlook or put an alert somewhere that will remind you let's say a week prior to update that API key. So, you don't have to worry about you know, that also causing an error you know 365 days from now right? Or 90 days from now, however long that you set that expiration for.

 

That's a great tip: to put it in the calendar; because otherwise, it just expires and causes problems.

 

Yep. Otherwise, it's going to throw you for a loop one year from today or however long you set it. Guaranteed. Because you won't remember.

 

Are there any resources that admins should be aware of?

 

I have a resources-slide here. I’ll pull up a couple of those pages that I talked about. I just want to hammer this point again. That it is available on community. I’ll go and visit that site in just a in just a moment. But again, it doesn't ship with the tenants; so I suggest that you subscribe to you know, to this post and follow it.

 

So, here's the page for the App Analyzer. You can see that it's actually been up since August of 2020. I believe there have been one or two version changes since. But you can find a demo very similar to the one that just gave on YouTube. You can also find a pretty exhaustive install guide for the app here as well. So, it's going to show you exactly how to set up and generate an API key; how to build out that REST Connection. A step-by-step guide to make sure that you'll be good-to-go for the application. So, you don't just have to go off the script notes. And then you'll see the actual you know. dot release version of the app. I just want to call one other thing out briefly. That the App Analyzer isn't officially Supported by Qlik, but we do have both Product Management, R&D, along with Pre-Sales (including myself) that are following that community entry. If you have issues there, please post them up; even just general feedback. We do look at it. We do address it. You know, we've got many customers that are already using this, and we know that it's going to be critical, so we will Support it you know, to the best of our abilities. But it isn't officially supported, and I am mandated to say that.

 

Can we take a look at those best practices sites you mentioned?

 

Yeah! So, we've got the Diagnostic Toolkit, which has been up for a couple of years now. And quite frankly, some of this is borrowed from the QlikView days, because we're working off the same engine here. What this does is: it gives you - don't have to fill out the top bit - it just exports a PDF if you wanted to. Again, like I said, some of our customers actually do require the output of this in their publish process.

It's these bullets below that can be really helpful as you're validating or you're building out a data model, and each one of these typically has links to relevant community articles. For example, this one actually links out to Rob Wunderlich’s utility. There's a whole bunch of articles that link out, you know, Henric Cronström’s old post. HICs if you're familiar, old posts. There's a lot of really good collated content here in one centralized place. And a bit of interface performance too. But the relevant bullets for the data model perspective are all in this top section here.

 

So, from the Admin Playbook perspective this is a recommended playbook and best practices guide for the Windows platform. There is a lot of overlap from an application perspective. But the reason I’m pulling this up is: we're currently investigating and exploring in 2021 the possibility of building something quite similar for the SaaS platform. You know, this took roughly a year of work to build out for the Windows platform. So, this is more of a ‘I’d keep your eyes peeled for something similar to this in the future from a SaaS perspective.’

 

Okay now it's time for some Q&A. Please place your questions in the Q&A panel on the left side of your on24 console. Dan, which question would you like to address first?

 

Yeah, let's go ahead and start with the first one that I see here. So, does the App Analyzer need to be purchased separately?

 

While it is separate, there is no fee. This is a free application that Qlik has provided to you. Again, while we don't have a strict Support policy for it per se, we will do our best to Support it over time, at least unofficially from a Pre-Sales perspective and a PM perspective. But it is something that we plan to make readily available for the foreseeable feature at no cost that you can import into your tenant and give it a run.

 

The next one here: Is there a version of this app for QlikView?

 

That's a really good question. So, one thing that I didn't call out during the presentation, and if you weren't already aware is: Qlik Sense Enterprise SaaS can host QlikView applications. And the App Analyzer will actually pick up those applications. So, if you're using let's say QlikView Publisher to distribute out QVWs, the App Analyzer will check whether those are you know, under 5 GB in RAM or not, and actually give you metrics about the model itself, which is unique to the SaaS platform, considering that it's you're able to analyze both types of applications. So, good question.

 

I’ve got one here that says you know: I’ve got some large applications in my Enterprise on Windows environments. What do I do with apps that are let's say 10 GB on disk?

 

So, yes. I did bring up that this presentation predominantly was focusing on the standard tier. We do have two additional tiers at this point in time: Expanded Capacity and Dedicated Capacity. Both of those allow for applications that are up to 50 GB in RAM. There is of course you know, an up charge for this, but do contact sales if you are interested.

 

We've got one that is: are there tips for optimizing peak reload RAM?

 

Yeah. I did mention at least one of them which was: you know, try not to use monolithic QVDs. Just the way that Qlik loads QVDs, they can they can take a lot of peak RAM to buffer in. So, it's why generally, we say you know, partition your QVDs. Be that by month; for example, potentially by dimension, because they will actually be easier to consume or less RAM intensive to consume. Also, just trying to avoid you know, massive nested Ifs, egregious usage of you know, auto-number or autogenerate, and things that are kind of notorious for taking a lot of peak RAM that you might be fine with eating in the Windows world. But from a SaaS perspective you know, it might behoove you to seek out alternative strategies there.

 

We've got one that's: will running the App Analyzer itself impact the performance of other apps on my tenant?

 

Good question. For this one, I mean generally speaking, no. Because it's reloading so rapidly. And we don't suggest that it reload you know, more than once a day, quite frankly. You know, it's, this isn't an app that you're gonna have reloading every 5 minutes. You're probably going to be checking it on at most a daily basis. So, I usually suggest running it you know, in your batch window overnight. Additionally, you know, because of the SaaS platform by nature; it's a microservice you know cloud-native offering. So, you're not going to hit the same bottlenecks that you might hit in the Windows world; so, even if you were running it you know every 5-10 minutes, I still don't think it would impact the performance of your tenant.

 

We've got one that is: what are the minimum privileges needed to do this?

 

So yeah. We did cover that that's going to be Tenant Admin and Developer (role). Wou will need Tenant Admin to of course access all of the assets across your tenant, as well as the Developer role so you can get an API key to actually interact with the Qlik APIs.

 

We've got another one that: is this the same as the app for Windows, the Sense System Performance Analyzer?

 

No. However, it does have a direct correlation in parallel with the App Metadata Analyzer for Windows, which is pretty much the same exact data model. That is another application that does again ship with the Windows product. You've got to manually import it into your Qlik Sense Enterprise and Windows site, but it is pretty much identical to this application. Just note that this one is obviously, you know, all of the piping has been redone to work with the Enterprise SaaS APIs. Instead ‘how to get the CPU hit’ and ‘RAM expansion on open,’ in SaaS you won't get the CUP, but you will get the RAM. For the App Analyzer, that's the key metric that that application exposes. And again, that's the key quota that is for the standard tier. That 5 GB is that app open event that's actually a good way of, it's actually the exact event that we throttle with REST Connections where data limits are in place.

 

… pagination…gotcha. So, basically, the  question is: in the SaaS APIs, there are, there's limits on in the amount of data that's returned so you do have to paginate.

 

And yes, if you actually take a look at the App Analyzers load script; on all of my REST calls to get the apps, to get the spaces, to get the users, all of those are set up to paginate by default. So, if there are, let's say, more than 100 apps in your tenant, that will be a minimum of two API calls to fetch all of those; and yes, you can you can use those example scripts to use in your own applications, if you see fit.

 

Is there an application like a License Monitor for Qlik Sense client managed?

 

Great question. And we get asked this a lot. This App Analyzer is the first monitoring application for SaaS, because it is quite frankly, the simplest to port, because of the fact that it's built off of the same JSON structure, the same application metadata that's available on both platforms. It was pretty close to plug and play in our SaaS tenant. That said, we completely understand that you know, user monitoring, adoption, I want to see what applications users are using, what sheets are they navigating to, I want to be able to do things like track expensive objects, absolutely. That is coming. In fact, the latter is coming in the February release, to be able to actually look at performance of individual objects in the application itself from a user perspective.

We are absolutely, product management and R&D are researching the best way to expose those metrics, but we do recognize that you know, that is of course not available in this application. But just to be frank, that's not the intent of this application.

 

Okay Dan, we have time for one last question.

 

Okay gotcha. Let's take, this is a good one: so moving from the Windows platform to SaaS, how do we know if it will fit in standard tier?

 

Really good question. So, we have developed a tool internally. We call them the SaaS Readiness Applications that pre-sales services, a number of different organizations across Qlik can help run on your site. They are just simply; it's a QVF that we can hook up to your site that will do a profile of all of the applications for you, and it will actually, you know, what respective tiers each application would fit in. So please do reach out to your account rep, and we can work with you to run that to make sure that you'll be you'll be as prepared as possible to migrate over to SaaS.

Note on the Readiness app mentioned:

The SaaS Readiness apps are available on the Partner Portal for download. That said, this was built as an internal PreSales tool that was then exposed to Partners. It requires interpretation. There have not been any major enhancements made to this app in a while.

A more complete toolset is now available publicly that incorporates much of the SaaS Readiness app (it was built on top of it) and that can be found in the Migration Center.

Great! Thank you very much, Dan. I think this can be really useful for people.

 

Absolutely! Thank you, Troy for having me.

 

Thank you everyone. We hope you enjoyed this session. Thank you especially to Dan for presenting. We appreciate getting experts like Dan to share with us. Here's our legal disclaimer, and thank you once again. Have a great rest of your day.