Synchronization issues can always be reported to the DataGalaxy Portfolio Support. Before that, depending on the scenario, here's a checklist of things to look out for.
All configuration keys mentioned below are described in the DataGalaxy Catalog connector documentation.
An instance is not created or synchronised
Does the token have the rights to see the instances?
The connector only retrieves the instances that the DataGalaxy Catalog token can see. An instance outside the token's rights is never retrieved.
In DataGalaxy Catalog, make sure that the user or integration linked to the token defined in has access to:
-
The workspaces defined in the configuration.
-
The instance types to synchronize (dictionary, usages, data products, etc.).
For updates from DataGalaxy Portfolio to DataGalaxy Catalog, the token also needs the rights to edit these instances.
Is there a default workspace ?
If no default workspace is defined on Catalog, each instance configuration (each configurationKey block) must have its own workspace. Otherwise, the instances of this type are not synchronized.
Is the configuration valid?
An error in the JSON configuration prevents the synchronization. The mapping section is only displayed once a valid JSON configuration is saved.
Compare the configuration with the model given in the DataGalaxy Catalog connector documentation.
An AI agent can also review the configuration against the official documentation page. Never share secrets with the agent: replace the token and any other sensitive value with a placeholder before submitting the configuration.
Does the instance match the filters?
Only the instances that match all the filters and linkFilters are synchronized, as filters are applied as AND filters. If a few instances are missing, compare them one by one with each filter.
Filters are only supported in flat configurations. Instances already synchronized are still updated, even if they no longer match the filters.
Is a calculated field synchronized in the wrong direction?
Calculated fields can be synchronized in one direction only: from DataGalaxy Portfolio to DataGalaxy Catalog (read mode). No value can be written in a calculated field.
If a calculated field is mapped to an attribute in sync or write mode, the whole update of the instance is blocked, not only this field. If the instance has never been created in DataGalaxy Portfolio, its creation is blocked as well.
Make sure that every attribute mapped to a calculated field is set to read.
Is the parent instance synchronized?
In a non-flat configuration with parentYOOIType set to embedding (default value), a child instance can't exist without its parent. If the parent is not synchronized, for any reason, the child is not created.
Make sure that:
-
The parent instance is synchronized. The checks on this page apply to the parent as well.
-
The embedding field is mapped on the parent concept. Otherwise, no child of this parent is synchronized.
-
The parent and its children belong to the same workspace.
A value is not synchronized as expected
Is the expected direction synchronized?
If a value was not updated as expected, make sure that the mode covers the expected direction. For example, with read, a value changed in DataGalaxy Catalog is never retrieved in DataGalaxy Portfolio: this is the expected behavior.
In addition:
-
When no
modeis set, the default value issyncif the attribute is editable in DataGalaxy Catalog,readotherwise. -
Some attributes are not editable in DataGalaxy Catalog. They are ignored on updates from DataGalaxy Portfolio, even in
syncorreadmode. See Editable attributes in DataGalaxy Catalog. -
Updates from DataGalaxy Catalog are only retrieved at each polling, as defined by the
cron.
Is a field mapped several times?
When several DataGalaxy Catalog attributes are mapped to the same DataGalaxy Portfolio field, a warning is displayed in the mapping. The field can only hold one value: the values overwrite each other, and the value finally kept can't be predicted. For example, with three attributes mapped to a single field, the field only contains the value of one of them.
Make sure that each field is mapped to one attribute only.
Similarly, a single-value relation attribute (ValueList, SystemEntityType) must be mapped either to an n-1 relation field or to a workflow, not both.
Is each configuration ID unique?
Each instance configuration is identified by its configurationKey, which the connector uses internally as an ID. Two configurations sharing the same configurationKey conflict, and only one of them is applied.
Make sure that each configurationKey is unique in the configuration and only contains letters, numbers and underscores.
Out of ideas?
If after all these checks the problem still can't be solved, the DataGalaxy Portfolio Support can help. Sharing the JSON configuration, with the token and any other secret removed, and the name of an affected instance speeds up the investigation.