Multi-configuration Considerations

Owned by Dorian Port
Last updated: Jun 19, 2015

The multi-configuration feature does have some considerations / limitations to consider before enabling:

  • Performance:  If multiple configurations are setup, each with their individual getupdates rules, the server has to process each "configuration" separately.  We receive a batch of updates from the data source, queue for routing based on configuration settings and then get the next batch of updates.   With 3 different configurations, each batch of updates needs to be processed using 3 different sets of rules and would take approximately 2.5 times longer than if there was 1 config.  As we are storing / checking multiple configurations during several server processes there may be an increase in disk usage, disk space required and server memory usage.  An upgrade to hardware maybe required to maintain the same server performance as single configuration servers.
  • Re-Activation:  The configuration settings are only received during activation.  If multiple configurations are defined, any existing users will need to re-activate to use the multi configuration feature. 
  • Maintenence:  As there are individual configurations, any required configuration changes will need to be replicated across other configurations.  For example, to change a field to read only for all users (with 3 configurations defined), the same change in each configuration created before sending a cad to users.
  • Server version: Some features are dependent on server version, please contact iEnterprises for clarification before enabling.

Limitations

The following menus cannot be individually controlled or have no function in separate configurations.  Therefore the multi-configuration selection menu may not be displayed:

  • Users: All users are displayed in a single screen
  • Handheld data:  All items are displayed in a single screen
  • DS Modules: All items are displayed in a single screen
  • Queues: All items are displayed in a single screen
  • Cleanup settings:  Cleanup settings are performed in the server against a single set of records.  As there is one cleanup job and all fields/modules are configured in the Base Configuration, any cleanup rules required should be entered in the Base Configuration cleanup screen.  The drop down selection menu allowing users to select individual configuratons will be removed in a future release as it has no function.
  • Administrator Settings:  All settings in the "Administrator" menu are used for all configurations, the only exception is "Device Messages"
  • Scheduled jobs:  There are still single getupdates, cleanup and queuejob processes being run on the server, using a common admin id.  You cannot have separate scheduler jobs for each configuration, all "configurations" are processed together.  Different getupdates/download rules can be defined in a configuration but a single job is used.  If mutiple rules are configured for a specific job, this does have a performance impact.  Cleanup rules are configured at a "Base configuration" level, individual multi-config cleanup rules are ignored.
  • Web Service Configuration / Custom Db Settings:  In Map Settings->Module Settings, editing a module allows changes to the WS Config / Custom Db fields.  These have no effect at a multi-config level, only the settings stored in the "Base Configuration" will be used.
  • System keys:  As all admin settings are common to all configurations, this includes system keys.  Therefore, any keys that used to set distribution methods / server defaults, will be used for all "configurations".