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.
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. |
|
Paramètre supplémentaire requis pour les méthodes getter non spécifiques pour les propriétés personnalisées d'activité BPEL. |
|
Paramètre supplémentaire requis pour les méthodes setter non spécifiques pour les propriétés personnalisées d'activité BPEL. |
|
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. |