Portal Edition R2 is the second release in a series that focuses on the role-based portal.
With Release 2, previous features in the Portal are improved and another new Portal App for monitoring ScriptRunner servers is introduced and made available in the browser for the first time:
Additional features in Release 2 include:
With this release, the ScriptRunner Portal App for Monitoring is delivered for the first time.
The following application scenarios are foreseen for the Monitor App:
Both types of use require the "Main Administrator" role.
The Monitor App provides the following functions:
Functional principle of the ScriptRunner Portal App for Script Monitoring
The Monitor App helps administrators and teams to:
Within the Monitor App, there are different functional areas for quick orientation.
The left tile displays the total number of script processing across all servers. In the middle chart, the running script processing (orange) and pending script processing in the queue (blue) are differentiated by color for each server. The scale shows the number of processing engines on the server. The server with the highest number of engines determines the scaling. By default, 10 engines are provided on the server for parallel script processing. On the right side there are buttons for the filters.
When evaluating pending processing in the queue (blue in the chart) on the respective server, the following settings must be taken into account:
Overview and filter both, running scripts and server load
The display of which script processings are shown can be set with the filter buttons in the upper right corner of the header block. By default, all script processing without queue and without scripted queries are displayed. The badges on the filter buttons indicate the amount of processing that is running, the amount scheduled, the ones waiting in the queue, and how many scripted queries are being processed.
Queued script processing waiting for execution is displayed/not displayed.
Processing of scheduled actions and scripted queries (for queries ON) is displayed/not displayed.
Processing of scripted queries is displayed/not displayed.
If only one or a selection of servers are to be monitored at a time, these can be specified in the server selection.
Depending on the filters set, the following script processing is displayed in a list view:
Note: After switching to another Portal App and returning, the current status is reloaded.
List view and live output of current and pending script processing operations
If a running or just finished script processing is clicked, the live output of this action opens. You can freely switch back and forth between the processings.
A running script processing can be aborted in the header of the live output.
Successful termination of the selected script processing
The configuration of the servers to be monitored is done in the configuration file App.Json in the portal directory on the server. The base URI corresponds to the master server from which the portal is loaded, and the data is used for the other Portal Apps, e.g. Script App.
Depending on the use case for individual monitoring or the design of the control center, the ScriptRunner servers are stored in the "monitoringServer" section. Note that, when using load balancers, the corresponding entries in the App.Json must be made on each server.
In the example, there are two servers to be monitored, each with a specific purpose. "Host 1", the first server, hosts all actions that are used interactively by service desk employees and end users in the portal, "Host 2", the other server, is responsible for all scheduled actions.
"monitoringServer": [
{
"displayName": "Host 1",
"identifier": "host1",
"path": "https://serverA.myorg.local:8091/scriptrunner"
},
{
"displayName": "Host 2",
"identifier": "host2",
"path": "https://serverB.myorg.local:8091/scriptrunner"
}
….
],
When the Portal is opened, the connections for the servers to be monitored are checked. If a ScriptRunner server is not reachable, a corresponding error message is displayed, and the connection is deactivated for the duration of the browser session. If a connection fails for a short time during monitoring, a reconnect is performed.
Error message if a ScriptRunner server is not reachable when starting the portal
The portal architecture has been enhanced with capabilities for parallel addressing of ScriptRunner servers. This enhancement focuses on running actions on different servers and viewing reports. This enables transparent use of the portal, especially for help desks and end users. In the Run App, all delegated actions are displayed to the portal user, no matter on which ScriptRunner server it has been configured and is being processed after startup.
Functional principle of ScriptRunner Portal App Run for multi-server
The configuration of the servers to be included is done in the configuration file App.Json in the Portal directory on the server. The base URI corresponds to the master server from which the portal is loaded, and the data is used for the other portal apps, e.g. Script App.
The corresponding servers are stored in the "executionServer" section. When using load balancers, note that the corresponding entries in the App.Json must be made on each server.
"executionServer": [
{
"displayName": "Server Team A",
"identifier": "server_a",
"path": "https://serverA.myorg.local:8091/scriptrunner"
},
{
"displayName": "Server Team B",
"identifier": "server_b",
"path": "https://serverB.myorg.local:8091/scriptrunner"
},
{
"displayName": "Server Special C",
"identifier": "server_c",
"path": "https://serverC.myorg.local:8091/scriptrunner"
}
],
Error message when disconnecting from a ScriptRunner server
When the user starts the portal, the connections to the stored servers are now checked. If a ScriptRunner server is not available, a corresponding error message is displayed and the connection is deactivated for the duration of the browser session. If a connection fails for a short time during Portal use, a reconnect is performed.
Access only to delegated actions even with multiserver access
If a portal user switches to the Run App, all actions to which he has authorized access are now displayed, no matter on which server the action resides. The same applies to the display of report results. In the example above, from three different servers (represented by the colors).
The Portal Edition R2 is the first version to be equipped with the new integrated and context-sensitive online help. Changes and extensions to the help content are thus always available to users immediately after publication on our systems. The expansion of our help is being consistently driven forward.
Access to the integrated context-sensitive help at any time
Depending on the app context, Portal Guide content is displayed on our support page. Help is accessed via the Help button in the Portal header. For this purpose, a panel is displayed on the right side and the mobile view of the respective section is displayed. The connection to the content is established directly from the portal in the user's browser to the online source, i.e. it does not depend on whether ScriptRunner Server itself being able to connect to the Internet.
For the use of the Portal in sensitive security areas without Internet access, an offline help is available as a PDF.
In the existing action settings in the Admin App, the parallel execution of actions on the server can be limited. If, for example, the limit is set to 5, each further start of this action is placed in a queue. If one of the already running executions has been terminated, the next action from the queue is processed. This mechanism allows you to better control executions and the load on resources on ScriptRunner Server.
Limiting actions that can be executed in parallel on the server
The purely action-related limitation has been supplemented in this release by the limitation on the target as a whole. Thus, the processing processes per target can now also be better restricted. This is particularly important for remote connections where there are only a limited number of PowerShell endpoints. For example, Microsoft's parallel PowerShell access to Azure and M365 services is limited. If the limit is exceeded without control with Queuing, the automated script execution leads to an error and termination.
With ScriptRunner Server, correct session set-up and dismantling is now ensured. Likewise, control and queuing of the scripts to be executed up to the maximum number of available or configured connections is warranted.
A delete function has been added to the Portal App for scripts. Depending on the role and the ScriptEditMode set on ScriptRunner Server, the following options are available:
ON (default): This setting allows all administrators to delete scripts in the ScriptRunner Portal.
OFF: The functions of the script editor are completely disabled. The code of the scripts is not displayed. The scripts cannot be deleted.
ViewOnly: The functions of the script editor are turned off, but the code of the scripts can be viewed. The scripts cannot be deleted. This setting is recommended for sync with a Git repository if the server is not designed for fast prototyping directly on the server.
Restricted: The functions of the script editor are limited to the system directory _Upload_ on ScriptRunner Server. This setting is recommended for fast script prototyping. The scripts in this directory can be deleted. This setting is recommended for syncing with a Git repository.
Further information about the Script App can be found here.
Deleting scripts directly from ScriptRunner
Before the actual deletion, a list of actions and queries is displayed in which the script is used. If the script is deleted anyway, ScriptRunner Server detects the missing references and marks the actions and queries as incorrect, and it does not execute them anymore.
Attention: the scripts are deleted from the repo on the disc at file level.
After selecting an action in the Run app, the input mask for this action appears. On the left, all other actions to which the portal user is entitled are displayed in a list panel.
To provide better orientation for the fields on the input mask, the list panel with the other actions can be closed and re-opened with a button. The setting is saved in the browser.
close and re-open the list
Administrators can now set a specific language setting for the first time the portal is launched, after which users can change it themselves if necessary.
The default setting can be made in the Main Administrator role in the Settings App
In order to better support the free test phase for ScriptRunner, the Trial Guide on our Support Portal has been revised and integrated into Portal Home. It will be displayed as long as the product has not been licensed yet.
Direct access to the trial guide on ScriptRunner Portal Home
Discover the new features and benefits of automation and delegation with PowerShell!