Hi Dojo,
when using GQI queries that are linked to element data (parameters & table data), it seems the element references (DataMiner ID / Element ID) are being stored inside the Low Code App json file.
When we transfer apps from staging to a production environment for deploying/releasing, we have to either reconfigure the LCA, or modify references in the json file.
This works, but feels a bit cumbersome. Do you have any alternative suggestions that might make it easier?
Thank you!
Transferring apps is currently not supported by the software. So the only way to transfer an app now is to do a manual copy of files, which means all source IDs (which is the only way to store a reference) could be invalid on the destination.
I’m afraid this cumbersome manual step is the only way for now, until we support transferring apps (export/import) in the software. I think an import should give a prompt to pick a value for all fixed unknown variables (elements, scripts, …) it detects.
That would work… But I’m not the one who will advice anyone to do this. Manipulating the json files through “3rd” party is not something I encourage. I’m more in fond of raising a flag to bump the priority of this missing feature in the software. But I understand your urge to just move on… so yes, it will work as long as the script is compatible with the software.
Hi Gilles Bara.
It is clear the workarounds are not supported by Skyline. The preference is to remain supported by Skyline with any process between Staging –> Production setups as advised.
May you add a link to the feature so it can be tracked and provide an estimated time for delivery. This will help in managing expectations and unsupported workflows in due course.
The feature is added to the roadmap https://solutions.skyline.be/app/28db6478-e2dd-4d5e-8726-a7ce2a487764, as “Dashboards/LCA portability”. There’s no documentation available yet.
Thanks. In the meantime we also have a way for some low code apps to workaround this element reference mismatch, and that is to go for GQI queries that are based on “Connectors”/”Protocols”. That way no need for a element reference. Note that for the data sets where multiple elements are present, the use-case might not be fully suited…. Looking forward to that new DM feature!
Hi Thijs,
It’s been some time since I was looking at this, but maybe it can help you further. Can you try to use the following tool (Low Code App Editor | Catalog) which helps you to export and import apps. Since this is a script in the background, possibly logic is applied to overcome this and, if not, maybe the script can be updated with the logic. You can find the repository here: SkylineCommunications/Low-Code-App-Editor.
Kind Regards,
Jarno
I would like to raise awareness though that this is not an official tool and LCA will not guaranteed to be backwards compatible with this.
Indeed, this comes with a disclaimer. It was created as we often needed this functionality, as many environments have both Staging and Production setups. This will be particularly interesting as well with a DaaS setup.
Note that in our case, the Low Code App is part of a solution package.
So we are more interested on how to dynamically configure element references on deployment. not necessarily to manually export/import.
Thanks Gilles, as we are deploying the LCA via ‘application packages’, do you agree with the suggestion that we use the “custom part of the install script”, to alter the “json” file and replace for example the known placeholder with the actual element reference of the element in PROD environment?
After doing this change to the JSON file, we would then also trigger the command to “force-sync that file in the DMS”. I’m assuming this could work right?