Skip to the main content.

ScriptRunner Blog

ScriptRunner Portal Edition R3

Inhaltsverzeichnis 

Post Featured Image

Die ganz neue Automation App, erweiterte Funktionalität in der Reports App und Server-Verbesserungen - die Liste an Weiterentwicklungen kann sich sehen lassen. Die Portal Edition R3 ist ein weiteres Release aus der aktuellen Versionsreihe, welche die vollständige Ablösung der bisherigen Web App durch das rollenbasierte Portal im Fokus hat.

Mit dem Release 3 werden eine zusätzliche, neue Portal App, eine weiterentwickelte Reports App sowie ein verbesserter ScriptRunner Server ausgeliefert. 
Außerdem wird in ScriptRunner eine Community License eingeführt und erstmalig verfügbar gemacht. 

  • Neue Portal App "Automation"
  • Verbesserte Portal App "Reports"
  • Zusätzliche Verbesserungen am ScriptRunner Server
  • Community License
  • Technologieerneuerungen

 

Neu: Die Automation App

Mit diesem Release wird erstmalig die ScriptRunner Portal App für die Konfiguration der Automation Connectors ausgeliefert.  

Die Automation App unterstützt die Konfiguration:

  • Betriebsart des Web Service Connector
  • Zuweisen der Authentifizierung am Web Service Connector 
  • Zuweisen der Autorisierung zur automatisierten Ausführung von Aktionen

Die Automation App im Portal steht nur Anwendern in der ScriptRunner Rolle "Main Administrator" zur Verfügung.

Überblick zur Funktion der Automation Connectoren

Automation Connectoren dienen dem Starten von konfigurierten Aktionen in ScriptRunner durch externe Systeme, wie Monitoring, Workflows, ITSM u.a.

Der Web Service Connector bietet eine sichere Schnittstelle mit Authentifizierung und Autorisierung über REST. 
 
Der E-Mail-Inbound Connector unterstützt die Automation mit Legacy Systems, welche nur über System-E-Mails kommunizieren können. 
 
Die Authentifizierungs- und Autorisierungsmechanismen stellen sicher, dass nur zugewiesene Absendersysteme erlaubt sind, diese Systeme sich beim Aufruf am ScriptRunner Server authentifizieren müssen und in ScriptRunner ausschließlich zugewiesene Aktionen ausführen können.   

Betriebsarten am Web Service Connector

Der Web Service Connector bietet drei verschiedene Betriebsarten und ist gemäß den Betriebsarten auch zu lizensieren. 
 Funktionsprinzip für Automation mit Web Service Connector in ScriptRunner

Funktionsprinzip für Automation mit Web Service Connector in ScriptRunner


Betriebsart "System / Application Backend"

In dieser Betriebsart wird das Backend eines Drittsystem mit dem ScriptRunner Server für die Automation integriert. So kann über eine solche Verbindung beispielsweise ein Workflow-Backend mit ScriptRunner kommunizieren. Zur Authentifikation werden Benutzer in einer Administrator-Rolle und in der Rolle Helpdesk akzeptiert.


Betriebsart "Users / Computers directly"

In dieser Betriebsart wird ScriptRunner Server direkt von Clients angesprochen. Die Autorisierung kann über Benutzer- oder Computerkonten erfolgen. Zur Authentifikation werden nur Benutzer in der Rolle End User akzeptiert.


Betriebsart "Microservice / Kubernetes"

Diese Betriebsart berücksichtigt die spezifischen Anforderungen, welche sich aus der Verwendung von Microservices als Quelle des Aufrufes einer Aktion in ScriptRunner ergeben. Zur Authentifikation werden Benutzer in einer Administrator-Rolle und in der Rolle Helpdesk akzeptiert.

Wizard zum Anlegen von Automations-Connectoren

Wizard zum Anlegen von Automations-Connectoren

Zum Verwenden des E-Mail-Inbound Connectors wird eine separate Mailbox für ScriptRunner benötigt, an welche die Legacy Systems ihre E-Mails senden können. Die einmalige Einrichtung des Zugriffes auf die Mailbox erfolgt serverseitig. ScriptRunner greift per IMAP auf diese Mailbox zu und prüft die E-Mails auf passenden Absender sowie eine entsprechende Semantik in Betreff und Body der E-Mail. Für die Semantik stehen verschiedene Optionen zur Verfügung, um den Connector auf die Möglichkeiten des Legacy Systems (Sender) anzupassen.

Web Service Connectoren konfigurieren

Nach dem Öffnen der Automation App werden die Automation Connectoren aufgelistet.

Der "Local Loopback Web Service Connector" kann dazu verwendet werden, aus einer laufenden Aktion eine weitere Aktion zu starten. Das ermöglicht zum einen den Aufbau von Sequenzen aus Aktionen oder die Gestaltung komplexer Abläufe mittels einer steuernden Aktion (auf Grundlage eines Steuerscripts) sowie aufgerufenen Einzelaktionen. Zu beachten ist dabei, dass eine Datenübergabe zwischen den in ScriptRunner unabhängigen Aktionen derzeit nur über eine lokale Datei möglich ist.

Der "Web Service Connector Example" kann in der Trial Phase zum Testen von Aktionsaufrufen durch Drittsysteme verwendet werden.

Sollen unterschiedliche Systeme Aktionen in ScriptRunner aufrufen können, sind mehrere Connectoren einzurichten und zu lizensieren.

 

Web Service Connectoren dienen einer integrierten Automation mit Drittsystemen

Web Service Connectoren dienen einer integrierten Automation mit Drittsystemen

Die Konfiguration eines Web Service Connectors wie hier im Beispiel in der Betriebsart Backendkopplung gestaltet sich recht einfach. Benötigt werden: 

  • Absender-IP Adresse: nur dieses System wird als REST Caller akzeptiert
  • Account für Authentifizierung sowie Zugangsbeschränkung: mit diesem Account authentifiziert sich der Caller Prozess an ScriptRunner Server. Der Account in der Rolle HelpDesk kann in der "Authorize & Delegate" App unter Festlegung des Authentifizierungsverfahren angelegt werden.
  • Delegation der Aktion: Aktionen, welche vom Caller System aufgerufen werden dürfen, müssen an den Account zur Caller Authentifizierung delegiert werden.

Durch diese Vorgehensweise ist sichergestellt, dass nur Systeme Aktionen in ScriptRunner aufrufen können, welche 

  • identifiziert
  • authentifiziert
  • und auf die Aktion(en) berechtigt sind.   

Beispiel einer Konfiguration für die Backendkopplung mit Web Service Connector.
Beispiel einer Konfiguration für die Backendkopplung mit Web Service Connector.

 

Aufrufen einer Aktion

Zum Aufrufen einer Aktion in ScriptRunner durch ein Drittsystem ergeben sich verschiedene Möglichkeiten.

Viele Workflow- und ITSM Systeme bieten inzwischen die Konfiguration eines REST Clients innerhalb der Application bzw. am Application Backend. Dort können i.d.R die Authentifizierung, die REST Methoden sowie die Datenübergabefomate (URL, JSON) im Details festgelegt werden.

Eine weitere Möglichkeit ist der Aufruf mittels eines Scriptes in JavaScript, PowerShell oder andere. In diesem Fall ruft das Drittsystem das Script auf, übergibt die Parameter und das Script ruft den Web Service in ScriptRunner auf. Diese Möglichkeit ist anwendbar für Systeme ohne einen REST Client sowie in ScriptRunner Aufrufe, welche direkt in Webseiten integriert werden können.

Eine spezielle Variante für die Einbindung in Webpages am Frontend ist das ScriptRunner Portal Widget.

scriptrunner-web-service-connector (2)

Varianten zum Aufrufen einer Aktion in ScriptRunner

Die dritte Möglichkeit bieten konfigurierbare und ausführbare REST Client Programme wie bspw. cURL. So lassen sich Monitoringsysteme auf Linux wie Nagios oder andere mit ScriptRunner koppeln. Das Monitoringsystem startet bei einem bestimmten Event einen parametrisierten cURL-Aufruf, der seinerseits mit dem ScriptRunner Server kommuniziert.   

Methoden der API

Der Web Service Connector unterstützt drei API-Varianten: 

  • Webhook API
  • ODATA API
  • M365 PowerAutomate API  

Speziell unter Verwendung der ODATA API lassen sich Aktionen so einrichten, dass sie noch kein konfiguriertes Zielsystem für die auszuführende Aktion enthalten. So können die Aktionen flexibel für verschiedene Zielsysteme eingesetzt werden, z.B. für verschiedene Server oder unterschiedliche M365 Tenants.  
 
Die Caller-Methodik und Syntax  für die Verwendung der ScriptRunner APIs können im PowerShell Script in unseren Action Packs eingesehen werden. 

Verbesserte Reports App

Die verbesserte "Reports" App beseitigt die bisherigen Limitierungen vollständig und lässt sich durch die Neugestaltung im Detail deutlich einfacher nutzen. Insbesondere das schneller Filtering und die drilldown-Funktionalität fallen sofort ins Auge.  
 
Eine wesentliche Grundlage dafür wurde mit dem serverseitigen Filtern und partiellen Nachladen geschaffen, um Teilmengen aus einer sehr großen Reportmenge viel schneller in der App anzeigen zu können. Damit ist auch die Anzeigelimitierung auf die 500 neusten Reports aufgehoben. Es können nun jegliche Reports aus der Gesamtmenge angezeigt werden.  
 
Beim Wechsel in die Reports App werden standardmäßig alle 20 neusten Reports angezeigt. In der Zeitstrahldarstellung in der Grafik steht der jüngste Report ganz rechts. 
 
Um das Handling und das Filtering für den Anwender so einfach wie möglich zu gestalten, wurde in der App ganz oben eine Schnellfilterleiste eingeführt und das bisherige Filterboard entfernt. 
 
Die Schnellfilterleiste ermöglicht das gezielte Ausfiltern von Reports für:

  • Erfolgreich abgeschlossenen Aktionen 
  • Fehlerhaft abgeschlossenen Aktionen
  • Abgeschlossene Scripted Queries
  • Zeitgesteuerte Aktionen

In Kombination mit der Anzeige:

  • aller Reports, die obigen Kriterien erfüllen
  • der Reports für die von mir ausgeführten Aktionen, die die obigen Kriterien erfüllen
  • einer bestimmten Zeitspanne  

 

In der Titelzeile werden die Anzahl der gefilterten Elemente zur Gesamtzahl angezeigt, es kann die Anzahl der gleichzeitig angezeigten Elemente 20-50-100 gewählt werden und es lässt sich in diesen Schritt in der Zeitleiste zu älteren und neueren Reports entlanggleiten.


Mit einem Klick auf den jeweiligen Zeitbalken öffnet sich der entsprechende Einzelreport. Die Anzahl der unter der Grafik aufgelisteten Reports entspricht der gefilterten Auswahl von oben.

Erweiterte Filteroptionen im Filter-Panel

Erweiterte Filteroptionen im Filter-Panel

Über den Button "all filters" kann das Filterpanel geöffnet werden. Im oberen Drittel finden sich die Filter aus der Schnellfilterleiste wieder. Ergänzt werden diese Filter um Selektionsmöglichkeiten für:

  • Ausgewählte Aktionen, welche Reports erzeugt haben
  • Ausgewählte Zielsysteme, auf denen Aktionen ausgeführt wurden
  • Ausgewählte Scripte, welche in Aktionen oder Script Queries verwendet wurden
  • Ausgewählte Benutzer, welche Reports durch gestartete Aktionen erzeugt haben 

Mit dem Schalter "Filter reset" lässen sich schnell das Standfiltereinstellungen wieder herstellen. 

Verbesserungen am ScriptRunner Server

Am ScriptRunner Server wurden wie in den bisherigen Releases wieder kleinere Verbesserungen und Technologieupdates vorgenommen. So wurde ein besseres Handling großer Datenmengen zwischen Frontend und Server umgestellt, um eine schnellere Anzeige und einen schnelleren Zugriff auf Teilmengen an Daten z.B. in der Reports App im Portal zu ermöglichen.

Für PowerShell 7 wurden die built-in Module erweitert, sowie einige kleinere Fehler für PowerShell generell gefixt.

Die Configuration im IIS für das Portal und die Web Apps wurde erweitert und zwei neue Fehlerseiten eingeführt. Die generelle Fehlerseite wird angezeigt, wenn im ScriptRunner Pfad …/scriptrunner/... Fehler bei der Eingabe erfolgen oder Programmelemente der Frontends nicht gefunden werden.

Eine zweite Fehlerinformation wird im Portal angezeigt, wenn HTML-Reports nicht mehr im Reports-Verzeichnis verfügbar sind.

neue Fehlerseite für ScriptRunner Frontends

Neue Fehlerseite für ScriptRunner Frontends

Community License

Die Community License ermöglicht den Einsatz von ScriptRunner zu Demonstrationszwecken und im nicht produktiven, persönlichen Einsatz bei IT Pros, insbesondere bei MVPs, Partnern sowie Admins, welche ScriptRunner hin und wieder nutzen wollen.

Eine Community License kann im ScriptRunner Portal nach dem Ablauf der Trial Period aktiviert werden. Voraussetzung ist eine Online-Verbindung. Eine Offline-Aktivierung ist nicht möglich.

Registrierung einer abgelaufenen Trial License als Community License

Registrierung einer abgelaufenen Trial License als Community License

Eine einmal aktivierte Community License kann jederzeit in eine kommerzielle Version ohne Neuinstallation umgewandelt werden. 
 
Die Community License ist funktional limitiert: 

  • Maximal 10 Scriptausführungen pro Tag (Aktionen, Scripted Queries)
  • Maximal 2 Benutzer in Administrator oder Helpdesk Rolle
  • Maximal 2 Benutzer in Enduser Rolle
  • Alle Connectoren sind deaktiviert 

 
Für die Community License besteht kein Anspruch auf Supportleistungen.
Disclaimer: Für die Community License besteht kein Anspruch auf Supportleistungen.

 

Ausblick auf Portal Edition R4

Das Portal wird in Funktionalität und User Experience auch im Release 4 weiter vorangetrieben. Im Fokus stehen dabei die Neuentwicklung eines Dashboards, die Einführung eines weiter besserten UI-Design sowie die erste Version der neuen "Configuration" App für Credentials und Targets im Portal. Wie in jedem neuen Release der Portal Edition werden am ScriptRunner Server ebenfalls kleinere Verbesserungen und Features Einzug halten.

 

Zusammenhängende Posts

12 min read

ScriptRunner Portal Edition R5 – Mission erfüllt

16 min read

ScriptRunner Portal Edition R4

Über den Autor: