Saltar al contenido principal
Versión: v2 ⚡

History y búsqueda en OpenFn

Para los administradores de la plataforma, History es la consola central para supervisar toda la actividad de tus workflows activos. Sigue leyendo para conocer sus componentes principales.

History​

La página History muestra una lista de todas las work orders y los runs que se procesaron en un proyecto.

History

Ejecución de workflows: work orders y runs​

Los workflows de OpenFn se ejecutan así:

  1. Un Trigger del workflow se activa con un evento de webhook, un temporizador cron o una acción manual.
  2. Esto crea una Work Order: una solicitud para ejecutar un workflow con una entrada determinada (por ejemplo, el envío de un formulario nuevo o un registro de paciente que hay que procesar). Para que una Work Order se complete, debería llegar a un step final con éxito (sin errores); así se garantiza que el procesamiento terminó.
  3. Después se ejecuta un Run para intentar completar el workflow con éxito. Este run tendrá un código de estado que indica si los steps del workflow se procesaron correctamente.
  4. Si el primer Run falla, puedes volver a ejecutarlo para "reintentar" el workflow. Se creará un segundo Run. Si tiene éxito, tanto el run como la work order relacionada se actualizarán con el estado success.

También puedes cancelar runs pendientes o reintentar work orders completadas directamente desde la página History. Consulta Reintentar y cancelar runs para más detalles.

History Page

Consulta las demás páginas de esta sección para saber más sobre cómo inspeccionar runs, solucionar problemas y volver a ejecutar runs fallidos.

Cómo funciona la búsqueda​

Con la barra de búsqueda de la página History puedes encontrar work orders cuyos dataclips de entrada o salida relacionados, o cuyos logs de runs, contienen cadenas de texto específicas. De forma predeterminada, el sistema busca solo en los logs de runs, pero puedes elegir buscar en cualquiera de estas tres opciones, o en todas:

Search Options

  1. UUIDs de OpenFn de work orders, runs o steps
  2. Cuerpos de los dataclips de entrada y salida
  3. Logs de runs

Si buscas texto dentro de un dataclip de entrada o salida o de los logs de runs, se aplica una búsqueda tsvector. Este método de búsqueda te permite encontrar work orders rápidamente y admite coincidencias parciales en todo el texto de los logs de runs y en las "keys" y los "values" de tus dataclips.

Es posible que los dataclips de entrada muy grandes o complejos no se

indexen

Actualmente no es posible crear índices tsvector de más de 1 MB, por lo que es posible que los dataclips de entrada muy grandes o complejos no aparezcan en los resultados de búsqueda. Por lo general esto no ocurre hasta que te acercas a los 10 MB de JSON, pero la cantidad de lexemas y posiciones distintos de tu JSON influye en el tamaño final del índice.

Más información en la página "text search limitations" de la documentación de Postgres.

Las coincidencias parciales funcionan mejor al principio de las palabras, así que si buscas elementos que coincidan con "newPatient", es mejor buscar "newPat" que "tient". (Si tienes dudas, las palabras completas o los IDs dan los mejores resultados).

Buscar y filtrar resultados​

Aunque puedes buscar cadenas de texto que aparecen en logs de runs o dataclips concretos, es importante recordar que los resultados que se devuelven siguen siendo work orders. Si los dataclips de salida del tercer step del primer run de la work order "123" coinciden con tu búsqueda, verás la work order "123" en los resultados.