Adición y ejecución de código de script de PowerShell en flujos de trabajo Estándar para Azure Logic Apps (versión preliminar)
Se aplica a: Azure Logic Apps (estándar)
Nota:
Esta funcionalidad está en versión preliminar y está sujeta a las Condiciones de uso complementarias para las versiones preliminares de Microsoft Azure.
Para realizar tareas de integración personalizadas insertadas con el flujo de trabajo Estándar en Azure Logic Apps, puede agregar y ejecutar directamente código de PowerShell desde el flujo de trabajo. Para esta tarea, use la acción de Código insertado denominada Ejecutar código de PowerShell. Esta acción devuelve los resultados desde el código de PowerShell para que pueda usar esa salida en las acciones posteriores del flujo de trabajo.
Esta funcionalidad proporciona las siguientes ventajas:
Escriba scripts propios en el diseñador de flujos de trabajo para que pueda resolver desafíos de integración complejos. No es necesario ningún otro plan de servicio.
Esta ventaja simplifica el desarrollo de flujos de trabajo, además de reducir la complejidad y el costo con la administración de más servicios.
Genere un archivo de código dedicado, que proporciona un espacio de scripting personalizado dentro del flujo de trabajo.
Realice el integración con Funciones de PowerShell de Azure Functions, que proporciona una eficaz funcionalidad y herencia para la ejecución de tareas avanzadas.
Implemente scripts junto con los flujos de trabajo.
En esta guía se muestra cómo agregar la acción en el flujo de trabajo y agregar el código de PowerShell que quiere ejecutar.
Requisitos previos
Una cuenta y una suscripción de Azure. Si aún no tiene una, regístrese para obtener una cuenta de Azure gratuita.
Flujo de trabajo de la aplicación lógica Estándar donde quiere agregar el script de PowerShell. El flujo de trabajo ya debe comenzar con un desencadenador. Para obtener más información, consulte Creación de flujos de trabajo de aplicaciones lógicas estándar de ejemplo.
Puede usar cualquier desencadenador para su escenario, pero como ejemplo, en esta guía se usa el desencadenador Solicitud denominado Cuando se recibe una solicitud HTTP y también la acción Respuesta. El flujo de trabajo se ejecuta cuando otra aplicación o flujo de trabajo envía una solicitud a la dirección URL del punto de conexión del desencadenador. El script de ejemplo devuelve los resultados de la ejecución del código como salida que puede usar en acciones posteriores.
Consideraciones
Azure Portal guarda el script como un archivo de script de PowerShell (.ps1) en la misma carpeta que el archivo workflow.json, que almacena la definición JSON del flujo de trabajo e implementa el archivo en el recurso de la aplicación lógica junto con la definición de flujo de trabajo.
El formato de archivo .ps1 le permite escribir menos "código reutilizable" y centrarse solo en escribir código de PowerShell. Si cambia el nombre de la acción, también se cambia el nombre del archivo, pero no al contrario. Si cambia directamente el nombre del archivo, la versión cuyo nombre ha cambiado sobrescribe la versión anterior. Si el nombre de la acción y los nombres de archivo no coinciden, la acción no encuentra el archivo e intenta crear un archivo vacío.
El script es local para el flujo de trabajo. Para usar el mismo script en otros flujos de trabajo, vea el archivo de script en la consola de KuduPlus y, a continuación, copie el script para reutilizarlo en otros flujos de trabajo.
Limitaciones
| Nombre | Límite | Notas |
|---|---|---|
| Duración de la ejecución del script | 10 minutos | Si tiene escenarios que necesitan duraciones más largas, use la opción de comentarios del producto para proporcionar más información sobre sus necesidades. |
| Tamaño de salida | 100 MB | El tamaño de salida depende del límite de tamaño de salida de las acciones, que suele ser de 100 MB. |
Adición de la acción Ejecutar código de PowerShell
En Azure Portal, abra su recurso de aplicación lógica estándar y el flujo de trabajo en el diseñador.
En el diseñador, siga estos pasos generales para agregar la acción Operaciones de código insertadas denominada Ejecutar código de PowerShell al flujo de trabajo.
Una vez que se abra el panel de información de acción, en la pestaña Parámetros, en el cuadro Archivo de código, actualice el código de ejemplo rellenado previamente con código propio.
Para acceder a los datos procedentes del flujo de trabajo, vea Acceder a las salidas de acción y desencadenador de flujo de trabajo en el script más adelante en esta guía.
Para devolver los resultados del script u otros datos al flujo de trabajo, vea Devolución de datos al flujo de trabajo.
En el ejemplo siguiente se muestra la pestaña Parámetros de la acción con el código de script de ejemplo:
En el ejemplo siguiente se muestra el código de script de ejemplo:
# 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 $customResponseEn el ejemplo siguiente se muestra un script de ejemplo personalizado:
$action = Get-TriggerOutput $results = "Hello from PowerShell!" Push-WorkflowOutput -Output $resultsCuando termine, guarde el flujo de trabajo.
Después de ejecutar el flujo de trabajo, puede revisar la salida del flujo de trabajo en Application Insights, si está habilitado. Para más información, vea Visualización de la salida en Application Insights.
Acceso a salidas de desencadenador y acción de flujo de trabajo en el script
Los valores de salida del desencadenador y las acciones anteriores se devuelven mediante un objeto personalizado, que tiene varios parámetros. Para acceder a estas salidas y asegurarse de que se devuelve el valor que desee, use los cmdlets Get-TriggerOutput, Get-ActionOutput y Push-WorkflowOutput además los parámetros adecuados descritos en la tabla siguiente, por ejemplo:
$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:
En PowerShell, si hace referencia a un objeto que tiene el tipo JValue dentro de un objeto complejo y agrega ese objeto a una cadena, se inicia una excepción de formato. Para evitar este error, use ToString().
Salidas de los desencadenadores y la acción de respuesta
En la tabla siguiente se enumeran las salidas que se generan al llamar a Get-ActionOutput o Get-TriggerOutput. El valor devuelto es un objeto complejo denominado PowershellWorkflowOperationResult, que contiene las siguientes salidas.
| Nombre | Escribir | Descripción |
|---|---|---|
| Nombre | Cadena | Nombre del desencadenador o la acción. |
| Entradas | JToken | Valores de entrada pasados al desencadenador o la acción. |
| Salidas | JToken | Salidas del desencadenador o la acción ejecutados. |
| StartTime | DateTime | Hora de inicio del desencadenador o la acción. |
| EndTime | DateTime | Hora de finalización del desencadenador o la acción. |
| ScheduledTime | DateTime | Hora programada para ejecutar el desencadenador o la acción. |
| OriginHistoryName | Cadena | Nombre del historial de origen de los desencadenadores con la opción Split-On habilitada. |
| SourceHistoryName | Cadena | Nombre del historial de origen de un desencadenador reenviado. |
| TrackingId | Cadena | Id. de seguimiento de la operación. |
| Código | Cadena | Código de estado del resultado. |
| Estado | Cadena | Estado de ejecución del desencadenador o la acción, por ejemplo, Correcto o Error. |
| Error | JToken | Código de error HTTP. |
| TrackedProperties | JToken | Cualquier propiedad con seguimiento que configure. |
Devolución de salidas al flujo de trabajo
Para devolver las salidas al flujo de trabajo, debe usar el cmdlet Push-WorkflowOutput.
Comandos de PowerShell personalizados
La acción Ejecutar código de PowerShell incluye los siguientes comandos personalizados de PowerShell (cmdlets) para interactuar con el flujo de trabajo y otras operaciones del flujo de trabajo:
Get-TriggerOutput
Obtiene la salida del desencadenador del flujo de trabajo.
Sintaxis
Get-TriggerOutput
Parámetros
Ninguno.
Get-ActionOutput
Obtiene la salida de otra acción del flujo de trabajo y devuelve un objeto denominado PowershellWorkflowOperationResult.
Sintaxis
Get-ActionOutput [ -ActionName <String> ]
Parámetros
| Parámetro | Tipo | Descripción |
|---|---|---|
| ActionName | Cadena | Nombre de la acción en el flujo de trabajo con la salida a la que quiere hacer referencia. |
Push-WorkflowOutput
Inserta la salida de la acción Ejecutar código de PowerShell en el flujo de trabajo, lo que puede devolver cualquier tipo de objeto. Si el valor devuelto es null, obtendrá un error de objeto null del cmdlet.
Nota:
Los cmdlets Write-Debug, Write-Host y Write-Output no devuelven valores al flujo de trabajo. La instrucción return tampoco devuelve valores al flujo de trabajo. Pero puede usar estos cmdlets para escribir mensajes de seguimiento que aparecen en Application Insights. Para más información, vea Microsoft.PowerShell.Utility.
Sintaxis
Push-WorkflowOutput [-Output <Object>] [-Clobber]
Parámetros
| Parámetro | Tipo | Descripción |
|---|---|---|
| Salida | Varía. | Salida que quiere devolver al flujo de trabajo. Esta salida puede tener cualquier tipo. |
| Clobber | Varía. | Parámetro de modificador opcional que puede usar para invalidar la salida insertada anteriormente. |
Autenticación y autorización del acceso con una identidad administrada mediante PowerShell
Con una identidad administrada, el recurso de aplicación lógica y el flujo de trabajo pueden autenticar y autorizar el acceso a cualquier servicio y recurso de Azure que admita la autenticación de Microsoft Entra sin incluir credenciales en el código.
Desde dentro de la acción Ejecutar código de PowerShell, puede autenticar y autorizar el acceso con una identidad administrada para que pueda realizar acciones en otros recursos de Azure donde ha habilitado el acceso. Por ejemplo, puede reiniciar una máquina virtual u obtener los detalles de ejecución de otro flujo de trabajo de aplicación lógica.
Para usar la identidad administrada desde dentro de la acción Ejecutar código de PowerShell, debe seguir estos pasos:
-
En el recurso de Azure de destino, revise las consideraciones siguientes:
En la pestaña Rol, un rol de Colaborador suele ser suficiente.
En la página Agregar asignación de roles, en la pestaña Miembros, en la propiedad Asignar acceso a, asegúrese de seleccionar Identidad administrada.
Después de seleccionar Seleccionar miembros, en el panel Seleccionar identidades administradas, seleccione la identidad administrada que quiera usar.
En la acción Ejecutar código de PowerShell, incluya el código siguiente como primera instrucción:
Connect-AzAccount -IdentityAhora, puede trabajar con el recurso de Azure mediante cmdlets y módulos.
Visualización del archivo de script
En Azure Portal, abra el recurso de aplicación lógica Estándar que tenga el flujo de trabajo que desee.
En el menú de recursos de la aplicación lógica, en Herramientas de desarrollo, seleccione Herramientas avanzadas.
En la página Herramientas avanzadas, seleccione Ir, lo que abre la consola de KuduPlus.
Abra el menú Consola de depuración y seleccione CMD.
Vaya a la ubicación raíz de la aplicación lógica: sitio/wwwroot
Vaya a la carpeta del flujo de trabajo, que contiene el archivo .ps1, en esta ruta de acceso: site/wwwroot/{nombre-de-flujo-de-trabajo}
Junto al nombre de archivo, seleccione Editar para abrir y ver el archivo.
Visualización de registros en Application Insights
En Azure Portal, en el menú del recurso de aplicación lógica, en Configuración, seleccione Application Insights y después la aplicación lógica.
En el menú Application Insights, en Supervisión, seleccione Registros.
Cree una consulta para buscar los seguimientos o errores de la ejecución del flujo de trabajo, por ejemplo:
union traces, errors | project TIMESTAMP, message
Módulos
Los módulos de PowerShell son unidades autocontenidas y reutilizables que incluyen varios componentes, por ejemplo los siguientes:
- Cmdlets: comandos individuales que realizan tareas específicas.
- Proveedores: permiten el acceso a almacenes de datos, como el Registro o el sistema de archivos, como si fueran unidades.
- Funciones: bloques de código reutilizables que realizan acciones específicas.
- Variables: almacenan datos para usarlos en el módulo.
- Otro tipos de recursos.
Un módulo organiza el código de PowerShell, lo que facilita su distribución. Por ejemplo, puede crear módulos propios para empaquetar y hacer que la funcionalidad relacionada sea más fácil de administrar y compartir. La acción Ejecutar código de PowerShell le permite importar módulos de PowerShell públicos y privados.
Módulos públicos
Para buscar módulos disponibles públicamente, visite la galería de PowerShell. Un recurso de aplicación lógica Estándar puede admitir hasta 10 módulos públicos. Para usar cualquier módulo público, debe seguir estos pasos para habilitar esta funcionalidad:
En Azure Portal, en el menú de recursos de la aplicación lógica, en Herramientas de desarrollo, seleccione Herramientas avanzadas.
En la página Herramientas avanzadas, seleccione Ir.
En la barra de herramientas de Kudu Plus, en el menú Consola de depuración, seleccione CMD.
Vaya al nivel raíz de la aplicación lógica en C:\home\site\wwwroot mediante la estructura de directorios o la línea de comandos.
Abra el archivo host.json del flujo de trabajo y establezca la propiedad managed dependency en true, que ya está establecida de manera predeterminada.
"managedDependency": { "enabled": true }Abra el archivo denominado requirements.psd1. Incluya el nombre y la versión del módulo que quiera mediante la sintaxis siguiente: NúmeroVersiónPrincipal.* o la versión exacta del módulo, por ejemplo:
@{ Az = '1.*' SqlServer = '21.1.18147' }
Consideraciones para los módulos públicos
Si usa la administración de dependencias, se aplican las siguientes consideraciones:
Para descargar módulos, los módulos públicos necesitan acceso a la galería de PowerShell.
Actualmente, las dependencias administradas no admiten módulos que exigen que acepte una licencia, ya sea de forma interactiva o proporcionando la opción -AcceptLicense al ejecutar Install-Module.
Módulos privados
Puede generar módulos privados de PowerShell propios. Para crear el primer módulo de PowerShell, vea Escritura de un módulo de script de PowerShell.
En Azure Portal, en el menú de recursos de la aplicación lógica, en Herramientas de desarrollo, seleccione Herramientas avanzadas.
En la página Herramientas avanzadas, seleccione Ir.
En la barra de herramientas de Kudu Plus, en el menú Consola de depuración, seleccione CMD.
Vaya al nivel raíz de la aplicación lógica en C:\home\site\wwwroot mediante la estructura de directorios o la línea de comandos.
Cree una carpeta con el nombre Módulos.
En la carpeta Módulos, cree una subcarpeta con el mismo nombre que el módulo privado.
En la carpeta del módulo privado, agregue el archivo de módulo privado de PowerShell con la extensión de nombre de archivo psm1. También puede incluir un archivo de manifiesto de PowerShell opcional con la extensión de nombre de archivo psd1.
Cuando haya terminado, la estructura de archivos de aplicación lógica completa será similar a la del ejemplo siguiente:
MyLogicApp
-- execute_powershell_script.ps1
-- mytestworkflow.json
Modules
-- MyPrivateModule
--- MyPrivateModule.psd1
--- MyPrivateModule.psm1
-- MyPrivateModule2
--- MyPrivateModule2.psd1
--- MyPrivateModule2.psm1
requirements.psd1
host.json
Errores de compilación
En esta versión, el editor basado en web incluye compatibilidad limitada con IntelliSense, que todavía está en mejora. Se detectan errores de compilación al guardar el flujo de trabajo y el entorno de ejecución de Azure Logic Apps compila el script. Estos errores aparecen en los registros de errores de su aplicación lógica a través de Application Insights.
Errores en tiempo de ejecución
Una acción de flujo de trabajo no devuelve ninguna salida.
Asegúrese de usar el cmdlet Push-WorkflowOutput.
Se produce un error en la acción Ejecutar código de PowerShell: "El término "{un-texto}" no se reconoce..."
Si hace referencia incorrectamente a un módulo público en el archivo requirements.psd1 o cuando el módulo privado no existe en la siguiente ruta de acceso: C:\home\site\wwwroot\Modules{nombre-del-módulo}, se produce el siguiente error:
El término "{un-texto}" no se reconoce como nombre de un cmdlet, una función, un archivo de script o un programa ejecutable. Compruebe la ortografía del nombre o, si ha incluido una ruta de acceso, compruebe que sea correcta e inténtelo de nuevo.
Nota:
De manera predeterminada, los módulos Az* aparecen en el archivo requirements.psd1, pero se convierten en comentarios al crear el archivo. Al hacer referencia a un cmdlet del módulo, asegúrese de quitar la marca de comentario del módulo.
Se produce un error en la acción Ejecutar código de PowerShell: "No se puede enlazar el argumento del parámetro "Output" porque es null".
Este error se produce cuando se intenta insertar un objeto null en el flujo de trabajo. Confirme si el objeto que va a enviar con Push-WorkflowOutput no es null.