Cómo cambiar el flujo de trabajo?

Question

Por ejemplo, el sistema procesa un pedido de cliente por check identification -> validate order context -> make order. Sin embargo, el administrador del sistema puede cambiar el flujo en tiempo de ejecución, el administrador puede saltarse el “validate order context”.

Mi pregunta es si el sistema está procesando las solicitudes de pedidos simultáneos, cuando el sistema debe aplicar el cambio de flujo?

• a):. Aplicar el cambio hasta la próxima solicitud de pedido nueva

• b): Aplicar el cambio inmediatamente, sin importar cualquier petición está siendo procesada. Suena demasiado rígido.

• c): aplicar el cambio hasta un cierto tiempo, por ejemplo, cualquier cambio será aplicado a las 00:00:00. No creo que es una buena estrategia.

¿Cuál es la mejor práctica para la situación? Si utilizo marco JBMP para controlar el flujo de trabajo, ¿qué estrategia se puede utilizar en tal caso? Gracias!

Answer 1

Las tres opciones son válidas. La elección correcta dependerá del problema que se está resolviendo. He aquí algunos ejemplos:

1. Aplicar el cambio a partir de la próxima nueva orden. Esta es una buena opción si quieres fase en un nuevo flujo de trabajo. Es posible describir esto como "terminar el trabajo actual con el flujo de trabajo actual, pero todo nuevo trabajo va a utilizar el nuevo flujo de trabajo".
2. Aplicar el cambio inmediatamente. Esta es una buena opción si es más importante que el flujo de trabajo currect (por eso, quiero decir el nuevo flujo de trabajo) se utilizará para todo el trabajo (tanto actuales como nuevo). Un ejemplo de esto podría ser "Hemos eliminado un paso innecesario del flujo de trabajo."
3. Aplicar el cambio a partir de un momento certin. Esta es una buena opción en situaciones que pueden describe así: "Hoy estamos utilizando el antiguo flujo de trabajo, pero mañana comenzamos con el nuevo flujo de trabajo"

Answer 2

Su primera opción de aplicar con el siguiente flujo de trabajo (es decir, orden) es la más segura desde el punto de vista de la concurrencia. Esto es lo que haría , ya que no interfiere con los objetos con estado y es muy claro, entonces, que un observador lo que ocurrió.

La segunda opción requiere bloqueo de los flujos de trabajo existentes para asegurar que ninguno se encuentran en el estado validate order context. Y, si hay alguno, escribir un algoritmo para resolver moverlo de ese estado correctamente.

Por último, su última opción es realmente sólo la programación de alrededor de los dos primeros. Como tal, se podría incorporar en cualquiera de los dos y debe ser impulsada por las reglas de negocio (requisitos es decir).