Hinzufügen und Ausführen von PowerShell-Skriptcode in Standardworkflows für Azure Logic Apps (Vorschau)
Gilt für: Azure Logic Apps (Standard)
Hinweis
Diese Funktion befindet sich in der Vorschauphase und unterliegt den Zusätzlichen Nutzungsbedingungen für Microsoft Azure-Vorschauversionen.
Um benutzerdefinierte Integrationsaufgaben inline in Ihrem Standardworkflow in Azure Logic Apps auszuführen, können Sie direkt in Ihrem Workflow PowerShell-Code hinzufügen und ausführen. Verwenden Sie für diese Aufgabe die Inlinecode-Aktion namens PowerShell-Code ausführen. Diese Aktion gibt die Ergebnisse Ihres PowerShell-Codes zurück, sodass Sie diese Ausgabe in nachfolgenden Aktionen Ihres Workflows verwenden können.
Diese Funktion bietet die folgenden Vorteile:
Schreiben Sie eigene Skripts im Workflow-Designer, um komplexere Integrationsprobleme zu lösen. Es sind keine weiteren Dienstpläne erforderlich.
Dieser Vorteil optimiert die Workflowentwicklung und reduziert die Komplexität und Kosten bei der Verwaltung weiterer Dienste.
Generieren Sie eine dedizierte Codedatei, die einen personalisierten Skriptbereich in Ihrem Workflow bereitstellt.
Integrieren Sie Azure Functions PowerShell-Funktionen, die leistungsstarke Funktionen und Vererbung für die Ausführung erweiterter Aufgaben bereitstellen.
Stellen Sie Skripts zusammen mit Ihren Workflows bereit.
In diesem Leitfaden wird gezeigt, wie Sie die Aktion in Ihrem Workflow hinzufügen und den PowerShell-Code hinzufügen, den Sie ausführen möchten.
Voraussetzungen
Ein Azure-Konto und ein Azure-Abonnement. Falls Sie kein Abonnement besitzen, können Sie sich für ein kostenloses Azure-Konto registrieren.
Der Logik-App-Standardworkflow, in dem Sie Ihr PowerShell-Skript hinzufügen möchten. Der Workflow muss bereits mit einem Trigger gestartet werden. Weitere Informationen finden Sie unter Erstellen eines Standard Logik-App-Beispielworkflows.
Sie können jeden Trigger für Ihr Szenario verwenden, aber als Beispiel verwendet dieses Handbuch den Anforderungsauslöser namens Wenn eine HTTP-Anforderung empfangen wird und auch die Antwortaktion. Der Workflow wird ausgeführt, wenn eine andere Anwendung oder ein anderer Workflow eine Anforderung an die Endpunkt-URL des Triggers sendet. Das Beispielskript gibt die Ergebnisse aus der Codeausführung als Ausgabe zurück, die Sie in nachfolgenden Aktionen verwenden können.
Überlegungen
Das Azure-Portal speichert Ihr Skript als PowerShell-Skriptdatei (.ps1) im selben Ordner wie Ihre Datei workflow.json, die die JSON-Definition für Ihren Workflow speichert, und stellt die Datei zusammen mit der Workflowdefinition in Ihrer Logik-App-Ressource bereit.
Beim PS1-Dateiformat müssen Sie weniger „Textbausteine“ schreiben und können sich ganz auf Ihren PowerShell-Code konzentrieren. Wenn Sie die Aktion umbenennen, wird die Datei ebenfalls umbenannt. Beim Umbenennen der Datei wird die Aktion jedoch nicht umbenannt. Wenn Sie die Datei direkt umbenennen, überschreibt die umbenannte Version die vorherige Version. Wenn der Aktionsname und der Dateiname nicht übereinstimmen, wird die Datei nicht von der Aktion gefunden, und sie versucht, eine neue leere Datei zu erstellen.
Das Skript ist lokal für den Workflow. Wenn Sie dasselbe Skript in anderen Workflows verwenden möchten, zeigen Sie die Skriptdatei in der KuduPlus-Konsole an, und kopieren Sie dann das Skript, um es in anderen Workflows wiederzuverwenden.
Begrenzungen
| Name | Grenze | Hinweise |
|---|---|---|
| Skriptausführungsdauer | 10 Minuten | Wenn Sie Szenarien haben, die längere Dauer benötigen, verwenden Sie die Produktfeedbackoption, um weitere Informationen zu Ihren Anforderungen bereitzustellen. |
| Ausgabegröße | 100 MB | Die Ausgabegröße hängt vom Grenzwert für die Ausgabegröße für Aktionen ab, was im Allgemeinen 100 MB beträgt. |
Hinzufügen der Aktion „PowerShell-Code ausführen“
Öffnen Sie im Azure-Portal Ihre Standard-Logik-App und deren Workflow im Workflow-Designer.
Führen Sie im Designer folgende allgemeine Schritte zum Hinzufügen der Aktion Inlinecodevorgänge namens PowerShell-Code ausführen zu Ihrem Workflow aus.
Daraufhin wird der Bereich „Aktionsinformationen“ geöffnet. Aktualisieren Sie dort auf der Registerkarte Parameter im Feld Codedatei den vorab aufgefüllten Beispielcode mit Ihrem eigenen Skriptcode.
Informationen zum Zugreifen auf Daten aus Ihrem Workflow finden Sie weiter unten in diesem Leitfaden im Abschnitt zum Zugreifen auf Workflowtrigger und Aktionsausgaben in Ihrem Skript.
Informationen zum Zurückgeben der Ergebnisse des Skripts oder anderer Daten an Ihren Workflow finden Sie unter Zurückgeben von Daten an Ihren Workflow.
Das folgende Beispiel zeigt die Registerkarte Parameter der Aktion mit dem Beispielskriptcode:
Das folgende Beispiel zeigt den Beispielskriptcode:
# Use the following cmdlets to retrieve outputs from prior steps. # $triggerOutput = Get-TriggerOutput # $ActionOutput = Get-ActionOutput -ActionName <action-name> $customResponse = [PSCustomObject]@{ Message = "Hello world!" } # Use Write-Debug/Write-Host/Write-Output/ to log messages to Application Insights. # Write-Host/Write-Output/Write-Debug and 'return' won't return an output to the workflow. # Write-Host "Sending to Application Insight logs" # Use Push-WorkflowOutput to push outputs into subsequent actions. Push-WorkflowOutput -Output $customResponseDas folgende Beispiel zeigt ein benutzerdefiniertes Beispielskript:
$action = Get-TriggerOutput $results = "Hello from PowerShell!" Push-WorkflowOutput -Output $resultsSpeichern Sie Ihren Workflow, wenn Sie fertig sind.
Nachdem Sie Ihren Workflow ausgeführt haben, können Sie die Workflowausgabe in Application Insights überprüfen, sofern dieses Tool aktiviert ist. Weitere Informationen finden Sie im Abschnitt zum Anzeigen der Ausgabe in Application Insights.
Access-Workflowtrigger und Aktionsausgabe in Ihrem Skript
Die Ausgabewerte des Triggers und der vorherigen Aktionen werden mithilfe eines benutzerdefinierten Objekts mit mehreren Parametern zurückgegeben. Um auf diese Ausgaben zuzugreifen und sicherzustellen, dass Sie den gewünschten Wert zurückgeben, verwenden Sie die Cmdlets Get-TriggerOutput, Get-ActionOutput und Push-WorkflowOutput sowie alle entsprechenden Parameter, die in der folgenden Tabelle beschrieben sind. Hier ein Beispiel:
$trigger = Get-TriggerOutput
$statusCode = $trigger.status.ToString();
$action = Get-ActionOutput -ActionName Compose
$actionOutput = $action.outputs['actionOutput'].ToString();
$populatedString = "Send the $statusCode for the trigger status and $actionOutputName."
Push-WorkflowOutput -Output $populatedString
Hinweis
Wenn Sie in PowerShell in einem komplexen Objekt auf ein Objekt vom Typ JValue verweisen und dieses Objekt einer Zeichenfolge hinzufügen, tritt eine Formatausnahme auf. Verwenden Sie ToString(), um diesen Fehler zu vermeiden.
Antwortausgaben von Triggern und Aktionen
In der folgenden Tabelle sind die Ausgaben aufgeführt, die generiert werden, wenn Sie Get-ActionOutput oder Get-TriggerOutput aufrufen. Der Rückgabewert ist ein komplexes Objekt namens PowershellWorkflowOperationResult, das die folgenden Ausgaben enthält.
| Name | Typ | BESCHREIBUNG |
|---|---|---|
| Name | String | Der Name des Triggers oder der Aktion |
| Eingaben | JToken | Die Eingabewerte, die an den Trigger oder die Aktion übergeben wurden |
| Ausgaben | JToken | Die Ausgaben des ausgeführten Triggers oder der ausgeführten Aktion |
| StartTime | DateTime | Die Startzeit für den Trigger oder die Aktion |
| EndTime | DateTime | Die Endzeit für den Trigger oder die Aktion |
| ScheduledTime | DateTime | Die geplante Zeit für die Ausführung des Triggers oder der Aktion |
| OriginHistoryName | String | Der Name des ursprünglichen Verlaufs für Trigger mit aktivierter Option Split-On |
| SourceHistoryName | String | Der Name des Quellverlaufs für einen erneut ausgegebenen Trigger |
| TrackingId | String | Die Nachverfolgungs-ID des Vorgangs |
| Code | String | Der Statuscode für das Ergebnis |
| Status | String | Der Ausführungsstatus für den Trigger oder die Aktion, z. B. Erfolgreich oder Fehlgeschlagen |
| Fehler | JToken | Der HTTP-Fehlercode |
| TrackedProperties | JToken | Alle nachverfolgten Eigenschaften, die Sie eingerichtet haben |
Zurückgeben von Ausgaben an Ihren Workflow
Um Ausgaben an Ihren Workflow zurückzugeben, müssen Sie das Cmdlet Push-WorkflowOutput verwenden.
Benutzerdefinierte PowerShell-Befehle
Die Aktion PowerShell-Code ausführen umfasst die folgenden benutzerdefinierten PowerShell-Befehle (Cmdlets) für die Interaktion mit Ihrem Workflow und anderen Vorgängen in Ihrem Workflow:
Get-TriggerOutput
Ruft die Ausgabe des Workflowtriggers ab.
Syntax
Get-TriggerOutput
Parameter
Keine.
Get-ActionOutput
Ruft die Ausgabe einer anderen Aktion im Workflow ab und gibt ein Objekt namens PowershellWorkflowOperationResult zurück.
Syntax
Get-ActionOutput [ -ActionName <String> ]
Parameter
| Parameter | Typ | BESCHREIBUNG |
|---|---|---|
| ActionName | String | Der Name der Aktion im Workflow, auf deren Ausgabe Sie verweisen möchten |
Push-WorkflowOutput
Pusht die Ausgabe der Aktion PowerShell-Code ausführen an Ihren Workflow, der ein Objekt beliebigen Typs zurückgegeben kann. Wenn der Rückgabewert NULL ist, erhalten Sie vom Cmdlet einen Fehler vom Typ „NULL-Objekt“.
Hinweis
Die Cmdlets Write-Debug, Write-Host und Write-Output geben keine Werte an Ihren Workflow zurück. Die return-Anweisung gibt ebenfalls keine Werte an Ihren Workflow zurück. Sie können diese Cmdlets jedoch verwenden, um Ablaufverfolgungsmeldungen zu schreiben, die in Application Insights angezeigt werden. Weitere Informationen finden Sie unter Microsoft.PowerShell.Utility.
Syntax
Push-WorkflowOutput [-Output <Object>] [-Clobber]
Parameter
| Parameter | Typ | BESCHREIBUNG |
|---|---|---|
| Output | Verschiedene Ursachen. | Die Ausgabe, die Sie an den Workflow zurückgeben möchten. Diese Ausgabe kann einen beliebigen Typ aufweisen. |
| Clobber | Verschiedene Ursachen. | Ein optionaler Switch-Parameter, mit dem Sie die zuvor gepushte Ausgabe überschreiben können. |
Authentifizieren und Autorisieren des Zugriffs mit einer verwalteten Identität mithilfe von PowerShell
Mit einer verwalteten Identität können Ihre Logik-App-Ressource und Ihr Logik-App-Workflow den Zugriff auf alle Azure-Dienste und -Ressourcen, die die Microsoft Entra-Authentifizierung unterstützen, authentifizieren und autorisieren, ohne dass Sie Anmeldeinformationen in Ihren Code einschließen.
In der Aktion PowerShell-Code ausführen können Sie den Zugriff mit einer verwalteten Identität authentifizieren und autorisieren, sodass Sie Aktionen für andere Azure-Ressourcen ausführen können, für die Sie den Zugriff aktiviert haben. Sie können beispielsweise eine VM neu starten oder die Ausführungsdetails eines anderen Logik-App-Workflows abrufen.
Um die verwaltete Identität innerhalb der Aktion PowerShell-Code ausführen zu verwenden, müssen Sie die folgenden Schritte ausführen:
-
Überprüfen Sie für die Azure-Zielressource Folgendes:
Auf der Registerkarte Rolle reicht normalerweise die Rolle Mitwirkender aus.
Stellen Sie auf der Seite Rollenzuweisung hinzufügen sicher, dass auf der Registerkarte Mitglieder für die Eigenschaft Zugriff zuweisen zu die Option Verwaltete Identität ausgewählt ist.
Wählen Sie Mitglieder auswählen und dann im Bereich Wählen Sie verwaltete Identitäten aus die verwaltete Identität aus, die Sie verwenden möchten.
Fügen Sie in Ihrer Aktion PowerShell-Code ausführen den folgenden Code als erste Anweisung hinzu:
Connect-AzAccount -IdentityJetzt können Sie mithilfe von Cmdlets und Modulen mit der Azure-Ressource arbeiten.
Ansehen der Skriptdatei
Öffnen Sie im Azure-Portal Ihre Standardlogik-App-Ressource mit dem gewünschten Workflow.
Wählen Sie im Ressourcenmenü Ihrer Logik-App unter Entwicklungstools die Option Erweiterte Tools aus.
Wählen Sie auf der Seite Erweiterte Tools die Option Goaus, wodurch die KuduPlus Konsole geöffnet wird.
Öffnen Sie das Menü Debugkonsole, und wählen Sie CMD aus.
Wechseln Sie zum Stammspeicherort Ihrer Logik-App: website/wwwroot
Wechseln Sie unter dem folgenden Pfad zum Ordner Ihres Workflows, der die PS1-Datei enthält: site/wwwroot/{workflow-name}
Wählen Sie neben dem Dateinamen Bearbeiten aus, um die Datei zu öffnen und anzuzeigen.
Anzeigen von Protokollen in Application Insights
Wählen Sie im Azure-Portal im Ressourcenmenü der Logik-App unter Einstellungen die Option Application Insights und dann Ihre Logik-App aus.
Wählen Sie im Menü Application Insights unter Überwachung die Option Protokolle aus.
Erstellen Sie eine Abfrage, um Ablaufverfolgungen oder Fehler der Workflowausführung zu finden, z. B.:
union traces, errors | project TIMESTAMP, message
Module
PowerShell-Module sind eigenständige, wiederverwendbare Einheiten, die verschiedene Komponenten enthalten, z. B.:
- Cmdlets: Einzelne Befehle, die bestimmte Aufgaben ausführen
- Anbieter: Ermöglichen den Zugriff auf Datenspeicher (z. B. die Registrierung oder das Dateisystem) als wären sie Laufwerke
- Funktionen: Wiederverwendbare Codeblöcke, die bestimmte Aktionen ausführen
- Variablen: Speichern Daten zur Verwendung im Modul
- Andere Ressourcentypen
Ein Modul organisiert PowerShell-Code und erleichtert seine Verteilung. Sie können z. B. eigene Module erstellen, um zusammengehörige Funktionen zu verpacken, damit sie leichter verwaltet und geteilt werden können. Mit der Aktion PowerShell-Code ausführen können Sie öffentliche und private PowerShell-Module importieren.
Öffentliche Module
Öffentlich verfügbare Module finden Sie im PowerShell-Katalog. Eine Logik-App-Standardressource kann bis zu zehn öffentliche Module unterstützen. Um ein öffentliches Modul zu verwenden, müssen Sie diese Funktion wie folgt aktivieren:
Wählen Sie im Azure-Portal im Menü Ihrer Logik-App-Ressource unter „Entwicklungstools“ die Option Erweiterte Tools aus.
Wählen Sie auf der Seite Erweiterte Tools die Option Los aus.
Wählen Sie auf der Kudu Plus-Symbolleiste im Menü Debugging-Konsole die Option CMD aus.
Navigieren Sie in der Verzeichnisstruktur oder mithilfe der Befehlszeile zur Stammebene Ihrer Logik-App unter C:\home\site\wwwroot.
Öffnen Sie die Datei host.json des Workflows, und legen Sie die managedDependency-Eigenschaft auf true fest. Diese Eigenschaft ist standardmäßig bereits festgelegt.
"managedDependency": { "enabled": true }Öffnen Sie die Datei requirements.psd1. Geben Sie den Namen und die Version des gewünschten Moduls mit der folgenden Syntax ein: MajorNumber.* oder die genaue Modulversion, z. B.:
@{ Az = '1.*' SqlServer = '21.1.18147' }
Überlegungen zu öffentlichen Modulen
Berücksichtigen Sie Folgendes, wenn Sie die Abhängigkeitsverwaltung verwenden:
Bei öffentlichen Modulen benötigen Sie zum Herunterladen Zugriff auf den PowerShell-Katalog.
Verwaltete Abhängigkeiten unterstützen derzeit keine Module, bei denen Sie eine Lizenz akzeptieren müssen, indem Sie diese entweder interaktiv akzeptieren oder beim Ausführen von Install-Module die Option -AcceptLicense angeben.
Private Module
Sie können eigene private PowerShell-Module generieren. Informationen zum Erstellen Ihres ersten PowerShell-Moduls finden Sie unter Schreiben eines PowerShell-Skriptmoduls.
Wählen Sie im Azure-Portal im Menü Ihrer Logik-App-Ressource unter „Entwicklungstools“ die Option Erweiterte Tools aus.
Wählen Sie auf der Seite Erweiterte Tools die Option Los aus.
Wählen Sie auf der Kudu Plus-Symbolleiste im Menü Debugging-Konsole die Option CMD aus.
Navigieren Sie in der Verzeichnisstruktur oder mithilfe der Befehlszeile zur Stammebene Ihrer Logik-App unter C:\home\site\wwwroot.
Erstellen Sie einen Ordner mit dem Namen Modules.
Erstellen Sie im Ordner Modules einen Unterordner mit dem Namen Ihres privaten Moduls.
Fügen Sie im Ordner des privaten Moduls Ihre private PowerShell-Moduldatei mit der Erweiterung psm1 hinzu. Sie können auch eine optionale PowerShell-Manifestdatei mit der Erweiterung psd1 hinzufügen.
Wenn Sie fertig sind, sieht die vollständige Logik-App-Dateistruktur in etwa wie folgt aus:
MyLogicApp
-- execute_powershell_script.ps1
-- mytestworkflow.json
Modules
-- MyPrivateModule
--- MyPrivateModule.psd1
--- MyPrivateModule.psm1
-- MyPrivateModule2
--- MyPrivateModule2.psd1
--- MyPrivateModule2.psm1
requirements.psd1
host.json
Kompilierungsfehler
In dieser Version enthält der webbasierte Editor eingeschränkte IntelliSense-Unterstützung, die noch verbessert wird. Alle Kompilierungsfehler werden erkannt, wenn Sie Ihren Workflow speichern, und die Azure Logic Apps-Laufzeit kompiliert Ihr Skript. Diese Fehler werden in den Fehlerprotokollen Ihrer Logik-App über Application Insights angezeigt.
Laufzeitfehler
Eine Workflowaktion gibt keine Ausgabe zurück.
Stellen Sie sicher, dass Sie das Cmdlet Push-WorkflowOutput verwenden.
Fehler bei der Aktion „PowerShell-Code ausführen“: Die Benennung „{some-text}“ wurde nicht erkannt...“
Wenn Sie in der Datei requirements.psd1 falsch auf ein öffentliches Modul verweisen oder Ihr privates Modul nicht im Pfad C:\home\site\wwwroot\Modules{module-name} vorhanden ist, wird der folgende Fehler angezeigt:
Die Benennung „{some-text}“ wurde nicht als Name eines Cmdlets, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Prüfen Sie die Schreibweise des Namens, bzw. stellen Sie sicher, dass der Pfad korrekt angegeben wurde, und versuchen Sie es erneut.
Hinweis
Standardmäßig werden die Az*-Module in der Datei requirements.psd1 angezeigt, sie sind bei der Dateierstellung jedoch auskommentiert. Wenn Sie im Modul auf ein Cmdlet verweisen, müssen Sie die Auskommentierung des Moduls aufheben.
Fehler bei der Aktion „PowerShell-Code ausführen“: „Das Argument kann nicht an den Parameter „Output“ gebunden werden, da es NULL ist.“
Dieser Fehler tritt auf, wenn Sie versuchen, ein NULL-Objekt an den Workflow zu pushen. Bestätigen Sie, dass das Objekt, das Sie mit Push-WorkflowOutput senden, nicht null ist.