Datahub issue after Mx10 Migration

0
Hi everyone, I'm currently migrating an application that exposes an OData service to Datahub. Upon the migration, I instantly got an error in Studio Pro concerning my exposed service, saying that "The exposed name cannot be the same as the exposed name of the containing entity." This is because my entity "Country" has an attribute "Country", and it happens that this attribute is the key for the service.   So I could follow 2 approaches: Change the name of the exposed name of the attribute to "Country_" for example Change the name of the exposed name of the entity to "Country_Entity" for example   I tried approach 1 and once I ran the application that is consuming the service, I got an error saying "Removal or rename of attributes in external entity key for entity 'Country' is not supported" -> precisely because I changed the key attribute's name, so this option is a no go;   Then I tried approach 2 (change exposed entity name) and after updating the service I got an error saying that the previously named entity no longer exists. Studio Pro doesn't allow me to replace it, the only workaround is to delete the previous entity and add the new one from the updated service. Problem is that I have internal entities associated to this external entity, and if I add the new one then it breaks the association.   This means that in order for everything to work, I would have to do 2 deployments -> the 1st, to store the keys in a separate entity; the 2nd, where I finally update the consumed service and after deployment I set the association to the "new" updated entity.   I'm trying to avoid this approach of 2 deployments, but I cannot see many other options to do this.   Did someone already have this issue, and did you find a different workaround?   Many thanks!
asked
1 answers
0

i would suggest to keep the existing version without any changes and publish new version with the correct name by changing the entity exposed name (provider-side), as a versioned service Instead of renaming the entity inside the same service and breaking all consumers.

 

Provider app

  1. Keep existing service as v1 (unchanged) so current consumers keep working.

  2. Create a new v2 published OData (new base path/location) and publish the same entity with:

    • Entity exposed name: Countries (or CountryEntity whatever)

    • Key attribute exposed name stays: Country

  3. Publish v2 to Data Hub.

This aligns with the exposed-name rule and avoids breaking existing consumers immediately (because v1 still exists).

 

Consumer migration without “2 deployments”

You still need to import v2 and map, but you can avoid the painful “break associations” move by doing a bridge approach:

Consumer app

  1. Import v2 external entity alongside the old one.

  2. Create a small persistable “bridge” entity like CountryRef(key) and associate your internal entities to CountryRef (not directly to the external entity).

  3. Populate CountryRef keys from the old external entity once.

  4. Switch the lookup/use to v2 external entity using the shared key.

 

This is basically the same idea as your 2-deploy plan, but you can often do it in one release window because you’re not deleting the old entity immediately - just running both until cutover.

answered