Elementos do BPEL 2.0 que não estão presentes nessa versão
Existem certas limitações nos elementos suportados nessa versão do BPEL Designer. Consulte o BPEL Service Engine User's Guide para obter detalhes sobre as construções e as limitações relacionadas suportadas da linguagem BPEL 2.0.
Usando esquemas BPEL diferentes da especificação BPEL 2.0
Esta versão do BPEL Designer suporta a especificação final BPEL 2.0 e não suporta as especificações anteriores. Isso significa que quando você abre os arquivos BPEL que estão em conformidade com as versões anteriores da especificação, o BPEL Designer mostra a mensagem Unable to Show the Diagram (Impossível mostrar o diagrama).
Se aparecer essa mensagem, faça o seguinte:
Verifique a versão da especificação com a qual o arquivo BPEL é compilado. Os arquivos BPEL que estão em conformidade com a especificação BPEL 2.0 possuem a seguinte string:
Substitua os namespaces em seus arquivos por aqueles acima e tente abrir o arquivo BPEL no BPEL Designer.
Verifique se as construções BPEL usadas em seu processo são compatíveis com a especificação BPEL 2.0.
Conflito de ponto de extremidade de serviço
Ao implantar dois ou mais projetos de aplicação composta, pode haver um conflito de ponto de extremidade de serviço e o deployment falhar. Em caso de conflito de ponto de extremidade de serviço, a mensagem seguinte será exibida:
Deploy service assembly failed. (partial success)
MESSAGE: (SOAPBC_DEPLOY_2) Failed to deploy: java.lang.Exception:
An activated endpoint already has the same SOAP Address location:
http://localhost:18181/SynchronousSample
C:\<...>\SynchronousSample1Application\nbproject\build-impl.xml:209:
Service assembly deployment failed.
BUILD FAILED (total time: 31 seconds)
Geralmente, isso acontece devido à tentativa de implantar processos praticamente idênticos que são empacotados em projetos de aplicação composta distintos. A solução alternativa para esse problema é usar pontos de extremidade diferentes durante o deployment de projetos de aplicação composta distintos.
Explicação: embora você esteja implantando aplicações compostas distintas e processos BPEL diferentes, por padrão, eles terão os mesmos endereços de ponto de extremidade definidos em seus arquivos SynchronousSample.wsdl. Ambos conterão o seguinte endereço de ponto de extremidade:
Se você tentar implantar duas aplicações compostas (por exemplo, SynchronousSampleApplication e SynchronousSample1Application com pontos de extremidade de serviço idênticos, o deployment da segunda aplicação composta falhará devido ao conflito de ponto de extremidade.
Talvez você queira implantar mais de uma versão da aplicação composta porque deseja fazer modificações em um ou em ambos os processos, e implantar ambos ao mesmo tempo. Ou você pode comparar o comportamento deles. Para fazer isso, você deve primeiro tornar seus endereços de ponto de extremidade distintos. Isso significa editar o arquivo wsdl do processo e ajustar o atributo soap:address location para que não haja conflito. Você pode ajustar o número da porta ou o nome do serviço. Por exemplo, qualquer um destes seria suficientemente distinto do original:
Relação de ponto de extremidade de serviço com casos de teste
Cada caso de teste na aplicação composta tentará enviar a mensagem de entrada para o processo de destino quando você chamar a ação Teste. Para saber para onde enviar a mensagem, cada caso de teste possui uma propriedade chamada destino. Você pode modificar essa propriedade na janela Propriedades. Para chamar a janela Propriedades, clique com o botão direito do mouse no nó do caso de teste e escolha Propriedades na janela pop-up.
O valor da propriedade de destino é definido no momento em que o caso de teste é criado. Sendo assim, se você alterar depois o ponto de extremidade de serviço, será necessário ajustar manualmente o atributo de destino de quaisquer casos de teste gerados anteriormente. Obviamente, os casos de teste gerados recentemente estarão OK.
Portas
Porta HTTP do servidor da aplicação GlassFish V2
Por padrão, o instalador tenta configurar a porta HTTP do servidor da aplicação como 8080. Alguns dos processos de amostra presumem o valor 8080. Se por algum motivo a porta HTTP do servidor de arquivos não for 8080, você terá que fazer ajustes nas amostras.
Em especial, a amostra Serviço de reserva de viagens necessitará de alguns ajustes.
Presuma, por exemplo, que o servidor da aplicação esteja escutando na porta HTTP 8090 (não na padrão 8080). Neste caso, você terá que fazer o seguinte:
Ajustar os arquivos WSDL dos serviços de parceiro de reserva
No projeto do módulo BPEL TravelReservationService, altere o valor do endereço de soap em AirlineReservationService.wsdl de
Atualize também os valores de endereço de soap no VehicleReservationService.wsdl e HotelReservationService.wsdl.
Observação: para descobrir em qual porta HTTP o servidor da aplicação está escutando, abra a janela Serviços, clique com o botão direito do mouse no nó Servidor da aplicação GlassFish V2 e escolha Exibir console de administração. Isso abre o console de administração do servidor da aplicação GlassFish V2 no navegador. Digite o nome de usuário e a senha (os valores padrão são admin/adminadmin) e faça logon. Clique em Servidor da aplicação no painel esquerdo e escolha a aba Geral no painel direito. O valor da porta HTTP de que você precisa é o primeiro na linha Porta(s) HTTP:
Como alternativa, localize as linhas seguintes no registro do servidor da aplicação:
WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8080
WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8181
WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 4848
O valor de que você precisa está na primeira linha.
Conflito de ponto de extremidade do serviço de reserva de viagens
Consulte a seção Conflito de ponto de extremidade de serviço acima para obter uma descrição geral do problema. Entretanto, no caso da amostra Serviço de reserva de viagens, você deve seguir estas etapas adicionais:
Se a porta 18181 não estiver disponível, e se você quiser executar o TRS em outra porta, tal como 19191, siga as etapas seguintes:
Atualize também a URL de airlineReserved, hotelReserved e vehicleReserved.
Ajustar o projeto EJB do parceiro, ReservationPartnerServices
Realize as seguintes etapas:
No IDE, abra o projeto ReservationPartnerServices.
(O IDE criou o projeto ReservationPartnerServices no local em que você criou o projeto TravelReservationService).
Na janela Projetos, expanda o nó do projeto ReservationPartnerServices, expanda o nó Arquivos de configuração, e clique duas vezes no nó ejb-jar.xml para abrir o arquivo no editor visual.
Na visualização Design, em Enterprise Beans, clique em ReservationCallBackProviderMDB para expandir a entrada. Expanda Ambiente do Bean e Entradas do ambiente.
Em Entradas do ambiente, selecione cada entrada e clique em Editar para alterar o número da porta 18181 no campo Valor de entrada.
Se o arquivo Output.xml estiver vazio (ele fica vazio depois que um novo caso de teste é criado), você será solicitado a decidir se Output.xml deve ser preenchido com a resposta da primeira execução de teste. Essa primeira saída da execução de teste indicará se houve falha.
Se o arquivo Output.xml não estiver vazio, os resultados obtidos serão comparados com o conteúdo desse arquivo; caso coincidam, ficará marcado que a execução de teste passou.
Falhas da execução de teste
Se você receber uma execução de teste falha, adote um dos procedimentos seguintes:
Verifique a mensagem da resposta depois de uma execução de teste falha. A mensagem da resposta está disponível no nó do caso de teste na janela Projetos. A mensagem da resposta possui carimbo de data e hora.
Você pode verificar se a resposta não corresponde ao esperado (ou seja, Output.xml) e talvez isso o ajude a entender o problema.
Verifique o arquivo de registro do servidor após uma execução de teste falha.
Para fazê-lo, vá para a aba Tempo de execução do IDE. Selecione a ação Exibir registro do servidor no nó Servidor da aplicação GlassFish V2.
Isso mostra o conteúdo do registro do servidor e talvez contenha informações sobre o motivo da falha da execução de teste.
Um caso específico de falhas de execução de teste está relacionado a testes que usam correlações baseadas em conteúdo incorporadas no Input.xml (por exemplo, os arquivos Input.xml nos casos de teste do Serviço de reserva de viagens têm <UniqueID>...</UniqueID> como a base da correlação). Nesta situação, se você executar o caso de teste quando já houver uma instância do processo em execução iniciada pelo mesmo caso de teste, a segunda instância do processo não será iniciada e o teste falhará. A mensagem seguinte será exibida no registro do servidor da aplicação GlassFish V2:
Exception occurred while executing a business process instance. (Ocorreu uma exceção ao executar uma instância do processo comercial).
com.sun.jbi.engine.bpel.core.bpel.exception.CorrelationAlreadyExists: An instance is associated with the correlation (uma instância é associada à correlação)
<...>
Desativando firewalls ao usar servidores
Talvez você queira desativar o firewall para que possa implantar, executar, depurar ou testar aplicações com êxito no servidor da aplicação ou processos comerciais no servidor BPEL.
Uso necessário do conjunto de correlações não detectado pelo sistema de validação
O mecanismo de serviço BPEL requer o uso preciso dos conjuntos de correlações. Atualmente, o sistema de validação não detecta violações dos seguintes requisitos:
On Message: o elemento On Message deverá ter um filho <correlations> válido se On Message for usado em uma atividade Selecionar que não tenha o atributo createInstance="yes".
Receber: o elemento Receber deverá ter um filho <correlations> válido caso não tenha o atributo createInstance="yes".
On Event: O elemento On Event deve ter um filho <correlations> válido.
Consulte as Notas de versão do NetBeans IDE 6.0 para saber de outros problemas conhecidos do SOA pack.
