Uso de tablas de configuración para definir el flujo de trabajo real

La primera parte de esta serie introdujo algunos pasos básicos para administrar el ciclo de vida de cualquier entidad en una base de datos. Nuestra segunda y última parte le mostrará cómo definir el flujo de trabajo real utilizando tablas de configuración adicionales. Aquí es donde se le presentan al usuario las opciones permitidas en cada paso del camino. También demostraremos una técnica para evitar la reutilización estricta de "ensamblajes" y "subensamblajes" en una estructura de lista de materiales.

Definir las opciones

La Parte 1 presentó las tablas de flujo de trabajo principales y cómo se pueden incorporar fácilmente a su base de datos. Lo que necesitamos ahora es algo que guíe al usuario a seleccionar el siguiente estado lógico, algo que defina un flujo de trabajo lógico. .

El siguiente diagrama define todos los componentes de un modelo de base de datos de flujo de trabajo:

Dos tablas de configuración, workflow_state_option y workflow_state_context , se han añadido al modelo. Comenzaremos con la tabla de opciones, que define los siguientes estados permitidos . Una vez que se comprenda su función, volveremos a la tabla de contexto y explicaremos el papel que desempeña.

Siguientes estados permitidos

Las tablas que siguen son algo así como una vista SQL de nuestras tablas de configuración. Aquí hemos ocultado las combinaciones de tablas y solo estamos viendo las combinaciones de type_keys . Entonces, consideremos cada ESTADO.RESULTADO combinación y definir las opciones disponible para el usuario:

Debido a que estamos ignorando el contexto por ahora, Contexto de estado y ¿Niño discapacitado? están en gris. También he limitado el número de opciones en este ejemplo a dos por razones de brevedad, aunque en la práctica no hay límite.

Entonces, ¿cómo funciona esto?

Imagine que la entrevista acaba de realizarse y el entrevistador está registrando el resultado. La tabla subyacente que se actualiza es managed_entity_state . Hay dos resultados lógicos:APROBADO y NO APROBADO. Así que el managed_entity_state actual se actualiza con el resultado seleccionado (wf_state_type_outcome_id ). En el modelo de ejemplo, el entrevistador también puede incluir algunas notas sobre la entrevista.

Si el entrevistador selecciona APROBADO, se le presentan dos opciones más:HACER_OFERTA y BUSCAR_REFERENCIAS. Estos son los próximos estados en nuestro flujo de trabajo. Son similares a go to declaraciones en la programación. Para cualquiera de las opciones, se inserta una nueva fila en managed_entity_state , moviendo la solicitud de empleo al siguiente estado en el proceso de flujo de trabajo. El usuario puede establecer una fecha límite para esto ingresando un due_date .

Por otro lado, si el entrevistador selecciona FALLIDO, solo hay una opción:APLICACIÓN_CERRADA. Así que un nuevo managed_entity_state la fila se inserta usando el estado APPLICATION_CLOSED (wf_state_type_state_id ).

Verá que no hay opciones disponibles para el estado APLICACIÓN_CERRADA. Esto significa que se ha llegado al final del proceso de flujo de trabajo.

La tabla de contexto

Miremos la configuración para el proceso de solicitud de empleo técnico para ver qué rol tiene la tabla de contexto juega:

Aquí el contexto es TECHNICAL_JOB_APPLICATION. ¿Porque es esto importante? Porque nos permite anular los resultados. Recuerde, anteriormente dijimos que podemos reutilizar "ensamblajes" y "subensamblajes" en una estructura de lista de materiales (BOM). Esto es útil cuando definimos algo una vez y lo reutilizamos, pero también puede ser demasiado rígido. ¿Y si no queremos reutilizar todo?

Insertando workflow_state_context entre workflow_state_hierarchy y workflow_state_option , podemos reutilizar y anular los resultados. En este modelo, podemos definir si un resultado está habilitado o deshabilitado para diferentes procesos.

En el ejemplo anterior, la combinación INTERVIEW.CANDIDATE_CANCELLED está deshabilitada. En otras palabras, estamos diciendo que simplemente no es un resultado permisible para las solicitudes de empleo técnico. En consecuencia, el entrevistador no podrá seleccionarlo cuando registre el resultado de una entrevista técnica de trabajo porque nuestra consulta solo selecciona opciones donde workflow_state_context.child_disabled = ‘N’ .

Porque workflow_state_option no es un hijo directo de workflow_state_hierarchy , tenemos que definir un conjunto separado de opciones cada vez que se usa un estado. Pero esta compensación nos permite ajustar con precisión las opciones para cada proceso.

Resultados de calificación

También tenemos la opción de definir calificadores más detallados para los resultados. Hay dos formas de hacerlo:

1. Puede crear un cuarto nivel en su lista de materiales para definir calificadores en los resultados de la jerarquía. La diligencia debida debe tomarse con este enfoque. Por ejemplo, el resultado FAILED se usa para diferentes estados. ¿Quiere tener los mismos calificadores para diferentes estados FALLIDOS? Tal vez no.
2. Puedes definir tus calificadores en workflow_state_type pero no atarlos a ninguna jerarquía; son independientes. Luego usa workflow_state_option para enumerar los calificadores para el contexto de resultado específico. Esto es lo que muestra la configuración anterior, donde los calificadores OVER_QUALIFIED e INSUFFICIENT_EXPERIENCE se enumeran como opciones para el resultado APPLICATION_CLOSED.NOT_HIRED.

En cualquier caso, la aplicación debe reconocer que se ha seleccionado un calificador en lugar de un estado o un resultado:workflow_level_type indicará esto y actualizará managed_entity_state.wf_state_type_qual_id con el valor seleccionado.

Algunos datos de configuración de tablas

Es posible que desee ver los datos de configuración subyacentes, tabla por tabla. Aquí tenemos los ids y las type_keys se refieren entre paréntesis. En aras de la brevedad, solo se presentan valores relacionados con el artículo.

tipo_nivel_de_flujo_de_trabajo

workflow_state_type

jerarquía_estado_de_flujo_de_trabajo

workflow_state_context

opción_estado_de_flujo_de_trabajo

Claramente, configurar esto es bastante complicado. Preferiblemente, debe administrarse a través de una aplicación con una interfaz fácil de usar.

Secuencias alternativas

Notará que varias tablas tienen una columna llamada alt_sequence . Esto se utiliza para ordenar la lista de valores para las diferentes selecciones presentadas al usuario. Por lo general, esto estará en orden descendente según el uso, con las opciones más utilizadas en la parte superior.

Si bien este artículo describió las solicitudes de empleo, el modelo se puede usar para muchos tipos de flujos de trabajo en los que el estado de una entidad debe administrarse a lo largo del tiempo. Alternativamente, el modelo puede servir como patrón para personalizarlo según sus requisitos particulares.