Dynamic Environment Control Using Activation Scripts

Overview

This guide describes how to control XDM Environments dynamically.

An environment can be configured dynamically by using activation scripts. This makes it possible to control which installed applications are active during a run. Activation is controlled by custom parameters and the activation script.

A typical use case is to include or exclude specific systems, such as contract systems, depending on task parameters.

Prerequisites

  • A configured environment that contains the required installed applications.

Steps

Step 1: Define a Custom Parameter in the Task

Within the task template, define a custom parameter that controls which installed applications should be activated for the run.

The parameter can be of any type. The exact interpretation of the parameter value is handled by the activation script.

Multiple parameters can also be used to implement more detailed activation logic.

Step 2: Create 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:

  • true: The installed application is activated.

  • false: The installed application is not 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 use a naming convention of the application models.

This example assumes that the variable name of the custom parameter is includeContractSystems. 
if (installedApplication.applicationModel.displayName.startsWith("CTR_")) {
    return environment.includeContractSystems
} else {
    return true
}

In this example, installed applications are only activated conditionally if the application model name starts with CTR_.

  • If includeContractSystems is true, these applications are activated.

  • If includeContractSystems is false, these applications are skipped.

  • All other installed applications are always activated.

Example 2: Using Multiple Custom Parameters

Controlling installed applications only by their names can be difficult. Instead, an additional Boolean custom parameter can be defined on the application model.

For example:

  • Parameter name: isContractSystem

  • Location: Application model

  • Type: Boolean

The activation script can then use this parameter:

if (installedApplication.applicationModel.isContractSystem) {
    return environment.includeContractSystems
} else {
    return true
}

This approach is more robust than relying on naming conventions.

Step 3: Checking the Configuration

The configuration can be checked with the Check Configuration button in the environment.

Custom parameters can be set on the environment for the configuration check. The default values are used during script evaluation.

During task execution, the Environment Tailoring Mode can also be used to inspect which installed applications are activated.

Step 4: Use More Complex Custom Parameters

Dynamic selection can be extended by using multi-value custom parameters.

This allows users to select multiple systems in the task. The activation script can then compare the selected values with custom parameters configured on the application models or installed applications.

Step 5: Set Task Parameters Using a Data Shop

This setup can be further automated by using a Data Shop.

The Data Shop can set the task parameters based on the systems selected by the user. This makes dynamic environments usable in the self-service portal.

Benefits

Dynamic environments provide several benefits:

  • Installed applications can be activated depending on runtime parameters.

  • The same environment can be reused for different execution scenarios.

  • Users can control system selection without changing the environment configuration.

Conclusion

Dynamic environments provide 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 improves flexibility, reduces the need for duplicated environments, and supports more dynamic execution scenarios.