Na aplicação web do projeto que estou trabalhando, nós fazemos o uso da API Commons Logging do Apache para poder fazer logging da aplicação, só que para o log aparecer corretamente no console existe um pequeno “macete”, que por incrivel que pareça não diz com mais detalhes na documentação do Weblogic.

O probleminha era, que por mais que eu fizesse o seguinte:

public class SovWS {
 
	private static Log log =  LogFactory.getLog("SOV-"+SovWS.class);
 
	@WebMethod
	public SaveMetaResponseDocument saveMeta(SaveMetaRequestDocument request) {		
		log.info(this.getClass() + " iniciando a nova meta");
               ....
        }
}

Eu não conseguia fazer com que a mensagem de log aparecesse no console do Workshop, ainda que tudo estivesse correto.

Para resolver é muito simples, basta ir nas propriedades do projeto, ir nos facets do projeto e verificar se a extensão Weblogic Integrated Commons Logging está como um facet do projeto, se não estiver, está aí o problema e para resolver basta adicionar esse novo facet.

Para ter certeza que está tudo certinho, sugiro abrir o arquivo weblogic-application.xml e verificar se a seguinte configuração está presente:

<wls:library-ref>
    <wls:library-name>wls-commonslogging-bridge</wls:library-name>
    <wls:specification-version>1.0</wls:specification-version>
    <wls:exact-match>true</wls:exact-match>
</wls:library-ref>

Se a seguinte configuração estiver presente, pronto, tudo ok! Agora o log deverá aparecer no console sem problemas.

PS: Só para ressaltar que essa dica é válida para ambiente de desenvolvimento.

Usando JSP, um novo leque de opções passou a existir e uma dessas opções passou a ser a possibilidade de usar Ajax. Ajax, para quem nunca ouviu falar, não é uma linguagem, uma API, tão pouco um framework, Ajax é o acrônimo de Asynchronous Javascript And XML e nada mais é que um conjunto de técnicas usadas para criar aplicações web interativas (RIA). Um dos pilares do Ajax é permitir comunicação assíncrona entre cliente e servidor utilizando requisições HTTP.

O Oracle BPM oferece uma maneira bem interessante de usar Ajax nas páginas JSP, mesmo não sendo nativa e também não tendo nada a respeito dizendo na documentação, é possível fazer a integração da camada de apresentação de um processo BPM com o próprio processo de uma maneira bem tranquila.

Para exemplificar isso melhor, criei um projeto bem simples no Oracle BPM, que na verdade só serve para mostrar como funciona essa integração entre páginas JSP e métodos dentro de um BPM Object através de Ajax.

Primeiros passos

Para começar, criei um BPM Object bem simples, que possui 3 atributos: name (String), mail (String), documents (String[]). Os dois primeiros atributos, que representam o nome e o email de alguém, são do tipo String e o terceiro atributo, que no caso representa os documentos de uma pessoa, é do tipo Array de String. Chamei esse objeto de: BpmObject.

Nesse mesmo objeto (BpmObject), criei ainda um método, esse método será responsável por retornar os documentos de um usuário. Na verdade esse é o método que irei chamar via requisição Ajax através de uma página JSP. O nome desse método ficou definido como getDocuments().

No futuro precisarei alterar esse objeto, mas eu explico depois.

Criando a página JSP

No Oracle BPM, para informar que a apresentação de determinado BPM Object deva se dar por meio de uma página JSP, se faz por necessário a utilização de Screenflows. Screenflow é um fluxo semelhante ao de um processo normal, mas a principal diferença é que o mesmo é executado por um participante único, ou seja, dentro de um Screenflow não existem lanes.

Após ter criado um processo normal, apenas com uma atividade do tipo Global Creation (para criar uma instância do processo) e também com uma Interactive Activity (para apontar para o Screenflow), parti para criação do Screenflow de fato. O Screenflow em questão, será tão simples quanto o processo no qual ele está associado, no caso contará apenas com uma única atividade do tipo Interactive Component Call, que será a responsável por “chamar” uma página JSP associando-a ao BPM Object criado no passo anterior.

Para chamar uma página JSP, se faz por necessária associar um BPM Object a mesma, então nesse caso criei um váriavel de instância do tipo BpmObject (o mesmo criado no primeiro passo) e dei o seu nome de bpmObject. Após isso, criei uma página JSP dentro de: /projetoBPM/webRoot/customJSP/ajaxPage.jsp.

O nome da página em questão é ajaxPage.jsp, e por enquanto ela irá possuir o seguinte código:

<%@ page session="true"%>
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%>
<%@ taglib uri="http://fuego.com/jsp/ftl" prefix="f"%>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Teste Ajax/title>        
        <script type="text/javascript" src="<f:webResources relativePath='js/prototype-1.6.0.3.js'/>"></script>
    </head>
    <body leftmargin="0" topmargin="0">
 
    Teste Ajax
    <br/><br/>
    Nome: <c:out value="${bpmObject.nome}" /> 
    <br/><br/>
 
    <div id="teste"></div>
 
    </body>
 
</html>

Então, relembrando os passos até aqui:

1) Criação de BPM Object com 3 atributos e um método;
2) Criação de processo com uma atividade do tipo Global Creation e outra do tipo Interactive Activity;
3) Criação de Screenflow;
4) Associação (Implementation Type) da Interactive Activity do processo ao Screenflow criado;
5) Criação de atividade do tipo Interactive Component Call no Screenflow;
6) Criação de váriavel de instância no Screenflow com o tipo sendo o mesmo do BPM Object que foi criado no primeiro passo;
7) Definição do Implementation Type da Interactive Component Call como BPM Object Interactive Call;
8) Associação do BPM Object criado como váriavel de instância da Interactive Component Call do Screenflow;
9) Definição da página ajaxPage.jsp como JSP Presentation da Interactive Component Call do Screenflow.

Feito os passos acima, a estrutura do processo está pronta para criação da página JSP que irá fazer a requisição via Ajax a um método do BPM Object que foi criado no primeiro passo.

Fazendo a requisição Ajax e explicando alguns components da taglib do Oracle BPM

Para criação do mecanismo que irá fazer a requisição Ajax, se faz por necessário a utilização da taglib do Oracle BPM, sem ela não seria possível usar Ajax, ou então seria bastante árduo fazer tal integração.

Por exemplo, para incluir a biblioteca Prototype, que no caso será a responsável por fazer o “trabalho sujo” e criar o objeto XMLHttpRequest para fazer a requisição assíncrona, utilizei a tag f:webResources (linha 10). Esta tag inclui os resources inclusos no projeto BPM, sem que seja necessário informar explicitamente o context path da aplicação para inclusão de imagens, CSS ou Javascripts.

Outra tag importante é a f:invokeUrl, que no caso irá gerar a URL para execução de um método dentro de um BPM Object. Dessa forma, a página JSP precisa ser alterada, pois agora irá contar com uma função Javascript que irá fazer a chamada via Ajax ao método getDocuments() do BPM Object criado no primeiro passo, retornando o output do método para div teste.

Página JSP alterada:

<%@ page session="true"%>
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%>
<%@ taglib uri="http://fuego.com/jsp/ftl" prefix="f"%>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Teste Ajax/title>        
        <script type="text/javascript" src="<f:webResources relativePath='js/prototype-1.6.0.3.js'/>"></script>
        <script>
        function callAjaxMethod () {
		var bpmUrl	='<f:invokeUrl var="bpmObject" methodName="getDocuments" />';		
		return bpmUrl;
	}        
 
	new Ajax.Updater('teste', callAjaxMethod());
        </script>
    </head>
    <body leftmargin="0" topmargin="0">
 
    Teste Ajax
    <br/><br/>
    Nome: <c:out value="${bpmObject.nome}" /> 
    <br/><br/>
 
    <div id="teste"></div>
 
    </body>
 
</html>

Repare que foi criada a função JS callAjaxMethod. Abaixo dessa função existe ainda a função JS Ajax.Updater, que no caso é uma função da biblioteca Prototype que irá fazer a chamada ao método do BPM Object, retornando seu output para a div teste.

Criando um output para o método getDocuments do BPM Object

Finalmente essa é a última parte desse pequeno tutorial. Agora a única coisa que falta é criar um output para o método do BPM Object que irá ser chamado via requisição Ajax.

Antes de mais nada, preciso dizer algo a respeito da tag f:invokeUrl, pois para ela funcionar corretamente existem algumas peculiariades.

Para um método de um BPM Object ser reconhecido por esta tag, ele deve ter uma das quatro assinaturas abaixo:

• methodName(Fuego.Net.HttpRequest request, Fuego.Net.HttpResponse response)
• methodName(java.util.Map requestParameters, java.util.Map requestHeaders)
• methodName(java.util.Map requestParameters)
• methodName()

No caso, eu optei por utilizar a primeira opção, pois para usar a função Ajax.Updater da Prototype, eu preciso escrever diretamente no output do método, ao invés de setar as informações necessárias através dos seus atributos.

Em virtude disso, o método getDocuments do objeto BpmObject agora passará a ter a seguinte assinatura:

getDocuments(Fuego.Net.HttpRequest request, Fuego.Net.HttpResponse response)

Agora, finalmente o código do método getDocuments, que ficará da seguinte maneira:

for (String doc : documents) {
    response.bodyTextContent(arg1 : doc);
}

No código acima, estou percorrendo o atributo documents (array) e imprimindo no output todos os documentos definidos para aquele atributo, dessa forma, quando a função callAjaxMethod é chamada na página JSP, ela automaticamente chama (assincronamente) este método contido dentro do BPM Object, imprimindo todos os documentos definidos para dentro da div com o ID teste.

Conclusão

Utilizando os recursos corretos do Oracle BPM, como sua taglib e seus componentes, não é muito difícil fazer uma tela de apresentação mais interativa usando Ajax. No exemplo acima, foi criado um projeto bem simples, apenas para ilustrar, com o intuito de mostrar a atualização do conteúdo de uma div feita assincronamente através de uma requisição Ajax.

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.

Na parte de apresentação no BPM existem duas opções: presentations e JSP. Em ambos os casos é necessário sempre utilizar um BPM Object para fazer a representação dos dados. Um BPM Object é puramente um objeto e com isso contém atributos e métodos específicos.

No meu caso, tenho trabalhado com JSP para a camada de visualização, já que preciso ir um pouco além do que simplesmente exibir dados. As telas do meu processo precisam um alto nível de customização e também possuem bastantes regras de validação e fluxo no lado do cliente usando Java Script. É também comum no meu processo a utilização de serviços externos, e com isso se faz por necessário apresentar os dados retornados por esses serviços nas minhas páginas JSP. Conforme dito anteriormente, para mostrar esses dados preciso de um BPM Object e para não criar um BPM Object redudante, ou seja, um BPM Object com a estrutura idêntica do XML Object – que já está cadastrado no meu projeto – o que eu fiz foi criar um atributo nesse BPM Object que encapsula um XML Object, dessa forma poderia usar os atributos do XML Object como atributos dentro do meu BPM Object. Algo como um atributo do tipo de uma lista genérica em um objeto java.

Mas qual foi a minha surpresa ao iterar sobre esse atributo do tipo XML Object no meu JSP? Simplesmente não funciona, ou melhor, funciona pela metade! hehe .. deixa eu explicar.

Se eu tenho um BPM Object com a seguinte estrutura:

MyBPMObject
- name (string)
- email (string)
- address (XMLObject)
 
Address (XMLObject)
- zipcode (int)
- city (string)
- state (string)

E no JSP tentar acessar o atributo da seguinte forma:

Nome: <c:out value="${bpmObject.name}"/>
<br/>
Estado: <c:out value="${bpmObject.address.state}"/>

Funciona!

Agora, se o meu XMLObject fosse do tipo array, ou seja, uma lista, não funciona! Vejamos o meu BPMObject alterado para suportar uma lista de endereços (address):

MyBPMObject
- name (string)
- email (string)
- address[] (XMLObject)

No JSP:

Nome: <c:out value="${bpmObject.name}"/>
<br/>
Estado: <c:out value="${bpmObject.address[0].state}"/>

O exemplo acima não funciona, é como se o atributo “address” não existisse! Bizarro! Tentei inclusive usando a própria taglib do BPM e nada!

O que eu tive que fazer? Tcharammm.. criar um BPM Object idêntico ao meu XMLObject e criar um método dentro desse BPM Object que recebe como parâmetro um XML Object, o que ele faz é mapear os valores desse XML Object para os seus próprios atributos… totalmente POG! Mas foi o jeito…

Se alguém souber de algum “pulo do gato”, por favor me informe que eu publico aqui, mas eu sinceramente acho difícil ter alguma mágica, por mais óbvio que seja, não funciona. O mais bizarro ainda, é que se no Screenflow que antecede o JSP eu der um output do objeto da mesma forma que eu estou dando no JSP, funciona, só não funciona mesmo no JSP :(

Fica a dica: não usem XML Object para apresentar dados!

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.