Configuring Installation Settings
On this stage of instantiating service, the Controller should prompt a user to configure parameters needed for service installation and configuration:
BASE_URL_PATH- defined by the specification. For details, refer to the 188.8.131.52.1. URL Mapping Variables section in the Specification.
Service settings are described in the package metadata file
When prompting the user to configure the service settings, the Controller must do the following:
class -attribute informs about the setting or group of settings meaning. For details, refer to the 184.108.40.206 Settings Semantics section in the Specification;
value-of-setting -attribute defines value of what setting should be used for the current setting. The referenced setting must be declared in the metadata and is searched in ascending order. For details, refer to the 5.2.5. Service Settings section in the Specification;
type -attribute defines setting value type. The
static-texttype dictates that value of the setting should not be changed by user and displayed as a static text. The
hiddentype dictates that neither setting name nor value can appear anywhere on application configuration screen. For details, refer to the 220.127.116.11 Data Types section in the Specification;
uniqattribute that value defines scope of setting value uniqueness. The Controller must validate and ensure such settings values uniqueness.
"/service/provision/"section. The Controller may run it to get list of choices for
enumsetting type. The Controller should cache this list of choices and suggest it for respective setting editing. For details on verification script 5.3.3 Verification Script section of the Specification.
"//setting/name"element and the
"//setting[@type]"attribute. For details, refer to the 18.104.22.168. Data Types section of the Specification.
When processing the settings data input by the user, the Controller should do the following:
"//setting[@type]"attribute), and their optional restrictions (if any provided in the metadata, for example uniqueness).
If a verification script is declared, the Controller may run it itself to validate settings values or provide a user with dialog window where user can click special control for verification, for example, Verify button. A verification script definition may include
structured-output element. In this case a script returns report on erroneous values in the form defined by the Specification. The Controller should catch output stream independently of error stream and process it. For details on script structured output, refer to the 22.214.171.124 Configuration script output section of the Specification;
SETTINGS_<id>, where <id> stands for a value of
"//setting[@id]"attribute, set each variable to the corresponding input value, and pass to the application configuration script. If a setting has the
track-old-valueattribute Controller must pass to configuration script old value together with new one. Child services may reference to values of parent service settings using
value-of-settingattribute. (For details, refer to the Specification's section 5.2.5. Service Settings.)
Processing Global Settings
The Controller must somehow store global settings of each application package available at its repository. (For details, refer to the Configuring Application's Global Settings section.)
When instantiating a package, the Controller must retrieve the package global configuration it stored, prepare from each global setting the
SETTINGS_<id> environment variable, in just the same way it does for service settings (see above), and pass the variables to the configuration script. (For details, refer to the Specification's section 5.1.15. Global Settings.)
Please send us your feedback on this help page