A primeira parte desta série apresentou algumas etapas básicas para gerenciar o ciclo de vida de qualquer entidade em um banco de dados. Nossa segunda e última parte mostrará como definir o fluxo de trabalho real usando tabelas de configuração adicionais. É aqui que o usuário é apresentado com opções permitidas em cada etapa do caminho. Também demonstraremos uma técnica para contornar a reutilização estrita de 'montagens' e 'submontagens' em uma estrutura de lista de materiais.
Definindo as opções
A Parte 1 apresentou as principais tabelas de fluxo de trabalho e como elas podem ser facilmente incorporadas ao seu banco de dados. O que precisamos agora é algo para orientar o usuário na seleção do próximo estado lógico – algo que defina um fluxo de trabalho lógico .
O diagrama abaixo define todos os componentes de um modelo de banco de dados de fluxo de trabalho:
Duas tabelas de configuração,
workflow_state_option
e workflow_state_context
, foram adicionados ao modelo. Começaremos com a tabela de opções, que define os próximos estados permitidos . Uma vez compreendida sua função, retornaremos à tabela de contexto e explicaremos o papel que ela desempenha. Próximos estados permitidos
As tabelas a seguir são como uma visualização SQL em nossas tabelas de configuração. Aqui ocultamos as junções de tabela e estamos apenas olhando para as combinações de
type_keys
. Então, vamos considerar cada STATE.OUTCOME combinação e defina as opções disponível para o usuário:Combinação STATE.OUTCOME (da hierarquia de estado) | Contexto do Estado | Criança desativada | Opção 1 | Opção 2 |
---|---|---|---|---|
APPLICATION_RECEIVED .ACEITO | STANDARD_JOB _APPLICATION | N | APPLICATION_REVIEW | |
APLICATION_RECEIVED .REJECTED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
REVISÃO_APLICATIVO .APROVADO | STANDARD_JOB _APPLICATION | N | INVITED_TO_INTERVIEW | |
APLICATION_REVIEW .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
INVITED_TO_INTERVIEW .ACEITO | STANDARD_JOB _APPLICATION | N | ENTREVISTA | |
INVITED_TO_INTERVIEW .RECUSADO | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
ENTREVISTA .APROVADO | STANDARD_JOB _APPLICATION | N | MAKE_OFFER | SEEK_REFERENCES |
ENTREVISTA.FALHA | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
ENTREVISTA .CANDIDATE_CANCELLED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | INVITED_TO_INTERVIEW |
ENTREVISTA .NO_SHOW | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
MAKE_OFFER.ACCEPTED | STANDARD_JOB _APPLICATION | N | SEEK_REFERENCES | |
MAKE_OFFER.DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
SEEK_REFERENCES .PASSED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .CONTRATADO | |
SEEK_REFERENCES .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
APPLICATION_CLOSED .CONTRATADO | STANDARD_JOB _APPLICATION | N | ||
APPLICATION_CLOSED .NOT_HIRED | STANDARD_JOB _APPLICATION | N |
Como estamos ignorando o contexto por enquanto, Contexto de estado e Criança desativada? estão acinzentados. Também limitei o número de opções neste exemplo a duas por questões de brevidade, embora na prática não haja limite.
Então, como isso funciona?
Imagine que a entrevista acabou de ser realizada e o entrevistador está registrando o resultado. A tabela subjacente que está sendo atualizada é
managed_entity_state
. Existem dois resultados lógicos:APROVADO e REPROVADO. Portanto, o managed_entity_state
atual é atualizado com o resultado selecionado (wf_state_type_outcome_id
). No modelo de exemplo, o entrevistador também pode incluir algumas notas sobre a entrevista. Se o entrevistador selecionar PASSED, serão apresentadas mais duas opções:MAKE_OFFER e SEEK_REFERENCES. Estes são os próximos estados em nosso fluxo de trabalho. Eles são semelhantes a
go to
declarações em programação. Para qualquer uma das opções, uma nova linha é inserida em managed_entity_state
, movendo o aplicativo de trabalho para o próximo estado no processo de fluxo de trabalho. O usuário pode definir um prazo para isso inserindo um due_date
. Por outro lado, se o entrevistador selecionar FAILED, há apenas uma opção:APPLICATION_CLOSED. Portanto, um novo
managed_entity_state
a linha é inserida usando o estado APPLICATION_CLOSED (wf_state_type_state_id
). Você verá que não há opções disponíveis para o estado APPLICATION_CLOSED. Isso significa que o fim do processo de fluxo de trabalho foi alcançado.
A Tabela de Contexto
Vejamos a configuração do processo de inscrição para vagas técnicas para ver qual função a tabela de contexto tocam:
Combinação STATE.OUTCOME (da hierarquia de estado) | Contexto do Estado | Criança desativada | Opção 1 | Opção 2 |
---|---|---|---|---|
APPLICATION_RECEIVED .ACEITO | TECHNICAL_JOB _APLICAÇÃO | N | APLICAÇÃO _REVISÃO | |
APLICATION_RECEIVED .REJECTED | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | |
REVISÃO_APLICATIVO .APROVADO | TECHNICAL_JOB _APLICAÇÃO | N | INVITED_TO _INTERVIEW | |
APLICATION_REVIEW .FAILED | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | |
INVITED_TO_INTERVIEW .ACEITO | TECHNICAL_JOB _APLICAÇÃO | N | TEST_APTITUDE | |
INVITED_TO_INTERVIEW .RECUSADO | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | |
TEST_APTITUDE .PASSED | TECHNICAL_JOB _APLICAÇÃO | N | ENTREVISTA | BUSCAR _REFERÊNCIAS |
TEST_APTITUDE .FAILED | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | |
ENTREVISTA .APROVADO | TECHNICAL_JOB _APLICAÇÃO | N | MAKE_OFFER | BUSCAR _REFERÊNCIAS |
ENTREVISTA .FALHA | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | |
ENTREVISTA .CANDIDATE_CANCELLED | TECHNICAL_JOB _APPLICATION | S | - | - |
ENTREVISTA .NO_SHOW | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | INVITED_TO _INTERVIEW |
MAKE_OFFER .ACEITO | TECHNICAL_JOB _APLICAÇÃO | N | BUSCAR _REFERÊNCIAS | |
MAKE_OFFER .RECUSADO | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | |
SEEK_REFERENCES .PASSED | TECHNICAL_JOB _APLICAÇÃO | N | APLICAÇÃO _CLOSED.SUCESS | |
SEEK_REFERENCES .FAILED | TECHNICAL_JOB _APLICAÇÃO | N | APLICATIVO _FECHADO | |
APPLICATION_CLOSED .CONTRATADO | TECHNICAL_JOB _APLICAÇÃO | N | ||
APPLICATION_CLOSED .NOT_HIRED | TECHNICAL_JOB _APLICAÇÃO | N | INSUFICIENTE _EXPERIÊNCIA | MAIS _QUALIFICADO |
Aqui o contexto é TECHNICAL_JOB_APPLICATION. Por que isso é importante? Porque nos permite substituir os resultados. Lembre-se, afirmamos anteriormente que podemos reutilizar 'montagens' e 'submontagens' em uma estrutura de lista de materiais (BOM). Isso é útil quando definimos algo uma vez e o reutilizamos, mas também pode ser muito rígido. E se não quisermos reutilizar tudo?
Ao inserir
workflow_state_context
entre workflow_state_hierarchy
e workflow_state_option
, podemos reutilizar e substituir os resultados. Nesse modelo, podemos definir se um resultado está habilitado ou desabilitado para diferentes processos. No exemplo acima, a combinação INTERVIEW.CANDIDATE_CANCELLED está desabilitada. Em outras palavras, estamos dizendo que simplesmente não é um resultado permitido para candidaturas a empregos técnicos. Consequentemente, o entrevistador não poderá selecioná-lo ao registrar o resultado de uma entrevista de emprego técnica porque nossa consulta seleciona apenas opções em que
workflow_state_context.child_disabled = ‘N’
. Porque
workflow_state_option
não é um filho direto de workflow_state_hierarchy
, temos que definir um conjunto separado de opções cada vez que um estado é usado. Mas essa compensação nos permite ajustar as opções para cada processo. Resultados Qualificados
Também temos a opção de definir qualificadores mais detalhados para resultados. Há duas maneiras de fazer isso:
- Você pode criar um quarto nível em sua BOM para definir qualificadores em resultados na hierarquia. A devida diligência deve ser tomada com esta abordagem. Por exemplo, o resultado FAILED é usado para diferentes estados. Deseja ter os mesmos qualificadores para diferentes estados FAILED? Talvez não.
- Você pode definir seus qualificadores em
workflow_state_type
mas não os vincula a nenhuma hierarquia; eles são autônomos. Você então usaworkflow_state_option
para listar os qualificadores para o contexto de resultado específico. Isso é o que a configuração acima mostra, onde os qualificadores OVER_QUALIFIED e INSUFFICIENT_EXPERIENCE são listados como opções para o resultado APPLICATION_CLOSED.NOT_HIRED.
Em ambos os casos, o aplicativo deve reconhecer que um qualificador foi selecionado em vez de um estado ou resultado –
workflow_level_type
indicará isso – e atualizará managed_entity_state.wf_state_type_qual_id
com o valor selecionado. Alguns dados de configuração de tabela
Você pode querer ver os dados de configuração subjacentes, tabela por tabela. Aqui temos os
ids
e as type_keys
eles se referem entre parênteses. Por questões de brevidade, são apresentados apenas os valores relacionados ao artigo. workflow_level_type
id | type_key |
---|---|
1 | PROCESSO |
2 | ESTADO |
3 | RESULTADO |
4 | QUALIFICADOR |
workflow_state_type
id | type_key | workflow_level_type_id |
---|---|---|
1 | STANDARD_JOB_APPLICATION | 1 (PROCESSO) |
2 | TECHNICAL_APPLICATION | 1 (PROCESSO) |
3 | ENTREVISTA | 2 (ESTADO) |
4 | APROVADO | 3 (RESULTADO) |
5 | FALHOU | 3 (RESULTADO) |
6 | MAKE_OFFER | 2 (ESTADO) |
7 | SEEK_REFERENCES | 2 (ESTADO) |
8 | APPLICATION_CLOSED | 2 (ESTADO) |
9 | CONTRATADO | 3 (RESULTADO) |
10 | NOT_HIRED | 3 (RESULTADO) |
11 | INSUFFICIENT_EXPERIENCE | 4 (QUALIFICADOR) |
12 | OVER_QUALIFIED | 4 (QUALIFICADOR) |
workflow_state_hierarchy
id | state_type_parent_id | state_type_child_id |
---|---|---|
1 | 1 (STANDARD_JOB_APPLICATION) | 3 (ENTREVISTA) |
2 | 2 (TECHNICAL_JOB_APPLICATION) | 3 (ENTREVISTA) |
3 | 3 (ENTREVISTA) | 4 (APROVADO) |
4 | 3 (ENTREVISTA) | 5 (FALHADO) |
5 | 1 (STANDARD_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
6 | 2 (TECHNICAL_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
7 | 8 (APPLICATION_CLOSED) | 9 (contratado) |
8 | 8 (APPLICATION_CLOSED) | 10 (NOT_HIRED) |
workflow_state_context
id | state_type_id | state_hierarchy_id | child_disabled |
---|---|---|---|
1 | 1 (STANDARD_JOB_ APPLICATION) | 3 (ENTREVISTA.APROVADA) | N |
2 | 1 (STANDARD_JOB_ APPLICATION) | 4 (ENTREVISTA. FALHA) | N |
3 | 1 (STANDARD_JOB_ APPLICATION) | 7 (APPLICATION_CLOSED. CONTRATADO) | N |
4 | 1 (STANDARD_JOB_ APPLICATION) | 5 (APPLICATION_CLOSED. NOT_HIRED) | N |
5 | 2 (TECHNICAL_APPLICATION) | 6 (APPLICATION_CLOSED. NOT_HIRED) | N |
workflow_state_option
id | state_context_id | state_type_id |
---|---|---|
1 | 1 (STANDARD_JOB_ APPLICATION. ENTREVISTA. APROVADA) | 6 (MAKE_OFFER) |
2 | 1 (STANDARD_JOB_ APPLICATION. ENTREVISTA. APROVADA) | 7 (SEEK_REFERENCES) |
3 | 2 (STANDARD_JOB_ APPLICATION. ENTREVISTA. FALHA) | 8 (APPLICATION_CLOSED) |
4 | 5 (TECHNICAL_JOB_ APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 11 (INSUFFICIENT_EXPERIENCE) |
5 | 5 (APLICAÇÃO _JOB_ TÉCNICA. APLICAÇÃO_FECHADA. NÃO_CONTRATADA) | 12 (OVER_QUALIFIED) |
Claramente, configurar isso é bastante complicado. Deve ser administrado preferencialmente por meio de um aplicativo com interface amigável.
Sequências alternativas
Você notará que várias tabelas têm uma coluna chamada
alt_sequence
. Isso é usado para ordenar a lista de valores para as diferentes seleções apresentadas ao usuário. Normalmente, isso estará em ordem decrescente com base no uso, com as opções mais usadas no topo. Embora este artigo tenha descrito os aplicativos de trabalho, o modelo pode ser usado para muitos tipos de fluxos de trabalho em que o estado de uma entidade precisa ser gerenciado ao longo do tempo. Alternativamente, o modelo pode servir como um padrão para personalizar de acordo com seus próprios requisitos específicos.