Há cerca de um mês atrás eu havia falado sobre isso, lembra? Resumidamente o que eu havia dito é que apesar de saber que a versão no cliente ainda era a 6.04, eu havia tomado a decisão de usar a versão nova do Oracle BPM Studio, pois em relação a ferramenta pouca coisa havia mudado e o que havia mudado não impactaria no arquivo gerado a ser deployado nas distribuições enterprise. Inclusive o pessoal da Oracle havia me confirmado isso em um workshop que eu havia ido.

Como o cluster lá do meu trabalho onde está (estava) rodando a versão 6.04 da distribuição enterprise estava muito instável, resolvi fazer a instalação em outra máquina. Foi aí que começou a minha própria Via Crucis. Um detalhe importante é que eu nunca havia feito a instalação da distribuição enterprise, portanto era uma experiência totalmente nova para mim.

A distribuição enterprise do ALBPM possui alguns conceitos um pouco diferentes da versão usada para desenvolvimento (Studio), a começar pelo conceito de directory service e pelas outras aplicações que vem agregadas juntas a instalação. Dentre as aplicações que me interessavam estavam apenas o process administrator, workspace e process engine. Tinha ainda o PAPI Web Services, que pode ser muito importante dentro de um projeto BPM, mas como eu não precisaria integrar outros projetos com o meu projeto BPM, então o PAPI-WS nesse caso não seria necessário, pelo menos não naquele directory service atual. Directory Service é onde ficam guardadas as informações referentes a usuários, roles, grupos, resources externos e outras informações que fazem parte de um projeto no BPM, além também dessas aplicações já citadas. Não necessariamente cada projeto deve ter o seu próprio directory service, na verdade N projetos podem compartilhar o mesmo. Outro ponto importante diz respeito a process execution engine, pois cada directory service possui a sua própria engine, ou até mesmo mais de uma, mas apenas uma engine cadastrada pode estar “rodando”. Uma engine está associada a um servidor de aplicações e no meu caso está associada a uma instância do weblogic, pois foi essa a versão que eu havia escolhido no ato do download.

Sinceramente, apesar de já ter escutado comentários de que a distribuição enterprise (<= 6.*) era um pouco irregular e que possuia algumas peculiaridades, eu não sabia que seria tão árdua a sua instalação. O primeiro problema que eu encontrei foi na criação de um directory service, nesse ponto, através de uma tela do tipo wizard, a instalação solicita as informações do banco de dados onde serão gravadas as informações do directory service, no meu caso eu escolhi como banco de dados o Oracle (Oracle-XE). Nessa mesma tela, a configuração solicita qual o nome do Schema onde serão criadas as tabelas e eu aconselho fortemente deixar essa opção em branco, pois além dela ser opcional, o negócio só funcionou depois que eu a deixei em branco. Em uma das minhas tentativas mal sucedidas eu até havia criado o schema “na mão”, mas mesmo assim não funcionou. Primeiro problema resolvido, nome dos schemas deixados em branco e tudo ok.

O segundo problema talvez tenha sido o pior de resolver. Depois de informar todos os dados necessários para a configuração viria a tela de progresso e conclusão da criação do directory service, nesse momento só resta aguardar até que a ferramenta termine o processo de criação. Mas para o meu azar o processo nunca conseguia ser concluído, pois sempre antes de chegar em 100% o processo me mostrava a mensagem: failed! Tentei mais algumas vezes e após tantos insucessos resolvi verificar os logs e ver qual era o erro. O log nesse caso ajudou e não ajudou, pois no log a informação principal do erro é que uma exceção havia sido disparada quando o JAR de algum EJB estava tentando ser gerado pela instalação. Pesquisei, pesquisei, pesquisei e nada… resolvi então falar com um amigo de trabalho que tinha comentado que a instalação da distribuição enterprise era meio caótica. Ele pediu para eu ver o stack-trace todo da exceção. Após reparar bem o stack-trace percebi que o mesmo continha uma frase que terminava com “too many open files” e informei sobre a mensagem para esse amigo, ele então me disse que esse problema não tinha relação com o JAR do EJB, na verdade o problema estava ocorrendo, pois o SO (Ubuntu) estava tentando abrir mais de 1024 arquivos ao mesmo tempo durante a instalação e que eu precisaria mudar algumas configurações padrões do SO (file descriptor) para resolver esse problema, isso no caso seria um OS tuning. Mudanças feitas e não deu outra: o diretório foi criado com sucesso!

O próximo problema ocorria ao tentar startar a process execution engine. Sempre que eu tentava inicializar a engine a mensagem de status nunca se modificava, não informava nem que estava inicializada e nem que estava parada. Após bater bastante cabeça com isso, fui até o manual de instalação e verifiquei que um dos pré-requisitos era que a versão do Weblogic fosse a 9.2 e no meu caso eu estava usando a 10.0 ou 10.3. Na verdade esse problema ocorreu mais em razão de um vacilo meu do que qualquer outra coisa. Instalei a versão 9.2, criei outro diretório novamente e agora eu conseguia startar a engine sem problemas.

Acho que tive também alguns problemas de versão de JVM, no caso JRockit, mas isso foi tranquilo de resolver, porque o erro era bem evidente.

Instalação concluída, fui tentar finalmente fazer o deploy de um projeto e… mais problemas! Fazer o deploy eu até conseguia, mas ao tentar executar os processos um erro estranho ocorria e verificando o log percebi que alguns arquivos do projeto não estavam sendo encontrados. Para mim nada poderia explicar aquilo a não ser problemas de versão, pois como eu já citei, a versão de desenvolvimento que eu estava usando era diferente da versão da distribuição enterprise. Resolvi então tentar abrir o projeto em uma versão de ambiente de desenvolvimento igual a da distribuição enterprise com o intuito de gerar o arquivo a ser deployado em versões iguais. Ao abrir o projeto em uma versão mais antiga não tive nenhum problema, o ALBPM Studio conseguiu detectar todos os processos, screenflows, resources e etc, mas ao tentar executar o processo comecei a ter alguns problemas. Após alguns debugs, percebi que alguns métodos da API de Java (Component Catalog) simplesmente não existiam, ou, não funcionavam nessa versão mais antiga (ALBPM Studio 6.04) e que provavelmente esse poderia ser o mesmo problema que ocorria na distribuição enterprise. Isso de certa forma fazia com que a minha teoria de que não haviam mudanças consideráveis entre as versões ALBPM e OracleBPM caísse por terra.

Fiz os ajustes no projeto na versão mais antiga da ferramenta, gerei um arquivo de deploy novo e fui novamente tentar rodar o projeto na distribuição enterprise. Mesmo problema! A essa hora minha paciência estava esvaindo-se, mas eu precisava conseguir deployar o projeto de qualquer jeito. Resolvi, só por desencargo de consciência, baixar a distribuição enterprise em sua versão mais atual, no caso já como Oracle BPM Enterprise 10g3. Baixei, fiz a instalação – que por sinal foi muito mais tranquila – e tentei fazer o deploy do projeto e executá-lo. Para minha surpresa (ou não) foi de primeira! Consegui executar o projeto direitinho na versão nova da distribuição enterprise, o que me faz concluir que a versão 6.04 (ou <) é realmente problemática ou então o impacto entre versões Oracle (Oracle BPM) x BEA (Aqualogic BPM) é realmente considerável.

Dicas Finais

• Caso use a distribuição enterprise na versão 6 (ou <) use o Weblogic 9.2 e não 10.0 (ou >);
• Não esqueça de mudar as configurações (file descriptor) do seu SO para permitir que ele consiga abrir mais de 1024 arquivos simultaneamente;
• Na criação de um directory service, deixei que a ferramente crie um schema para você no banco de dados, portanto deixe a opção em branco;
• Verificar possíveis incompatibilidades entre versões de JVM;
• É necessário sempre inicializar a instância do Weblogic antes de inicializar o Admin Center do BPM;
• Caso não consiga startar a sua engine e tudo pareça estar correto, tente acessar o console do weblogic e dar unlock no usuário FuegoWeblogicDeployer, pois quando uma engine tenta ser inicializada várias vezes e não consegue, esse usuário fica travado;
• Caso algum erro ocorra no Process Administrator ou então no Workspace, tente ver o código fonte da página HTML, pois em muitas vezes o erro (detalhado) fica oculto dentro de comentários.

O início

Ao iniciar o projeto que estou atualmente, confesso que fiquei no impasse de “qual versão usar?”, pois o BPM Server (enterprise) de produção ainda é o 6, ou seja, Aqualogic. Paralelo a isso, comecei a ter alguns problemas com a versão 6.03 do Aqualogic BPM Studio na minha máquina, pois como tenho dois localhost (alias) apontando para o mesmo IP local (127.0.0.1), ao subir a engine um erro com a mensagem “server has exited” começou a ocorrer e com isso não conseguia “startar” a ferramenta. Pesquisando no Google, vi no falecido fórum da BEA, uma thread dizendo que para resolver esse problema bastaria eu comentar uma das linhas que apontam para o meu IP local no arquivo de hosts do meu SO. Fiz o procedimento e… nada! Ainda nessa mesma thread, havia outro comentário informando que na versão nova (Oracle) a engine estava mais esperta e resolvia esses tipos de problemas, foi a partir disso que resolvi usar a nova versão, ainda meio que ressabiado.

O problema e a segurança

Mas aí surge um novo problema: a incompatibilidade entre versões. Meu ambiente de desenvolvimento usa a versão nova e o meu ambiente de produção usa a versão mais antiga, será que com isso terei problemas em fazer deploy? A princípio não deveria ocorrer problema algum, pois na verdade o que mudou foi basicamente a skin da ferramenta, o workspace (skin também) e a engine que ficou mais esperta. Nesse meio tempo, por coinciência, tive um treinamento de BPM aqui no RJ com o pessoal da Oracle e ao perguntar pra eles se esse problema poderia se concretizar, fui respondido que não, apesar de nunca terem feito esse teste. Confirmaram ainda, que realmente quase nada havia mudado de uma versão para outra. Foi o suficiente para eu ter segurança na minha decisão.

A realidade

Mas no decorrer do projeto, tenho percebido que o buraco é um pouco mais embaixo hehe, nada que comprometa o desenvolvimento, mas alguns cuidados precisam ser tomados e como estou passando pela experiência, acho válido relatar para quem possar vir a passar pelas mesmas situações que eu. Só gostaria de ressaltar, que os testes que tenho feito não são os ideais, pois o que estou testando é o projeto sendo executado no Studio BPM na versão Oracle (nova) e também no Aqualogic (antiga), mas ainda não tentei fazer deploy em uma versão enterprise, pois ainda estou sem ambiente para isso, quando tiver esses testes, atualizo esse post.

Abaixo irei enumerar as diferenças que notei até agora com suas devidas observações.

Controle de Versão
Na versão 6.03 (Aqualogic), a ferramenta ainda não possuia um controle de versão embutido para SVN, se fazia por necessário instalar um plugin (Subversive) para ter essa funcionalidade, agora isso já vem de graça! Essa sem dúvida foi uma melhoria muito positiva na qual não tive problema algum entre as versões.

Connectors
O BPM Studio, em ambas as versões, tem uma coisa muito legal chamada connectors. Com os connectors é possível criar um atalho para determinada atividade sem ter que puxar uma transition para a mesma, isso é muito bom para ajudar na organização do processo, pois com isso evita-se que um monte de transitions fiquem entrelaçadas deixando o processo uma verdadeira zona.

Com connectors comecei a ter alguns problemas, pois processos que possuiam connectors na versão nova simplesmente não funcionavam na versão antiga. Pior do que isso, processos com connectors na versão nova não abrim na versão antiga! Não consegui descobrir o motivo, a única conclusão que cheguei é que geralmente o problema ocorria com connectors que linkavam para uma atividade final (End) do processo.

Conclusão: não uso mais.

Instanciar Variáveis
Esse foi um comportamento que eu sinceramente prefiro da versão antiga, pois acho mais correto.

O que ocorre é que algumas variáveis de instância eu não preciso instanciar, então em um array de BPMObject eu consigo ter algo do tipo:

bpmObject[i].nome = "Marcus Cavalcanti";

Ou seja, não precisei instanciar aquele índice corrente do array. Já na versão antiga isso não funciona, obviamente ocorre um NullPointerException, então para resolver isso eu preciso fazer:

bpmObject[i] = new MeuBpmObject();
bpmObject[i].nome = "Marcus Cavalcanti";

Eu prefiro a segunda opção, mais conservadora. Sinceramente não sei como e porque a primeira opção funciona na versão nova, pois não deveria.

Activity x Transitions
Uma mudança simples, mas muito significativa ocorreu nessa nova versão. Toda vez que uma atividade é adicionada ou removida, automaticamente o layout se ajusta e na maioria das vezes bagunçando as transitions entre uma atividade e outra. Agora na nova versão existe a possibilidade de habilitar/desabilitar esse “recurso”. É muito simples, basta ir em:

Window > BPM Preferences > Activity > General

Seguido os passos acima, basta apenas desmarcar o último checkbox. Fichinha!

Gráficos e Skin
Nossa… esse foi um avanço e tanto! Na versão para Linux os ícones ficavam horrorosos! Ficavam sem transparência por causa do PNG, então ficava aquele fundo preto e era horrível, além do mais os ícones agora estão bem mais trabalhados e bonitinhos :)

O Workspace foi outra coisa que mudou, achei a nova skin bem melhor e funcional, parece que cabem mais informações.

Conclusão

Conforme dito no começo, mudanças em relação a features não existem de uma versão para outra, mas percebi algumas pequenas mudanças ao executar o mesmo projeto em versões diferentes, o que pode trazer pequenos problemas.

Acredito que a principal questão seja em relação a diferença entre versões de desenvolvimento e enterprise, mas esses testes ainda não possuo e assim que possuir atualizo esse post. Da mesma forma, se surgirem novas diferenças entre as “versões Studio”, esse espaço será atualizado.

PS: se alguém tiver percebido mais algum comportamento estranho, fique a vontade para compartilhar, os comentários estão aí pra isso!

BPM

BPM é o acrônimo de Business Process Management, que traduzindo para o português seria Gerenciamento de Processos de Negócio.

Definir o termo BPM não é uma tarefa trivial, pois como se trata de um assunto amplo e recente, cabem mil definições, algumas não tão boas, de cunho mais comercial e outras mais simples. Porém acredito que as explicações mais simples, não conseguem dar um overview sobre BPM para uma pessoa leiga no assunto, portanto tentarei usar exemplos e conceitos para tentar passar melhor esse significado.

BPM tem a ver com processos, e BPMS com processos e software. Sendo prático, eu diria que BPM é uma metodologia, um conjunto de boas práticas, com o o intuito de mapear e gerenciar processos de negócio, onde são (ou não) envolvidos clientes, usuários, fornecedores e atividades automáticas (informatizadas), onde o principal objetivo do BPM seria obter uma melhoria desse processo.

Se ainda não ficou muito claro, para facilitar as coisas, darei um exemplo real. Imagine o seguinte cenário:

• Departamento comercial da empresa X identifica que o produto Y é um produto com forte potencial de venda;
• Departamento comercial solicita ao departamento de compra/venda o produto Y;
• Departamento de compra/venda vai em busca de fornecedores fazendo cotação de preços em busca do melhor custo x benefício;
• Departamento de compra/venda define o fornecedor Z como escolhido e esse fica de fazer a entrega dos produtos em 15 dias;
• Na data estipulada, o setor de logística da empresa X, recebe o produto do fornecedor Z e assim comunica ao departamento comercial que este está disponível para venda;
• Departamento comercial da empresa X, então comunica ao departamento de marketing, que nesse caso irá bolar um campanha de divulgação desse novo produto;
• Campanha criada, produto finalmente é lançado.

Repare no fluxo acima e perceba que isso é um processo de negócio, pois ele possui um começo, envolve pessoas, pode envolver outros recursos, tem um objetivo bem definido e provavelmente ocorre com certa frequência. Esse processo pode ser melhorado, se tornar mais eficiente? É provável que sim e é nesse ponto que entram o BPM e o BPMS. O BPM seria uma forma de mapear esse processo, identificar gargalos, pontos falhos afim de melhorá-lo e para isso a ajuda de um (bom) software BPMS é muito importante.

BPMS

BPMS (Bussiness Process Management Software) seria o braço direito do BPM na melhoria do processo exemplificado acima, através do BPMS seria possível modelar esse processo visualmente e com recursos específicos de uma ferramenta BPMS é possível ter métricas e controles de todo fluxo do processo, dessa forma seria possível, por exemplo, simular esse processo de diversas maneiras, criar mecanismos de automação e fornecer relatórios específicos para tomadas de decisão. Tudo isso com o objetivo único e exclusivo da melhoria desse processo.

É difícil falar sobre BPM sem ser um pouco repetitivo, sem deixar a leitura cansativa, pois trata-se de um assunto muito teórico e abstrato, mas a melhor forma de falar sobre BPM é com exemplos, portanto, com o assunto introduzido, no próximo post mostrarei um cenário de um processo real em que estou trabalhando atualmente e a necessidade do uso de uma ferramenta BPMS.

Só para finalizar, BPM hoje em dia é um dos “componentes” que fazem parte de uma arquitetura SOA completa, o que não significa que para ter uma solução SOA eu tenha que fazer o uso do BPM, porém se usados juntos da forma correta, tornam-se uma poderosa dupla na gestão, automatização e melhoria de processos de negócios.