Migration des fragments Java de WebSphere Business Integration Server Foundation BPEL

Cette section concerne les processus BPEL qui contiennent des fragments Java. Elle décrit comment migrer l'ancienne API des fragments Java vers la nouvelle API des fragments Java quand les données qui transitent par l'application sont stockées comme objets SDO (Service Data Objects) Eclipse.

Pour connaître les étapes de migration spécifiques à la transition de WSIFMessage vers SDO, voir la section "Migration des appels des API WSIFMessage vers les API SDO".

Si possible, les fragments sont migrés automatiquement par l'Assistant de migration mais celui-ci ne peut pas les migrer tous. Des étapes manuelles supplémentaires sont nécessaires pour compléter la migration. Pour plus d'informations sur les types de fragments Java devant être migrés manuellement, voir la rubrique sur les restrictions. Chaque fois que l'un de ces fragments est détecté, l'Assistant de migration explique pourquoi il ne peut pas être migré automatiquement et envoie un avertissement ou un message d'erreur.

Le tableau suivant illustre les modifications apportées à l'API et au modèle de programmation de fragments BPEL Java entre la version 5.1 et la version 6.0 de Business Process Choreographer :
Tableau 1. Modifications et solutions concernant la migration des fragments Java de WebSphere Business Integration Server Foundation BPEL
Modification Solution
Les classes de conteneur WSIFMessage ne sont plus générées pour les types de message WSDL et les classes d'aide de bean Java ne sont plus générées pour les types de schéma complexe. Les variables BPEL sont directement accessibles par nom. Notez que les variables BPEL dont la définition de message WSDL possède une seule partie représenteront maintenant directement la partie concernée au lieu d'encapsuler les données. Les variables dont le type de message possède plusieurs parties auront un conteneur DataObject autour des parties (le conteneur dans WebSphere Application Developer Integration Edition était un WSIFMessage).

Etant donné que les variables BPEL peuvent être utilisées directement dans les fragments 6.0, les variables locales ne sont pas aussi nécessaires que dans la version 5.1.

Les méthodes getter spécifiques pour les variables BPEL initialisaient de manière implicite l'objet de conteneur WSIFMessage autour des parties du message. Il n'existe pas d'objet 'conteneur' pour les variables BPEL dont la définition de message WSDL n'a qu'une seule partie : dans ce cas, les variables BPEL représentent directement la partie (lorsque la partie est un type simple XSD, la variable BPEL est représentée en tant que type de conteneur d'objet Java tel que java.lang.String, java.lang.Integer, etc). Les variables BPEL avec des définitions de message WSDL contenant plusieurs parties sont traitées différemment : il existe encore un conteneur autour des parties et ce conteneur DataObject doit être initialisé de manière explicite dans le code de fragment Java 6.0 s'il n'a pas déjà été défini par une opération précédente.

Si des variables locales des fragments 5.1 portaient le même nom que la variable BPEL, des conflits peuvent survenir. Dans la mesure du possible, essayez de résoudre cette situation.

Les objets WSIFMessage ne sont plus utilisés pour représenter les variables BPEL. Si l'une des classes Java personnalisées appelée à partir des fragments Java possède un paramètre WSIFMessage, elle devra être migrée de manière à accepter/renvoyer un DataObject.
Les méthodes getter spécifiques pour les variables BPEL ne sont plus disponibles. Les variables sont directement accessibles par nom. Notez que les variables BPEL dont la définition de message WSDL possède une seule partie représenteront maintenant la partie directement au lieu d'avoir un conteneur autour des données réelles. Les variables dont le type de message possède plusieurs parties auront un conteneur DataObject autour des parties (le conteneur dans WebSphere Application Developer Integration Edition était un WSIFMessage).
Les méthodes setter spécifiques pour les variables BPEL ne sont plus disponibles. Les variables sont directement accessibles par nom. Notez que les variables BPEL dont la définition de message WSDL possède une seule partie représenteront maintenant directement la partie concernée au lieu d'encapsuler les données. Les variables dont le type de message possède plusieurs parties auront un conteneur DataObject autour des parties (le conteneur dans WebSphere Application Developer Integration Edition était un WSIFMessage).
Les méthodes getter non spécifiques pour les variables BPEL qui renvoient un WSIFMessage ne sont plus disponibles. Les variables sont directement accessibles par nom. Notez que les variables BPEL dont la définition de message WSDL possède une seule partie représenteront maintenant directement la partie concernée au lieu d'encapsuler les données. Les variables dont le type de message possède plusieurs parties auront un conteneur DataObject autour des parties (le conteneur dans WebSphere Application Developer Integration Edition était un WSIFMessage).
Notez qu'il existait deux variations de la méthode getVariableAsWSIFMessage :
getVariableAsWSIFMessage(String variableName)
getVariableAsWSIFMessage(String variableName, 
boolean forUpdate)
Pour une activité de fragment de code Java, l'accès par défaut est défini est en lecture-écriture. Vous pouvez activer l'accès en lecture seule en indiquant @bpe.readOnlyVariables dans un commentaire du fragment de code, avec la liste des noms de variables concernées. Par exemple, vous pouvez mettre les variables B et D en lecture seule en procédant comme suit :
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"

Dans le cas d'un fragment de code Java inclus dans une condition, les variables sont en lecture seule par défaut. Vous pouvez les rendre accessibles en en lecture-écriture en indiquant @bpe.readWriteVariables...

Les méthodes setter non spécifiques pour les variables BPEL ne sont plus disponibles. Les variables sont directement accessibles par nom. Notez que les variables BPEL dont la définition de message WSDL possède une seule partie représenteront maintenant directement la partie concernée au lieu d'encapsuler les données. Les variables dont le type de message possède plusieurs parties auront un conteneur DataObject autour des parties (le conteneur dans WebSphere Application Developer Integration Edition était un WSIFMessage).
Les méthodes getter non spécifiques pour les messages des variables BPEL ne sont pas appropriées pour les messages à une seule partie et ont été modifiées pour les messages à plusieurs parties. Migrez vers la méthode getter non spécifique pour les propriétés (DataObject) des variables BPEL.

Notez que pour les variables BPEL dont la définition de message WSDL possède une seule partie, la variable BPEL représente directement la partie et vous devez accéder à la variable directement, sans l'aide d'une méthode getter.

Il existait deux variations de la méthode getVariablePartAsObject :
getVariablePartAsObject(String variableName, 
String partName)
getVariablePartAsObject(String variableName, 
String partName,boolean forUpdate)
Pour les messages à plusieurs parties, une fonctionnalité équivalente est fournie par cette méthode dans la version 6.0 :
getVariableProperty(String variableName, 
QName propertyName);

Dans la version 6.0, il n'est pas question de l'utilisation d'une variable pour l'accès en lecture seule (alors que c'était le cas dans la version 5.1 pour la première méthode ainsi que la deuxième méthode avec forUpdate='false'). La variable est directement utilisée dans le fragment 6.0 et peut toujours être mise à jour.

Les méthodes setter non spécifiques pour les messages des variables BPEL ne sont pas appropriées pour les messages à une seule partie et ont été modifiées pour les messages à plusieurs parties. Migrez vers la méthode setter non spécifique pour les propriétés (DataObject) des variables BPEL.

Notez que pour les variables BPEL dont la définition de message WSDL possède une seule partie, la variable BPEL représente directement la partie et vous devez accéder à la variable directement, sans l'aide d'une méthode setter.

Les appels à la méthode suivante doivent être migrés :
setVariableObjectPart(String variableName, 
String partName, Object data)  
Pour les messages à plusieurs parties, une fonctionnalité équivalente est fournie par cette méthode dans la version 6.0 :
setVariableProperty(String variableName, 
QName propertyName,Serializable value);
Les méthodes getter spécifiques pour les liens partenaires BPEL ne sont plus disponibles. Migrez vers les méthodes getter non spécifiques pour les liens partenaires BPEL.
Les méthodes setter spécifiques pour les liens partenaires BPEL ne sont plus disponibles. Migrez vers les méthodes setter non spécifiques pour les liens partenaires BPEL.
Les méthodes getter spécifiques pour les ensembles de corrélation BPEL ne sont plus disponibles.
Fragment V5.1 :
String corrSetPropStr = 
getCorrelationSetCorrSet-
APropertyCustomerName();
int corrSetPropInt = 
getCorrelationSet-
CorrSetBPropertyCustomerId();
Fragment V6.0 :
String corrSetPropStr = 
(String) getCorrelationSetProperty
(“CorrSetA”, new
QName(“CustomerName”));
int corrSetPropInt = 
((Integer) getCorrelationSetProperty 
(“CorrSetB”, new
QName(“CustomerId”))).intValue();
Paramètre supplémentaire requis pour les méthodes getter non spécifiques pour les propriétés personnalisées d'activité BPEL.
Fragment V5.1 :
String val = 
getActivityCustomProperty(“propName”);
Fragment V6.0 :
String val = 
getActivityCustomProperty
(“name-of-current-activity”, “propName”);
Paramètre supplémentaire requis pour les méthodes setter non spécifiques pour les propriétés personnalisées d'activité BPEL.
Fragment V5.1 :
String newVal = 
“new value”;
setActivityCustomProperty
(“propName”, newVal); 
Fragment V6.0 :
String newVal = 
“new value”;
setActivityCustomProperty
(“name-of-current-activity”, 
“propName”, newVal);
La méthode raiseFault(QName faultQName, Serializable message) n'existe plus. Le cas échéant, migrez vers la méthode raiseFault(QName faultQName, String variableName) ; sinon, migrez vers la méthode raiseFault(QName faultQName) ou créez une nouvelle variable BPEL pour l'objet Serializable.
Tâches associées
Migration des appels des API WSIFMessage vers les API SDO
Référence associée
Restrictions du processus de migration (pour la migration des artefacts source)

Commentaires
(C) Copyright IBM Corporation 2005. Tous droits réservés.