Dynamic Environments
Dynamic environments enable the control of specific installed applications within the environments for individual runs based on custom parameters.
Step 1: Defining a Custom Parameter in the Task for Control
Within the task template, a custom parameter is required to determine which installed applications in the environment should be activated for the run. This parameter can be of any type, as the exact implementation is managed within a script that processes the values of the parameter as needed. Multiple parameters can also be used to refine the control.
Step 2: Creating the Activation Script
The activation script is defined in the environment. It is executed during the tailoring process for each installed application. The script must return a Boolean value. If the value is 'false,' the installed application will not be activated. If the value is 'true,' the installed application will be activated.
Example 1: Boolean Custom Parameter with Naming Convention
If a custom parameter of type Boolean is defined in the task, an activation script can be used to establish a simple system based on the naming convention of the application models in the installed application.
We assume the variable name of the custom parameter is includeContractSystems.
|
if(installedApplication.applicationModel.displayName.startsWith("CTR_")) {
return environment.includeContractSystems
} else {
return true
}In this case, installed applications are only activated if the custom parameter includeContractSystems is set to 'true' for application models where the name starts with 'CTR_', otherwise all other application models are added.
Example 2: Using Multiple Custom Parameters
Since controlling installed applications based solely on their names can be challenging, an additional boolean custom parameter can be introduced to indicate whether an application model belongs to a contract system.
This parameter could be named isContractSystem and should be defined as a custom parameter on the application model.
The script can then be written as follows:
if(installedApplication.applicationModel.isContractSystem) {
return environment.includeContractSystems
} else {
return true
}Step 3: Checking the Configuration
The configuration can be checked using the 'Check Configuration' button in the environment. The custom parameters can be set on the environment, The default values will be used for the script evaluation.
Also, during task execution the Environment Toleration Mode can be used to observe the activated installed applications.
Step 4: Using More Complex Custom Parameters
By utilizing multi-value custom parameters, dynamic selection can be further expanded, allowing multiple systems to be selectable within the task and configurable within the application models.
Step 5: Setting the task parameters using a data shop
This example can be further automated by setting the set of the selected systems in a data shop, that sets the custom parameters for the task based on the selected systems. With this, the dynamic environments can also be used in the self-service portal.
Conclusion
Using dynamic environments provides a flexible way to control installed applications based on configurable parameters. By defining custom parameters and implementing activation scripts, users can precisely manage which applications are enabled for specific runs. This approach ensures better adaptability and efficiency in handling complex environments. Expanding the implementation with multi-value parameters allows even greater customization,