Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 35 Próxima »

Modelo de Processo de Negócios e Notação (BPMN), fornecerá as empresas um padrão para entender seus procedimentos internos de negócios em uma notação gráfica. Esta notação gráfica tem como principal intuito facilitar o entendimento dos fluxos dos processos das empresas, a fim de garantir que entendam, participem e se ajustem as circunstâncias do negócio.

Utilizando o BPMN em um projeto

  1. Clicar sobre a aba Plugin;
  2. Selecionar opção Adicionar novo plugin;
  3. Selecionar opção General;
  4. Selecionar Cronapp Workflow;
  5. Clicar sobre Avançar, em seguida Finalizar;
  6. Clicar sobre Salvar para confirmar alterações no arquivo POM;

Figura 1.1 - Adicionando Plugins


Figura 1.2 - Adicionando Plugin Cronapp Workflow

Agora tudo está pronto para criar sua primeira aplicação com BPMN, todos os arquivos .bpmn serão implementados automaticamente ao executar o projeto pela primeira vez.

Criando um Fluxo de Trabalho BPMN

  1. Clicar com o botão direito na pasta Arquivos de Recursos;

  2. Selecionar opção Novo;

  3. Selecionar opção Fluxo de Trabalho.


Figura 2.1 - Criando novo arquivo .bpmn


Área de edição do BPMN

O Cronapp Modeler cobre todos os elementos do BPMN 2.0 para processos de modelagem.

Figura 2.1 - Área de edição

  1. Caixa de ferramentas: possui os elementos, que são arrastados e soltos no diagrama, as conexões e as ferramentas para manipulação;
  2. Área de edição: área para construção do diagrama de orquestração;
  3. Área de propriedades: muda conforme o elemento selecionado, mas nessa área é visualizar e editar atributos que se aplicam ao elemento atualmente selecionado.

Elementos do BPMN 2.0

Piscina

Uma piscina serve para representar um processo ou participante. Uma piscina pode ter raias e essas raias significam as responsabilidades que um participante ou processo pode ter.

Figura 2.2.1 - Piscina e Piscina com raia

Subprocesso

Um subprocesso é um conjunto de atividades de um processo maior e ele permite um maior detalhamento do que o processo. O elemento que caracteriza um subprocesso é um retângulo com bordas arrendondas e ele varia conforme os seus tipos: subprocesso embutido (borda simples), atividade de chamada (bordas em negrito), subprocesso por evento (bordas pontilhadas) e transação (bordas dupla). Por padrão, o tipo de subprocesso ao ser arrastado é o subprocesso embutido, mas ao utilizar o ícone de chave inglesa é possível alterar para outro tipo de subprocesso (Figura 2.2).

Figura 2.2.2 - Tipos de subprocesso

  • Subprocesso embutido: subprocesso que faz referência a um processo interno;
  • Atividade de chamada: subprocesso faz referência a um processo externo;
  • Subprocesso por evento: subprocesso que ocorre através da ação de um evento;
  • Transação: subprocesso que agrupa várias atividades para uma transação.

Tarefa

Uma tarefa contém atividades que deverão ser realizadas pelo responsável dentro de um prazo. Essas tarefas podem ter várias definições (Figura 2.3):


Figura 2.2.3 - Tipos de tarefa

  • Tarefa: tarefa sem nenhuma definição;
  • Tarefa de enviar mensagem: envia uma mensagem para um participante ou processo;
  • Tarefa de receber mensagem: espera o recebimento de uma mensagem de um participante ou processo;
  • Tarefa de usuário: realizada por um usuário que esteja no conectado ao motor do BPMN;
  • Tarefa manual: executa uma tarefa que não utiliza o fluxo de trabalho;
  • Tarefa de regra de negócio: executada automaticamente por uma decisão de negócio;
  • Tarefa de serviço: executa ou chama uma regra de negócio;
  • Tarefa de roteiro: executa uma sequência de comandos (script).

Gateways

Gateways são pontos de desvio em um processo, permitindo que decisões sejam tomadas baseando-se em eventos ou dados como também separações e junções simultâneas. O elemento que caracteriza um gateway é um losango e dentro desses losangos, os símbolos determinam seu tipo.

Figura 2.2.4 - Tipos de gateway

  • Gateway exclusivo: define que o processo terá um único caminho através de uma condição previamente imposta; 
  • Gateway paralelo: define que o processo ocorre simultaneamente, podendo que ele seja separado em vários partes ou unidos de vários partes em uma só;
  • Gateway inclusivo: combinação do gateway exclusivo com o gateway paralelo, no qual o mesmo permite que um processo possa ter múltiplos caminhos através das condições previamente impostas;
  • Gateway complexo: controla condições complexas de junções e separações;
  • Gateway baseado em eventos: define que o processo possa fazer desvio baseado nos eventos.

Dados

No BPMN 2.0, os dados a serem manipulados podem ser vindo de objetos ou de banco de dados.

Figura 2.2.5 - Tipos de dados


Eventos

No BPMN 2.0 há três tipos básicos de eventos: o início, o intermediário e o fim. O evento de início é caracterizado por uma borda simples, enquanto o intermediário por uma borda dupla e o final, uma borda em negrito. Esses três tipos de eventos podem ter diversos outros eventos atrelados à eles, como tempo, condição, sinais, mensagens e entre outros.

Eventos de início

Indica o início de um processo ou subprocesso. Há cinco tipos de eventos de início: básico, por mensagem, por tempo, por condição e por sinal (Figura 2.2.6.1).


Figura 2.2.6.1 - Eventos de início

  • Evento de início básico: o início do processo não é específico e que o motor BPMN não tem como quando esse processo poderá ocorrer;
  • Evento de início por mensagem: o início do processo ocorre após o recebimento de uma mensagem;
  • Evento de início por tempo: define o tempo que dará início ao processo;
  • Evento de início por condição: o início do processo ocorre após uma condição lógica;
  • Evento de início por sinal: o início do processo ocorre após o recebimento de um sinal de outro processo.

Eventos intermediário

Os eventos intermediários ocorrem durante o processo.



Evento de finalização

Indica a finalização do processo ou subprocesso. Os eventos de finalização podem ser por mensagem, por escalonamento, por erro, por compensação, por terminação e por sinal.

Figura 2.2.6.3 - Eventos de finalização

  • Evento de finalização básica: indicação simples de que o processo foi finalizado;
  • Evento de finalização por erro: indica que ao finalizar uma mensagem de erro será enviada para um subprocesso;
  • Evento de finalização por terminação: indica que ao finalizar todas as partes do processo serão encerradas;
  • Evento de finalização por mensagem: indica que ao finalizar enviará uma mensagem para outro participante;
  • Evento de finalização por compensação: indica que ao finalizar será iniciado o tratamento de compensações, no qual será desfeito todas as ações ocorridas no processo;
  • Evento de finalização por escalonamento: indica que ao finalizar enviará uma mensagem de escalonamento para eventos de catch;
  • Evento de finalização por sinal: indica que ao finalizar será enviado um sinal para outros processos.

Atalhos dos elementos

Cada elemento e conexão no 

Utilização de Blockly no BPMN

Para utilizarmos um bloco de programação no BPMN são necessários alguns passos prévios.

Permitir a exibição do Bloco Programação

  • Abrir as Propriedades do bloco de programação;
  • Marcar a opção Exibir no Bpmn;
  • Clicar em Salvar.

Figura 4.1.1 - Ativando opção de exibição no Bpmn

Vincular o Bloco de Programação a Tarefa

Para executar o Blockly criado, você deve vinculá-lo a expressões de tarefas de serviço.

  1. Clicar no ícone da ferramenta;
  2. Selecionar a opção Tarefa de Serviço;
  3. Selecionar a opção Expressão da aba de Implementação;
  4. Clicar no botão Editar;
  5. Clicar no botão ... para escolher um Bloco;
  6. Selecionar o bloco de programação a ser vinculado a tarefa.

Figura 4.2.1 - Implementação de Expressão para vincular um Blockly


Figura 4.2.2 - Selecionando o bloco a ser vinculado

Variáveis de processo

Esta seção descreve os conceitos de variáveis em processos. As variáveis podem ser usadas para adicionar dados ao processo de tempo de execução ou, mais especificamente, aos escopos de variáveis. Vários métodos de API que alteram o estado dessas entidades permitem a atualização das variáveis anexadas. Em geral, uma variável consiste em um nome e um valor. O nome é usado para identificação nas construções do processo. Por exemplo, se uma atividade define uma variável chamada var , uma atividade de acompanhamento pode acessá-la usando esse nome. O valor de uma variável é um objeto Java.

Escopos variáveis e visibilidade de variável

Todas as entidades que podem ter variáveis são chamadas de escopos de variáveis . Estas são execuções (que incluem instâncias de processo) e tarefas. O estado de tempo de execução de uma instância do processo é representado por uma árvore de execuções. Considere o seguinte modelo de processo em que os pontos vermelhos marcam tarefas ativas:

A estrutura de tempo de execução desse processo é a seguinte:

Há uma instância de processo com duas execuções filho, cada uma das quais criou uma tarefa. Todas essas cinco entidades são escopos variáveis e as setas marcam um relacionamento pai-filho. Uma variável definida em um escopo pai é acessível em todos os escopos filhos, a menos que um escopo filho defina uma variável com o mesmo nome. Por outro lado, as variáveis filho não são acessíveis no escopo pai. Variáveis diretamente anexadas ao escopo em questão são chamadas de variáveis locais . Considere a seguinte atribuição de variáveis aos escopos:

Nesse caso, ao trabalhar na Tarefa 1, as variáveis worker e customer estão acessíveis. Note-se que, devido à estrutura de espaços, a variável trabalhador pode ser definida por duas vezes, de modo que Tarefa 1 acede a um diferente trabalhador variável de Tarefa 2 . No entanto, ambos compartilham o cliente variável, o que significa que, se essa variável for atualizada por uma das tarefas, essa alteração também será visível para a outra.

Ambas as tarefas podem acessar duas variáveis cada uma, enquanto nenhuma delas é uma variável local. Todas as três execuções têm uma variável local cada.

Agora, digamos, definimos um cliente de variável local na Tarefa 1 :

Enquanto duas variáveis denominadas cliente e trabalhador ainda podem ser acessadas na Tarefa 1 , a variável do cliente na Execução 1 está oculta, portanto, a variável acessível do cliente é a variável local da Tarefa 1 .

Em geral, as variáveis são acessíveis nos seguintes casos:

  • Instanciando processos
  • Entregando mensagens
  • Transições do ciclo de vida da tarefa, como conclusão ou resolução
  • Configurando / obtendo variáveis de fora
  • Definindo / obtendo variáveis
  • Expressões no modelo de processo
  • Scripts no modelo de processo
  • Consultas variáveis (históricas)


Valores de variáveis suportados

O mecanismo do processo suporta os seguintes tipos de valores variáveis:

Dependendo do valor real de uma variável, um tipo diferente é atribuído. Entre os tipos disponíveis, existem nove tipos de valores primitivos , o que significa que eles armazenam valores de classes JDK padrão simples sem metadados adicionais:

  • boolean: Instâncias de java.lang.Boolean
  • bytes: Instâncias de byte[]
  • short: Instâncias de java.lang.Short
  • integer: Instâncias de java.lang.Integer
  • long: Instâncias de java.lang.Long
  • double: Instâncias de java.lang.Double
  • date: Instâncias de java.util.Date
  • string: Instâncias de java.lang.String
  • null: nullreferências

Os valores primitivos diferem de outros valores de variáveis, pois podem ser usados em consultas de API, como consultas de instância de processo como condições de filtragem.

O tipo file pode ser usado para armazenar o conteúdo de um arquivo ou fluxo de entrada, juntamente com metadados, como um nome de arquivo, uma codificação e o tipo MIME ao qual o conteúdo do arquivo corresponde.

O tipo de valor objectrepresenta objetos Java customizados. Quando essa variável é persistida, seu valor é serializado de acordo com um procedimento de serialização. Esses procedimentos são configuráveis e intercambiáveis.

Referencias da Api Rest

O objetivo da API REST é fornecer acesso a todas as interfaces relevantes do mecanismo

Para acessar todos os métodos e os formatos e conteúdos esperados clique no link:
https://docs.camunda.org/manual/7.11/reference/rest/

Estrutura

Estes documentos explicam todos os métodos existentes na API REST. Para cada método que eles fornecem:

  • Uma descrição informal
  • Verbo e URL HTTP
  • Possíveis parâmetros de consulta, caminho ou corpo da mensagem
  • Uma descrição detalhada do conteúdo da resposta
  • Possíveis códigos de resposta
  • Um breve exemplo de solicitação e resposta

Uso do motor

Os métodos descritos funcionam no mecanismo de processo padrão, conforme fornecido pelo ProcessEngineProviderserviço disponível .

Você pode anexar /engine/{name}um dos métodos (a menos que esteja documentado em contrário) para acessar outro mecanismo em que {name}está o nome do mecanismo de processo retornado por, por exemplo /engine/myEngineName/task


Tratamento de erros

Para todos os métodos, esta documentação fornece possíveis códigos de status HTTP. As explicações do código de erro não cobrem todas as possíveis causas de erro que podem surgir quando a solicitação é atendida, por exemplo, a maioria das solicitações não funcionará corretamente se houver problemas com o acesso ao banco de dados. Qualquer um desses erros não documentados será convertido em um erro HTTP 500.

Todos os erros também fornecem um corpo de resposta JSON do formulário:

  {
    "type" : "SomeExceptionClass",
    "message" : "a detailed message"
  }

Exceções de autorização

Se um usuário já autenticado interagir com um recurso de maneira não autorizada, o código de status da resposta será definido como 403 Forbidden. Detalhes sobre a interação não autorizada são fornecidos no corpo da resposta.

Tipo

AuthorizationException

Corpo de resposta

{"type" : "AuthorizationException", "message" : "The user with id 'jonny' does not have 'DELETE' permission on resource 'Mary' of type 'User'.", "userId" : "jonny", "permissionName" : "DELETE", "resourceName" : "User", "resourceId" : "Mary"}


Nessa Página:

  • Sem rótulos