Das erste Release auf neuer Plattformtechnologie ist verfügbar! Nach dem erfolgreichen Start mit ausgewählten Kunden wird das Release nun auch für die breite Nutzung zur Verfügung gestellt. Der Fokus liegt vor allem auf Testnutzern und Neukunden sowie auf Kunden, die auf die neue Plattform migrieren wollen. 

Wichtiger Hinweis: Das In-Place-Upgrade eines bestehenden ScriptRunners wird erst ab dem nächsten Release unterstützt. Wenn du dein System aktualisieren möchtest, wende dich bitte an unseren Support.

Dieser Blogbeitrag fasst die wichtigsten Neuerungen für den Single-Node-Betrieb zusammen. 

• Azure Marketplace-Bereitstellung
• Setup und erste Schritte für Administratoren
• Neues KI-Hilfesystem
• Neue Dokumentationsversionen
• Neuer Lizenzierungsservice
• Zentrale Datenspeicherung und Datenbank
• Knotenüberwachung und Wartung
• Skriptverwaltung mit integriertem Git (lokal und remote)
• Neue Teamressourcen für Passwortsicherheit und Benachrichtigungen
• Azure Key Vault als zentraler Tresor für vertrauliche Daten (Secrets)
• PnP PowerShell im M365 Target
• Neue Query-Einstellungen
• Übergabe von Parametern an eine Query per URL
• Parallele Verwendung mehrerer IdM-Anbieter für die Authentifizierung von Nutzern 
   

Da diese Plattform mit einer Reihe von Änderungen und Weiterentwicklungen nicht nur für Single-Node- sondern auch für Multi-Node-Umgebungen einhergeht, werden diese Änderungen in den nächsten Wochen in der separaten Blogserie "News & Changes" behandelt.

Funktionen, die aus ScriptRunner Enterprise entfernt wurden

Die neue Plattformarchitektur führt auch zu Änderungen bei früheren Funktionen, die jetzt überflüssig sind und nicht mehr unterstützt werden.

• IIS Web-Server Unterstützung: Das Portal wird ausschließlich über den integrierten Webservice bereitgestellt.  
• SQL Server-Konnektor: Alle Berichte werden jetzt in der ScriptRunner-Datenbank gespeichert. Ein separater externer Speicher ist nicht mehr erforderlich. Da sich die Datenbankstruktur geändert hat und in Version 7.0 auch Konfigurationsdaten enthält, können die Daten aus der Audit-Datenbank nicht mehr verwendet werden. Dieser Konnektor ist daher überflüssig.
• E-Mail-Inbound-Konnektor: Durch die Verwendung von Webservice-Schnittstellen auf vielen Systemen ist die frühere Verbindung per E-Mail überflüssig geworden. Die neue Plattform nutzt die Rest-API zur Integration mit Drittsystemen.
• Dateibasierte Skriptverwaltung: Diese wurde durch eine Git-basierte Skriptverwaltung ersetzt (siehe auch unten).

Abkündigung aller Releases der ScriptRunner Portal Edition

Die Versionen der ScriptRunner Portal Editionen R1 bis R5 wurden mit Wirkung zum 31. Dezember 2024 bereits abgekündigt. Für diese Versionen erfolgen keine Fixes oder Anpassungen mehr. Treten bereits bekannte Fehler auf, so wurden diese bereits in Folgeversionen behoben. Als letztes Release auf der alten Plattform wird weiterhin die Ultimate Edition 6 unterstützt. Kunden, die noch nicht auf die neue Plattform wechseln wollen, sollten die Portal Edition R1 bis R5 auf das letzte Fix-Release der Ultimate Edition 6 updaten (hier liegt die Übersicht der Releases).

Sollten bisher unbekannte Fehler auftreten, werden diese erst in den Releases der neuen Plattform, Enterprise Version 7.0 und später, behoben.  

Azure Marketplace Deployment

Das neue Deployment eignet sich zum schnellen Testen der neuen Version, aber auch für den produktiven Einsatz von ScriptRunner, vor allem wenn die Automatisierung und Verwaltung von Diensten und Ressourcen in Entra ID, Azure und Microsoft 365 im Mittelpunkt des Deployments stehen. ScriptRunner wird automatisch in deinem eigenen Tenant in einer separaten Ressourcengruppe implementiert. Nach dem Marketplace-Deployment sind nur noch wenige Konfigurationsschritte erforderlich, um die Integration in deinen Tenant abzuschließen. Du kannst die Software-Instanz selbst betreiben oder dies an uns oder einen Partner auslagern (Azure Marketplace: Hier ist ScriptRunner ab Juni '24 verfügbar).

Neues PowerShell Settings-Modul

Für die neue Softwareplattform Enterprise Version 7.0 wurde ein neues PowerShell-Modul entwickelt, das auf der ScriptRunner API basiert und daher funktional erweitert wurde. Das Modul wird bei der Einrichtung auch auf dem Server installiert. Neben vielen ähnlichen Funktionen wie im vorherigen Modul Einstellungen gibt es viele neue Cmdlets für neue Funktionen und Einstellungen.

Auch die Benennung der Cmdlets wurde geändert. Sie beginnen jetzt nach dem Standard-Kommando Get/Set/... etc. mit Srx, beispielsweise Get-SRXLicense oder Get-SRXAzureHome.

Zeige alle Befehle des neuen Einstellungsmoduls in der Powershell-Konsole an:

Get-command -module ScriptrunnerSettings -ShowCommandInfo

Die vollständige Hilfe für ein Cmdlet aus dem Settings-Modul anzeigen:

Get-Help SrxAzureHome -Full

Das Settings-Modul befindet sich in: Drive:\Program Files\ScriptRunner\Services\Bin\PsModules\

Einrichtung und Inbetriebnahme für Administratoren

Die ScriptRunner-Automatisierungsplattform kann weiterhin mit unternehmensinternen Ressourcen betrieben werden. Mit Enterprise Version 7.0 haben sich die Systemvoraussetzungen geändert (siehe: Systemvoraussetzungen). ScriptRunner Enterprise Version 7.0 benötigt Windows Server 2022 als Betriebssystem sowie das .NET 8.0 Hosting Bundle (LTS), das vorinstalliert sein muss. 

Installationshinweis bei fehlendem .NET 8.0 Hosting Bundle 

ScriptRunner wird mit zwei Hosts ausgeliefert, darunter PowerShell 5.1 und PowerShell 7.4 (LTS). Welchen du zur Laufzeit verwenden kannst, hängt von der Verfügbarkeit der PowerShell-Module des Anbieters ab. Die Module können von der PowerShell Gallery heruntergeladen und auf dem ScriptRunner Server installiert werden.

Während des Setups können unsere neuen Konfigurationsbeispiele installiert werden. Nach der Installation stehen zahlreiche Skripte und Beispielkonfigurationen für Zielsysteme, Queries und Aktionen zur Verfügung, mit denen der Funktionsumfang von ScriptRunner schnell erschlossen und demonstriert werden kann.

Der neue Bereich "Getting started" bietet eine Übersicht über die neuen Konfigurationsbeispiele. Dieser Bereich wird während der Testphase immer angezeigt und kann bei Bedarf nach Lizenzierung der Software über das Raketensymbol oder das Helpdesk-Menü oben rechts aktiviert werden.  

"Getting started" für Neueinsteiger in ScriptRunner 

"Getting started" enthält neben sofort lauffähigen Beispielen auch welche, die noch einer Anpassung an die eigene Infrastruktur bedürfen sowie verschiedene Einstiegsvideos. Zu jedem Beispiel einer Aktion und den darin verwendeten Elementen gibt es eine Schritt-für-Schritt-Anleitung für die notwendigen Anpassungen.  

Die Themen reichen von PowerShell über Active Directory, EntraID und verschiedene M365 Services bis hin zu Azure, VMware, Hyper-V und Filesystem.

Neues Hilfesystem mit KI

Das bisherige, kontextbezogene Hilfesystem wurde ersetzt durch die Hilfe mit einem KI-Assistenten. Dieser ist sowohl im Produkt als auch über unsere Support-Site zu erreichen.

Der Assistent erlaubt natürliche Anfragen und beantwortet diese mit Verlinkungen auf die Quellen in unserer Dokumentation. Anfragen können beispielsweise lauten:

• "What is an action?"
• "How do I configure a user query to EntraID?"
• "What are my input validation options?"
• "Can I validate my scripts at runtime?"
• "What do I do to configure a connection to Teams?"
• "How do I edit a script?"

Interaktive Hilfe mit KI-Agent

Neue Versionen der Dokumentation

Die zahlreichen Änderungen an der Plattform haben neue Versionen der meisten Guides auf unserer Supportseite erforderlich gemacht. Die neuesten Versionen werden standardmäßig angezeigt. Für alle älteren Versionen der Software kann oben in der Themenleiste des jeweiligen Guides die passende Version ausgewählt werden.

Guide Versionsauswahl

Neuer Lizenzservice

Die Lizenzaktivierung und -verteilung wurde komplett überarbeitet. Sowohl die Aktivierung als auch die Verteilung der Lizenzen erfolgt nun automatisiert über eine Cloud-Plattform. Werden Lizenzen von ScriptRunner Sales neu ausgegeben oder erweitert, wird dies automatisch im Portal gemeldet und dort vom Administrator bestätigt. Anschließend werden die Lizenzen freigeschaltet. Für ScriptRunner-Umgebungen, die komplett offline laufen, also inklusive Portalzugriff im Browser, können Lizenzen auch weiterhin manuell aktiviert werden, bequem im Portal oder über ein Settings Cmdlet.

Aktivierung einer Lizenz online

Die Lizenzierung hat nun ein Umlaufverfahren für Accounts in allen Nutzerrollen erhalten (bislang nur Endbenutzer). Damit entfällt das bisher notwendige "Freischalten" von Lizenzen ausgeschiedener Nutzer. Das Umlaufverfahren entfernt inaktive Accounts automatisch nach Ablauf von 60 Tagen für Administrator- und Helpdesk-Rollen und nach 90 Tagen für Enduser. Eine Reaktivierung von Accounts nach einer Auszeit von gleicher Dauer ist ebenfalls nicht mehr notwendig.

Zentrale Datenhaltung 

Das Modell der Datenspeicherung für Systemdaten, Konfigurationsdaten, Reports und Statistiken wurde auf die zentrale Verwendung einer Datenbank umgestellt. Die Größe der Datenbank ist jetzt unbeschränkt, und es ist kein Umlaufmechanismus mehr erforderlich. Durch die standardmäßige Verwendung einer Datenbank entfällt der bisherige SQL-Konnektor.

Folgende Varianten sind möglich:

• Azure Marketplace-Bereitstellung
• SQLite – Standard für Trial und Single Node Instanz
• SQL Server – Single Node und Multi Node Instanzen
• Azure SQL DB – Single Node und Multi Node Instanzen
• MongoDB Standard – Single Node und Multi Node Instanzen
• Mongo Atlas DB – Single Node und Multi Node Instanzen

Es kann jeweils nur eine Datenbank verwendet werden. Das Sichern und Wiederherstellen ist daher Teil des Datenbankbetriebs im Unternehmen. ScriptRunner selbst stellt kein Backup zur Verfügung.

Die Einstellungen für die Datenbank werden mit dem Settings Cmdlet Set-SRXPersitance vorgenommen.

Unabhängig vom Data Storage werden die System Logs und die Engine Logs weiterhin im Filesystem der jeweiligen Nodes geschrieben.

Node Monitoring

Neu eingeführt wurde das Node Monitoring, mit dem die einzelnen Knoten einer ScriptRunner-Umgebung überwacht werden können. Das Node Monitoring besteht aus einer Statusanzeige sowie einer Ereignisanzeige für einen Knoten. Für einen schnellen Überblick wird im Hauptmenü "Monitoring" der Punkt "Nodes" ausgewählt. Die Übersicht zeigt alle Knoten einer Umgebung auf jeweils einer Statuskachel. Die Statusanzeige umfasst den Zustand des Knotens und den Status der angeschlossenen Ressourcen, wie z.B. die Verbindung zum Password Server, zum Git-Repository oder zum Lizenzservice (einer pro Umgebung). Außerdem werden die Version der Software auf dem Knoten sowie die letzten Ereignisse symbolisiert.

Übersicht über den Status pro Knoten

Durch Klicken auf die Kachel werden die Details angezeigt. Das Ereignisprotokoll des Knotens gibt Auskunft über Fehler, Warnungen und Informationen.

Detailansicht zu Events im Node-Monitoring  

Verwaltung von Skripten mit built-in Git – lokal und remote

Die bisherige Verwaltung von Skripten direkt auf dem Filesystem des ScriptRunner Servers wurde durch die Verwendung eines eingebauten Git-Mechanismus ersetzt. Dieser Mechanismus ermöglicht nun die Verwaltung, Bearbeitung und Nutzung von Skripten auf moderne Art und Weise.

Der Zugriff auf die verwalteten Skripte kann im Portal und/oder über VS Code mit Enterprise Extension und ScriptRunner API sowie über VS Code direkt mit einem Git Server erfolgen. (Link zu Visual Studio Marketplace  –  ScriptRunner Enterprise for VS Code)

Prinzip der Git-verwalteten Skriptquellen (Script Sources)

Den organisatorischen Kern des Script Managements bilden die Git-verwalteten Script Sources. Alle Script Sources haben eine Repräsentation in Git-verwalteten Ordnern im Dateisystem eines Knotens. Es wird unterschieden zwischen Local Script Sources und Remote Script Sources.

Local Script Sources existieren nur auf dem Knoten, werden dort lokal von Git verwaltet und sind nur für reine Single Node Umgebungen geeignet. Eine Synchronisation zwischen verschiedenen Nodes ist nicht möglich. Der Zugriff auf die Skripte erfolgt über das Portal oder über VS Code mit der Enterprise Extension.

Remote Script Sources sind jeweils mit einem Repository auf einem Git Server verbunden. Dies ist eine mögliche Konfiguration für Single Node (auch im Mix mit Local Script Sources) und die ausschließliche Konfiguration im Multi Node Betrieb.

Auf beiden Seiten werden Änderungen an Skripten in Remote Script Sources synchronisiert, unabhängig davon, auf welchem Weg sie vorgenommen wurden.  So kann ein Skriptentwickler seine Änderungen im Portal vornehmen und diese werden in das zentrale Repository auf dem Git Server synchronisiert. Ebenso umgekehrt. Alle weiteren Knoten im Multi-Node-Betrieb synchronisieren sich automatisch mit dem zentralen Repository auf dem Git Server. Das Entfernen einer Remote Script Source löscht nur die Repräsentation und die Skripte auf ScriptRunner. Der Inhalt im Repository auf dem Git Server bleibt erhalten.

Remote Script Source auf einem Git Server Repository für das Azure Admin-Team

Eine weitreichende Änderung sind die Script Repositories für Administratoren im Multi-Team Modus. Jedes Team in der Rolle "Administrators" kann eine oder mehrere Script Sources zugewiesen bekommen. Diese können mit verschiedenen Repositories auf Git Servern verbunden oder lokal sein. Alle Skripte in einem Team-Repository erhalten automatisch die Ownership des Teams. Gemischte Ownerships für Skripte in einem einzelnen Repository sind nicht möglich. 

Neue Teamressourcen für Passwort-Safe und Benachrichtigungen

Der Einsatz von zentralen Password Services zum besseren Schutz von Passwörtern und zum Management von Passwortzugriffen nimmt in Organisationen generell zu.  ScriptRunner unterstützt nun verschiedene Sicherheitsszenarien bei der Verwendung von Password Services.

Im einfachsten Szenario erfolgt die Konfiguration von ScriptRunner nur in der Rolle des Hauptadministrators. In diesem Fall wird ein Zugang zum Password Server in ScriptRunner hinterlegt. Für alle Passwort-Safes, auf die ScriptRunner zugreifen soll, erhält der Zugang im Passwort-Server die entsprechenden Berechtigungen (i.d.R. Lesen).

Für komplexere Szenarien mit differenzierten Zugriffen kann der Team-Modus in ScriptRunner verwendet werden. Jedes Team erhält eigene Ressourcen und kann nur diese verwalten. Das betrifft Skripte, Zielsysteme, Queries und Aktionen und nun auch den Zugriff auf einen eigenen Passwortsafe. Damit ist es möglich, verschiedene Teams mit jeweils eigenem Passwort-Safe auf einem Passwort-Server zu unterstützen. 

Neu sind ScriptRunner-Ressourcen für jedes Administratoren-Team

Der Versand von E-Mail-Benachrichtigungen in großen, globalen IT-Organisationen über eine einzige Mailbox ist oft nicht sinnvoll. Mit der neuen Einstellung für E-Mail-Benachrichtigung kann ein zuvor erstelltes Credential mit E-Mail-Adresse und Passwort ausgewählt werden. Zur Laufzeit stellt es die Einstellung für den Versand von Benachrichtigungs-E-Mails an genau dieses Postfach dar. Jedes Team kann nun sein eigenes Postfach dafür definieren.

Azure Key Vault als zentraler Safe für Secrets

Azure Key Vault ist ein Dienst zur sicheren Speicherung von Secrets. ScriptRunner unterstützt nun das Speichern und Verwenden von Secrets in Azure Key Vault als Alternative zum lokalen Windows Credential Store von Windows Server, der nur in Single Node Umgebungen sinnvoll einsetzbar ist.

Das Anlegen und Speichern eines Secrets in Azure Key Vault im Portal

Ein einmal angelegtes Secret kann jederzeit geändert und gelöscht werden

Voraussetzung für die Verwendung von Azure Key Vault ist, dass der ScriptRunner Service in Azure registriert wurde und somit die Einstellungen für den Azure Home Tenant in ScriptRunner konfiguriert sind. Anschließend kann der Azure Key Vault direkt mit dem Cmdlet New-SrxAzureHomeVault erstellt und verbunden werden.

Liste der ScriptRunner Secrets in einem Azure Key Vault

Die Eintragung der jeweiligen Secrets erfolgt seitens ScriptRunner nicht mit Klarnamen, sondern als Referenz-ID. Dadurch wird zum einen sichergestellt, dass sich ScriptRunner Secrets im Vault eindeutig von anderen Einträgen unterscheiden und zum anderen, dass die direkte Referenz nicht unmittelbar erkennbar ist.

PnP PowerShell im M365 Target

PnP PowerShell ist ein plattformübergreifendes PowerShell-Modul mit über 650 Cmdlets, die mit Microsoft 365-Umgebungen und -Produkten wie SharePoint Online, Microsoft Teams, Microsoft Planner, Microsoft Flow und mehr zusammenarbeiten. Es läuft unter Windows, Linux und MacOS (Mehr zu PnP PowerShell hier).

Mit dem neuen Dienst in Azure und M365 Target können die Möglichkeiten von PnP PowerShell nun optimal genutzt werden. Dazu ist das entsprechende PnP PowerShell Modul auf ScriptRunner im globalen Maschinenkontext zu installieren, ein entsprechendes Service Principal in EntraID anzulegen (oder ein vorhandenes zu verwenden) und anschließend ein PnP Service in einem M365 Target hinzuzufügen und zu konfigurieren.

Neuer Service PnP PowerShell in ScriptRunner

Neue Einstellungen für Queries

Queries sind ein mächtiges Feature, um sehr benutzerfreundliche Actions mit Auswahlmöglichkeiten zu gestalten. Technisch gesehen wird eine Datenabfrage an ein Verzeichnis oder ein Drittsystem entweder über REST oder durch die Verarbeitung eines Skripts, einer Liste oder einer Datei durchgeführt. Die Ergebnisdaten einer Abfrage können sowohl einfache Strings als auch komplexe Strukturen in JSON sein. Die Darstellung im Auswahlmenü selbst hängt vom Anzeigewert ab. Unser Coding Guide enthält weitere Informationen zu Abfragen. 

Um die Menge der Datensätze, die ohne Suchfunktion im Portal sofort im Auswahlmenü angezeigt werden, sinnvoll zu begrenzen, kann nun die Anzahl der sofort angezeigten Einträge begrenzt werden. Damit entfällt die bisherige Begrenzung auf 500 Einträge mit einer Suche.

Einstellungen für Anzahl der Einträge und Timeout für Queries

Insbesondere Anfragen mittels PowerShell-Skript an ein System oder eine Datenquelle können länger dauern, wenn die Einträge nicht aus dem Cache geladen, sondern mittels Echtzeitmodus jeweils aktuell ermittelt werden sollen. Um zu lange Abfragezeiten z.B. durch hohe Systemauslastung der Datenquelle zu vermeiden, kann nun ein Timeout für die Abfrageoperation gesetzt werden.

Generell wird empfohlen, Queries mit PowerShell-Skripten im Cached Mode zu betreiben oder eine alternative Query unter direkter Verwendung von AD oder Entra/Azure zu verwenden. 

Übergabe von Parametern an eine Query über Portal-URL

Der Aufruf von Actions und Queries erfolgt in der Regel über das Portal oder das Portal Widget. Diese Methode ist für die Verwendung durch Drittsysteme wie ITSM, Workflow, IDM oder Monitoring für eine nahtlose End-to-End-Automatisierung nicht geeignet. Daher gibt es auch die Möglichkeit des Aufrufs über URL. 

Eine Möglichkeit nutzt die URL zur Übergabe von Werten an das Portal, z.B. durch einen Link im Quellsystem auf das ScriptRunner Portal.

Mit "https://mycorp/scriptrunner/portal/#/actions/37?username=John%20Smith" wird beispielsweise das Formular im Portal in Run aufgerufen und das Feld 'username' mit dem Wert 'John Smith' vorbelegt.

Vorbelegtes Formularfeld via Portal-URL

Diese Möglichkeit war bisher nur Feldern vorbehalten, denen keine Queries zugeordnet sind. Neu in dieser Version ist die Verwendung als Input für die Suche einer interaktiven Query.

Im obigen Beispiel ist dem Parameter 'username' in der Action-Konfiguration nun eine Query für die Suche nach Accounts im Directory zugeordnet. Mit "https://mycorp/scriptrunner/portal/#/actions/37?qry_username=John" wird das Suchfeld der Query mit dem Wert 'John' belegt und automatisch gestartet, alle Werte mit 'John' im username ermittelt und das Auswahlmenü angezeigt. 

Suchfeld der Query, mit 'John' belegt

Mit dieser Lösung ist es nun möglich, eine Maske zum Ausführen einer Aktion über eine Link-URL aus einem externen UI vollständig zu füllen und die Queries automatisch auszuführen. 

Ein Beispiel hierfür könnte ein Ticket in einem ITSM sein, dessen Felder per Link hinter einem Button an eine ScriptRunner Action übergeben werden. Die Action öffnet sich im Browser, der Helpdesk-Mitarbeiter überprüft die automatisch übernommenen Eingaben und startet die Action. Es handelt sich also um eine Frontend-Frontend-Kopplung, die schnell und unkompliziert realisiert werden kann. Alternativ steht für eine vollautomatisierte End-to-End-Kopplung unser Web Service Connector zur Verfügung.  

Parallele Verwendung mehrerer IDM-Provider zur Nutzerauthentifizierung

Mit der neuen Version von ScriptRunner ist es nun möglich, verschiedene Mechanismen zur Nutzerauthentifizierung parallel zu verwenden. Dies hilft insbesondere bei der Migration zwischen und auf verschiedene IDM-Systeme. Zum Beispiel, wenn ein Teil der Nutzer sich noch direkt über Active Directory authentifiziert und ein anderer Teil bereits über Entra ID. Oder wenn ein übergreifendes IDM wie OKTA eingeführt und die Benutzerauthentifizierung schrittweise umgestellt wird. 

Die Konfiguration der IDM-Verbindungen erfolgt über Cmdlets an ScriptRunner sowie über entsprechende Einstellungen und Gruppen im IDM.  

Ausblick auf Version 7.1

Auch die Version 7.1 von ScriptRunner Enterprise wird wesentliche neue Features sowie eine Reihe von Verbesserungen enthalten. Die wichtigsten Neuerungen werden sein:

• Aktionen: Ausführen einer Aktion zu einem vom Nutzer konfigurierbaren Zeitpunkt.
• Aktionen: Genehmigung der Ausführung einer Aktion durch einen oder mehrere andere Nutzer.
• Aktionen: Neue Kalenderansicht zur besseren Übersicht, Erstellung und Überwachung geplanter Aufgaben.
• Berichte: Automatisches Anonymisieren und Löschen von Berichten nach einer konfigurierbaren Zeitspanne, um die Compliance und den Datenschutz zu verbessern.
• Compliance: Nachverfolgung von Konfigurationsänderungen in ScriptRunner zu Kontroll- und Auditzwecken.

Unsere Roadmap gibt einen Überblick über unsere Pläne. 

Weiterführende Links

• ScriptRunner Release Guide für Enterprise Version 7.0
• ScriptRunner Roadmap
• System requirements
• Download .NET 8.0 Hosting Bundle (LTS)
• Microsoft Azure Key Vault
• "Input with Queries" – Artikel im Coding Guide zum Thema Abfragen
• Link zu Visual Studio Marketplace  –  ScriptRunner Enterprise for VS Code