Nos projetos de orquestração BPEL nos quais trabalhei o grande desafio do desenvolvimento é o fato de estarmos tratando da camada de orquestração, e isso presupõe que todos os sistemas envolvidos no processo que está sendo orquestrado já estejam prontos, disponíveis e com todos os seus inputs e outputs definidos.
Mas na vida real a coisa não é bem assim… Mesmo se o processo está claro e definido, nem sempre as mensagens que irão trafegar no seu fluxo estarão. Isso para não falar dos serviços que os sistemas em questão deverão fornecer para a integração e orquestração.
Esse ensaio vai demonstrar uma solução simples para esse problema em tempo de desenvolvimento: a utilização de Unit Tests, que simulam as mensagens que deveriam trafegar no processo.
Certamente a utilização de testes unitários já se justifica pelo seu fim específico, mas em BPEL isso é reforçado pela indisponibilidade de alguns (ou todos os) serviços envolvidos na orquestração.
Lembro que o Oracle SOA Suite possibilita testes unitários com todos os serviços possíveis do componente, como Mediator, Human Tasks e Business Rule. Contudo o foco do nosso teste é fazê-lo num serviço BPEL.
Esse ensaio foi realizado utilizando:
- WebLogic Server Version: 10.3.3.0
- JRockit 1.6.0
- Oracle SOA Suite Version: 11.1.1.3
- Integrações BPEL desenvolvidas utilizando JDev 11.1.1.3
Primeiro passo: criar 2 projetos
O primeiro será um projeto auxiliar síncrono, com um serviço BPEL que, no nosso caso, simplemente receberá um input e retornará um callback.
O projeto principal também será simples: um composite com o serviço BPEL que receberá um input, chamará o serviço auxiliar como um WebService (ele já deverá ter sido deployed) e retornará para o processo chamador um valor padrão.
O BPEL do projeto principal invoca o serviço auxiliar.
Depois do projeto deployed, vamos executar um teste para verificar se o nosso projeto está funcionando corretamente.
Agora vamos incluir uma suite de testes no nosso projeto. Dentro dela é possível incluir quantos casos de teste quisermos. Nesse ensaio criaremos somente um caso.
- Na lista de arquivos do projeto, clique sobre composite.xml e, na guia Structure, localize a opção Test Suite. Clique com o botão direto sobre essa opção e selecione a opção Create Test Suite.
- Digite o nome da suite de testes.
- Digite o nome do caso de teste.
- Esse procedimento criou um novo composite. Ele é igual ao composite do projeto, mas com detalhes específicos para a criação do nosso caso de teste.
- A partir desse ponto é que entra em cena a criação das condições de teste. A suite permite simular mensagens de entrada e saída de dados, dependendo dos objetivos do teste. Sugere-se que o teste unitário seja utilizado não somente para testar serviços que estão indisponíveis e sim para verificar todos os serviços de um projeto SCA.
- Clique duas vezes sobre o Exposed Service do serviço BPEL. Ele abrirá uma janela para inclusão da mensagem inicial de teste.
- Nessa tela clique em Generate Sample para criar um XML automático com as informações de input do serviço. Se fosse pertinente para o teste, poderia ser adicionado um delay de tempo para o envio da mensagem. Um exemplo para isso é quando sabe-se que existe um tempo para que um determinado serviço assíncrono responda e isso deve ser contemplado no caso de teste. Não será o nosso caso.
- O próximo passo será informar qual é o conteúdo da mensagem que irá trafegar entre os componentes.
- Nesse sentido, podemos dizer que os casos de testes são compostos por:
- inicialização de processos;
- emulação (emulations); e
- afirmações (assertions).
- Para adicionar essas ações a casos de teste é necessário estar em modo ‘teste’ do componente SOA Composite Editor.
- Algumas ações que são possíveis nesses testes:
- criar um processo de inicialização para simular mensagens de entrada na sua aplicação SOA;
- criar emulações para simular entrada ou saída de dados, dados com erro, dados de retorno ou todos os tipos que a sua aplicação SOA recebe do WebService parceiro;
- criar afirmações para validar a mensagem inteira de um arquivo XML inteiro ou uma parte da mensagem, simulando a execução de um processo.
- Vamos criar uma assertion. Clique duas vezes sobre a linha de ligação entre o exposed service e o serviço BPEL. Ou então clique com o botão direito sobre a linha e em seguida em Create Wire Actions:
- Clique no botão para adicionar uma assertion.
- Clique em Generate Sample para gerar um XML baseado no payload da mensagem. Nesse passo seria possível alterar o tipo de assertion para Output, Callback ou Fault, dependendo do caso de teste. Também seria possível comparar de duas maneiras: idêntica ou semelhante.
- Aparecerá, no composite do test case, uma seta indicando que existe uma condição para a mensagem de entrada do processo.
- Nesse ponto estamos simulando somente a mensagem de entrada. Já é possível executar o teste unitário. Para tanto é necessário fazer o deploy e abrir o Enterprise Manager para executarmos o test case.
- Note que o resultado do teste ser Failed.
- Descendo a barra de rolagem será possível ver o valor de entrada e o valor esperado. E realmente o erro era esperado. Foi inserido no valor inicial do processo o valor “input value” e no assertion somente “value”.
- Vamos repetir o teste. Porém antes vamos corrigir o valor da entrada do processo para “value”. E o resultado também será “Passed”
- Seguindo na mesma linha é possível simular as mensagens de entrada e saída de todos os serviços dos componentes. Na imagem abaixo é possível visualizar como o composite fica no caso de serem incluídas mensagens de testes no input e no output dos serviços.
Sugere-se sempre utilizar os testes unitários em todas as soluções desenvolvidas para BPEL (ver TDD). E para saber mais detalhes sobre implementações de testes unitários, veja o manual da Oracle.
