I value this quite high. Being part of the 2016 Luminary program too, I know how much value it brought both in terms of great networking opportunities with fellow Luminaries (and others), as well as more and closer contacts with Qlik themselves.
The one thing that makes Sense stand out (IMHO) is the fact that it is a very solid platform, on top of which you can build all kinds of interesting apps.
Qlik’s own user-facing standard Sense client is great, but there are for sure times when you want something else. The APIs very nicely enable that kind of development.
On the other hand, with so much great work happening in the open source field (around back-end technologies, visualisations etc), it is also extremely promising to see Qlik open sourcing some of their tech.
2017 has indeed started in an interesting way for Sense, can’t wait what’s in store for the rest of the year.
For a long time I wanted to learn more about client side development.
Javascipt, CSS, reactive frameworks etc – all those concepts that make today’s web sites tick. I really think backend developers can benefit from having at least a basic understanding of how the front-end works – this will make the finished app better as a whole.
I worked on a small node.js server during the past couple of weeks. The idea came from the fact that
I over and over again find myself creating Sense apps that are almost identical, and
people starting out as Sense developers spend too much time learning the basics. I wanted to bootstrap their learning process by providing well written skeleton apps for them.
This could of course be achieved by just duplicating apps using the QMC, but it would be way better if there was a nice little web app that listed the available Sense app templates, and allowed anyone (with permissions to create apps) to create new apps based on them. Or maybe this feature could even be integrated into one of the different Sense hubs that are now available…
One of the recent versions (3.0? 3.1? 3.1.1?) of Sense added much improved syntax color coding of the load scripts, as well as autocompletion of function names, field names, variables etc.
What might seem like a small change is at least to me super, super useful. I can suddenly keep my hands on the keyboard, and don’t have to switch to another browser tab to check in the app data model to check the exact name of some field – I just type a couple of characters and a list of suggestions pop up. Productivity is up and frustration down – that is a very good combo.
Real-time monitoring of failed reload tasks, with notifications sent as emails, to Slack channels and as MQTT messages
Starting Sense reload tasks from the load script or from external systems, using a REST API
Posting messages to Slack from the reload script. Great for sysadmin notifications as well as notifying end users that new data is available in an app
Sending MQTT pub-sub messages from the load script
Get full metadata, including load script, for any app
Getting free disk info for the Sense server
All in all, Butler 2.0 includes a set of features that offers greatly enhanced features for anyone involved in the operation of a Sense Enterprise environment.
Butler is available via Qlik Branch, with all source code hosted on GitHub. Documentation is available on github.io. That documentation is the best starting point for learning more about what Butler does and how to use it.
Some sample screen shots shows what is possible to achieve:
I recently investigated a strange behaviour of the Qlik Sense REST connector, where it would become slower and slower executing REST queries, the longer the server had been running. RAM or CPU consumption was not unusually high, but something was clearly eating away some kind of resources from the system. Turned out it was disk access that was the bottleneck.
The goal of the previously described Slack proxy project was to allow posting of messages from Qlik Sense load scripts to Slack (great instant messaging platform!). The project has however developed into something larger and slightly more ambitious, integrating other connections than Slack. The original project name “Slack proxy” has become less and less relevant, and the project has thus been renamed to “Butler”.
As of right now (May 2016), Butler’s feature set include
Send messages from Sense load script to Slack
Send/publish MQTT messages from Sense load script (i.e. outbound MQTT).
Sense reload failures as emails, and to Slack.
Sense audit events (session start/stop and connection open/close) to Slack and to MQTT messages.
Create new directories on the Sense server’s (where Butler is running) disks.
Get disk space info, for disks on the Sense server where Butler is running.
With so much cool data available online, tools like QlikView and Sense becomes real Swiss Army knives of data integration.
Pull in some data from company internal databases, some data from previously created QVDs, and more and more commonly also from various online sources, both public and private. Depending on how you call those online APIs you might get away with just sending in query parameters as they are, but in other cases – and this is especially true if you need to send more complex text strings to the API – you need to URL encode the query parameters.
Over the years I have run into this numerous times, but the other weekend I realised it’s actually very easy. Just create a mapping table using an online source for the utf8-to-URL encoded mapping, then use MapSubstring to convert each character in the URL parameter to its hex counterpart.