When running a workflow instance, Active Roles uses a single PowerShell operating environment (called "runspace") for all script activities held in that workflow. The workflow runtime engine creates a runspace once the workflow instance started, and maintains the runspace during the run of the workflow instance.
When you configure a workflow, you can specify PowerShell commands you want the workflow runtime engine to initialize immediately after creating the runspace. These commands are part of an initialization script that the workflow engine runs prior to performing the script activities.
With an initialization script, you can define runspace configuration data separately from the logic of other script activities, and you can use it to initialize the environment for initializing script activities. Specifically, you can:
-
Load PowerShell modules and snap-ins. All activity scripts can use the modules and snap-ins loaded in the initialization script without having to load the prerequisite modules or snap-ins on a per-activity basis.
The modules and snap-ins loaded in the initialization script are available to all script activities at workflow runtime. For example, the Import-Module 'SmbShare' command added to the initialization script makes the Server Message Block (SMB) Share-specific cmdlets available to all script activities within the workflow.
-
Initialize environment-specific variables, referred to as "global variables". All activity scripts can retrieve and update global variables, which makes it possible to exchange data between different activity scripts.
The global variables are visible to all script activities at workflow runtime. For example, the $rGuid = [Guid]::NewGuid() command added to the initialization script makes the $rGuid variable available to all script activities within the workflow. To reference a variable defined in the initialization script, the activity script must use the $global: qualifier, such as $global:rGuid.
TIP: If the run of the workflow instance is suspended (for example, because it is waiting for approval), then resumed (for example, after receiving approval), the runspace is reinitialized, so the global variables may change.
In such cases, if you need to preserve the value of a global variable, add the [Persist()] attribute to the variable name in the initialization script, such as [Persist()]$rGuid = [Guid]::NewGuid(). Global variables defined this way are saved to a persistent storage when the workflow instane is suspended, then restored from the storage when the workflow instance is resumed.
To save a variable, Active Roles creates and stores an XML-based representation of the object represented by the variable, similarly to the Export-Clixml command in Windows PowerShell. When restoring the variable, Active Roles retrieves the XML data that represents the object, and creates the object based on that data, similarly to the Import-Clixml command.
Getting started
You can create new initialization scripts in the Workflow Designer of the Active Roles Console.
To start creating a new initialization script
-
In the Active Roles Console, navigate to Configuration > Policies > Workflow.
-
To open the Workflow Designer, select the workflow you want to configure.
-
In the details pane, click Workflow options and start conditions > Configure.
-
To open the initialization script editor, click Initialization script.
The Initialization script tab then displays the currently used script (if it exists). To add a new script or modify the existing one, use the editor.