Uso do MDS (MetaData Service) no Oracle SOA Suite

O Oracle SOA Suite, solução da Oracle para integração de sistemas e automação de processos, na sua versão 11g, trouxe muitas novidades, se compararmos com a versão 10g. Uma delas foi o MDS, ou o MetaData Service. Nesse post vamos falar sobre ele, procurando esclarecer para que serve e como utilizá-lo.

Definição
O MDS é um repositório unificado para armazenamento de arquivos (metadados) usados nos projetos do SOA Suite. Quando, por exemplo, um projeto BPEL ou BPM é implementado (deploy) os seus arquivos são armazenados no MDS.

Além disso, é possível utilizar o MDS para outros fins, como, por exemplo, compartilhar artefatos comuns entre os vários projetos, sejam eles schemas XML (XSD), arquivos EDL, DVM ou WSDL.

Porque usar o MDS para artefatos comuns?
O MDS provê maior segurança e melhor manutenção dos artefatos comuns aos projetos do SOA Suite. Existe total compatibilidade com o JDeveloper (IDE de desenvolvimento) para visualizar o conteúdo do repositório e total compatilidade do EM para a sua manutenção.

Um exemplo de situação que justifica o uso do MDS é quando um arquivo XSD é compartilhado por vários projetos, o que ocorre com certa freqüência quando utilizamos modelos canônicos. Ter uma cópia desse arquivo em cada projeto pode gerar um problema de manutenção (pensemos que, cada nova versão do arquivo deveria ser replicada 10, 20 vezes, dependendo da quantidade de projetos envolvidos na integração). Se utilizamos o MDS, os projetos envolvidos farão uma referência para ele no repositório e, sempre que o arquivo XSD for atualizado, automaticamente todos os projetos também estarão atualizados.

Como utilizar o MDS
Existem duas versões do MDS: uma armazenada em forma de arquivos e outra registrada no banco de dados (servidor). A primeira é usada para o desenvolvimento e pode ser salva, por exemplo, num repositório subversion (GIT, SVN, CVS, TFS, etc), de forma que todos os desenvolvedores tenham acesso ao conteúdo.

A versão do banco de dados, por sua vez, será aquela utilizada pelo servidor SOA Suite, que estará rodando sobre um server Weblogic. Assim será necessário implementar (deploy) o conteúdo dos arquivos no banco de dados para que o servidor tenha acesso ao conteúdo atualizado pelos desenvolvedores.

Cada projeto utiliza um padrão próprio para implantação (deploy) dos projetos no servidor SOA Suite. Esse artigo explica como criar a árvore de arquivos e como atualizar o MDS da maneira nativa, ou seja, via JDeveloper.

Uma vez que o MDS esteja configurado e com o conteúdo armazenado, a referenciação dentro do projeto é bastante simples, bastando informar, na localização, o caminho completo dentro do MDS e incluindo o prefixo oramds. Veja no exemplo:

  • Para referenciar o XSD que está no caminho apps/MyCannonical: oramds:/apps/MyCannonical.xsd
  • Para referenciar um WSDL:

 

Utilizar o MDS em projetos SOA Suite é uma opção de arquitetura que pode simplificar muito o desenvolvimento. Porém, é necessário que exista um forte controle das atualizações dos arquivos locais e do banco de dados. Trabalhar com multi-desenvolvedores também pode causar algum tipo de transtorno caso isso não ocorra.

Podem haver problemas, também, no uso compartilhado do conteúdo do repositório. Indispensável dizer que deve haver uma preocupação muito grande quando esses artefatos forem atualizados, evitando incompatibilidade com outros projetos.

BPMN: Modelando processos de negócio com elementos avançados (Parte III)

Prosseguindo com nosso estudo de elementos avançados, neste terceiro artigo da série abordaremos um dos elementos mais utilizados no fluxo de um processo de negócio: os Gateways.

Gateways

Gateways são os elementos de BPMN responsáveis por controlar iterações do fluxo, criando caminhos alternativos ou paralelos no mapeamento do processo ou unificando fluxos para continuação em uma mesma sequência de atividades.

No artigo Um guia para iniciar estudos em BPMN (II): Gateways, vimos também que o gateway é conectado ao fluxo através de setas de fluxo de sequência e é representado visualmente por um losango. O símbolo interno do losango identifica a interpretação lógica representada. Para um estudo completo sobre os gateways indicamos a leitura deste artigo.

Com foco em elementos avançados falaremos sobre dois dos cinco diferentes gateways.

Exclusive Event-Based Gateway

O desvio condicionado por evento é semelhante ao Gateway exclusivo (Databased Exclusive Gateway): indica pontos do processo em que o gateway exclusivo não se baseia em dados de processo, mas sim sobre as mensagens ou eventos externos. Esta forma é usada para exercer controle sobre a execução de determinadas atividades que ficam disponíveis até que um dos eventos sejam executados.

Gateway exclusivo condicionado por eventos – decisão depende do resultado dos eventos imediatamente posteriores a ele.

No gateway condicionado por um evento específico, normalmente o recebimento de uma mensagem determina o caminho que será tomado. Basicamente a decisão é tomada por um outro participante, com base em dados que não são visíveis ao processo e, assim, exigindo o uso do gateway baseada em eventos.

Podemos imaginar: quando nosso processo chegou ao evento baseado em gateway, vamos esperar até que algo aconteça. O evento geralmente é disparado por terceiros (por exemplo, o nosso cliente envia o pagamento para nós). Abaixo é a porta baseada em eventos típicos. Enviamos uma cotação para o cliente, aguardando o cliente confirmar o pedido. Se o cliente envia a confirmação, vamos preparar as mercadorias para o cliente. Se não receber qualquer confirmação do cliente após 15 dias, o pedido é cancelado. Veja o processo abaixo.

Gateway exclusivo condicionado por eventos – O primeiro evento disparado cancela os demais eventos. No exemplo acima, ou o processo recebe a confirmação do pagamento e envia o pedido, ou o processo é cancelado pelo pelo cliente por não ter confirmado em até 15 dias.

Complex

Gateway complexo é usado para modelar o comportamento de sincronização complexa. É sempre indicado que antes de utilizar o gateway complexo, tente usar a combinação de tipos diferentes de gateways.

Gateway Complexo – Criado para dar maior flexibilidade ao BPMN.

Uma Activation Condition Expression (Expressão de ativação de condição) é usada para descrever o comportamento preciso do gateway complexo.

Por exemplo, essa expressão poderia especificar que os tokens em três dos cinco fluxos de sequência de entrada são necessários para ativar o gateway do processo abaixo.

Gateway Complexo – Quando a combinação do fluxo não pode ser utilizada por nenhum outro gateway utiliza-se o gateway complexo.

Obrigado a todos e até nosso próximo artigo!


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

BPMN: Modelando processos de negócio com elementos avançados (Parte II)

Este é o segundo artigo de uma série dedicada ao estudo de elementos avançados de BPMN.

No artigo anterior iniciamos o estudo dos marcadores de atividades, vimos que cada marcador tem uma função específica que determina o comportamento de uma atividade durante sua execução. Neste artigo daremos andamento a este estudo finalizando a explicação ao que diz respeito a estes atributos.

Atividades de Múltiplas Instâncias (Multi-Instace Activity)

Representado por um marcador de 3 barras paralelas verticais presente na parte inferior central da atividade, dispara múltiplas instâncias da mesma atividade.

O marcador de múltiplas instâncias pode ser aplicado a uma tarefa como em um subprocesso.

O atributo de múltiplas instâncias permite que uma atividade tenha “N” repetições, podendo ser instanciada em paralelo diversas vezes.

Neste exemplo, o processo demostra o fluxo do processo de “Cadastro de Orçamentos”, no qual há uma tarefa para cadastrar orçamento. Esta tarefa permite que um ou mais orçamentos sejam cadastrados ao mesmo tempo. Quando a tarefa de cadastro dos orçamentos finalizar, o processo enviará estes cadastros para a tarefa que avaliará os orçamentos para escolher o vencedor.

Subprocesso ad-hoc

Um subprocesso ad-hoc indica um conjunto de atividades desempenhadas sem uma sequência pré-definida pois suas tarefas (tasks) não são conectadas pelo fluxo de sequência (sequence flow).

Subprocesso ad-hoc

É importante ressaltar que não existe uma obrigatoriedade na execução de todas as tarefas de um processo ad-hoc.

Estas atividades estão relacionadas, geralmente, a atividades humanas onde a quantidade de vezes e a ordem são definidas pelo executor.

O exemplo acima trata de um subprocesso ad-hoc. Como o subprocesso não possui um fluxo de sequência, suas atividades podem ser executadas sem sequência ou obrigatoriedade.

Tarefa de Compensação (Compensation)

A tarefa de compensação é uma tarefa particular e não faz parte do fluxo normal de um processo. Em alguns momentos na modelagem de processos de negócios, precisamos “desfazer” uma atividade ou processo e em alguns casos, quando desfeito, precisamos gravar esta operação, o que requer uma etapa exclusiva representada por uma tarefa de compensação (compensation).
Este “desfazer” o processo poderia ser representado por um subprocesso, gerando um fluxo muitas vezes complexo. A tarefa de compensação resolve este problema com apenas uma tarefa.

A tarefa de compensação é representada como uma tarefa normal, mas com um pequeno símbolo que se parece com o botão de rebobinamento num leitor de áudio (dois pequenos triângulos apontando para a esquerda).

A tarefa de compensação é utilizada exclusivamente para executar a compensação de uma atividade já realizada no processo.

Sua conexão é realizada através da associação de compensação (compensation association) e ligado ao evento anexado a atividade já realizada. Este evento é conhecido como catch compensation.

No exemplo acima, por uma determinada condição do processo, a atividade “Reservar van”, já realizada, deverá ser compensada, levando ao seu cancelamento.

Subprocesso de Transação (Transiction)

Transação é um tipo de subprocesso que contém um conjunto de atividades, logicamente relacionadas, e pode seguir um protocolo transacional específico. Ele faz com que todas as suas atividades sejam completadas com sucesso ou canceladas (compensadas).

O subprocesso de transação é representado por um retângulo de bordas arredondadas e linha dupla e pode ser representado tanto na forma contraída (collapsed) como na forma expandida (expanded).
A fronteira da atividade será uma linha dupla que indicará que trata-se de uma transação.

Subprocesso de Transação (Transiction)

Para que o subprocesso de transação seja finalizado com sucesso todas as suas atividades devem ser completadas. Veja o exemplo abaixo que demostra a representação do subprocesso de transação.

O exemplo acima demostra que é necessário que a reserva da van e do passeio no parque sejam concluídos para que o processo de reservas seja concluído com sucesso, levando a atividade de faturar comprador. Caso a reserva da van seja concluída e do passeio não, a reserva da van é cancelada (e vice-versa). No caso de cancelamento, um evento intermediário de cancelamento (cancel), mostrará o caminho que o fluxo irá seguir (fracasso), levando a execução da atividade “Avisar da indisponibilidade”. Erro (error): quando isto ocorrer significa que nenhuma conclusão bem sucedida como também nenhuma conclusão fracassada ocorreu. Neste caso usa-se a exceção para mostrar o perigo. Quando um perigo é detectado, a atividade é interrompida (sem compensação) e o fluxo prossegue pelo evento intermediário de exceção (erro).

Obrigado a todos e até nosso próximo artigo!


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

BPMN: Modelando processos de negócio com elementos avançados (Parte I)

A notação BPMN (Business Process Model and Notation), atualmente na versão 2.0, reúne um conjunto de elementos intuitivos e robustos, que auxiliam usuários técnicos e de negócio na documentação de seus processos em diferentes níveis de detalhes, de maneira que possam mapear, de maneira padrão, todos os processos de negócios de sua organização.

A lista de elementos gráficos de BPMN apresenta desde elementos essenciais para a modelagem dos processos, utilizados em uma documentação simples, até elementos avançados, requeridos para desenhar modelos de processos complexos.

Dedicaremos os artigos semanais de janeiro para contribuir com o estudo dos elementos avançados, requeridos para a compreensão de uma modelagem complexa.

Marcadores de Atividades

Abordaremos neste primeiro artigo os marcadores de atividades, conhecidos também como atributos especiais.

Os marcadores de atividades ou atributos especiais tem o objetivo de indicar o comportamento específico de uma atividade durante sua execução.

Marcadores de Atividades

Marcadores de Atividades

No artigo “Um guia para iniciar estudos em BPMN”, vimos que atividades (activities) representam um trabalho realizado em uma etapa do processo de negócio e podem ser do tipo “Tarefa” (task) ou “Subprocesso” (subprocess).

Subprocesso

Um subprocesso representa um conjunto de atividades realizadas dentro de um processo de negócio. São representados graficamente de duas formas, contraído ou expandido.

A Imagem acima demostra o subprocesso contraído (collapsed), representado pelo símbolo “+” indicando a existência de outro nível de detalhe, que pode ser expandido (expanded).

Subprocesso contraído

subprocesso contraído

Subprocesso contraído (Busca de informações): No exemplo acima o processo inicia-se com a execução da tarefa de solicitação de reembolso, após sua execução o fluxo segue dando início ao subprocesso que buscará as informações das despesas. Após a análise destas informações, o subprocesso é finalizado voltando ao fluxo do processo principal da solicitação de reembolso e partindo para a tarefa da aprovação do gestor.

Subprocesso Expandido

O mesmo subprocesso pode ser representado de forma expandida (expanded), apresentando o seu conjunto de detalhes no próprio processo “pai”.

Subprocesso Expandido

Exemplo de subprocesso expandido: O mesmo fluxo do subprocesso contraído é executado, porém o subprocesso de busca de informações apresenta o detalhamento de suas atividades visíveis no processo “pai”.

Atenção: O fluxo do processo “pai” não pode atravessar de forma alguma a fronteira do subprocesso.

subprocesso Expandido fronteira atravessada

Uma regra importante no BPMN é que um subprocesso nunca pode ter sua fronteira cruzada pelo fluxo de sequência. O fluxo de sequência apresenta a ordem de execuções das atividades em um processo e nunca entre processos. Os fluxos de sequência de entrada e saída devem ser ligados no limite do subprocesso (sua borda), e não deve iniciar e terminar os eventos no nível de expansão dentro do retângulo arredondado (subprocesso expandido), conforme mostra a figura acima.

Loop – Atividade cíclica

Representado por uma linha circular com seta (conforme imagem abaixo), atributo em atividades que simula a operação “do-while”, uma atividade pode ser executada várias vezes em ciclo.

Utilizada quando o número de repetições não é conhecido;
A atividade de repetição será repetida enquanto a condição do loop for atendida.

Loop

Loop – Atividade cíclica

Uma atividade de loop terá uma expressão booleana que é avaliada para cada ciclo. Se a expressão for verdadeira, então irá continuar. O loop irá avaliar a expressão após a realização da atividade, isto significa que atividade será realizada pelo menos uma vez.

Loop subprocesso

No exemplo acima, o subprocesso “Seleção de Candidato” avalia candidatos a serem selecionados para entrevista. A expressão booleana para este loop poderia ser “O candidato não passou na seleção?” se a resposta for “verdadeira” então a atividade será realizada novamente e se for “falsa” o processo seguirá seu fluxo.

Em nosso próximo artigo:
Continuaremos o estudo sobre os Marcadores de Atividades, iniciado neste primeiro artigo.


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

Um guia para iniciar estudos em BPMN (VI): Swimlanes e Artefatos

Este é o último artigo de uma série de seis postagens sobre a utilização dos elementos básicos da notação BPMN.

Neste artigo, tratamos alguns elementos utilizados a nível de organização do diagrama do processo: swimlanes para atribuir visualmente responsabilidades sobre as atividades, e artefatos para agregar informações adicionais que possam contribuir com a compreensão da lógica do processo de negócio.

Swimlanes

Swimlanes são os elementos de BPMN utilizados para organizar os processos de um diagrama, definindo o escopo de cada processo e possibilitando identificar os papéis responsáveis pela execução de cada atividade do processo.

Estes elementos são definidos em uma estrutura semelhante a uma piscina (pool) e suas raias (lanes).

Uma pool pode conter apenas um processo de negócio. Processos de negócio distintos devem estar contidos, cada um, em uma pool específica.

Uma pool pode conter tantas lanes quantas forem necessárias para caracterizar os participantes envolvidos na realização das atividades do processo.

A prática comum é desenhar as pools e suas lanes horizontalmente, mas a notação permite a representação vertical.

No exemplo acima, a pool contém todo o processo para conceder crédito. O nome do processo está na borda da pool, que é o retângulo inteiro contendo todo o “Processo de Concessão de Crédito”. Este processo contém atividades que envolvem dois papéis: o Gerente da Conta e o Gerente do Produto. Cada é representado no processo através de uma lane da pool. O diagrama de processos utilizando pools e lanes facilita a identificação visual da troca de mãos da responsabilidade de agir em cada etapa do processo.

As pools são nomeadas com a identificação do Processo (quando o processo modelado está em nível de detalhe operacional) ou com a identificação do Participante (por exemplo, uma entidade externa que se envolve de alguma forma com o processo de negócio modelado em outra pool).

No exemplo acima temos o exemplo de dois processos que se comunicam através de message flow. Observe que cada processo está contido em uma pool. Uma pool pode conter apenas um processo de negócio. Processos de negócio distintos devem estar contidos, cada um, em uma pool específica. A interação entre processos se dá por comunicação, utilizando-se o conector de message flow.

Em alguns casos, pools podem não detalhar o seu conteúdo, mas figurar em um diagrama apenas como um apontamento visual de que aquele processo existe no contexto de negócio no qual um processo comunica-se com outros processos ou entidades. Nestes casos, chamamos as pools não detalhadas de collapsed ou black box (caixa preta).

No exemplo acima, o mesmo processo agora é apresentado em um diagrama que demonstra a comunicação do Processo de Concessão de Crédito com os participantes externos Cliente e SERASA. Estes participantes também possuem seus processos, porém o detalhamento das atividades realizadas em cada um é transparente para o Processo de Concessão de Crédito. Por este motivo, estes participantes são representados no processo como pools black box. Observe que a comunicação entre os processos (ou do processo modelado com os outros processos/participantes) é sempre representada através do conector de message flow.

Artefatos (Artifacts)

Além dos elementos de fluxo (atividades, gateways e eventos), dos elementos conectores (fluxo de sequência e fluxo de mensagem) e dos elementos organizacionais (swimlanes), BPMN oferece elementos adicionais para sinalização visual do processo mas que não influenciam no fluxo do processo. São elementos de anotações, que podem ser utilizados para adicionar informações complementares ao processo.

O objeto de dados (data object) é um elemento que representa um conjunto de informações no contexto do processo, de uma atividade ou de uma troca de mãos (através do fluxo de sequência). É representado por uma página com a ponta dobrada.
No exemplo, “Lista de alunos” é um objeto de dados que transita da tarefa “Verificar inscrições pagas” para “Providenciar impressão dos certificados”.

O artefato de anotação de texto (annotation) é um elemento que pode ser utilizado para agregar comentários ao processo ou a um elemento. É representado por uma área de texto marcada com a borda lateral, e pode ou não estar conectado a elementos do diagrama.
No exemplo, há uma anotação na tarefa “Preparar cadeiras e mesas” que complementa o entendimento da tarefa.

O artefato de grupo (group) é um elemento de anotação visual que pode ser utilizado para sinalizar grupos de atividades dando-lhes algum destaque. O grupo é uma simples anotação e não influencia no fluxo do processo, podendo inclusive ser desenhado cruzando lanes e pools. É representado por um retângulo com bordas arredondadas e linha tracejada.
No exemplo, há um grupo denominado “Controle das Inscrições” destacando um grupo de elementos relacionados a este controle. Procure abstrair a existência do grupo e note que o fluxo do processo não se altera se este elemento for ou não utilizado.

O conector de associação (association) é um conector específico para conectar os elementos de artefatos ao diagrama, e é representado por uma linha pontilhada, podendo ou não apresentar setas em “v” (ele é distinto do message flow, que tem a linha tracejada e ponta de triângulo).
No exemplo, os artefatos de objeto de dados e anotação estão ligados ao fluxo do processo através de conectores de associação.
Com este artigo, finalizamos nosso guia para iniciar estudos em BPMN.


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