PROJECT ONLINE. COMO INTERPRETAR ERRORES COMUNES EN LOS FLUJOS DE TRABAJO.
Buenas,
En este post queríamos haceros llegar la información que escribió la semana pasada Brian Smith en su blog, acerca de cómo interpretar errores comunes en flujos de trabajo en Project Online. El post original puede encontrarse en el siguiente enlace:
“Ejecutar flujos de trabajo en Project Online implica un montón de componentes móviles y muchas opciones de configuración que podrían afectar la forma en que fluyen los flujos de trabajo, o tal vez incluso dejar de fluir. En este post tengo el objetivo de tratar de desmitificar algunos de los procesos involucrados y ayudaros a entender por qué los flujos de trabajo pueden ser suspendidos - y muy a menudo no tiene nada que ver con un fallo en nuestro servicio. Eso no quiere decir que esté culpando a los clientes - ya que no hacemos en absoluto fácil de entender lo que pasó, o por qué. Estamos trabajando en ese aspecto - pero por ahora….
Primero vamos a cubrir donde se puede ver el estado de los flujos de trabajo. Desde la propia página del flujo de trabajo del proyecto principal, se puede ver la fase, la etapa y cualquier estado de la etapa del flujo de trabajo que se haya configurado a través de su flujo de trabajo. En este caso no estoy mostrando ningún estado de etapa específica - pero es una buena idea poner algo aquí para que sus usuarios sepan lo que está sucediendo - y tal vez lo que podría estar esperando.
Expandir la sección todas las etapas del flujo de trabajo como lo he hecho aquí ofrece una visión más amplia de dónde se encuentra. Asumiendo que tenemos el nivel de permiso correcto, veremos una opción en la esquina inferior derecha para ver los datos de flujo de trabajo adicionales:
Si hacemos click en la opción “Additional Workflow data” (Datos adicionales del flujo de trabajo) nos lleva a la siguiente captura de pantalla, y veremos cualquier información de estado escrita en el histórico del flujo de trabajo, y el estado interno. Si estás tratando de resolver algún problema, es posible que veas la información relativa al Estado Interno, como suspendida, y en el caso de ejemplo este flujo de trabajo terminaría siendo suspendido después de varios intentos, como se puede el estado bajo el icono informativo justo al lado de “Started” (Comenzado) en la siguiente captura de pantalla.
También podemos localizar el estado del flujo de trabajo desde Configuración de servidor \ Flujos de trabajo del sitio \ Mostrar todos los flujos de trabajo
Desafortunadamente, la página de flujos de trabajo de ejemplo muestra los flujos de trabajo de manera genérica y no tienen un contexto de proyecto directo, pero seremos capaces de ver cuáles están suspendidos:
Otra manera de localizar esta información es mediante odata, usando _api/ProjectData/ProjectWorkflowStageDataSet, añadido a la dirección de nuestro sitio PWA.
Lo anterior ha sido una introducción a cómo encontrar el estado, pero es momento de hablar ya de algunos errores comunes que podemos encontrarnos, y podemos ver algunos de éstos cuando un flujo de trabajo alcanza un estado suspendido, o quizás lo veamos cuando está yendo a través de varios intentos, pero lo que está claro es que veremos algo como esto si revisamos el estado del flujo de trabajo. Todas estas referencias de ejemplo terminarán por aparecer como suspendidas después de varios intentos, a no ser que la condición causante sea rectificada antes de que se complete el ciclo de reintentos:
La causa de cada uno de estos errores era un problema de permisos con la cuenta usada para ejecutar el flujo de trabajo. No podemos garantizar el error que veremos en cada escenario, ya que realmente se trata de una combinación entre el error específico de permisos y la acción que el flujo de trabajo está tratando de realizar. ¿Pero cuál es la cuenta de usuario que tiene el problema y está recibiendo el mensaje de acceso denegado?
Cuando un proyecto se crea el flujo de trabajo se lanza usando un token del usuario que ha hecho inicio de sesión, y continúa ejecutándose en el contexto del usuario hasta que se completa, o falla por alguna razón. Mantiene el mismo contexto de usuario incluso si el propietario de proyecto cambia.
Algo que puede suceder que cause problemas es que haya una falta de permisos, y esto está relacionado con la PDP que estaba causando el error ‘403’. Este problema es relativamente sencillo de localizar ya que es normalmente obvio quién está ejecutando el flujo de trabajo si falla de manera inmediata.
¿Pero qué pasa si el usuario que inició el flujo de trabajo abandona la compañía y se inactiva? Esto puede dar lugar a los mensajes Prohibido: Acceso denegado y Error interno: Acceso DenegadoSeguridadGeneral.
Reiniciar los flujos de trabajo suele resolver este problema. Otro ejemplo que hemos visto está relacionado con la cuenta que ejecuta el flujo de trabajo y pierde permisos (una posibilidad es que se cambie su rol de jefe de proyecto a integrante de grupo) o quizás la categoría a la cual pertenecía ha sido actualizada con algún tipo de acceso limitado (a nivel de permisos o incluso de proyectos). Los mismos mensajes aparecerán, dependiendo de las acciones sucediendo en el flujo de trabajo.
Este otro es curioso:
Aquí podemos ver algo más de información que en los otros. El flujo de trabajo está leyendo algún campo de tipo Fecha, y teniendo problemas. Podemos ver una referencia: '21af92c1-a389-e711-80c8-00155de44f0a', y generalmente suelen referenciar campos personalizados, por lo general a nivel de proyecto. Una manera rápida para encontrar el GUID del campo personalizado es usar “Ver código” en la página de Campos personalizados y tablas de consulta, y buscar por el GUID.
En el flujo de trabajo de ejemplo se estaba leyendo la fecha y configuración como variable, pero como la fecha no se había introducido todavía, se lanzaba una excepción, la cual causaba el error interno mostrado en el flujo de trabajo. En este caso, asegurarnos que la fecha tendrá un valor antes de leerla evitará el problema.
Estamos trabajando en tratar de mostrar mejor la verdadera causa de los errores, y que así podáis determinar si es algo que se pueda resolver simplemente reiniciando el flujo de trabajo, o se necesita contactar con soporte, para confirmar si se ha roto algo en nuestro entorno.”
Esperamos os resulte de interés, un saludo.
Jorge Puig