When relying on various Node.js services (e.g. Butler SOS, Butler, App Duplicator etc), you quickly run into the challenge to ensure all services are always up and running.
A failing service might be fine, as long as it is quickly restarted in a predictable way.
A concrete example could be Qlik Sense or QlikView apps that send status messages to Slack during the execution of their reload scripts. Those messages will fail if Butler is for some reason not running.
This leads us to the conclusion that the services must automatically be
a) started when a server is rebooted, and
b) restarted if they for some reason terminate/die.
Enter process monitors.
At their core, process monitors ensure that the desired processes are always running, i.e. bullet b) above. Some process monitors also offer additional features such as zero-downtime restart of services, memory and performance profiling of the monitored services, being able to monitor different kinds of processes (not only Node.js ditto).
Adding to the pain is the fact that Sense and QlikView runs on Windows servers, meaning that all those great tools available on Linux cannot be used.
Looking at Node.js specifially, I have found two process monitors to work well on Windows: Forever and PM2.
For some time I have been thinking about how to improve the Sense development process as a whole. There is a lot of gathered experience and best practices from the wider software development community, but how can we apply this to Qlik Sense development?
I think more can be done though.
Looking at the concepts promoted in DevOps, it struck me that Sense development follows about the same phases as those in DevOps. Combining Sense and DevOps of course gives us….
The more I looked at it, the more I felt “wow – SenseOps really rocks!”
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.
This obviously means that the apps name – “slack_proxy” – is not really that relevant or correct any longer… And with more end points considered, the name will become even less correct…. Oh well – I’ll keep the name for now – maybe it will change sometime up ahead.
One of the great things about both QlikView (QV) and Qlik Sense is their integrations with other systems. Given the native connectivity to any ODBC source, web pages in general, Salesforce, REST APIs, BigQuery etc – combined with the dozens of connectors provided by tools like QVSource – I have yet to find a single system or data source we could not pull data from.
The great thing about this is that it makes it easy to quickly get some real data and then start building your application.
That said, sometimes you need a limited data set to start with, or just some conceptual data to try out an idea on. Enter online test data generators, which can be used to generate test data for
I finally got around to start using GitHub Gists a bit more systematically for storing useful bits of code. Going forward I will post useful, reusable pieces of Qlik Sense and QlikView code there. My own experience tells me there is tons of time to be saved by reusing existing code rather than writing it from scratch each time..
IMHO GitHub could improve the gists concept by adding tags to them, that way it would be way easier to find relevant gists. Or I’ll move to some other tool if/once I find it… Any suggestions on good ones? Leave a note in the comments!
Slack has only been around since August 2013, but I would definitively say it’s one of the better team communication services out there. The web client is great, and the OSX and IOS clients are truly awesome. It integrates with tons of other services, including Dropbox, GitHub, IFTTT, Jira, Google Drive, RSS, Nagios, Yo, Twitter and Pingdom are just some of the services it supports (as of today they seem to support ca 75 integrations). There are also generic connectors for incoming and outgoing webhooks, especially the incoming webhook feature will be interesting from a systems monitoring perspective – it will allows us to post messages to Slack by just calling a certain URL.
In this post we will look how we can use this to both monitor the various QlikView services, as well as monitor the transfer of files (e.g. data files used by QV) to a QV server, and a as a generic way of sending notifications from QlikView Management Console (QMC).
Most of the concepts below also apply to Qlik Sense, of course.