I was asked how backend component parameters can be configured and managed centrally for all services. Above all: Is it possible to do this using the Console?
Well, unfortunately not. However, some customers solve this by using LDAP configurations for their backends such as JMS or DB servers.
Others build their own solution by reading the configuration parameters from a central database and setting them dynamically on the adapters. This works fine for all adapters except the SQL adapter. This adapter cannot set the connection dynamically but only the authentication credentials (see http://wiki.e2e.ch/E2EDOC/Dynamic+Configuration+of+SQL+Adapters).
Any other IDs how to set up such a central connection repository?
At one of our customers, LDAP is used for the lookup of different connection parameters:
* JMS: JNDI lookup in LDAP
* DB: TNSname lookup in LDAP
Still, identical backend component parameters are redundantly configured, both within one service (e.g. more than one jms listener) and across different services.
In order to overcome this, I think an own solution based on dynamical backend calls would indeed be useful, especially if the number of services (and thus redundancies) keeps growing.
Are there any further limitations, besides calls to SQL adapters? From the top of my head, at the moment de-central management of settings cannot be avoided for:
– external persistent state db settings (db name / credentials, number of workers)
– java virtual machine parameters (?)
– jms listeners (?)
– further settings per service apart from backend details (dump settings, log levels, tracing etc.)
Yes, JVM parameters and JMS listeners cannot be set dynamically because we need these parameters at start-up time. I’m not aware of any other backends that cannot be set dynamically.
Would it be an option to allow retrieving and overwriting the parameters that are needed at start-up time within an individual startup activity?
This could be very dangerous. For example, if you wanna change SQL connection parameters you have to do this before the SQL component gets initialized. But on the other hand, you might need the SQL component to read the connection parameter from a central DB – which wouldn’t be possible, if the DB hasn’t been started. So to make this scenario working, the SQL component would have to start and then change its own configuration. However, if we allow components to manipulate their own configuration, we might get into real troubles.
Ok, is see the danger.
What about only allowing a SOAP adapter call in this special startup activity?
A different – external, already started – service could centrally manage retrieval of central settings, and thus e.g. execute the lookup in the central DB, and only provide the details back to the startup activity of the service starting up.
I don’t see any problems with changing the SQL connection parameters during run time. In fact we offer this already for the user and password of a SQL connection (http://docu.e2ebridge.com/Dynamic+Configuration+of+SQL+Adapters).
We discussed the SQLConfigurationAdapter right at the beginning of this thread and were sort of disappointed that you can set user and password but not the connection string 😉
So it’s good to hear that you don’t see any problems implementing this enhancement. I opened a new Improvement Issue (RUN-1546) because this enhancement would come in handy not only in Christof’s use case but also when configuring for example the process dashboard.