Qlik Sense - Visualization Extension - Handling "extension upgrade" and impact on custom properties

[qlikssewarrior]

Hello Qlik experts!

I have built a Qlik Sense visualization extension with a list of custom properties to control the extension behavior. I am setting the default value of the properties in the property definition code as follows - 

var chartProperty = {
  type: "number",
  label: "Chart Property",
  ref: "myProperties.chartProperty",
  defaultValue: 12,
  min: 0,
  max: 100,
  show: function (data) {
      return data.myProperties.showChartProperty;
  }
};  

Now, after I have deployed this extension at customer site, I have been asked to change the default value of this property from 12 to 2. I updated the code above with "defaultValue: 2", built and redeployed the extension on qlik server, however the default value on the app stays at 12. 

Does anyone know why this is happening. While testing locally (on Qlik Sense Desktop), I noticed the default value changes to 2 only when I remove and re-add the extension from my app. This is an unacceptable solution to our customers.

Does anyone here experienced this? Any guidance for how I can handle this in the extension code? Does Qlik visualization Extension development has any best practices or guidelines for handling extension upgrade scenario for existing apps that may be using the extension?

Thank you! 

[Damien_V]

Hello @qlikssewarrior 

That is ecpected, that is the default value.

Once the extension is added as an object in an app, the value will be saved for the object, so even if you changed the default value in the extension, it won’t change for objects already added. 
You would need to find out in which apps the extension has been added and use the Engine API to update object properties if you want to automate the process of resetting that value for already existing objects.

[qlikssewarrior]

Thanks Damien! Do you have any references or examples for how to automate property update process using Engine API? I am a novice with Qlik development, and this sounds like a complex task to me. 

Thank you! 

[Damien_V · Accepted solution]

The complex part is to find in which apps that extension has been added, as extensions are just considered generic objects and there is not a clear distinction from a Qlik Sense API perspective to find out which app uses which extension. I remember there are 3rd party solutions to do that, I would need to find the link to it, if that can help.

When it comes to using the Engine API to update the properties of the object, you could use enigma.js to connect to the Engine API and call the SetProperties() method towards the object 

https://help.qlik.com/en-US/sense-developer/February2021/APIs/EngineAPI/services-GenericObject-SetPr...

The easiest to find out which parameters and format you need to sent them in, would be to perform the action in the app manually and look into the browser devtools network tab inside the websocket messages what are the parameters for the API call sent.

Here is an example on how to use enigma.js (You would need to adapt it for your use case):
https://support.qlik.com/articles/000077843

[qlikssewarrior]

Thanks @Damien_V ! While I have you here. Is there a way to store a custom configuration (string) that I want to maintain/store with the app, so it maintains the value in between extension refresh? like a property on the Layout object? Similar to the custom property values, except this configuration is not exposed to the end-users.      

[Damien_V]

Hello @qlikssewarrior 

If you don't want the value to be configurable by the end user, what is the point of defining it as a default property instead of just hard-coding the value in your extension javascript code ?

[qlikssewarrior]

Good question!

The custom configuration is the API payload that I would like to store/persist, so If the user updates the chart properties that do not effect the API payload (for example, chart color, text size etc.), I can compare the newly calculated Payload to the previous Payload and decide If I need to call the external API again or not. This would be a huge performance boast, because currently, the extension calls the external API regardless of what property is updated by the user. In my extension, most of the custom properties are UX controls (that don't require an API call).

Thanks! 

[Damien_V]

I would tend to think, that if that specific value is not meant for end users to change, but you would still like Admins to be able to modify it by changing a setting file on disk, you should move it out of the ChartProperty variable.
That would pretty much depends how you want to implement it.

Maybe some other people that have created similar extensions would have other ideas about it.