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.

Quando usar o OSB, Oracle BPEL ou Oracle BPM

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).

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="https://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″]

Avaliando o real custo-benefício de BPMS livres ou de baixo custo

No nosso último post falamos sobre os motivos que tornam a escolha de uma plataforma de BPMS tão difícil (veja aqui).

Aprofundando a questão da seleção de plataformas, um equívoco muito comum está no fato dos profissionais acreditarem que soluções de BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas. Por vários fatores que veremos a seguir esta premissa nem sempre é verdadeira, sendo fundamental que os seguintes fatores sejam analisados:

  1. Investimento total na ferramenta no longo prazo: Nem sempre o custo de licenciamento é o maior custo na aquisição de uma solução BPMS, principalmente quando visto a médio ou longo prazo. Muitas vezes, o custo de um contrato de suporte e manutenção de uma ferramenta gratuíta é significativamente maior ao final de 3 ou 5 anos do que a soma dos custos de licenciamento e contrato de manutenção de outras ferramentas, de modo que este custo não pode ser analisado somente no primeiro ano.
  2. Requisitos disponibilizados pela ferramenta: Para evitar que o barato saia caro, analise o quanto a solução escolhida é aderente às necessidades da sua empresa. Caso existam requisitos obrigatórios ou opcionais que ela não atenda, verifique qual será o impacto da solução escolhida não ter estas funcionalidades.
  3. Benefícios (reais) de uma solução Open Source: A escolha de uma solução open source (quando o fabricante disponibiliza o acesso ao código fonte do produto) nem sempre traz o benefício esperado pela organização. Via de regra, fornecedores que dão suporte e manutenção às suas ferramentas não permitem, durante o período de vigência do contrato, que seus clientes alterem o seu código fonte, pois isso inviabilizaria o contrato de suporte.
  4. Características do suporte oferecido pelo fabricante: É fundamental verificar como é o nível de suporte fornecido pelo fabricante: Questões como a existência de suporte no país, a língua em que é prestado o atendimento, a possibilidade de se obter um atendimento no local, a disponibilidade 24×7, a existência ou não de um limite de abertura de chamados e o tempo de atendimento à produção devem ser analisados de modo a verificar se o suporte irá atender às expectativas.
  5. Existência de mão de obra qualificada: Uma ferramenta de BPMS, por si só, é uma caixa vazia: não tem nenhuma utilidade enquanto os processos não forem desenvolvidos. Assim, a disponibilidade de mão de obra capacitada para realizar este desenvolvimento torna-se um fator crucial.
  6. Esforço para a formação de um profissional apto a operar com a plataforma: Uma alternativa para uma eventual falta de mão de obra qualificada é a organização investir na formação de pessoal capacitado. Aqui, torna-se fundamental avaliar qual a complexidade desta formação: Quais os pré-requisitos mínimos de conhecimento de um profissional que venha a se capacitar? Como é a qualidade do material de capacitação fornecido pelo fornecedor? Existem instrutores disponíveis para realizar esta formação? Ou existe uma material de auto-estudo que permita esta capacitação? O quão rico é este material?
  7. Verifique o custo da mão de obra especializada: De nada adianta a organização economizar em licenciamento e gastar muito mais a cada projeto de automação que for realizar. Desta forma, é importante que se avalie qual o custo da mão de obra especializada em operar a ferramenta de BPM.
  8. Qual a produtividade oferecida pela plataforma: Finalmente, a produtividade também é um fator essencial na análise de custo entre plataformas distintas. Semelhante à questão do custo da mão de obra, uma plataforma que render uma produtividade significativamente superior às outras pode ter o seu custo de licenciamento pago rapidamente ao final de um primeiro ou segundo projeto de automação.

Timeout de atividades humanas no Oracle BPM

A necessidade de estipular prazos para que as tarefas humanas sejam realizadas é uma  característica constante nos processos automatizados.

Leia nesse artigo técnico um passo-a-passo de como implementar o uso de timeout no produto Oracle BPM 11g.

1. Timeout com expiração da tarefa

Se o objetivo é expirar a tarefa, retirando-a da lista de trabalho do usuário, o timeout pode ser setado diretamente nas configurações da tarefa humana, conforme segue:

A configuração deste tipo de timeout é semelhante no caso de tarefas humanas no Oracle BPEL 11g.

 

1.1. Definindo o timeout

Edite o arquivo .task de definição da tarefa. Conforme exibido na Figura 1 abaixo, na definição da tarefa, na aba “Deadlines” configure para expirar conforme um número fixo de dias, horas ou minutos a partir do início da tarefa; ou relativo a algum parâmetro definido no processo.

Note que a duração de tempo relativo em XML é expressa no formato P0Y0M0DT0H0M0S (https://www.w3schools.com/Schema/schema_dtypes_date.asp). Por exemplo, P2D equivale a 2 dias, e PT60S equivale a 60 segundos.

Se for preciso fazer cálculos com datas para calcular o timeout, existem no produto funções XPath para fazer adição ou subtração de durações de tempo com datas.

configuração do timeout na tarefa humana

Figura 1: configuração do timeout na tarefa humana

1.2. Avaliando no processo como a tarefa foi encerrada

Quando a tarefa é encerrada por timeout, seu status é alterado para expirada e o processo segue adiante. Então, se for preciso tomar alguma ação ou rota específica quando ocorrer o timeout, é preciso verificar nos dados de retorno como a tarefa foi encerrada.

Primeiro, é preciso salvar os dados de execução da tarefa em um dataobject, como exibido na Figura 2 abaixo:

mapeando o retorno dos dados da tarefa

Figura 2: mapeando o retorno dos dados da tarefa

Depois, numa tarefa de script extraia o valor do estado da tarefa com a expressão XPath:
string(bpmn:getDataObject(‘taskExec’)/ns:systemAttributes/ns:state)

Se o valor do estado for igual a EXPIRED, a tarefa foi encerrada por timeout ;-)

2. Timeout sem expiração da tarefa

É comum também que seja preciso implementar controle de timeout em uma tarefa, sem no entanto encerrá-la. Por exemplo, para enviar um email de aviso de atraso.

Nesse caso, não configure o timeout na aba ”Deadlines” da definição da tarefa. Ao invés disso, adicione um evento de timer de borda na tarefa humana, como mostra a Figura 3 a seguir:

timer de borda

Figura 3: timer de borda

Se o prazo de expiração for único, o timer pode por exemplo ser implementado como a adição de uma determinada duração a data atual no momento de criação da atividade:

xp20:add-dayTimeDuration-to-dateTime(string(xp20:current-dateTime()),concat(‘PT’,string(bpmn:getDataObject(‘timeout’)),’S’))

Se o timeout deve ser com base em uma data fixa, configure o timer como sendo do tipo Time Date, como mostra a figura abaixo.

timer de data fixa

Figura 4: timer de data fixa

Deixe desmarcada a opção “Interrupting Event” se a tarefa NÃO deve ser encerrada ao estourar o timeout. Se marcar essa opção a tarefa será interrompida quando ocorrer o timeout!

Se o timeout deve ser executado diversas vezes, ciclicamente, então é só marcar o timer como “Cycle” e lembrar que ele não deve ser do tipo “interrupting”:

timeout cíclico

Figura 5: timeout cíclico

Lembre-se que sendo do tipo cíclico, o valor da expressão que tem de ser setado é novamente uma duração. Por exemplo:
concat(‘PT’,string(bpmn:getDataObject(‘timeout’)),’S’)

 

* Observação: as cópias de tela apresentadas são baseadas no produto Oracle BPM 11g – versão 11.1.1.4, porém as configurações citadas são igualmente válidas nas versões posteriores do produto, apenas variando um pouco o estilo das caixas de diálogo.

 

BPA (Business Process Analysis) – Indo além dos Desenhadores de Processos

Utilizados principalmente pelos usuários de negócio, o BPA (Business Process Analysis) é a principal ferramenta utilizada pelo analista de processos para mapear, documentar, analisar e redesenhar os seus processos organizacionais.

Diferentemente dos desenhadores de processos, que são utilizados quase que exclusivamente para o mapeamento e documentação de atributos do processo, os BPAs possuem funcionalidades que extrapolam as funções de desenho do processo e apoiam grande parte das iniciativas de gestão por processo da organização.

Apesar das funcionalidades disponíveis numa ferramenta de BPA dependerem da implementação de cada fornecedor, iremos citar abaixo algumas das principais características presentes na maioria destas plataformas.

  • Gestão do Repositório de Processos Organizacional. Os processos são armazenados em uma base de dados, centralizada, de forma controlada e estruturada. Todos os processos da organização são mantidos nesta base, com controle de acesso e segurança. Somente usuários autorizados podem acessar a esta base, e é possível configurar quem pode acessar cada processo e quais são estes direitos de acesso (leitura, alteração, exclusão, …)
  • Definição de Metadados dos processos. São definidos atributos que permitem a classificação e catalogação dos processos organizacionais. Estes atributos podem ser utilizados para auxiliar a navegação no repositório de processos ou a realização de pesquisas avançadas.
  • Visão top-down dos Processos da Organização. Podemos modelar num BPA o processograma da organização, que abrange desde a identificação da cadeia de valor até o detalhamento dos seus macro-processos e processos operacionais.
  • Definição dos Campos de Documentação. Os campos que documentam os processos e suas atividades podem ser definidos pela organização, bem como seus tipo e obrigatoriedade.
  • Customização de Templates de Documentação. As informações dos processos armazenados no BPA podem ser exportadas para documentos cuja estrutura pode ser definida pelo escritório de processos. A empresa pode definir templates de diferentes tipos de documentos e gerar estes documentos automaticamente para um determinado processo. A figura abaixo mostra uma tela de customização de relatórios do Aris.

  • Publicação dos Processos de Negócio. Os processos armazenados podem ser consultados por diferentes usuários da organização através da sua publicação em um portal de processos. Mais do que uma exportação em formato Web, disponível em muitos desenhadores de processo, esta publicação mantém as regras de segurança e controle de acesso, exigindo login e senha dos seus usuários e garantindo que eles só poderão acessar os processos em que estão autorizados.

  • Soluções de Colaboração. Ao longo do mapeamento e redesenho de processos, é muito comum a equipe de análise precisar de um feedback de pessoas da organização sobre o processo que está sendo analisado. Através das soluções de colaboração, é possível que usuários selecionados façam anotações no processo e proponham sugestões sem que o processo seja efetivamente alterado. Estas sugestões são então analisadas pela equipe de analistas que avalia a viabilidade da sua adoção.
  • Simulação de Processos. Complementar a modelagem de processos, a simulação permite que o analista verifique qual será o comportamento do processo numa nova configuração. Como resultado, são gerados relatórios que demonstram como foi o seu desempenho, quais os pontos de gargalo, quais as necessidades de recursos, entre outras informações. Além disso, diferentes simulações podem ser comparadas com o objetivo de avaliar o ganho obtido com cada configuração.

 Podemos citar como exemplos de soluções de BPA os softwares Aris da Software AG, Oracle BPA da Oracle, iGrafix da Corel e Websphere Modeler da IBM; e são exemplos de desenhadores de processo o Oryx, o BizAgi Modeler e o Microsoft Visio.