Agendamento / Temporizador
Temporizador de espera
Esse evento é utilizado quando uma atividade precisa ficar escondida de colaboração por determinado tempo antes que o usuário possa colaborar com ela.
Pode ser utilizado, por exemplo, em processos de Produção, onde um produto foi enviado para fabricação e seu processo foi passado para frente na atividade de Embalagem, porém o responsável por essa atividade não pode colaborar imediatamente com o processo. Desse modo, configura-se um temporizador de espera de acordo com o tempo estimado de fabricação do produto para que a atividade "Embalagem" possa ser executada.
** ATENÇÃO: Aguarda 'x' horas e minutos antes de liberar o processo para colaboração.
- Descrição: campo traz por padrão a 'descrição do tipo de evento' mas permite edição.
- Momento da execução: define o momento em que o evento será executado: Ao entrar, Ao sair da atividade, Ao anexar.
- Aguardar* (h): tempo, em horas, que a instância ficará fora de colaboração do usuário, importante dizer que, caso esse campo não seja utilizado, deixar valor padrão zero;
- Aguardar* (min): tempo, em minutos, que a instância ficará fora de colaboração do usuário. Caso esse campo não seja utilizado, deixar o valor padrão zero.
Caso a instância com o temporizador configurado ainda esteja "escondida" da colaboração e seja tentado acessar para continuar, o sistema dará o seguinte erro: "A instância do processo ainda não está liberada para colaboração".
Criar agendamento / Remover agendamento
Esses eventos são em sua maioria utilizados em conjunto. São utilizados caso você queira que uma instância de processo mude sua atividade de acordo com um limite de tempo pré-definido no evento. É importante citar que aqui chegamos a uma parte importante de processos BPM, o motor DOX.
- Descrição: campo traz por padrão a ‘descrição do tipo do evento’, mas permite edição;
- Momento da execução: define o momento em que o evento vai ser executado: Ao entrar, Ao sair da atividade, ou Ao anexar;
- Atividade destino: atividade da instância que será definida como atual após atingir um tempo limite;
- Aguardar* (h): caso sejam horas, aqui poderá ser definido o limite em horas que a atividade poderá ficar sem interação antes de ser passada pra frente. Caso esse campo não seja utilizado, deixar como valor padrão zero;
- Aguardar* (min): caso necessite que o tempo seja contato em minutos, aqui poderá ser definido quantos minutos a atividade poderá ficar sem interação. Caso esse campo não seja utilizado, deixar como valor padrão zero.
Depois de ser criado um evento de CRIAÇÃO de agendamento, precisa criar um evento de REMOÇÃO desse agendamento. Pois ele precisa sumir da fila depois de executado sua ação.
- Descrição: campo traz por padrão a 'descrição do tipo do evento' mas permite edição.
- Momento da execução: Define o momento em que o evento será executado: Ao entrar, Ao sair da atividade, Ao anexar.
- Aguardar* (h): caso sejam horas, aqui poderá ser definido o limite em horas para que os agendamentos sejam removidos. Caso esse campo não seja utilizado, deixar como valor padrão zero.;
- Aguardar* (min): caso sejam minutos, aqui poderá ser definido o limite em minutos para que os agendamentos sejam removidos. Caso esse campo não seja utilizado, deixar como valor padrão zero.
*** ATENÇÃO: É interessante utilizar da seguinte estrutura:
- Cria agendamento AO ENTRAR
- Remove agendamento AO SAIR
Um exemplo de uso destes eventos em um processo seria com um processo de solicitação de investimento. Caso uma solicitação de investimento foi aberta e não houve colaboração na primeira atividade deste processo durante um período de 8 horas, o agendamento encaminha o processo para o fim.
Deste modo, pode-se dizer que a atividade destino dessa atividade será o Fim, pois entende-se que a mesma foi aberta por engano.
Exemplo:
Vamos criar um exemplo com um procedimento, visando mostrar na prática a utilização desses dois eventos de sistema. Porém, antes de criar o BPM, é importa verificar duas questões:
- Como foi citado acima, agendamentos de processos BPM utilizam de motor DOX para serem executados, por isso antes de iniciarmos nosso exemplo verifique se o micro_serviço do motor DOX está ativo, se não, ative e suba os serviços novamente.
Acesse o ema configurador > Serviços > Marque o ema Motor DOX:
- O agendamento que é executado no motor é realizado pelo usuário publico configurado no nosso sistema. Verifique se existe um usuário publico e caso não, clique aqui para entender melhor como configurar.
No exemplo mais a frente iremos criar um processo simples de registro de despesas. Ele funcionará da seguinte forma: caso o usuário fique parado na primeira atividade por 1h hora, o processo irá ser cancelado automaticamente. Se o usuário prosseguir, a despesa informada por ele será cadastrada em uma tabela do banco de dados.
Antes da criação do BPM, vamos criar a nossa tabela de despesas:
CREATE TABLE X_DESPESA (
IDPROCESSO INTEGER NOT NULL PRIMARY KEY,
IDUSUARIO INTEGER NOT NULL,
DESCRICAO VARCHAR (250),
NUMERONOTA INTEGER,
VALOR NUMERIC (15,2))
- Campo "IDPROCESSO" pois o usuário só poderá registrar uma despesa por vez, caso queira mudar esse funcionar, basta personalizar essa tabela de acordo.
- Campo "IDUSUARIO" para ter um registro de quem foi o usuário que fez a inserção das informações, caso futuramente um relatório traga essas informações.
- Os outros campos são os valores informados no processo que iremos criar a seguir.
Agora, vamos criar o nosso BPM. Estamos disponibilizando o BPM Clicando aqui ou em anexo deste tópico. Porém é interessante ler todo o tópico de criação para melhor entendimento.
A principio teremos as seguintes atividades
Atividade 1: Inicio | Padrão |
Atividade 2: Manual "Preenchimento da Despesa" | Onde o usuário colocará as informações de descrição, nota e valor da despesa. |
Atividade 3: Automática "Registra Despesa" | Onde será registrado a despesa no banco de dados. |
Atividade 4: Automática "Cancela processo" | Caso o processo aberto fique sem interação por 1h será encaminhado para a atividade "Cancela processo" e a colaboração se encerará. |
Atividade 9999: Fim | Padrão |
Veja a imagem:
Atividade 2 - Preenchimento da Despesa:
Nesta atividade terá 3 formulários obrigatórios para que o usuário coloque as informações sem falta. Faça conforme a imagem:
** Configure o tamanho dos formulários da forma que achar melhor.
Depois de criado os formulários, vamos para os eventos:
- Evento 1: Define IDPROCESSO
Neste evento vamos definir o valor da variável de sistema /*IDPROCESSO*/ para uma variável que criamos no processo /*CODPROCESSO*/
- Evento 2: Define IDUSUARIO
Vamos pegar o IDUSUARIO que está atualmente colaborando com o processo, passando como parâmetro a variável de sistema /*USERID*/.
SQL de consulta:
SELECT IDUSUARIO
FROM USUARIO
WHERE IDCLIFOREMP = 0/*USERID*/
- Evento 3: Criar agendamento 1h
Chegamos no evento mais importante, no campo "Atividade destino" é necessário colocar a atividade "Cancela processo", ou seja. o agendamento irá mover a colaboração para essa atividade depois de 1h. Outra observação é que o campo de min, deve ter o zero como valor caso nada seja colocado nele. Este evento está AO ENTRAR.
Faça como na imagem abaixo:
- Evento 4: Remover agendamento 1h
Atividade 3 - Registra Despesa:
Nesta atividade automática só iremos criar um evento de executar SQL para que os dados informados pelo usuário sejam cadastrados no banco de dados. Vale ressaltar que isso só ira ocorrer se o processo for colaborador, caso sua colaboração seja abandonada, o processo irá ser cancelado.
SQL de execução:
INSERT INTO X_DESPESA
VALUES (0/*CODPROCESSO*/,
0/*IDUSUARIO*/,
'/*DESCRICAO*/',
'/*NUMERONOTA*/',
CAST(REPLACE('0/*VALOR*/', ',', '.') AS NUMERIC (15,2)))
** Variáveis do tipo texto devem ir entre aspas, enquanto as do tipo inteiro devem ter um zero na frente.
Atividade 4 - Cancela processo
É aqui que o sistema irá encaminhar a colaboração caso haja inatividade. Vamos apenas configurar um evento simples de cancelamento.
O campo "Motivo" irá preencher o campo "motivocancelamento" da tabela CRM_PROCESSO.