Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
yosuke-coupa
Partner - Contributor III
Partner - Contributor III

Metadata or attributes that retains on QVF export/import?

We want to associate some custom metadata, such as "version", on an App in QVF format.  For example, we have a QVF file that we import across different Tenants.  We want to associate some kind of "version" like attribute or metadata to this QVF.  Is there a mechanism that would allow this type of information to be included in the QVF?  We don't want to use file name or the App description for this purpose.  

We've tried adding information to the "attributes.cutom" property of an App, but it looks like this information is not retained when a QVF is exported and imported.  

Does anyone have any experience associating some custom metadata or attributes that gets retained within the QVF?

Labels (1)
1 Solution

Accepted Solutions
stevedark
Partner Ambassador/MVP
Partner Ambassador/MVP

Hi @yosuke-coupa 

I see what you are trying to achieve now.

PEEKing the values out of the load script should certainly be possible.

I wondered if there was a way to retrieve variable values using the same API, but variables don't seem to be there as an endpoint (though they are available in Qlik Automations, so it must be possible to get to them somehow).

I didn't find that functionality, sadly, but I did find this:
https://qlik.dev/apis/rest/apps/#%23%2Fentries%2Fv1%2Fapps%2F-appId%2Fdata%2Fmetadata-get

As this gives the table information for the app, you could create a metadata table within the app in the load script and perhaps have different fields as the headers, e.g. Version and then either tags or comments to hold the values.

This is not something I have tried (yet) but it looks like it might be possible.

If you give that a try, please let me know how you get on.

Cheers!

Steve

View solution in original post

3 Replies
stevedark
Partner Ambassador/MVP
Partner Ambassador/MVP

Hi @yosuke-coupa 

You could make use of variables. Simply set them in the load script:

Let vAppVersion = '0.1.2.3';

I tend to populate a number of variables,  such as vLastLoadStart, vLastLoadEnd and vNoOfRows.

These do not appear in the UI by default, but you could have a text object that displays them on a sheet in each app. 

Hope that helps, 

Steve

yosuke-coupa
Partner - Contributor III
Partner - Contributor III
Author

Hi @stevedark,

Thanks for the information.  

That would be OK if we need that type of information displayed on the Sheets.  What we're looking for is something that can be queried by API, such as in the response body of GET /api/v1/apps/{appId}.

I guess if we have an agreed format, we could put the information in the load script as a comment, and retrieve the load script with GET /api/v1/apps/{appId}/scripts/{version}.  Then we can parse the load script and match on the agreed format.  This is a bit hacky, so something "first class" to the App/QVF is preferred, but this may be the only way to achieve what we're looking for.  

stevedark
Partner Ambassador/MVP
Partner Ambassador/MVP

Hi @yosuke-coupa 

I see what you are trying to achieve now.

PEEKing the values out of the load script should certainly be possible.

I wondered if there was a way to retrieve variable values using the same API, but variables don't seem to be there as an endpoint (though they are available in Qlik Automations, so it must be possible to get to them somehow).

I didn't find that functionality, sadly, but I did find this:
https://qlik.dev/apis/rest/apps/#%23%2Fentries%2Fv1%2Fapps%2F-appId%2Fdata%2Fmetadata-get

As this gives the table information for the app, you could create a metadata table within the app in the load script and perhaps have different fields as the headers, e.g. Version and then either tags or comments to hold the values.

This is not something I have tried (yet) but it looks like it might be possible.

If you give that a try, please let me know how you get on.

Cheers!

Steve