Java MS SDK MicroserviceSettingsService vs Tenant Options

Forum
, , , ,
1

Hi guys,

I need some help in understanding the behaviour of tenant options together with the MicroserviceSettingsService of the Java MS SDK (2025.78.0).

If I define a setting in the settings array in the cumulocity.json like this:

{
  "key": "myAppSettingsKey",
  "defaultValue": "50",
  "editable": true
}

and deploy the MS to Cumulocity, this setting is then available as tenant option:

PS> c8y tenantoptions get --category dtm --key "myAppSettingsKey" --raw
{
  "category": "dtm",
  "key": "myAppSettingsKey",
  "self": "https://t488540.dtm-dev.stage.c8y.io/tenant/options/dtm/myAppSettingsKey",
  "value": "50"
}

Now I can query this setting in my Java Microservice using the MicroserviceSettingsService.get(String key)/getAll() methods - this works well. At least until someone deletes the tenant option: c8y tenantoptions delete --category dtm --key "myAppSettingsKey"

Now (or better: after the 10min “lazy caching”) the MicroserviceSettingsService does not know this setting anymore. I would expect the MicroserviceSettingsService to fallback to the entry in the cumulocity.json.

Is this a misunderstanding or how is the microservice supposed to get the default value of a setting if it has been removed from the tenant options? Or how can someone reset a previously updated tenant option to the initial/default value if deleting the tenant option is not the right way?

I’d be happy to get some insights into this topic.

Best Regards,
Michael

2

My assumptions are that the settings are created on microservice boot. So if you delete a tenant options without re-starting the microservices it will not fallback to any default values.

So what you need to potentially do is to re-subscribe the microservice after you have deleted the tenan option setting. I think it will be re-created with default value during boot.

The real question is, in which cases do you think the tenant options should be deleted (and not updated) or reset to default values?

If you want such behaviour in your microservice I think you need to implement it as part of your microservice:

  1. Provide an REST endpoint that defaults the value on request (instead of deleting it).
  2. Updating the value in the tenant options

Deleting that setting directly via tenant options API and not microservice API should be considered as somehow unsupported.

3

Even after re-subscription of the Microservice, the tenant option is not re-created! Therefore if a tenant option is (accidentally) deleted, there is no (easy) way to get it back.

If a customer wants to test a different value of a tenant option for a Microservice and later go back to the initial/default value, he would need to remember the default value or ask the C8Y support. Is that the intention and communicated to the customers?

Wouldnt it be a good idea to improve the Microservice SDK by letting the MicroserviceSettingsService use the default values from cumulocity.json if a tenant option does not exist? Furthermore this would allow the Microservice implementation to be simplified as it does not need to handle missing setting values - the value either comes from the tenant option or from the cumulocity.json.