Scripting Node

This node, under Security in the Workflow Administration Console, lets you configure Workflow Server settings for designing and running scripts with the Script and SDK Script activities. This node lets you enable or disable scripting, terminate workflows that attempt to run script activities that are not allowed, cancel scripts that run too long, and manage references to Global Assembly Cache (GAC) assemblies.

ClosedShow me this node.

To open this node

  1. In the Workflow Administration Console's Console Pane, expand the Security node.
  2. Select Scripting. The node will list the script security settings.
  3. Tip: You can refresh this list to reflect recent changes by clicking the Refresh link below Scripting in the Actions Pane. Alternatively, right-click the Scripting node and select Refresh.

To allow script references to GAC assemblies

Script references are links to other .NET assemblies that can be run by the script. There are two setup parts to using a reference in a script. The first part is configuring the reference with the Workflow Server. After a reference is configured with the server it will be available for use in the Workflow Designer's Script Editor.

  1. Select the Scripting node in the Console Pane or any scripting security settings in the Details Pane.
  2. Click Properties in the Actions Pane, or right-click and select Properties.
  3. In the ClosedReferences tab, configure which GAC assemblies you want to allow references to.
    • None: No GAC assemblies will be provided as a reference.
    • LFSO interops only: LFSO80, 81, 82, 83, 90 can be referenced in a script via their interop assemblies (e.g., Interop.LFSO80.dll). Repository Access is also available. (It has no interop.)
    • LFSO interops and .NET Framework: In addition to the LFSO interops, any .NET 'System' assemblies that have the following public key tokens: b77a5c561934e089, b03f5f7f11d50a3a, 31bf3856ad364e35 can be referenced.
    • All assemblies: All assemblies can be referenced from the GAC.
  4. Optional: To configure custom references, click Add. Browse to the desired assembly, and click Open. Select the Allowed checkbox to be able to reference the assembly. Clear the checkbox to not be able to reference the assembly. To remove a custom assembly, select the assembly and click Remove.

Note: If you reference an assembly that is not allowed (either because it is a custom assembly with a cleared Allowed checkbox or because its excluded by the reference option you chose above) and you reference the assembly in a Script activity, you will encounter build warnings in the Script Editor and errors during publishing for having referenced an assembly that is not allowed.

To configure script settings

  1. Select the Scripting node in the Console Pane or any scripting security settings in the Details Pane.
  2. Click Properties in the Actions Pane, or right-click and select Properties.
  3. In the ClosedSettings tab, select or clear the following options.
    • Report unhandled script exceptions as: Select to report unhandled script exceptions as warnings that will not terminate the workflow or as errors that will terminate the workflow.
    • Enable scripting activities: Select this option to allow script activities to run. You can further choose to allow C# .NET scripts, Visual Basic .NET scripts, or both C# .NET and Visual Basic .NET scripts. Clear this option to prevent script activities from running. Clearing this option will protect the Workflow Server from script activities.
    • Terminate workflows that attempt to run a script in a language that is not allowed: Select this option to terminate workflows with an error when they try to run a script activity configured to use a script language disallowed by the previous setting. Optionally, type a reason for why the workflow terminated. Clear this option to report a warning but not terminate the workflow when a workflow tries to run a disallowed script language.

To configure advanced performance script options

Note: These options may affect the performance of your Workflow Server.

  1. Select the Scripting node in the Console Pane or any scripting security settings in the Details Pane.
  2. Click Properties in the Actions Pane, or right-click and select Properties.
  3. In the ClosedPerformance (Advanced) tab, select or clear the following options.
    • Script domain model: This option determines how the Workflow Server will run a script.
      • Isolated (High safety, low speed): With this setting, when a script runs, its code is isolated into its own AppDomain and is isolated from the Workflow Server. Once the script is finished running, the AppDomain is promptly unloaded from the server. This process is known as sandboxing. It's an expensive process that can be optimized (made faster) by relaxing some of the strictness of the sandboxing. This is the default domain model.
      • Shared (Moderate safety, moderate speed): This setting allows the scripts of a single workflow version to run in the same AppDomain. Each workflow version will have up to 2 AppDomain objects (one for each script language) that will be shared by all running instances. Sharing provides significant performance savings because the script assembly, any references, and the AppDomain itself are loaded once and are not unloaded. This option introduces the chance that scripts from different workflow instances could contaminate each other via static or global variables and through the use of non-thread-safe libraries. Since a workflow version tends to be authored by a single person or department, the risk of this contamination is low.
      • Single (Low safety, high speed): This setting has one AppDomain for all script instances. This configuration is the least safe but produces the fastest performance. With this setting, multiple workflow scripts may interact with each other, causing unintentional side effects. To safely use this setting, multiple workflow authors must coordinate their scripting efforts.
    • Domain pool sharing timer: This option controls how long a shared or single app domain will be available for reuse before Workflow reclaims the resources it is using. To configure the time in minutes, type a number in the text box or use the scroll box (up-and-down arrows) to choose a number.
    • Script disconnect timeout: This option controls the maximum time a script can run before the Workflow Server disconnects the script. When Workflow disconnects a script, a warning appears in the Messages tab of the workflow instance details. ClosedShow me what this looks like. If your script frequently times out, then you will probably want to clean up your script or increase the timeout period with this option. To configure the time in minutes, type a number in the text box or use the scroll box (up-and-down arrows) to choose a number.

To export the contents of this node in a .csv, .xml, or .txt file

  1. Select the node in the Console Pane.
  2. Select View from the main menu.
  3. Click Export Contents.
  4. In the Export data dialog box, name the exported file.
  5. Select CSV File, XML File, or Tab Delimited Text File from the drop-down menu.
  6. Click Save.