Oracle BAM – Atualizando a definição de dataObjects

Em um artigo anterior (http://blog.iprocess.com.br/2012/04/exportacao-e-importacao-de-objetos-do-oracle-bam/) vimos como utilizar o comando icommand para  importar/exportar objetos do Oracle BAM, dentre eles um data object, que é a estrutura onde os dados exibidos no Oracle BAM são armazenados.

Neste tópico, veremos como atualizar a definição dos data objects do Oracle BAM de uma forma um pouco mais poderosa que utilizando o icommand, por meio dos webservices do Oracle BAM.

Problema:

Uma das limitações do icommand é que ele não permite “atualizar” um data object. Por exemplo, via icommand, não é possível incluir uma nova coluna. É preciso excluir o data object e criá-lo novamente, o que acarreta a perda de referências e também a perda de dados.

Solução:

Utilize o webservice DataObjectDefinition (http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/bam_webservices.htm) para enviar a nova estrutura do data object, sem perder os dados existentes.

O modo de funcionamento é simples: você envia a nova estrutura do data object no payload. As colunas que existirem com o mesmo nome serão atualizadas, as que não existirem serão criadas e as que existirem mas não estiverem na nova definição, serão excluídas.

Exemplo de payload:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bam="http://xmlns.oracle.com/bam" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Header/>
   <soap:Body>
      <bam:Update>
         <bam:xmlPayload>
            <![CDATA[
            <DataObject Version="14" Name="Distribuicao" ID="_Distribuicao1" Path="/Logistica" External="0">
               <Layout>
                  <Column Name="Local" ID="_Local" Type="string" MaxSize="100" Nullable="1" Public="1" TipText="&quot;CQ&quot; / &quot;Buffer&quot; / &quot;Direto&quot;"/>
                  <Column Name="Quantidade" ID="_Quantidade" Type="integer" Nullable="1" Public="1"/>
                  <Column Name="Data_Expiracao" ID="_Data_Expiracao" Type="datetime" Nullable="1" Public="1" TipText="Data de expiração dos dados no BAM"/>
               </Layout>
            </DataObject>
            ]]>
         </bam:xmlPayload>
      </bam:Update>
   </soap:Body>
</soap:Envelope>

Note que o formato do payload é o mesmo que o utilizado no XML exportado ou importado via icommand, o que facilita o trabalho.

A atualização terá ocorrido com sucesso se o retorno do webservice for o elemento “UpdateResponse” vazio.

BPMN: Modelando corretamente o fluxo de sequência de atividades

Em seis anos de estudo da notação, quatro destes realizando treinamentos na área, uma situação recorrente que percebo na compreensão da notação BPMN está em uma confusão relacionada ao fluxo de sequência de atividades de um processo e o fluxo de mensagens da comunicação do processo com agentes externos.

O fluxo de atividades é desenhado pela sequência das atividades de um processo de negócio. Ele é representado através do conector sequence flow. Este objeto de conexão liga dois elementos de fluxo de processo (eventos, gateways ou atividades). O objeto na origem do conector é a atividade predecessora, e o objeto de destino do conector (para onde a seta aponta) é a atividade sucessora.
Este conector implica no entendimento que a atividade sucessora ocorrerá após a atividade predecessora ser concluída.

BPMN - fluxo de sequencia de atividades (foco) - material de treinamento da iProcess - direitos reservados

Existe uma sequência entre as atividades "Solicitar Cotação de Passagem ou Hotel" e "Avaliar Cotações Recebidas", pois estas atividades estão conectadas por um sequence flow.

O fluxo de mensagens representa a comunicação entre dois processos, ou duas entidades representadas por pools diferentes (já que cada entidade tem o seu processo).  Ele não representa a sequência de ações realizadas pelo processo, mas simplesmente quem envia e quem recebe uma informação relevante naquele ponto do processo. O Fluxo de mensagens é representado através do conector message flow. Este objeto de conexão liga dois elementos do tipo eventos de mensagem ou atividades. O objeto na origem do conector é o remetente e o objeto de destino do conector (para onde a seta aponta) é o destinatário, ou receptor.
Este conector implica no entendimento de que esta comunicação acontece durante a execução da atividade de origem da comunicação.

BPMN - fluxo de mensagens (foco) - material de treinamento da iProcess - direitos reservados

Existe uma comunicação com o agente externo "Agência de Viagens" na atividade "Solicitar Cotação de Passagem ou Hotel" do Processo de Viagem, porque há uma conexão de message flow entre elas.

Você consegue perceber a distinção do que cada um destes fluxos representa?

O que muitas vezes percebo nos modelos que enviam para minha avaliação, é uma confusão na utilização do fluxo de mensagens para representar também a sequência de atividades, o que é incorreto na interpretação de um diagrama BPMN. O diagrama abaixo apresenta um exemplo deste equívoco comum:

BPMN - erro fluxo de sequencia - material de treinamento da iProcess - direitos reservados

O autor do diagrama tentou representar a sequência das atividades do processo através do fluxo de mensagens, o que é inválido para a notação BPMN.

Observe na imagem acima que não está sendo representado o fluxo de sequência de atividades entre as tarefas “Solicitar Cotação de Passagem ou Hotel” e “Avaliar Cotações Recebidas”. O autor tentou representar de forma implícita que a sequência das atividades seguirá ordem representada através do fluxo de mensagens nestas duas atividades. Este entendimento implícito não é válido para a modelagem de um processo aderente à especificação BPMN.

Por quê? Porquê nem sempre o fluxo de atividades de um processo segue o fluxo de mensagens. Além disso, a representação da troca de mensagens de um processo não precisa ser explícita (não é obrigatória) em um diagrama de processo, enquanto o fluxo das atividades é obrigatório sempre que houver dependência entre elas. Portanto, a modelagem correta para o caso apresentado acima é esta:

BPMN - solucao fluxo de sequencia - material de treinamento da iProcess - direitos reservados

Agora sim! A sequência das atividades no processo está sendo representada de forma íntegra. Se o fluxo das mensagens fosse removido (não fosse exibido), ainda assim o diagrama do processo estaria correto.

Os trechos de definições abaixo reforçam o entendimento semântico envolvido na utilização destes dois tipos de conectores (extraídas da Especificação BPMN 2.0, tradução livre desta autora):

  • Sequence Flow: Sequence Flow é usado para demonstrar a ordem em que as Atividades serão executadas em um Processo.” (p. 29)
  • “Se uma Atividade não possui Sequence Flows de entrada, a Atividade será instanciada quando o Processo ou Subprocesso que a contiver for instanciado.” (p.427)
  • “Se uma Atividade não possui Sequence Flows de saída, a Atividade será terminada sem produzir nenhum token e a semântica de término para o contenedor [Processo/Subprocesso] é aplicado” (p.427)
  • Message Flow: Message Flow é usado para mostrar o fluxo de Mensagens entre dois Participantes que estão preparados para recebê-las e enviá-las [representados através de Pools].” (p. 29)

A especificação BPMN 2.0 vai mais além quando realiza uma distinção destes fluxos em diagramas distintos: o de Processo, ou Orquestração (que representa a sequência das atividades do processo de negócio) e os de Colaboração e Conversação (que representam exclusivamente a comunicação entre processos de negócio e outros participantes externos).

Apenas para reforçar a diferença semântica existente entre estes dois elementos de BPMN, veja um outro exemplo em que o fluxo de atividades não poderia ser representado pelo fluxo de mensagens:

BPMN - exemplo de processo de tele-entrega de pizzaria

Exemplo de processo de tele-entrega de pizza (traduzido livremente do modelo "5.2 The Pizza Collaboration" em «1» BPMN 2.0 by Example).

Observe no exemplo acima como não seria possível garantir a compreensão do fluxo de atividades do processo se elas fossem representadas apenas pelos fluxos de mensagem. Além disso, note como os fluxos de cada um dos processos (do cliente e da pizzaria) são independentes um do outro: cada um tem seu evento de início, sua própria sequência de atividades e seu evento de término. É possível ler o flluxo do processo do cliente sem conhecer o processo da pizzaria, assim como é possível ler o fluxo do processo da pizzaria sem conhecer o processo do cliente. Essa independência é fundamental para uma diagramação de processos correta, e este tipo de leitura é um excelente exercício na hora de elaborar seus próprios modelos de processos.

Portanto, ao desenvolver seu modelo, lembre-se de garantir que o fluxo de atividades esteja íntegro. Onde houver dependência de execução entre as atividades do processo, a mesma deve ser representada usando o conector de sequence flow.

 «1» BPMN 2.0 by Example