Technical guide

ScriptRunner ActionPack for Automic

Author: | Reading time: 10 minutes | Category: Action Pack

ScriptRunner Leitfadten Automic, PowerShell-Scripte, Action Pack, Automation

This article has been translated automatically.

The combination of Automic and ScriptRunner allows IT teams to leverage the strengths of PowerShell for day-to-day administration and automation as well as the strengths of IT-supported workflows. In this scenario, the Automic platform takes over the central control and workflow functions for the IT-supported processes. ScriptRunner provides with the Integration Pack a highly flexible and very secure PowerShell Automation Engine. This executes PowerShell scripts in a controlled manner based on configurable policies. At the same time these policies can be interactively used by administrators and HelpDesk, Support and User Self Service with the ScriptRunner Apps.

Automic and PowerShell Automation Engine with ScriptRunner

As all Microsoft products including Microsoft Office can now be controlled and automated with PowerShell over a wide range of functions, the combination of Automic and ScriptRunner is also ideally suited for the automation of business processes, data analysis and combinations as well as for use in heterogeneous scenarios in which very different systems and applications have to interact with each other.

Basic principle

The following basic principle shows the allocation of the two platforms to the respective functions as well as interaction and the process:

  • Source System: Can be a system, data source or application used in an Automic workflow. The source can trigger a workflow in Automic by means of an event or Automic starts a workflow independently.
    Source and target system can, but do not have to be identical.
  • Target System: Can be a system, a data sink or an application to be addressed in an Automic workflow with the PowerShell Automation Engine of ScriptRunner. The target system can be identical to the source system.
  • Automic Platform: controls workflows and jobs, stores results and processes them further. In Automic, appropriate connections, workflows, and jobs are configured to use ScriptRunner as the PowerShell Automation Engine. Automic starts the jobs, receives the results and processes them further.
  • ScriptRunner Engine: Accepts a job call from Automic, checks for the default rules for executing the addressed action. ScriptRunner then starts a controlled and always traceable PowerShell processing. The results are recorded and saved in detail. Automic has full access to results, meta information and execution details. With the ScriptRunner Apps settings are made and tested. At the same time, the configured actions can also be used interactively with the apps.
  • On both participating platforms, the results will be fully available for further processing after completion of the action.

The following figure shows a somewhat detailed consideration of the interaction:

  • Automic Workflow Configuration: This is done with Automic Orchestration. On the Automic side you need a web service connection configuration to the ScriptRunner Connector, one or more ScriptRunner Job Templates and a workflow which includes ScriptRunner Jobs.
  • At runtime of the workflow the ScriptRunner jobs are processed by one of the running PM processes. If the job processing is to start a ScriptRunner action, an ODATA POST command with the necessary parameters and in the authorization context of the account stored in Automic is sent to the Web Service Connector of the ScriptRunner Service Host via the Web Service connection with REST. The call parameters are transmitted as JSON data objects. The calling job in Automic receives as response a JobControl-ID from ScriptRunner and if necessary already first execution results.
  • Web Service Connector from ScriptRunner: provides a web service connection with REST via ODATA for external systems. The configuration of the Web Service Connector requires at least the sender address of the Web service caller. You can also specify whether an incoming authentication of the caller is required.
  • Action in ScriptRunner: an action in ScriptRunner is a policy set that determines which script can be started on which target system(s), with which administrative rights and parameters the script should be executed on the target system and who or what is authorized to start the action. For an automation scenario with Automic, the values for action, target systems, parameter names for the corresponding script, and the parameter values at runtime can be controlled by the workflow. The actions are assigned to the Web service call using authorizations. This ensures that an action only takes place from an authorized account via the authorized connector.
  • ScriptRunner Service Host: controls the controlled execution of an action on the target system, stores metadata, results, and PowerShell execution information in a database. In the admin app this information can be viewed via the dashboard and the detail reports.
  • When the action is complete, all of PowerShell’s metadata, results, and execution information are fully available. The retrieval and subsequent further processing by Automic is carried out via a REST GET command with reference to the JobControl-ID of ScriptRunner transferred to the job at startup. The result data is transmitted as a JSON data object.

Explanations of the example configuration in the Integration Pack

Automic and ScriptRunner provide an example configuration using the Integration Pack, which is explained below. The prerequisites, commissioning and testing of the sample configuration are described separately and in detail below.

First the example configuration is presented under Automic/UC4. The sample configuration contains:

  • ScriptRunner Web Service connection configuration: in this configuration the URI to the ScriptRunner Service Host as well as the caller permission is stored. Both entries must be adapted to your real environment. In the URI, the host name for the ScriptRunner Service Host must be changed, the authorization or the account must be set to a local or AD account. If the port (default 8091) of the ScriptRunner Service Host was changed during the installation of ScriptRunner, the port must also be changed. This account must also have permissions for ScriptRunner.
    https://hostname:port/ScriptRunner/ActionContextItem/StartASRNamedAction=- sync:ßÇÈâÈâ


ScriptRunner Job Template

  • ScriptRunner sample workflow with ScriptRunner Job “JOBS.REST.START_PS.SCRIPTRUNNER” to start and execute a ScriptRunner action.

When the job is executed, the connection to the ScriptRunner service is used to execute a REST POST with a JSON-BODY on the ScriptRunner service host in the permission context of the caller. The data action name, parameter name and parameter values are transmitted in the JSON-BODY. If the connector is active, the caller is authorized and the action is assigned, the POST command is accepted, the action is started and a RESPONSE with the JobControl-ID of ScriptRunner is transferred to the calling Automic job.

The following information is used:

  • Action Name: “Local: Add two values”
  • Parameter Names: “Value A”, “Value B”
  • Parameter Values: “Script”, “Runner”

Important note: In the PowerShell script “Sum2Values”, which is used in the action “Local: add two values”, so-called Validate Sets are defined in the PowerShell Param Block. These only allow certain values for the two parameters “Value A” and “Value B”. In addition, both parameters are mandatory and must therefore contain one of the permitted values at runtime.



[ValidateSet(17, “Script”, “Two parts o”)]



[ValidateSet(5, “Runner”, “f a sentence”)]



  • ScriptRunner Job “JOBS.REST.CHECK_ACTION.STATUS.SCRIPTRUNNER” to check if the execution of the action is completed. The response value of the processing variable “Running = FALSE” is checked for the corresponding JobControl-ID using REST GET. If the value is TRUE the execution of the action is still running on ScriptRunner and is not complete.

  • ScriptRunner Job “PRINT.REPORT.SCRIPTRUNNER” to read the execution results of the ScriptRunner action with REST GET on the now complete record of the JobControl-ID. All metadata for execution, all result data, the $SRXEnv.ResultMessage variable that can be used freely in the script, all PowerShell execution information, and all error information are sent to this job. The job prepares this information. Within Automic, the relevant information is filtered from the response using JSONPath.

  • ScriptRunner Job “SCRI.PRINT.REPORT.SCRIPTRUNNER” to print the results. This job shows how the results of the ScriptRunner action can be used in Automic.

Now for the example configuration in ScriptRunner. After the installation ScriptRunner contains a sample configuration for Automic, which has to be adapted to the real environment:

  • ScriptRunner Authorization Group: An authorization group is required for the access authorization of the connector used. This can be created and configured quickly and easily in the “Authorizations” main menu. The authorization group is assigned either a local or an AD group. The caller’s account in the Automic Web Service Connection configuration must be a member of this group. In the Commissioning and Testing sections, the (AD/local) group is called “Automic-Automation,” and the (AD/local) user is called “Automic.
  • ScriptRunner Web Service Connector: The connector configuration is used to assign and check the calling system and caller. The connector must be adapted to the actual IP address (IPv4 or IPv6) of the Automic system as caller. An authorization group can (in production should) be assigned to the connector.
    Important notes: If Automic test system and ScriptRunner service host are on the same machine, either the local Loopback Web Service Connector can be used for the test (then the following applies to this Connector) or must be entered for localhost (for IPv4 only). If IPv4 AND IPv6 is used on the machine, the local link IPv6 address must be entered.
    The functions of the Web Service Connector on the ScriptRunner Service Host must be unlocked via Activation Key. In the versions on commissioning and testing, the connector is called “Automic Automation”.
  • ScriptRunner script: A simple script “Sum2Values.PS1” is used to test the function of the call, the execution and the results easily and comprehensibly.



Add two values – since we don’t specify a type, it allows numbers as well as strings.


First value to add


Second value to add





[ValidateSet(17, “Script”, “Two parts o”)]



[ValidateSet(5, “Runner”, “f a sentence”)]



# add the two values, and print the result as a nice string to the report.

$result = $ValueA + $ValueB

$SRXEnv.ResultMessage = “” + $ValueA + ” + ” + $ValueB + ” = ” + $result


  • ScriptRunner Action: An action in ScriptRunner includes a PowerShell script and a set of execution policies for that script. The actions that can be used as examples with the ActionPack configuration in Automic are “Local: Add two values” and “PS Remoting: Add two values”. The difference is in the execution mode for the same PowerShell script.
    When executed locally, the script is executed by the ScriptRunner Service Host with the administrative rights “Local System”. When running with PowerShell Remoting, the script can run on a remote system (which must be configured for PowerShell Remoting) and with other administrative privileges.
    Since both actions use the same script, the settings are the same except for the target system configuration. The most important setting can be found on the “Authorizations” tab. Here the action must be allowed on the used permission group (see ScriptRunner permissions above). When an action is called using the Web Service Connector, the system checks whether the caller is allowed to start the specific action.

Important notes: The possibilities for the separation of permissions are very relevant for the practice with PowerShell, because scripts on target systems should be executed with different permissions than those of an Automic Web Service caller. PowerShell does not natively support the clean and mutually anonymous separation of caller permissions and execution permissions as such. Different account information including password can be used/transmitted in PowerShell native without ScriptRunner only as part of the script.
When calling an action via the Web Service Connector in ScriptRunner, the following security scheme is run through:

  1. Check whether the caller from Automic has a permission in ScriptRunner. If it does not belong to any of the permission groups in ScriptRunner, the first authentication check step rejects the call with “Access Denied”.
  2. Check whether the call corresponds to an allowed connector connection. If the IP address of the calling system does not match the IP address stored in the ScriptRunner Web Service Connector used, the call is rejected with reference to an incorrect address.
  3. Check whether the caller in Automic is authorized for this connector. If the caller is a member of the selected ScriptRunner authorization group, the call is accepted, otherwise it is rejected. If the connector is configured to “unrestricted”, this check is not necessary. Any caller who is a member of any ScriptRunner permission group will be accepted. This can be used to test the pure service connection.
  4. Check whether the caller can call this special action using the Web Service Connector. To do this, the action must be assigned to the authorization group for the connector.

This scheme ensures that:

  • Accounts without ScriptRunner permissions do not have access to the ScriptRunner system
  • Connector calls from the ScriptRunner system are only accepted by defined source systems and defined caller accounts.
  • only defined actions can be called via a connector, even if the caller is authorized to start further actions e.g. via ScriptRunner Admin or Delegate App.


The easiest way to implement a test scenario using Integration Pack is in a test environment. Different test cases can be used:

Small variant “everything on a separate VM”. In this scenario, the Automic and ScriptRunner installations are located on a virtual machine. If the VM is integrated into an Active Directory, the accounts and group settings for AD users and AD groups are used. If the VM works without Active Directory, local users and groups can be used instead.

Large variant “distributed over several VMs”. This scenario can be expanded as required. In the minimal configuration of this variant there is an Active Directory with DNS, a VM with the Automic software, a VM with the ScriptRunner software. All VMs are in the same IP network.

The scenario can be expanded as required. Thus the environment could be extended by a separate VM as target system, by a VM with SQL server for the ScriptRunner Audit database, by separate clients for the ScriptRunner Apps as well as VMs with monitoring and ITSM.

For the test scenario with the ScriptRunner Integration Pack for Automic, the following requirements must be met on the respective systems.

Requirements Automic

  • Automic ONE Automation Engine Version v10 or newer
  • Automic Webservice Agents Version 3.2 or later

Requirements ScriptRunner

  • ScriptRunner Service Host and the ScriptRunner Apps must be installed on the test VM. WinS2008R2, WinS2012R2, WinS2016 can be used as operating system for the ScriptRunner Service Host. Windows Core Server and Windows Nano Server are not currently supported as service hosts, but can be used as target systems.
  • NET Framework 4.5 or higher must be installed.
  • ScriptRunner Team Apps, require Internet Explorer 11, because the apps use the IE control.
  • ScriptRunner Web Service Connector must be activated with an Activation Key. You can get it by sending an inquiry to


The following preparations must be made for the test scenario.

Network settings in the test environment

All VMs in the test environment should be in the same IP subnet and belong to the same domain or workgroup. IPv4 should be used as the network protocol. To do this, deactivate the IPv6 protocol option at the network interface of the Windows operating system. Since IPv6 behaves differently in detail than IPv4, IPv6 experts can also use this protocol and evaluate the corresponding logs if errors occur.

The Windows Firewall settings should be set so that the Web Service Protocol can access the set port of the ScriptRunner Service Host.

These settings are made with the ScriptRunner Service Setup.

PowerShell Settings in Test Environment

The VM with the ScriptRunner service host and each separate target system must be configured to run PowerShell. Two aspects are important: the PowerShell Execution Policy and the PowerShell Remoting permissions.

For the ScriptRunner Service Host, these settings are made through the ScriptRunner Service Setup.

For each separate target system these settings can be done manually or by a configuration wizard (which is included in the ScriptRunner setup package).

Authorizations in the test environment

For a practical test, it is recommended that you set up separate authorization groups and users for the test. Two possibilities can be used:

  • The test VMs have access to an Active Directory.
    • Creating a Test OU
    • Setting up an AD user “Automic” in the test OU
    • Setting up an AD group “Automic-Automation” in the test OU
    • Adding the AD user “Automic” to the AD group “Automic Automation
    • Setting up an AD group “ASR-Admins” in the Test-OU
    • Include AD users as authorized ScriptRunner administrators
    • Optional: Creation of further AD users as well as creation of a further AD group “ASR operators” in the test OU. Include these users in this AD group.
  • The Test VM uses local accounts and groups on the ScriptRunner Service Host
    • Setting up a local “Automic” user
    • Setting up a local “Automic-Automation” group
    • Include local user “Automic” in the local group “Automic Automation”.
    • Setting up a local ASR admin
    • Recording local users as authorized ScriptRunner administrators
    • Optional: Creation of further local users and creation of a further local group “ASR operators”. Include these users in this group.

Installation of ScriptRunner in the test environment

Copy the ScriptRunner setup package as a ZIP file to the designated VM. Open the ZIP file and run the ScriptRunner Service Setup first. In the Setup Wizard, set the setting for the Administrators permission group to the AD or local group “ASR Admins”.

: You should make sure that your login account is a member of this group.

In the second step run the “ScriptRunner Team Apps Setup”. The service host should be set to localhost.

: If the Team Apps are installed on a separate VM, the FQDN or IP address of the ScriptRunner Service Host must be specified.

After the installation of ScriptRunner in the test environment, the configuration and an emulation test should take place there first.

Setting up the Authorization Group for Automic/UC4 in ScriptRunner

  • Start ScriptRunner Admin App as a member of the “ASR-Admins” group described above.
  • Select the main menu item “Authorization”.
  • Select “Create” in the action bar below and create a new authorization group. Enter the group “Automic-Automation” and for AD groups also the domain and execute “Validate”. Then save with OK.

Setting up the Web Service Connector in ScriptRunner

  • Start ScriptRunner Admin App as a member of the “ASR-Admins” group described above.
  • Select the main menu item “Connectors/Connections”.
  • Select “Automic Automation” and click on “Edit” in the action bar below. Then enter the IP address of the source system, the calling instance of Automic. Optionally set the Restrictions to the group “Automic-Automation”.
  • Alternatively for a small scenario: Select “Local Loopback Web Service Connector”. No IP address can be entered for this. The source system is “localhost”. Optionally set the Restrictions to the group “Automic-Automation”.
  • Alternative for advanced tests: Click “Create” in the action bar below and create and configure a new Web Service Connector.

To activate the ScriptRunner Web Service Connector, perform the following steps:

  • Activate ScriptRunner Web Service Connector once with Activation Key. See the product activation document for more information.
  • Select the connector used and activate it via the action bar.

Setting up the action to be called in ScriptRunner

  • Start ScriptRunner Admin App as a member of the “ASR-Admins” group described above.
  • Select the main menu item “Actions”.
  • Select the action with the name “Local: Add two values”.
  • Click on “Authorize” in the action bar below. The Action Wizard opens the corresponding tab for this action. At the top delete all tags and enter “Automic”. Select the authorization group “Automic-Automation” below and save everything with OK.
    Note: With CTRL+mouse selection several authorization groups can also be selected. This is useful when both Automic and other user groups need to apply the same action configuration. For example, operators can start the same action interactively with the Delegate App.

Testing the sample configuration on ScriptRunner

Testing the sample configuration on ScriptRunner is done in several steps, described below, for a better understanding.

In summary, these are:

  • Interactive execution of the action “Local: Add two values” to be called later by Automic with the ScriptRunner Delegate App and with the ScriptRunner Admin App.
  • Emulate the Web service call on the ScriptRunner service host directly with PowerShell ISE.
  • Emulation of the Web Service call on the Automic system directly with PowerShell ISE.
  • Alternatively: Create and configure a separate ScriptRunner action which allows to emulate the Web Service call with the ScriptRunner Delegate App.
    • Emulation of the Web Service Call on the ScriptRunner Service Host
    • Emulation of the Web Service Call on the Automic System

Interactive execution of the action “Local: Add two values” with the Delegate App

  • To do this, start the Delegate App as a member of the “Start ScriptRunner Administrators” permission group.
  • Click on the “Automic” tab, which was assigned as described above using “Authorize”. A tile appears with the name “Local: Add two values”. Alternatively, use the “ALL” tab.
  • Click on the tile and select the values for Value A and Value B.
    Note: as described above, the script uses Validate Sets and mandatory for the parameters. Validate Sets are automatically displayed in drop-down menus in ScriptRunner Team Apps.
  • Specify a reason for the execution. This becomes part of the metadata for the executed action.

The execution and the result are displayed in a pop-up menu and the tile indicates the status of the last interactive execution by the logged on user.

The action can also be started with the ScriptRunner Admin App. The interactive entries are then made in the execution mode of the action wizard.

Via the dashboard or the main menu “Actions” the detail reports for the execution of the action can be viewed in the admin app.

Emulation of the Web Service Call on the ScriptRunner Service Host with PowerShell ISE

The Local Loopback Web Service Connector is used to emulate the Web Service Call on the ScriptRunner Service Host. Use this connector with the default setting “unrestricted”.

  • Switch on the Local Loopback Web Service Connector with the Admin App.
  • Copy the script “CallASRWebSvcConnector.ps1” from the Integration Pack to C:userspublic. The PowerShell script emulates an external system calling the ScriptRunner Web Service Connector. Therefore the script is also suitable for testing on the Automic System (see below).
  • Run the PowerShell ISE as an administrator. Then execute the following commands in the console:
    • Cd … to root directory C:
    • Cd users
    • Cd public
    • .CallASRWebSvcConnector.ps1 -ActionName “Local: Add two values” -ParamNames ValueA,ValueB -ParamValues “Script”,”Runner” -Reason “Testing WebSvc Functionality”
      • The parameter “ActionName” determines which action is to be called by the external system using the Web Service Connector.
      • The ParamNames parameter specifies a list of parameter names that are required in the script to be executed. Here the mapping of Automic parameters with the PowerShell parameters from the script of the called action takes place later.
      • The parameter “ParamValues” defines the list of values for the list of parameters. This is where the final mapping of values from the Automic runtime environment to the values for the PowerShell parameters at execution time takes place.
      • The combination ofParamNames andParamValues results in a flexible number of parameter-value pairs. This also makes generic action calls that are only controlled by parameters possible.
      • The Reason parameter is used to pass a reason for the action call and becomes part of the execution and reporting metadata. It thus supports traceability, compliance and audits.

The execution and the result of the call can be followed directly on the PowerShell ISE console as well as in the dashboard of the ScriptRunner Admin app. The metadata of the report shows details about the execution:

  • Which action was called and started
  • When was the action started and how long did it last?
  • Who has started the action (on the target system) -> ScriptRunner Service under “Local System” -> ScriptRunner Service under “Local System” -> ScriptRunner Service under “Local System” -> ScriptRunner Service under “Local System” -> ScriptRunner Service under “Local System”.
  • What was the reason for the start of the action -> here called by the Local Loopback Web Service Connector with the transmitted reason “Testing WebSvc Functionality”.
  • On which target system and with which administrative rights the action script was executed -> here local execution on the ScriptRunner host with “Local System”.

For operational use cases, both the target system and the administrative execution rights will contain different values.

The Web service call can now be modified for further tests.

The “Local Loopback Web Service Connector” can also be configured to the “Automic-Automation” authorization group.
To test, perform the following steps:

  • Run the PowerShell ISE as the Automic user. This user is a member of the AD/local group “Automic Automation”. Since this group was also created as a permission group in ScriptRunner, the security scheme can now be tested.
  • To run PowerShell ISE as another user, press the Shift key using the RIGHT mouse button.
  • Then execute the commands as above
    • Cd.. to root directory C:
    • Cd users
    • Cd public
    • .CallASRWebSvcConnector.ps1 -ActionName “Local: Add two values” -ParamNames ValueA,ValueB -ParamValues “Script”,”Runner” -Reason “Testing with Connector Restrictions”

The ScriptRunner action “PS Remoting: Add two values” can now also be used. For this purpose, the authorizations of the action must be set to the corresponding authorization group “Automic-Automation”.

The call using PowerShell ISE is now:

  • CallASRWebSvcConnector.ps1 -ActionName “PS Remoting: Add two values” -ParamNames ValueA,ValueB -ParamValues “17”,”5″ -Reason “Testing with PS Remoting”

The modified call should now lead to modified metadata and a different result when looking at the corresponding reports.

This concludes the tests for the small scenario.

Emulation of the Web service call on the Automic instance with PowerShell ISED

The above steps can also be executed in the same way on the Automic instance in the large test scenario. However, the following must be observed:

  • It should be ensured that the PowerShell ISE takes place in the user context of the configured caller account. The user used should either be a member of the ScriptRunner Administrators permission group or of the Automic-Automation permission group.
  • The Web Service Connector “Automic Automation” in ScriptRunner must be configured with the IP address of the calling Automic instance (source IP).
  • The connector should first be called with the authorization “unrestricted”. You can then make the settings for the corresponding authorization group.
  • The called actions must be assigned to the authorization group of the caller.
  • The PowerShell script “CallASRWebSvcConnector.ps1” to emulate the Web Service call must have been copied to the Automic instance under c:userspublic.
  • In the PowerShell CallASRWebSvcConnector.ps1 script, the URI entry to the ScriptRunner Service Host must be customized with the valid FQDN.


# set your ScriptRunner server here; for local loopback connector simply set ‘localhost:port_number’


The Automic Export included in the Integration Pack (file ScriptRunnerJobs_export.xml) contains all necessary objects for the execution of the example ScriptRunner job “Sum2Values.PS1” via the Automation Engine of Automic.

The export XML file must be imported into the target client via the import function within the Automic UI. After the adjustments to your environment the job can be tested.

The individual steps for commissioning in detail:

  • Importing objects

  • If the Web Service Agent is not running on the same machine as ScriptRunner, you must adjust the endpoint URL accordingly. The user and password must also be adapted to your environment. The user must be a member of one of the named ScriptRunner permission groups.
  • Adjusting the Web service agent assignment to job level:
    The delivered job objects reference a Web service agent with the name “WEBESERVICE01”. This assignment must be adapted to your configuration in all job objects.

Once this has been done, the first tests can be carried out.


To perform a test, please start the top-level workflow “JOBP.RUN.SCRIPTRUNNER.ACTION”. The screenshot shows the workflow in the Web UI of Automic:

After a successful start of the workflow, the input of paramaters is expected via so-called PropSets. These can be recognized by the request icon in the upper right corner of the Web UI.

Please click on the button with the waiting “1 Request”. Then the input dialog opens. Enter the appropriate values and exit with “Submit”. ScriptRunner checks the values for admissibility before executing the action. The PowerShell script to run uses validate sets in the PowerShell Param block with value restrictions.



[ValidateSet(17, “Script”, “Two parts o”)]



[ValidateSet(5, “Runner”, “f a sentence”)]



Accordingly, only the value pairs “17” and “5”, “Script” and “Runner” as well as “Two parts o” and “f a sentence” are allowed.
According to the policy in ScriptRunner other values are not allowed and are acknowledged with an error. This error is currently not intercepted in Automic and the workflow still ends successfully.
However, this could be detected with a Job Output Scan and the workflow could terminate with an error code. Alternatively, the error messages can be processed via the JobControl-ID of ScriptRunner.

A description of the individual jobs has already been given in the previous chapters. If everything was configured correctly, the workflow should be terminated with the status “Success” and the ScriptRunner job should have been executed successfully with the action on the ScriptRunner host. The Workflow Monitor should then look like this:

Summarized again the sequence of the jobs in their order:

  • Job 1 starts the action in ScriptRunner with the parameters and gets the JobControl-ID back from the ScriptRunner Service Host.
  • Job 2 checks the status of job 1 until it is no longer in “Running” status.
  • Job 3 executes the job again to get the complete results.
  • Job 4 ScriptRunner Job “SCRI.PRINT.REPORT.SCRIPTRUNNER” to print the results. This job shows how the results of the ScriptRunner action can be used in Automic. This is done by filling Automic variables.example report:

Example report of a faulty job due to invalid parameter entry:

These posts might also be interesting for you:

Action Packs. ScriptRunner PowerShell Scripts
Action Pack Exchange einrichten , ScriptRunner PowerShell, Automation
ScriptRunner Action Packs, PowerShell-Scriptsammlungen