Ejecución manual de una función no desencadenada por HTTP
En este artículo se muestra cómo ejecutar manualmente una función no desencadenada por HTTP a través de una solicitud HTTP con formato especial.
En algunos contextos, por ejemplo, durante el desarrollo y la solución de problemas, es posible que tenga que ejecutar "a petición" una función de Azure que se desencadena indirectamente. Algunos ejemplos de desencadenadores indirectos son las funciones según una programación o las funciones que se ejecutan como el resultado de los eventos.
El procedimiento descrito en este artículo equivale a usar la funcionalidad de Test/Run de la pestaña Código + prueba de una función en Azure Portal. También puede usar Visual Studio Code para ejecutar manualmente funciones.
Requisitos previos
Los ejemplos de este artículo utilizan una herramienta de prueba de HTTP. Asegúrese de elegir una herramienta que mantenga los datos seguros. Para más información, vea Herramientas de prueba HTTP.
Definición de la ubicación de la solicitud
Para ejecutar una función no desencadenada por HTTP, necesita una manera de enviar una solicitud a Azure para que ejecute la función. La dirección URL que se usa para hacer esta solicitud tiene un formato específico.
- Nombre de host: La ubicación pública de la aplicación de función que consta del nombre de la aplicación de función más azurewebsites.net o el dominio personalizado. Cuando trabaja con ranuras de implementación que se utilizan para el almacenamiento provisional, la parte del nombre de host es el nombre de host de producción con
-<slotname>anexados. En el ejemplo anterior, la URL serámyfunctiondemos-staging.azurewebsites.netpara una ranura denominadastaging. - Ruta de acceso de carpeta: para obtener acceso a funciones no desencadenadas por HTTP a través de una solicitud HTTP, debe enviar la solicitud a través de la ruta de acceso
admin/functions. Las API de la ruta de acceso de/admin/solo son accesibles con autorización. - Nombre de la función: El nombre de la función que quiere ejecutar.
Las siguientes consideraciones se aplican cuando se realizan solicitudes a los puntos de conexión de administrador en la aplicación de función:
- Al realizar solicitudes a cualquier punto de conexión en la ruta de acceso de
/admin/, debe proporcionar la clave maestra de la aplicación en el encabezadox-functions-keyde la solicitud. - Cuando se ejecuta localmente, no se aplica la autorización y no se requiere la clave maestra de la función. Puede llamar a la función directamente al omitir el encabezado
x-functions-key. - Al acceder a los puntos de conexión de la aplicación de función en una ranura de implementación, asegúrese de usar el nombre de host específico de la ranura en la URL de solicitud, junto con la clave maestra específica de la ranura.
Obtener la clave maestra
Puede obtener la clave maestra en Azure Portal o mediante la CLI de Azure.
Precaución
Debido a los permisos elevados de la aplicación de función otorgados por la clave maestra, no debe compartir esta clave con terceros ni distribuirla en una aplicación. La clave solo se debe enviar a un punto de conexión HTTPS.
Vaya a la aplicación de función en Azure Portal, seleccione Claves de la aplicación y, luego, la clave
_master.
En la sección Editar clave, copie el valor de la clave en el portapapeles y, a continuación, seleccione Aceptar.
Llamada a la función
En Azure Portal, vaya a la aplicación de función y elija su función.
Seleccione Código + prueba y, a continuación, Registros. Cuando ejecute manualmente la función desde su herramienta de prueba HTTP, aquí verá los mensajes de la función registrados.
En la herramienta de prueba HTTP, use la ubicación de solicitud que definió como la URL de solicitud y asegúrese de que el método de solicitud HTTP es POST e incluya estos dos encabezados de solicitud:
Key Value x-functions-keyEl valor de clave maestra pegado desde el portapapeles. Content-Typeapplication/jsonAsegúrese de que la carga útil/cuerpo de la solicitud POST sea
{ "input": "<TRIGGER_INPUT>" }. El valor de<TRIGGER_INPUT>específico que proporcione dependerá del tipo de desencadenador, pero solo puede ser un valor de cadena, numérico o booleano. En el caso de los servicios que usan cargas JSON como, por ejemplo, Azure Service Bus, la carga JSON de prueba se debe escapar y serializar como una cadena.Si no desea pasar datos de entrada a la función, debe pasar un diccionario
{}vacío como el cuerpo de la solicitud POST. Para obtener más información, consulte el artículo de referencia del desencadenador no HTTP concreto.Envíe la solicitud POST HTTP. Si la respuesta debe ser HTTP 202 (Aceptada).
A continuación, vuelva a la función en Azure Portal. Revise los registros y verá los mensajes procedentes de la llamada manual a la función.
La forma en que se accede a los datos enviados al desencadenador depende del tipo de desencadenador y del lenguaje de la función. Para obtener más información, consulte los ejemplos de referencia del desencadenador específico.