Solución de problemas |
Scroll |
¿Cómo se ejecuta 'Función de llamada'?
Es necesario comprender los aspectos básicos de esta función para solucionar problemas. El diagrama siguiente ilustra el comportamiento de los distintos componentes.
Cuando se ejecuta la tarea “Función de llamada” en el motor de flujos de trabajo, se envía una solicitud HTTPS POST a la función. Si la llamada es correcta, la función llamada se ejecutará y muy probablemente llamará al servidor de Therefore™ utilizando la API web para recuperar documentos, datos de índice y otra información adicional necesaria para su propósito.
La función llamada puede ser una función de Azure, un servicio web o cualquier ejecutable que pueda reaccionar a solicitudes HTTPS POST. Sin embargo, es necesario que la función llamada devuelva un objeto JSON que contenga la cadena “TheError” y un valor booleano “TheRoutingDone” o un entero “TheRetryAfterMin”. Si la función fue desarrollada por Therefore™, se puede hospedar en la suscripción a Azure de Therefore™ Online.
Por motivos de seguridad, las funciones desarrolladas por clientes deben ejecutarse en su suscripción a Azure o en su infraestructura.
Como se muestra en el diagrama, todas las conexiones entre Therefore™ y la función llamada son solo solicitudes HTTPS POST y llamadas a la API (web). El servicio del servidor no ejecuta directamente código del cliente y tampoco se ejecuta código del cliente en el entorno de Therefore™ Online. Todas las comprobaciones de permisos se aplican de la forma habitual cuando se realizan llamadas a la API web. El token de acceso suministrado con la solicitud HTTPS se limita a la instancia de flujo de trabajo actual. Dada esta arquitectura, es seguro utilizar personalización de flujos de trabajo en Therefore™ Online.
¿Cómo se comunican los mensajes de error?
Todos los mensajes de error que se producen se deben comunicar al historial de flujos de trabajo.
Como se muestra en el diagrama de arquitectura, Therefore™ solo envía una solicitud HTTPS, la parte más importante (el código del cliente) se ejecuta en la función llamada.
Si la función falla, todos los errores que se hayan producido se comunicarán a Therefore™ para que se puedan registrar en el historial de WF. Si la función devuelve un error, la entrada del historial de WF comenzará con “La función llamada ha producido un error”. Si la función se bloquea debido a una excepción no controlada o no devuelve la información, Therefore™ no podrá registrar nada. Si una función devuelve simplemente un objeto JSON con una cadena “TheError” vacía y el valor booleano “TheRoutingDone” se establece como False, ya se considera un éxito, pues la llamada HTTPS ha funcionado y no se ha comunicado ningún error.
Estos son algunos de los errores mostrados que pueden producirse al llamar a una función:
|
---|
¿Cómo funciona la monitorización en Azure Portal?
Se debe configurar “Application Insights” de Microsoft para monitorizar funciones de Azure. Se puede mostrar una lista de llamadas de función recientes al hacer clic en “Monitor” después de seleccionar una función en Azure Portal.
Las llamadas a funciones se mostrarán como 'correctas' si no se ha producido una excepción no controlada, independientemente del código de resultado o de las excepciones detectadas. Therefore™ trata esto de manera similar: si se detecta una excepción, se debe comunicar con el código de estado 200, además de la información de excepción en la cadena devuelta 'TheError'.
Si se produce una excepción no controlada no se puede devolver nada a Therefore™ desde la función. El servicio web se limitará a enviar el código de estado 500. En este caso, no se podrá mostrar ninguna otra información que no sea el código de estado 500 en Therefore™ y será necesario verificar los detalles de Azure Monitoring.
Se puede utilizar el “ID de operación” para consultar los detalles y los seguimientos de la pila en la tabla de excepciones. Copie el “ID de operación” y haga clic en “Ejecutar en Application Insights” para abrirlo en una nueva pestaña.
Pegue el “ID de operación” en la ventana de consulta y estructure una consulta de este modo:
exceptions | where operation_Id == "OperationID"
| limit 50
Después de hacer clic en “Ejecutar” deberá mostrarse la información de excepciones que pertenece al “ID de operación”.
Debe haber al menos una fila que muestre información de excepciones.
Exporte todas las filas y envíalas al desarrollador responsable de esta función de Azure.
Compruebe además la información de flujos de trabajo adicionales en la tabla de seguimientos. Si se utilizó una muestra, cada llamada de función deberá registrarse con número de instancia, token, expediente o documento.
Copie la consulta anterior y sustituya la palabra “exceptions” por “traces”:
traces | where operation_Id == "OperationID"
| limit 50
Incluya esa información también cuando informe al desarrollador.
Si la función realiza tareas de conversión, también deberá suministrar el documento.
Preguntas frecuentes sobre desarrollo
¿Cómo y dónde puedo desarrollar una función de Azure?
El desarrollo de una función de Azure se puede realizar por completo en Visual Studio y sin necesidad de una suscripción a Azure. Después de crear una nueva función de Azure utilizando el asistente de proyectos, se puede iniciar pulsando F5. El depurador con puntos de interrupción funciona como en cualquier otra aplicación.
¿Necesito una suscripción a Azure?
No la necesita para pruebas o desarrollo. Las funciones de Azure se pueden escribir y ejecutar directamente en Visual Studio. Si el sistema de desarrollo es accesible púbicamente a través de http, puede incluso utilizarse con Therefore™ Online. Cuando se trata de ejecutar la función de Azure en un entorno de producción se necesita una suscripción a Azure. Además, también es posible crear una función para un servicio web no hospedado en Microsoft Azure. En este caso no se necesita suscripción.
¿Por qué no devuelve mi función un parámetro obligatorio?
Todas las funciones llamadas por la tarea "Función de llamada" deben devolver un objeto JSON que contenga la cadena “TheError” y un valor booleano “TheRoutingDone” o un entero “TheRetryAfterMin”.
Si no se produce un error, “TheError” debe estar vacío, pero debe existir en el objeto JSON. Pero especialmente en caso de error, es importante capturar la excepción y reenviarla a Therefore™ utilizando “TheError” para que se pueda registrar correctamente.
¿Cómo pruebo mi función (de Azure) sin Therefore™?
Puede ser más rápido llamar directamente a la función para comprobarla, en particular al comenzar a desarrollar funciones (de Azure). Si utiliza cURL podrá hacerlo con el comando siguiente:
curl –d “” –i –X POST http://localhost:Port/api/Route
Si la función ya se ha desplegado en Azure, utilice el comando siguiente:
curl –d “” –i –X POST “https://AppName.azurwebsites.net/api/Route?code=FunctionKey”
La ruta se puede definir con código. Si no la define, utilice el nombre de función en su lugar.
Al llamar a la API web aparece “Acceso denegado” o “No está autorizado a…”
Por motivos de seguridad, el JWT-token suministrado tiene permisos muy limitados y, por tanto, es probable que surjan problemas con los permisos. Si necesita más permisos, deberá crear un usuario interno que tenga todos los permisos necesarios. A continuación puede pasar las credenciales a la función utilizando “WebAPIUser” y “WebAPIPassword” añadiéndolos como ajuste de aplicación en Azure Portal o para desarrollo local en el archivo “local.settings.json”.
¿Puedo utilizar la API de Therefore™ para mi función?
Depende de la plataforma que utilice. Cuando utiliza funciones de Azure, debe utilizar la API web de Therefore™, ya que la API normal tiene demasiadas dependencias.