Modelo

Un WorkflowModel representa una definición (modelo) de un flujo de trabajo. Está compuesto por WorkflowNodes y WorkflowTransitions. Las transiciones conectan los nodos y definen flow. El modelo siempre tiene un nodo de inicio y un nodo de finalización.

Modelo Runtime

Los modelos de flujo de trabajo tienen versiones. Al ejecutar una instancia de flujo de trabajo, se utiliza y se mantiene el modelo de tiempo de ejecución del flujo de trabajo, tal como estaba disponible en el momento en que se inició el flujo de trabajo.

Se genera un modelo en tiempo de ejecución cuando se activa Sync en el editor del modelo de flujo de trabajo.

Las ediciones realizadas en el modelo de flujo de trabajo, en los modelos de tiempo de ejecución generados o en ambos, después de de iniciar la instancia específica no se aplican a esa instancia.

ATENCIÓN
Los pasos realizados están definidos por el modelo de tiempo de ejecución, generado en el momento en que se activa la acción Sincronizar en el editor del modelo de flujo de trabajo.
Si el modelo de flujo de trabajo cambia después de este momento (sin que se active Sync), la instancia de tiempo de ejecución no reflejará dichos cambios. Solo los modelos en tiempo de ejecución generados después de la actualización reflejan los cambios. Las excepciones son los scripts ECMA subyacentes, que se conservan una sola vez para que se realicen los cambios.

Paso

Cada paso realiza una tarea discreta. Existen diferentes tipos de pasos del flujo de trabajo:

  • Participante (usuario/grupo): estos pasos generan un elemento de trabajo y lo asignan a un usuario o grupo. Un usuario debe completar el elemento de trabajo para avanzar en el flujo de trabajo.
  • Process (Script, Java™ method call): el sistema ejecuta estos pasos automáticamente. Un script ECMA o una clase Java™ implementan el paso. Los servicios se pueden desarrollar para escuchar eventos de flujo de trabajo especiales y realizar tareas según la lógica empresarial.
  • Contenedor (subflujo de trabajo): este tipo de paso inicia otro modelo de flujo de trabajo.
  • OR Split/Join: utilice la lógica para decidir qué paso ejecutar en el flujo de trabajo.
  • División/unión AND: permite ejecutar varios pasos simultáneamente.

Todos los pasos comparten las siguientes propiedades comunes: Autoadvance y Timeout alertas (que se pueden usar como scripts).

Transición

Un(a) WorkflowTransition representa una transición entre dos WorkflowNodes de un(a) WorkflowModel.

  • Define el vínculo entre dos pasos consecutivos.
  • Es posible aplicar reglas.

WorkItem

Un(a) WorkItem es la unidad que se pasa a través de una instancia Workflow de un(a) WorkflowModel. Contiene el WorkflowData en el que actúa la instancia y una referencia al WorkflowNode que describe el paso de flujo de trabajo subyacente.

  • Se utiliza para identificar la tarea y se coloca en la bandeja de entrada correspondiente.
  • Una instancia de flujo de trabajo puede tener uno o varios WorkItems al mismo tiempo (según el modelo de flujo de trabajo).
  • WorkItem hace referencia a la instancia de flujo de trabajo.
  • En el repositorio, WorkItem se almacena debajo de la instancia de flujo de trabajo.

Carga útil

Hace referencia al recurso que debe avanzarse a través de un flujo de trabajo.

La implementación de carga útil hace referencia a un recurso del repositorio (por ruta, UUID o URL) o por un objeto Java™ serializado. La referencia a un recurso en el repositorio es flexible y fiable, con sling productivo. Por ejemplo, el nodo al que se hace referencia podría representarse como un formulario.

Ciclo de vida

Se crea al iniciar un nuevo flujo de trabajo (seleccionando el modelo de flujo de trabajo correspondiente y definiendo la carga útil) y finaliza cuando se procesa el nodo final.

Las siguientes acciones son posibles en una instancia de flujo de trabajo:

  • Terminar
  • Suspender
  • Reanudar
  • Reiniciar

Se archivan las instancias completadas y terminadas.

Bandeja de entrada

Cada cuenta de usuario tiene su propia bandeja de entrada de flujo de trabajo en la que se puede acceder a los WorkItems asignados.

Los(as) WorkItems se asignan a la cuenta de usuario directamente o al grupo al que pertenecen.

Tipos de flujo de trabajo

Existen varios tipos de flujo de trabajo como se indica en la consola Modelos de flujo de trabajo:

wf-actualizado-03

  • Predeterminado

    AEM Estos tipos son los flujos de trabajo listos para usar incluidos en una instancia estándar de la interfaz de usuario de la aplicación de.

  • Flujos de trabajo personalizados (sin indicador en la consola)

    Estos flujos de trabajo se han creado como nuevos o a partir de flujos de trabajo integrados que se han superpuesto con las personalizaciones.

  • Heredado

    AEM Flujos de trabajo creados en una versión anterior de. Estos flujos de trabajo se pueden retener durante una actualización o exportarse como un paquete de flujo de trabajo de la versión anterior y luego importarse en la nueva versión.

Flujos de trabajo transitorios

Los flujos de trabajo estándar guardan la información de tiempo de ejecución (historial) durante su ejecución. También puede definir un modelo de flujo de trabajo como Transitorio para evitar que dicho historial se mantenga. Este flujo de trabajo se utiliza para ajustar el rendimiento porque ahorra tiempo y recursos que se utilizan para mantener la información.

Los flujos de trabajo transitorios se pueden utilizar para cualquier flujo de trabajo que:

  • se ejecutan a menudo.
  • no necesita el historial del flujo de trabajo.

Se han introducido flujos de trabajo transitorios para cargar muchos recursos, donde la información del recurso es importante, pero no el historial de tiempo de ejecución del flujo de trabajo.

NOTA
Consulte Creación de un flujo de trabajo transitorio para obtener más información.
ATENCIÓN
Cuando un modelo de flujo de trabajo se marca como Transitorio, hay algunos escenarios en los que la información de tiempo de ejecución debe persistir:
  • El tipo de carga útil (por ejemplo, vídeo) requiere pasos externos para el procesamiento; en estos casos, el historial de tiempo de ejecución es necesario para la confirmación de estado.
  • El flujo de trabajo introduce AND Split. En estos casos, el historial de tiempo de ejecución es necesario para la confirmación de estado.
  • Cuando el flujo de trabajo transitorio introduce un paso de participante, cambia de modo, durante la ejecución, a no transitorio. Como la tarea se pasa a una persona, el historial debe persistir.
ATENCIÓN
Dentro de un flujo de trabajo transitorio, no debería usar un Paso Ir a.
El motivo es que Ir al paso crea un trabajo de sling para continuar el flujo de trabajo en el punto goto. Evita el propósito de hacer que el flujo de trabajo sea transitorio y genera un error en el archivo de registro.
Use OR Split para hacer elecciones dentro de un flujo de trabajo transitorio.
NOTA
Consulte las Prácticas recomendadas para Assets para obtener más información sobre cómo los flujos de trabajo transitorios afectan el rendimiento de los recursos.