Windows Workflow - PersistableIdle

Question

En nuestra empresa tenemos un proceso de negocio que necesite:

1. obtener datos de X
2. Espere a que el usuario Y para hacer la investigación
3. obtener datos de Z basado en el paso 2 datos

Al investigar esto, parece que hay algunas opciones para implementar esto en el flujo de trabajo.

1. Agregue una actividad de retardo entre el Paso 1 (actividad de flujo de trabajo) y el Paso 3 (actividad de flujo de trabajo). Luego, durante el evento PersistableIdle, descarga el flujo de trabajo. Cuando el usuario finalice con el paso 2, vuelva a cargar el flujo de trabajo de la base de datos.
2. Igual que el n. ° 1 excepto que se usa un marcador en lugar de una actividad de retardo.

¿Hay una mejor aproximación (1, 2 u otra opción)?

Todas nuestras otras actividades son AsyncCodeActivities, así que estoy bastante seguro de que no dispararán el evento PersistableIdle (ya que están en una zona sin persistencia), pero quiero asegurarme de que el flujo de trabajo no se descargue accidentalmente en otros casos. ¿Hay algún riesgo aquí? ¿Hay alguna forma de crear una actividad que fuerce la descarga del flujo de trabajo?

Answer 1

¿Hay un mejor enfoque (1, 2 u otra opción)?

A primera vista, parece # 2 necesario. La razón para usar marcadores (o actividad de marcadores de algún tipo, como Recibir) es que se pueden reanudar en cualquier momento. Esto permite que finalice la investigación Y del usuario y el flujo de trabajo reanude la ejecución en cualquier momento (en lugar de bloquearse hasta que caduque el retraso).

El argumento en contra, que # 1 también puede ser necesario, es que quizás desee establecer un límite de tiempo que active las acciones del flujo de trabajo (se disparan los avisos, excepciones, cancelaciones, etc.).

¿Cómo decidir? Creo que la respuesta suele ser # 3: Ambos

Usar Pick Activity es una gran manera de hacer ambas cosas. Al utilizar la actividad de Marcadores en un activador PickBranch y la actividad Delay en el otro activador PickBranch, puede componer un flujo de trabajo que 'manejará lo que ocurra primero - usuario Y, o tiempo de espera'.

Una pregunta secundaria que planteas es '¿Cómo impido que un flujo de trabajo se descargue cuando no quiero que sea? ¿Es sorprendente la descarga de flujo de trabajo de riesgo?

Bueno, eso depende. Si está utilizando WorkflowServiceHost, tener el flujo de trabajo descargado no parece ser un gran riesgo, porque WorfklowServiceHost es lo suficientemente inteligente como para volver a cargar su flujo de trabajo cuando necesita hacer más trabajo (manejar un mensaje entrante o reanudar el retraso).

Si no está utilizando WorkflowServiceHost, probablemente esté escribiendo su host, puede lograr el mismo efecto con algo de trabajo, o puede evitar que la descarga ocurra, cuando usted escribe el host, usted controla la política de descarga , a través de los eventos en la Aplicación de flujo de trabajo

Otros puntos varios: -Las actividades de código asíncrono evitan que su flujo de trabajo persista mientras realizan un trabajo asincrónico. Sin embargo, no creo que deban usarse deliberadamente como mecanismo antipersistencia, si quieres uno de ellos, echa un vistazo al NoPersistZone activity.

-No hay actividad 'Descargar', pero hay una actividad 'Persistir'. Los flujos de trabajo pueden indicar que desean guardar el progreso, pero solo el host puede tomar la decisión final cuando ocurre la descarga.