The completely new Automation App, extended functionality in the Reports App and server improvements - the list of developments is impressive. Portal Edition R3 is another release from the current version series, which focuses on the complete replacement of the previous Web App by the role-based Portal.

With Release 3, another new Portal App, an enhanced Reports App and an improved ScriptRunner Server are delivered. 
In addition, a Community License will be introduced and made available for the first time in ScriptRunner. 

• New Portal App "Automation"
• Enhanced Portal App "Reports"
• Additional improvements to the ScriptRunner Server
• Community License
• Technology updates

New: Automation App

With this release, the ScriptRunner Portal App for configuring Automation Connectors is delivered for the first time.  

The Automation App supports the configuration:

• Operating mode of the Web Service Connector
• Assigning authentication to the Web Service Connector 
• Assigning authorization for automated execution of actions

The Automation App in the portal is only available to users in the ScriptRunner "Main Administrator" role.

Overview of the Automation Connectors function

Automation Connectors are used to start configured actions in ScriptRunner by external systems, such as monitoring, workflows, ITSM and others.

The Web Service Connector provides a secure interface with authentication and authorization via REST. 
 
The Email Inbound Connector supports automation with legacy systems that can only communicate via system emails. 
 
The authentication and authorization mechanisms ensure that only assigned sender systems are allowed, these systems must authenticate to the ScriptRunner server when called, and can only perform assigned actions in ScriptRunner.   

Operating modes on the Web Service Connector

The Web Service Connector offers three different operating modes and is also to be licensed according to the operating modes. 
 

Operating principle for automation with Web Service Connector in ScriptRunner

Operating mode "System / Application Backend"

In this operation mode, the backend of a third-party system is integrated with the ScriptRunner server for automation. For example, a workflow backend can communicate with ScriptRunner via such a connection. For authentication, users in an administrator role and in the helpdesk role are accepted.

Operating mode "Users / Computers directly"

In this mode, ScriptRunner Server is accessed directly by clients. Authorization can be done by user or computer accounts. For authentication only users in the role End User are accepted.

Operating mode "Microservice / Kubernetes"

This operating mode takes into account the specific requirements resulting from the use of microservices as the source of invoking an action in ScriptRunner. For authentication, users in an administrator role and in the helpdesk role are accepted.

Wizard for creating automation connectors

To use the Email Inbound Connector, a separate mailbox is required for ScriptRunner, to which the legacy systems can send their emails. The one-time setup of access to the mailbox is done on the server side. ScriptRunner accesses this mailbox via IMAP and checks the emails for matching senders as well as appropriate semantics in the subject and body of the email. For the semantics, various options are available to adapt the connector to the capabilities of the legacy system (sender).

Configuring Web Service Connectors

After opening the Automation App, the Automation Connectors are listed.

The "Local Loopback Web Service Connector" can be used to start another action from a running action. On the one hand, this makes it possible to build sequences of actions or to design complex processes using a controlling action (based on a control script) as well as called individual actions. It should be noted that a data transfer between the actions that are independent in ScriptRunner is currently only possible via a local file.

The "Web Service Connector Example" can be used in the trial phase to test action calls by third-party systems.

If different systems should be able to call actions in ScriptRunner, several connectors have to be set up and licensed.

Web service connectors are used for integrated automation with third-party systems

The configuration of a Web Service Connector as shown here in the example in the backend coupling operating mode is quite simple. Required are: 

• Sender IP address: only this system is accepted as REST Caller
• Account for authentication and access restriction: with this account the caller process authenticates itself to ScriptRunner Server. The account in the HelpDesk role can be created in the "Authorize & Delegate" app by specifying the authentication procedure.
• Action delegation: Actions that may be invoked by the Caller system must be delegated to the Caller authentication account.

This procedure ensures that only systems can call actions in ScriptRunner that are 

• identified, 
• authenticated,
• and are authorized to the action(s).
     

Example of configuration for backend coupling with Web Service Connector

Calling an action

There are different possibilities to call an action in ScriptRunner by a third party system.

Many workflow and ITSM systems now offer the configuration of a REST client within the application or at the application backend. There, the authentication, the REST methods as well as the data transfer format (URL, JSON) can usually be defined in detail.

Another possibility is the call by means of a script in JavaScript, PowerShell or others. In this case the third party system calls the script, passes the parameters and the script calls the web service in ScriptRunner. This option is applicable for systems without a REST client as well as in ScriptRunner calls, which can be integrated directly into web pages.

A special variant for integration into web pages at the frontend is the ScriptRunner Portal Widget.

Variants for calling an action in ScriptRunner

The third possibility are configurable and executable REST client programs like cURL. Thus monitoring systems on Linux like Nagios or others can be coupled with ScriptRunner. The monitoring system starts a parameterized cURL call on a certain event, which in turn communicates with the ScriptRunner server.
   

API methods

The Web Service Connector supports three API variants: 

• Webhook API
• ODATA API
• M365 PowerAutomate API  

Especially using the ODATA API, actions can be set up in a way that they do not yet contain a configured target system for the action to be executed. This allows the actions to be used flexibly for different target systems, e.g. for different servers or different M365 tenants.  
 
The caller methodology and syntax for using the ScriptRunner APIs can be viewed in the PowerShell Script in our Action Packs. 

Enhanced Reports App

The improved "Reports" App completely removes the previous limitations and is much easier to use thanks to the redesign in detail. In particular, the faster filtering and drilldown functionality immediately catch the eye.  
 
An essential basis for this was created with the server-side filtering and partial reloading to be able to display subsets from a very large report set much faster in the app. This also removes the display limitation to the 500 most recent reports. Any report from the total set can now be displayed.  
 
When switching to the Reports App, all 20 newest reports are displayed by default. In the timeline display in the graphic, the most recent report is on the far right. 
 
To make handling and filtering as easy as possible for the user, a quick filter bar has been introduced at the very top of the app and the previous filter board has been removed. 
 
The quick filter bar allows targeted filtering of reports for:

• Successfully completed actions 
• Actions that completed incorrectly
• Completed scripted queries
• Timed actions

In combination with the display

• of all reports that meet the above criteria,
• of the reports for the actions I executed that meet the above criteria,
• of a certain period of time.  
  
  
  

In the title bar, the number of filtered elements to the total number is displayed, it is possible to select the number of elements 20-50-100 displayed at the same time and it is possible to slide along the timeline to older and newer reports in this step.

Clicking on the respective time bar opens the corresponding individual report. The number of reports listed below the graph corresponds to the filtered selection from above.

Advanced filter options in the filter panel

The filter panel can be opened by clicking the "all filters" button. The upper third contains the filters from the quick filter panel. These filters are supplemented by selection options for:

• Selected actions, which have generated reports
• Selected target systems on which actions were executed
• Selected scripts that were used in actions or script queries
• Selected users, which generated reports by started actions 

The "Filter reset" button can be used to quickly restore the default filter settings. 

Improvements to the ScriptRunner Server

As in previous releases, minor improvements and technology updates have been made to the ScriptRunner Server. For example, a better handling of large amounts of data between frontend and server has been changed to allow faster display and access to subsets of data, e.g. in the Reports App in the portal.

For PowerShell 7 the built-in modules have been extended and some minor bugs for PowerShell in general have been fixed.

The configuration in IIS for the portal and the web apps was extended and two new error pages were introduced. The general error page is displayed if in the ScriptRunner path .../scriptrunner/... errors occur during input or program elements of the frontends are not found.

A second error information is displayed in the portal if HTML reports are no longer available in the reports directory.

New error page for ScriptRunner frontends

Community License

The Community License allows the use of ScriptRunner for demonstration purposes and for non-productive, personal use by IT Pros, especially MVPs, partners as well as admins who want to use ScriptRunner from time to time.

A Community License can be activated in the ScriptRunner portal after the trial period has expired. An online connection is required. Offline activation is not possible. 

Registration of an expired Trial License as Community License

Once activated, a Community License can be converted to a commercial version at any time without reinstallation.

 
The Community License is functionally limited: 

• Maximum 10 script executions per day (actions, scripted queries)
• Maximum 2 users in administrator or helpdesk role
• Maximum 2 users in end user role
• All connectors are disabled  

 
There is no entitlement for support under the Community License.

Outlook on Portal Edition R4

The portal will be further advanced in functionality and user experience in Release 4. The focus is on the new development of a dashboard, the introduction of a further improved UI design and the first version of the new Configuration App for credentials and targets in the portal. As in every new release of the Portal Edition, minor improvements and features will also be added to the ScriptRunner Server.