It is very disheartening when after importing or deploying dashboard (or LCA) into a new system some components are stop working. This can happen for a multitude of reasons, such as the components being linked to element IDs that are not available in the new system.
To the question Exporting Dashboard from staging to Production – DataMiner Dojo, Wim replies: “Note that the ImportDashboards has been made to import dashboards that are made in such a way that they can work on any DataMiner system. Copying over dashboards that were created on another DataMiner cluster might contain references to element IDs etc that are not available on the DataMiner cluster you’re importing it.”
I’d like to know what are some best practices (Dos & Don’ts) to follow when building a dashboard or LCA that will be transferred to other systems (via package or import). How to create them in such a way that can be used across different systems with minimal or no changes?
Thanks in advance for your responses.
Hi Miguel,
It’s always unfortunate when a deployment fails, and as you mentioned, the reasons can vary widely. Fortunately, there’s a solution for most of these issues.
Take IDs, for example. A general recommendation would be to use feeds instead. Suppose you have an element you’d like to work with. You could display the elements of a specific protocol in a dropdown, then use the selected value in your dashboard. This approach avoids relying on IDs, as the selected element is automatically filtered based on the protocol.
Additionally, we’re actively working on documenting these best practices, while also adding more tools to the core software. These enhancements will facilitate smoother integration with CI/CD pipelines and improve the portability of dashboards and low-code applications.
No ETA as far as I’m aware. We’ll make sure to place an update here once it’s available.
Thanks Sebastiaan, I look forward to reading the best practices documentation. Is there an ETA for its publication?