Outra utilidades do Maven é o gerenciamento de dependências da aplicação, pois uma vez que sua aplicação use outras bibliotecas, não se faz por necessário incluir os devidos JARs no repositório da aplicação, basta apenas informar isso no Maven e deixar que ele se encarregue de encontrar essas bibliotecas e baixar para sua máquina.

No caso do ALBPM (Aqualogic BPM), temos um cenário um pouco diferente, pois no final das contas tudo que é gerado são arquivos XML com as informações dos seus processos, então nesse caso usamos o Maven apenas para geração de pacotes. No ALBPM, um pacote nada mais é que o diretório da aplicação compactado (zipado) com uma extensão específica, no caso *.exp, deve-se considerar ainda a exclusão de alguns diretórios na geração do pacote, pois esses diretórios são gerados em tempo de compilação pela engine do ALBPM. Baseado nisso, criei uma configuração do Maven que será responsável pela geração de pacote de um projeto no ALBPM.

Usei ainda uma integração do Maven com o Ant, através de um plugin específico do Maven, onde o Ant será responsável por realizar algumas rotinas bem específicas, como renomear o arquivo gerado e apagar diretórios que não serão usados.

Vale ressaltar que eu testei essa rotina apenas para o ALBPM na versão 6.*, no caso da versão 5.*, acho que não deve mudar muita coisa, mas a extensão do pacote gerada é diferente, portanto será necessário algumas adaptações para que essa rotina funcione também nessa versão. No caso das versões já com a Oracle como responsável pelo produto (OracleBPM), essa rotina também deverá funcionar sem problemas.

Criando o POM do Maven

Como nosso projeto do ALBPM possui apenas um único módulo, será necessário a criação apenas de um único arquivo *.pom, que no caso será o responsável por incluir os plugins que serão usados, além de chamar um arquivo com algumas tasks do Ant. Dessa forma, o arquivo POM fica assim:

A idéia aqui não estar explicando o que é um POM, sua estrutura, como funciona, etc, a idéia é apenas mostrar como criar um POM com o intuito de gerar pacotes do ALBPM.

Explicando o POM utilizado

No começo do nosso POM temos algumas informações obrigatórias que o Maven exige, portanto acho que não vale a pena citá-las, dessa forma partindo para a declaração das propriedades ( ), nós temos:

packageName – Nome do diretório da aplicação
packageDirectory – Diretório onde deverá ser gerado o pacote
packageExtension – Extensão do pacote a ser gerado

Na parte da declaração de plugins, nós declaramos os dois plugins que utilizaremos: maven-assembly-plugin (será o responsável por gerar o arquivo compactado, excluir os diretórios não desejados, etc) e maven-antrun-plugin (será o responsável por fazer algumas tarefas pontuais como renomear o arquivo compactado e deletar os diretórios não utilizados e que são gerados pelo plugin anterior).

No caso do plugin maven-assembly-plugin, associamos ainda um descriptor, que é um arquivo XML que contém todas as rotinas que esse plugin deverá executar e que possui o seguinte conteúdo:

No conteúdo acima, especificamos no elemento
o formato do arquivo a ser gerado, no caso um zip. No elemento informamos ao plugin que não queremos que ele inclua o diretório base no arquivo zip a ser gerado. No elemento definimos uma série de regras que o arquivo a ser zipado deverá obedecer: no primeiro elemento () informamos qual diretório deverá ser zipado, repare que nesse caso usamos os valores das propriedades definido no arquivo POM do Maven. No segundo elemento, no caso , informamos que NÃO queremos que o plugin inclua os diretórios que não possuem arquivos, ou seja, não queremos diretórios em branco. No terceiro elemento (), informamos ao plugin quais são os diretórios e arquivos que NÃO devem ser incluídos no arquivo zip a ser gerado, nesse caso não queremos incluir nenhum diretório/arquivo do SVN, não queremos incluir o JAR fuego.portal, assim como não queremos incluir os diretórios build e system, pois eles são gerados pela IDE em tempo de compilação e não são necessários para nosso pacote.

Explicando o arquivo Ant

No nosso POM, declaramos o plugin maven-antrun-plugin, que será o plugin responsável por executar tasks do Ant.

Ainda no arquivo POM, definimos algumas propriedades que o arquivo Ant deverá conhecer, ou seja, ele irá herdar as propriedades que definimos no POM, bem como definimos qual é o arquivo XML que conterá as taks do Ant a serem executadas, no nosso caso esse arquivo é o maven-setup.xml.

O arquivo maven-setup.xml conterá duas rotinas: uma que é renomear o zip gerado, para ao invés de possuir a extensão .zip, possuir a extensão .exp (propriedade definida no POM e herdada no arquivo Ant), e outra rotina deverá ser remover o diretório target, que é gerado pelo maven-assembly-plugin e que no nosso caso não teria nenhuma utilidade. Dessa forma o conteúdo do nosso arquivo Ant ficou assim:

Repare, que no arquivo Ant usamos as propriedades definidas no nosso POM do Maven e usamos ainda o elemento para termos informação do que o Ant está fazendo.

Resumindo

Usando apenas 3 arquivos (pom.xml, assembly-descriptor.xml, maven-setup.xml) nós temos nosso pacote do ALBPM sendo gerado pelo Maven e pronto para ser deployado na versão enterprise do ALBPM.

Agora basta apenas um mvn install na linha de comando para geração do pacote.

Mais informações

Começando com o Maven

Maven Assembly Plugin

Maven AntRun Plugin

Maven Lifecycle

Ou seja, é muito importante sabermos que essa API existe e principalmente sabermos como usá-la. Existem duas maneiras de usá-la: externa e internamente. Externamente isso pode ser feito usando o PAPI-WS, que são serviços expostos pelo próprio ALBPM para que se possa usar o PAPI, porém um pouco limitado. Outra opção é usando a JAVA API, que é mais completa. Dentro do ALBPM usamos diretamente a Java API através do Catálogo de API’s da ferramenta.

Criando e Recuperando Instâncias de Processos

Fiz um exemplo de código bem simples no ALBPM para poder apresentar como criar instâncias e recuperar instâncias de processos. Seguem os dois exemplos com os respectivos comentários:

Criando Instâncias
Para criar instâncias é muito simples, basta usarmos o método create da API ProcessInstance, passando como parâmetros o ID do processo (sempre com “/” na frente), os argumentos de incialização (caso existam), e o nome do método de inicialização, que pode ser visto através da opção “argument mapping” do evento de inicialização. Segue o código:

Recuperando Instâncias
Para recuperar instâncias também é muito simples, mas devemos ter atenção com a autenticação no DirectoryService onde o projeto correspondente a instância a ser recuperada está deployado.

Esse passo é necessário, pois para recuperar instâncias é usada outra API, no caso a API ProcessService e para tal precisamos autenticar no DirectoryService antes de tentar recuperar a instância de fato.

Para autenticação no DirectoryService, usamos o método connectTo da API ProcessService, e esse método espera 3 parâmetros: A URL do DirectoryService (pode-se usar as constantes como no exemplo abaixo), o usuário e a senha. O usuário e a senha devem possuir a role onde a atividade de criação da instância está associada.

Agora para visualizar o resultado, basta o seguinte código:

Para apresentação, criei um projeto piloto “empréstimo bancário” onde é possível mostrar os conceitos mais básicos do ALBPM. Como imagino existirem mais pessoas com tal necessidade, irei disponibilizar o download do projeto, bem como o script SQL necessário para criação da tabela usada no projeto.

Os tópicos abordados na apresentação foram:

- O que é BPM e BPMS?

- SVN

Download do projeto.

Download do script SQL.

PS: O projeto não disponibiliza todos os tópicos abordados e citados acima, mas quase todos.

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:

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:

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:

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.

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!