· May 9, 2017

System default settings versus production settings

I'd like to have production specific settings for different environments (OTAP). I have set the system default settings on my production to override the default settings. However, this does not seem to work. It is my understanding that the system default settings override the settings I have set on the production (I thought I heard my Sales Engineer say this). However, reading the documentation I am not sure of this reading either. However, when I clear the values for the adapters on my production my system default settings are still not apply.

Are the system default settings supposed to override my adapter settings I have applied on my production (i.e. the screen with the green bulbs)??

Discussion (8)2
Log in or sign up to continue

I got it to work. Clearing the values from the production didn't work because an empty string was left behind in the production file. So I went to studio and deleted the parameter settings there.

When I then viewed the production (and reloading it) via the management portal the settings specified in the system default settings then turned green. Apparently there is some color coding going on:

Setting name:

Green -> provided via class definition

Blue -> Provided via system default settings

Black -> Provided as production setting (in xml that extends ens.production )

Maybe I'm missing something but with the way we have our code and data split our, we're only mirroring our data. So an advantage of using the System Default Settings is the change made on the primary is already updated on the secondary. Is there a best practice on this type of setup when dealing with having to fail over to a secondary and needing the existing business host values the same? I do agree that it would be nice if we could use the Sytem Default Settings to be available to multiple namespaces.

Settings stored in the XData block of the production class (e.g. values entered through Portal) trump any System Default Settins values.

In Portal there's this button to get you to a page that may help you understand what's going on:

For a long time I've complained that the Portal UI makes it too easy to override a System Default Settings value (which is namespace-specific) with a value that gets stored in the production class (which you might migrate from one namespace to another). Add to this the fact that Portal ignores source control when altering the production class sad