All good things must end

IKEA store. Not really where I worked.

After more than two years at IKEA, my work with them has now ended. It has been a fantastic journey, with the introduction of a global Qlik Sense dashboard with support both for desktop and mobile and a set of Qlik Sense extensions with the IKEA profile and covering their needs (well, perhaps not everything, but quite a lot of them). I am very happy to have been a part of this, I think we have been able to do amazing things.

My work at Qlik continues. The Advanced Authoring project moves forward, hopefully you will see some really interesting stuff in upcoming Qlik Sense releases. Looks like I will continue helping them a few months more. After that I’m not yet book, so if you ahve an interesting project starting after the summer where you need help with Qlik Sense development, please let me know.

Apart from that I’m in some discussions about other work in the Qlik Sense area And of course, I’m preparing for Master Summit in Stockholm!

Masters Summit in Stockholm

Stockholm is beautiful, and April is a very good time to visit

I’m really happy to be guest speaker when Masters Summit for Qlik comes to Stockholm in April. For those of you who have not heard about Masters Summit, you should really check it out. I took part in Boston in 2017, and it was truly a great event.

API track

In Stockholm they are adding an API track, for developers working more with build applications, mashups and extension using Qlik Sense API’s and Qlik Core. Great content and led by people that really know what they are talking about. And with me in a short session on Qlik Sense use of web sockets….

Registration is here. See you in Stockholm!

Alternate state support in your extension II

A while ago I wrote a small post on how to add alternate state support to your extension: https://extendingqlik.upper88.com/adding-alternate-state-support-to-your-qlik-sense-extension/

I am happy to tell you that with Qlik Sense november 2018 this is now obsolete. In most cases you don’t need to do anything to have alternate state support in november 2018, it will work out of the box. For example the wordcloud extension:

You will get a new section in the property panel where you can set the state to use. The default setting, ‘inherited’ will mean that the chart will inherit its state from it’s parent (currently the sheet), but you can also specify what state you want.

November 2018 also includes support for managing alternate states and the selection toolbar shows selections for all

 

Qlik Sense november 2018 – with qsVariable

One of the new features of Qlik Sense november 2018 is the bundled extensions. If you install the bundle that’s included with the release (and I think you should) you will get a couple of extensions, one of them based on my qsVariable:

Based on, because Qlik has renamed it and made some modifications. Since it has a new name your existing apps that uses qsVariable will continue to do so, you will need to convert them to use the bundled version: You should probably do so, since Qlik will maintain the new version, and test and possibly fix it for new Qlik Sense versions.

 

Limit the number of rows in your Qlik Sense extension

A common mistake when you start with Qlik Sense extensions is to forget about setting Initial data fetch in your extension. Typically you would include something like this in the initialProperties of your extension:

That would work, and make sure your extension gets the 500 first rows of data in the layout provided to your paint method. But sometimes you want the app developer to be able to set the number of rows fetched. In that case you can simply add the qHeight parameter to the property panel like this:

And the result is a new section in the property panel, where the app developer can set the number of rows initially fetched.

 

My best advice to Qlik Sense extension developers

When you work a lot with something you develop opinions about how things should be done. Here is my list, after two years as an independent contractor, mainly with Qlik Sense extensions and mashup, and of course based on my experience from Qlik.

Git is the industry standard for version control, and it’s free.

1. Use version handling

There is no reason not to use version handling of your code. I use Git for everything, but if you are still using something else, that might be OK too. You probably should consider switching to Git, but as a developer that might be a decision taken over your head.

The benefits of using version control are enourmous. You can easily go back and find the reason behind a bug or the implementation behind that feature the customer now wants in another extension too. Invaluable!

You also should keep a version number in your qext file, and change it every time you deploy a new version. The main benefit of this is that you can see what version of your extension is in use in a Qlik Sense installation. I have described how to do this in a previous post.

2. Always test your extension in a browser

The developer console is an excellent tool for extension development. You use it to debug your javascript code, to inspect the HTML and CSS and to analyze the network traffic, including the web socket traffic. It can also be used to turn caching off, so you know that you are running the latest version. The browser included with Qlik Sense Desktop is not of much use for extension development. Even if you can open the console, it’s an environment your users do not use.

3. Stay in your sandbox

The extension framework gives you a HTML element for your extension. Stay inside it, unless you have very good reasons not to do so. That goes both for your javascript and CSS.

  • do not inject HTML elements outside of your own element
  • prefix your CSS rules so that it affects only the extension
  • scan only your element, use $element.find() rather than $(), or element.querySelectorAll rather than document.querySelectorAll
  • avoid html id’s, since they must be unique within the page. If you must use one (really only when you use a library that needs an id) make sure they are unique for each extension instance (test with multiple instances of the same extension)

There are occasions when you need to break theses rules, but only do it when it’s need for your extension functions.

4. Use modern development tools

Pretty soon after you have started with extension development you will grow out of the Qlik Sense dev-hub extension editor. A modern, nodejs-based environment, with a good text editor gives you a lot of benefits, and works well with version handling software. I would recommend the following:

  • a good editor. I mostly use Visual Studio Code, but there are others that probably are just as good.
  • a CSS preprocessor like less  helps you with prefixing css, add vendor prefixes etc
  • a lint tool, to find common errors an enforce good programming practices
  • possibly a preprocessor, to allow you to use modern javascript features and still work on older browsers

5. Always keep your extension backwards compatible

After a while your users will most likely want more functionality in your extension. They might want more interactivity, more rendering options, perhaps support for more dimensions and measures. You will probably add new settings giving your extension more flexibility. You might also find that some of the stuff you originalyy programmed was not perfect (that happens to all of us..).  But if you have deployed your extension to production, make sure that all your changes are backward compatible. If you don’t you will have huge problems when you deploy the new version, with breaking apps.

If you find it impossible to make your new extension backwards compatible you probably should not be making a new version, but a new extension, with a different name.

6. Base your rendering on only the layout

The model behind Qlik Sense extensions (and the built-in charts too, actually) is that the extension is based on a Generic Object, where you configure the Generic Object in the property panel and use the layout for rendering. Stick to that model, do not break it. If you need more data for your rendering, add it to the properties structure. Avoid:

  • creating HyperCubes and ListBox objects programatically, add them to initialProperties and the property panel instead
  • fetching variable values programatically, add expressions to the property structure instead (that also gives the app developers more options, like hard-coding values, or making them change automatically as selection state (or data) changes

It is however OK, even recommended, to call API methods for:

  • showing lists of available values in the property panel
  • making selections etc when the users clicks on buttons, menues or other parts of your UI

I have written on this before here and here.

A third way to run a reload from a Qlik Sense mashup

Back in 2016 I wrote a post on running a reload from a Qlik Sense mashup. To recap, I described two ways:

  1. call the Engine API method doReload(). Use this in Qlik Sense desktop, since it’s the only method available.
  2. use the repository call App reload optionally with the help of the callRepository method. This is of course only relevant in a server installation.

You’ll find code examples in my original post, and also how to know if you are running in server or desktop.

What happens when you use /app/reload ?

While this method works well in some scenarios, like when you just want to run one reload of an app ASAP, it has some limitations. Behind the scenes Qlik will create a very simple task for you, and try to start it immediately. The task will look like this:

Very basic, just an app, a name, an the default Task session timeout of a day (or 1440 minutes). No triggers, since the task is started by the REST call, no tags, no custom properties. And, perhaps most important, no retries. This means that if you create a series of reloads this way, most likely only the first few will succeed, the rest will fail since there is no engine instance available.

Another method to start a reload

But there is another way to do it. You can easily create the Task yourself, and set whatever parameters you need. Qlik Sense QRS API is really easy to work with, and the callRepository method can help you by fixing the xrfkey and wrapping the call in a javascript Promise. So creating a reload task can be made as simply as this:

This will create the reload task the way we want it and return the id for the task, whish we can use to start it. That’s just another call to the Repository like this:

And that’s it. A little more code than the second method, but much more control over what we get.

How to find out what extensions and versions are installed on your Qlik Sense server

You have been running Qlik Sense for a while in production, with multiple apps, some extensions and mashups. Or, you are just starting to work on a Qlik Sense site, where you don’t really know what has happened before. And perhaps the extensions you are using in development are missing or they seem to be of an older version. How do you find out what is on the server?

Whenever you are running Qlik Sense, whether it’s the standard built-in client or a mashup, the client will call the server to find out what extensions (including mashups) are available. This call has the format:

https://[server]/[proxy]/qrs/extension/schema (+ xrfkey in server installation)

Dump of the extension list, taken from Chrome developer console

The reply you get is in JSON format, and contains all extensions available with their id (the qext filename) plus the contents of the qext file. It’s quite readable and when you look at it in the developer console you can expand the lines you are interested in.

This will give you the extension version number, provided you keep a version number in the qext file, which of course you do.

 

Some useful patterns for your Qlik Sense extension property panel

Building a panel

The property panel is a key part of your Qlik Sense extension. The aibility to set extension properties is what makes your extension both reusable and flexible. At the same time your options are much more limited than in the rendering part of the extension. And since this is Qlik Sense specific all of it, there is not so much information and examples available on the internet. So here are some patterns and techniques I find useful in extension development.

1. Use expressions always

Strings in the property panel can allow Qlik Sense expression by setting “expression: ‘optional’ “. Use that – always. This allows the app developer to use expressions for the property and thereby make the property dynamic. It also allows the app developer to reference a variable and use a variable extension to allow the end user to switch values for the property (horizontal/vertical for example).

It allows the app developer to use an expression, but doesn’t force her. Still a fixed string can be used, and probably will be used. And the good thing thing is you don’t have to bother about that in your extension code, you get this flexibility for free.

2. Dropdown with custom alternative

Sometimes you have just a few possible values for a property, or you want to help the app developer with a list of common values for a property. The dropdown component is a good choice for that. But you risk loosing the flexibility of the expression: the dropdown will only make it possible to select a value at design time, no possibility to make it dynamic or affected by a variable. Or the list is really not a complete list, there are alternatives for the more advanced app developer.

In those scenarios you can combine a dropdown with a separate field that allows expressions like this:

  • create a dropdown with your alternatives
  • add a ‘custom’ alternative to the dropdown
  • add a field with expression: ‘optional’ for the custom value
  • give the field a show function, that returns true if the selected value is ‘custom’

In your extension code you will need to check for custom values, something like this:

var width = layout.width === ‘custom’ ? layout.customwidth : layout.width;

3. Add properties to dimensions and measures

Sometimes you need a property for every dimension or measure. In that case you can extend the built-in dimensions and measures objects by adding new properties. You do this simply by setting the items property to the properties you want to add, and Qlik Sense will merge the default properties with the ones you hav defined. An example:

Note that the ref should begin with ‘qDef.’. That will mean it will be part of the measures property. To the app developer your roperty will look just like the built-in ones. You can do the same thing with dimensions.

Adding alternate state support to your Qlik Sense extension

One of the more advanced feature in QlikView is alternate state. It alllows you to have several different selections active at the same time. With set analysis expressions you can then combine your selection sets to gain valuable insights.

While alternate states are not exposed in the built-in Qlik Sense client, you can easily add them to your custom extension with just a few lines of code. Let’s see how.

Step 1: add a property panel field

The qStateName property already exists (check the Qix Engine API), so a first step is to map it to the property panel. Lets create a new section under “Addons”:

This assumes a HyperCube, $ is the default state which is always there. This is already enough for alternate state to work in your extension. If you enter a valid alternate state name in the property panel your extension will be connected to it. Problem is there has to be an alternate state in the app, and you need to know it’s name. Lets do something about that.

Step 2: add a listbox with existing alternate states.

Lets convert our property panel to a dropdown list, where the app developer can choose what state the object should be connected to. We do this by setting the component to ‘dropdown’ and adding a function to return the options:

Alternate states ar listed in the app layout structure, so we need to get the app layout and format the states in the format the property panel dropdown wants. The default state ‘$’ is not in the list, so we need to add that ourselves. For this to work you need to have the qlik module available in your extension.

Now you will have a dropdown list in your extension property panel, something like this:

Still doesn’t look much, does it… But it does it’s job. Now we just need a way to create those alternate states.

Step 3:Creating the alternate states

Well, actually you need to do this first. But there are different ways to achieve this:

  • there are extensions for this
  • you could do it in Engine API explorer, since its really a one-time thing
  • or, you could add it to the property panel.

The property panel is not really meant for this, since we are not updating the object properties, but the app properties, but still it’s pretty easy to do. You can add something like this to the property panel:

It’s really not more complicated than that. You will get an inputfield in the propertypanel. If the user writes anything in that field, an alternate state will be created. It will then show up in the listbox, so you can use it in your extension.

Conclusion

It’s really not at all difficult to add alternate state support to your extension. Probably you should do something to show the user that this chart belongs to an alternate state: you can use the header for that, or add some styling or an icon for charts that are in another state. I’ll leave that for you.