Migrando Snippets Java do BPEL do WebSphere Business Integration Server Foundation

Para processos BPEL que contenham snippets Java, esta seção detalha como migrar da API de snippet Java antiga para a nova API de snippet Java na qual os dados que fluem pelo aplicativo são armazenados como SDOs (Service Data Objects) do Eclipse.

Consulte a seção "Migrando das Chamadas da API WSIFMessage para APIS do SDO" para obter as etapas de migração para executar ações específicas à transição do WSIFMessage para o SDO.

Sempre que possível, os snippets são migrados automaticamente pelo assistente de migração, mas existem snippets que o assistente de migração não pode migrar totalmente. Isto requer etapas manuais extras para concluir a migração. Consulte o tópico Limitações para obter detalhes sobre os tipos de snippets Java que devem ser migrados manualmente. Sempre que um desses snippets for encontrado, o assistente de Migração explicará por que ele não pode ser migrado automaticamente e emitirá uma mensagem de aviso ou de erro.

A seguinte tabela detalha as alterações no modelo de programação e na API do snippet Java do BPEL do Process Choreographer versão 5.1 para 6.0:
Tabela 1. Alterações e Soluções para Migrar os Snippets Java do BPEL do WebSphere Business Integration Server Foundation
Alterar Solução
As classes do wrapper baseadas no WSIFMessage não são mais geradas para tipos de mensagens do WSDL, nem são as classes do assistente do Java bean geradas para os tipos de esquema complexos. As variáveis BPEL podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).

Como as variáveis BPEL podem ser utilizadas diretamente nos snippets 6.0, há menos necessidade de variáveis locais do que havia na 5.1.

Os getters altamente especificados para as variáveis BPEL inicializavam implicitamente o objeto do wrapper WSIFMessage em torno das partes da mensagem. Não há nenhum objeto ‘wrapper’ para as variáveis BPEL cuja definição de mensagem do WSDL tem apenas uma única parte: nesse caso, as variáveis BPEL representam diretamente a parte (No caso em que a única parte é um tipo simples XSD, a variável BPEL será representada como o tipo de wrapper do objeto Java, como java.lang.String, java.lang.Integer, etc). As variáveis BPEL com definições de mensagens do WSDL de várias partes são manipuladas de forma diferente: ainda há um wrapper em torno das partes e esse wrapper DataObject deve ser explicitamente inicializado no trecho de código Java 6.0 se ainda não tiver sido definido por uma operação anterior.

Se qualquer variável local dos snippets da 5.1 tiver o mesmo nome da variável BPEL, poderão ocorrer conflitos; portanto, tente remediar essa situação, se possível.

Os objetos WSIFMessage não são mais utilizados para representar variáveis BPEL. Se qualquer classe Java customizada chamada a partir dos snippets Java tiver um parâmetro WSIFMessage, ela precisará ser migrada de forma que aceite/retorne um DataObject.
Os métodos getter altamente especificados para variáveis BPEL não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, agora representarão diretamente a parte em vez de ter um wrapper em torno dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).
Os métodos setter altamente especificados para variáveis BPEL não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).
Os métodos getter pouco especificados para variáveis BPEL que retornam um WSIFMessage não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).
Observe que há duas variações do método getVariableAsWSIFMessage:
getVariableAsWSIFMessage(String variableName)
getVariableAsWSIFMessage(String variableName,
 boolean forUpdate)
Para uma atividade de snippet Java, o acesso padrão é de leitura/gravação. É possível alterá-lo para de leitura especificando @bpe.readOnlyVariables com a lista de nomes das variáveis em um comentário no snippet. Por exemplo, você pode configurar a variável B e a variável D como de leitura da seguinte forma:
variableB.setString("/x/y/z", variableA.getString("/a/b/c")); // @bpe.readOnlyVariables names="variableA"
variableD.setInt("/x/y/z", variableC.getInt("/a/b/c")); // @bpe.readOnlyVariables names="variableC"

Além disso, se você tiver um snippet Java em uma condição, as variáveis serão de leitura por padrão, mas será possível torná-las de leitura/gravação especificando @bpe.readWriteVariables...

Os métodos setter pouco especificados para variáveis BPEL não estão mais disponíveis. As variáveis podem ser acessadas diretamente pelo nome. Observe que, para variáveis BPEL cuja definição de mensagem WSDL possui uma única parte, estas variáveis agora representarão diretamente a parte em vez de ter um wrapper ao redor dos dados reais. As variáveis cujo tipo de mensagem tem várias partes terão um wrapper DataObject em torno das partes (em que o wrapper no WebSphere Application Developer Integration Edition era um WSIFMessage).
Os métodos getter pouco especificados para partes de mensagem das variáveis BPEL não são adequados para mensagens de uma única parte e foram alterados para mensagens de várias partes. Migre para o método getter pouco especificado para as propriedades das variáveis BPEL (DataObject’s).

Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, a variável BPEL representa diretamente a parte e deve ser acessada diretamente sem utilizar um método getter.

Há duas variações do método getVariablePartAsObject:
getVariablePartAsObject(String variableName, String
 partName)
getVariablePartAsObject(String variableName, String
 partName,boolean forUpdate)
Para mensagens de várias partes, a funcionalidade equivalente é fornecida para esse método na 6.0:
getVariableProperty(String variableName, QName propertyName);

Na 6.0, não há nenhuma noção da utilização de uma variável para acesso de leitura (que era o caso na 5.1 para o primeiro método acima, bem como o segundo método com forUpdate='false'). A variável é diretamente utilizada no snippet da 6.0 e está sempre apta para ser atualizada.

Os métodos setter pouco especificados para partes de mensagem das variáveis BPEL não são adequados para mensagens de uma única parte e foram alterados para mensagens de várias partes. Migre para o método setter pouco especificado para as propriedades das variáveis BPEL (DataObject’s).

Observe que para as variáveis BPEL, cuja definição de mensagem do WSDL tem uma única parte, a variável BPEL representa diretamente a parte e deve ser acessada diretamente sem utilizar um método setter.

As chamadas para o seguinte método devem ser migradas:
setVariableObjectPart(String variableName, String
 partName, Object data)  
Para mensagens de várias partes, a funcionalidade equivalente é fornecida para esse método na 6.0:
setVariableProperty(String variableName,
QName propertyName,Serializable value);
Os métodos getter altamente especificados para links de parceiros BPEL não estão mais disponíveis. Migre para os métodos getter pouco especificados para links de parceiros BPEL.
Os métodos setter altamente especificados para links de parceiros BPEL não estão mais disponíveis. Migre para os métodos setter pouco especificados para links de parceiros BPEL.
Os métodos getter altamente especificados para conjuntos de correlações BPEL não estão mais disponíveis.
Snippet da V5.1:
String corrSetPropStr =
 getCorrelationSetCorrSetAProperty
CustomerName();
int corrSetPropInt =
 getCorrelationSetCorrSetBProperty
CustomerId();
Snippet da V6.0:
String corrSetPropStr =
 (String) getCorrelationSetProperty
(“CorrSetA”, new  						
QName(“CustomerName”));
int corrSetPropInt =
 ((Integer) getCorrelationSetProperty
(“CorrSetB”, new  			
QName(“CustomerId”))).intValue();
Parâmetros adicionais necessários para os métodos getter pouco especificados para propriedades customizadas da atividade BPEL.
Snippet da V5.1:
String val =
 getActivityCustomProperty(“propName”);
Snippet da V6.0:
String val =
 getActivityCustomProperty
(“name-of-current-activity”, “propName”);
Parâmetros adicionais necessários para os métodos setter pouco especificados para propriedades customizadas da atividade BPEL.
Snippet da V5.1:
String newVal = “new value”;
setActivityCustomProperty
(“propName”, newVal); 
Snippet da V6.0:
String newVal = “new value”;
setActivityCustomProperty
(“name-of-current-activity”, “propName”,
 newVal);
O método raiseFault(QName faultQName, Serializable message) não existe mais. Migre para o raiseFault(QName faultQName, String variableName) onde possível; caso contrário, migre para o método raiseFault(QName faultQName) ou crie uma nova variável BPEL para o objeto Serializable.
Tarefas relacionadas
Migrando Chamadas de API WSIFMessage para APIs SDO
Referências relacionadas
Limitações do Processo de Migração (Para Migração de Artefatos de Origem)

Feedback
(C) Direitos Autorais IBM Corporation 2005, 2006. Todos os Direitos Reservados.