Settings
If you want to use settings in your model, we recommend to always use one or more classes and mark the attributes as settings.
Advantages of this approach:
It is easy to find all settings of a service.
The same settings can be re-used in several diagrams.
It is easier to maintain the settings.
It is not recommended to use the inline style definition of settings within Action Script.
Only exception of this rule: Use the inline style definition when having a single setting in a specific context.
Create a Settings Class
As a best practice, we recommend to define the settings on a class in the context where they are used.
This can be
one settings class (maybe also called Settings) that contains all service settings as properties.
one settings class per context, e.g. FTPConnection (a class that contains all FTP connection settings).
To define a class property as a custom service setting, add the Setting extension to the property. This is done in the Attributes panel. You can also define the default value there.
For more details about how to define a settings class and how to access the settings in the service configuration, refert to How to Define Custom Service Settings in a Designer Service.
Naming Conventions for Settings
For | Use | Example |
|---|---|---|
Single Settings | one class named Settings | |
Multiple Settings | multiple classes: SettingsSuffix | SettingsCustomer |
Documentation | use field Description in the Attributes panel | Put in timeout in seconds: |
Setting vs. User Interface
Usage of a settings class is to be preferred, if the setting is a simple one, e.g Customer.
In place of settings, you could also implement a user interface. You should prefer to use a user interface in the following cases:
The settings need enhanced validation (enumeration etc.).
The settings are complex, e.g. three input fields which belong together.
Expert Advice
If you want to use a user interface to change the settings, they should be adjustable without service stop.