Oracle SOA Suite 11g: uso da atividade assign no BPEL

Trabalho com desenvolvimento BPEL há alguns anos utilizando o produto da Oracle, o SOA Suite, e tenho acompanhado a sua evolução desde a versão 10g, incluindo a IDE de desenvolvimento, o JDeveloper.

Recentemente estive envolvido em um projeto e precisei utilizar em diferentes contextos o componente assign. Nas versões mais recentes do produto existe uma sensível diferença na interface para realizar as atribuições e isso me motivou a escrever esse post, na tentativa de destacar e exemplificar o uso do copy e das suas regras: copy listappend, insert after e insert before.

Nos exemplos abaixo utilizei uma VM produzida pela Oracle (disponível aqui) e configurada com:

Oracle Enterprise Linux (64-bit) EL 5 Update 5
Oracle XE Database 11.2.0
Oracle SOA Suite 11.1.1.6.0 (includes Service Bus)
Oracle BPM Suite 11.1.1.6.0
Oracle JDeveloper 11.1.1.6.0
JRockit R28.2.0-79-146777-1.6.0_29s

O valor de input utilizado nos testes foi:

<inputVariable>
    <part  name="payload">
        <ns1:OrdemServicoRequest xmlns:ns1="http://xmlns.oracle.com/DDM">
            <ns1:CodigoOS>123</ns1:CodigoOS>
            <ns1:DataAberturaOS>22/09/2012</ns1:DataAberturaOS>
            <ns1:TipoOS>OS</ns1:TipoOS>
            <ns1:StatusOS>Iniciado</ns1:StatusOS>
            <ns1:DataEncerramentoOS>25/09/2012</ns1:DataEncerramentoOS>
            <ns1:Codigocliente>12114</ns1:Codigocliente>
            <ns1:NomeCliente>José da Silva Sauro</ns1:NomeCliente>
            <ns1:EnderecosCliente>
                <ns1:EnderecoCliente>
                    <ns1:Rua>Rua 1</ns1:Rua>
                    <ns1:Numero>2</ns1:Numero>
                    <ns1:Complemento>Bairro 3</ns1:Complemento>
                    <ns1:Cidade>Longe de Tudo</ns1:Cidade>
                    <ns1:Estado>Algum</ns1:Estado>
                    <ns1:CEP>01000-000</ns1:CEP>
                </ns1:EnderecoCliente>
                <ns1:EnderecoCliente>
                    <ns1:Rua>Rua 2</ns1:Rua>
                    <ns1:Numero>3</ns1:Numero>
                    <ns1:Complemento>Bairro 4</ns1:Complemento>
                    <ns1:Cidade>Perto de Tudo</ns1:Cidade>
                    <ns1:Estado>Nenhum</ns1:Estado>
                    <ns1:CEP>02000-000</ns1:CEP>
                </ns1:EnderecoCliente>
            </ns1:EnderecosCliente>
            <ns1:EmailCliente>jose@sauro.sil</ns1:EmailCliente>
        </ns1:OrdemServicoRequest>
    </part>
</inputVariable>

 

  • Uso tradicional do copy

O uso tradicional do copy serve, entre outras coisas, para atribuição de valores para variáveis à partir de outras variáveis ou funções pré-definidas no produto (expression).

Copy tradicional

Nesse caso temos o uso do assign com o copy tradicional. Cada campo utiliza uma solução diferente: atribuição direta de variável, atribuição de valor textual e utilização de uma função pré-definida do produto (no exemplo, current-dateTime()).

O retorno dessa atribuição será:

Copy tradicional - resposta

Resultado da execução

 

  • Uso do append

O append irá inserir um elemento ao final da lista, sem alterar o conteúdo já existe. Veja o exemplo abaixo.

Nesse exemplo foi criado um elemento para ser inserido na lista de status. Depois de alimentar as informações com valores válidos, foi incluído o elemento na lista de status com a regra append.

O resultado da lista, nesse momento do exemplo, são dois elementos.

Esse é o resultado da lista com o elemento incluindo no append.

 

  • Uso do copyList

A regra copyList tem por característica eliminar todos os elementos que já existirem na lista de destino e substituir integralmente o seu conteúdo, incluindo elementos e atributos.

No nosso exemplo incluímos um terceiro assign, depois dos dois assigns dos exemplos acima, com a regra copyList. Note que o array destino continha, até então, dois elementos. Os dois foram excluídos e um novo elemento será incluído, conforme exemplo. Para deixar claro o exemplo, incluímos dois elementos utilizando o copyList. O valor final do array irá conter somente o segundo valor inserido.

copyList assign

Observe que foram incluídos 2 novos elementos usando o copyList. Somente o segundo irá aparecer no array, já que a função copyList tem por princípio eliminar todos os elementos do destino antes de alimentar a variável com os novos valores.

O resultado final da lista conterá somente o segundo elemento inserido.

copyList response

O resultado do exemplo depois do uso do copyList no último assign.

 

  • Uso do insertBefore e insertAfter

O nosso último exemplo é para demonstrar o uso do insertBefore e insertAfter. O primeiro irá incluir um elemento antes do elemento assinalado no destino e o segundo, depois.

Nesse ponto do exemplo temos somente 1 elemento na lista. No último assign incluímos dois novos elementos: um utilizando insertBefore e outro utilizando insertAfter. Veja abaixo o resultado desse array.

O resultado final da lista será:

O resultado da lista com os valores incluídos antes e depois do elemento que já estava na lista.

 

A atividade assign é uma ótima opção para atribuição de valores às variáveis, muitas vezes eliminando a necessidade de uma transformação. Conhecer bem as suas regras ajuda a tirar proveito de todos os recursos envolvidos.

Um detalhe, por experiência de projeto, é que essa janela pode se tornar muito lenta no caso de utilização de schemas (XSD) que ficam armazenados em servidores remotos e no MDS. Esperemos que isso melhore nas próximas versões do produto.

O projeto utilizado no exemplo está disponível para download no link abaixo:

  • [download id="1"]

Implantação de BPMS não substitui os sistemas da empresa

Num artigo anterior deste blog, procuramos abordar as diferenças entre BPM e Workflow, com a intenção de minimizar a confusão existente com relação a este dois termos. Neste sentido, achamos interessante continuarmos a desmitificar outros mitos que se referem a BPM no que tange o aspecto da tecnologia.

Hoje, vamos falar de um dos mitos que mais escutamos durante os nossos projetos: a idéia de que a implementação de BPM irá “substituir” total ou parcialmente os sistemas atuais, e passar eventualmente a ser o repositório central das informações da organização. Ou, como já ouvimos algumas vezes, que o BPMS vai passar a ser o “ERP” da organização!

Em uma iniciativa BPM, uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Neste sentido, um BPMS atua como orquestrador da execução dos processos entre pessoas e sistemas, definindo o fluxo do trabalho e da informação entre estes participantes. Mas então, vem a pergunta: quem é o dono da informação numa automação de processos? Vamos primeiramente analisar 2 dos cenários mais frequentes de automação de processos.

1) Automação de processos que originalmente eram executados em papel, pouco/nenhum apoio de sistemas:

Neste caso, a organização não dispõe de sistemas para apoiar a execução destes processos, ou dispõe de sistemas que atendem apenas a uma parte do processo.

Normalmente são criados formulários eletrônicos que são responsáveis pelo início e execução do processo (ex: num processo de solicitação de viagem, o formulário inicial conteria os dados da viagem desejada pelo usuário). Durante a execução destes processos, usualmente existem pontos de integração com sistemas existentes na empresa (ex: sistema financeiro, contábil, etc). Neste cenário, eventualmente o BPMS poderá servir como repositório de algumas informações, normalmente sendo o repositório das “solicitações” em si (ex: solicitações de compra, solicitações de viagem, etc), e não dos dados de negócio de fato. Mas na experiência que temos, com bastante frequência as informações originadas/geradas pelos processos automatizados são enviadas para gravação em sistemas existentes da organização, como por exemplo ERP ou sistemas legados, que são de fato os responsáveis por armazenar e manter aquelas informações.

2) Automação de processos com apoio de sistemas:

Neste caso já existe um ou mais sistemas que apoiam a execução de parte ou todo um processo, mas o fluxo de execução das atividades não é orquestrado e controlado, ou seja, os sistemas e usuários responsáveis por aquele processo estão desconectados uns dos outros, o que gera então a necessidade de automação.

Neste cenário, com frequência as atividades do processo automatizado são executadas nos próprios sistemas, cabendo ao processo automatizado basicamente controlar o início e término das atividades, e a comunidação dos envolvidos nos pontos onde há necessidade de alguma intervenção humana. Assim, as atividades na lista de trabalho meramente direcionam os usuários para os sistemas onde estes deverão efetivamente realizar as atividades. Outro cenário bastante frequente é a busca, pelo processo automatizado, de informações armazenadas em sistemas existentes, de forma a apoiar os usuários na execução dos processos. E, como não poderia deixar de ser, neste cenário é ainda mais frequente e usual a necessidade de, em diversos pontos do processo automatizado, enviar as informações geradas durante a execução do processo para armazenamento em sistemas existentes.

Com base nos cenários visto acima, retomamos então a pergunta. Quem é realmente o dono da informação numa automação de processos?

Note que, em qualquer um dos casos que citamos até agora, normalmente o BPMS não é a fonte principal dos dados sendo manipulados, mas atua principalmente como integrador destas informações, buscando e enviando dados para outros sistemas durante a execução dos processos.

Podemos concluir, então, que a implementação de um processo automatizado de forma nenhuma significa a descontinuidade dos sistemas existentes!

Estimando a duração de processos

Durante a análise de um processo, um dos trabalhos comumente realizados é a estimativa da duração do processo e suas atividades.

Apesar de ser um atributo importante para o entendimento de um processo, o tempo é uma informação  frequentemente avaliada de modo bastante displicente. A estimativa de tempo do processo acaba por ser realizada com base na percepção das pessoas em função do trabalho realizado, em geral na forma de “chute”. O resultado é uma avaliação que não condiz com a realidade – ou porquê foi superestimado, levando a crer que o processo possui um desempenho superior ao seu real potencial, ou subestimado, levando ao entendimento de que o processo não é eficiente pois está sempre atrasado.

Assim, uma avaliação de tempo realizada sem um estudo apropriado tende a impactar em diversas decisões equivocadas de melhoria, já que é um critério essencial para a avaliação do desempenho do processo.

Para se estimar o tempo envolvido na realização de um processo, é necessário compreender os conceitos de: duração, execução e trabalho.

Esquema de espera, execução, trabalho e duração da atividadeO trabalho, ou esforço,  é o tempo que o participante da atividade leva, efetivamente, na realização do trabalho a ser executado. Em uma tarefa, é possível que o trabalho seja realizado em partes antes da mesma ser considerada como concluída.  Por exemplo, o preenchimento de um formulário, a pesquisa de dados adicionais e a complementação do mesmo. Portanto, o tempo de trabalho é a soma do tempo dispendido em ações necessárias para que a tarefa seja concluída.

A execução é o tempo dispendido deste o início do trabalho até o mesmo ser concluído, inclusive o tempo entre as partes do trabalho. Por exemplo, do momento em que a pessoa iniciou o preenchimento do formulário, até o momento em que o mesmo foi completamente preenchido.

A duração é o tempo calculado desde o momento em que a tarefa esteve disponível para o participante responsável pela atividade. Por exemplo, desde o momento que o formulário foi deixado na caixa de entrada do participante,  mais o tempo de espera que levou para que a pessoa tomasse o formulário em mãos para iniciar o trabalho, até o seu completo  preenchimento.

Analisar a execução de um processo requer conhecer o tempo de trabalho, execução e duração de cada atividade envolvida.

Ao se calcular a duração de um processo, entretanto, não basta somar as durações das atividades envolvidas. Em um processo executado manualmente (ou seja, sem o controle por um BPMS), a duração é afetada também pelo handoff, que é a espera dispendida no transporte das informações do processo entre os participantes das atividades.

Esquema de espera, execução, trabalho e duração de processo manual

Um exemplo clássico do tempo de espera em transporte é, por exemplo, o tempo levado para que um formulário preenchido em uma atividade seja disponibilizado para o participante da próxima atividade.

Assim, a duração do processo é a soma da duração das atividades mais a soma das esperas entre atividades.

Estimar corretamente os tempos de um processo pode levar a várias ações de melhoria, como:

  • Definir níveis de serviço (SLA) realistas;
  • Definir indicadores que apoiem na identificação de gargalos em atividades, baseados no tempo de espera que uma atividade leva para ser iniciada;
  • Melhorar a distribuição de recursos para realizar as atividades de acordo com o volume de trabalho;
  • Melhorar as ferramentas utilizadas pelos participantes das atividades a fim de agregar velocidade à realização do trabalho;
  • Avaliar melhoria de desempenho simplificando-se ou removendo-se tempos de transporte (handoffs), ou mesmo buscando métodos de transporte mais eficazes.

A automatização de processos é uma alternativa para a busca de desempenho e solução para o transporte das informações entre as atividades. Em geral, há dois benefícios comumente identificados na automatização relacionados ao tempo de execução do processo:

  1. Eliminação do tempo de handoff, já que o motor do processo disponibiliza as informações ao próximo participante imediatamente após a conclusão da atividade anterior;
  2. Eliminação do tempo de espera em atividades executadas pelo sistema (como serviços de busca ou gravação de informações, por exemplo), já que a execução das mesmas é realizada imediatamente  quando a atividade é disponibilizada.

Esquema de espera, execução, trabalho e duração de processo automatizado

Seja executado por controles manuais ou automatizado com um BPMS, compreender a análise dos tempos na avaliação da duração de atividades e processos é uma ferramenta de gestão fundamental rumo à melhoria do desempenho dos processos da organização.


Leia mais sobre o cálculo da duração de processos no artigo complementar Estimando a duração de processos II – processos não lineares.

BPM e Workflow – Qual a diferença?

Com o crescimento da temática de Gestão por Processos nas organizações, muitas pessoas tem dúvida de quais seriam as diferenças entre BPM e Workflow. Primeiramente, vamos conceituar cada um destes termos:

  • Workflow é um tipo de tecnologia para automação do fluxo de atividades de um processo, tecnologia esta que existe há varios anos. Com uma ferramenta de workflow, é possível coordenar a execução de um processo de negócio através da execução ordenada de tarefas, que podem ser de responsabilidade de pessoas ou de sistemas.
  • BPM (Business Process Managament), segundo a definição do BPM CBOK, é “uma abordagem disciplinada para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio automatizados ou não para alcançar os resultados pretentidos consistentes e alinhados com as metas estratégicas de uma organização“.

Podemos identificar de imediato que BPM tem uma abordagem e uma área de atuação muito mais abrangente que Worklow. No que se refere a tecnologia, a adoção de BPM geralmente inclui, por exemplo, a utilização de produtos de software para modelagem, análise e desenho de processos (BPA – Business Process Analysis), automação do fluxo de trabalho (Workflow), motores de regras de negócio (BRM – Business Rules Managament), monitoramento de processos de negócio (BAM – Business Activity Monitoring), Gerenciamento de Conteúdo (GED/ECM) e gerenciamento de repositório de processos.

Visão geral - Tecnologia de apoio a BPM

BPM também é uma disciplina, que orienta a empresa a conduzir sua operação numa abordagem horizontal, com o foco voltado aos seus processos de negócio. Desta forma, é perfeitamente possível que uma organização adote BPM e não precise, necessariamente, implementar ou utilizar uma ferramenta de automação ou BPMS (Business Process Managament System), embora o apoio assistido de tecnologia seja cada vez mais importante para a implementação bem sucedida de BPM nas organizações. Não podemos deixar de mencionar que BPM envolve também mudanças na cultura e valores da organização, indo assim muito além de uma simples plataforma tecnológica para apoio a execução dos processos.

Workflow, por sua vez, refere-se apenas a tecnologia que implementa a automação de fluxos de trabalho. Projetos de implementação de workflow normalmente costumam ser ações mais pontuais, específicas e departamentais dentro da organização, sendo frequentemente tentativas de melhoria de processo problemáticos, com foco por exemplo em diminuição de prazo e maior controle das atividades, e na maioria das vezes sem uma abordagem estruturada e planejada de melhoria de processos embasando o trabalho.

Nota-se que as organizações frequentemente utilizam ferramentas de workflow para automatizar processos de apoio (ex: processo de solicitação de viagem), e não processos primários ou core, o que também é um fator relevante a destacar. Também nota-se que as organizações usualmente automatizam processos numa ferramenta de workflow sem passar por uma fase de análise e desenho prévio daqueles processos, ou seja, sem avaliar as necessidades de melhoria e gerar o modelo TO-BE, o que pode levar a resultados pouco satisfatórios.

Com base no que detalhamos até agora, gostaríamos de concluir este artigo alertando para uma certa confusão que existe hoje no mercado, onde temos ferramentas de Workflow que autointitulam-se como “plataforma de BPM” ou “BPMS”, embora na prática implementem apenas uma parte dos conceitos relacionados a BPM (normalmente a automação de fluxo de trabalho, e eventualmente o gerenciamento de documentos).

É importante ter claro que se uma empresa está apenas automatizando fluxos de trabalho utilizando uma ferramenta de Workflow, sem uma abordagem estruturada para gerenciamento e monitoramento de processos de negócios que embase este trabalho, ela não está implementando BPM, mas apenas automatizando seus fluxos de trabalho.