Aggiungere ed eseguire codice script di PowerShell nei flussi di lavoro Standard per App per la logica di Azure (anteprima)
Si applica: App per la logica di Azure (Standard)
Nota
Questa funzionalità è in anteprima ed è soggetta alle Condizioni supplementari per l'utilizzo per le anteprime di Microsoft Azure.
Per eseguire attività di integrazione personalizzate inline con il flusso di lavoro Standard in App per la logica di Azure, è possibile aggiungere ed eseguire direttamente il codice di PowerShell dall'interno del flusso di lavoro. Per questa attività, usare l'azione Codice inline denominata Esegui codice di PowerShell. Questa azione restituisce i risultati del codice di PowerShell in modo che sia possibile usare questo output nelle azioni successive del flusso di lavoro.
Questa funzionalità offre i vantaggi seguenti:
Scrivere script personalizzati all'interno della finestra di progettazione del flusso di lavoro in modo da poter risolvere problemi di integrazione complessi. Non sono necessari altri piani di servizio.
Questo vantaggio semplifica lo sviluppo del flusso di lavoro e riduce la complessità e i costi con la gestione di più servizi.
Generare un file di codice dedicato, che fornisce uno spazio di scripting personalizzato all'interno del flusso di lavoro.
Eseguire l'integrazione con Funzioni di Azure Funzioni di PowerShell, che offre funzionalità avanzate ed ereditarietà per l'esecuzione avanzata delle attività.
Distribuire il codice insieme ai flussi di lavoro.
Questa guida illustra come aggiungere l'azione nel flusso di lavoro e aggiungere il codice di PowerShell da eseguire.
Prerequisiti
Account e sottoscrizione di Azure. Se non si ha una sottoscrizione, è possibile iscriversi per creare un account Azure gratuito.
Flusso di lavoro dell'app per la logica Standard in cui si vuole aggiungere lo script di PowerShell. Il flusso di lavoro deve già iniziare con un trigger. Per altre informazioni, vedere Creare flussi di lavoro dell'app per la logica Standard.
È possibile usare qualsiasi trigger per lo scenario, ma, ad esempio, questa guida usa il trigger Richiesta denominato Quando viene ricevuta una richiesta HTTP e anche l'azione Risposta. Il flusso di lavoro viene eseguito quando un'altra applicazione o flusso di lavoro invia una richiesta all'URL dell'endpoint del trigger. Lo script di esempio restituisce i risultati dell'esecuzione del codice come output che è possibile usare nelle azioni successive.
Considerazioni
Il portale di Azure salva lo script come file di script di PowerShell (ps1) nella stessa cartella del file workflow.json, che archivia la definizione JSON per il flusso di lavoro e distribuisce il file nella risorsa dell'app per la logica insieme alla definizione del flusso di lavoro.
Il formato di file ps1 consente di scrivere meno "boilerplate" e di concentrarsi solo sulla scrittura di codice di PowerShell. Se si rinomina l'azione, il file viene rinominato, ma non viceversa. Se si rinomina direttamente il file, la versione rinominata sovrascrive la versione precedente. Se il nome dell'azione e i nomi di file non corrispondono, l'azione non riesce a trovare il file e tenta di creare un nuovo file vuoto.
Lo script è locale per il flusso di lavoro. Per usare lo stesso script in altri flussi di lavoro, visualizzare il file di script nella console kuduPluse quindi copiare lo script da riutilizzare in altri flussi di lavoro.
Limiti
| Nome | Limit | Note |
|---|---|---|
| Durata esecuzione script | 10 minuti | Se si hanno scenari che richiedono durate più lunghe, usare l'opzione di feedback del prodotto per fornire altre informazioni sulle proprie esigenze. |
| Dimensioni di output | 100 MB | Le dimensioni dell'output dipendono dal limite di dimensioni di output per le azioni, che in genere è di 100 MB. |
Aggiungere l'azione Esegui codice PowerShell
Nel portale di Azure aprire la risorsa e il flusso di lavoro dell'app per la logica Standard nella finestra di progettazione.
Nella finestra di progettazione seguire questa procedura generale per aggiungere l'azione Operazioni codice inline denominata Esegui codice PowerShell al flusso di lavoro.
Dopo aver aperto il riquadro informazioni sull'azione, nella scheda Parametri , nella casella File di codice aggiornare il codice di esempio prepopolato con il proprio codice.
Per accedere ai dati provenienti dal flusso di lavoro, vedere Accedere agli output di trigger e azioni del flusso di lavoro nello script più avanti in questa guida.
Per restituire i risultati dello script o altri dati al flusso di lavoro, vedere Restituire dati al flusso di lavoro.
L'esempio seguente mostra la scheda Parametri dell'azione con il codice script di esempio:
L'esempio seguente illustra il codice di script di esempio:
# 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'esempio seguente mostra uno script di esempio personalizzato:
$action = Get-TriggerOutput $results = "Hello from PowerShell!" Push-WorkflowOutput -Output $resultsAl termine, salvare il flusso di lavoro.
Dopo aver eseguito il flusso di lavoro, è possibile esaminare l'output del flusso in Application Insights, se abilitato. Per altre informazioni, vedere Visualizzare l'output in Application Insights.
Accedere agli output di trigger e azioni del flusso di lavoro nello script
I valori di output del trigger e delle azioni precedenti vengono restituiti usando un oggetto personalizzato, con più parametri. Per accedere a questi output e assicurarsi di restituire il valore desiderato, usare i cmdlet Get-TriggerOutput, Get-ActionOutput e Push-WorkflowOutput, oltre ai parametri appropriati descritti nella tabella seguente, ad esempio:
$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
Nota
In PowerShell, se si fa riferimento a un oggetto con tipo JValue all'interno di un oggetto complesso e si aggiunge tale oggetto a una stringa, si ottiene un'eccezione di formato. Per evitare questo errore, usare ToString().
Output della risposta di trigger e azione
La tabella seguente elenca gli output generati quando si chiama Get-ActionOutput o Get-TriggerOutput. Il valore restituito è un oggetto complesso denominato PowershellWorkflowOperationResult, che contiene gli output seguenti.
| Nome | Tipo | Descrizione |
|---|---|---|
| Nome | string | Nome del trigger o dell'azione. |
| Input | JToken | Valori di input passati al trigger o all'azione. |
| Output | JToken | Output dal trigger o dall'azione eseguita. |
| StartTime | DataOra | Ora di inizio per il trigger o l'azione. |
| EndTime | DataOra | Ora di fine per il trigger o l'azione. |
| ScheduledTime | Data/Ora | Ora pianificata per eseguire il trigger o l'azione o il trigger. |
| OriginHistoryName | String | Nome della cronologia di origine per i trigger con l'opzione Split-On abilitata. |
| SourceHistoryName | String | Nome della cronologia di origine per un trigger di nuovo inviato. |
| TrackingId | String | ID di rilevamento dell'operazione. |
| Codice | String | Codice di stato per il risultato. |
| Stato | String | Stato dell'esecuzione per il trigger o l'azione, ad esempio Succeeded o Failed. |
| Errore | JToken | Codice di errore HTTP. |
| TrackedProperties | JToken | Eventuali proprietà rilevate configurate. |
Restituire output al flusso di lavoro
Per restituire gli output al flusso di lavoro, è necessario usare il cmdlet Push-WorkflowOutput.
Comandi di PowerShell personalizzati
L'azione Esegui codice PowerShell include i comandi personalizzati di PowerShell (cmdlet) seguenti per interagire con il flusso di lavoro e altre operazioni nel flusso di lavoro:
Get-TriggerOutput
Ottiene l'output dal trigger del flusso di lavoro.
Sintassi
Get-TriggerOutput
Parametri
Nessuna.
Get-ActionOutput
Ottiene l'output da un'altra azione nel flusso di lavoro e restituisce un oggetto denominato PowershellWorkflowOperationResult.
Sintassi
Get-ActionOutput [ -ActionName <String> ]
Parametri
| Parametro | Tipo | Descrizione |
|---|---|---|
| ActionName | String | Nome dell'azione nel flusso di lavoro con l'output a cui si desidera fare riferimento. |
Push-WorkflowOutput
Esegue il push dell'output dall'azione Esegui codice di PowerShell al flusso di lavoro, che può passare qualsiasi tipo di oggetto. Se il valore restituito è Null, viene visualizzato un errore di oggetto Null dal cmdlet .
Nota
I cmdlet Write-Debug, Write-Host e Write-Output non restituiscono valori al flusso di lavoro. L'istruzione return non restituisce anche i valori al flusso di lavoro. Tuttavia, è possibile usare questi cmdlet per scrivere messaggi di traccia visualizzati in Application Insights. Per altre informazioni, vedere Microsoft.PowerShell.Utility.
Sintassi
Push-WorkflowOutput [-Output <Object>] [-Clobber]
Parametri
| Parametro | Tipo | Descrizione |
|---|---|---|
| Output | Variabile. | Output che si desidera restituire al flusso di lavoro. Questo output può avere qualsiasi tipo. |
| Clobber | Variabile. | Parametro di opzione facoltativo che è possibile usare per eseguire l'override dell'output precedentemente sottoposto a push. |
Autenticare e autorizzare l'accesso con un'identità gestita tramite PowerShell
Con un'identità gestita, la risorsa e il flusso di lavoro dell'app per la logica possono autenticare e autorizzare l'accesso a qualsiasi servizio e risorsa di Azure che supporti l'autenticazione di Microsoft Entra senza includere le credenziali nel codice.
Dall'interno dell'azione Esegui codice di PowerShell è possibile autenticare e autorizzare l'accesso con un'identità gestita in modo da poter eseguire azioni su altre risorse di Azure in cui è stato abilitato l'accesso. Ad esempio, è possibile riavviare una macchina virtuale o ottenere i dettagli dell'esecuzione di un altro flusso di lavoro dell'app per la logica.
Per usare l'identità gestita dall'interno dell'azione Esegui codice PowerShell, è necessario seguire questa procedura:
-
Nella risorsa di Azure di destinazione esaminare le considerazioni seguenti:
Nella scheda Ruolo è in genere sufficiente un ruolo Collaboratore.
Nella pagina Aggiungi assegnazione di ruolo, nella scheda Membri, per la proprietà Assegna accesso alla proprietà assicurarsi di selezionare Identità gestita.
Dopo aver selezionato Seleziona membri, nel riquadro Seleziona identità gestite selezionare l'identità gestita da usare.
Nell'azione Esegui codice PowerShell includere il codice seguente come prima istruzione:
Connect-AzAccount -IdentityÈ ora possibile usare la risorsa di Azure usando i cmdlet e i moduli.
Visualizzare il file di script
Nel portale di Azure aprire la risorsa dell'app per la logica Standard con il flusso di lavoro desiderato.
Nel menu delle risorse dell'app per la logica, in Strumenti di sviluppo selezionare Strumenti avanzati.
Nella pagina Strumenti avanzati selezionare Vai, che apre la console di KuduPlus.
Aprire il menu Console di debug e selezionare CMD.
Passare alla posizione radice dell'app per la logica: site/wwwroot
Passare alla cartella del flusso di lavoro, che contiene il file ps1, lungo questo percorso: site/wwwroot/{workflow-name}
Accanto al nome del file selezionare Modifica per aprire e visualizzare il file.
Visualizzare i log in Application Insights
Nel portale di Azure, nel menu delle risorse dell'app per la logica, in Impostazioni selezionare Application Insights e quindi selezionare l'app per la logica.
Nel menu Application Insights, in Monitoraggio selezionare Log.
Creare una query per trovare tracce o errori dall'esecuzione del flusso di lavoro, ad esempio:
union traces, errors | project TIMESTAMP, message
moduli
I moduli di PowerShell sono unità autonome riutilizzabili che includono vari componenti, ad esempio:
- Cmdlet: singoli comandi che eseguono attività specifiche.
- Provider: consente l'accesso agli archivi dati, ad esempio il Registro di sistema o il file system, come se fossero unità.
- Funzioni: blocchi di codice riutilizzabili che eseguono azioni specifiche.
- Variabili: archiviare i dati da usare all'interno del modulo.
- Altri tipi di risorse.
Un modulo organizza il codice di PowerShell, semplificando la distribuzione. Ad esempio, è possibile creare moduli personalizzati per creare pacchetti e rendere più gestibile e condivisibile la funzionalità correlata. L'azione Esegui codice PowerShell consente di importare moduli PowerShell pubblici e privati.
Moduli pubblici
Per trovare moduli disponibili pubblicamente, visitare la raccolta di PowerShell. Una risorsa dell'app per la logica Standard può supportare fino a 10 moduli pubblici. Per usare qualsiasi modulo pubblico, è necessario abilitare questa funzionalità seguendo questa procedura:
Nel portale di Azure, nei menu delle risorse dell'app per la logica, in Strumenti di sviluppo selezionare Strumenti avanzati.
Nella pagina Strumenti avanzati selezionare Vai.
Sulla barra degli strumenti Kudu Plus scegliere CMD dal menu Console di debug.
Passare al livello radice dell'app per la logica in C:\home\site\wwwroot usando la struttura di directory o la riga di comando.
Aprire il file di host.json del flusso di lavoro e impostare la proprietà di dipendenza gestita su true, che è già impostata per impostazione predefinita.
"managedDependency": { "enabled": true }Aprire il file denominato requirements.psd1. Includere il nome e la versione per il modulo desiderato usando la sintassi seguente: MajorNumber.* o la versione esatta del modulo, ad esempio:
@{ Az = '1.*' SqlServer = '21.1.18147' }
Considerazioni per i moduli pubblici
Se si usa la gestione delle dipendenze, si applicano le considerazioni seguenti:
Per scaricare i moduli, i moduli pubblici richiedono l'accesso a PowerShell Gallery.
Le dipendenze gestite attualmente non supportano i moduli che richiedono l'accettazione di una licenza, accettando la licenza in modo interattivo o fornendo l'opzione -AcceptLicense quando si esegue Install-Module.
Moduli privati
È possibile generare moduli di PowerShell privati. Per creare il primo modulo di PowerShell, vedere Scrivere un modulo di script di PowerShell.
Nella portale di Azure, nel menu delle risorse dell'app per la logica, in Strumenti di sviluppo selezionare Strumenti avanzati.
Nella pagina Strumenti avanzati selezionare Vai.
Sulla barra degli strumenti Kudu Plus scegliere CMD dal menu Console di debug.
Passare al livello radice dell'app per la logica in C:\home\site\wwwroot usando la struttura di directory o la riga di comando.
Creare una cartella denominata Modules.
Nella cartella Modules creare una sottocartella con lo stesso nome del modulo privato.
Nella cartella del modulo privato aggiungere il file del modulo di PowerShell privato con l'estensione psm1 . È anche possibile includere un file manifesto di PowerShell facoltativo con l'estensione del nome file psd1 .
Al termine, la struttura completa del file dell'app per la logica appare simile all'esempio seguente:
MyLogicApp
-- execute_powershell_script.ps1
-- mytestworkflow.json
Modules
-- MyPrivateModule
--- MyPrivateModule.psd1
--- MyPrivateModule.psm1
-- MyPrivateModule2
--- MyPrivateModule2.psd1
--- MyPrivateModule2.psm1
requirements.psd1
host.json
Errori di compilazione
In questa versione, l'editor basato sul Web include un supporto IntelliSense limitato, che è ancora in fase di miglioramento. Eventuali errori di compilazione vengono rilevati quando si salva il flusso di lavoro e il runtime di App per la logica di Azure compila lo script. Questi errori vengono visualizzati nei log degli errori dell'app per la logica tramite Application Insights.
Errori di runtime
Un'azione del flusso di lavoro non restituisce alcun output.
Assicurarsi di usare il cmdlet Push-WorkflowOutput .
L'azione Esegui codice di PowerShell non riesce: "Il termine '{some-text}' non è riconosciuto..."
Se si fa riferimento erroneamente a un modulo pubblico nel file requirements.psd1 o quando il modulo privato non esiste nel percorso seguente: C:\home\site\wwwroot\Modules{module-name}, viene visualizzato l'errore seguente:
Il termine '{some-text}' non viene riconosciuto come nome di un cmdlet, di una funzione, di un file di script o di un programma eseguibile. Controllare l'ortografia del nome o se è stato incluso un percorso, verificare che il percorso sia corretto e riprovare.
Nota
Per impostazione predefinita, i moduli Az* vengono visualizzati nel file requirements.psd1, ma vengono commentati durante la creazione del file. Quando si fa riferimento a un cmdlet dal modulo, assicurarsi di rimuovere il commento dal modulo.
L'azione Esegui codice di PowerShell ha esito negativo: "Impossibile associare l'argomento al parametro 'Output' perché è null".
Questo errore si verifica quando si tenta di eseguire il push di un oggetto Null nel flusso di lavoro. Verificare se l'oggetto inviato con Push-WorkflowOutput non è Null.