Arquivos Mensais:dezembro 2012

Um guia para iniciar estudos em BPMN (V): Subprocessos

-
(9) Comentários

Retornando ao tema Atividades (Activities), em nossa série de artigos dedicados ao BPMN Nível 1, há um segundo tipo deste elemento além das tarefas (tasks): são os subprocessos.

Tarefas que em conjunto possuam um propósito específico dentro de um processo de negócio podem ser abstraídas em uma outra unidade de processo e representadas no processo maior por um único objeto do tipo atividade, denominado Subprocesso.

Subprocessos são representados visualmente como retângulos com bordas arredondadas (como as tarefas), porém apresentam um símbolo [+] na base inferior implicando no entendimento que esta atividade contém um conjunto de tarefas. Subprocessos são conectados ao fluxo do processo da mesma forma que as outras atividades, através de conectores de fluxo de sequência.

No exemplo acima, a atividade “Aprovação de exceções de negócio” é um subprocesso, que abstrai um conjunto de atividades cujo propósito é avaliar uma exceção de negócio (por exemplo, crédito para um cliente antigo mesmo que tenha situação financeira negativa) para então dar continuidade à concessão do crédito se esta exceção for autorizada. Abaixo tem-se um exemplo de detalhamento das atividades deste subprocesso.

Em geral, o fluxo que compõe o subprocesso é mapeado em um diagrama separado. Algumas ferramentas permitem criar vínculo entre o diagrama do processo principal e o subprocesso, possibilitando a navegação de um para outro com um ou dois cliques de mouse.

Se o processo que está sendo modelado possui muitas atividades e conexões, tornando-o difícil para a interpretação dos leitores, a utilização de subprocessos pode ser um excelente artificio para organizar o fluxo sem interferir diretamente na execução do mesmo, possibilitando criar uma visão mais abstrata e objetiva das atividades que ocorrem no processo.

Subprocessos também podem ser úteis para reunir partes de fluxos que podem ser repetidas em momentos distintos do processo, caracterizando reuso.

Continue acompanhando! No sexto e último artigo deste guia básico, swimlanes e artefatos para apoiar na organização do diagrama do processo.

Confira todos os artigos deste guia de BPMN Nível 1:

Quando usar o OSB, Oracle BPEL ou Oracle BPM

-
Comentar

Estivemos presentes no Oracle Open World Brasil 2012 e tivemos a oportunidade de ter uma agradável conversa com um consultor da Oracle sobre uma dúvida recorrente entre os nossos clientes. Por mais que saibamos para ‘que serve’ cada produto, muitas vezes, em projetos de automação de processos e de integração de sistemas, existe a dúvida: quando utilizar OSB, Oracle BPEL e Oracle BPM?

Usando do expertise da iProcess e da Oracle buscamos alguns pontos que podem ajudar na tomada de decisão. São eles:

  • BPEL e BPM possuem a auditoria completa da execução da instância de orquestração e do processo automatizado. Assim, se o serviço precisa de auditoria, sugere-se escolher um deles. OSB não tem esse requisito.
  • O seu projeto vai produzir eventos que irão ser integrados ao Oracle BAM? BPEL e BPM possuem esse recurso e o desenvolvimento é rápido e fácil com ele. OSB, não.
  • É necessário utilizar o error hospital, incluindo a ressubmissão de mensagens etrace completo no caso de erro? Essa também é uma característica do BPEL e BPM.
  • BPEL/BPM são stateful (guarda o estado do processo) e OSB é stateless (não guarda o estado do processo). Ou seja, caso seja necessário ter uma execução de longa duração (de alguns minutos a vários dias) que aguarde eventos intermediários e tome decisões baseado no estado atual do processo e mais os dados do evento recebido, deve-se utilizar BPEL/BPM. Caso a execução leve apenas alguns segundos e todas as decisões ocorram apenas com base nos dados recebidos no momento da chamada, pode-se utilizar OSB. Para saber mais sobre stateless/stateful, veja esse artigo.
  • O projeto prevê a existência de tarefas humanas? Opte por BPM. O BPEL também é uma alternativa (já que a infraestrutura do SOA Suite é a mesma para ambos). OSB não possui esse recurso.
  • Entre BPM e BPEL, qual escolher? Ambos são ótimas soluções. No caso de não haver grande diferença entre um e outro, hoje em dia sugere-se utilizar o BPM pela simplicidade no aprendizado e na pouca quantidade de código envolvido. O BPEL ainda necessita um conhecimento mais aprofundado de XML e seus correlatos. Outro ponto é que BPM usa BPMN como notação para representar o fluxo do processo, que é muito mais facil de ser compreendida pelo negócio tanto no desenho do processo a ser automatizado quanto no acompanhamento da execução das instâncias.
Certamente muitos outros aspectos devem ser considerados nessa tomada de decisão, incluindo o tempo de processamento do serviço, se ele será síncrono ou assíncrono, etc. Mas os pontos acima podem ser úteis para, ao menos, eliminar uma ou outra opção.
(Com a contribuição de Leonardo Fagundes, Kelly Sganderla e Rafael Andrade).

Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários

-
(25) Comentários

No artigo anterior iniciamos o estudo dos eventos, detalhando os principais tipos de gatilhos para eventos de início e fim de processo.

O evento intermediário (Intermediate event) sinaliza um ponto no decorrer do processo no qual é previsto que um fato irá ocorrer.

Eventos intermediários podem ser tanto do tipo catch (aguardam a ocorrência do fato para que o processo continue) quando do tipo throw (geram a ocorrência do fato e dão continuidade ao processo).

Em geral os eventos intermediários são conectados ao processo através de conectores de fluxo de sequência, dando o contexto de que ocorrem durante o processo. Entretanto, um evento intermediário também pode ser definido para ocorrer durante uma tarefa tarefa específica. Neste caso, o evento intermediário é anexado à borda da atividade, como mostrado em alguns exemplos abaixo.

Os tipos de evento intermediário mais comuns são:

Tempo ou Prazo (Timer)
Utilizado para representar um fato relacionado a uma condição temporal, como uma data específica (ex. 01 de janeiro), uma data relativa (próxima terça-feira), um intervalo de tempo (em sete dias) ou uma situação de espera de tempo.

O evento de timer é simbolizado por um relógio.

Quando utilizado no fluxo do processo, o evento intermediário de timer representa que o processo deverá parar naquele ponto do processo e aguardar que a condição de tempo se torne verdadeira.

Neste exemplo, quando a tarefa “Preparar viagem” for finalizada, o processo realizará uma pausa aguardando a data de início da viagem. Só então o processo continuará, iniciando a tarefa “Realizar viagem”.

Quando utilizado na borda de uma atividade, o evento intermediário de timer representa que que, enquanto a atividade estiver em execução, o evento poderá acontecer, e neste caso, o fluxo desenhado a partir do evento será executado. Neste caso, o evento intermediário poderá ser de dois tipos:

Timer interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, ela será interrompida, e o fluxo seguirá pelo conector que se origina no evento.
A borda do evento é dupla e lisa.
No exemplo ao lado, se a atividade “Confirmar recebimento de mercadorias” for concluída  antes da data de entrega prevista, o processo seguirá sua execução pelo fluxo normal do processo. Entretanto, se a data de entrega prevista for atingida e o recebimento das mercadorias não tiver sido confirmado, a tarefa é automaticamente cancelada e o fluxo que sai do evento de timer é disparado, dando início à atividade “Cancelar o pedido”. A atividade de “Confirmar recebimento de mercadorias” não poderá mais ser realizada pois foi interrompida.

 

Timer non-interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, um fluxo paralelo será iniciado a partir do conector que se origina no evento, mas a tarefa permanece aguardando a sua execução.
A borda do evento é dupla e tracejada.
No exemplo ao lado, se o após dois dias úteis a tarefa “Avaliar pedido” ainda não tiver sido finalizada, o fluxo iniciado no evento é disparado, iniciando a tarefa “Receber aviso de atraso na avaliação”. A atividade de avaliar pedido, entretanto, poderá ser realizada normalmente, dando sequência ao fluxo normal do processo. Se a tarefa “Avaliar pedido” for finalizada antes da ocorrência dos dois dias úteis, então a atividade “Receber aviso de atraso na avaliação” não acontecerá.

 

Condicional (Conditional)
Utilizado para representar um fato relacionado a uma condição de negócio, pausando o processo até que ela se torne verdadeira.

No exemplo ao lado, ações são compradas e então o processo aguarda até que a condição “Valor de venda atingido” se torne verdadeira, dando continuidade ao processo e iniciando a tarefa “Vender ações”.

O evento do tipo conditional também pode ser conectado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será acionado quando a condição de negócio associada se torne verdadeira.

 

Mensagem (Message)
Eventos intermediários de tipo message são utilizados para demonstrar um ponto do processo onde ocorre uma comunicação com um outro processo ou agente externo.

O evento de “throw message” tem como símbolo um envelope preto e sinaliza o envio da comunicação, enquanto o evento do tipo “catch message” tem como símbolo um envelope branco e sinaliza o recebimento da mesma.

No exemplo acima, o Processo de Logística de Treinamentos prevê uma atividade para “Alugar sala de treinamento”. Após alugar a sala, o processo aguarda uma “Comunicação do número de Participantes”. Quando esta comunicação for recebida, a próxima atividade poderá ser iniciada, providenciando cadeiras e mesas para os participantes do treinamento cujas inscrições foram confirmadas.

Este exemplo apresenta o Processo de Inscrições de Treinamento, no qual há uma tarefa para receber as fichas de inscrição e então uma atividade para “Verificar inscrições pagas”. Quando as inscrições pagas forem verificadas, o processo poderá comunicar o número de participantes que estão inscritos, enviando uma mensagem (que será recebida no processo demonstrado anteriormente, no evento com o mesmo nome). Após, o processo segue, iniciando a tarefa de “Providenciar impressão dos certificados”.

A identificação de que a mensagem enviada por um processo é a mesma recebida em outro processo deve ser explicitada utilizando-se a mesma descrição para o elemento.

É possível ainda demonstrar visualmente esta comunicação, colocando-se os dois processos em um mesmo diagrama BPMN e apresentando como esta mensagem flui de um processo para o outro. Neste caso, utiliza-se um conector especial para demonstrar essa ligação entre processos através da troca de mensagens (envio e recebimento): o conector de fluxo de mensagem (message flow).

O conector de fluxo de mensagem pode ser usado apenas para conectar elementos de envio e recebimento de mensagem, e caracteriza-se por uma linha tracejada com uma seta vazada apontando para o destino da mensagem.

É importante ressaltar que para o BPMN, uma comunicação é realizada sempre para fora do processo, nunca entre eventos de mensagem de um mesmo processo.

O evento do tipo mensagem também pode ser utilizado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será sempre “catch”, aguardando a chegada de uma mensagem, e será acionado se a mensagem for recebida enquanto a atividade estiver sendo executada.

Ligação (Link)
Eventos intermediários de link representam uma ligação entre pontos distantes de um mesmo do processo.

Este elemento é utilizado frequentemente em processos cujo número de atividades é muito grande e há pontos do processo que estão visualmente distantes ou bloqueados. Assim, para evitar a sobreposição de conectores de fluxo de sequência, pode-se utilizar este evento, criando uma “ponte virtual” entre pontas do fluxo do processo.

O evento de “throw” link tem como símbolo uma seta preta e sinaliza a ponta de origem da ligação, enquando o evento do tipo “catch” tem como símbolo uma seta branca e sinaliza o destino da mesma.

O exemplo acima apresenta um exemplo de uso de eventos de ligação (link). Observe que há dois eventos de ligação com o mesmo nome: “Continuar negociação”. O primeiro tem a seta preta, indicando a origem da ligação, e o segundo a seta branca, indicando o destino da ligação. Com isso, a leitura que se faz deste diagrama é de que após a realização da atividade “Verificar condições de férias” o processo dá sequência ao fluxo iniciando a tarefa “Avaliar solicitação de férias”.

Para entender melhor o uso de eventos de mensagem e link, leia também estes artigos:

No próximo artigo, um elemento fundamental para a abstação de conjuntos de tarefas na estruturação de diagramas de processos com níveis de profundidade e granularidade diferentes: os subprocessos.

Confira todos os artigos deste guia de BPMN Nível 1:

Caso de Sucesso – Aumento da produtividade e efetividade nos negócios do SICREDI com a adoção de SOA e BPM

-
(2) Comentários

Marcio Lermen, gerente de tecnologia do Sicredi

Durante o Oracle Open World 2012 em São Paulo, Marcio Lermen, gerente de tecnologia do Sicredi, apresentou como caso de sucesso a adoção da suíte de SOA e BPM da Oracle para a automação dos processos da organização e o uso do Oracle Exalogic como plataforma de hardware e software para dar alta performance a esta suíte.

De acordo com Marcio, a escolha destas tecnologias foi feita dado o desafio que o Sicredi tinha quanto a decisões e processos manuais em um cenário de negócio complexo, em que os processos estão distribuídos entre as cooperativas do sistema. A adoção destas tecnologias viabilizou o redesenho e automação dos processos, apresentando excelentes ganhos no controle da execução dos processos.

Dentre os benefícios obtidos com esta adoção, foi mencionado o ganho de tempo na execução de um processo. Em alguns casos, a automação de um processo (que antes era ad-hoc e feito via envio de e-mails e trocas de telefonemas) fez com que o ciclo de vida do mesmo, que costumava levar vários dias, pudesse ser realizado no mesmo dia. Além disto, foi mencionado o ganho de desempenho com o uso do Oracle Exalogic, que chegou na ordem de 4 a 6 vezes. Segundo Márcio, para conseguir esta performance foi preciso que todos os serviços envolvidos estivessem dentro do Exalogic.

Como pontos importantes apresentados por ele, foram citados os seguintes fatores:

  • o mapeamento e desenho do processo as-is e to-be antes da automação do mesmo;
  • a definição dos pontos onde serão gerados indicadores (que serão enviados ao BAM na execução) durante a definição do processo;
  • a quebra do processo principal em subprocessos menores, inclusive para facilitar o controle de versão e o desenvolvimento;
  • governança SOA, contendo uma arquitetura bem definida, além da necessidade de uma garantia de que a mesma será utilizada dentro dos projetos.

Foram mostrados alguns exemplos de processos criados utilizando Oracle BPM, sendo que muitos deles foram mapeados e criados em parceria com a iProcess.

É um orgulho para nós poder fazer parte de cases de sucesso em BPM do sicredi.

Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim

-
(25) Comentários

Este é o terceiro artigo de uma série dedicada ao estudo da notação BPMN básica, ou nível descritivo. No artigo anterior, descrevemos um importante elemento na representação de processos nesta notação, os gateways.

Este artigo é dedicado ao esclarecimento de outro importante componente de fluxo em BPMN: os eventos.

Eventos (Events) são elementos utilizados para representar a ocorrência de fatos em um processo.

Eventos podem representar a espera de que um fato aconteça para iniciar/prosseguir a execução o processo ou então sinalizar que o processo produzirá a ocorrência de um fato durante ou ao término de sua execução.

Os eventos são sinalizados no processo através de um círculo, e dependendo do ponto do processo onde ocorrem podem ser sinalizados de forma diferente:

  • Eventos de início (Start events) marcam o ponto onde o processo inicia e são representados por um círculo de linha simples.
  • Eventos intermediários (Intermediate events) marcam ocorrência de eventos no decorrer do processo e são representados por um círculo de linha dupla.
  • Eventos de fim (End events) marcam o ponto onde o processo termina e são representados por um círculo de linha grossa.

Eventos que aguardam fatos e possuem uma causa são chamados “catch”.

Eventos que produzem fatos e possuem um resultado são chamados “throw”.

A causa ou resultado do evento é chamado “trigger” (gatilho) e sinalizado através de um símbolo dentro do elemento. Os tipos de gatilho variam de acordo com cada tipo de evento.

 

Evento de início (Start Event)

O evento de início marca o ponto onde deve-se iniciar a leitura ou a execução de um processo.

O evento de início será sempre do tipo catch, pois deve aguardar a ocorrência de um evento para realizar o disparo (início da execução) do processo.

É recomendável que todo o processo tenha um evento de início para facilitar a leitura do diagrama, possibilitando a quem lê identificar por onde começa o fluxo de atividades.

Os tipos de evento de início mais comuns são:

None
O processo é iniciado sem a definição de um fato específico que gere o seu início.
Não possui símbolo.

 

Timer
O processo é iniciado pela ocorrência de um fato temporal, como a chegada de uma data específica (ex. 01 de janeiro) ou relativa (ex. primeira terça-feira do mês).
É simbolizado por um relógio.

 

Message
O processo é iniciado com a chegada de uma comunicação de qualquer tipo (um documento, uma mensagem, um telefonema, etc).
É simbolizado por um envelope branco (catch).

 

Conditional
O processo é iniciado quando uma determinada condição torna-se verdadeira. É simbolizado por um desenho de página com linhas representando as condições.

 

Evento de fim (End event)

O evento de fim marca o término onde deve-se iniciar a execução de um processo.

O evento de fim será sempre do tipo throw, marcando que o processo termina com a geração de um fato.

É recomendável que todo o processo tenha ao menos um evento de fim. É possível entretanto simbolizar términos diferentes para o processo usando mais de um evento de fim.

Os tipos de evento de fim mais comuns são:

None
O processo termina sem gerar nenhum fato específico.
Não possui símbolo.

 

Message
O processo é finalizado com o envio de uma comunicação de qualquer tipo (um documento, uma mensagem, um telefonema, etc). É usado para iniciar um outro processo ou fornecer um resultado a uma comunicação começada no início ou decorrer do processo.
É simbolizado por um envelope preto (throw).

 

Terminate
O processo é terminado finalizando por completo, mesmo que existam atividades em fluxos paralelos em execução. Caso existam atividades em execução quando um dos fluxos existentes atinja o evento de fim terminate, as tarefas pendentes são canceladas e o processo é dado como completamente finalizado.
É simbolizado por um círculo preto preenchido.

 

No exemplo acima, o evento de fim “Processo arquivado” é do tipo terminate. Se a tarefa “Arquivar processo” for concluída antes das atividades do fluxo paralelo, o processo chegará ao evento terminate e as tarefas que ainda estavam em execução serão interrompidas. Mas se a tarefa “Anexar documentos pendentes” terminar antes de “Arquivar processo”, o processo finalizará com todas as atividades executadas, pois diferente do evento terminate o evento do tipo none não interrompe a execução de atividades no fluxo paralelo.

Embora o uso de eventos de início e fim não sejam obrigatórios, são considerados uma boa prática, fundamental para a obtenção de um processo bem mapeado, claro e legível a todos os participantes do processo.

Há porém uma regra na especificação que deve ser observada: se for utilizado um evento de início no processo, deve  obrigatoriamente haver ao menos um evento de fim. Da mesma forma, se for adicionado ao mapeamento do processo um evento de fim, então o processo deve obrigatoriamente possuir ao menos um evento de início.

Existem outros gatilhos para eventos de início e de fim do processo. Estes apresentados, porém, são os mais comumente utilizados e que compõem o nível de componentes do nível descritivo da notação BPMN.

No próximo artigo:
o tema Eventos continua! Estudaremos os principais usos e tipos de eventos intermediários, usados para prever ocorrência de eventos no decorrer da execução dos processos.

Confira todos os artigos deste guia de BPMN Nível 1: