Ajouter et exécuter du code de script PowerShell dans des workflows standard pour Azure Logic Apps (préversion)
S’applique à : Azure Logic Apps (Standard)
Remarque
Cette fonctionnalité est en préversion et est soumise aux conditions d’utilisation supplémentaires des préversions de Microsoft Azure.
Pour effectuer des tâches d’intégration personnalisées en ligne avec votre workflow standard dans Azure Logic Apps, vous pouvez ajouter et exécuter du code PowerShell depuis votre workflow. Pour cette tâche, utilisez l’action Code Inline nommée Exécuter le code PowerShell. Cette action retourne les résultats de votre code PowerShell afin de vous permettre d’utiliser cette sortie dans les actions suivantes de votre workflow.
Cette fonctionnalité offre les avantages suivants :
Écrivez vos propres scripts dans le concepteur de workflows pour vous permettre de résoudre des problèmes d’intégration complexes. Aucun autre plan de service n’est nécessaire.
Cet avantage simplifie le développement de flux de travail et réduit la complexité et le coût de la gestion d’un plus grand nombre de services.
Générez un fichier de code dédié, qui fournit un espace de script personnalisé dans votre flux de travail.
Intégrez Fonctions PowerShell Azure Functions, qui fournit des fonctionnalités puissantes et un héritage pour l’exécution avancée des tâches.
Déployez des scripts en même temps que vos flux de travail.
Ce guide montre comment ajouter l’action dans votre workflow et ajouter le code PowerShell que vous souhaitez exécuter.
Prérequis
Un compte et un abonnement Azure. Si vous n’avez pas encore d’abonnement, vous pouvez vous inscrire pour obtenir un compte Azure gratuitement.
Workflow d’application logique standard dans lequel vous souhaitez ajouter votre script PowerShell. Le workflow doit déjà commencer par un déclencheur. Pour plus d’informations, consultez Créer des exemples de flux de travail d’application logique standard.
Vous pouvez utiliser n’importe quel déclencheur pour votre scénario, mais, par exemple, ce guide utilise le déclencheur de Requête nommé Lorsqu’une requête HTTP est reçue et également l’action Réponse. Le flux de travail s’exécute lorsqu’une autre application ou flux de travail envoie une requête à l’URL du point de terminaison du déclencheur. L’exemple de script retourne les résultats de l’exécution du code en tant que sortie que vous pouvez utiliser dans les actions suivantes.
À propos de l’installation
Le portail Azure enregistre votre script en tant que fichier de script PowerShell (.ps1) dans le même dossier que votre fichier workflow.json, qui stocke la définition JSON de votre workflow et déploie le fichier dans votre ressource d’application logique, ainsi que la définition de workflow.
Le format de fichier .ps1 vous permet d’écrire moins de « code réutilisable » et de vous concentrer sur l’écriture de code PowerShell. Si vous renommez l’action, le fichier est également renommé, mais pas inversement. Si vous renommez directement le fichier, la version renommée remplace la version précédente. Si le nom de l’action et les noms de fichiers ne correspondent pas, l’action ne trouvera pas le fichier et tentera de créer un fichier vide.
Le script est local dans le flux de travail. Pour utiliser le même script dans d’autres flux de travail, afficher le fichier de script dans la console KuduPlus, puis copier le script pour le réutiliser dans d’autres flux de travail.
Limites
| Nom | Limite | Remarques |
|---|---|---|
| Durée de l’exécution du script | 10 minutes | Si vous avez des scénarios qui nécessitent des durées plus longues, utilisez l’option de commentaires sur le produit pour fournir plus d’informations sur vos besoins. |
| Taille de sortie | 100 Mo | La taille de sortie dépend de la limite de taille de sortie pour les actions, qui est généralement de 100 Mo. |
Ajouter l’action Exécuter le code PowerShell
Sur le portail Azure, ouvrez votre application logique Standard et votre flux de travail dans le concepteur.
Dans le concepteur, suivez ces étapes générales pour ajouter l’action Opérations de code Inline appelée Exécuter le code PowerShell à votre workflow.
Une fois le volet d’informations d’action ouvert, sous l’onglet Paramètres, dans la zone Fichier de code, mettez à jour l’exemple de code prérenseigné avec votre propre code de.
Pour accéder aux données provenant de votre workflow, consultez Accéder aux sorties de déclencheur et d’action de workflow dans votre script plus loin dans ce guide.
Pour renvoyer les résultats du script ou d’autres données à votre workflow, consultez Retourner des données à votre workflow.
L’exemple suivant montre l’onglet Paramètres de l’action avec l’exemple de code de script :
L’exemple suivant montre l’exemple de code de script :
# 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 $customResponseL’exemple suivant montre l’exemple de script personnalisé :
$action = Get-TriggerOutput $results = "Hello from PowerShell!" Push-WorkflowOutput -Output $resultsLorsque vous avez terminé, enregistrez votre flux de travail.
Après avoir exécuté votre flux de travail, vous pouvez passer en revue la sortie du flux de travail dans Application Insights, s’il est activé. Pour plus d’informations, consultez Afficher la sortie dans Application Insights.
Accéder aux sorties de déclencheur et d’action de flux de travail dans votre script
Les valeurs de sortie du déclencheur et des actions précédentes sont retournées à l’aide d’un objet personnalisé avec plusieurs paramètres. Pour accéder à ces sorties et vous assurer que vous retournez la valeur souhaitée, utilisez les applets de commande Get-TriggerOutput, Get-ActionOutput et Push-WorkflowOutput ainsi que tous les paramètres appropriés décrits dans le tableau suivant, par exemple :
$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
Remarque
Dans PowerShell, si vous référencez un objet avec un type JValue à l’intérieur d’un objet complexe et que vous ajoutez cet objet à une chaîne, vous obtenez une exception de format. Pour éviter cette erreur, utilisez ToString().
Sorties de réponse de déclencheur et d’action
Le tableau suivant répertorie les sorties générées lorsque vous appelez Get-ActionOutput ou Get-TriggerOutput. La valeur de retour est un objet complexe appelé PowershellWorkflowOperationResult, qui contient les sorties suivantes.
| Nom | Type | Description |
|---|---|---|
| Nom | Chaîne | Le nom du déclencheur ou de l’action. |
| Entrées | JToken | Les valeurs d’entrée passées dans le déclencheur ou l’action. |
| Sorties | JToken | Les sorties du déclencheur ou de l’action exécutés. |
| StartTime | Date/Heure | L’heure de début du déclencheur ou de l’action. |
| EndTime | Date/Heure | L’heure de fin du déclencheur ou de l’action. |
| ScheduledTime | Date/Heure | Heure planifiée pour exécuter le déclencheur ou l’action. |
| OriginHistoryName | Chaîne | Nom de l’historique des origines des déclencheurs avec l’option Fractionnement activée. |
| SourceHistoryName | Chaîne | Nom de l’historique source d’un déclencheur renvoyé. |
| TrackingId | Chaîne | ID de suivi de l’opération. |
| Code | Chaîne | Le code d’état du résultat. |
| État | Chaîne | État d’exécution du déclencheur ou de l’action, par exemple, Réussi ou Échec. |
| Error | JToken | Code d’erreur HTTP. |
| TrackedProperties | JToken | Toutes les propriétés suivies que vous avez configurées. |
Retourner des sorties à votre workflow
Pour renvoyer les sorties à votre workflow, vous devez utiliser l’applet de commande Push-WorkflowOutput.
Commandes PowerShell personnalisées
L’action Exécuter le code PowerShell inclut les commandes PowerShell (applets de commande) personnalisées suivantes pour interagir avec votre workflow et d’autres opérations dans votre workflow :
Get-TriggerOutput
Obtient la sortie du déclencheur du workflows.
Syntaxe
Get-TriggerOutput
Paramètres
Aucune.
Get-ActionOutput
Obtient la sortie d’une autre action dans le workflow et retourne un objet nommé PowershellWorkflowOperationResult.
Syntaxe
Get-ActionOutput [ -ActionName <String> ]
Paramètres
| Paramètre | Type | Description |
|---|---|---|
| ActionName | Chaîne | Nom de l’action dans le workflow avec la sortie que vous souhaitez référencer. |
Push-WorkflowOutput
Envoie (push) la sortie de l’action Exécuter le code PowerShell à votre workflow, ce qui peut transmettre n’importe quel type d’objet. Si la valeur de retour est Null, vous obtenez une erreur d’objet Null à partir de l’applet de commande.
Remarque
Les applets de commande Write-Debug, Write-Host et Write-Output ne retournent pas de valeurs à votre workflow. L’instruction return ne retourne pas non plus de valeurs à votre workflow. Toutefois, vous pouvez utiliser ces applets de commande pour écrire des messages de suivi qui s’affichent dans Application Insights. Pour plus d’informations, consultez Microsoft.PowerShell.Utility.
Syntaxe
Push-WorkflowOutput [-Output <Object>] [-Clobber]
Paramètres
| Paramètre | Type | Description |
|---|---|---|
| Sortie | Varie. | Sortie que vous souhaitez retourner au workflow. Cette sortie peut être de n’importe quel type. |
| Écraser | Varie. | Paramètre de commutateur facultatif que vous pouvez utiliser pour remplacer la sortie envoyée précédemment. |
Authentifier et autoriser l’accès avec une identité managée à l’aide de PowerShell
Avec une identité managée, votre ressource d’application logique et votre workflow peuvent authentifier et autoriser l’accès à n’importe quel service et ressource Azure prenant en charge l’authentification Microsoft Entra sans inclure d’informations d’identification dans votre code.
À partir de l’action Exécuter le code PowerShell, vous pouvez authentifier et autoriser l’accès avec une identité managée afin de pouvoir effectuer des actions sur d’autres ressources Azure où l’accès est activé. Par exemple, vous pouvez redémarrer une machine virtuelle ou obtenir les détails de l’exécution d’un autre workflow d’application logique.
Pour utiliser l’identité managée à partir de l’action Exécuter le code PowerShell, procédez de la manière suivante :
-
Sur la ressource Azure cible, passez en revue les considérations suivantes :
Sous l’onglet Rôle, un rôle Contributeur est généralement suffisant.
Dans la page Ajouter une attribution de rôle, sous l’onglet Membres, pour la propriété Attribuer l’accès à, veillez à sélectionner Identité managée.
Après avoir sélectionné Sélectionner des membres, dans le volet Sélectionner des identités managées, sélectionnez l’identité managée que vous souhaitez utiliser.
Dans votre action Exécuter le code PowerShell, incluez le code suivant comme première instruction :
Connect-AzAccount -IdentityÀ présent, vous pouvez utiliser la ressource Azure à l’aide d’applets de commande et de modules.
Afficher le fichier de script
Dans le portail Azure, ouvrez votre ressource d’application logique Standard avec le flux de travail souhaité.
Dans le menu des ressources de l’application logique, sous Outils de développement, sélectionnez Outils Avancés.
Dans la page Outils avancés, sélectionnez Go, qui ouvre la console KuduPlus.
Ouvrez le menu de la console de débogage, puis sélectionnez CMD.
Accédez à l’emplacement racine de votre application logique : site/wwwroot
Accédez au dossier de votre workflow, qui contient le fichier .ps1, sur ce chemin : site/wwwroot/{workflow-name}
En regard du nom de fichier, sélectionnez Modifier pour ouvrir et afficher le fichier.
Afficher les journaux d’activité dans Application Insights
Dans le portail Azure, dans le menu de ressources de l’application logique, sous Paramètres, sélectionnez Application Insights, puis votre application logique.
Dans le menu Application Insights, sous Surveillance, sélectionnez Journaux.
Créez une requête pour rechercher des traces ou des erreurs dans l’exécution de votre flux de travail, par exemple :
union traces, errors | project TIMESTAMP, message
Modules
Les modules PowerShell sont des unités autonomes et réutilisables qui incluent différents composants, par exemple :
- Applets de commande : commandes individuelles qui effectuent des tâches spécifiques.
- Fournisseurs : autorisez l’accès aux magasins de données, tels que le registre ou le système de fichiers, comme s’ils étaient des lecteurs.
- Fonctions : blocs de code réutilisables qui effectuent des actions spécifiques.
- Variables : stockez les données à utiliser dans le module.
- Autres types de ressources.
Un module organise le code PowerShell, ce qui facilite la distribution. Par exemple, vous pouvez créer vos propres modules pour empaqueter et rendre les fonctionnalités associées plus gérables et partageables. L’action Exécuter le code PowerShell vous permet d’importer des modules PowerShell publics et privés.
Modules publics
Pour trouver des modules disponibles publiquement, consultez PowerShell Gallery. Une ressource d’application logique standard peut prendre en charge jusqu’à 10 modules publics. Pour utiliser n’importe quel module public, vous devez activer cette fonctionnalité en procédant de la manière suivante :
Dans le portail Azure, dans les menus des ressources de votre application logique, sous Outils de développement, sélectionnez Outils avancés.
Dans la page Outils avancés, sélectionnez Go.
Dans la barre d’outils Kudu Plus, depuis le menu Console de débogage, sélectionnez CMD.
Accédez au niveau racine de votre application logique dans C:\home\site\wwwroot à l’aide de la structure de répertoires ou de la ligne de commande.
Ouvrez le fichier host.json du workflow et définissez la propriété dépendance managée sur true, qui l’est par défaut.
"managedDependency": { "enabled": true }Ouvrez le fichier nommé requirements.psd1. Incluez le nom et la version du module souhaités à l’aide de la syntaxe suivante : MajorNumber.* ou de la version exacte du module, par exemple :
@{ Az = '1.*' SqlServer = '21.1.18147' }
Considérations relatives aux modules publics
Si vous utilisez la gestion des dépendances, les considérations suivantes s’appliquent :
Pour télécharger des modules, les modules publics nécessitent l’accès à PowerShell Gallery.
Actuellement, les dépendances managées ne prennent pas en charge les modules qui vous obligent à accepter une licence, soit en acceptant la licence de manière interactive, soit en fournissant l’option -AcceptLicense lorsque vous exécutez Install-Module.
Modules privés
Vous pouvez générer vos propres modules PowerShell privés. Pour créer votre premier module PowerShell, consultez Écrire un module de script PowerShell.
Dans le portail Azure, dans le menu des ressources de votre application logique, sous Outils de développement, sélectionnez Outils avancés.
Dans la page Outils avancés, sélectionnez Go.
Dans la barre d’outils Kudu Plus, depuis le menu Console de débogage, sélectionnez CMD.
Accédez au niveau racine de votre application logique dans C:\home\site\wwwroot à l’aide de la structure de répertoires ou de la ligne de commande.
Créez un dossier intitulé Modules.
Dans le dossier Modules, créez un sous-dossier portant le même nom que votre module privé.
Dans votre dossier de module privé, ajoutez votre fichier de module PowerShell privé avec l’extension au nom du fichier psm1. Vous pouvez également inclure un fichier manifeste PowerShell facultatif avec l’extension au nom du fichier psd1.
Lorsque vous avez terminé, votre structure de fichiers d’application logique complète doit ressembler à l’exemple suivant :
MyLogicApp
-- execute_powershell_script.ps1
-- mytestworkflow.json
Modules
-- MyPrivateModule
--- MyPrivateModule.psd1
--- MyPrivateModule.psm1
-- MyPrivateModule2
--- MyPrivateModule2.psd1
--- MyPrivateModule2.psm1
requirements.psd1
host.json
Erreurs de compilation
Dans cette version, l’éditeur web inclut une prise en charge limitée d’IntelliSense, qui est toujours en cours d’amélioration. Toutes les erreurs de compilation sont détectées lorsque vous enregistrez votre flux de travail et que le runtime Azure Logic Apps compile votre script. Ces erreurs apparaissent dans les journaux d’erreurs de votre application logique via Application Insights.
Erreurs d’exécution
Une action de workflow ne retourne aucune sortie.
Veillez à utiliser l’applet de commande Push-WorkflowOutput.
L’action Exécuter le code PowerShell échoue : « Le terme "{du-texte}" n’est pas reconnu... »
Si vous référencez incorrectement un module public dans le fichier requirements.psd1 ou lorsque votre module privé n’existe pas dans le chemin suivant : C:\home\site\wwwroot\Modules{module-name}, vous obtenez l’erreur suivante :
Le terme « {du-texte} » n’est pas reconnu comme nom d’applet de commande, d’une fonction, d’un fichier de script ou d’un programme exécutable. Vérifiez l’orthographe du nom ou, si un chemin d’accès a été inclus, vérifiez que le chemin d’accès est correct, puis réessayez.
Remarque
Par défaut, les modules Az* apparaissent dans le fichier requirements.psd1, mais ils sont commentés lors de la création du fichier. Lorsque vous référencez une applet de commande à partir du module, veillez à annuler les marques de commentaire du module.
L’action Exécuter le code PowerShell échoue : « Impossible de lier l’argument au paramètre "Sortie", car il est Null. »
Cette erreur se produit lorsque vous essayez d’envoyer un objet Null au workflow. Vérifiez que l’objet que vous envoyez avec Push-WorkflowOutput n’a pas la valeur Null.