As some of you might know the configuration system in InfoSystems suite is quite flexible, and by now it has a lot of configurations. A little over 1000 configuration options in total, some are more relevant than others by now. The system as it is currently, is basically an evolution of the system that existed in the old VB6 suite of application (now dubbed Classic) – meaning the design is roughly 20 years old!
Surprisingly it has held out quite nice, and while we have had our concerns with it, there has been no real need. Now however, due to performance issues we had to re-write the entire set of management forms. Instead of just fixing the form to perform better we had a look at the structure of the thing.
Title based configuration values
Most configurations are related to a title, so that title A can have one value and title B can have another in case they do things differently. That’s all fine and very nice, but the data model is such that each configuration must exist once per title. Now imagine you have 70 titles in the database, and each instance of configuration “C1″ should be the same but it should not be whatever default the system comes with: Then you have to go around and change 70 instances of “C1″, not exactly fun or time saving.
We are changing that, so now some of the configurations will allow you to set a default, with no title indication. Meaning that if a configuration “C1″ is not defined for a given title “A”, the default value will be used. There are still going to be a few configurations that will require you to set a title as there is no “sane” scenario where having a shared default makes sense (there are possibly scenarios where you would want to do it anyway, but we have to deal with your insanity :))
Configuration as a service
One other thing that rebuilding the configuration system has allowed us to do, is to expose the values as a service. It is not often needed, but on rare occasions a web client might need to know a specific configuration setting or limitation value from the system in order to provide the best end-user experience. Previously this was impossible without digging into the database, so most people resolved to hard-coding the values, other resolved to build it into their own configuration system. Either way there was a synchronization issue only resolvable by human interference.
With the re-write there is now a read only service that will give you any configuration that you need. We are still discussing the options for creating and maintaining your own configurations but as of yet we have had no demands for such an extensible configuration service so we are holding it back for when demand arrives.
Maintaining Configuration Data When Needed (Reducing startup)
Depending on the amount of data in the various configuration tables, the startup time of the application suite, be it client, webservice or the jobscheduler, takes from around 15 seconds up towards 40-45 seconds in the worst scenarios (largest installations). Part of this is due to the fact that during startup a maintenance routine runs to ensure consistency between the database, and the various defaults that should exist in the system.
In reality this maintenance is only required in two cases, the defaults changed (with a new version) or someone messed around with the database manually. The latter case is unsupported in any event, but the first is the whole reason for the maintenance routine.
We are introducing a change to this maintenance system so that it is only executed ONCE per new version. I.e. the first person starting any of the applications on a new version will get the long startup time, usually the person doing the upgrade, while all others will skip the maintenance routine altogether. This will reduce startup time with anything from 2 to 15 seconds depending on the database speed and number of records to analyze for maintenance. For those with either a lot of overrides or even a few titles (4+) this should be quite noticeable.
So when will you be getting all this configuration goodness?
The short answer: v3.6.0
The slightly longer answer: Bits and pieces of it has already found its way into 3.5.0 and a bit more into 3.5.1, but you probably won’t notice any of it. The things described above will be fully implemented in 3.6.0 to be released sometime during Q1 2016.
Enough about the technicalities already, I want to see the damned result!
The new configuration form with “all” configuration values.
The yellow cell indicates a user override is present for the current user.
An example of editing a given configuration. Very similar to the old one.