Hi all, we are encountering an issue with import/export. Exporting and then importing a workspace results in:

Some of given referenced 'datasets' entities do not exist. Not existing IDs: [Identifier(in_dest_end)/Workspace(56d66ea8beed4144b7c20a76c4a49015)]

During investigating it I've learned: • there is a ref to the "in_dest_end" dataset in a visualizationObjects ◦ E.g.: model.analytics.visualizationObjects[x].content.buckets[0].items[0].measure.definition.measureDefinition.filters[0].relativeDateFilter.dataSet.identifier.id == "in_dest_end" • The visualizationObjects is not referred to from any widget • On the UI, in edit mode, it does not appear under

Saved Insights

(where all the other visualizationObjects are enlisted) So: • Probably the "in_dest_end" dataset was once present, but got removed • There is no way to resolve the reference error on the UI • The API, AFAIK, has no switch to filter out invalid refs during export Update: • Also had another workspace with some more erros: ◦ Two metrics containing an invalid label. ▪︎ These, as being invalid, are not listed in the Metrics UI. ◦ It has 3 dashbaords in the export but only 2 in the UI. ▪︎ The missing dashboard containing a widget referring to some broken visualizationObjects • Once I manually removed the broken parts, the json was successfully loaded. Let me know, if there is a better place to report bugs, if you need any further info/context, and if there are any suggestions on how to fix/avoid this. Thanks

Hi Vajk, thanks for sharing your experience with this known behavior. We would like to change it in the future. We would appreciate your proposals of how it should work to provide optimal developer experience. What is technically possible on our side (APIs): • Add a new HTTP header into export layout APIs to force export of only valid objects. The export would be slower because we would have to validate all objects. • Provide a new layout APIs exporting only valid objects • Add a new HTTP header into import layout APIs forcing ignoring invalid objects NOTEs: • you can utilize HTTP header X-GDC-VALIDATE-RELATIONS with entity APIs (e.g. /api/entities/workspaces/<id>/analyticalDashboards to list invalid objects, they contain attribute areRelationsValid determining if objects are valid. • In the next release (March) we are going to extend dashboards UI so dashboards are displayed even when they contain references to no longer existing or invalid insights. We want to improve our UI apps in this area further, any proposals from your side would be very appreciated.

Thank you Jan! Yeah, the pain point is to be able to quicky clone our prod to staging for debugging. Being able to run an automated export-import step. Tech-wise another option would be to allow importing the data as-is (with the broken referneces). Yeah, suboptimal, the overall direction I guess is minimizing invalid state, not adding more, BUT this would also make the export-import operation seamless. The entity API based X-GDC-VALIDATE-RELATIONS trick is neat, but sadly does not sound like a feasible approach, would need to review how to build the layout API response from the entity calls, could require anywhere between 4 to 16 hours, sounds like too much fuss. Displaying the error messages on the UI is gonna be a great addition, waiting for that to roll out. Is there any chance to receive API updates in the next release that would enable the automated export-import experience? All of the options you enlisted as technically possible sound great to us.

It seems the GDCN app hides any objects (metric, insight, dashboard) with invalid state. The invalid state seems due to breaking LDM changes. Some additional suggestions: • Warn/prevent breaking LDM changes • Show objects in broken state, and allow correction (deletion, or update reference to a valid LDM property) Otherwise, +1 to what Vajk said. Jan, your comment of "Add a new HTTP header into export layout APIs to force export of only valid objects" seems like an intuitive design.

@Ondrej Macek please, adopt above feedback into our roadmap 😉

Vajk & Carson, thanks for sharing the feedback. We will discuss internally and assign to backlog within reasonable timeframe as convenience of working with GD.CN API layer is a priority for us.

🎉 New note created.