IBM WebSphere WebSphere Integration Developer
Version 6.1
Guide de migration
Version 6.1
Important
Avant d'utiliser le présent document et le produit associé,
prenez connaissance des informations générales figurant à la section Remarques.
Remarque
Certaines illustrations de ce manuel ne sont pas disponibles en français à la date d'édition.
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut
les mises à jour. Les informations qui y sont fournies sont
susceptibles d'être modifiées avant que les produits décrits ne deviennent
eux-mêmes disponibles. En outre, il peut contenir des informations ou des
références concernant certains produits, logiciels ou services non annoncés
dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir
des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles
dans votre pays, ou adressez-vous à votre partenaire commercial.
Vous pouvez également consulter les serveurs Internet suivants :
Compagnie IBM France
Direction Qualité
Tour Descartes
92066 Paris-La Défense Cedex 50
© Copyright IBM France 2008. Tous droits réservés.
© Copyright International Business Machines Corporation 2005, 2007. All rights reserved.
Chapitre 1. Migration vers WebSphere Integration Developer
WebSphere
Integration Developer version 6.1 fournit les outils nécessaires pour migrer votre environnement existant.
Remarque : Les projets WebSphere Integration
Developer 6.0.2 et 6.1 ne peuvent pas être utilisés dans WebSphere Integration Developer 6.0.1.
Après avoir effectué la mise à niveau vers WebSphere Integration Developer 6.0.2 ou 6.1, vous
ne pouvez pas réutiliser les projets dans WebSphere Integration Developer 6.0.1.x.
Aucune prise en charge n'est possible si vous utilisez la version 6.0.2 ou 6.1 pour rechercher du
code dans un référentiel ou exporter des projets que vous voulez ensuite partager avec un utilisateur de WebSphere Integration
Developer 6.0.1.
Les rubriques suivantes décrivent les concepts, les informations de référence et les instructions pas-à-pas pour migrer vers WebSphere Integration Developer :
Chapitre 2. Migration à partir de versions précédentes de
WebSphere
Integration Developer
La migration à partir des versions antérieures de WebSphere Integration Developer vers WebSphere Integration
Developer 6.1 est prise en charge. Il s'agit d'une migration d'une version à une autre.
La migration vers WebSphere Integration Developer 6.1 permet de préserver
la structure de base de votre application existante avec une reconfiguration minimale requise.
Notez que le processus de migration d'une version à une autre n'est associé à aucun
assistant de migration.
Les rubriques suivantes fournissent une assistance supplémentaire
concernant le processus de migration de
WebSphere Integration Developer d'une version à une autre :
Remarques relatives au processus de migration d'une version à une autre
Lorsque vous effectuez une migration d'une version antérieure de WebSphere Integration Developer vers
la version 6.1, une grande partie du processus de migration est faite automatiquement. Toutefois, vous devez prendre en
compte que certains éléments requièrent une configuration manuelle supplémentaire.
Les remarques suivantes sont destinées à vous aider au cours du processus de migration
d'une version à l'autre :
- Adaptateurs
- Les applications qui utilisent un niveau antérieur de l'adaptateur peuvent être migrées rapidement
vers le niveau en cours à l'aide d'un utilitaire. Pour plus d'informations, consultez la rubrique
"Migration d'applications à l'aide de niveaux d'adaptateurs précédents" dans la section associée
ci-dessous.
- Evénements CEI
- Les modèles de surveillance WebSphere
Integration Developer 6.0.2 ne peuvent pas être créés mais ils peuvent être utilisés dans WebSphere Integration
Developer 6.1 s'ils ont déjà été créés.
- Editeur de définition d'événement
- Cet éditeur est déprécié dans WebSphere Integration Developer 6.1.
- Fédération XSD
- La fédération XSD (c'est-à-dire, la génération d'inclusions XSD) a été supprimée dans WebSphere Integration
Developer 6.1. Par conséquent, tous les anciens échanges de projets doivent avoir une inclusion XSD obligatoire
incluse dans l'échange de projet. Cela se fait automatiquement pour les échanges de projets exportés dans WebSphere Integration
Developer 6.0.2.x. Toutefois, pour exporter des échanges de projets depuis la version 6.0.1.2, vous devez explicitement
cocher la case Include derived files (Inclure les fichiers dérivés) lors de
l'exportation.
- Primitives de transformation XSL
- Dans WebSphere Integration
Developer 6.1, la primitive de transformation XSL est dotée d'un nouvel éditeur de mappage XML.
Les mappes XML générées dans une version antérieure doivent être migrées vers
le nouveau format avant de pouvoir être éditées. Pour plus d'informations, consultez la rubrique
"Migration d'une primitive de transformation XSL" dans la section associée ci-dessous.
Niveau des versions de développement et de déploiement
Le choix des niveaux de version nécessaires dans votre environnement
dépend des niveaux de version auxquels vos applications ont été développées.
WebSphere
Process Server 6.1 et
WebSphere
Integration Developer 6.1 sont compatibles avec les éditions précédentes, comme suit as :
Remarque : Pour les systèmes i5/OS,
aucune version antérieure n'a été installée.
- Le déploiement de
WebSphere
Integration Developer 6.0.x.x (où 6.0.x.x fait référence à
6.0.1.x à 6.0.2.x) vers
WebSphere
Process Server 6.1 est pris en charge.
- Les applications créées et générées à l'aide de
WebSphere
Integration Developer 6.0.x.x peuvent être publiées sur les serveurs
WebSphere
Process Server 6.1.
- Les applications créées et générées dans
WebSphere
Integration Developer 6.0.x.x et exportées de celui-ci peuvent être installées sur les
serveurs WebSphere
Process Server 6.1.
- L'exécution d'artefacts de
WebSphere
Process Server 6.1 sur
WebSphere
Process Server 6.0.x.x n'est pas pris en charge.
- Les applications créées avec
WebSphere
Integration Developer 6.1 ne peuvent pas être publiées ou installées sur des serveurs
WebSphere
Process Server 6.0.x.x (toute édition précédente). Un tel contenu ne
s'exécutera pas correctement sur
WebSphere
Process Server 6.0.x.x et les modifications apportées à la génération de code
entraîneront une exécution incorrecte des applications sur
WebSphere
Process Server 6.0.x.x.
- Les applications créées avec
WebSphere
Integration Developer 6.0.x.x et générées dans
WebSphere
Integration Developer 6.1 ne peuvent pas être publiées ou installées sur des serveurs
WebSphere
Process Server 6.0.x.x.
Les modifications apportées à la génération de code entraîneront l'exécution incorrecte des applications
sur WebSphere
Process Server 6.0.x.x.
- Les applications générées à l'aide de serviceDeploy depuis un serveur
WebSphere
Process Server 6.1 ne peuvent pas être installées sur un serveur
WebSphere
Process Server 6.0.x.x.
Les modifications apportées à la génération de code entraîneront l'exécution incorrecte des applications
sur WebSphere
Process Server 6.0.x.x.
Chapitre 3. Migration vers WebSphere Process Server à partir de WebSphere InterChange Server
La migration à partir de WebSphere InterChange Server vers WebSphere Process Server est prise en charge via les fonctions suivantes de WebSphere Integration Developer.
Remarque : Reportez-vous aux notes d'édition pour plus d'informations sur les restrictions liées à la migration dans cette édition de WebSphere Process Server.
- Migration automatique d'artefacts source via les outils de migration pouvant être appelés à partir des éléments suivants :
- Le menu
Fichier -> Importer -> Business
Integration de WebSphere
Integration Developer
- La page d'accueil de
WebSphere
Integration Developer
- L'utilitaire de ligne de commande reposMigrate
- La prise en charge native lors de l'exécution de plusieurs API de WebSphere InterChange Server
- La prise en charge de la technologie WebSphere Business Integration Adapter actuelle, de sorte que les adaptateurs existants soient compatibles avec WebSphere Process Server
Bien que la migration d'artefacts source soit prise en charge, il est recommandé d'effectuer une analyse et des tests exhaustifs pour déterminer si les applications résultantes fonctionneront comme prévu dans WebSphere Process Server, ou si elles devront être à nouveau modifiées après la migration. Cette recommandation se base par rapport aux restrictions suivantes de parité fonctionnelle entre WebSphere InterChange Server et cette version de WebSphere Process Server. Il n'existe aucune prise en charge de cette version de WebSphere Process Server qui soit équivalente à ces fonctions WebSphere Interchange Server :
- Group Support
- Hot Deployment/Dynamic Update
- Scheduler - Pause Operation
- Security - Auditing
- Security - Fine Grain RBAC
- Les descripteurs de sécurité (Security Descriptors) ne sont pas migrés
Chemins de migration pris en charge pour WebSphere InterChange Server
Les outils de migration de WebSphere Process
Server prennent en charge la migration à partir des versions 4.2.2 ou ultérieures de WebSphere
InterChange Server.
Toute version de WebSphere InterChange Server
antérieure à 4.2.2 devra d'abord migrer vers la version
4.2.2 ou 4.3 avant de migrer vers WebSphere Process Server.
Avant de migrer vers WebSphere Process Server depuis WebSphere InterChange Server, vous devez vérifier que vous avez bien préparé votre environnement. WebSphere Process Server fournit les outils nécessaires pour migrer depuis WebSphere InterChange Server.
Ces outils de migration peuvent être appelés à partir :
- Du menu
Fichier -> Importer -> Business
Integration de WebSphere
Integration Developer
- De la page d'accueil de
WebSphere
Integration Developer
L'entrée dans les outils de migration est un fichier de référentiel jar exporté à partir de WebSphere Interchange Server. Avant d'accéder à ces outils de migration avec ces options, vous devez d'abord :
- Vérifiez que vous exécutez une version de WebSphere InterChange Server
pouvant être migrée vers WebSphere Process Server. Voir la rubrique "Chemins de migration pris en charge pour WebSphere
InterChange Server".
- exporter vos artefacts source depuis
WebSphere
InterChange Server dans un fichier de référentiel .jar à l'aide de la commande de
WebSphere
InterChange Server repos_copy (voir la documentation de
WebSphere
InterChange Server). L'assistant
requiert un fichier JAR du référentiel WebSphere InterChange Server en tant qu'entrée.
Ce fichier JAR doit être intégré indépendamment selon les applications
migrées. C'est-à-dire que tous les artefacts référencés par l'un des artefacts du
fichier JAR doit également être intégré à ce fichier. Pour vérifier que le fichier JAR
du référentiel généré est intégré indépendamment, exécutez la commande repos_copy
avec l'option -vr avant d'exporter le référentiel de serveur (cela permet de valider
le référentiel). Si le référentiel est valide, repos_copy écrit
la sortie suivante dans la console : Validation Succeeded. All Dependencies
Resolved. Si le référentiel n'est pas valide, repos_copy imprime
une liste des dépendances à résoudre. Résolvez les dépendances
avant d'exporter le référentiel. Exportez les artefacts du référentiel et créez
le fichier JAR du référentiel à l'aide de la commande repos_copy de WebSphere InterChange Server
avec l'option -o (Pour plus d'informations, consultez la documentation de WebSphere InterChange Server 4.3,
y compris les informations sur l'exportation des composants individuels).
Remarques relatives au processus de migration de
WebSphere
InterChange Server
Les remarques suivantes sont destinées à vous aider lors du développement
d'artefacts d'intégration pour WebSphere InterChange Server. En vous y conformant, vous pourrez effectuer la migration d'artefacts WebSphere InterChange Server vers WebSphere Process Server avec beaucoup plus de facilité.
Ces recommandations sont uniquement destinées à vous guider. Parfois, il
peut être nécessaire de procéder différemment de ces instructions. Dans ce cas, limitez le plus possible les différences de procédure lorsque vous effectuez la migration des artefacts, afin d'alléger les tâches nécessaires après l'opération. Notez que ces instructions
n'englobent pas les remarques relatives au développement d'artefacts WebSphere InterChange
Server en général. Elles se limitent aux remarques
pouvant affecter la facilité de migration d'artefacts.
Remarques : développement général
Plusieurs considérations s'appliquent largement à la plupart des artefacts d'intégration. En règle générale, les artefacts qui exploitent les fonctions de l'outil et qui sont conformes aux modèles de métadonnées appliqués par ce dernier sont les plus simples à migrer. En revanche, ceux possédant des extensions importantes et des dépendances externes peuvent nécessiter une intervention manuelle lors de leur migration.
La liste suivante récapitule les remarques relatives au développement général de solutions basées
sur WebSphere
InterChange Server,permettant de faciliter les opérations de migration :
- Documentez la conception du système et des composants
- Utilisez l'outil de développement pour éditer les artefacts d'intégration
- Optimisez les suggestions pour définir des règles d'outil et de fragments
Java
Pour utiliser des solutions d'intégration, il est important de bien suivre l'architecture
et le modèle de programmation fournis par WebSphere InterChange Server. Chacun
des composants d'intégration de WebSphere InterChange Server joue
un rôle bien défini dans l'architecture. Si vous suivez une procédure trop différente de ce modèle, la migration de contenu vers des artefacts WebSphere Process Server sera plus compliquée.
Une autre pratique permettant d'améliorer grandement la réussite de projets de migration
consiste à documenter la conception du système. Assurez-vous de bien comprendre la conception et l'architecture d'intégration. Cela inclut les besoins en matière de fonctionnalités et de qualité de service, les inter-dépendances entre artefacts partagés sur plusieurs projets, ainsi que les décisions de conception prises lors du déploiement. Ces informations vous aideront pour analyser le système lors de la migration et permettront d'alléger les tâches nécessaires après l'opération.
Pour créer, configurer et modifier des définitions d'artefacts, utilisez uniquement
l'outil de développement fourni. Evitez de manipuler manuellement les métadonnées des
artefacts (par exemple, en éditant directement les fichiers XML). Cela risque de corrompre les
artefacts lors de la migration.
Lors du développement de code Java dans des modèles de collaboration,
mappes, utilitaires de code usuels et autres composants, procédez comme suit :
- Utilisez uniquement les interfaces API publiées.
- Utilisez l'éditeur d'activités.
- Utilisez des adaptateurs pour accéder aux services EIS.
- Evitez toute dépendance externe dans le code de fragments Java.
- Conformez-vous aux pratiques de développement J2EE pour une meilleure portabilité
- Ne générez pas d'unités d'exécution et n'utilisez pas de primitives de synchronisation d'unités d'exécution. Si vous y êtes obligé, vous devrez les convertir pour pouvoir utiliser les beans asynchrones lors de la migration.
- N'effectuez aucune opération d'E-S de disque via java.io.* Utilisez JDBC pour stocker des données.
- N'exécutez aucune fonction pouvant être réservée à un conteneur EJB
tel qu'une E-S de connecteur, le chargement de classe, le chargement de bibliothèques natives, etc.
Si vous y êtes contraint, vous devez convertir ces fragments manuellement pour pouvoir utiliser les fonctions du
conteneur EJB lors de la migration.
Utilisez uniquement les interfaces API publiées dans la documentation du produit WebSphere InterChange Server
concernant les artefacts. Celles-ci sont présentées en détail dans les guides de développement de WebSphere InterChange Server. Des API de compatibilité sont fournies par WebSphere Process
Server pour les API WebSphere InterChange Server publiées. Bien que WebSphere InterChange
Server dispose de nombreuses interfaces internes pouvant être utilisées,
rien ne garantit leur prise en charge par les versions
ultérieures du produit.
Lors de la conception de la logique métier et des règles de transformation dans les mappes et les modèles de
collaboration, évitez de développer des bibliothèques d'utilitaires de code usuels et de les inclure
comme fichiers d'archive Java
(*.jar) dans le chemin de classe de WebSphere InterChange Server, car
elles doivent être migrées manuellement.
Utilisez le plus possible l'éditeur d'activités. Cet outil assure que la logique est décrite via des métadonnées qui peuvent être converties plus facilement vers les nouveaux artefacts. Pour toute opération que vous souhaitez réutiliser dans l'outil, utilisez autant que possible la fonction "My Collections" (Mes collections) de l'éditeur d'activités.
Pour tout fragment de code Java qui nécessite un développement,
il est recommandé de simplifier au maximum le code utilisé. Le niveau de complexité du code Java
doit impliquer un niveau de script de type évaluations, opérations
et calculs de base, formatage de données, conversions de types, etc. Si une
logique d'application plus complète et plus complexe est nécessaire, utilisez des EJB
fonctionnant sous WebSphere Application
Server pour encapsuler cette logique. Utilisez les appels de service Web pour l'appeler à partir de WebSphere InterChange
Server. Utilisez les bibliothèques JDK standard plutôt que des bibliothèques tierces ou externes qui nécessiteraient une migration au cas par cas. Par ailleurs, regroupez tous les éléments relatifs à une même logique dans un fragment de code unique. Evitez d'utiliser une logique dans des contextes de connexion et de transaction impliquant plusieurs fragments. Pour des opérations de base de données, par exemple, le code permettant d'établir une connexion, de démarrer et d'arrêter une transaction et de fermer la connexion doit être regroupé dans un seul fragment de code.
D'une manière générale, vérifiez que le code conçu pour faire l'interface avec un système EIS est intégré à des adaptateurs et non à des mappes ou à des modèles de collaboration. En général, cela est recommandé pour la conception de
l'architecture. Elle permet également d'éviter le besoin d'une configuration prérequise pour des bibliothèques tierces et de considérations s'y rapportant au niveau du code, telles que la gestion des connexions et les implémentations JNI (Java Native Interface) éventuelles.
Faites en sorte que le code soit aussi sécurisé que possible, en utilisant un traitement des exceptions approprié.
Par ailleurs, le code doit pouvoir fonctionner dans un environnement de serveur d'applications J2EE, même s'il fonctionne actuellement dans un environnement J2SE. Conformez-vous aux
pratiques de développement J2EE : évitez les variables statiques, la génération d'unités d'exécution
et les E-S de disque. Ces pratiques peuvent
améliorer la portabilité.
Remarques : utilitaires de code communs
Il est recommandé d'éviter de développer des bibliothèques d'utilitaires de
code communs et de les utiliser pour des artefacts d'intégration en environnement
WebSphere InterChange Server. Bien que la réutilisation du code dans les artefacts d'intégration soit nécessaire, il est recommandé d'utiliser la fonction "My Collections" de l'éditeur d'activités.
Pensez également à utiliser des EJB fonctionnant sous
WebSphere
Application Server pour encapsuler la logique. Utilisez les appels de service Web pour les appeler à
partir de WebSphere
InterChange Server.
Bien que certaines bibliothèques d'utilitaires de code communs puissent s'exécuter correctement sous WebSphere Process Server, c'est l'utilisateur qui est responsable de la migration des utilitaires personnalisés.
Remarques : pools de connexion de base de données
Le pool de connexion de base de données WebSphere InterChange
Server d'une mappe ou d'un modèle de collaboration
se présente comme une ressource JDBC standard dans WebSphere Process Server. La gestion
des connexions et des transactions peut toutefois être différente entre WebSphere InterChange
Server et WebSphere Process
Server. Evitez donc d'activer les transactions de la base de données via des fragments Java.
Les pools de connexion de base de données définis par l'utilisateur sont très utiles dans des mappes et des modèles de
collaboration. Ils permettent d'effectuer des recherches de données simples et de gérer des états plus complexes dans
des instances de processus. Un pool de connexion de base de données dans WebSphere InterChange Server se présente comme une ressource JDBC standard dans WebSphere Process Server. Sa fonction de base reste identique. La gestion des connexions et des transactions peut
toutefois être différente.
Pour optimiser la portabilité, désactivez les transactions de base de données sur les noeuds de fragments Java dans un modèle de collaboration ou une mappe. Par exemple, le code permettant d'établir une connexion, de démarrer et d'arrêter une transaction et de fermer la connexion doit être regroupé dans un seul fragment de code.
Remarques : objets métier
Lors du développement d'objets métier, utilisez uniquement les outils fournis
pour configurer les artefacts, les types et les longueurs des données explicites pour les attributs de données
et les API documentées.
Les objets métier de WebSphere Process Server sont basés sur des objets SDO
(Service Data Objects). Les objets SDO utilisent des attributs de données fortement typés. Pour des objets
métier WebSphere InterChange
Server et des adaptateurs, les attributs de données ne sont pas fortement typés et, parfois,
les utilisateurs affectent des types de données de chaînes à des attributs de données sans chaînes. Pour éviter
les incidents sous WebSphere Process
Server, indiquez des types de données explicites.
Il est possible que des objets métier de WebSphere Process Server
soient sérialisés au moment de l'exécution lorsqu'ils sont transférés entre des composants. Il est donc important
d'utiliser des longueurs d'attributs de données explicites pour minimiser l'utilisation
des ressources système. Pour cette raison, évitez, par exemple, d'utiliser la longueur maximum d'attribut de chaîne (255 caractères). N'attribuez pas non plus la valeur 0 comme longueur d'attributs, car la valeur par défaut de 255 caractères est alors prise en compte. Indiquez la longueur exacte nécessaire aux attributs.
Les règles XSD NCName s'appliquent aux noms d'attribut d'objet métier de WebSphere Process
Server. N'utilisez donc ni espace ni ":" dans ces
noms. Les noms de l'attribut objet métier avec espaces ou " : " ne sont pas valides pour WebSphere Process Server. Renommez les attributs d'objet métier avant la migration.
Si vous utilisez un tableau dans un objet métier, son ordre peut ne pas être respecté
lors de son indexation dans le tableau dans Mappes et/ou Relations. L'architecture
WebSphere Process Server
dans laquelle ces derniers sont migrés ne garantit pas l'ordre de l'index, particulièrement lorsque des entrées sont supprimées.
Il est important d'utiliser uniquement l'outil Business Object Designer pour éditer les
les définitions d'objet métier et pour utiliser uniquement les API publiées pour les objets métier
des artefacts d'intégration.
Remarques : modèles de collaboration
La plupart des instructions décrites plus haut s'appliquent au
développement de modèles de collaboration.
Pour vous assurer que les processus sont décrits de façon appropriée à l'aide de métadonnées, utilisez toujours l'outil de conception de processus lorsque vous créez et modifiez des modèles de collaboration, et évitez d'éditer directement les fichiers de métadonnées. Utilisez le plus possible l'éditeur d'activités pour optimiser l'utilisation de métadonnées lors de la description de la logique nécessaire.
Pour alléger les tâches manuelles nécessaires après la migration, utilisez uniquement les API documentées dans les modèles de collaboration. Evitez l'utilisation de variables statiques. Utilisez plutôt des variables non statiques et des propriétés de collaboration pour adresser les conditions requises de la logique métier. Evitez l'utilisation de qualificatifs Java finaux, transitoires et natifs dans les fragments Java. Ceux-ci ne peuvent pas être appliqués
dans des fragments Java BPEL résultant de la migration de modèles
de collaboration.
Pour optimiser la portabilité, évitez d'utiliser des appels de fin de connexion
explicites et de placer les transactions (validations et annulations)
explicites entre parenthèses pour des pools de connexion à une base de données définis par l'utilisateur. Utilisez plutôt la mise entre parenthèses de transactions implicites et la suppression de connexions implicites gérées par le conteneur. Désactivez les transactions et les connexions système sur les noeuds de fragments Java dans un modèle de collaboration ou une mappe.
Ceci s'applique à toutes les connexions à un système externe ainsi qu'aux pools de connexion à une base de données définis par l'utilisateur. Les opérations impliquant un service EIS externe doivent être gérées
par un adaptateur. Le code utilisé pour les opérations de base de données doit être contenu
dans un fragment de code unique. Ceci peut être nécessaire dans une collaboration qui, lorsqu'elle est affichée comme composant de processus métier BPEL, peut être déployée de manière sélective sous forme de flux interruptible. Dans ce cas, le processus peut comporter plusieurs transactions distinctes, assurant uniquement le transfert des informations de variables d'état et globales entre les activités. Le contexte de toutes les connexions système ou transactions associées ayant déployé ces transactions de processus serait perdu.
Nommez les propriétés du modèle de collaboration selon les conventions de dénomination
W3C XML NCName. WebSphere Process Server accepte les noms conformes
à ces conventions. Ces caractères ne sont pas valides en tant que noms de propriété BPEL
dans lesquels ils sont migrés. Renommez les propriétés pour supprimer ces caractères
avant la migration. Vous éviterez ainsi des erreurs de syntaxe dans le BPEL généré lors de
la migration.
Ne référencez pas les variables en utilisant "this." Par exemple, utilisez "inputBusObj"
au lieu de "this.inputBusObj".
Pour les variables, utilisez plutôt une extension de niveau de classe qu'une de niveau de scénario.
Le niveau de scénario n'est pas conservé lors de la migration.
Initialisez toutes les variables déclarées dans les fragments Java avec une valeur par défaut : par exemple,
"Object myObject = null;". Assurez-vous que toutes les variables sont initialisées lors de la
déclaration précédant la migration.
Vérifiez qu'aucune instruction d'importation Java ne se trouve dans les sections modifiables
des modèles de collaboration. Dans la définition de ces derniers,
utilisez les zones d'importation pour indiquer les packages Java à importer.
Ne définissez pas les valeurs de l'objet métier entrant à stocker dans la variable triggeringBusObj.
Dans WebSphere InterChange
Server, triggeringBusObj est en lecture seule et ses valeurs
ne peuvent pas être remplacées. Les valeurs de l'objet métier entrant ne sont donc pas
sauvegardées. Si triggeringBusObj est utilisé en tant que variable
de réception pour un objet métier entrant sur un appel de service entrant, après
la migration, le comportement de l'appel de service entrant est différent :
dans le processus BPEL, la valeur entrante de l'appel de service entrant
remplace la valeur stockée dans triggeringBusObj.
Remarques : mappes
La plupart des instructions décrites pour les modèles de collaboration
s'appliquent également aux mappes.
Pour vous assurer que les mappes sont décrites de façon appropriée à l'aide de métadonnées, utilisez toujours l'outil de conception de mappes lorsque vous créez et modifiez des mappes, et évitez d'éditer directement les fichiers de métadonnées. Utilisez le plus possible l'éditeur d'activités pour optimiser l'utilisation de métadonnées lors de la description de la logique nécessaire.
Lorsque vous faites référence à des objets métier enfant dans une mappe, utilisez une sous-mappe pour
ces objets.
Evitez d'utiliser du code Java comme "valeur" d'une transaction SET car ce code n'est pas valide dans WebSphere Process Server. Utilisez plutôt des constantes. Par exemple, si la valeur définie est "xml version=" + "1.0" + " encoding=" + "UTF-8", elle ne sera pas validée dans WebSphere Process Server. Indiquez plutôt "xml version=1.0 encoding=UTF-8" avant d'effectuer la migration.
Pour alléger les tâches manuelles nécessaires après la migration,
utilisez uniquement les API documentées dans les mappes. Evitez l'utilisation de variables statiques.
Utilisez plutôt des variables non statiques. Evitez l'utilisation de qualificatifs Java finaux,
transitoires et natifs dans le code personnalisé des mappes.
Si vous utilisez un tableau dans un objet métier, son ordre peut ne pas être respecté
lors de son indexation dans le tableau dans Mappes. L'architecture WebSphere Process Server
dans laquelle ces derniers sont migrés ne garantit pas l'ordre de l'index, particulièrement lorsque des entrées sont supprimées.
Pour optimiser la portabilité, évitez d'utiliser des appels de fin de connexion
explicites et de placer les transactions (validations et annulations)
explicites entre parenthèses pour des pools de connexion à une base de données définis par l'utilisateur. Utilisez plutôt la mise entre parenthèses de transactions implicites et la suppression de connexions implicites gérées par le conteneur. Désactivez les transactions et les connexions système
lors des étapes de mappage personnalisées sur les limites des noeuds de transformation. Ceci s'applique à toutes les connexions à un système externe ainsi qu'aux pools de connexion de base de données définis par l'utilisateur. Les opérations impliquant un service EIS externe doivent être gérées par un adaptateur.
Le code utilisé pour les opérations de base de données doit être contenu dans une étape
personnalisée.
N'utilisez pas de classes internes dans vos mappes. La commande de migration (reposMigrate)
ne migre pas les classes internes. Vous recevrez donc des messages d'erreur si vos mappes en
contiennent. Dans un référentiel WebSphere InterChange
Server, une classe interne peut être définie dans un noeud et référencée
par d'autres noeuds dans le même modèle de collaboration. Dans WebSphere Process
Server, une classe interne définie dans un composant BPEL ne peut pas être utilisée par d'autres
composants. C'est pourquoi les classes internes ne sont pas translatées et doivent
être traitées manuellement. Les modifications recommandées incluent le regroupement du code de la classe
interne dans une bibliothèque en tant que classe externe ou la suppression de la déclaration de la classe interne,
la résolution des erreurs et le placement du code comme requis par le BPEL.
Remarques : relations
Bien que les définitions de relations peuvent être migrées pour être utilisées dans WebSphere Process Server, il est important de se rappeler que les données d'instance et le schéma du tableau de relations peuvent être réutilisés par ce même programme. Ils peuvent également être partagés de façon concurrentielle entre WebSphere InterChange Server et WebSphere Process Server.
Pour les relations, utilisez uniquement les outils fournis pour configurer les composants
associés et les API publiées pour les relations des artefacts
d'intégration.
Utilisez uniquement le concepteur de relations pour éditer les définitions de relation.
De plus, autorisez uniquement WebSphere InterChange Server à configurer le schéma de
relations, généré automatiquement lors du déploiement des définitions de relation.
Ne modifiez pas le schéma du tableau de relations directement à l'aide des outils de base de données ou des scripts SQL.
Si vous devez modifier manuellement les données d'instance de relations dans ce schéma
de tableau, assurez-vous d'utiliser les fonctions fournies par le gestionnaire de relations.
Utilisez uniquement les API publiées pour les relations des artefacts d'intégration.
Remarques : clients de canevas d'accès
Ne développez aucun nouveau client utilisant les API CORBA IDL. Elles ne seront
pas prises en charge dans
WebSphere
Process Server.
Remarques : empêcher les collisions de base de données
Vous pouvez empêcher les collisions de base de données en planifiant
les événements afin qu'ils se produisent à deux secondes d'intervalle au minimum.
Si une application migrée entraîne la réalisation de plusieurs événements en même temps
sur les composants WebSphere Business
Integration, des collisions de base de données ou des interblocages peuvent se produire. Cela
se produit lorsque WebSphere Process
Server Application Scheduler (AppScheduler) planifie plusieurs événements afin qu'ils se produisent
exactement en même temps. Lorsqu'un interblocage se produit, l'événement qui l'a provoqué
est annulé et relancé dès que possible. Ce cycle continue
jusqu'à ce que chacune des unités d'exécution tentant d'accéder à la base de données le mette correctement
à jour.
Par exemple :
AppScheduler E com.ibm.wbiserver.scheduler.AppSchedulerMB process CWLWS0021E:
The AppSchedulerMB.process method has generated an exception.
WSRdbXaResour E DSRA0304E: XAException occurred. XAException contents
and details are:
The DB2 Error message is : Error executing a XAResource.end(), Server returned
XA_RBDEADLOCK The DB2 Error code is : -4203
The DB2 SQLState is : null
Pour éviter cela, planifiez les événements afin qu'ils se produisent à intervalles
éloignés pour ne pas déclencher d'interblocages. Planifiez les événements pour qu'ils se produisent à deux
secondes d'intervalle au minimum. Toutefois, le temps nécessaire varie selon
les autres facteurs de votre environnement pouvant affecter les performances, tels que la taille de la
base de données, le matériel, la vitesse de connexion, etc.
Remarques : post-migration
Lorsque les applications ont été migrées de
WebSphere
InterChange Server vers
WebSphere
Integration Developer ou
WebSphere Process
Server, certains points doivent faire l'objet d'une attention particulière pour que les applications
migrées dans
WebSphere
Integration Developer et
WebSphere Process
Server fonctionnent conformément à leur fonction prévue, en raison des différences avec l'architecture
de WebSphere
InterChange Server.
Pour plus d'informations concernant les remarques relatives à la post-migration, voir
Post-migration considerations.
Migration de WebSphere InterChange Server avec l'Assistant de migration
Vous pouvez utiliser l'Assistant de migration de WebSphere Integration Developer pour migrer vos artefacts WebSphere InterChange Server.
Pour utiliser l'assistant de migration afin de migrer vos artefacts WebSphere InterChange Server, procédez comme suit :
- Appelez l'assistant en sélectionnant Fichier -> Importer -> Intégration métier -> WebSphere InterChange Server - Fichier JAR et cliquez sur Suivant :
OU vous pouvez également
ouvrir l'assistant de migration à partir de la page d'accueil en cliquant sur l'icône Pour ceux qui sont déjà
utilisateurs
pour ouvrir la page Pour ceux qui sont déjà utilisateurs (notez que vous pouvez toujours
revenir à la page d'accueil en cliquant sur Aide -> Bienvenue) :
Cliquez sur Migration
sur le côté gauche de la page Pour ceux qui sont déjà utilisateurs pour ouvrir la page Migration. Sur
la page Migration, sélectionnez l'option Migrer un référentiel WebSphere ICS
.
- L'Assistant de migration apparaît. Pour entrer le nom du fichier
source dans la zone Sélection de la source,
cliquez sur le bouton Parcourir et recherchez
le fichier. Entrez le nom de la bibliothèque dans la zone correspondante.
Si la bibliothèque partagée n'existe pas encore dans l'espace de travail, elle doit être
créée en cliquant sur Nouveau.... Cliquez sur Suivant :
- La fenêtre Options de migration apparaît. De là, vous pouvez accepter les
valeurs de migration par défaut ou cocher une case pour modifier l'option :

Le tableau suivant
répertorie les options de migration disponibles :
Option |
Description |
Avertir en cas d'erreurs d'analyse syntaxique Java |
(facultatif)
Par défaut, la migration d'un artefact individuel échoue si un incident de conversion Java
est détecté. Si cette option est définie, tous les incidents de conversion Java sont traités
en tant qu'avertissements et, si possible, l'artefact est migré. |
Arrêter la migration au premier incident |
(facultatif)
Par défaut, l'assistant de migration continue à traiter les artefacts restants
dans le fichier JAR si une erreur survient au cours du traitement de certains artefacts.
Si cette option est définie, le traitement s'arrête dès qu'une erreur est détectée.
L'artefact contenant l'erreur et tous les artefacts suivants ne sont pas traités. |
Utiliser le débouclage de canevas de collaboration |
(facultatif)
Les demandes présentées par toutes les boucles dans un modèle de collaboration sont conservées.
Si cette option n'est pas présente, par défaut, la migration utilise le débouclage. |
Activer le séquençage d'événement |
(facultatif) Le séquençage d'événement doit est activé pour toutes les méthodes WSDL asynchrones. Si cette option
n'est pas présente, par défaut, la migration n'active pas le séquençage d'événement
sur toutes les méthodes WSDL. |
Utiliser le canevas par défaut |
(facultatif) Les demandes
qui assemblent les modèles d'éditeur dans le répertoire spécifié sont chargées et
utilisées pour la conversion du code XML en Java. La valeur par défaut de cette propriété
définit que la version 4.3.3 du canevas de l'éditeur d'assemblage standard est utilisée pour la conversion du code XML en Java. |
- Cliquez sur
Terminer.
Une barre de progression située dans la partie inférieure de la boîte de dialogue Migration indique la
progression de la migration. Une fois que le processus de migration est terminé, la boîte de dialogue
Migration disparaît et la fenêtre Résultats de la migration s'ouvre.
Vérification de la migration de
WebSphere InterChange Server
Si aucune erreur n'est rapportée lors de la migration du fichier JAR de WebSphere InterChange
Server, cela signifie que les artefacts ont été correctement migrés. Lorsque la migration échoue, une liste répertoriant les erreurs, les avertissements et/ou les messages informatifs s'affiche. Vous pouvez utiliser ces messages pour vérifier la migration de WebSphere InterChange Server.
Remarque : En raison de la complexité d'une migration de WebSphere InterChange Server vers WebSphere Process Server, il est fortement recommandé d'effectuer un test approfondi des applications générées qui s'exécutent dans WebSphere Process Server afin de vous assurer de leur bon fonctionnement avant de les mettre en production.
Si des messages de migration ont été générés pendant le processus de migration, la page suivante apparaît :
La fenêtre Résultats de la migration présente les messages de migration qui ont été générés lors du processus de migration. Sélectionnez un message dans la liste des messages supérieure située en haut pour visualiser d'autres informations le concernant dans la fenêtre inférieure Description du message.
Pour conserver tous les messages afin de vous y référer ultérieurement,
cliquez sur le bouton Générer un pense-bête pour créer une liste des tâches à
effectuer dans la vue des tâches et/ou cliquez sur le bouton Enregistrer
sous... pour sauvegarder les messages dans un fichier texte dans le système de fichiers. Pour visualiser l'agenda généré, cliquez sur Fenêtre -> Afficher la vue -> Autre... -> Général -> Tâches, puis sur OK.
La vue Tâches affiche la liste de l'agenda généré à partir du processus
de migration.
Résolution des échecs de migration dans WebSphere InterChange Server
Si la migration depuis WebSphere InterChange Server échoue, vous pouvez résoudre ce problème de deux manières.
Remarque : Vous préférerez peut-être la première méthode car, au début, vous connaissez mieux
WebSphere InterChange Server. Toutefois, à mesure que vous connaîtrez mieux WebSphere Process Server et ses nouveaux artefacts, vous choisirez peut-être de réparer les artefacts migrés dans WebSphere Integration Developer.
- Si la nature de l'erreur le permet, vous pouvez modifier les artefacts de
WebSphere
InterChange Server à l'aide des outils de
WebSphere
InterChange Server puis exporter le fichier .jar et tenter une nouvelle migration.
- Vous pouvez corriger toutes les erreurs des artefacts générés de
WebSphere
Process Server en les éditant dans
WebSphere
Integration Developer.
Artefacts WebSphere InterChange Server gérés par les outils de migration
Les outils de migration permettent d'effectuer automatiquement la migration des artefacts WebSphere InterChange Server.
Les artefacts pouvant être migrés sont les suivants :
- Les objets métier deviennent des objets métier WebSphere Process Server
- Les mappes deviennent des mappes WebSphere Process Server
- Les relations deviennent des relations et des rôles WebSphere Process Server
- Les modèles de collaboration deviennent des BPEL et WSDL WebSphere Process Server
- Les objets de collaboration deviennent des modules WebSphere Process Server contenant
un composant SCA lié au modèle de collaboration BPEL et à toutes les connexions
SCA nécessaires
- Les définitions de connecteur deviennent des modules WebSphere Process Server contenant
des importations et des exportations SCA pour permettre de communiquer avec les adaptateurs existants,
l'artefact de l'adaptateur d'administration existant et toutes les connexions SCA nécessaires
Les outils de migration créeront un script Jython qui peut être utilisé avec l'outil de ligne de commande wsadmin pour configurer des ressources dans WebSphere Process Server, pour les artefacts/ressources suivants de WebSphere InterChange Server :
- Pools DBConnection
- Relations
- Entrées du planificateur
Les outils de migration ne permettent pas de gérer les artefacts WebSphere InterChange Server suivants :
- Artefacts de test de performance
API WebSphere InterChange Server prises en charge
Outre les outils de migration d'artefacts source qu'il propose (fournis avec WebSphere Process Server et WebSphere Integration Developer), WebSphere InterChange Server prend en charge de nombreuses API. Les outils de migration fonctionnent conjointement à ces API WebSphere InterChange Server en conservant au maximum le code des fragments personnalisés lors de la migration.
Remarque : Ces API sont fournies uniquement pour prendre en charge les applications WebSphere InterChange Server migrées, jusqu'à ce que ces dernières puissent être modifiées pour utiliser de nouvelles API de Process Server.
Les API WebSphere InterChange Server prises en charge dans Process Server sont répertoriées ci-après. Elles
offrent des fonctions dans
WebSphere
Process Server identiques à celles fournies dans
WebSphere
InterChange Server. Consultez la documentation de WebSphere InterChange Server documentation pour une description des fonctions de ces API.
CwBiDiEngine
AppSide_Connector/
- BiDiBOTransformation(BusinessObject, String, String, boolean):BusinessObj
- BiDiBusObjTransformation(BusObj, String, String, boolean):BusObj
- BiDiStringTransformation(String, String, String):String
JavaConnectorUtil
AppSide_Connector/
- INFRASTRUCTURE_MESSAGE_FILE
- CONNECTOR_MESSAGE_FILE
- XRD_WARNING
- XRD_TRACE
- XRD_INFO
- XRD_ERROR
- XRD_FATAL
- LEVEL1
- LEVEL2
- LEVEL3
- LEVEL4
- LEVEL5
- createBusinessObject(String):BusinesObjectInterface
- createBusinessObject(String, Locale):BusinesObjectInterface
- createBusinessObject(String, String):BusinesObjectInterface
- createContainer(String):CxObjectContainerInterface
- generateMsg(int, int, int, int, int, Vector):String
- generateMsg(int, int, int, int, Vector):String
- getBlankValue():String
- getEncoding():String
- getIgnoreValue():String
- getLocale():String
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
- isBlankValue(Object):boolean
- isIgnoreValue(Object):boolean
- isTraceEnabled(int):boolean
- logMsg(String)
- logMsg(String, int)
- traceWrite(int, String)
JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
BusObj
Collaboration/
- BusObj(DataObject)
- BusObj(String)
- BusObj(String, Locale)
- copy(BusObj)
- duplicate():BusObj
- equalKeys(BusObj):boolean
- equals(Object):boolean
- equalsShallow(BusObj):boolean
- exists(String):boolean
- get(int):Object
- get(String):Object
- getBoolean(String):boolean
- getBusObj(String):BusObj
- getBusObjArray(String):BusObjArray
- getCount(String):int
- getDouble(String):double
- getFloat(String):float
- getInt(String):int
- getKeys():String
- getLocale():java.util.Locale
- getLong(String):long
- getLongText(String):String
- getString(String):String
- getType():String
- getValues():String
- getVerb():String
- isBlank(String):boolean
- isKey(String):boolean
- isNull(String):boolean
- isRequired(String):boolean
- keysToString():String
- set(BusObj)
- set(int, Object)
- set(String, boolean)
- set(String, double)
- set(String, float)
- set(String, int)
- set(String, long)
- set(String, Object)
- set(String, String)
- setContent(BusObj)
- setDefaultAttrValues()
- setKeys(BusObj)
- setLocale(java.util.Locale)
- setVerb(String)
- setVerbWithCreate(String, String)
- setWithCreate(String, boolean)
- setWithCreate(String, BusObj)
- setWithCreate(String, BusObjArray)
- setWithCreate(String, double)
- setWithCreate(String, float)
- setWithCreate(String, int)
- setWithCreate(String, long):
- setWithCreate(String, Object)
- setWithCreate(String, String)
- toString():String
- validData(String, boolean):boolean
- validData(String, BusObj):boolean
- validData(String, BusObjArray):boolean
- validData(String, double):boolean
- validData(String, float):boolean
- validData(String, int):boolean
- validData(String, long):boolean
- validData(String, Object):boolean
- validData(String, String):boolean
BusObjArray
Collaboration/
- addElement(BusObj)
- duplicate():BusObjArray
- elementAt(int):BusObj
- equals(BusObjArray):boolean
- getElements():BusObj[]
- getLastIndex():int
- max(String):String
- maxBusObjArray(String):BusObjArray
- maxBusObjs(String):BusObj[]
- min(String):String
- minBusObjArray(String):BusObjArray
- minBusObjs(String):BusObj[]
- removeAllElements()
- removeElement(BusObj)
- removeElementAt(int)
- setElementAt(int, BusObj)
- size():int
- sum(String):double
- swap(int, int)
- toString():String
BaseDLM
DLM/
- BaseDLM(BaseMap)
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection
- getName():String
- getRelConnection(String):DtpConnection
- implicitDBTransactionBracketing():boolean
- isTraceEnabled(int):boolean
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- raiseException(RunTimeEntityException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- releaseRelConnection(boolean)
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
CwDBConnection
CwDBConnection/
CxCommon/
- beginTransaction()
- commit()
- executePreparedSQL(String)
- executePreparedSQL(String, Vector)
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- release()
- rollback()
CwDBConstants
CwDBConnection/
CxCommon/
- PARAM_IN - 0
- PARAM_INOUT - 1
- PARAM_OUT - 2
CwDBStoredProcedureParam
CwDBConnection/
CxCommon/
- CwDBStoredProcedureParam(int, Array)
- CwDBStoredProcedureParam(int, BigDecimal)
- CwDBStoredProcedureParam(int, boolean)
- CwDBStoredProcedureParam(int, Boolean)
- CwDBStoredProcedureParam(int, byte[])
- CwDBStoredProcedureParam(int, double)
- CwDBStoredProcedureParam(int, Double)
- CwDBStoredProcedureParam(int, float)
- CwDBStoredProcedureParam(int, Float)
- CwDBStoredProcedureParam(int, int)
- CwDBStoredProcedureParam(int, Integer)
- CwDBStoredProcedureParam(int, java.sql.Blob)
- CwDBStoredProcedureParam(int, java.sql.Clob)
- CwDBStoredProcedureParam(int, java.sql.Date)
- CwDBStoredProcedureParam(int, java.sql.Struct)
- CwDBStoredProcedureParam(int, java.sql.Time)
- CwDBStoredProcedureParam(int, java.sql.Timestamp)
- CwDBStoredProcedureParam(int, Long)
- CwDBStoredProcedureParam(int, String)
- CwDBStoredProcedureParam(int, String, Object)
- getParamType():int getValue():Object
DataHandler (classe abstraite)
DataHandlers/
crossworlds/
com/
- createHandler(String, String, String):DataHandler
- getBO(InputStream, Object):BusinessObjectInterface
- getBO(Object, BusinessObjectInterface, Object)
- getBO(Object, Object):BusinessObjectInterface
- getBO(Reader, BusinessObjectInterface, Object) (méthode abstraite)
- getBO(Reader, Object):BusinessObjectInterface (méthode abstraite)
- getBO(String, Object):BusinessObjectInterface
- getBOName(InputStream):String
- getBOName(Reader):String
- getBOName(String):String
- getBooleanOption(String):boolean
- getEncoding():String
- getLocale():Locale
- getOption(String):String
- getStreamFromBO(BusinessObjectInterface, Object):InputStream (méthode abstraite)
- getStringFromBO(BusinessObjectInterface, Object):String (méthode abstraite)
- setConfigMOName(String)
- setEncoding(String)
- setLocale(Locale)
- setOption(String, String)
- traceWrite(String, int)
NameHandler (classe abstraite)
DataHandlers/
crossworlds/
com/
- getBOName(Reader, String):String) (Abstract Method)
ConfigurationException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
MalformedDataException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
NotImplementedException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
BusinessObjectInterface
CxCommon/
- clone():Object
- dump():String
- getAppText():String
- getAttrCount():int
- getAttrDesc(int):CxObjectAttr
- getAttrDesc(String):CxObjectAttr
- getAttribute(String):Object
- getAttributeIndex(String):int
- getAttributeType(int):int
- getAttributeType(String):int
- getAttrName(int):String
- getAttrValue(int):Object
- getAttrValue(String):Object
- getBusinessObjectVersion():String
- getDefaultAttrValue(int):String
- getDefaultAttrValue(String):String
- getLocale():String
- getName():String
- getParentBusinessObject():BusinessObjectInterface
- getVerb():String
- getVerbAppText(String):String
- isBlank(int):boolean
- isBlank(String):boolean
- isIgnore(int):boolean
- isIgnore(String):boolean
- isVerbSupported(String):boolean
- makeNewAttrObject(int):Object
- makeNewAttrObject(String):Object
- setAttributeWithCreate(String, Object)
- setAttrValue(int, Object)
- setAttrValue(String, Object)
- setDefaultAttrValues()
- setLocale(Locale)
- setLocale(String)
- setVerb(String)
CxObjectAttr
CxCommon/
- BOOLEAN
- BOOLSTRING
- DATE
- DATESTRING
- DOUBLE
- DOUBSTRING
- FLOAT
- FLTSTRING
- INTEGER
- INTSTRING
- INVALID_TYPE_NUM
- INVALID_TYPE_STRING
- LONGTEXT
- LONGTEXTSTRING
- MULTIPLECARDSTRING
- OBJECT
- SINGLECARDSTRING
- STRING
- STRSTRING
- equals(Object):boolean
- getAppText():String
- getCardinality():String
- getDefault():String
- getMaxLength():int
- getName():String
- getRelationType():String
- getTypeName():String
- getTypeNum():String
- hasCardinality(String):boolean
- hasName(String):boolean
- hasType(String):boolean
- isForeignKeyAttr():boolean
- isKeyAttr():boolean
- isMultipleCard():boolean
- isObjectType():boolean
- isRequiredAttr():boolean
- isType(Object):boolean
CxObjectContainerInterface
CxCommon/
- getBusinessObject(int):BusinessObjectInterface
- getObjectCount():int
- insertBusinessObject(BusinessObjectInterface)
- removeAllObjects()
- removeBusinessObjectAt(int)
- setBusinessObject(int, BusinessObjectInterface)
DtpConnection
Dtp/
CxCommon/
- beginTran()
- commit()
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- rollback()
DtpDataConversion
Dtp/
CxCommon/
- BOOL_TYPE - 4
- CANNOTCONVERT - 2
- DATE_TYPE - 5
- DOUBLE_TYPE - 3
- FLOAT_TYPE - 2
- INTEGER_TYPE - 0
- LONGTEXT_TYPE - 6
- OKTOCONVERT - 0
- POTENTIALDATALOSS - 1
- STRING_TYPE - 1
- UNKNOWN_TYPE - 999
- getType(double):int
- getType(float):int
- getType(int):int
- getType(Object):int
- isOKToConvert(int, int):int
- isOKToConvert(String, String):int
- toBoolean(boolean):Boolean
- toBoolean(Object):Boolean
- toDouble(double):Double
- toDouble(float):Double
- toDouble(int):Double
- toDouble(Object):Double
- toFloat(double):Float
- toFloat(float):Float
- toFloat(int):Float
- toFloat(Object):Float
- toInteger(double):Integer
- toInteger(float):Integer
- toInteger(int):Integer
- toInteger(Object):Integer
- toPrimitiveBoolean(Object):boolean
- toPrimitiveDouble(float):double
- toPrimitiveDouble(int):double
- toPrimitiveDouble(Object):double
- toPrimitiveFloat(double):float
- toPrimitiveFloat(int):float
- toPrimitiveFloat(Object):float
- toPrimitiveInt(double):int
- toPrimitiveInt(float):int
- toPrimitiveInt(Object):int
- toString(double):String
- toString(float):String
- toString(int):String
- toString(Object):String
DtpDate
Dtp/
CxCommon/
- DtpDate()
- DtpDate(long, boolean)
- DtpDate(String, String)
- DtpDate(String, String, String[], String[])
- addDays(int):DtpDate
- addMonths(int):DtpDate
- addWeekdays(int):DtpDate
- addYears(int):DtpDate
- after(DtpDate):boolean
- before(DtpDate):boolean
- calcDays(DtpDate):int
- calcWeekdays(DtpDate):int
- get12MonthNames():String[]
- get12ShortMonthNames():String[]
- get7DayNames():String[]
- getCWDate():String
- getDayOfMonth():String
- getDayOfWeek():String
- getHours():String
- getIntDay():int
- getIntDayOfWeek():int
- getIntHours():int
- getIntMilliSeconds():int
- getIntMinutes():int
- getIntMonth():int
- getIntSeconds():int
- getIntYear():int
- getMaxDate(BusObjArray, String, String):DtpDate
- getMaxDateBO(BusObj[], String, String):BusObj[]
- getMaxDateBO(BusObjArray, String, String):BusObj[]
- getMinDate(BusObjArray, String, String):DtpDate
- getMinDateBO(BusObj[], String, String):BusObj[]
- getMinDateBO(BusObjArray, String, String):BusObj[]
- getMinutes():String
- getMonth():String
- getMSSince1970():long
- getNumericMonth():String
- getSeconds():String
- getShortMonth():String
- getYear():String
- set12MonthNames(String[], boolean)
- set12MonthNamesToDefault()
- set12ShortMonthNames(String[])
- set12ShortMonthNamesToDefault()
- set7DayNames(String[])
- set7DayNamesToDefault()
- toString():String
- toString(String):String
- toString(String, boolean):String
DtpMapService
Dtp/
CxCommon/
- runMap(String, String, BusObj[], CxExecutionContext):BusObj[]
DtpSplitString
Dtp/
CxCommon/
- DtpSplitString(String, String)
- elementAt(int):String
- firstElement():String
- getElementCount():int
- getEnumeration():Enumeration
- lastElement():String
- nextElement():String
- prevElement():String
- reset()
DtpUtils
Dtp/
CxCommon/
- padLeft(String, char, int):String
- padRight(String, char, int):String
- stringReplace(String, String, String):String
- truncate(double):int
- truncate(double, int):double
- truncate(float):int
- truncate(float, int):double
- truncate(Object):int
- truncate(Object, int):double
BusObjInvalidVerbException (étend InterchangeExceptions)
Exceptions/
CxCommon/
IdentityRelationship
relationship/
utilities/
crossworlds/
com/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- foreignKeyLookup(String, String, BusObj, String, BusObj, String, CxExecutionContext)
- foreignKeyXref(String, String, String, BusObj, String, BusObj, String, CxExecutionContext)
- maintainChildVerb(String, String, String, BusObj, String, BusObj, String, CxExecutionContext, boolean, boolean)
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- updateMyChildren(String, String, BusObj, String, String, String, String, CxExecutionContext)
MapExeContext
Dtp/
CxCommon/
- ACCESS_REQUEST - "SUBSCRIPTION_DELIVERY"
- ACCESS_RESPONSE - "ACCESS_RETURN_REQUEST"
- EVENT_DELIVERY - "SUBSCRIPTION_DELIVERY"
- SERVICE_CALL_FAILURE - "CONSUME_FAILED"
- SERVICE_CALL_REQUEST - "CONSUME"
- SERVICE_CALL_RESPONSE - "DELIVERBUSOBJ"
- getConnName():String
- getGenericBO():BusObj
- getInitiator():String
- getLocale():java.util.Locale
- getOriginalRequestBO():BusObj
- setConnName(String)
- setInitiator(String)
- setLocale(java.util.Locale)
Participant
RelationshipServices/
Server/
- Participant(String, String, int, BusObj)
- Participant(String, String, int, String)
- Participant(String, String, int, long)
- Participant(String, String, int, int)
- Participant(String, String, int, double)
- Participant(String, String, int, float)
- Participant(String, String, int, boolean)
- Participant(String, String, BusObj)
- Participant(String, String, String)
- Participant(String, String, long)
- Participant(String, String, int)
- Participant(String, String, double)
- Participant(String, String, float)
- Participant(String, String, boolean)
- getBoolean():boolean
- getBusObj():BusObj
- getDouble():double
- getFloat():float
- getInstanceId():int
- getInt():int
- getLong():long
- getParticipantDefinition():String
- getRelationshipDefinition():String
- getString():String INVALID_INSTANCE_ID
- set(boolean)
- set(BusObj)
- set(double)
- set(float)
- set(int)
- set(long)
- set(String)
- setInstanceId(int)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
Relationship
RelationshipServices/
Server/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- addParticipant(Participant):int
- addParticipant(String, String, boolean):int
- addParticipant(String, String, BusObj):int
- addParticipant(String, String, double):int
- addParticipant(String, String, float):int
- addParticipant(String, String, int):int
- addParticipant(String, String, int, boolean):int
- addParticipant(String, String, int, BusObj):int
- addParticipant(String, String, int, double):int
- addParticipant(String, String, int, float):int
- addParticipant(String, String, int, int):int
- addParticipant(String, String, int, long):int
- addParticipant(String, String, int, String):int
- addParticipant(String, String, long):int
- addParticipant(String, String, String):int
- create(Participant):int
- create(String, String, boolean):int
- create(String, String, BusObj):int
- create(String, String, double):int
- create(String, String, float):int
- create(String, String, int):int
- create(String, String, long):int
- create(String, String, String):int
- deactivateParticipant(Participant)
- deactivateParticipant(String, String, boolean)
- deactivateParticipant(String, String, BusObj)
- deactivateParticipant(String, String, double)
- deactivateParticipant(String, String, float)
- deactivateParticipant(String, String, int)
- deactivateParticipant(String, String, long)
- deactivateParticipant(String, String, String)
- deactivateParticipantByInstance(String, String, int)
- deactivateParticipantByInstance(String, String, int, boolean)
- deactivateParticipantByInstance(String, String, int, BusObj)
- deactivateParticipantByInstance(String, String, int, double)
- deactivateParticipantByInstance(String, String, int, float)
- deactivateParticipantByInstance(String, String, int, int)
- deactivateParticipantByInstance(String, String, int, long)
- deactivateParticipantByInstance(String, String, int, String)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteParticipant(Participant)
- deleteParticipant(String, String, boolean)
- deleteParticipant(String, String, BusObj)
- deleteParticipant(String, String, double)
- deleteParticipant(String, String, float)
- deleteParticipant(String, String, int)
- deleteParticipant(String, String, long)
- deleteParticipant(String, String, String)
- deleteParticipantByInstance(String, String, int)
- deleteParticipantByInstance(String, String, int, boolean)
- deleteParticipantByInstance(String, String, int, BusObj)
- deleteParticipantByInstance(String, String, int, double)
- deleteParticipantByInstance(String, String, int, float)
- deleteParticipantByInstance(String, String, int, int)
- deleteParticipantByInstance(String, String, int, long)
- deleteParticipantByInstance(String, String, int, String)
- getNewID(String):int
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- retrieveInstances(String, boolean):int[]
- retrieveInstances(String, BusObj):int[]
- retrieveInstances(String, double):int[]
- retrieveInstances(String, float):int[]
- retrieveInstances(String, int):int[]
- retrieveInstances(String, long):int[]
- retrieveInstances(String, String):int[]
- retrieveInstances(String, String, boolean):int[]
- retrieveInstances(String, String, BusObj):int[]
- retrieveInstances(String, String, double):int[]
- retrieveInstances(String, String, float):int[]
- retrieveInstances(String, String, int):int[]
- retrieveInstances(String, String, long):int[]
- retrieveInstances(String, String, String):int[]
- retrieveInstances(String, String[], boolean):int[]
- retrieveInstances(String, String[], BusObj):int[]
- retrieveInstances(String, String[], double):int[]
- retrieveInstances(String, String[], float):int[]
- retrieveInstances(String, String[], int):int[]
- retrieveInstances(String, String[], long):int[]
- retrieveInstances(String, String[], String):int[]
- retrieveParticipants(String):Participant[]
- retrieveParticipants(String, String):Participant[]
- retrieveParticipants(String, String[]):Participant[]
- retrieveParticipants(String, int):Participant[]
- retrieveParticipants(String, String, int):Participant[]
- retrieveParticipants(String, String[], int):Participant[]
- updateMyChildren(String, String, BusObj, String, String, String, String, CxExecutionContext)
- updateParticipant(String, String, BusObj)
- updateParticipantByInstance(Participant)
- updateParticipantByInstance(String, String, int)
- updateParticipantByInstance(String, String, int, BusObj)
UserStoredProcedureParam
Dtp/
CxCommon/
- UserStoredProcedureParam(int, String, Object, String, String)
- getParamDataTypeJavaObj():String
- getParamDataTypeJDBC():int
- getParamIndex():int
- getParamIOType():String
- getParamName():String
- getParamValue():Object
- setParamDataTypeJavaObj(String)
- setParamDataTypeJDBC(int)
- setParamIndex(int)
- setParamIOType(String)
- setParamName(String)
- setParamValue(Object)
- PARAM_TYPE_IN - "IN"
- PARAM_TYPE_OUT - "OUT"
- PARAM_TYPE_INOUT - "INOUT"
- DATA_TYPE_STRING - "String"
- DATA_TYPE_INTEGER - "Integer"
- DATA_TYPE_DOUBLE - "Double"
- DATA_TYPE_FLOAT - "Float"
- DATA_TYPE_BOOLEAN - "Boolean"
- DATA_TYPE_TIME - "java.sql.Time"
- DATA_TYPE_DATE - "java.sql.Date"
- DATA_TYPE_TIMESTAMP - "java.sql.Timestamp"
- DATA_TYPE_BIG_DECIMAL - "java.math.BigDecimal"
- DATA_TYPE_LONG_INTEGER - "Long"
- DATA_TYPE_BINARY - "byte[]"
- DATA_TYPE_CLOB - "Clob"
- DATA_TYPE_BLOB - "Blob"
- DATA_TYPE_ARRAY - "Array"
- DATA_TYPE_STRUCT - "Struct"
- DATA_TYPE_REF - "Ref"
BaseCollaboration
Collaboration/
- BaseCollaboration(com.ibm.bpe.api.ProcessInstanceData)
- AnyException - "AnyException"
- AppBusObjDoesNotExist - "BusObjDoesNotExist"
- AppLogOnFailure - "AppLogOnFailure"
- AppMultipleHits - "AppMultipleHits"
- AppRequestNotYetSent - "AppRequestNotYetSent"
- AppRetrieveByContentFailed - "AppRetrieveByContent"
- AppTimeOut - "AppTimeOut"
- AppUnknown - "AppUnknown"
- AttributeException - "AttributeException"
- existsConfigProperty(String):boolean
- getConfigProperty(String):String
- getConfigPropertyArray(String):String[]
- getCurrentLoopIndex():int
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection getLocale():java.util.Locale
- getMessage(int):String
- getMessage(int, Object[]):String
- getName():String
- implicitDBTransactionBracketing():boolean
- isCallerInRole(String):boolean
- isTraceEnabled(int):boolean
- JavaException - "JavaException"
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- not(boolean):boolean ObjectException - "ObjectException"
- OperationException - "OperationException"
- raiseException(CollaborationException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- ServiceCallException - "ConsumerException"
- ServiceCallTransportException - "ServiceCallTransportException"
- SystemException - "SystemException"
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
- TransactionException - "TransactionException"
CxExecutionContext
CxCommon/
- CxExecutionContext()
- getContext(String):Object
- MAPCONTEXT - "MAPCONTEXT"
- setContext(String, Object)
CollaborationException
Collaboration/
- getMessage():String
- getMsgNumber():int
- getSubType():String
- getText():String
- getType():String
- toString():String
Filter
crossworlds/
com/
- Filter(BaseCollaboration)
- filterExcludes(String, String):boolean
- filterIncludes(String, String):boolean
- recurseFilter(BusObj, String, boolean, String, String):boolean
- recursePreReqs(String, Vector):int
Globals
crossworlds/
com/
- Globals(BaseCollaboration)
- callMap(String, BusObj):BusObj
SmartCollabService
crossworlds/
com/
- SmartCollabService()
- SmartCollabService(BaseCollaboration)
- doAgg(BusObj, String, String, String):BusObj
- doMergeHash(Vector, String, String):Vector
- doRecursiveAgg(BusObj, String, String, String):BusObj
- doRecursiveSplit(BusObj, String):Vector
- doRecursiveSplit(BusObj, String, boolean):Vector
- getKeyValues(BusObj, String):String
- merge(Vector, String):BusObj
- merge(Vector, String, BusObj):BusObj
- split(BusObj, String):Vector
StateManagement
crossworlds/
com/
- StateManagement()
- beginTransaction()
- commit()
- deleteBO(String, String, String)
- deleteState(String, String, String, int)
- persistBO(String, String, String, String, BusObj)
- recoverBO(String, String, String):BusObj
- releaseDBConnection()
- resetData()
- retrieveState(String, String, String, int):int
- saveState(String, String, String, String, int, int, double)
- setDBConnection(CwDBConnection)
- updateBO(String, String, String, String, BusObj)
- updateState(String, String, String, String, int, int)
EventKeyAttrDef
EventManagement/
CxCommon/
- EventKeyAttrDef()
- EventKeyAttrDef(String, String)
- public String keyName
- public String keyValue
EventQueryDef
EventManagement/
CxCommon/
- EventQueryDef()
- EventQueryDef(String, String, String, String, int)
- public String nameConnector
- public String nameCollaboration
- public String nameBusObj
- public String verb
- public int ownerType
FailedEventInfo
EventManagement/
CxCommon/
- FailedEventInfo()
- FailedEventInfo(String x6, int, EventKeyAttrDef[], int, int, String, String, int)
- public String nameOwner
- public String nameConnector
- public String nameBusObj
- public String nameVerb
- public String strTime
- public String strMessage
- public int wipIndex
- public EventKeyAttrDef[] strbusObjKeys
- public int nKeys
- public int eventStatus
- public String expirationTime
- public String scenarioName
- public int scenarioState
Mappage de WebSphere Process Sever DataObject à partir de WebSphere InterChange
Server XML
Si vous utilisez les adaptateurs existants pour vous connecter à WebSphere Process Server, l'algorithme suivant vous permet de mieux comprendre comment WebSphere Process Server DataObject a été créé à partir de WebSphere InterChange Server XML.
Ces informations présentent l'emplacement des valeurs de données, ainsi que celles qui ont été choisies pour remplacer les valeurs utilisées dans WebSphere InterChange Server.
Autres dispositions
- Pour que l'instruction de ChangeSummary puisse être définie, tous les paramètres sont définis via les interfaces API markCreate/Update/Delete.
- Pour que l'instruction de ChangeSummary/EventSummary puisse être définie, les instructions Create, Update et Delete sont définies dans ChangeSummary et toutes les autres dans EventSummary.
- Pour obtenir l'instruction à partir de ChangeSummary :
- Si isDelete a la valeur true, l'instruction utilisée est Delete.
Remarque : La valeur de isCreate est ignorée si isDelete a la valeur true. Le cas peut se présenter si la création a été marquée avant l'entrée de l'objet de données (DataObject) dans le concentrateur (auquel cas il a été supprimé), ou si la création et la suppression ont eu lieu dans le concentrateur.
- Si isDelete a la valeur false et isCreate, la valeur true, l'instruction utilisée est Create.
- Si isDelete et isCreate ont la valeur false, l'instruction utilisée est Update.
- Pour éviter qu'un objet de données soit identifié comme objet Create au lieu de Update, vous devez procéder comme suit (si la consignation est activée) :
- Interrompez la consignation pendant la création de l'objet de données.
- Poursuivez la consignation pendant la mise à jour de l'objet de données (ou utilisez l'API markUpdated).
Chargement
Charge un fichier XML d'exécution de WebSphere InterChange Server dans une instance WebSphere Business Integration BusinessGraph AfterImage.
- Une instance appropriée de BusinessGraph est créée.
- La consignation ChangeSummary est activée. Si vous l'activez ultérieurement, vous ne supprimerez donc pas les entrées.
- La consignation ChangeSummary est mise en pause pour éviter que toute information indésirable ne soit envoyée dans ChangeSummary.
- Les attributs de l'objet métier supérieur sont créés dans l'objet de données
(voir la section "Traitement des attributs" ci-dessous).
- Si l'objet métier supérieur possède des objets enfants, ceux-ci sont traités de façon récurrente.
- Les attributs de ces objets métier enfants sont créés dans l'objet de données (voir la section "Traitement des attributs" ci-dessous).
- L'instruction de l'objet métier supérieur est définie dans l'instruction supérieure du BusinessGraph et dans les récapitulatifs.
- L'instruction des objets métier enfants est définie dans les récapitulatifs.
Enregistrement
Enregistre une instance WebSphere Business Integration BusinessGraph AfterImage dans un fichier XML d'exécution de WebSphere InterChange Server. Une exception est envoyée si le BusinessGraph de l'entrée n'est pas au format AfterImage.
Traitement des attributs
- Toutes les valeurs non mentionnées ci-dessous sont des valeurs ASIS chargées/enregistrées.
- ObjectEventId est chargé dans/enregistré à partir de EventSummary.
- Pour CxBlank et CxIgnore :
- Lors de la conversion, du côté de l'objet métier WebSphere Business Integration, CxBlank et CxIgnore sont définis/identifiés de la manière suivante :
- CxIgnore : Non défini ou défini avec la valeur null Java
- CxBlank : Valeur dépendant du type utilisé (voir tableau ci-dessous)
- Lors de la conversion, du côté du fichier XML WebSphere InterChange Server, CxBlank et CxIgnore sont définis/identifiés de la manière suivante :
Tableau 1. Définition de CxBlank et de CxIgnore
Type |
CxIgnore |
CxBlank |
Int |
Integer.MIN_VALUE |
Integer.MAX_VALUE |
Float |
Float.MIN_VALUE |
Float.MAX_VALUE |
Double |
Double.MIN_VALUE |
Double.MAX_VALUE |
String/date/longtext |
"CxIgnore" |
"" |
Objets métier enfants |
(élément vide) |
N/A |
Chapitre 4. Migration vers WebSphere Integration Developer à partir de WebSphere MQ Workflow
WebSphere Integration Developer fournit les outils nécessaires pour migrer à partir de WebSphere MQ Workflow.
L'Assistant de migration permet de convertir des définitions FDL de processus
métier que vous avez exportées à partir du composant build time de
WebSphere
MQ Workflow en artefacts WebSphere Process Integration correspondants. Les artefacts générés comprennent des définitions XML pour des objets
métier, définitions WSDL, BPEL, des définitions d'importation et de composants et des définitions TEL.
L'outil de conversion nécessite une définition FDL sémantiquement complète d'un modèle de processus que vous exportez de
WebSphere
MQ Workflow build time avec l'option export
deep. Cette option garantit que toutes les spécifications de données, programme et sous-processus nécessaires sont comprises. Assurez-vous également que chaque définition de serveur d'exécution de processus défini par l'utilisateur (UPES) référencée dans votre modèle de processus WebSphere MQ Workflow est aussi sélectionnée lorsque vous exportez FDL à partir de WebSphere MQ Workflow build time.
Remarque : L'Assistant de migration ne couvre pas la migration :
- des instances d'exécution de WebSphere MQ Workflow,
- des applications de programme appelées par un agent d'exécution de programme (PEA) WebSphere MQ Workflow ou un serveur d'exécution de processus (PES pour z/OS) WebSphere MQ Workflow.
Pour plus d'informations sur la migration à l'aide de l'outil de conversion FDL2BPEL, voir le Site de support de WebSphere MQ Workflow.
Avant de migrer WebSphere Integration Developer depuis WebSphere MQ Workflow, vous devez d'abord vérifier que vous avez bien préparé votre environnement.
L'étendue des mappages dépend de la manière dont vous suivez les recommandations suivantes pour la migration :
- Vérifiez que les activités des programmes FDL sont associées à un serveur d'exécution de processus (UPES) défini par l'utilisateur, s'il ne s'agit pas d'activités de personnel pures.
- Vérifiez que les affectations de personnel pour les activités des programmes WebSphere MQ Workflow sont compatibles avec les instructions de personnel par défaut de TEL.
- Utilisez des noms courts et simples pour améliorer la lisibilité des modèles de processus migrés. Notez que les noms FDL peuvent ne pas être acceptés comme noms BPEL. L'Assistant de migration vous aide à convertir automatiquement les noms FDL en noms BPEL valides.
L'Assistant de migration produit des constructions BPE dont la syntaxe est correcte même pour les structures WebSphere MQ Workflow qui ne peuvent pas être migrées (activités des programmes PEA ou PES, certaines affectations de personnel dynamiques, etc) et qui doivent être adaptées manuellement aux artefacts BPE exécutables.
Le tableau suivant détaille les règles de correspondance applicables :
Tableau 2. Règles de correspondance
WebSphere MQ Workflow |
WebSphere Integration Developer |
Processus |
Processus avec mode d'exécution longRunning; Liens partenaires pour les interfaces entrantes et sortantes du processus |
Source et Sink |
Variables pour l'entrée et la sortie des processus ; activité Récevoir et activité Répondre |
Activité des programmes |
Activité Appeler |
Activité des processus |
Activité Appeler |
Activité Vide |
Activité FMCINTERNALNOOP |
Bloc |
Etendue avec activités BPEL imbriquées |
Condition de sortie de l'activité |
Activité Pendant (qui contient l'activité proprement dite) |
Condition de démarrage de l'activité |
Condition de jointure de l'activité |
Affectation de personnel de l'activité |
Activité Tâche manuelle |
Conteneur d'entrée et conteneur de sortie de l'activité |
Variables utilisées pour spécifier l'entrée et la sortie de l'activité Appeler |
Connecteur de contrôle ; Condition de transition |
Lier; Condition de transition |
Connecteur de données |
Activité Affecter |
Conteneur de données globales |
Variable |
Remarque : Si possible, commencez le processus de migration avec des petits projets. L'Assistant de migration va simplifier la conversion de vos modèles de processus WebSphere MQ Workflow en modèles de processus Business Process Editor mais sachez que les processus ne peuvent pas être mappés deux par deux quand vous créez un nouveau modèle de programmation. Les syntaxes des langages de spécification des processus sous-jacents (FDL et BPEL) sont parfois communes mais pas totalement identique. Business Process Editor n'aurait aucune utilité sinon. Les services Web constituent une nouvelle technologie prometteuse appelée à remplacer des technologies dépassées.
D'une manière générale, vous devez toujours examiner et modifier, si possible, les artefacts créés. Un effort supplémentaire doit être fait pour réussir la migration ou finir la tâche de migration.
Migration de définitions WebSphere MQ Workflow avec l'Assistant de migration
L'Assistant de migration permet de convertir des définitions FDL de processus
métier que vous avez exportées à partir du composant build time de
WebSphere
MQ Workflow en artefacts WebSphere Process Integration correspondants. Les artefacts générés comprennent des définitions XML pour des objets
métier, définitions WSDL, BPEL, des définitions d'importation et de composants et des définitions TEL.
Remarque : L'Assistant de migration ne couvre pas la migration des :
- Instances d'exécution de WebSphere MQ Workflow
- Applications appelées par un agent d'exécution de programme (PEA) de WebSphere MQ Workflow ou par un serveur d'exécution de processus de WebSphere MQ Workflow (PES pour z/OS)
Suivez les étapes suivantes pour utiliser l'Assistant de migration afin de migrer vos artefacts
WebSphere
MQ Workflow :
- Appelez l'assistant en sélectionnant Fichier -> Importer -> Intégration métier -> WebSphere MQ Workflow - Fichier FDL et cliquez sur Suivant :
OU vous pouvez également ouvrir
l'assistant de migration à partir de la page d'accueil en cliquant sur l'icône Pour ceux qui sont déjà
utilisateurs
pour ouvrir la page Pour ceux qui sont déjà utilisateurs (notez que vous pouvez toujours
revenir à la page d'accueil en cliquant sur Aide -> Bienvenue) :
Cliquez sur Migration
sur le côté gauche de la page Pour ceux qui sont déjà utilisateurs pour ouvrir la page Migration. Sur
la page Migration, sélectionnez l'option Migrer un processus WebSphere MQ
Workflow
.
- L'Assistant de migration apparaît. Entrez le chemin absolu et le nom du fichier FDL dans la zone Sélection de la source ou sélectionnez-les dans le système de fichiers en cliquant sur le bouton Parcourir et recherchez le fichier. Entrez le nom du module dans la zone prévue (vous devez entrer un nom de module dans la zone Nom de module pour pouvoir continuer). Cliquez sur Suivant :
- La page Options de migration s'ouvre. Vous pouvez accepter les options de migration par défaut ou sélectionner une case à cocher pour modifier une option. La sélection de la case à cocher Traiter les conflits de noms comme des erreurs
empêche l'ajout automatique de suffixes qui peuvent entraîner des
erreurs d'interopérabilité. La case à cocher Initialiser les membres de données prédéfinis
ajoute des noeuds supplémentaires au processus afin d'initialiser les membres de données prédéfinis :
- Cliquez sur Terminer.
Une barre de progression située dans la partie inférieure de la boîte de dialogue Migration indique la
progression de la migration. Une fois que le processus de migration est terminé, la boîte de dialogue
Migration disparaît et la fenêtre Résultats de la migration s'ouvre :
Vérification de la migration de WebSphere MQ Workflow
Lorsque l'exécution de l'assistant d'installation échoue, une liste répertoriant les erreurs, les avertissements et/ou les messages informatifs s'affiche dans la fenêtre Résultats de la migration.
Sinon, la fenêtre de l'assistant se fermera dans le cas où la migration aboutit.
La page suivant s'affiche si des messages de migration ont été générés au cours du processus
de migration :
La fenêtre Résultats de la migration répertorie les messages de migration
qui ont été générés au cours du processus de migration.
Sélectionnez un message dans la liste des messages supérieure située en haut pour visualiser d'autres informations le concernant dans la fenêtre inférieure Description du message.
Pour conserver
tous les messages afin de vous y référer ultérieurement, cliquez sur le bouton Générer un
pense-bête pour créer une liste des tâches à effectuer dans la vue des tâches et/ou
cliquez sur le bouton Enregistrer sous... pour sauvegarder les messages
dans un fichier texte dans le système de fichiers.
Pour visualiser l'agenda généré, cliquez sur Fenêtre -> Afficher la vue -> Autre... -> Général -> Tâches, puis sur OK.
La vue Tâches affiche la liste de l'agenda généré à partir du processus
de migration.
Restrictions du processus de migration (à partir de WebSphere MQ Workflow)
Certaines restrictions s'appliquent au processus de migration de WebSphere MQ Workflow.
- La migration de FDL générera des actions d'appel pour les activités UPES et les WSDL correspondants. Cependant, l'environnement d'exécution diffère beaucoup entre IBM WebSphere MQ Workflow et IBM WebSphere Process Server au niveau des techniques utilisées pour mettre en corrélation les messages d'appel et leurs réponses.
- Les moteurs d'exécution d'IBM WebSphere MQ Workflow et d'IBM WebSphere Process Server gère les données non initialisées de façon différente. Alors qu'elles ne provoquaient pas d'erreur dans IBM WebSphere MQ Workflow, IBM WebSphere Process Server renvoie une exception et interrompt l'exécution du processus lors de leur traitement. Pour que les applications migrées s'exécutent correctement dans IBM WebSphere Process Server, vérifiez que toutes les variables et sous-structures sont initialisées avant d'être utilisées par les activités Attribuer, Appeler, Personnel et Répondre.
Chapitre 5. Migration d'artefacts source vers WebSphere Integration Developer à partir de WebSphere Studio Application Developer Integration Edition
Les artefacts source peuvent être migrés à partir de WebSphere Studio Application Developer Integration Edition vers WebSphere Integration Developer. La migration des artefacts source dans une application implique leur migration vers le nouveau modèle de programmation WebSphere Integration Developer afin que les nouvelles fonctionnalités puissent être utilisées. L'application peut alors être redéployée et installée sur le serveur WebSphere Process Server.
Plusieurs fonctions de
WebSphere Business
Integration Server Foundation 5.1 ont été déplacées dans la base de
WebSphere
Application Server 6.x.
Pour des conseils sur la migration de ces fonctions, voir la rubrique :
Conseils pour la migration des extensions de modèles de programmation.
Pour migrer complètement un projet de service WebSphere Studio Application Developer Integration Edition, réalisez trois tâches fondamentales :
- Préparez des artefacts source pour la migration. Vous devrez peut-être effectuer ces actions dans WebSphere Studio Application Developer Integration Edition.
- Utilisez l'assistant de migration ou le script en ligne de commande
WSADIEServiceProjectMigration pour migrer automatiquement les artefacts vers le projet de module
d'intégration métier.
- Utilisez WebSphere Integration Developer pour terminer la migration manuellement. Cela demande de corriger tous les codes Java ne pouvant pas être migrés automatiquement et de vérifier la connexion des artefacts migrés.
Remarque : La migration d'exécution (chemin de mise à niveau) ne sera pas fournie dans
WebSphere
Process Server 6 x et ce mode de migration des artefacts source sera la seule option
pour migrer les projets de service
WebSphere
Studio Integration Edition dans la version 6 x.
Avant de débuter la migration d'artefacts source à partir de WebSphere Studio Application Developer Integration Edition, vérifiez les chemins de migration pris en charge par WebSphere Integration Developer.
L'Assistant de migration permet de migrer un projet de service WebSphere Studio Application Developer Integration Edition version 5.1 (ou supérieure) à la fois. Il ne migrera pas un espace de travail entier.
L'Assistant de migration ne migre pas les applications binaires. Il migre uniquement les artefacts source trouvés dans un projet de service WebSphere Studio Application Developer Integration Edition.
Avant de migrer des artefacts source vers WebSphere Integration Developer depuis WebSphere Studio Application Developer Integration Edition, vous devez vérifier que vous avez bien préparé votre environnement.
Les étapes suivantes décrivent comment préparer votre environnement avant de migrer les artefacts source vers WebSphere Integration Developer depuis WebSphere Studio Application Developer Integration Edition.
- Vérifiez que vous disposez d'une copie de sauvegarde de tout l'espace de travail de la version 5.1 avant d'effectuer la migration.
- Consultez la section relative à la migration dans le Centre de documentation de Rational Application Developer pour déterminer la meilleure manière de migrer les projets non WBI dans votre espace de travail : Migration à partir de WebSphere Studio V5.1, 5.1.1 ou 5.1.2
- Relisez la section sur les services Web dans le Centre de documentation de Rational Application Developer pour obtenir des informations sur les fonctionnalités de service Web fournies par Rational Application Developer : Développement de services Web
- Vérifiez que toutes les fonctions requises de WebSphere Integration Developer sont activées. Si elles ne sont pas activées, vous risquez de ne pas voir les options de menu décrites ci-après. Pour activer les fonctions importantes :
- Dans WebSphere Integration Developer, sélectionnez l'option Fenêtre puis sélectionnez Préférences.
- Ouvrez l'espace de travail puis sélectionnez la catégorie Fonctionnalités.
- Sélectionnez toutes les fonctionnalités dans les catégories suivantes :
- Advanced J2EE
- Java Enterprise
- Integration Developer
- Java Developer
- Web Developer (standard)
- Web Service Developer
- XML Developer
- Cliquez sur
OK.
- Utilisez un nouveau répertoire d'espace de travail pour WebSphere Integration Developer. Il est déconseillé d'ouvrir WebSphere Integration Developer dans un ancien espace de travail WebSphere Studio Application Developer Integration Edition qui contient des projets de service car ces projets doivent d'abord être migrés dans un format lisible par WebSphere Integration Developer. Les étapes à suivre pour le faire sont les suivantes :
- Copiez tous les projets autres que des services depuis l'ancien espace de travail vers le nouveau.
Ne copiez pas les projets 5.1 EJB, Web et EAR créés lors de la création du code de déploiement pour un projet de service 5.1. Le nouveau code de déploiement 6.x sera régénéré
automatiquement à la compilation du module BI.
- Ouvrez WebSphere
Integration Developer dans l'espace de travail vide et importez tous les projets autres que des
services en cliquant sur
Fichier -> Importer -> Général -> Existing Projects into Workspace (Projets existants dans l'espace de travail) et
sélectionnez les projets que vous avez copiés dans le nouvel espace de travail.
- Si le projet est un projet J2EE, migrez-le vers le niveau 1.4 en utilisant l'Assistant de migration de Rational Application Developer :
- Avec le bouton droit, cliquez sur le projet et sélectionnez Migration -> Assistant de migration J2EE.
- Lisez les avertissements sur la première page et, sauf autre instruction, cliquez sur
Suivant.
- Vérifiez que le projet J2EE est coché dans la liste des projets. Laissez cochées les options Migrer la structure de projet et Migrer le niveau de spécification J2EE. Sélectionnez J2EE version 1.4 et Serveur
de processus WebSphere v6.1 du serveur cible.
- Sélectionnez toutes les autres options appropriées pour votre projet J2EE et cliquez sur Terminer. Si cette étape s'accomplit normalement, un message vous indiquera que la migration a réussi.
- S'il existe des erreurs dans le projet J2EE après la migration, vous devrez supprimer toutes les entrées de chemin de classe qui référencent des fichiers jar v5 ou des bibliothèques et ajouter les bibliothèques Bibliothèque système JRE et Cible de serveur WPS dans le chemin de classe (voir ci-après). Ceci devrait résoudre la plupart de ces erreurs.
- Pour les projets EJB
WebSphere
Business Integration contenant des données CMM (Extended Messaging) ou CMP/A (Container Managed
Persistence over Anything), les fichiers de descripteurs d'extension jar EJB
IBM doivent être
migrés une fois le projet 5.1 importé dans l'espace de travail 6.x.
Voir "Migration de projets EJB WebSphere Business Integration" pour plus d'informations.
- Modifiez le chemin de classe pour chaque projet non-service importé dans l'espace de travail.
Pour ajouter les bibliothèques JRE et WebSphere Process Server dans le chemin de classe, avec le bouton droit, cliquez sur le projet importé et sélectionnez Propriétés.
Allez à l'entrée Chemin de compilation Java et sélectionnez l'onglet Bibliothèques.
Ensuite, exécutez les opérations suivantes :
- Sélectionnez Ajouter une bibliothèque -> Bibliothèque système
JRE -> Autre JRE - WPS Server v6.1 JRE -> Terminer.
- Ensuite, sélectionnez Ajouter une bibliothèque -> Cible de serveur WPS -> Configurer le chemin de classe du serveur WPS -> Terminer.
- Par défaut, WebSphere Integration Developer génère le code de déploiement lors de la génération.
- Pour migrer tous les fichiers .bpel d'un projet de service, vous devez vérifier que tous les fichiers .wsdl et .xsd référencés par les fichiers .bpel peuvent être résolus dans un projet Business Integration dans le nouvel espace de travail :
- Si les fichiers .wsdl et/ou .xsd sont dans le même projet de service que le fichier .bpel, aucune autre action n'est requise.
- Si les fichiers .wsdl et/ou .xsd sont dans un autre projet de service que celui que vous migrez, les artefacts 5.1 doivent être réorganisés avec WebSphere Studio Application Developer Integration Edition avant la migration car les projets de module Business Integration ne partagent pas les artefacts.
Vous pouvez réorganiser les artefacts 5.1 de deux manières :
- Dans WebSphere Studio Application Developer Integration Edition, créez un nouveau projet Java contenant tous les artefacts communs. Placez tous les fichiers .wsdl et .xsd qui sont partagés par plusieurs projets de service dans ce nouveau projet Java.
Ajoutez sur ce nouveau projet Java une dépendance avec tous les projets de service qui utilisent ces artefacts communs. Dans WebSphere Integration Developer, créez un nouveau projet de bibliothèque Business Integration portant le même nom que le projet Java 5.1 partagé avant de migrer les projets de service. Copiez manuellement les anciens fichiers .wsdl et .xsd depuis le projet Java v5.1 partagé vers le dossier de ce nouveau projet de bibliothèque BI. Ceci doit être fait avant de migrer les projets de service BPEL.
- Vous pouvez aussi garder une copie locale des fichiers partagés .wsdl et .xsd dans chaque projet de service pour qu'il n'existe pas de dépendances entre les projets de service.
- Si les fichiers .wsdl et/ou .xsd sont dans un autre type de projet (habituellement d'autres projets Java), vous devez créer un projet de type Bibliothèque Business Integration portant le même nom que le projet 5.1. Vous devez également configurer le chemin de classe du nouveau projet de bibliothèque en y ajoutant les entrées éventuelles du projet Java 5.1. Ce type de projet est utile pour stocker des artefacts partagés.
Vous êtes maintenant prêt à commencer le processus de migration.
Remarques relatives au processus de migration de l'artefact source
Il existe un certain nombre de remarques relatives au processus de migration d'artefact
source de WebSphere
Studio Application Developer Integration Edition.
Les pratiques suivantes montrent comment concevoir des services de WebSphere Studio Application Developer Integration Edition pour assurer leur migration vers le nouveau modèle de programmation :
- Essayez d'utiliser l'activité Affecter autant que possible (par
opposition au service de conversion qui est nécessaire uniquement lorsqu'une transformation avancée est requise). Vous devez utiliser cette méthode car un composant intermédiaire doit être créé pour que le module SCA appelle un service de transformateur. De plus, il n'existe pas de prise en charge de l'outil spécifique dans WebSphere Integration Developer pour les services de transformateur créés avec la version 5.1 (vous devez utiliser l'éditeur WSDL ou XML pour modifier le XSLT intégré dans le fichier WSDL si vous devez changer le comportement du service de transformateur).
- Spécifiez une partie par message WSDL et par spécification d'interopérabilité de services Web (WS-I), ainsi que le style préféré de la version 6.x.
- Utilisez le style doc-literal WSDL car il s'agit du style préféré dans la version 6.x.
- Vérifiez que tous les types complexes disposent d'un nom et qu'ils peuvent être identifiés de façon unique par leur nom et espace de nom cible. Méthode recommandée pour définir des types complexes et des éléments qui les composent (la définition du type complexe est suivie de celle d'un élément qui utilise ce type) :
<schema
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<complexType name="Duration">
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
<element name="DurationElement" type="tns:Duration"/>
</schema>
L'exemple suivant montre un type complexe anonyme à
éviter, car il peut provoquer des incidents lorsqu'un SDO est sérialisé en XML
(élément contenant une définition de type complexe anonyme) :
<schema
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<element name="DurationElement">
<complexType>
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
</element>
</schema>
- Si vous publiez un service pour des clients externes, générez un code de déploiement
de service à l'aide des services Web
IBM
(par opposition à Apache SOAP/HTTP) car les services Web
IBM
sont directement pris en charge dans la version 6.x, contrairement aux services Web Apache.
- Il existe deux façons d'organiser des fichiers WSDL et
XSD dans la version 5.1 pour réduire la réorganisation que vous devez effectuer
pendant la migration. Dans la version 6.x, les artefacts partagés tels que les
fichiers WSDL et XSD doivent être situés dans les projets BI
(modules Business Integration et Bibliothèques) afin
d'être référencés par un service BI :
- Conservez tous les fichiers WSDL partagés par plusieurs projets de service dans un projet Java que les projets de service peuvent référencer. Lors de la migration vers la version 6.x, vous
créerez une bibliothèque Business Integration du même nom que le projet
Java 5.1 partagé. Copiez tous les artefacts du projet Java 5.1 partagé vers la bibliothèque de sorte que l'Assistant de migration puisse résoudre les artefacts lorsqu'il migre les projets de service utilisant ces artefacts.
- Conservez une copie locale de tous les fichiers WSDL/XSD qu'un projet de service référence dans le projet de service lui-même. Les projets de service WebSphere Studio Application Developer Integration Edition seront migrés vers un module Business Integration dans WebSphere Integration Developer. Un module ne peut pas avoir de dépendance sur d'autres modules (un projet de service ayant des dépendances sur un autre projet de service pour le partage des fichiers WSDL ou XSD ne migrera pas correctement).
- Evitez d'utiliser l'API Generic Messaging de
Business Process Choreographer (Generic MDBs) car elle n'est pas fournie dans
la version 6.x. Une interface MDB offrant une connexion tardive
n'est pas disponible dans la version 6.x.
- Utilisez l'API EJB générique de Business Process Choreographer par opposition à l'appel des beans de session générés spécifiques à une version particulière d'un processus. Ces beans de session ne seront
pas générés dans la version 6.x.
- Si vous possédez un processus métier avec plusieurs réponses
pour la même opération, assurez-vous que, si l'une d'elles a des paramètres client, toutes les réponses
pour cette opération ont les mêmes paramètres client, étant donné que dans la version 6.x, un
seul ensemble de paramètres client par réponse d'opération est pris en charge.
- Concevez les fragments Java BPEL selon les directives suivantes :
- Evitez l'envoi de paramètres WSIFMessage à toute classe Java personnalisée. Essayez de ne pas dépendre du format de données WSIFMessage dès que cela est possible.
- Evitez, si possible, l'utilisation d'API métadonnées WSIF.
- Dans la mesure du possible, évitez de créer des services EJB ou Java descendants car le squelette Java/EJB généré à partir des messages et des types de port WSDL dépendra des classes WSIF (par exemple : WSIFFormatPartImpl). Créez d'abord les interfaces Java/EJB et créez un service autour de la classe Java ou de l'EJB (approche ascendante).
- Evitez de créer ou d'utiliser des interfaces WSDL qui référencent le type soapenc:Array, dans la mesure où ce type d'interface n'est pas pris en charge en mode natif dans le modèle de programmation SCA.
- Evitez de créer des types de message dont l'élément de niveau supérieur est un type de tableau (l'attribut maxOccurs est supérieur à un), dans la mesure où ce type d'interface n'est pas pris en charge en mode natif dans le modèle de programmation SCA.
- Définissez les interfaces WSDL de manière précise (dans la mesure du possible, évitez les types complexes XSD qui référencent le type xsd:anyType).
- Pour tout WSDL et XSD généré à partir d'un EJB ou d'un bean
Java,
vérifiez que l'espace de nom cible est unique (le nom du module et celui de la classe
Java sont
représentés par l'espace de nom cible) afin d'éviter des conflits lors de la migration vers
WebSphere
Process Server 6.x. Dans
WebSphere
Process Server 6.x, deux définitions WSDL/XSD différentes de nême nom et de même espace
de nom cible ne sont pas autorisées. Cette situation se présente fréquemment lorsque l'Assistant de service Web ou la commande Java2WSDL est utilisé, mais que l'espace de nom cible n'est pas indiqué explicitement (l'espace de nom cible doit être unique pour le nom du module de l'EJB ou du bean Java, mais pas pour la classe elle-même. Des incidents peuvent donc survenir lorsqu'un service Web est généré pour plusieurs EJB ou beans Java d'un même module). La solution consiste à définir un package personnalisé pour le mappage de l'espace de nom dans l'Assistant de service Web. Vous pouvez aussi utiliser l'option de
ligne de commande Java2WSDL -namespace pour vous assurer que l'espace de nom des fichiers générés correspond uniquement à la classe concernée.
- Essayez toujours d'utiliser un espace de nom unique pour chaque fichier WSDL. Selon la
spécification WSDL 1.1, l'importation de deux fichiers WSDL différents ayant le même espace de nom
fait l'objet de certaines limitations. Dans WebSphere
Integration Developer 6.x, ces limitations sont renforcées.
Migration des projets de service avec l'assistant WebSphere Integration Developer Migration
L'Assistant de migration de WebSphere Integration Developer Migration permet de migrer des projets de service.
Remarque :
- Vous devez migrer les projets de service dans l'ordre de dépendance. Par
exemple, si un BPEL dans un projet de service A effectue un appel de processus
à processus vers un BPEL de projet de service B, le projet de service B doit être migré avant le projet de service A. Faute de quoi, l'appel de processus à processus ne peut pas être configuré correctement.
- Il n'est pas obligatoire de désactiver la génération automatique dans WebSphere Integration Developer Migration 6.0.2 et version suivante car la génération automatique est désactivée automatiquement lors du processus de migration.
L'Assistant de migration exécute les opérations suivantes :
- Création d'un module Business Integration (vous définissez vous-même son nom)
- Migration des entrées de chemin de classe du projet de service vers le nouveau module
- Copie de tous les artefacts source de WebSphere Business Integration Server Foundation depuis le projet source sélectionné vers le module
- Migration des extensions BPEL dans des fichiers WSDL
- Migration des processus métier (fichiers .bpel) de BPEL4WS version 1.1 vers la nouvelle version prise en charge par WebSphere Process Server, qui repose sur BPEL4WS version 1.1, avec les fonctionnalités majeures des spécifications du langage BPEL version 2.0 à venir
- Création d'un composant SCA pour chaque .bpel
- Création d'un fichier de contrôle .mon pour chaque processus BPEL afin de préserver le comportement de contrôle par défaut de WebSphere Studio Application Developer Integration Edition (si nécessaire)
- Création d'importations et d'exportations en fonction des options de déploiement choisies dans WebSphere Studio Application Developer Integration Edition
- Connecte le composant BPEL à ses liens partenaires (importations, exportations et composants Java).
Pour migrer des projets de service au moyen de l'assistant de migration deWebSphere Integration Developer, procédez comme suit :
- Appelez l'assistant en sélectionnant Fichier -> Importer -> Intégration métier -> WebSphere
Studio Application Developer Integration Edition - Projet de service et cliquez sur Suivant :
OU vous pouvez également ouvrir l'assistant de migration à partir de la page d'accueil
en cliquant sur l'icône Pour ceux qui sont déjà utilisateurs
pour ouvrir la page Pour ceux qui sont déjà utilisateurs (notez
que vous pouvez toujours revenir à la page d'accueil en cliquant sur Aide -> Bienvenue) :
Cliquez sur Migration
sur le côté gauche de la page Pour ceux qui sont déjà utilisateurs pour ouvrir la page Migration. Sur
la page Migration, sélectionnez l'option Migrer un projet de service
Integration Edition 5.1
.
- L'Assistant de migration apparaît. Entrez le chemin d'accès à la sélection de la source ou cliquez sur le bouton Parcourir pour le rechercher. Entrez également le nom de module de l'emplacement du projet de service WebSphere Studio Application Developer Integration Edition à migrer :
Remarque : Il est conseillé de choisir le nom du projet de service comme nom du module car, si l'espace de travail contient d'autres projets WebSphere Studio Application Developer Integration Edition qui dépendent de ce projet, vous n'aurez pas besoin de mettre à jour les chemins de classe des projets dépendants après les avoir importés dans WebSphere Integration Developer.
- Dans les options de migration, cochez la case Conserver les fragments
Java
BPEL d'origine dans les commentaires :
Cliquez sur
Terminer.
- Une fois le processus de migration terminé, la fenêtre Résultats de la migration s'affiche :
Un fichier journal contenant ces messages de migration est automatiquement
généré dans le dossier .metadata de l'espace de travail 6.x. Ce
fichier journal est appelé ".log".
Quand l'Assistant de migration a terminé, compilez le module Business Integration créé et essayez de résoudre les erreurs de compilation éventuelles. Vérifiez tous les fichiers .bpel migrés. Vérifiez qu'ils sont totalement migrés et qu'ils peuvent être ouverts dans WebSphere Integration Developer BPEL Editor. Certains fragments BPEL Java ne peuvent pas être migrés automatiquement. Si vous constatez des erreurs dans les fragments Java BPEL, reportez-vous à la section "Migration vers le modèle de programmation SCA" pour
connaître les étapes nécessaires à la résolution de ces erreurs. Si vous avez utilisé l'Assistant de migration pour migrer un projet de service vers un module BI, ouvrez l'éditeur de dépendances de module pour vérifier que les dépendances sont bien définies. Pour cela, basculez dans la perspective
Business Integration et cliquez deux fois sur le projet de module Business Integration. Vous pouvez ensuite ajouter des dépendances dans les projets de bibliothèque d'intégration métier, dans les projets, Java et dans les projets J2EE.
Migration des projets de service à l'aide de WSADIEServiceProjectMigration
La commande WSADIEServiceProjectMigration permet la migration de projets de service.
La commande de migration exécute les opérations suivantes :
- Création d'un module Business Integration (vous définissez vous-même son nom)
- Migration des entrées de chemin de classe du projet de service vers le nouveau module
- Copie de tous les artefacts source de WebSphere Business Integration Server Foundation depuis le projet source sélectionné vers le module
- Migration des extensions BPEL dans des fichiers WSDL
- Migration des processus métier (fichiers .bpel) de BPEL4WS version 1.1 vers la nouvelle
version prise en charge par
WebSphere Process
Server, qui repose sur BPEL4WS version 1.1, avec les fonctionnalités majeures des spécifications du
langage BPEL version 2.0 à venir
- Création d'un composant SCA pour chaque .bpel
- Création d'un fichier de contrôle .mon pour chaque processus BPEL afin de préserver le comportement de contrôle par défaut de WebSphere Studio Application Developer Integration Edition (si nécessaire)
- Création d'importations et d'exportations en fonction des options de déploiement choisies dans WebSphere Studio Application Developer Integration Edition
- Connexion du composant BPEL à ses liens partenaires (importations, exportations et composants Java).
Remarque : Vous devez migrer les projets de service dans l'ordre de dépendance.
Par exemple, si un BPEL dans un projet de service A effectue un appel de processus
à processus vers un BPEL de projet de service B, le projet de service B doit être migré avant
le projet de service A. Faute de quoi, l'appel de processus à processus ne peut pas être
configuré correctement.
Pour exécuter le script WSADIEServiceProjectMigration, procédez
comme suit :
- Repérez le script en ouvrant le dossier partagé spécifié pendant l'installation de
WebSphere
Integration Developer. Par exemple, le script sera situé sous :
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0
- Appelez le script comme suit : WSADIEServiceProjectMigration
-e rép_eclipse -s rép_projet_source -d espacedetravail [-t nom_projet_cible]
[-preserveSnippets true|false] [-debug]
Définitions de paramètre :
- -e rép_eclipse
- Emplacement de votre dossier Eclipse (runtime Eclipse).
- -s rép_projet_source
- Chemin complet du projet de service de
WebSphere
Studio Application Developer Integration Edition 5.1.
- -d espacedetravail
- Espace de travail dans lequel le nouveau module Business Integration sera créé.
- -t nom_projet_cible
- Nom du nouveau module Business Integration à créer. La valeur par défaut est identique à celle du
projet WebSphere
Studio Application Developer Integration Edition 5.1 en cours de migration.
- -preserveSnippets flag
- Active ou désactive la préservation des fragments BPEL
Java
existants tel que commentés. La valeur par défaut est true.
- -debug flag
- Active la sortie de débogage.
Par exemple :
WSADIEServiceProjectMigration -e WID_HOME\eclipse" -d "\myWIDworkspace"
-s "\\MyServiceProject" -t "MyBIModuleName" -preserveSnippets false -debug
- Une fois la commande exécutée, lancez le nouvel espace de travail dans
WebSphere
Integration Developer.
- Générez le module Business Integration créé et essayez de résoudre les éventuelles
erreurs de génération. Vérifiez tous les fichiers .bpel migrés. Vérifiez qu'ils sont totalement migrés et qu'ils peuvent être ouverts dans WebSphere Integration Developer BPEL Editor. Certains fragments BPEL Java ne peuvent pas être migrés automatiquement. Si vous constatez des erreurs dans les fragments Java BPEL, reportez-vous à la section "Migration vers le modèle de programmation SCA pour
connaître les étapes nécessaires à la résolution de ces erreurs.
- Ouvrez l'éditeur de dépendances de modules afin de s'assurer que les dépendances sont correctement
définies. Pour cela, basculez dans la perspective Business Integration et cliquez deux fois sur le
projet de module Business Integration. Vous pouvez ensuite ajouter des dépendances dans les projets de bibliothèque d'intégration métier, dans les projets, Java et dans les projets J2EE.
Fin de la migration de l'application
Lorsque l'Assistant de migration a migré les artefacts vers le nouveau module Business Integration, les artefacts doivent être liés pour créer une application conforme au modèle SCA. Notez que même si l'assistant de migration tente de migrer les artefacts, il est conseillé d'effectuer une vérification manuelle. Vous pouvez utiliser les informations de cette section pour vérifier que la migration a réussi.
- Ouvrez WebSphere Integration Developer et passez dans Business Integration. Vous pouvez voir le ou les modules créés par l'Assistant de migration (un module par projet de service migré). Le premier artefact listé sous le projet de module est le fichier d'assemblage du module (même nom que le module).
- Double-cliquez sur le fichier d'assemblage pour l'ouvrir dans
l'éditeur d'assemblage et créer des composants SCA que vous pourrez relier
ensemble pour obtenir des fonctionnalités identiques à celles de l'application version 5.1. S'il existait des processus BPEL dans le projet de service WebSphere Studio Application Developer Integration Edition, l'Assistant de migration doit avoir créé des composants SCA par défaut pour chacun d'eux dans l'éditeur d'assemblage.
- Sélectionnez un composant puis ouvrez la vue Propriétés. Vous verrez les propriétés Description, Détails et Implémentation et vous pourrez les modifier.
Certains projets requièrent
des reconnexions après la migration afin de reconnecter les services comme ils étaient dans la
version 5.1. Les informations suivantes décrivent comment relier manuellement l'application en utilisant les outils disponibles dans WebSphere Integration Developer :
Création de composants SCA et d'importations SCA pour les services dans l'application en vue d'une reconnexion
Tous les processus métier migrés doivent être connectés à leurs partenaires métier. Un composant SCA ou une importation SCA doit être créé pour tous les autres types de service. Pour les projets de service WebSphere Studio Application Developer Integration Edition qui interagissent avec des systèmes ou des entités externes au projet, un import SCA peut être créé pour le projet migré afin d'accéder à ces entités en tant que services, en fonction du modèle de programmation SCA.
Remarque : L'utilitaire de migration tente d'effectuer cette tâche automatiquement mais vous
pouvez vous reporter aux informations suivantes pour vérifier les tâches réellement exécutées par
l'outil.
Pour les projets de service WebSphere Studio Application Developer Integration Edition qui interagissent avec des entités internes au projet (par exemple un processus métier, un service de transformateur ou une classe Java), une importation SCA peut être créé afin d'accéder à ces entités en tant que services, en fonction du modèle de programmation SCA.
Les sections suivantes fournissent d'autres détails sur l'importation SCA ou les composants SCA à créer selon le type de service à migrer.
Migration d'un service Java
Vous pouvez migrer un service Java vers un composant Java SCA.
Si le projet de service
WebSphere Studio
Application Developer Integration Edition dépend d'autres projets
Java,
copiez les projets existants dans le répertoire du nouvel espace de travail et importez les dans
WebSphere
Integration Developer à l'aide de l'assistant
Fichier -> Importer -> Général -> Existing Projects into Workspace (Projets existants dans l'espace de travail).
Dans WebSphere Studio Application Developer Integration Edition, quand vous créez un nouveau service Java depuis une classe Java existante, les options suivantes sont proposées :
- Créer des schémas XSD pour les types de données complexes :
- Dans le fichier WSDL de l'interface
- Comme nouveau fichier pour chaque type de données
- Prendre en charge la gestion d'erreurs :
- Générer une erreur
- Ne pas générer d'erreur
- Autres détails sur le service à générer comme les noms des liaisons et des services.
de nouveaux composant sont mis à disposition, ils offrent de nouvelles fonctionnalités telles que le mappage de données, la médiation par interface, des machines métier, des sélecteurs, des
règles métier etc. Vous devez d'abord déterminer si certains de ces nouveaux composants peuvent remplacer un composant personnalisé Java. Si cela n'est pas possible, suivez la procédure de migration décrite ci-après.
Importez le projet de service à l'aide de l'Assistant de migration. Cela va créer un module Business Integration contenant les messages WSDL, les types de port, les liaisons et les services créés dans WebSphere Studio Application Developer Integration Edition.
Dans Business Integration, développez le module pour voir son contenu. Pour ouvrir l'éditeur d'assemblage, double-cliquez sur le premier élément sous le projet de module (même nom que le projet).
Vous disposez des options suivantes :
Création d'un composant personnalisé Java (option 1)
La technique de migration recommandée est d'utiliser le type de composant WebSphere Integration Developer Java qui permet de représenter le service Java en tant que composant SCA. Au cours de la migration, vous devez écrire un code Java pour faire la conversion entre le style d'interface Java SCA et le style d'interface Java existant du composant.
Pour créer le composant Java personnalisé, procédez comme suit :
- Sous le projet de module, développez Interfaces et sélectionnez l'interface WSDL créée pour cette classe Java
dans WebSphere Studio
Application Developer Integration.
- Faites glisser cette interface dans l'éditeur d'assemblage. Une boîte de dialogue vous demande de sélectionner le type de composant à créer. Sélectionnez Composant sans type d'implémentation et cliquez sur OK.
- Un composant générique apparaît dans le diagramme de l'assemblage. Sélectionnez-le et passez dans la vue Propriétés.
- Dans l'onglet Description, vous pouvez remplacer le nom et le nom d'affichage du composant par un nom plus descriptif.
- Dans l'onglet Détails, vous verrez que ce
composant a une interface, celle que vous avez fait glisser dans
l'éditeur d'assemblage.
- Vérifiez que la classe Java à laquelle vous tentez d'accéder se trouve dans le chemin de classe du projet de service, si elle n'est pas dans le projet de service lui-même.
- Avec le bouton droit, cliquez sur le projet de module et sélectionnez
Ouvrir l'éditeur de dépendances. Dans la section
Java, veillez à ce que le projet contenant l'ancienne classe
Java
soit répertorié. Dans le cas contraire, ajoutez-le
en cliquant sur Ajouter....
- Dans l'éditeur d'assemblage, cliquez avec le bouton droit de la souris sur le composant que vous venez de créer et sélectionnez Générer l'implémentation... -> Java Sélectionnez ensuite le package dans lequel l'implémentation Java sera générée.
Ceci crée une structure de service Java compatible avec l'interface WSDL et le modèle de programmation SCA dans laquelle les types complexes sont représentés par un objet commonj.sdo.DataObject et les types simples sont représentés par des objets Java équivalents.
Les exemples de code suivants montrent :
- les définitions correspondantes issues de l'interface WSDL 5.1 ;
- les méthodes Java de WebSphere Studio
Application Developer Integration Edition 5.1 qui correspondent à l'interface WSDL
- les méthodes Java de
WebSphere
Integration Developer 6.x pour la même interface WSDL
Le code suivant montre les définitions correspondantes issues de l'interface WSDL 5.1 :
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://migr.practice.ibm.com/"
xmlns:xsd1="http://migr.practice.ibm.com/">
<complexType name="StockInfo">
<all>
<element name="index" type="int"/>
<element name="price" type="double"/>
<element name="symbol" nillable="true"
type="string"/>
</all>
</complexType>
</schema>
</types>
<message name="getStockInfoRequest">
<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
<part name="result" type="xsd1:StockInfo"/>
</message>
<operation name="getStockInfo" parameterOrder="symbol">
<input message="tns:getStockInfoRequest"
name="getStockInfoRequest"/>
<output message="tns:getStockInfoResponse"
name="getStockInfoResponse"/>
</operation>
Le code suivant affiche les méthodes Java de WebSphere Studio Application Developer Integration Edition 5.1 qui correspondent à l'interface WSDL :
public StockInfo getStockInfo(String symbol)
{
return new StockInfo();
}
public void setStockPrice(String symbol, float newPrice)
{
// set some things
}
Le code suivant montre les méthodes
Java de
WebSphere
Integration Developer 6.x pour la même interface WSDL :
public DataObject getStockInfo(String aString) {
//TODO Needs to be implemented.
return null;
}
public void setStockPrice(String symbol, Float newPrice) {
//TODO Needs to be implemented.
}
Vous devez ensuite remplir les lignes de code contenant "//TODO" dans la classe d'implémentation Java générée. Vous avez deux options :
- Transférer la logique de la classe Java d'origine vers cette nouvelle classe en l'adaptant aux objets DataObjects.
- C'est l'option recommandée si vous avez choisi l'approche partant du haut dans WebSphere Studio Application Developer Integration Edition et que vous voulez que votre composant Java puisse gérer les paramètres DataObject. Cette modification est nécessaire car les classes Java générées à partir des définitions WSDL dans WebSphere Studio Application Developer Integration Edition ont des dépendances WSIF qui doivent être éliminées.
- Créez une instance privée de l'ancienne classe Java à l'intérieur de la nouvelle classe Java et écrivez un code pour :
- convertir tous les paramètres de la classe d'implémentation Java générée en paramètres compatibles avec l'ancienne classe Java ;
- appeler l'instance privée de l'ancienne classe Java avec les paramètres convertis ;
- convertir la valeur de retour de l'ancienne classe Java dans le type de valeur de retour déclarée par la méthode d'implémentation Java générée.
- Cette option est recommandée pour les scénarios de consommation dans lesquels les proxy de
service WSIF doivent être utilisés par des nouveaux composants
Java
de type 6.x.
Quand vous avez terminé l'une des options ci-dessus, vous devez reconnecter le service Java.
Comme il ne doit exister aucune référence, il vous suffit de reconnecter l'interface du composant Java :
- Si ce service est appelé par un processus métier situé dans le même module,
vous devez créer une connexion entre la référence de processus métier
appropriée et l'interface de ce composant
Java.
- Si ce service est appelé par un processus métier situé dans un
autre module, créez une exportation avec liaison
SCA et à partir de l'autre module, effectuez un
glisser-déposer de cette exportation vers l'éditeur d'assemblage de
ce module pour créer l'importation avec liaison
SCA correspondante. Connectez la référence de processus métier appropriée
à cette importation.
- Si ce service a été publié dans WebSphere Studio Application Developer Integration Edition pour faire l'objet d'une
exposition externe, voir la section "Création d'exportations SCA afin
d'accéder au service migré" pour savoir comment le publier de nouveau.
Création d'un service Web Java (option 2)
Les services Web Application Developer Rational vous permettent de créer un service Web basé sur une classe Java.
Remarque : Cette option demande de configurer un runtime de service Web dans WebSphere Integration Developer avant d'appeler l'assistant de service Web.
Si vous avez choisi l'approche ascendante dans WebSphere Studio Application Developer Integration Edition pour générer WSDL sur la base d'une classe Java, procédez comme suit :
- Créez un nouveau projet Web et copiez la classe Java sur laquelle vous voulez baser un service dans le dossier source Java de ce projet Web.
- Avec le bouton droit, cliquez sur le projet d'application métier qui contient la classe Java sur laquelle le service sera basé.
- Sélectionnez Propriétés, accédez aux propriétés Serveur
et vérifiez que Environnement d'exécution cible a la valeur WebSphere
Process Server v6.1 et que Default server (Serveur par défaut)
correspond au serveur WebSphere Process Server v6.1 installé.
- Démarrez le serveur de test et déployez l'application sur ce serveur puis vérifiez que le lancement a réussi.
- Ensuite, avec le bouton droit, cliquez sur la classe
Java
sur laquelle vous voulez baser votre nouveau service puis sélectionnez
Services Web -> Créer un service Web.
- Pour Type de service Web, sélectionnez Service Web de bean Java et décochez l'option Démarrer le service Web dans le projet Web, sauf si vous voulez déployer le service Web immédiatement. Vous pouvez aussi choisir de générer un proxy client. Cliquez sur Suivant.
- La classe Java sur laquelle vous avez cliqué apparaît. Cliquez sur Suivant.
- Vous devez maintenant configurer les options de déploiement du service. Cliquez sur Editer....
Sélectionnez WPS Server v6.1 comme type de serveur et
IBM WebSphere et J2EE version 1.4
comme exécution du service Web. Si vous ne parvenez pas à sélectionner une combinaison
valide, reportez-vous à la section "Préparation à la migration" pour plus d'informations
sur la migration des projets J2EE vers le niveau v1.4. Cliquez sur OK.
- Pour le projet de service, entrez le nom du projet Web. Sélectionnez aussi le projet EAR approprié. Cliquez sur Suivant. Notez que ceci peut demander quelques minutes d'attente.
- Dans le volet d'identification du bean Java du service Web, sélectionnez le fichier WSDL qui contiendra les définitions WSDL. Choisissez les méthodes qui seront disponibles dans le service Web et le style/codage approprié (Document/Literal, RPC/Literal, ou RPC/Encoded). Sélectionnez l'option Définir le mappage personnalisé du package vers l'espace de nom, puis un espace de nom considéré unique par la classe Java en cours de migration pour tous les modules Java utilisés par l'interface de cette classe Java (l'espace de nom par défaut attribué au nom du package est unique, ce qui peut provoquer des conflits si vous créez un autre service Web utilisant les mêmes classes Java). Le cas échéant, renseignez les autres paramètres.
- Cliquez sur Suivant. Dans le panneau Web Service package to namespace mapping (Package du service Web pour le mappage de l'espace de nom), cliquez sur Ajouter et,
sur la ligne créée, entrez le nom du package du bean Java,
puis ajoutez l'espace de nom personnalisé qui identifie uniquement cette classe Java.
Continuez à ajouter des mappages pour tous les modules Java utilisés par l'interface du bean Java.
- Cliquez sur Suivant. Notez que ceci peut demander quelques minutes d'attente.
- Cliquez sur Terminer. Après avoir terminé l'assistant, copiez le fichier WSDL généré qui définit le service Java pour le projet de module Business Integration si le projet de service est un utilisateur du service Java. Vous le trouverez dans le projet Web de routeur généré, dans le dossier WebContent/WEB-INF/wsdl. Réactualisez/recompilez le projet de module Business Integration.
- Passez dans Business Integration et développez le module puis la catégorie logique Ports de service Web.
- Sélectionnez le port créé dans les étapes précédentes et faites-le glisser dans l'éditeur d'assemblage puis sélectionnez Import avec connexion de service Web. Sélectionnez l'interface WSDL de la classe Java si cela vous est demandé.
Le composant SCA qui consommait le composant Java dans la version 5.1 peut maintenant être connecté à cet import pour terminer les étapes de migration de la reconnexion manuelle.
Notez que l'interface peut être légèrement différente de celle de la version 5.1 et qu'il vous faudra peut-être insérer un composant de médiation d'interface entre le consommateur 5.1 et le nouvel import. Pour cela, cliquez sur l'outil Connexion dans l'éditeur d'assemblage et connectez le composant source SCA à cette nouvelle importation avec liaison de service Web. Comme les interfaces sont différentes, un message vous indiquera que les noeuds source et cible ont des interfaces différentes. Choisissez de créer un mappage d'interfaces entre le noeud source et le noeud cible. Double-cliquez sur le composant de mappage créé dans l'éditeur d'assemblage. L'éditeur d'assemblage s'ouvre.
Voir le Centre de documentation pour savoir comment créer un mappage d'interfaces.
Si vous avez choisi l'approche partant du bas dans WebSphere Studio Application Developer Integration Edition pour créer des classes Java depuis une définition WSDL, procédez comme suit :
- Créez un nouveau projet Web et copiez le fichier WSDL que vous voulez associer au squelette Java du dossier source de ce projet Web.
- Avec le bouton droit, cliquez sur le fichier WSDL contenant le type de port à partir duquel vous voulez générer le squelette Java puis sélectionnez Services Web -> Generate Java bean skeleton (Générer le squelette de bean Java).
- Choisissez le type de service Web Service Web de bean Java squelette et terminez l'assistant.
Une fois l'assistant terminé, vous devez disposer de classes Java qui implémentent l'interface du service et ne dépendent pas des API WSIF.
Avantages et inconvénients pour chacune des options de nouvelle connexion d'un service
Java
Il existe des avantages et des inconvénients pour chacune des options
de nouvelle connexion d'un service
Java.
La liste suivante décrit les options ainsi que ses avantages et ses inconvénients :
- La première option est censée donner de meilleures performances pendant l'exécution car l'appel d'un service Web est plus lent que l'appel d'un composant Java.
- La première option peut propager le contexte alors que l'appel d'un service Web ne propage pas le contexte de la même manière.
- La deuxième option n'implique pas la création d'un code personnalisé.
- Il est possible que la deuxième option ne soit pas disponible pour certaines définitions d'interface Java dans la mesure où la génération d'un service Java est soumise à des restrictions. Voir la documentation de Rational Application Developer à l'adresse suivante : Limitations of Web services
- La deuxième option peut entraîner la modification de l'interface, et par conséquent, la modification du client SCA.
- La deuxième option nécessite qu'un serveur
WebSphere
Process Server 6.x soit installé et configuré de manière à fonctionner avec
WebSphere
Integration Developer.
Pour connaître les environnements d'exécution installés qui sont configurés pour fonctionner avec WebSphere Integration
Developer, accédez à Fenêtre -> Préférences -> Serveur -> Installed Runtimes (Environnements d'exécution installés) et
sélectionnez l'entrée WebSphere Process Server v6.1 le cas
échéant ; assurez-vous qu'elle pointe vers l'emplacement d'installation du produit.
Vérifiez que cette entrée est activée si le serveur existe et désactivée si le serveur n'est pas installé. Vous pouvez également cliquer sur Ajouter... pour
ajouter un autre serveur.
- Si le composant Java a été généré dans WebSphere Studio Application Developer Integration Edition à l'aide de l'approche descendante dans laquelle le squelette Java a été généré à partir d'un WSDL, les paramètres à l'intérieur et à l'extérieur de cette classe Java mettront probablement WSIFFormatPartImpl sous forme de sous-classe. Dans ce cas, choisissez la première option pour générer un nouveau squelette Java de style SCA à partir des WSDL/XSD d'origine ou la deuxième option pour générer un nouveau squelette Java générique (indépendant des API DataObject ou WSIF) à partir de l'interface WSDL d'origine.
Migration d'un service EJB
Vous pouvez migrer un service EJB vers une importation SCA avec liaison de bean session sans état.
Si le projet de service
WebSphere Studio
Application Developer Integration Edition était dépendant d'un autre projet EJB, d'un client EJB ou d'un
projet Java,
importez ces projets existants à l'aide de l'assistant :
Fichier -> Importer -> Général -> Existing Projects into Workspace (Projets existants dans l'espace de travail). C'est généralement le cas quand un EJB a été référencé depuis un projet de service. Si un des fichiers WSDL ou XSD référencés depuis le projet de service existe dans un autre type de projet, créez une nouvelle bibliothèque Business Integration sous le même nom que l'ancien projet (non service) et copiez tous les artefacts dans la bibliothèque.
Importez le projet de service à l'aide de l'Assistant de migration. Cette opération crée un module Business Integration avec les messages WSDL, les types de port, les liaisons et les services générés dans WebSphere Studio Application Developer Integration Edition.
Dans Business Integration, développez le module pour voir son contenu. Pour ouvrir Assembly Editor, cliquez deux fois sur le premier élément sous le projet de module (même nom que le projet).
Vous avez plusieurs possibilités :
Création du composant EJB personnalisé (option 1)
La technique de migration recommandée consiste à utiliser le type d'importation avec liaison de session sans état de WebSphere Integration Developer qui vous permet d'appeler un EJB de session sans état en tant que composant SCA. Pendant la migration, vous devez écrire du code Java personnalisé pour la conversion entre le style d'interface Java SCA et le style d'interface EJB existant.
Remarque : Bien que l'outil de migration traite cela automatiquement, toutes les modifications apportées après la migration aux interfaces et types de données (objets métier) impliqués dans l'interface EJB devront être mises à jour manuellement au code de conversion mentionné ici. Les erreurs peuvent être affichées dans WebSphere Integration Developer, selon le type de modification apportée.
Pour créer le composant EJB personnalisé, procédez comme suit :
- Sous le projet de module, développez Interfaces et sélectionnez l'interface WSDL générée pour cet EJB dans WebSphere Studio Application Developer Integration.
- Effectuez un glisser-déposer de cette interface vers l'éditeur d'assemblage. Une boîte de dialogue vous demande de sélectionner le type de composant à créer. Sélectionnez Composant (sans type d'implémentation) et cliquez sur OK.
- Un composant générique apparaît dans le diagramme d'assemblage. Sélectionnez-le et accédez à la vue Propriétés.
- Dans l'onglet Description, vous pouvez
remplacer le nom et le nom d'affichage du composant par un nom plus
descriptif. Attribuez-lui le nom de votre EJB et ajoutez un suffixe tel que "JavaMed", car ce composant Java servira d'intermédiaire entre l'interface WSDL générée pour l'EJB dans WebSphere Studio Application Developer Integration et l'interface Java de l'EJB.
- Dans l'onglet Détails, vous voyez que ce
composant a une interface (celle pour laquelle vous avez effectué un
glisser-déposer vers l'éditeur d'assemblage).
- Dans l'éditeur d'assemblage, cliquez avec le bouton droit de la souris sur
le composant que vous venez de créer et sélectionnez
Générer l'implémentation... -> Java Sélectionnez ensuite le package dans lequel l'implémentation Java sera générée.
Cette opération crée un service
Java
squelette conforme à l'interface WSDL selon le modèle de programmation SCA, où
les types complexes sont représentés par un objet de type
commonj.sdo.DataObject et où les types simples sont représentés par leurs
équivalents objet
Java.
Les exemples de code suivants affichent :
- des définitions appropriées provenant de l'interface WSDL 5.1 ;
- les méthodes Java de WebSphere Studio
Application Developer Integration Edition 5.1 qui correspondent à l'interface WSDL
- les méthodes Java de
WebSphere
Integration Developer 6.x pour la même interface WSDL
Le code suivant affiche les définitions appropriées provenant de l'interface WSDL 5.1 :
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://migr.practice.ibm.com/"
xmlns:xsd1="http://migr.practice.ibm.com/">
<complexType name="StockInfo">
<all>
<element name="index" type="int"/>
<element name="price" type="double"/>
<element name="symbol" nillable="true"
type="string"/>
</all>
</complexType>
</schema>
</types>
<message name="getStockInfoRequest">
<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
<part name="result" type="xsd1:StockInfo"/>
</message>
<operation name="getStockInfo" parameterOrder="symbol">
<input message="tns:getStockInfoRequest"
name="getStockInfoRequest"/>
<output message="tns:getStockInfoResponse"
name="getStockInfoResponse"/>
</operation>
Le code suivant affiche les méthodes Java de WebSphere Studio Application Developer Integration Edition 5.1 qui correspondent à l'interface WSDL :
public StockInfo getStockInfo(String symbol)
{
return new StockInfo();
}
public void setStockPrice(String symbol, float newPrice)
{
// set some things
}
Le code suivant montre les méthodes
Java de
WebSphere
Integration Developer 6.x pour la même interface WSDL :
public DataObject getStockInfo(String aString) {
//TODO Needs to be implemented.
return null;
}
public void setStockPrice(String symbol, Float newPrice) {
//TODO Needs to be implemented.
}
Pour finir, vous devez entrer du code réel aux endroits où vous voyez les balises "//TODO" dans la classe d'implémentation Java générée. Commencez par créer une référence de ce composant Java vers l'EJB réel de sorte qu'il puisse accéder à l'EJB selon le modèle de programmation SCA :
- Laissez l'éditeur d'assemblage ouvert et accédez à J2EE. Localisez le projet EJB contenant l'EJB pour lequel vous créez un service.
- Développez Descripteur de déploiement : <nom-projet> et localisez l'EJB. Effectuez un glisser-déposer vers l'éditeur d'assemblage. Si un message vous informe que les dépendances du projet doivent être mises à jour,
cochez la case Ouvrir l'éditeur de dépendances
du module... et cliquez sur OK.
- Sous la section J2EE, assurez-vous que le projet EJB est répertorié et, dans le
cas contraire, ajoutez-le en cliquant sur Ajouter....
- Sauvegardez les dépendances du module et fermez cet éditeur. Vous voyez qu'un nouvel import a été créé dans l'éditeur d'assemblage. Vous pouvez le sélectionner et accéder à la vue Propriétés de l'onglet Description afin de remplacer le nom et le nom d'affichage de cet import par un nom plus explicite. Dans l'onglet Liaison, vous remarquez que le type d'importation a automatiquement la valeur Liaison de bean session sans
état et que le nom JNDI de l'EJB est déjà défini de manière appropriée.
- Sélectionnez l'outil Connexion dans la palette de l'éditeur d'assemblage.
- Cliquez sur le composant Java et relâchez le bouton de la souris.
- Ensuite, cliquez sur l'importation EJB et relâchez le bouton de la souris.
- Vous allez voir apparaître un message Une référence
correspondante va être créée sur le noeud source. Voulez-vous
continuer ? Cliquez sur OK.
Une connexion est créée entre les deux composants.
- Sélectionnez le composant Java dans l'éditeur d'assemblage et dans la vue Propriétés de l'onglet Détails, développez Références, puis sélectionnez la référence à l'EJB que vous venez de créer. Vous pouvez mettre à jour le nom de la référence si le nom généré n'est pas assez descriptif ou pas approprié. N'oubliez pas le nom de cette référence en vue d'une utilisation future.
- Sauvegardez le diagramme d'assemblage.
Vous devez utiliser le modèle de programmation SCA pour appeler l'EJB à partir de la classe Java générée.
Ouvrez la classe Java générée et suivez ces étapes pour écrire le code qui appellera le service EJB. Pour la classe d'implémentation Java générée :
- Créez une variable privée (dont le type correspond à celui de votre interface EJB distante) :
private YourEJBInterface ejbService = null;
- Si votre interface EJB contient des types complexes, créez également une variable privée pour BOFactory :
private BOFactory boFactory = (BOFactory)
ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo
/BOFactory");
- Dans le constructeur de la classe d'implémentation Java, utilisez les API SCA pour résoudre la référence EJB (pensez à indiquer le nom de la référence EJB que vous avez écrit dans une étape précédente) et affectez à la variable privée la même valeur que cette référence :
// Locate the EJB service
this.ejbService = (YourEJBInterface)
ServiceManager.INSTANCE.locateService("name-of-your-ejb-reference");
Pour chaque balise "//TODO" dans la classe d'implémentation Java générée :
- Convertissez tous les paramètres en types de paramètre attendus par l'EJB.
- Appelez la méthode appropriée sur la référence EJB à l'aide du modèle de programmation SCA, en envoyant les paramètres convertis.
- Convertissez la valeur de retour de l'EJB en type de valeur de retour déclaré par la méthode d'implémentation Java générée.
/**
* Method generated to support the implementing WSDL port type named
* "interface.MyBean".
*/
public DataObject getStockInfo(String aString) {
DataObject boImpl = null;
try {
// invoke the EJB method
StockInfo stockInfo = this.ejbService.getStockInfo(aString);
// formulate the SCA data object to return.
boImpl = (DataObject)
this.boFactory.createByClass(StockInfo.class);
// manually convert all data from the EJB return type into the
// SCA data object to return
boImpl.setInt("index", stockInfo.getIndex());
boImpl.setString("symbol", stockInfo.getSymbol());
boImpl.setDouble("price", stockInfo.getPrice());
} catch (RemoteException e) {
e.printStackTrace();
}
return boImpl;
}
/**
* Method generated to support the implementing WSDL port type named
* "interface.MyBean".
*/
public void setStockPrice(String symbol, Float newPrice) {
try {
this.ejbService.setStockPrice(symbol, newPrice.floatValue());
} catch (RemoteException e) {
e.printStackTrace();
}
}
Création d'un service Web EJB (option 2)
L'outil des services Web Rational Application Developer est une autre option qui vous permet de créer un service Web autour d'un EJB.
Remarque : Cette option requiert qu'un runtime de service Web soit configuré via WebSphere Integration Developer avant l'appel de l'Assistant de service Web.
Pour créer un service Web autour d'un EJB, procédez comme suit :
- Cliquez avec le bouton droit de la souris sur le projet d'application d'entreprise situé dans le conteneur pour l'EJB autour duquel vous créez un service.
- Sélectionnez Propriétés, accédez aux propriétés Serveur
et vérifiez que Environnement d'exécution cible a la valeur WebSphere
Process Server v6.1 et que Default server (Serveur par défaut)
correspond au serveur WebSphere Process Server v6.1 installé.
- Démarrez le serveur de test, déployez cette application sur le serveur et vérifiez qu'elle démarre correctement.
- Dans J2EE, développez EJB project (Projet EJB) dans la vue de l'explorateur de projet. Développez Deployment Descriptor (Descripteur de déploiement), puis la catégorie Session Beans (Beans de session). Sélectionnez le bean autour duquel générer le service Web.
- Cliquez avec le bouton droit de la souris et sélectionnez
Services
Web -> Create Web service (Créer un service Web).
- Sélectionnez EJB Web Service (Service Web EJB) pour Web Service Type (Type de service Web) et désactivez l'option Start Web service in Web project (Démarrer le service Web dans le projet Web), à moins que vous ne souhaitiez déployer immédiatement le service Web. Cliquez sur Suivant.
- Vérifiez que l'EJB sur lequel vous avez cliqué avec le bouton droit de la souris est sélectionné, puis cliquez sur Suivant.
- Vous devez maintenant configurer les options de déploiement du service. Cliquez sur Editer....
Sélectionnez WPS Server v6.1 comme type de serveur et
IBM WebSphere et J2EE version 1.4
comme exécution du service Web. Si vous n'arrivez pas à sélectionner une combinaison valide, reportez-vous à la section "Préparation de la migration" pour plus d'informations sur la migration des projets J2EE vers le niveau v1.4. Cliquez sur OK.
- Pour le projet Service, entrez le nom du projet EJB contenant l'EJB. Sélectionnez également le projet EAR approprié. Cliquez sur Suivant.
Notez que cette opération peut prendre quelques minutes.
- Dans le panneau relatif à la configuration EJB du service Web, sélectionnez le projet routeur approprié à utiliser (choisissez le nom du projet Web routeur à créer pour que ce projet soit ajouté à la même application d'entreprise que l'EJB d'origine. Sélectionnez le transfert souhaité (SOAP over HTTP ou SOAP over JMS). Cliquez sur Suivant.
- Sélectionnez le fichier WSDL qui contiendra les définitions WSDL. Sélectionnez les méthodes que vous souhaitez exposer sur le service Web et choisissez le style/codage approprié (Document/Literal, RPC/Literal ou RPC/Encoded). Sélectionnez l'option Define custom mapping for package to namespace (Définir un mappage personnalisé du package à l'espace de nom), puis un espace de nom considéré unique par l'EJB en cours de migration pour tous les modules Java utilisés par cet EJB (l'espace de nom par défaut attribué au nom du package est unique, ce qui peut provoquer des conflits si vous créez un autre service Web utilisant les mêmes classes Java). Le cas échéant, renseignez les autres paramètres. Il existe des restrictions pour chaque combinaison style/codage.
Pour plus d'informations, voir les limitations : Limitations des services Web
- Cliquez sur Suivant. Dans le panneau Web Service package to namespace mapping (Package du service Web pour le mappage de l'espace de nom), cliquez sur Ajouter et,
sur la ligne créée, entrez le nom du package de votre EJB,
puis l'espace de nom personnalisé qui identifie uniquement cet EJB. Continuez à ajouter des mappages pour tous les modules Java utilisés par l'interface de l'EJB.
- Cliquez sur Suivant. Notez que cette opération peut prendre quelques minutes.
- Cliquez sur Terminer. Une fois l'Assistant terminé,
vous devez copier le fichier WSDL généré qui décrit le service EJB vers le projet du module Business Integration si le projet de service était un consommateur du service EJB. Il est situé dans le projet Web routeur généré sous le dossier WebContent/WEB-INF/wsdl. Actualisez/Concevez de nouveau le projet du module Business Integration.
- Accédez à Business Integration et développez le module migré, puis la catégorie logique Ports de service Web.
- Sélectionnez le port généré dans les étapes précédentes et faites-le glisser vers l'éditeur d'assemblage, puis créez une importation avec liaison de services Web (Import with Web Service Binding). Sélectionnez l'interface WSDL de l'EJB si vous y êtes invité.
A présent, le composant SCA qui utilisait l'EJB dans la version 5.1 peut être connecté à cet import pour exécuter les étapes de migration de nouvelle connexion manuelle.
Si vous avez utilisé une approche descendante dans WebSphere Studio Application Developer Integration Edition, en générant un squelette EJB à partir d'une définition WSDL, procédez comme suit :
- Créez un projet Web et copiez le fichier WSDL à partir duquel vous souhaitez générer le squelette EJB dans le dossier source de ce projet Web.
- Cliquez avec le bouton droit de la souris sur le fichier WSDL contenant le type de port à partir duquel vous souhaitez générer le squelette EJB et sélectionnez Services Web -> Générer un squelette de bean Java.
- Choisissez le type de service Web Service Web d'EJB squelette et finissez d'exécuter l'assistant.
Une fois l'assistant terminé, vous devez disposer d'un EJB qui implémente l'interface de service et qui ne dépend pas des API WSIF.
Notez que l'interface peut légèrement différer de l'interface 5.1, et vous devrez peut-être insérer un composant de médiation d'interface entre le consommateur 5.1 et la nouvelle importation.
Pour ce faire, cliquez sur l'outil Connexion dans l'éditeur d'assemblage et connectez le composant source SCA à la nouvelle importation avec liaison de services Web. Etant donné que les interfaces diffèrent, vous recevez le message suivant : Les noeuds source et cible n'ont pas d'interfaces correspondantes.
Choisissez de créer un mappage d'interface entre les noeuds source et cible. Cliquez deux fois sur le composant de mappage créé dans l'éditeur d'assemblage. L'éditeur de mappage s'affiche. Consultez le centre de documentation pour obtenir des instructions sur la création d'un mappage d'interface.
Ensuite, vous devez reconnecter le service EJB. Comme il ne doit exister aucune référence, il vous suffit de reconnecter l'interface du composant Java :
- Si ce service est appelé par un processus métier situé dans le même module, vous devez créer une connexion entre la référence de processus métier appropriée et l'interface de ce composant.
- Si ce service est appelé par un processus métier situé dans un autre module, créez une exportation avec liaison SCA et à partir de l'autre module, effectuez un glisser-déposer de cette exportation vers l'éditeur d'assemblage de ce module pour créer l'importation avec liaison SCA correspondante. Connectez la référence de processus métier appropriée à cette importation.
- Si ce service a été publié dans WebSphere Studio Application Developer Integration Edition pour faire l'objet d'une
exposition externe, voir la section "Création d'exportations SCA afin
d'accéder au service migré" pour savoir comment le publier de nouveau.
Avantages et inconvénients de chacune des options de nouvelles connexions de service EJB
Il existe des avantages et des inconvénients pour chaque option de nouvelle connexion
d'un service EJB.
La liste suivante décrit les options ainsi que ses avantages et ses inconvénients :
- La première option est censée donner de meilleures performances pendant l'exécution car l'appel d'un service Web est plus lent que l'appel d'un EJB.
- La première option peut propager le contexte alors que l'appel d'un service Web ne propage pas le contexte de la même manière.
- La deuxième option n'implique pas la création d'un code personnalisé.
- Il est possible que la deuxième option ne soit pas disponible pour certaines définitions d'interface EJB dans la mesure où la génération d'un service EJB est soumise à des restrictions. Voir la documentation de Rational Application Developer à l'adresse suivante : Limitations of Web services
- La deuxième option peut entraîner la modification de l'interface, et par conséquent, la modification du client SCA.
- La deuxième option nécessite qu'un serveur
WebSphere
Process Server 6.x soit installé et configuré de manière à fonctionner avec
WebSphere
Integration Developer.
Pour connaître les environnements d'exécution installés qui sont configurés pour fonctionner avec WebSphere Integration
Developer, accédez à Fenêtre -> Préférences -> Serveur -> Installed Runtimes (Environnements d'exécution installés) et
sélectionnez l'entrée WebSphere Process Server v6.1 le cas
échéant ; assurez-vous qu'elle pointe vers l'emplacement d'installation du produit.
Vérifiez que cette entrée est activée si le serveur est présent et désactivée si le serveur n'est pas installé. Vous pouvez également cliquer sur Ajouter... pour
ajouter un autre serveur.
- Si le composant Java a été généré dans WebSphere Studio Application Developer Integration Edition à l'aide de l'approche descendante dans laquelle le squelette EJB a été généré à partir d'un WSDL, les paramètres à l'intérieur et à l'extérieur de cette classe Java mettront probablement WSIFFormatPartImpl sous forme de sous-classe. Dans ce cas, choisissez la deuxième option pour générer un nouveau squelette Generic EJB (indépendant des API DataObject ou WSIF) à partir de l'interface WSDL d'origine.
Migration d'un processus métier vers un appel de service de processus métier
Ce scénario s'applique à un processus métier qui appelle un autre processus métier à l'aide d'une liaison de processus WSIF. Cette section décrit comment migrer un processus BPEL vers un appel de service BPEL à l'aide d'une liaison ou d'un import/export avec liaison SCA.
Pour migrer un projet de service de connexion (BPEL) pour un service en sortie, procédez comme suit :
- Dans Business Integration, développez le module pour voir son contenu. Pour ouvrir l'éditeur d'assemblage, double-cliquez sur le premier élément sous le projet de module (même nom que le projet).
- Ils existent plusieurs scénarios dans lesquels un processus BPEL peut appeler un autre processus BPEL. Recherchez le scénario adapté à votre application parmi les scénarios suivants :
- Si le BPEL appelé se trouve dans le même module, créez une connexion à partir de la référence appropriée sur le premier composant BPEL vers l'interface appropriée sur le composant BPEL cible.
- Si le processus BPEL appelé est situé dans un autre module (l'autre module étant un projet de service migré) :
- Créez un export avec liaison SCA pour le deuxième processus métier dans son diagramme de module.
- Dans la vue Intégration métier, développez l'icône de l'assemblage du deuxième module dans le navigateur. Vous devez voir l'export que vous venez de créer.
- Effectuez un glisser-déposer de l'export de la vue Intégration métier sous le deuxième module vers l'éditeur d'assemblage ouvert du premier module. Un import avec liaison SCA est créé dans le premier module. Si ce service a été publié dans WebSphere Studio Application Developer Integration Edition afin de l'exposer de manière externe, voir la section "Création d'exports SCA afin d'accéder au service migré".
- Connectez la référence appropriée sur le premier processus métier à l'import que vous venez de créer dans ce module.
- Sauvegardez le diagramme d'assemblage.
- Pour effectuer une liaison tardive lors de l'appel du second processus métier, procédez comme suit :
- Ne connectez pas la référence de composant du premier processus métier. Ouvrez ce dernier dans l'éditeur BPEL puis, dans la section Partenaires de référence, sélectionnez le partenaire qui correspond au second processus BPEL pour effectuer l'appel à l'aide de la liaison tardive.
- Dans la vue Propriétés de l'onglet Description, entrez le nom du second processus métier dans la zone Modèle de processus.
- Sauvegardez le processus métier. La configuration de l'appel par
liaison tardive est maintenant terminée.
Migration d'un service Web (SOAP/JMS)
Vous pouvez migrer un service Web (SOAP/JMS) dans une importation SCA avec liaison de service Web.
Pour migrer un projet de service SOAP/JMS sortant, procédez comme suit :
- Vous devrez d'abord importer le projet de service à l'aide de l'Assistant de migration. Cette opération crée un module Business Integration avec les messages WSDL, les
types de port, les liaisons et les services générés dans
WebSphere
Studio Application Developer Integration Edition. Notez que si le service Web IBM (SOAP/JMS) que cette application va appeler est aussi un service Web WebSphere Studio Application Developer Integration Edition qui sera migré, des mises à jour de ce service Web peuvent avoir lieu lors de la migration. Dans ce cas, vous devez utiliser ici les fichiers WSDL migrés de ce service Web.
- Dans Business Integration, développez le module pour voir son contenu. Pour ouvrir l'éditeur d'assemblage, double-cliquez sur le premier élément sous le projet de module (même nom que le projet).
- Ensuite, ajoutez une importation qui permettra à l'application d'interagir avec le service Web IBM (via SOAP/JMS) en fonction du modèle de programmation SCA. Vérifiez que l'interface WSDL, la liaison et les définitions de service sont présents dans le module migré ou dans une bibliothèque dont dépend le module migré.
- Dans Business Integration, développez le module migré et ouvrez son diagramme d'assemblage dans l'éditeur d'assemblage.
- Développez la catégorie logique Ports de service Web et faites glisser le port qui correspond au service que vous voulez appeler dans l'éditeur d'assemblage.
- Sélectionnez Import with Web Service Binding (Importer avec liaison de service Web).
- Une fois l'importation créée, sélectionnez-la dans l'éditeur d'assemblage et ouvrez la vue Propriétés. Dans l'onglet Liaison, vous verrez le port et le service auxquels l'importation est connectée.
- Sauvegardez le diagramme d'assemblage.
Quand vous avez terminé, vous devez reconnecter le service :
- Si ce service est appelé par un processus métier dans le même module, créez une connexion entre la référence de processus métier appropriée et cette importation.
- Si ce service est appelé par un processus métier situé dans un autre module, créez une exportation avec liaison SCA et à partir de l'autre module, effectuez un glisser-déposer de cette exportation vers l'éditeur d'assemblage de ce module pour créer l'importation avec liaison SCA correspondante. Connectez la référence de processus métier appropriée à cette importation.
- Sauvegardez le diagramme d'assemblage.
Migration d'un service Web (SOAP/HTTP)
Vous pouvez migrer un service Web (SOAP.HTTP) dans une importation SCA avec liaison de service Web.
Pour migrer un projet de service SOAP/HTTP sortant, procédez comme suit :
- Vous devrez d'abord importer le projet de service à l'aide de l'Assistant de migration. Cela va créer un module Business Integration contenant les messages WSDL, les types de port, les liaisons et les services créés dans WebSphere Studio Application Developer Integration Edition. Notez que si le service Web IBM (SOAP/HTTP) que cette application va appeler est aussi un service Web WebSphere Studio Application Developer Integration Edition qui sera migré, des mises à jour de ce service Web peuvent avoir lieu lors de la migration. Dans ce cas, vous devez utiliser ici les fichiers WSDL migrés de ce service Web.
- Dans Business Integration, développez le module pour voir son contenu. Pour ouvrir l'éditeur d'assemblage, double-cliquez sur le premier élément sous le projet de module (même nom que le projet).
- Ensuite, ajoutez une importation qui permettra à l'application d'interagir avec le service Web IBM (via SOAP/HTTP) en fonction du modèle de programmation SCA. Vérifiez que l'interface WSDL, la connexion et les définitions de service sont présents dans le module migré ou dans une bibliothèque dont dépend le module migré.
- Dans Business Integration, développez le module migré et ouvrez son diagramme d'assemblage dans l'éditeur d'assemblage.
- Développez la catégorie logique Ports de service Web et faites glisser le port qui correspond au service que vous voulez appeler dans l'éditeur d'assemblage.
- Sélectionnez Import with Web Service Binding (Importer avec liaison de service Web).
- Une fois l'importation créée, sélectionnez-la dans l'éditeur d'assemblage et ouvrez la vue Propriétés. Dans l'onglet Liaison, vous verrez le port et le service auxquels l'importation est connectée.
- Sauvegardez le diagramme d'assemblage.
Quand vous avez terminé, vous devez reconnecter le service :
- Si ce service est appelé par un processus métier dans le même module, créez une connexion entre la référence de processus métier appropriée et cette importation.
- Si ce service est appelé par un processus métier situé dans un autre module, créez une exportation avec liaison SCA et à partir de l'autre module, effectuez un glisser-déposer de cette exportation vers l'éditeur d'assemblage de ce module pour créer l'importation avec liaison SCA correspondante. Connectez la référence de processus métier appropriée à cette importation.
- Sauvegardez le diagramme d'assemblage.
Migration d'un service JMS
Vous pouvez migrer un service JMS dans une importation SCA avec liaison JMS.
Remarque : Si le message JMS est envoyé à un adaptateur
WebSphere
Business Integration, reportez-vous à la section "Migration des interactions avec l'adaptateur
WebSphere
Business Integration" au moyen du lien au-dessous.
Pour migrer un projet de service JMS sortant, procédez comme suit :
- Vous devrez d'abord importer le projet de service à l'aide de l'Assistant de migration. Cela va créer un module Business Integration contenant les messages WSDL, les types de port, les liaisons et les services créés dans WebSphere Studio Application Developer Integration Edition.
- Dans Business Integration, développez le module pour voir son contenu. Pour ouvrir l'éditeur d'assemblage, double-cliquez sur le premier élément sous le projet de module (même nom que le projet).
- Ensuite, ajoutez une importation qui permettra à l'application d'interagir avec une file d'attente JMS en fonction du modèle de programmation SCA.
- Dans l'éditeur d'assemblage, développez le projet de module migré et développez la catégorie Interfaces puis recherchez le type de port WSDL qui décrit le service Web que l'application doit appeler. Effectuez un glisser-déposer vers l'éditeur d'assemblage.
- Une boîte de dialogue Création de composants vous invite à sélectionner le type de composant à créer. Choisissez Importation sans liaison.
- Une nouvelle importation est créée dans l'éditeur d'assemblage. Sélectionnez-la puis ouvrez la vue Propriétés. Dans l'onglet Description, vous pouvez remplacer le nom et le nom d'affichage de l'importation par un nom plus descriptif.
- Vous pouvez vous reporter aux fichiers de service et de liaison WSDL 5.1 pour plus de détails
sur le service JMS en cours de migration. Ces fichiers peuvent être utilisés pour remplir les détails
de l'"importation avec liaison JMS" de la version 6.x. Recherchez-les dans le projet de service 5.1 (ils sont habituellement appelés *JMSBinding.wsdl et *JMSService.wsdl). Prenez connaissance des informations de liaison et de service qui s'y trouvent. La partie liaison permet de déterminer si les messages de texte ou d'objet ont été utilisés. Elle permet également de déterminer si des liaisons de format de données personnalisées ont été utilisées.
Si tel est le cas, pensez également à créer une liaison personnalisée de données pour la fonction
"Importer avec liaison JMS" de la version 6.x. La partie service contient la fabrique de contexte initiale, le nom de la fabrique de connexions JNDI, le nom de destination JNDI et le style de destination (file d'attente).
- Avec le bouton droit, cliquez sur l'importation et sélectionnez Générer la liaison puis Liaison JMS. Vous serez invité à entrer les paramètres suivants :
- Sélectionnez le domaine de messagerie JMS :
-
- Point à point
- Publier/Abonner
- Indépendant du domaine
- Sélectionnez la façon dont les données sont sérialisées entre l'objet métier et le message JMS :
-
- Texte
- Objet
- Fourni par l'utilisateur
- Si vous sélectionnez Fourni par l'utilisateur :
- Indiquez le nom qualifié complet de la classe d'implémentation com.ibm.websphere.sca.jms.data.JMSDataBinding. Vous devez indiquer une liaison de données définie par l'utilisateur si l'application doit utiliser des propriétés d'en-tête JMS habituellement non définies dans la liaison d'importation JMS. Dans ce cas, vous pouvez créer une classe de liaison de données personnalisée qui prolonge la liaison de données JMS standard "com.ibm.websphere.sca.jms.data.JMSDataBinding", et ajouter un code personnalisé permettant d'accéder directement à JMSMessage. Pour consulter les exemples JMS se trouvant dans "Création et modifications des liaisons des composants d'importation et d'exportation",
cliquez sur le lien ci-dessous.
- La connectivité en entrée utilise la classe de sélecteur de fonction JMS par défaut :
- <sélectionné> ou <désélectionné>
- Sélectionnez l'import que vous venez de créer. Dans la vue Propriétés, sélectionnez l'onglet Liaison. Vous pouvez indiquer manuellement toutes les données de liaison en utilisant les valeurs que vous avez déjà indiquées dans WebSphere Studio Application Developer Integration Edition. Les données de liaison que vous pouvez indiquer sont les suivantes :
- Liaison d'importation JMS (le plus important)
- Connexion
- Adaptateur de ressource
- Destinations JMS
- Liaisons de méthode
Quand vous avez terminé, vous devez reconnecter le service :
- Si ce service est appelé par un processus métier dans le même module, créez une connexion entre la référence de processus métier appropriée et cette importation.
- Si ce service est appelé par un processus métier situé dans un autre module, créez une exportation avec liaison SCA et à partir de l'autre module, effectuez un glisser-déposer de cette exportation vers l'éditeur d'assemblage de ce module pour créer l'importation avec liaison SCA correspondante. Connectez la référence de processus métier appropriée à cette importation.
- Sauvegardez le diagramme d'assemblage.
Migration d'un service J2C-IMS
Vous pouvez migrer un service J2C-IMS dans une importation SCA avec liaison EIS ou une importation SCA avec liaison de service Web.
N'utilisez aucun des artefacts de
WebSphere Studio
Application Developer Integration Edition qui ont été générés pour ce service
IMS. Vous devrez recréer le service à l'aide des assistants disponibles dans WebSphere Integration Developer et reconnecter l'application manuellement.
Remarque : Activez la fonction de compilation automatique ou compilez le module manuellement.
Vous disposez des options suivantes :
Remarque : Pour les deux options, notez que si un service BPEL appelle ce service IMS, le BPEL devra changer légèrement car l'interface du service EIS sera sensiblement différente de l'ancienne interface 5.1. Pour cela, ouvrez l'éditeur de BPEL et modifiez le lien partenaire qui correspond au service EIS puis utilisez la nouvelle interface (fichier WSDL ) quand vous exécuterez les étapes ci-après. Apportez les modifications nécessaires aux activités BPEL pour la nouvelle interface WSDL du service EIS.
Création d'un import SCA pour appeler le service
IMS (option 1)
Vous pouvez créer une importation SCA avec liaison EIS qui utilisera les objets DataObjects pour stocker le message ou les données afin de communiquer avec le système IMS.
Pour créer une importation SCA afin d'appeler le service IMS, procédez comme suit :
- Créez un nouveau projet de module Business Integration pour contenir ce nouveau service IMS.
- Pour recréer le service EIS, sélectionnez
Fichier -> Nouveau -> Autre -> Intégration
métier -> Service externe.
- Cet assistant vous permet d'importer un service depuis un système EIS. Il est très proche de l'assistant de WebSphere Studio Application Developer Integration Edition qui créait le service EIS basé sur WSIF dans la version 5.1. Vous pouvez importer le nouvel adaptateur de ressource IMS J2C dans cet assistant. Naviguez jusqu'au répertoire d'installation de WebSphere Integration Developer et recherchez Adaptateurs de ressource -> ims15 -> imsico9102.rar.
Remarque : Voir le Centre de documentation pour plus d'informations sur les volets des propriétés et des opérations. Dans l'assistant Service externe, quand vous ajoutez une opération, vous pouvez également
créer des objets métier pour le type de données d'entrée ou de sortie de l'opération. Ceci requiert le fichier source C ou COBOL que vous avez utilisé dans l'assistant de WebSphere Studio Application Developer Integration Edition. Ces fichiers doivent avoir été copiés dans l'ancien projet de service pour que puissiez retrouver les fichiers source. Vous pouvez également importer les objets
métier avec l'autre assistant. Pour cela, sélectionnez
Fichier -> Nouveau -> Autre -> Intégration
métier -> Données externes.
- Une fois l'assistant terminé, ouvrez la perspective Intégration métier et
développez le module pour voir son contenu. Vous devez voir les nouveaux objets métier du module listés sous Types de données et les nouvelles interfaces listées sous Interfaces.
- Pour ouvrir l'éditeur d'assemblage, cliquez deux fois sur le premier élément sous le projet de module (même nom que le projet). Vous devez voir une importation sur la trame. Cette importation possède une liaison EIS et représente le service que vous venez de créer.
Voir la section "Création d'exportations SCA afin d'accéder au service migré" pour savoir comment publier ce service.
Création d'un service Web autour du service J2C (option 2)
Vous pouvez créer un service Web J2C et, si l'utilisateur de ce service est un composant SCA, consommer le service en tant que service Web IBM (SOAP/HTTP ou SOAP/JMS).
Pour créer un service Web avec le service J2C, procédez comme suit :
- Pour créer le bean Java J2C, cliquez sur Fichier -> Nouveau -> J2C -> Bean Java J2C
- Choisissez la version 1.5 du Connecteur IMS pour Java et cliquez sur Suivant.
- Cochez l'option Connexion gérée et entrez le nom de recherche JNDI. Cliquez sur Suivant.
- Indiquez le projet, le module et le nom du nouveau bean Java.
Le bean comprend une interface et une classe d'implémentation. Cliquez sur Suivant.
- Ajoutez une méthode Java pour chaque fonction ou service auxquels vous voulez accéder depuis EIS. Vous pourrez ajouter d'autres méthodes ensuite dans l'éditeur source Java via la vue des fragments. Quand vous cliquez sur le bouton Ajouter, choisissez le nom puis la méthode et cliquez sur Suivant.
- Vous pouvez maintenant cliquer sur Parcourir, pour réutiliser des types existants, ou sur Nouveau, pour lancer l'assistant de connexion de données Java de CICS/IMS (où vous pourrez référencer un fichier source COBOL ou C) et spécifier les types de données d'entrée ou de sortie.
- Une fois créées les méthodes Java, cliquez sur Suivant.
- Finissez les autres étapes de l'assistant pour créer votre bean Java J2C.
- Cliquez sur Fichier -> Nouveau -> J2C -> Page Web, Service Web, ou EJB depuis Bean Java J2C pour créer le service Web avec le bean Java J2C.
- Terminez l'assistant.
Les consommateurs peuvent maintenant utiliser le service WSDL créé avec cet assistant pour appeler le service IMS.
Avantages et inconvénients pour chacune des options de nouvelle connexion d'un service J2C-IMS
Il existe des avantages et des inconvénients pour chaque option de nouvelle connexion
d'un service J2C-IMS.
La liste suivante décrit les options ainsi que ses avantages et ses inconvénients :
- La première option utilise le composant SCA standard pour appeler le service HOD.
- La première option est soumise à certaines restrictions :
- L'API de spécification SDO version 1 ne fournit pas l'accès au tableau d'octets C ou COBOL. Cela affectera les clients qui utilisent les multi-segments HOD.
- La spécification SDO version 1 pour la sérialisation ne prend pas en charge la construction REDEFINE de langage COBOL ou la construction d'union de langage C.
- La deuxième option utilise l'approche JSR 109 standard pour la connexion au service HOD.
Cette fonctionnalité est disponible avec Rational Application Developer.
Migration d'un service J2C-CICS ECI
Vous pouvez migrer un service J2C-CICS ECI vers une importation SCA avec liaison EIS ou une importation SCA avec liaison de services Web.
Suivez les instructions contenues dans la section "Migration
d'un projet de service J2C-IMS" ; vous devez importer le fichier RAR
suivant au lieu du fichier RAR IMS :
- Accédez au répertoire d'installation de WebSphere Integration Developer et faites défiler la liste jusqu'à Adaptateur de ressources -> cics15 -> cicseci.rar.
Si vous suivez la deuxième option pour créer un service Web J2C, sélectionnez l'adaptateur ECIResourceAdapter V1.5 dans le deuxième panneau de l'Assistant de création de bean Java J2C.
Voir aussi la rubrique concernant la migration d'un service J2C-IMS.
Migration d'un service J2C-CICS EPI
Il n'existe pas de support direct pour le service J2C-CICS EPI dans WebSphere Integration Developer. Pour accéder à ce service depuis un module SCA, vous devrez migrer à l'aide du scénario de consommation.
Voir la rubrique "Scénario de consommation pour la migration de service" pour savoir comment migrer ce type de service dans WebSphere Integration Developer.
Migration d'un service J2C-HOD
Il n'existe pas de support direct pour le service J2C-HOD dans WebSphere Integration Developer. Pour accéder à ce service depuis un module SCA, vous devrez effectuer une migration à l'aide du scénario de consommation.
Voir la rubrique "Scénario de consommation pour la migration de service" pour savoir comment migrer ce type de service dans WebSphere Integration Developer.
Vous pouvez parfois migrer un service de transformateur dans une mappe de données SCA et une mappe d'interfaces. Vous pouvez également utiliser le scénario de consommation pour accéder à ce service depuis un module SCA.
Les composants mappe de données et mappe d'interfaces sont des nouveautés de la version 6.0.
Ils offrent des fonctions identiques au service de transformateur de la version 5.1 mais n'ont pas les mêmes capacité de transformation XSL. Si vous ne pouvez pas remplacer votre service de transformateur par l'un de ces composants, vous devez faire la migration avec le scénario de consommation car il n'existe pas de support direct pour le service de transformateur dans WebSphere Integration Developer. Suivez les étapes décrites dans la section "Scénario de consommation pour la migration de service" pour accéder à ce service depuis un module SCA.
Scénario de consommation pour la migration de service
Lorsqu'il n'existe pas d'équivalent direct pour un type de service WebSphere Studio Application Developer Integration Edition, un scénario de consommation est nécessaire pour utiliser l'ancien service WebSphere Studio Application Developer Integration Edition tel quel lors de la nouvelle conception de l'application dans WebSphere Integration Developer.
Voici les étapes que vous devez suivre dans WebSphere Studio Application Developer Integration Edition avant d'appeler l'Assistant de migration :
- Créez un projet Java pour conserver ce code de proxy client. Ne placez pas ce code de proxy client dans le projet de service car les classes de bean Java et les messages générés de type 5.1 seront ignorés par l'Assistant de migration automatique qui migre les projets de service.
- Ouvrez WebSphere Studio Application Developer Integration Edition et cliquez avec le bouton droit de la souris sur le fichier WSDL contenant la liaison de transformateur ainsi que le service, puis sélectionnez Services entreprise -> Générer le proxy de service.
Vous devez indiquer le type de proxy à créer, mais seul le type Web Services Invocation Framework (WSIF) est disponible. Cliquez sur Suivant.
- Vous pouvez maintenant indiquer le module et le nom de la classe Java de proxy de service à créer (vous créerez le proxy dans le projet de service en cours). Cliquez sur Suivant.
- Vous pouvez maintenant indiquer le style du proxy ; cliquez sur Module de remplacement client, sélectionnez les opérations que vous souhaitez inclure dans le proxy, puis cliquez sur Terminer.
Cette opération crée une classe Java qui expose les mêmes méthodes que le service WebSphere Studio Application Developer Integration Edition, où les arguments pour les méthodes Java correspondent aux parties du message WSDL source.
Vous pouvez maintenant effectuer la migration vers WebSphere Integration Developer :
- Copiez le projet Java du proxy client vers le nouvel espace de travail et importez-le à l'aide de l'option Fichier -> Importer -> Projet existant dans l'espace de travail.
- Importez le projet de service à l'aide de l'Assistant de migration. Cela va créer un module Business Integration contenant les messages WSDL, les types de port, les connexions et les services créés dans WebSphere Studio Application Developer Integration Edition.
- Dans Business Integration, développez le module pour voir son contenu. Pour ouvrir l'éditeur d'assemblage, double-cliquez sur le premier élément sous le projet de module (même nom que le projet).
- Pour créer le composant Java personnalisé, sous le projet de module, développez Interfaces et sélectionnez l'interface WSDL générée pour ce service de transformateur dans WebSphere Studio Application Developer Integration Edition.
- Glissez-déplacez cette interface vers l'éditeur d'assemblage. Une boîte de dialogue vous demande de sélectionner le type de composant à créer. Sélectionnez Composant (sans type d'implémentation) et cliquez sur OK.
- Un composant générique apparaît dans le diagramme d'assemblage. Sélectionnez-le et accédez à la vue Propriétés.
- Dans l'onglet Description, vous pouvez remplacer le nom et le nom d'affichage du composant par un nom plus descriptif (dans le cas présent, attribuez-lui le nom de votre EJB et ajoutez un suffixe tel que "JavaMed", car ce composant Java servira d'intermédiaire entre l'interface WSDL générée pour le service de transformateur dans WebSphere Studio Application Developer Integration Edition et l'interface Java du proxy client du transformateur).
- Dans l'onglet Détails, vous verrez que ce composant a une interface, celle que vous avez fait glisser dans l'éditeur d'assemblage.
- Dans l'éditeur d'assemblage, cliquez avec le bouton droit de la souris sur le composant que vous venez de créer et sélectionnez Générer l'implémentation... -> Java Sélectionnez ensuite le package dans lequel l'implémentation Java sera générée.
Cette opération crée un service
Java
squelette conforme à l'interface WSDL selon le modèle de programmation SCA, où
les types complexes sont représentés par un objet de type
commonj.sdo.DataObject et où les types simples sont représentés par leurs
équivalents objet
Java.
Maintenant, vous devez entrer du code aux endroits où vous voyez les balises "//TODO" dans la classe d'implémentation Java générée. Il existe deux options :
- Déplacez la logique de la classe Java d'origine vers cette classe, en l'adaptant à la nouvelle structure de données.
- Créez une instance privée de l'ancienne classe Java à l'intérieur de cette classe Java générée et écrivez du code dans :
- Convertissez tous les paramètres de la classe d'implémentation Java générée en paramètres attendus par l'ancienne classe Java.
- Appelez l'instance privée de l'ancienne classe Java avec les paramètres convertis.
- Convertissez la valeur de retour de l'ancienne classe Java en type de valeur de retour déclaré par la méthode d'implémentation Java générée.
Une fois que vous avez exécuté les opérations ci-dessus, vous devez reconnecter le proxy client. Comme il ne doit exister aucune "référence", il vous suffit de reconnecter l'interface du composant
Java :
- Si ce service est appelé par un processus métier situé dans le même module,
vous devez créer une connexion entre la référence de processus métier
appropriée et l'interface de ce composant
Java.
- Si ce service est appelé par un processus métier situé dans un autre module, créez une exportation avec liaison SCA et à partir de l'autre module, effectuez un glisser-déposer de cet exportation vers l'éditeur d'assemblage de ce module pour créer l'importation avec liaison SCA correspondante. Connectez la référence de processus métier appropriée à cet importation.
- Si ce service a été publié dans WebSphere Studio Application Developer Integration Edition pour faire l'objet d'une
exposition externe, voir la section "Création d'exportations SCA afin
d'accéder au service migré" pour savoir comment le publier de nouveau.
Création d'exportations SCA afin d'accéder au service migré
Une exportation SCA doit être créée pour mettre le service migré à la disposition des clients externes selon le modèle SCA pour tous les services ayant généré du code de déploiement dans le projet de service WebSphere Studio Application Developer Integration Edition. Cela inclut tous les services pouvant être appelés par les clients externes à l'application. Remarque : l'utilitaire de migration tente d'effectuer cette tâche automatiquement mais vous pouvez vous reporter aux informations suivantes pour vérifier les tâches réellement exécutées par l'outil.
Si dans WebSphere Studio Application Developer Integration Edition, vous avez cliqué avec le bouton droit de la souris sur le processus BPEL ou un autre service WSDL et sélectionné Services entreprise -> Générer le code de déploiement, vous devez suivre les étapes de migration manuelle ci-dessous. Notez que WebSphere Integration Developer est différent de WebSphere Studio Application Developer Integration Edition dans la mesure où il stocke toutes les options de déploiement. Lorsque le projet est créé, le code de déploiement est automatiquement mis à jour dans l'EJB et les projets Web générés. Il n'existe donc plus aucun moyen de générer du code de déploiement manuellement.
Cinq options de liaison ont été fournies dans la section Interfaces pour partenaires de l'assistant Générer un code de déploiement BPEL.
Les informations de migration de service BPEL entrant suivantes fournissent des informations supplémentaires sur les propriétés et le type d'exportation à créer selon le ou les types de liaison de déploiement sélectionnés dans WebSphere Studio Application Developer Integration Edition :
- EJB
- Services Web IBM (SOAP/JMS)
- Services Web IBM (SOAP/HTTP)
- Services Web Apache (SOAP/HTTP)
- JMS
Migration de la liaison EJB et de la liaison de processus EJB
La liaison EJB et la liaison de processus EJB peuvent être migrées vers la construction SCA recommandée.
Dans WebSphere Studio Application Developer Integration Edition, ce type de liaison permettait aux clients de communiquer avec un processus BPEL ou un autre type de service en appelant un EJB.
Notez que ce type de liaison n'est pas facultatif pour les microprocessus : elle est toujours sélectionnée dans la mesure où le EJB généré était utilisé en interne par les autres types de liaison.
Le nom JNDI de l'EJB généré est automatiquement généré comme une combinaison du nom de langage BPEL, de l'espace de nom cible et d'un horodatage de début de validité.
Par exemple, ces attributs peuvent être trouvés en examinant les propriétés du processus de langage BPEL dans les onglets Description et Contenu du serveur de l'éditeur BPEL :
Tableau 3. Espace de nom généré
Nom de processus |
MyService |
Espace de nom cible |
http://www.example.com/process87787141/ |
Valide à partir de |
01 jan 2003 02:03:04 |
L'espace
de nom généré pour cet exemple est alors
com/example/www/process87787141/MyService20030101T020304.
Dans WebSphere Studio Application Developer Integration Edition, lorsque la connexion EJB était sélectionnée en tant que type de déploiement, aucune option n'était fournie.
Il existe quatre options pour la migration de la liaison de processus de WebSphere Studio Application Developer Integration Edition. Le type de client qui accède au service détermine les options ci-dessous à exécuter :
Remarque : Une fois les étapes de migration manuelle terminées, le client doit également être migré vers le nouveau modèle de programmation. Voir la rubrique appropriée pour les types suivants de clients :
Tableau 4. Plus d'informations sur la migration des clients
Type de client |
Pour plus d'informations, voir |
Clients EJB qui appellent le bean de session généré.
Ce type de client appelle une méthode EJB correspondant à l'opération BPEL à appeler. |
"Migration du client EJB" |
Client WSIF qui utilise la liaison de processus EJB. |
"Migration du client de liaison de processus EJB" |
API EJB de Generic Business Process Choreographer |
"Migration d'un client utilisant l'API EJB générique de Business Process
Choreographer" |
API de messagerie de Generic Business Process Choreographer |
"Migration d'un client utilisant l'API de messagerie générique de Business Process Choreographer" |
Autre processus BPEL dans le même module |
Non applicable : connecter ensemble des composants de langage BPEL à l'aide de l'éditeur d'assemblage. |
Autre processus de langage BPEL dans un module différent |
Non applicable : créer une Importation avec liaison SCA dans le module de référence et configurer ses liaisons pour pointer vers l'Exportation avec liaison SCA que vous avez créée plus haut dans la première option. |
Option de migration 1 pour la connexion de processus EJB et EJB
La première option de migration pour la connexion du processus EJB WebSphere Studio Application Developer Integration Edition consiste à rendre les processus métier accessibles à un autre composant dans le même module.
Dans l'éditeur d'assemblage, connectez cet autre composant au composant BPEL :
- Sélectionnez l'élément Connexion dans la barre d'outils.
- Cliquez sur l'autre composant pour le sélectionner en tant que source de la connexion.
- Cliquez sur le composant BPEL SCA pour le
sélectionner en tant que cible de la connexion.
- Sauvegardez le diagramme d'assemblage.
Option de migration 2 pour la connexion de processus EJB et EJB
La deuxième option de migration pour la connexion du processus EJB WebSphere Studio Application Developer Integration Edition consiste à rendre les processus métier accessibles à d'autres clients et modules SCA.
Remarque : Ces étapes sont obligatoires si les API de Generic Business Process Choreographer sont utilisées pour appeler le processus métier.
L'exportation avec liaison SCA permet à d'autres modules SCA d'accéder à un composant SCA. Pour créer une exportation avec liaison SCA, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une exportation avec liaison SCA pour chaque interface du processus BPEL pour laquelle une liaison a été générée dans WebSphere Studio Application Developer Integration Edition :
- Cliquez avec le bouton droit de la souris sur le composant BPEL dans
l'éditeur d'assemblage.
- Sélectionnez Exporter....
- Sélectionnez Liaison SCA.
- S'il existe plusieurs interfaces pour le processus, sélectionnez la
ou les interfaces à exporter avec ce type de liaison.
- Une fois l'exportation SCA créée, sélectionnez-la dans l'éditeur d'assemblage et dans la vue Propriétés, sélectionnez le volet Description. Le nom de l'exportation et sa description sont répertoriés et peuvent être modifiés si nécessaire.
- Sauvegardez le diagramme d'assemblage.
Option de migration 3 pour les liaisons EJB et les liaisons de processus EJB
La troisième option de migration option pour la connexion du processus EJB WebSphere Studio Application Developer Integration Edition consiste à rendre les modules accessibles à une entité non-SCA (par exemple, un JSP ou un client Java).
La référence autonome permet à tout client externe d'accéder à un composant SCA. Pour créer une référence autonome, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par
l'Assistant de migration.
- Créez une référence autonome pour chaque interface de processus BPEL pour laquelle une liaison EJB a été générée dans WebSphere Studio Application Developer Integration Edition :
- Sélectionnez l'élément Référence autonome dans
la barre d'outils.
- Cliquez sur le canevas de l'éditeur d'assemblage pour créer une
entité SCA références autonomes.
- Sélectionnez l'élément Connexion dans la barre d'outils.
- Cliquez sur l'entité Références autonomes pour
la sélectionner en tant que source de la connexion.
- Cliquez sur le composant BPEL SCA pour le
sélectionner en tant que cible de la connexion.
- Un message d'alerte s'affiche : Une référence correspondante va être créée sur le noeud source. Voulez-vous continuer ?.
Cliquez sur OK.
- Sélectionnez l'entité Références autonomes qui
vient d'être créée et, dans la vue Propriétés, sélectionnez le volet
Description.
- Développez le lien Références et sélectionnez
la référence qui vient d'être créée. Le nom et la description de la
référence sont répertoriés et peuvent être modifiés si nécessaire.
- S'il existe plusieurs interfaces pour le processus, sélectionnez la
ou les interfaces à exporter avec ce type de connexion.
- Sauvegardez le diagramme d'assemblage.
Option 4 de la migration pour EJB et connexion de processus EJB
La quatrième option de migration option pour la connexion du processus EJB WebSphere Studio Application Developer Integration Edition consiste à rendre les processus métier accessibles à un client de services Web.
L'exportation avec liaison de services Web permet à un client de services Web externe d'accéder à un composant SCA. Pour créer une exportation avec liaison de service Web, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une exportation avec liaison SCA pour chaque interface du processus BPEL pour laquelle une liaison a été générée dans WebSphere Studio Application Developer Integration Edition :
- Cliquez avec le bouton droit de la souris sur le composant BPEL dans
l'éditeur d'assemblage.
- Sélectionnez Exporter....
- Sélectionnez Liaison de services Web.
- S'il existe plusieurs interfaces pour le processus, sélectionnez la
ou les interfaces à exporter avec ce type de liaison.
- Sélectionnez le transport : soap/http ou soap/jms.
- Une fois l'exportation de services Web créée, sélectionnez-la dans
l'éditeur d'assemblage et dans la vue Propriétés, sélectionnez le
volet Description. Le nom de l'exportation et sa
description sont répertoriés et peuvent être modifiés si nécessaire.
- Sauvegardez le diagramme d'assemblage.
Migration de la liaison JMS et de la liaison de processus JMS
La liaison JMS et la liaison de processus JMS peuvent être migrées vers la construction SCA recommandée.
Dans WebSphere Studio Application Developer Integration Edition, ce type de liaison permettait aux clients de communiquer avec un processus BPEL ou un autre type de service en envoyant un message à un MDB. Notez que ce type de liaison n'était pas facultatif pour les processus longs car il était toujours sélectionné. En effet, ce type de liaison était le seul type de liaison autorisé pour les interfaces demande-réponse des processus longue durée. Pour les autres types de service, un MDB est généré et appelle le service approprié.
Le nom JNDI utilisé par la liaison JMS était une combinaison du nom du BPEL, de l'espace de nom cible et d'un horodatage de début de validité.
Dans WebSphere Studio Application Developer Integration Edition, lorsque la liaison JMS était sélectionnée comme type de déploiement pour un processus BPEL, les options suivantes étaient fournies :
- Fabrique de connexions JNDI - par défaut, jms/BPECF (il s'agit du nom JNDI de la fabrique de connexions de file d'attente du conteneur de processus métier cible)
- File d'attente de la destination JNDI : par défaut, jms/BPEIntQueue (il s'agit du nom JNDI de la file d'attente interne du conteneur du processus métier cible)
- URL de fournisseur JNDI : fournie par le serveur ou personnalisée : vous devez entrer une adresse. L'adresse par défaut est iiop://localhost:2809
Il existe cinq options pour la migration de la liaison de processus JMS de WebSphere Studio Application Developer Integration Edition. Le type de client qui accède au service déterminera les options ci-dessous à exécuter :
Remarque : Une fois les étapes de migration manuelle terminées, le client doit également être migré vers le nouveau modèle de programmation. Voir la rubrique appropriée pour les types de clients suivants :
Tableau 5. Plus d'informations sur la migration des clients
Type de client |
Pour plus d'informations, voir |
Client WSIF qui utilise la liaison de processus JMS |
"Migration du client d'API de messagerie générique de
Business Process Choreographer et du client de liaison de processus JMS" |
API EJB de Generic Business Process Choreographer |
"Migration d'un client utilisant l'EJB de l'API générique de
Business Process Choreographer" |
Migration métier via l'API de messagerie générique de Business Process Choreographer |
"Migration d'un client via l'API de messagerie générique de Business Process Choreographer" |
Autre processus BPEL dans le même module |
Non applicable : connecter ensemble des composants BPEL à l'aide de l'éditeur d'assemblage. |
Autre processus BPEL dans un module différent |
Non applicable : créer une Importation avec liaison SCA dans le module de référence et configurer ses liaisons pour pointer vers l'Exportation avec liaison SCA que vous avez créée plus haut dans la première option. |
Option de migration 1 pour la connexion de processus JMS et JMS
La première option de migration pour la connexion de processus JMS WebSphere Studio Application Developer Integration Edition est d'autoriser l'accès aux processus métier pour un autre composant dans le même module.
Dans l'éditeur d'assemblage, connectez cet autre composant au composant BPEL :
- Sélectionnez l'option Connexion dans la barre d'outils.
- Cliquez sur l'autre composant pour le sélectionner en tant
que source de la connexion.
- Cliquez sur le composant BPEL SCA
pour le sélectionner en tant que cible de la connexion.
- Sauvegardez le diagramme d'assemblage.
Option de migration 2 pour la connexion de processus JMS et JMS
La deuxième option de migration pour la connexion de processus JMS WebSphere Studio Application Developer Integration Edition est d'autoriser l'accès aux processus métier pour d'autres clients et modules SCA.
L'exportation avec liaison SCA rend un composant SCA accessible par d'autres modules SCA. Pour créer une exportation avec liaison SCA, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une exportation avec liaison SCA pour chaque interface
du processus BPEL pour laquelle une liaison JMS a été générée dans
WebSphere
Studio Application Developer Integration Edition :
- Cliquez avec le bouton droit de la souris sur le
composant BPEL dans l'éditeur d'assemblage.
- Sélectionnez Exporter....
- Sélectionnez Liaison SCA.
- S'il existe plusieurs interfaces pour le processus, sélectionnez la ou les
interface(s) à exporter avec ce type de liaison.
- Une fois l'exportation SCA créée, sélectionnez-la dans l'éditeur d'assemblage, puis, dans la vue Propriétés, sélectionnez le volet Description. Le nom de l'exportation et sa description sont répertoriés et peuvent être modifiés si nécessaire.
- Sauvegardez le diagramme d'assemblage.
Option 3 de migration de liaison JMS et de processus JMS
La troisième option de migration de liaison de processus JMS WebSphere est d'autoriser l'accès aux processus métier pour une entité non-SCA (par exemple, un JSP ou un client Java).
La référence autonome autorise l'accès à un composant SCA pour tout client externe. Pour créer une référence autonome, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une référence autonome pour chaque interface de processus BPEL pour laquelle une liaison JMS a été générée dans WebSphere Studio Application Developer Integration Edition :
- Sélectionnez l'élément Références autonomes dans
la barre d'outils.
- Cliquez sur le canevas de l'éditeur d'assemblage pour créer une
entité SCA Références autonomes.
- Sélectionnez l'élément Connexion dans la barre
d'outils.
- Cliquez sur l'entité Références autonomes pour
la sélectionner en tant que source de la connexion.
- Cliquez sur le composant BPEL SCA pour le
sélectionner en tant que cible de la connexion.
- Un message d'alerte s'affiche : Une référence correspondante va être créée sur le noeud source. Voulez-vous continuer ?.
Cliquez sur OK.
- Sélectionnez l'entité Références autonomes qui
vient d'être créée et, dans la vue Propriétés, sélectionnez le volet
Description.
- Développez le lien Références et sélectionnez
la référence qui vient d'être créée. Le nom et la description de la
référence sont répertoriés et peuvent être modifiés si nécessaire.
- S'il existe plusieurs interfaces pour le processus, sélectionnez la
ou les interfaces à exporter avec ce type de liaison.
- Sauvegardez le diagramme d'assemblage.
Option 4 de la migration de liaison JMS et de liaison de processus JMS
La quatrième option de migration pour la connexion de processus JMS WebSphere Studio Application Developer Integration Edition est d'autoriser l'accès aux processus métier pour un client de services Web.
L'exportation avec liaison de services Web rend un composant SCA accessible par un client de services Web externe. Pour créer une exportation avec liaison de service Web, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une exportation avec liaison SCA pour chaque interface
du processus BPEL pour laquelle une liaison JMS a été générée dans
WebSphere
Studio Application Developer Integration Edition :
- Cliquez avec le bouton droit de la souris sur le
composant BPEL dans l'éditeur d'assemblage.
- Sélectionnez Exporter....
- Sélectionnez Liaison de services Web.
- S'il existe plusieurs interfaces pour le processus, sélectionnez la ou les
interface(s) à exporter avec ce type de liaison.
- Sélectionnez le transport : soap/http ou soap/jms.
- Une fois l'exportation de services Web créée, sélectionnez-la dans l'éditeur d'assemblage et dans la vue Propriétés, sélectionnez le volet Description. Le nom de l'export et sa description sont répertoriés et peuvent être modifiés si nécessaire.
- Sauvegardez le diagramme d'assemblage.
Option 5 de la migration de liaison JMS et liaison de processus JMS
La cinquième option de migration pour la connexion de processus JMS WebSphere Studio Application Developer Integration Edition est d'autoriser l'accès aux processus métier pour un client JMS.
L'exportation avec liaison JMS rend un composant SCA accessible par un client JMS externe. Pour créer une exportation avec liaison JMS, procédez comme suit :
- La liaison de processus JMS 5.1 étant très différente de la liaison JMS 5.1 standard, vous devez créer et référencer de nouvelles ressources de file d'attente pour les
services BPEL. Pour les services non BPEL, vous pouvez consulter les valeurs que vous avez sélectionnées pour le code de déploiement JMS dans WebSphere Studio Application Developer Integration Edition 5.1. Pour cela, recherchez le fichier WSDL nommé JMSBinding.wsdl et JMSService.wsdl dans le package approprié se trouvant sous le dossier ejbModule/META-INF du projet de l'EJB généré et consultez les information relatives à la liaison et au service qui s'y trouvent. La partie liaison permet de déterminer si les messages de texte ou d'objet ont été utilisés. Elle permet également de déterminer si des liaisons de format de données personnalisées ont été utilisées. Si tel est le
cas, pensez également à créer une liaison personnalisée de données pour l'exporter
avec liaison JMS de la version 6.x. Les informations sur le service indiquent la fabrique de contextes initiale, le nom de la fabrique de connexions JNDI, le nom de destination JNDI et le style de destination (file d'attente).
- Ouvrez l'éditeur d'assemblage pour le module créé par
l'Assistant de migration.
- Créez une exportation avec liaison JMS pour chaque interface de processus
BPEL pour laquelle une liaison (SOAP/HTTP) de service Web IBM a été générée dans WebSphere Studio Application Developer Integration Edition, en cliquant à l'aide du bouton droit de la souris sur le composant BPEL dans l'éditeur d'assemblage.
- Sélectionnez Exporter....
- Sélectionnez Export avec liaison JMS.
- S'il existe plusieurs interfaces pour le processus, sélectionnez la ou les interface(s) à exporter avec ce type de liaison.
- Dans l'écran suivant (attributs de liaison d'exportation JMS), sélectionnez Domaine de messagerie JMS. Affectez à cet attribut la valeur De point à point.
- Sélectionnez la méthode de sérialisation des données
entre l'objet métier et le message
JMS, puis entrez les valeurs indiquées ci-après. Il
est recommandé de sélectionner Texte plutôt
qu'Objet. L'option Texte correspond généralement
au format XML et est indépendante de l'exécution. Elle permet
l'intégration des services entre différents systèmes hétérogènes.
- Pour Texte, sélectionnez le
sélecteur de fonctions JMS par défaut ou
entrez le nom entièrement qualifié de la classe d'implémentation FunctionSelector.
- Pour Objet, sélectionnez le
sélecteur de fonctions JMS par défaut ou
entrez le nom entièrement qualifié de la classe d'implémentation FunctionSelector.
- Pour Fourni par l'utilisateur,
entrez le nom entièrement qualifié de la classe d'implémentation de
JMSDataBinding. Vous devez sélectionner Fourni par
l'utilisateur si l'application doit accéder à
des propriétés d'en-tête JMS qui ne sont pas disponibles dans la
liaison d'importation JMS. Dans ce cas, vous devez créer une
classe de liaison de données personnalisée étendant
la liaison de données JMS standard
com.ibm.websphere.sca.jms.data.JMSDataBinding,
et ajouter un code personnalisé permettant d'accéder directement
au message JMS. Indiquez ensuite le nom de la classe personnalisée pour cette zone. Pour consulter les exemples JMS se trouvant dans
"Creating and modifying bindings for import and export components",
cliquez sur le lien ci-dessous.
- Pour Fourni par l'utilisateur, sélectionnez le
sélecteur de fonctions JMS par défaut ou
entrez le nom entièrement qualifié de la classe d'implémentation FunctionSelector.
- Une fois l'exportation JMS créée, sélectionnez-la dans l'éditeur
d'assemblage et sélectionnez le volet Description dans
la vue Propriétés. Le nom de l'exportation et sa description sont répertoriés et peuvent être
modifiés si nécessaire.
- Sélectionnez le volet Connexion pour afficher de nombreuses autres options.
- Sauvegardez le diagramme d'assemblage.
Migration de la liaison de services Web IBM (SOAP/JMS)
La liaison de services Web IBM (SOAP/JMS) pour un processus BPEL ou un autre type de service peut être migrée vers la construction SCA recommandée.
Dans WebSphere Studio Application Developer Integration Edition, ce type de liaison permettait aux clients de communiquer avec un processus BPEL ou un autre type de service en appelant un service Web IBM, où le protocole de communication était JMS et le message observait les règles de codage SOAP.
L'exemple suivant montre certaines conventions utilisées lors de la génération d'un service Web IBM (SOAP/JMS) pour un service BPEL 5.1. Le nom JNDI du service Web IBM généré était une combinaison du nom du BPEL, de l'espace de nom cible et d'un horodatage de début de validité, ainsi que du nom de l'interface (type de port WSDL pour lequel le code de déploiement a été généré). Par exemple, ces attributs peuvent être trouvés en examinant les propriétés du processus BPEL dans les onglets Description et Contenu du serveur de l'éditeur BPEL :
Tableau 6. Espace de nom généré
Nom de processus |
MyService |
Espace de nom cible |
http://www.example.com/process87787141/ |
Valide à partir de |
01 janv. 2003 02:03:04 |
Interface |
Type de port du processus |
L'espace de
nom généré pour cet exemple est alors
com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.
Dans WebSphere Studio Application Developer Integration Edition, lorsque la liaison de services Web IBM (SOAP/JMS) était sélectionnée en temps que type de déploiement pour le processus BPEL ou tout autre type de service, les options suivantes étaient fournies :
- Pour le style de document, l'option par défaut était DOCUMENT / autre option : RPC
- Pour l'utilisation du document, l'option par défaut était LITERAL / autre option : ENCODED
- Pour l'URL fournisseur JNDI, il s'agissait de Fourni par le serveur ou
de Personnalisé (une adresse doit être saisie, l'adresse par défaut étant
iiop://localhost:2809)
- Pour le style de destination, l'option par défaut est file d'attente / l'autre option est rubrique
- Pour la fabrique de connexions JNDI, l'option par défaut est jms/qcf (il s'agit du nom JNDI de la fabrique de connexions de file d'attente pour la file d'attente MDB générée)
- Pour la file d'attente de destination JNDI, l'option par défaut est jms/queue (il s'agit du nom JNDI de la file d'attente MDB générée)
- Pour le port d'écoute MDB, l'option par défaut est <Nom projet de service>MPort d'écoute Mdb
Un fichier WSDL spécifiant le service et la liaison SOAP/JMS de service Web IBM est créé dans le projet EJB généré mais pas dans le projet de service lui-même.
Cela signifie que vous devez localiser manuellement ce fichier et le copier dans votre projet de module d'intégration métier si le code client du service Web IBM ne doit pas être modifié.
Par défaut, ce fichier WSDL a été créé dans le projet EJB à l'emplacement ejbModule/META-INF/wsdl/<nom du processus métier>_ <nom du type de port de l'interface processus métier>_JMS.wsdl
Le type de port WSDL et les messages de l'interface processus métier sont également copiés dans ce fichier WSDL, plutôt que de référencer le type de port WSDL et les messages existants définis dans le projet de service.
S'il est important que le code client de services Web IBM reste inchangé après la migration, les informations contenues dans ce fichier seront nécessaires pour les étapes de migration manuelle ci-dessous.
Il existe deux options pour la migration de la liaison de processus SOAP/JMS WebSphere Studio Application Developer Integration Edition. Vous devrez choisir entre migrer le client vers le modèle de programmation SCA ou le conserver comme client de services Web :
Remarque : Une fois les étapes de migration manuelle terminées, le client doit également être migré vers le nouveau modèle de programmation.
Voir la rubrique appropriée pour les types suivants de clients :
Tableau 7. Plus d'informations sur la migration des clients
Type de client |
Pour plus d'informations, voir |
Client de services Web IBM |
"Migration du client (SOAP/JMS) de services Web IBM" |
Option de migration 1 pour la connexion de services Web IBM (SOAP/JMS)
La première option de migration pour la connexion SOAP/JMS de WebSphere Studio Application Developer Integration Edition consiste à rendre le service accessible à un client de services Web.
L'exportation avec liaison de service Web permet de rendre accessible un composant SCA à un client externe de services Web. Pour créer une exportation avec liaison de service Web, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une exportation avec liaison SCA pour chaque interface de service
pour laquelle une connexion (SOAP/JMS) de service Web
IBM
a été générée dans
WebSphere
Studio Application Developer Integration Edition :
- Cliquez avec le bouton droit de la souris sur le composant SCA dans
l'éditeur d'assemblage.
- Sélectionnez Exporter....
- Sélectionnez Liaison de service Web.
- Si le composant est associé à plusieurs interfaces, sélectionnez
celles que vous souhaitez exporter avec ce type de liaison.
- Sélectionnez le transport SOAP/JMS.
- Une fois l'exportation de services Web créée, sélectionnez-la dans l'éditeur d'assemblage et dans la vue Propriétés, sélectionnez le volet Description. Le nom de l'exportation et sa description sont répertoriés et peuvent être modifiés si nécessaire.
- Sauvegardez le diagramme d'assemblage.
- Sélectionnez le panneau du contenu Liaison. Observez qu'un élément
connexion et service de type IBM Web Service WSDL a été directement généré dans le dossier projet du module. Il est nommé composant-exporté Export Nom Typeport WSDL Jms_Service.wsdl. Si vous examinez ce fichier, vous trouverez que la liaison
Document/Literal encapsulée est utilisée par défaut, étant donné qu'il s'agit du style préféré dans
6.x. Ceci est le WSDL que les clients de services Web IBM utiliseront pour appeler le service.
- Suivez les étapes suivantes pour générer une nouvelle liaison de services Web et un service si vous voulez préserver le code client :
- Copiez le fichier WSDL 5.1 dans le projet EJB 5.1 généré dans
ejbModule/META-INF/wsdl/nom_processus
métier/type_port_interface_processus métierJMS.wsdl vers
le projet de module Business Integration.
- Après avoir copié le fichier et recompilé le module, vous verrez peut-être des messages d'erreur car les types de schéma XML, les messages WSDL et les types de port WSDL utilisés par le service Web sont dupliqués dans le fichier WSDL du service Web
IBM
dans la version 5.1. Pour régler ce problème, supprimez les définitions en double du fichier WSDL du service ou de la connexion de service Web IBM et ajoutez à la place un import WSDL pour l'interface WSDL réelle. Remarque : Notez que quand WebSphere Studio Application Developer Integration Edition a généré le code de déploiement du service Web IBM, les définitions de schéma ont aussi été modifiées dans certains cas. Cela peut causer des incohérences pour les clients existants qui utilisent le service Web WSDL IBM. Par exemple, l'attribut de schéma "elementFormDefault" a pris la
valeur "qualified" dans le schéma en ligne généré dans le fichier
WSDL de service Web
IBM
si la définition de schéma d'origine n'était pas qualifiée. L'erreur
suivante sera générée au cours de l'exécution : WSWS3047E:
Error: Cannot deserialize element.
- Avec le bouton droit, cliquez sur le fichier WSDL que vous venez de
copier dans le module Business Integration et sélectionnez
Ouvrir avec puis Editeur WSDL.
- Accédez à l'onglet Source. Supprimez tous les messages et types de port
définis dans ce fichier.
- Vous voyez maintenant l'erreur : Le type de port "<portType>" spécifié pour la connexion "<binding>" n'est pas défini.
Pour régler ce problème, dans l'éditeur WSDL, dans l'onglet
Graphique, cliquez avec le bouton droit dans la section Imports et
sélectionnez Ajouter une importation.
- Dans la vue Propriétés de l'onglet Propriétés générales, cliquez sur
le bouton ... situé à droite de la zone Emplacement. Passez dans l'interface WSDL où résident le message WSDL et les définitions des types de port puis cliquez sur OK pour importer l'interface WSDL dans le
fichier WSDL de la liaison/du service.
- Sauvegardez le fichier WSDL.
- Réactualisez/recompilez le projet. Passez dans la perspective Intégration métier. Ouvrez le diagramme d'assemblage du module dans l'éditeur d'assemblage.
- Dans la vue de l'explorateur de projet, développez le module que vous migrez puis développez la catégorie logique Ports de service Web. Vous devez voir apparaître le port qui existe dans le fichier WSDL de la liaison/du service. Faites-le
glisser dans l'éditeur d'assemblage.
- Choisissez de créer une exportation avec liaison de services Web et sélectionnez le nom de port approprié. Cela créera l'exportation qui utilise la liaison/service antérieurs de sorte que les clients de service Web existants n'aient pas à être modifiés. Si vous sélectionnez l'exportation que vous venez de créer dans l'éditeur d'assemblage et que vous passez dans la vue Propriétés, vous devez voir dans l'onglet Liaison que les noms de service et le port 5.1 ont été entrés pour vous.
- Sauvegardez toutes les modifications.
- Juste avant de déployer l'application, vous pouvez modifier la
configuration du projet Web généré pour refléter l'adresse du service
version 5.1 (vous devez faire ces modifications chaque fois que vous
modifiez le module SCA qui cause la régénération de ce fichier). Si vous regardez la définition Service du fichier WSDL du service Web IBM que vous réutilisez à partir de la version 5.1, vous verrez l'adresse de service codée dans le client 5.1 : <wsdlsoap:address
location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
- Pour que les artefacts du projet Web 6.x généré utilisent cette ancienne adresse de
service, vous devez modifier le descripteur de déploiement du projet Web généré. Ouvrez le descripteur de déploiement dans WebSphere Integration Developer et, dans l'onglet Servlets, ajoutez un autre mappage d'URL
proche du mappage d'URL existant pour cette exportation, avec le même
nom de servlet mais avec un autre modèle d'URL.
- Notez aussi que si vous devez modifier la racine
de contexte de ce projet Web pour qu'elle reflète la racine
de contexte de l'adresse de service d'origine (dans cet exemple, la
racine de contexte est "MyServiceWeb"), vous pouvez alors ouvrir
le descripteur de déploiement de l'application J2EE Enterprise
où réside ce projet Web et modifier la racine de contexte de ce
module Web pour refléter celle de l'ancienne adresse de service. Vous verrez peut-être l'erreur suivante que vous pouvez ignorer : CHKJ3017E: Le projet Web <nom_projet web> est mappé à une racine de contexte non valide : <nouvelle racine de contexte> dans le projet EAR : <nom_application>.
Option de migration 2 pour la connexion de services Web IBM (SOAP/JMS)
La deuxième option de migration pour la connexion de processus SOAP/JMSWebSphere Studio Application Developer Integration Edition est d'autoriser l'accès aux processus métier pour une entité non-SCA (par exemple, un JSP ou un client Java).
La référence autonome permet de rendre un composant SCA accessible à tout type de client externe. Pour créer une référence autonome, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une référence autonome pour chaque interface de processus BPEL pour laquelle une liaison de service Web IBM
(SOAP/JMS) a été générée dans WebSphere Studio Application Developer Integration Edition :
- Sélectionnez l'élément Références autonomes dans la barre d'outils.
- Cliquez sur le canevas de l'éditeur d'assemblage pour créer une entité SCA de références autonomes :
- Sélectionnez l'élément Connexion dans la barre d'outils.
- Cliquez sur l'entité Références autonomes pour la sélectionner en tant que source de connexion.
- Cliquez sur le composant BPEL SCA pour le sélectionner en tant que cible de connexion.
- Un message d'alerte s'affiche : Une référence correspondante va être créée sur le noeud source. Voulez-vous continuer ? .
Cliquez sur OK.
- Sélectionnez l'entité Références autonomes qui vient d'être créée puis, dans la vue des propriétés, sélectionnez le panneau de contenu Description.
- Développez le lien Références et sélectionnez la référence qui vient d'être créée. Le nom et la description de la référence sont répertoriés et peuvent être modifiés le cas échéant.
- Si le processus est associé à plusieurs interfaces, sélectionnez celle(s) que vous souhaitez exporter avec ce type de liaison.
- Sauvegardez le diagramme d'assemblage.
Migration de la liaison de services Web IBM (SOAP/HTTP)
La liaison de services Web IBM (SOAP/HTTP) pour un processus BPEL ou un autre type de service peut être migrée vers la construction SCA recommandée.
Dans WebSphere Studio Application Developer Integration Edition, ce type de liaison permettait aux clients de communiquer avec un processus BPEL ou un autre type de service en appelant un service Web IBM, où le protocole de communication était HTTP et le message observait les règles de codage SOAP.
L'exemple suivant montre certaines conventions utilisées lors de la génération d'un service Web IBM (SOAP/HTTP) pour un service BPEL 5.1. Le nom JNDI du service Web IBM généré était une combinaison du nom du BPEL, de l'espace de nom cible et d'un horodatage de début de validité, ainsi que du nom de l'interface (type de port WSDL pour lequel le code de déploiement a été généré). Par exemple, ces attributs peuvent être trouvés en examinant les propriétés du processus BPEL dans les onglets Description et Contenu du serveur de l'éditeur BPEL :
Tableau 8. Espace de nom généré
Nom de processus |
MyService |
Espace de nom cible |
http://www.example.com/process87787141/ |
Valide à partir de |
01 jan 2003 02:03:04 |
Interface |
Type de port du processus |
L'espace de
nom généré pour cet exemple est alors
com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.
Dans WebSphere Studio Application Developer Integration Edition, lorsque la connexion de services Web IBM (SOAP/HTTP) était sélectionnée en temps que type de déploiement pour le processus BPEL ou tout autre type de service, les options suivantes étaient fournies :
- Pour le style de document, l'option par défaut est RPC / autre option : DOCUMENT
- Pour l'utilisation du document, l'option par défaut est ENCODED / autre option : LITERAL
- Pour l'adresse de routeur, l'option par défaut est http://localhost:9080
Un fichier WSDL spécifiant le service et la connexion SOAP/HTTP de service Web IBM est créé dans les projets EJB et Web générés mais pas dans le projet de service lui-même. Cela signifie que vous devez localiser manuellement ce fichier et le copier dans votre projet de module d'intégration métier si le code client du service Web IBM ne doit pas être modifié. Par défaut, ce fichier WSDL a été créé dans le projet Web à l'emplacement WebContent/WEB-INF/wsdl/<nom du processus métier>_<nom du type de port de l'interface processus métier>_HTTP.wsdl
Le type de port WSDL et les messages de l'interface processus métier sont également copiés dans ce fichier WSDL, plutôt que de référencer le type de port WSDL et les messages existants définis dans le projet de service.
S'il est important que le code client de services Web IBM reste inchangé après la migration, les informations contenues dans ce fichier seront nécessaires pour les étapes de migration manuelle ci-dessous.
Il existe deux options pour la migration de la liaison de processus SOAP/HTTP WebSphere Studio Application Developer Integration Edition. Vous devrez choisir entre migrer le client vers le modèle de programmation SCA ou le conserver comme client de services Web :
Remarque : Une fois les étapes de migration manuelle terminées, le client doit également être migré vers le nouveau modèle de programmation.
Voir la rubrique appropriée pour les types de clients suivants :
Tableau 9. Plus d'informations sur la migration des clients
Type de client |
Pour plus d'informations, voir |
Client de services Web IBM |
"Migration du client (SOAP/HTTP) de services Web IBM" |
Option de migration 1 pour la connexion de services Web IBM (SOAP/HTTP)
La première option de migration pour la connexion de processus SOAP/HTTP de WebSphere Studio Application Developer Integration Edition consiste à rendre des processus métier accessibles à un client de services Web.
L'exportation avec liaison de service Web permet de rendre accessible un composant SCA à un client externe de services Web. Pour créer une exportation avec liaison de service Web, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par
l'Assistant de migration.
- Créez une exportation avec liaison SCA pour chaque interface de processus
BPEL pour laquelle une liaison (SOAP/HTTP) de service Web IBM a été générée dans WebSphere Studio Application Developer Integration Edition, en cliquant avec le bouton droit de la souris sur le composant BPEL dans l'éditeur d'assemblage.
- Sélectionnez Exporter....
- Sélectionnez Liaison de services Web.
- Si le composant est associé à plusieurs interfaces, sélectionnez
celles que vous souhaitez exporter avec ce type de liaison.
- Sélectionnez le transport SOAP/HTTP.
- Une fois l'exportation de services Web créée,
sélectionnez-la dans l'éditeur d'assemblage et dans la vue
Propriétés, sélectionnez le volet Description. Le nom de l'exportation et sa description sont répertoriés et peuvent
être modifiés si nécessaire.
- Sauvegardez le diagramme d'assemblage.
- Suivez les étapes suivantes pour générer une nouvelle liaison de services Web et un service si vous voulez préserver le code client :
- Copiez le fichier WSDL 5.1 depuis le projet EJB généré sous la
version 5.1 dans le fichier ejbModule/META-INF/wsdl/nom_processus
métier/type_port_interface_processus métier_HTTP.wsdl
vers le projet de module Business Integration.
- Après avoir copié le fichier et recompilé le module, vous verrez peut-être des messages d'erreur car les types de schéma XML, les messages WSDL et les types de port WSDL utilisés par le service Web sont dupliqués dans le fichier WSDL du service Web
IBM
dans la version 5.1. Pour régler ce problème, supprimez les définitions en double du fichier WSDL du service ou de la connexion de service Web IBM et ajoutez à la place un import WSDL pour l'interface WSDL réelle. Remarque : notez que quand WebSphere Studio Application Developer Integration Edition a généré le code de déploiement du service Web IBM, les définitions de schéma ont aussi été modifiées dans certains cas. Cela peut causer des incohérences pour les clients existants qui utilisent le service Web WSDL IBM. Par exemple, l'attribut de schéma "elementFormDefault" a pris la
valeur "qualified" dans le schéma en ligne généré dans le fichier
WSDL de service Web
IBM
si la définition de schéma d'origine n'était pas qualifiée. L'erreur
suivante sera générée au cours de l'exécution : WSWS3047E:
Error: Cannot deserialize element.
- Avec le bouton droit, cliquez sur le fichier WSDL que vous venez de
copier dans le module Business Integration et sélectionnez
Ouvrir avec puis Editeur
WSDL.
- Accédez à l'onglet Source. Supprimez tous les messages et types de port
définis dans ce fichier.
- Vous voyez maintenant l'erreur : Le type de port "<portType>" spécifié pour la connexion "<binding>" n'est pas défini.
Pour régler ce problème, dans l'éditeur WSDL, dans l'onglet Graphique,
cliquez avec le bouton droit dans la section Imports et sélectionnez
Ajouter une importation.
- Dans la vue Propriétés de l'onglet Propriétés générales, cliquez sur
le bouton ... situé à droite de la zone Emplacement. Passez dans l'interface WSDL où résident le message WSDL et les définitions des types de port puis cliquez sur OK pour importer l'interface WSDL dans le
fichier WSDL de la liaison/du service.
- Sauvegardez le fichier WSDL.
- Réactualisez/recompilez le projet. Passez dans la perspective Intégration métier. Ouvrez le diagramme d'assemblage du module dans l'éditeur d'assemblage.
- Dans la vue de l'explorateur de projet, développez le module que vous
migrez puis développez la catégorie logique Ports de
service Web. Vous devez voir apparaître le port qui existe dans le fichier WSDL de la liaison/du service. Faites-le glisser dans l'éditeur d'assemblage.
- Choisissez de créer une exportation avec liaison de services Web et sélectionnez le nom de port approprié. Ceci va créer une exportationutilisant l'ancienne liaison/service pour que les clients du service Web actuels ne demandent pas de modification. Si vous sélectionnez l'exportation que vous venez de créer dans l'éditeur d'assemblage et que vous passez dans la vue Propriétés, vous devez voir dans l'onglet Liaison que les noms de service et le port 5.1 ont été entrés pour vous.
- Sauvegardez toutes les modifications.
- Juste avant de déployer l'application, vous pouvez changer la configuration du projet Web généré pour refléter l'adresse du service version 5.1 (vous devez faire ces modifications chaque fois que vous modifiez le module SCA qui cause la régénération de ce fichier). Si vous consultez la définition de service Web IBM WSDL
réutilisée à partir de la version 5.1, vous visualiserez l'adresse de service définie dans le client 5.1 : <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>.
- Pour que les artefacts du projet Web 6.x généré utilisent cette ancienne adresse de
service, vous devez modifier le descripteur de déploiement du projet Web généré. Ouvrez le descripteur de déploiement dans WebSphere Integration Developer et, dans l'onglet Servlets, ajoutez un autre mappage d'URL
proche du mappage d'URL existant pour cette exportation, avec le même
nom de servlet mais avec un autre modèle d'URL.
- Notez aussi que si vous devez modifier la racine de
contexte de ce projet Web pour qu'elle reflète la racine de contexte de
l'adresse de service d'origine (dans cet exemple, la racine de
contexte est "MyServiceWeb"), vous pouvez alors ouvrir le descripteur
de déploiement de l'application J2EE Enterprise où réside ce projet
Web et modifier la racine de contexte de ce module Web pour refléter
celle de l'ancienne adresse de service. Vous verrez peut-être l'erreur suivante que vous pouvez ignorer : CHKJ3017E: Le projet Web <nom_projet web> est mappé à une racine de contexte non valide : <nouvelle racine de contexte> dans le projet EAR : <nom_application>.
Option de migration 2 pour la connexion de services Web IBM (SOAP/HTTP)
La deuxième option de migration pour la connexion de processus SOAP/HTTPWebSphere Studio Application Developer
Integration Edition est d'autoriser l'accès aux processus métier pour une entité non-SCA (par exemple, un JSP ou un client Java).
La référence autonome permet de rendre un composant SCA accessible à tout type
de client externe. Pour créer une référence autonome, procédez comme suit :
- Ouvrez l'éditeur d'assemblage pour le module créé par l'Assistant de migration.
- Créez une référence autonome pour chaque interface pour laquelle une liaison de service Web IBM
(SOAP/HTTP) a été générée dans WebSphere Studio Application Developer
Integration Edition :
- Sélectionnez l'élément Références autonomes dans la barre d'outils.
- Cliquez sur le canevas de l'éditeur d'assemblage pour créer une entité SCA de références autonomes :
- Sélectionnez l'élément Connexion dans la barre d'outils.
- Cliquez sur l'entité Références autonomes pour la sélectionner en tant que source de connexion.
- Cliquez sur le composant SCA pour le sélectionner en tant que cible de connexion.
- Un message d'alerte s'affiche : Une référence correspondante va être créée sur le noeud source. Voulez-vous continuer ?.
Cliquez sur OK.
- Sélectionnez l'entité Références autonomes qui vient d'être créée puis, dans la vue des propriétés, sélectionnez le panneau de contenu Description.
- Développez le lien Références et sélectionnez la référence qui vient d'être créée. Le nom et la description de la référence sont répertoriés et peuvent être modifiés le cas échéant.
- Si le processus est associé à plusieurs interfaces, sélectionnez celles que vous souhaitez exporter avec ce type de liaison.
- Sauvegardez le diagramme d'assemblage.
Migration de la connexion (SOAP/HTTP) de services Web Apache
La connexion de services Web Apache (SOAP/HTTP) pour un processus BPEL ou un autre type de service peut être migrée vers la construction SCA recommandée.
Dans WebSphere Studio Application Developer Integration Edition, ce type de connexion donne aux clients la capacité de communiquer avec un processus BPEL ou tout autre type de service en appelant un service Web Apache.
Dans WebSphere Studio Application Developer Integration Edition, lorsque la connexion du service Web Apache a été sélectionnée comme type de déploiement pour un processus BPEL ou tout autre type de service, les options suivantes ont été données :
- Pour le style de document, il s'agit de RPC (aucune autre option disponible)
- Pour une action SOAP, il s'agit de URN:nom Type de port WSDL
- Pour l'adresse, il s'agit de http://localhost:9080/nom du projet de service Web/servlet/rpcrouter
- Pour Utiliser le codage, l'option par défaut est oui (Si oui, alors le style de codage était défini sur : http://schemas.xmlsoap.org/soap/encoding/)
Un fichier WSDL spécifiant le service et la connexion Apache SOAP est créé dans le projet de service. Par défaut, ce fichier est créé dans le même répertoire que le service qu'il lie, avec le nom
<nom de processus métier>_<nom du type de port de l'interface processus métier>_SOAP.wsdl.
Les messages et le type de port WSDL de l'interface du processus métier sont utilisés directement par ce service et cette connexion. Après la migration, vous ne devriez pas utiliser ce WSDL sauf
éventuellement pour utiliser les mêmes espace de nom, port et noms de service dans le nouveau WSDL
qui sera généré dans la version 6.x.
Il existe deux options pour la migration de la connexion de processus de WebSphere Studio Application Developer Integration Edition Web Service. Un choix devra être fait : migrer le client vers le modèle de programmation SCA ou le laisser en tant que modèle de programmation de services Web IBM. Il n'existe plus de connexion équivalente au type de connexion de services Web Apache (SOAP/HTTP) dans le modèle de programmation SCA V6.
Vous devez migrer ce service Web Apache pour utiliser le moteur IBM Web Service. Pour des instructions sur l'exécution de cette migration et la création d'un service Web IBM (SOAP/HTTP), voir la rubrique "Migration de la liaison de services Web IBM (SOAP/HTTP)".
Pour tout code Java de format libre qui interagit avec un service WebSphere Studio Application Developer Integration Edition, cette section montrera comment migrer le modèle de programmation WSIF vers le nouveau modèle de programmation SCA où les données qui transitent dans l'application sont stockées dans des objets SDO Eclipse. Cette section décrit également la migration manuelle des types de client les plus communs vers le nouveau modèle de programmation.
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 où les données qui transitent par l'application sont stockées dans les objets SDO (Service Data Objects) Eclipse. Lorsque cela est possible, les fragments sont automatiquement migrés par l'Assistant de migration, mais il existe des fragments que l'Assistant de migration ne peut pas migrer complètement, ce qui signifie que des étapes manuelles sont nécessaires afin de terminer la migration.
Voici un récapitulatif des modifications apportées au modèle de programmation :
- Modèle de programmation V5.1
-
- Basé sur WSIF et WSDL
- Proxys générés pour les services
- Beans et gestionnaires de mise en forme pour les types
- Modèle de programmation V6.x (plus centré sur Java)
-
- Services SCA basés sur les SDO avec balises doclet
- Connexions d'interface pour les services
- SDO et connexions de données pour les types
Migration des appels des API WSIFMessage vers les API SDO
La section suivante décrit comment migrer l'ancien modèle de programmation de
WebSphere Business
Integration Server Foundation version 5.1, avec lequel les données transitant par l'application sont
représentées sous la forme d'objets WSIFMessage avec une interface spécifique vers le nouveau modèle de
programmation de WebSphere
Process Server, dans lequel les données sont représentées sous la forme d'objets SDO (Service Data
Objects) sans création d'une interface spécifique.
Tableau 10. Modifications et solutions pour la migration des appels des API WSIFMessage vers les API SDO
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 complexes. |
Lorsque vous écrivez du code qui interagit avec les services SCA, vous devez utiliser les API SDO Generic pour manipuler les messages commonj.sdo.DataObject contenant les données qui transitent par l'application.
Les définitions de message WSDL avec une seule partie simple seront maintenant représentées par un type Java simple qui représente directement la partie, plutôt qu'un conteneur soit placé autour des données réelles. Si la partie de message simple a un type complexe, les données sont représentées comme un DataObject conforme à la définition de type complexe.
Les définitions de message WSDL qui possèdent plusieurs parties correspondent maintenant à un DataObject qui a des propriétés pour toutes les parties de message, où les complexTypes sont représentés comme des propriétés "référence-type" du DataObject parent, accessibles via les méthodes getDataObject et setDataObject. |
Vous ne devez plus utiliser les méthodes getter spécifiques pour les parties WSIFMessage et les beans Java générés. |
Vous devez utiliser l'API SDO non spécifique pour obtenir les propriétés DataObject. |
Les méthodes setter spécifiques pour les messages des variables BPEL ne sont plus disponibles. |
L'API SDO non spécifique doit être utilisée pour définir les propriétés DataObject. |
Vous ne devez plus utiliser les méthodes getter non spécifiques pour les propriétés WSIFMessage. |
L'API SDO non spécifique doit être utilisée pour définir les propriétés DataObject. |
Vous ne devez plus utiliser les méthodes setter non spécifiques pour les propriétés WSIFMessage. |
L'API SDO non spécifique doit être utilisée pour définir les propriétés DataObject. |
Le cas échéant, tous les appels API WSIFMessage doivent être migrés vers l'API SDO. |
Dans la mesure du possible, migrez l'appel vers un appel API SDO équivalent. Sinon, concevez de nouveau la logique. |
Migration du code client de WebSphere Business Integration Server Foundation
Cette section décrit comment migrer les différents types de client disponibles pour les types de service WebSphere Business Integration Server Foundation 5.1.
Migration du client EJB
Cette rubrique traite de la migration de clients qui utilisent une interface EJB pour appeler un service.
- Glissez/déplacez l'exportation avec liaison SCA depuis le module migré vers l'instance d'éditeur d'assemblage du nouveau module. Cela va créer une importation avec liaison SCA.
Pour qu'un client obtienne une référence à cet importation, vous devez créer une référence autonome.
- Sélectionnez l'option Référence autonome dans la palette. Cliquez une fois sur le canevas de l'éditeur d'assemblage une fois pour créer une nouvelle référence autonome pour ce nouveau module.
- Sélectionnez l'outil Connexion et cliquez sur la référence du service, puis sur Importer.
- Cliquez sur OK quand un message vous dit qu'une référence correspondante sera créé sur le noeud source.
- Vous recevez le message suivant : It is easier for a Java client to use a
Java interface with this reference - would you like to convert the WSDL reference
to a compatible Java reference? (Il est plus facile pour un client Java d'utiliser une interface Java avec cette référence. Voulez-vous convertir la référence WSDL en référence compatible Java ?) :
- Cliquez sur Oui si vous souhaitez que le client recherche ce service et effectue un transtypage vers une classe Java pour l'appeler à l'aide d'une interface Java.
Cette nouvelle interface Java prend le nom du type de port WSDL. Le module de l'interface provient de l'espace de nom du type de port WSDL. Une méthode est définie pour chaque opération définie sur le type de port WSDL et chaque message WSDL est représenté par un argument dans les méthodes de l'interface.
- Cliquez sur Non si vous souhaitez que le client recherche ce service et utilise l'interface Generic com.ibm.websphere.sca.Service pour l'appeler à l'aide de l'opération d'appel en tant que service SCA générique.
- Si besoin, donnez à la référence autonome un nom plus significatif en sélectionnant l'option Références autonomes dans l'éditeur d'assemblage. Passez dans la vue Propriétés, onglet Détails, puis recherchez et sélectionnez la référence qui vient d'être créée. Modifiez son nom. Gardez en mémoire le nom choisi pour cette référence car le client devra utiliser celui-ci lors de l'appel de la méthode locateService de l'instance com.ibm.websphere.sca.ServiceManager.
- Cliquez sur Sauvegarder pour sauvegarder le diagramme d'assemblage.
Le nouveau module doit se trouver dans le chemin de classe local du client pour que l'on puisse accéder au module EJB migré qui s'exécute sur le serveur.
Voici à quoi ressemble le code client pour un service de type "CustomerInfo" :
// Créer un gestionnaire de services
ServiceManager serviceManager = ServiceManager.INSTANCE;
// Localiser le service CustomerInfo
CustomerInfo customerInfoService = (CustomerInfo) serviceManager.locateService
("<name-of-standalone-reference-from-previous-step");
// Appeler le service CustomerInfo
System.out.println(" [getMyValue] getting customer info...");
DataObject customer = customerInfoService.getCustomerInfo(customerID);
Le client doit modifier la structure du message.
Auparavant, les messages étaient basés sur la classe WSIFMessage mais ils doivent maintenant être basés sur la classe commonj.sdo.DataObject.
Migration du client de liaison de processus EJB
Cette rubrique traite de la migration de clients utilisant le processus de liaison de l'EJB WSIF pour accéder à un service BPEL.
Les clients qui utilisaient la liaison de processus EJB pour appeler un processus métier doivent maintenant utiliser l'API SCA pour appeler le service (le processus métier migré doit avoir un export avec connexion SCA) ou l'API du client IBM Web Service pour appeler le service (le processus métier migré doit avoir une exportationation avec liaison de services Web).
Voir les rubriques "Migration du client EJB", "Migration du
client IBM
Web Service (SOAP/JMS)"; ou "Migration du client
IBM
Web Service (SOAP/HTTP)" pour plus d'informations sur la génération de ce type de client.
Migration du client IBM Web Service (SOAP/JMS)
Cette rubrique traite de la migration de clients qui utilisent les API de services Web (SOAP/JMS) pour appeler un service.
Aucune migration n'est nécessaire pour les clients existants pendant la migration. Notez que vous devez modifier manuellement le projet Web généré (créez un mappage de servlet) et parfois modifier la racine de contexte du projet Web dans le descripteur de déploiement de l'application d'entreprise pour publier le service à la même adresse que celle à laquelle il avait été publié sur WebSphere Business Integration Server Foundation. Voir la rubrique "Migration de la liaison de services Web IBM (SOAP/JMS)".
Notez
que contrairement à la version 5.1, dans laquelle un proxy client WSIF ou RPC pouvait être généré,
dans la version 6.x , les outils prennent uniquement en charge la génération de client RPC car
RPC est l'API préférée de cette version par rapport aux API WSIF.
Remarque : pour générer un nouveau proxy client à partir de WebSphere Integration Developer, un serveur WebSphere Process Server ou WebSphere Application Server doit être installé sur votre système.
- Vérifiez qu'un serveur WebSphere Process Server ou WebSphere Application Server est installé.
- Dans la perspective Ressources ou Java, recherchez le fichier WSDL correspondant à l'exportation avec liaison de services Web, puis cliquez avec le bouton droit de la souris et sélectionnez Services Web -> Générer client (notez que cet assistant ressemble beaucoup à l'assistant de la version 5.1).
- Pour le type du proxy client, sélectionnez Proxy Java et cliquez sur Suivant.
- L'emplacement de WSDL doit être indiqué. Cliquez sur Suivant.
- Vous devez ensuite sélectionner les options appropriées pour indiquer la configuration de l'environnement client, notamment le serveur et l'exécution du service Web, la version de J2EE, le type de client (Java, EJB, Web, Client d'application). Cliquez sur Suivant.
- Terminez les étapes restantes pour créer le proxy client.
Migration du client IBM Web Service (SOAP/HTTP)
Cette rubrique traite de la migration de clients utilisant les API de services Web (SOAP/HTTP) pour appeler un service.
Aucune migration n'est nécessaire pour les clients existants pendant la migration. Notez que vous devez modifier manuellement le projet Web généré (créez un mappage de servlet) et parfois modifier la racine de contexte du projet Web dans le descripteur de déploiement de l'application d'entreprise pour publier le service à la même adresse que celle à laquelle il avait été publié sur WebSphere Business Integration Server Foundation. Voir "Migration de la liaison de services Web IBM (SOAP/HTTP)".
Si des modifications de conception ont été effectuées et que vous souhaitez créer un nouveau proxy client, suivez les étapes ci-dessous. Notez que contrairement à la version 5.1, dans laquelle un proxy
client WSIF ou RPC pouvait être généré, dans la version 6.x , les outils prennent uniquement
en charge la génération de client RPC car RPC est l'API préférée de cette version par rapport aux
API WSIF.
Remarque : Pour générer un nouveau proxy client à partir de WebSphere Integration Developer, un serveur WebSphere Process Server ou WebSphere Application Server doit être installé sur votre système.
- Vérifiez qu'un serveur WebSphere Process Server ou WebSphere Application Server est installé.
- Sélectionnez le fichier WSDL correspondant à l'exportation avec liaison de services Web, puis cliquez avec le bouton droit de la souris et sélectionnez Services Web -> Générer client (notez que cet assistant ressemble beaucoup à l'assistant de la version 5.1).
- Pour le type du proxy client, sélectionnez Proxy Java et cliquez sur Suivant.
- L'emplacement de WSDL doit être indiqué. Cliquez sur Suivant.
- Vous devez ensuite sélectionner les options appropriées pour indiquer la configuration de l'environnement client, notamment le serveur et l'exécution du service Web, la version de J2EE, le type de client (Java, EJB, Web, Client d'application). Cliquez sur Suivant.
- Terminez les étapes restantes pour créer le proxy client.
Migration du client Apache Web Service (SOAP/HTTP)
Les API du client Apache Web Service ne sont pas appropriées pour appeler un service WebSphere Integration Developer. Le code client doit être migré pour que les API client IBM Web Service (SOAP/HTTP) soient utilisables.
Pour plus d'informations, voir la rubrique "Migration du client IBM Web Service (SOAP/HTTP)".
Dans la version 5.1, si un proxy client était automatiquement généré, ce proxy utilisait les API WSIF pour interagir avec le service. Dans la version 6.x , les outils prennent
uniquement en charge la génération de client RPC car RPC est l'API préférée de cette version par
rapport aux API WSIF.
Remarque : Pour générer un nouveau proxy client à partir de WebSphere Integration Developer, un serveur WebSphere Process Server ou WebSphere Application Server doit être installé sur votre système.
- Vérifiez qu'un serveur WebSphere Process Server ou WebSphere Application Server est installé.
- Sélectionnez le fichier WSDL correspondant à l'exportation avec liaison de services Web, puis cliquez à l'aide du bouton droit de la souris et sélectionnez Services Web -> Générer client (notez que cet assistant ressemble beaucoup à l'assistant de la version 5.1).
- Sélectionnez Proxy Java comme type du proxy client et cliquez sur Suivant.
- L'emplacement de WSDL doit être indiqué. Cliquez sur Suivant.
- Vous devez ensuite sélectionner les options appropriées pour indiquer la configuration de l'environnement client, notamment le serveur et l'exécution du service Web, la version de J2EE, le type de client (Java, EJB, Web, Client d'application). Cliquez sur Suivant.
- Termnez les étapes restantes pour créer le proxy client.
Migration du client JMS
Les clients ayant communiqué avec un service 5.1 via l'API JMS (envoi d'un message JMS dans une file d'attente) peuvent nécessiter une migration manuelle. Cette rubrique traite de la migration de clients utilisant des API JMS pour appeler un service.
Vous devez vous assurer que l'exportation avec liaison JMS que vous avez créée lors d'une étape précédente sera en mesure d'accepter le message de texte ou d'objet sans avoir à le modifier. Vous devrez peut-être écrire une liaison de données personnalisée pour cela. Voir la section "Migration de liaison JMS et de liaison de processus JMS" pour plus d'informations.
Le client doit modifier la structure du message.
Auparavant, les messages étaient basés sur la classe WSIFMessage mais ils doivent maintenant être basés sur la classe commonj.sdo.DataObject. Pour plus d'informations sur cette migration manuelle, voir la section "Migration des appels d'API WSIFMessage vers les API SDO".
Migration du client d'API de l'EJB générique Business Process Choreographer
Cette rubrique traite de la migration de clients utilisant l'API
d'EJB générique de Process Choreographer 5.1 pour appeler un service BPEL.
Une nouvelle version de l'API d'EJB générique EJB utilise DataObjects comme
format de message. Le client doit modifier la structure du message.
Auparavant, les messages étaient basés sur la classe WSIFMessage mais ils doivent maintenant être basés sur la classe commonj.sdo.DataObject. Notez que l'API Generic EJB n'a pas beaucoup changé puisque ClientObjectWrapper fournit toujours un conteneur de message associé au format du message.
Ex : DataObject dobj = myClientObjectWrapper.getObject();
String result = dobj.getInt("resultInt");
Le nom JNDI de l'ancien
EJB générique qui prend les objets WSIFMessage est le suivant :
GenericProcessChoreographerEJB
Nom JNDI : com/ibm/bpe/api/BusinessProcessHome
Interface : com.ibm.bpe.api.BusinessProcess
Il existe deux API Generic EJB dans la version 6.0 car les opérations de tâche manuelle sont maintenant disponibles dans un EJB séparé. Les noms JNDI V6.0 de ces API Generic EJB sont les suivants :
GenericBusinessFlowManagerEJB
Nom JNDI : com/ibm/bpe/api/BusinessFlowManagerHome
Interface : com.ibm.bpe.api.BusinessFlowManager
HumanTaskManagerEJB
Nom JNDI : com/ibm/task/api/TaskManagerHome
Interface : com.ibm.task.api.TaskManager
Migration du client API de messagerie générique de Generic Business Process
Choreographer et du client de liaison de processus JMS
Il n'existe pas d'API de messagerie générique dans
WebSphere
Process Server. Voir "Migration de la liaison JMS et de la liaison de processus JMS" pour choisir une autre manière d'exposer le processus métier aux consommateurs et réécrire le client en fonction de la liaison sélectionnée.
Migration du client Web de Business Process Choreographer
Cette rubrique traite de la migration de paramètres clients Web et de JSP personnalisés de Process Choreographer 5.1.
L'Assistant de migration conserve les paramètres client Web 5.1 ; vous pouvez éditer ceux-ci dans l'Editeur de tâche manuelle. Vous devez créer des paramètres client Web et des JSP à l'aide
de WebSphere
Integration Developer 6.x.
- Migration des modifications du client Web
- Dans la version 5.1, vous pouviez modifier l'apparence du client Web Struts en modifiant son JSP Header.jsp et sa feuille de style dwc.css.
Depuis la version 6.x, le client Web (renommé Explorateur Business Process Choreographer) est basé sur
Java
Server Faces (JSF) plutôt que sur Struts ; la migration automatique des modifications du client Web
n'est pas possible. Par conséquent, nous vous recommandons de consulter la documentation de
l'"Explorateur Business Process Choreographer" pour plus d'informations sur la personnalisation de
la version 6.x de cette application.
Les JSP définis par
l'utilisateur peuvent être définis pour les processus métier ainsi que pour les
activités de personnel. Le client Web utilise ces JSP afin d'afficher les messages d'entrée et de sortie pour le processus et les activités.
Ces JSP sont particulièrement utiles dans les cas suivants :
- Les messages ont des parties non-primitives pour étendre l'utilisation de la structure de données du message.
- Vous souhaitez étendre les fonctionnalités du client Web.
Les options disponibles
sont différentes et plus nombreuses lorsque vous indiquez les paramètres du client Web pour un
processus 6.x. Par conséquent, vous devrez utiliser
WebSphere
Integration Developer afin de concevoir de nouveau les paramètres du client Web pour les activités
et les processus migrés :
- Sélectionnez le canevas de processus ou une activité dans le processus.
- Dans la vue Propriétés, sélectionnez l'onglet Client pour concevoir de nouveau les paramètres du client Web.
- Migrez manuellement tous les JSP définis par l'utilisateur :
- Voir la section "Migration du modèle de programmation SCA"
concernant la modification du modèle de programmation.
- Le client Web utilise les API génériques pour interagir avec les processus métier.
Reportez-vous aux sections décrivant la migration d'appels vers ces API génériques.
- Spécifiez le nom du nouveau JSP dans les paramètres du client Web 6.x pour le processus
Remarque : Les
JSP de mappage ne sont pas nécessaires avec l'explorateur Business Process Choreographer 6.x
car DataObjects ne requiert aucun mappage personnalisé.
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".
Lorsque c'est 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.x de Business Process Choreographer :
Tableau 11. 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 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).
Etant donné que les variables BPEL
peuvent être utilisées directement dans les fragments 6.x , 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 temps 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.x 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 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 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 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).
Notez qu'il existait deux variations de la méthode getVariableAsWSIFMessage :
getVariableAsWSIFMessage
(String variableName)
getVariableAsWSIFMessage(String variableName,
boolean forUpdate)
L'accès par défaut, dans le cadre d'une activité de fragment de code Java, est en lecture-écriture. Vous pouvez le modifier en accès en lecture seule. Pour ce faire, indiquez @bpe.readOnlyVariables dans la liste des noms de variables mise en commentaire dans le fragment. Par exemple, vous pouvez mettre les variables B et D en lecture seule :
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"
De plus, si vous disposez d'un fragment de code Java répondant à ces conditions, les variables sont par défaut en lecture seule. Vous pouvez toutefois modifier leur accès en lecture-écriture. Pour ce faire, indiquez @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 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 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.x :
getVariableProperty(String variableName,
QName propertyName);
Dans la version 6.x , 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.x 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.x :
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 =
getCorrelationSetCorrSetAPropertyCustomerName();
int corrSetPropInt =
getCorrelationSetCorrSetBPropertyCustomerId();
- Fragment V6.x :
-
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.x :
-
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.x :
-
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. |
Migration des interactions avec les adaptateurs WebSphere Business Integration
Si le client JMS est un adaptateur
WebSphere
Business Integration, vous pouvez avoir besoin d'utiliser les outils de service externe pour créer
l'importation avec liaison JMS. Cette importation utilise une liaison de données spéciale pour sérialiser le SDO au format attendu par l'adaptateur WebSphere Business Integration.
Pour accéder aux outils de service externe, procédez comme suit :
- Naviguez jusqu'à
Fichier -> Nouveau -> Autre -> Business Integration et sélectionnez Service externe. Cliquez sur Suivant.
- Choisissez Adaptateurs. Cliquez sur Suivant.
- Entrez le chemin du fichier de configuration (.cfg) de l'adaptateur WebSphere Business Integration et le répertoire qui contient le schéma XML des objets métier utilisés par l'adaptateur. Cliquez sur Suivant.
- Examinez la requête générée et, si elle est correcte, cliquez sur
Exécuter la requête. Dans la liste des Objets reconnus par la requête, sélectionnez les objets que vous voulez ajouter (un par un) et cliquez sur le bouton >> Ajouter.
- Acceptez les paramètres de configuration pour l'objet métier et
cliquez sur OK.
- Répétez cette procédure pour chaque objet métier.
- Cliquez sur Suivant.
- Pour Format des objets métier d'exécution,
sélectionnez SDO.
Pour Projet cible, sélectionnez le module
que vous venez de migrer.
Laissez vide la zone Dossier.
- Cliquez sur Terminer.
Cet outil va migrer les anciens XSD au format attendu par la liaison de données spéciale. Vous devez donc supprimer du module les anciens XSD de l'adaptateur WebSphere Business Integration et utiliser les nouveaux XSD. Si le module n'est pas supposé recevoir les messages de l'adaptateur, supprimez les exportations générées par cet outil. Si le module n'est pas supposé envoyer des messages à l'adaptateur, supprimez l'importation. Voir le centre de documentation pour plus d'informations sur cette fonction.
Migration d'interfaces WSDL avec des types de tableau encodé soap
Cette section décrit comment migrer ou gérer des schémas XML avec des types de tableau encodé soap.
Les types de tableau encodé soap répondant au style RPC sont traités par la version
6.x comme séquences illimitées d'un type concret. Il n'est pas recommandé de créer des types XSD qui référencent les types soapend:Array, car le modèle de programmation se déplace vers le style encapsulé Document/Literal plutôt que vers le style RPC (bien que cela soit variable).
Dans certains cas, une application SCA doit appeler un service externe qui utilise le type soapend:Array. Dans certains cas, il est impossible d'éviter ce point. Pour le résoudre, procédez comme suit :
Exemple de code WSDL :
<xsd:complexType name="Vendor">
<xsd:all>
<xsd:element name="name" type="xsd:string" />
<xsd:element name="phoneNumber" type="xsd:string" />
</xsd:all>
</xsd:complexType>
</xsd:schema>
<xsd:complexType name="Vendors">
<xsd:complexContent mixed="false">
<xsd:restriction base="soapenc:Array">
<xsd:attribute wsdl:arrayType="tns:Vendor[]" ref="soapenc:arrayType"
xmlnxsd:wsdl="http://schemas.xmlsoap.org/wsdl/" />
</xsd:restriction>
</xsd:complexContent>
<xsd:complexType name="VendorsForProduct">
<xsd:all>
<xsd:element name="productId" type="xsd:string" />
<xsd:element name="vendorList" type="tns:Vendors" />
</xsd:all>
</xsd:complexType>
<xsd:complexType name="Product">
<xsd:all>
<xsd:element name="productId" type="xsd:string" />
<xsd:element name="productName" type="xsd:string" />
</xsd:all>
</xsd:complexType>
<message name="doFindVendorResponse">
<part name="returnVal" type="tns:VendorsForProduct" />
</message>
<operation name="doFindVendor">
<input message="tns:doFindVendor" />
<output message="tns:doFindVendorResponse" />
</operation>
Exemple de code pour un client de ce service Web :
Localiser le service du fournisseur et rechercher l'opération doFindVendor
Service findVendor=(Service)ServiceManager.INSTANCE.locateService("vendorSearch");
OperationType doFindVendorOperationType=findVendor.getReference()
.getOperationType("doGoogleSearch");
Créer l'objet de données (DataObject) de l'entrée
DataObject doFindVendor=DataFactory.INSTANCE.create
(doFindVendorOperationType.getInputType());
doFindVendor.setString("productId", "12345");
doFindVendor.setString("productName", "Refrigerator");
Appeler le service FindVendor
DataObject FindVendorResult =
(DataObject)findVendor.invoke(doFindVendorOperationType,
doFindVendor);
Afficher les résultats
int resultProductId=findVendorResult.getString("productId");
DataObject resultElements=findVendorResult.getDataObject("vendorList");
Sequence results=resultElements.getSequence(0);
for (int i=0, n=results.size(); i
for (int i=0, n=results.size(); i
Voici un autre exemple dans lequel le type racine de l'objet de données est soapenc:Array. Remarquez la façon dont l'objet de données (DataObject) sampleElements est créé à l'aide du second schéma listé ci-dessus.
Le type de l'objet de données, puis la propriété de sampleStructElement sont obtenus. Il s'agit véritablement d'une propriété de signet qui est uniquement utilisée pour obtenir une propriété valide permettant d'ajouter les DataObjects à la séquence. Le modèle suivant peut être utilisé dans votre scénario :
Exemple de code WSDL :
<s:schema elementFormDefault="qualified" targetNamespace="http://soapinterop.org/xsd">
<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
<s:import namespace="http://schemas.xmlsoap.org/wsdl/" />
<s:complexType name="SOAPStruct">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" form="unqualified"
name="varInt" type="s:int" />
<s:element minOccurs="1" maxOccurs="1" form="unqualified"
name="varString" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" form="unqualified"
name="varFloat" type="s:float" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfSOAPStruct">
<s:complexContent mixed="false">
<s:restriction base="soapenc:Array">
<s:attribute wsdl:arrayType="s0:SOAPStruct[]" ref="soapenc:arrayType" />
</s:restriction>
</s:complexContent>
</s:complexType>
</s:schema>
<wsdl:message name="echoStructArraySoapIn">
<wsdl:part name="inputStructArray" type="s0:ArrayOfSOAPStruct" />
</wsdl:message>
<wsdl:message name="echoStructArraySoapOut">
<wsdl:part name="return" type="s0:ArrayOfSOAPStruct" />
</wsdl:message>
<wsdl:operation name="echoStructArray">
<wsdl:input message="tns:echoStructArraySoapIn" />
<wsdl:output message="tns:echoStructArraySoapOut" />
</wsdl:operation>
<schema targetNamespace="http://sample/elements"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://sample/elements">
<element name="sampleStringElement" type="string"/>
<element name="sampleStructElement" type="any"/>
</schema>
Exemple de code pour un client de ce service Web :
Créer l'objet de données (DataObject) de l'entrée puis
obtenir la séquence SDO pour l'élément any
DataFactory dataFactory=DataFactory.INSTANCE;
DataObject arrayOfStruct =
dataFactory.create("http://soapinterop.org/xsd","ArrayOfSOAPStruct");
Sequence sequence=arrayOfStruct.getSequence("any");
Obtenir la propriété SDO pour l'élément exemple à utiliser
dans ce cas pour remplir la séquence
Nous avons défini cet élément dans le fichier SampleElements.xsd
DataObject
sampleElements=dataFactory.create("http://sample/elements",
"DocumentRoot");
Property property =
sampleElements.getType().getProperty("sampleStructElement");
Ajouter les éléments à la séquence
DataObject item=dataFactory.create("http://soapinterop.org/xsd",
"SOAPStruct");
item.setInt("varInt", 1);
item.setString("varString", "Hello");
item.setFloat("varFloat", 1.0f);
sequence.add(property, item);
item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 2);
item.setString("varString", "World");
item.setFloat("varFloat", 2.0f);
sequence.add(property, item);
Appeler l'opération echoStructArray
System.out.println("[client] invoking echoStructArray operation");
DataObject echoArrayOfStruct =
(DataObject)interopTest.invoke("echoStructArray", arrayOfStruct);
Afficher les résultats
if (echoArrayOfStruct!=null) {
sequence=echoArrayOfStruct.getSequence("any");
for (int i=0, n=sequence.size(); i<n; i++) {
item=(DataObject)sequence.getValue(i);
System.out.println("[client] item varInt = "+
item.getInt("varInt")+"
varString="+item.getString("varString")+"
varFloat="+item.getFloat("varFloat"));
Migration des projets EJB WebSphere Business Integration
Dans WebSphere Studio Application Developer Integration Edition, les projets EJB peuvent avoir des fonctionnalités WebSphere Business Integration spécifiques, telles que la Messagerie étendue (CMM) et CMP/A (Component-Managed Persistence Anywhere). Les descripteurs de déploiement pour ce type de projet doivent être migrés ; cette section explique comment effectuer cette migration.
Pour effectuer cette migration, procédez comme suit :
- Copiez le projet EJB
WebSphere Business
Integration vers le nouvel espace de travail et importez-le à partir de
WebSphere
Integration Developer à l'aide de l'assistant
Fichier -> Importer -> Existing Project into Workspace (Projet existant dans l'espace de travail).
En outre, vous pouvez éventuellement exécuter l'Assistant de migration J2EE.
- Fermez toutes les instances de
WebSphere
Integration Developer en cours d'exécution dans l'espace de travail 6.x.
- Exécutez le script suivant pour migrer les descripteurs de déploiement WebSphere Business Integration dans le projet EJB :
- Sous Windows :
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/
WSADIEEJBProjectMigration.bat
- Sous Linux :
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/
WSADIEEJBProjectMigration.sh
Les paramètres suivants sont pris en charge (l'espace de travail et le nom du projet sont obligatoires) :
Syntaxe : WSADIEEJBProjectMigration.bat
[-e dossier-eclipse] -d espace-travail -p projet
dossier-eclipse : Emplacement de votre dossier Eclipse -- il s'agit
généralement de l'élément 'eclipse'
situé sous le dossier d'installation du produit.
espace-travail : Espace de travail contenant le projet
WSADIE EJB à migrer.
projet : Nom du projet à migrer.
Par exemple,
WSADIEEJBProjectMigration.bat -e "C:\IBM\WID6\eclipse" -d "d:\my60workspace"
-p "MyWBIEJBProject"
- Lorsque vous ouvrez WebSphere Integration Developer, vous devez actualiser le projet EJB afin d'obtenir les fichiers mis à jour.
- Recherchez le fichier ibm-web-ext.xmi dans le projet EJB. Si vous le trouvez, vérifiez que la ligne suivante est présente dans ce fichier sous l'élément :
<webappext:WebAppExtension> element:
<webApp href="WEB-INF/web.xml#WebApp"/>
- Supprimez l'ancien code de déploiement généré dans la version 5.1. Recréez le code de déploiement en suivant les instructions de WebSphere Application Server.
Suppression manuelle des définitions WSIF (Web Services Invocation Framework)
Après avoir terminé la migration des artefacts source, supprimez toutes les définitions
WSDL de liaisons et de services WSIF 5.1 qui ont été configurées pour des projets 6.x mais
ne sont plus utilisées. Le scénario de consommation pour la migration de services est le seul cas dans lequel une liaison ou un service WSIF peut encore être utilisé.
Les espaces de nom WSDL ci-après indiquent qu'une définition de liaison ou de service est un service WSIF 5.1 pouvant être supprimé s'il n'est plus utilisé :
- Espace de nom WSIF JMS :
- http://schemas.xmlsoap.org/wsdl/ejb/
- Espace de nom WSIF Java :
- http://schemas.xmlsoap.org/wsdl/java/
- Espace de nom WSIF JMS :
- http://schemas.xmlsoap.org/soap/jms/
- Espace de nom WSIF d'un processus métier :
- http://schemas.xmlsoap.org/wsdl/process/
- Espace de nom WSIF du transformateur :
- http://schemas.xmlsoap.org/wsdl/transformer/
- Espace de nom WSIF IMS :
- http://schemas.xmlsoap.org/wsdl/ims/
- Espace de nom WSIF CICS-ECI :
- http://schemas.xmlsoap.org/wsdl/cicseci/
- Espace de nom WSIF CICS-EPI :
- http://schemas.xmlsoap.org/wsdl/cicsepi/
- Espace de nom WSIF HOD :
- http://schemas.xmlsoap.org/wsdl/hod3270/
Vérification de la migration de l'artefact source
Lorsque l'exécution de l'assistant d'installation échoue, une liste répertoriant les erreurs, les avertissements et/ou les messages informatifs s'affiche dans la fenêtre Résultats de la migration.
Sinon, la fenêtre de l'assistant se fermera dans le cas où la migration aboutit.
Si des messages de migration ont été générés pendant le processus de migration, la page suivante apparaît :
La fenêtre Résultats de la migration présente les messages de migration qui ont été générés lors du processus de migration. Sélectionnez un message dans la liste des messages supérieure située en haut pour visualiser d'autres informations le concernant dans la fenêtre inférieure Description du message.
Pour
conserver tous les messages afin de vous y référer ultérieurement, cliquez sur le bouton
Générer un pense-bête pour créer une liste des tâches à effectuer dans la vue
des tâches et/ou cliquez sur le bouton Enregistrer sous... pour sauvegarder les
messages dans un fichier texte dans le système de fichiers.
Examinez chaque message pour savoir si une action doit être entreprise pour corriger immédiatement un artefact dont la migration n'a pas abouti. Pour visualiser l'agenda généré, cliquez sur Fenêtre -> Afficher la vue -> Autre... -> Général -> Tâches, puis sur OK.
La vue Tâches affiche la liste de l'agenda généré à partir du processus
de migration.
Pour vérifier qu'une partie de la migration a été effectuée, passez sur la perspective Business Integration et vérifiez que tous les processus et interfaces WSDL de l'ancien projet de service apparaît dans le nouveau module. Créez le projet et corrigez toutes les erreurs empêchant sa création.
Une fois terminées les étapes manuelles de la migration de l'application Business Integration, exportez l'application en tant que fichier EAR et installez-la sur un serveur WebSphere Process Server en configurant les ressources appropriées.
Effectuez les étapes de migration manuelles requises pour migrer un code client
ou pour générer un nouveau code client à l'aide de WebSphere
Integration Developer. Assurez-vous que le client peut accéder à l'application et que celle-ci se comporte de la même façon que dans l'environnement d'exécution précédent.
Traitement des échecs de migration des artefacts source
Si la migration des artefacts source depuis WebSphere Studio Application Developer Integration Edition échoue, vous pouvez résoudre ces échecs de plusieurs manières.
Voici quelques exemples de ces échecs :
Si l'Assistant de Migration se termine sans que ce message s'affiche, la liste des messages d'informations, d'avertissement et d'erreur s'affiche. Cela signifie que certaines parties du projet de service n'ont pas pu être migrées automatiquement et que des modifications manuelles doivent être effectuées pour terminer la migration.
Limitations du processus de migration (pour la migration des artefacts source)
Il existe certaines limitations au processus de migration des artefacts source de WebSphere Studio Application Developer Integration Edition.
Les listes suivantes détaillent certaines des limitations applicables au processus de migration des artefacts source :
Limitations générales
- WebSphere Studio Application Developer Integration Edition n'était pas efficace pour imposer la cohérence entre les WSDL et les autres artefacts des projets. WebSphere Integration Developer est beaucoup plus strict et effectuera un rapport des incohérences non relevées par WebSphere Studio Application Developer
Integration Edition (également présentes dans l'exécution de réglage de WebSphere Business Integration Server Foundation).
- Bien que WebSphere Studio Application Developer Integration Edition ait autorisé plusieurs définitions identiques de liaison et de service de service Web (nom et espace de nom), ce n'est pas le cas de WebSphere Integration Developer. Vous devez résoudre ces doubles manuellement avant la migration (dans WebSphere Studio Application Developer Integration Edition) ou après la migration (dans WebSphere Integration Developer). Par exemple, dans WebSphere Studio Application Developer Integration Edition, toutes les définitions de service générées dans les fichiers WSDL avec des noms différents (finissant par _EJB, _JMS, etc.) apparaissent sous la forme :
<service name="OrderProcessIntfcService">
Pour corriger le double, il suffit d'ajouter le type de liaison au nom d'attribut. Pour le fichier *_EJB.wsdl, le nom doit être modifié par
<service name="OrderProcessIntfcServiceEJB">
Pour le fichier *_JMS.wsdl, il doit être modifié par
<service name="OrderProcessIntfcServiceJMS">
Cependant, une fois le nom modifié, l'exportation générée dans WebSphere Integration Developer pour utiliser ce service devra également être modifiée pour utiliser le nouveau nom.
- L'Assistant de Migration ne peut pas gérer l'intégralité des espaces de travail de WebSphere Studio Application Developer Integration Edition. Il est conçu pour migrer un projet de service WebSphere Studio Application Developer Integration Edition à la fois.
- L'Assistant de Migration ne migre pas les application binaires, il migre uniquement les artefacts source trouvés dans un projet de service WebSphere Studio Application Developer Integration Edition.
- Les beans de règles métier sont obsolètes dans
WebSphere Process
Server 6.x mais il existe une option au cours de l'installation de
WebSphere Process
Server permettant d'installer la prise en charge des ces beans de règles métier obsolètes de sorte
qu'ils s'exécuteront "tels quels" sur un serveur
WebSphere Process
Server 6.x. En revanche, il n'existe pas de prise en charge d'outil spécifique pour les
anciens beans de règles métier, et si vous souhaitez que les artefacts des anciens beans de règles
métier soient compilés dans les outils, vous devez consulter la documentation de
WebSphere
Integration Developer afin d'installer ces composants obsolètes au-dessus du serveur de test
WebSphere Process
Server 6.x intégré, puis ajouter manuellement les fichiers jar obsolètes au chemin
d'accès de classe du projet en tant que fichiers jar externes. Vous devez utiliser les
nouveaux outils de règles métier disponibles dans
WebSphere
Integration Developer pour recréer leurs règles métier selon les spécifications de 6.x.
- La prise en charge de la messagerie étendue est obsolète dans
WebSphere Process
Server 6.x mais il existe une option au cours de l'installation de
WebSphere Process
Server permettant d'installer la prise en charge des fonctions obsolètes de messagerie étendue de
sorte que les applications existantes puissent s'exécuter "telles quelles" sur un serveur
WebSphere Process
Server 6.x. En revanche, il n'existe pas de prise en charge d'outil spécifique pour les
anciennes fonctions de messagerie étendue. Si vous souhaitez que les artefacts de l'ancienne
messagerie étendue soient compilés dans les outils, vous devez consulter la documentation de
WebSphere
Integration Developer afin d'ajouter ces composants obsolètes au serveur de test intégré à
WebSphere Process
Server 6.x, puis ajouter manuellement les fichiers jar obsolètes au chemin
d'accès de classe du projet en tant que "fichiers jar externes".
- La liaison de données JMS standard fournie ne permet pas d'accéder aux propriétés d'en-tête JMS personnalisées. Vous devez pour cela écrire une liaison de données personnalisée pour les services SCA.
Limitations du modèle de programmation SCA
- La spécification SDO version 1 ne fournit pas l'accès au tableau d'octets C ou COBOL. Cela affectera les personnes qui utilisent les multi-segments IMS.
- La spécification SDO version 1 pour la sérialisation ne prend pas en charge la construction REDEFINE de langage COBOL ou la construction d'union de langage C.
- Lorsque vous concevez de nouveau vos artefacts source selon le modèle de programmation SCA, notez que le style WSDL encapsulé Document/Literal (qui est le style par défaut pour les nouveaux artefacts créés à l'aide des outils de WebSphere Integration Developer) ne prend pas en charge la surcharge de méthode. Les autres styles WSDL étant encore pris en charge, il est recommandé d'utiliser dans ce cas un style/codage WSDL autre que le style encapsulé Document/Literal.
- La prise en charge en mode natif des tableaux est limitée. Pour appeler un service externe qui expose les types soapenc:Array à une interface WSDL, vous devrez créer une
interface WSDL qui définit un élément dont l'attribut "maxOccurs" est supérieur à un (il s'agit de l'approche recommandée pour concevoir un type de tableau).
Limitations techniques d'un processus de migration BPEL
- Réponses multiples par opération BPEL. Dans WebSphere Business Integration Server Foundation, un processus métier pouvait avoir une activité recevoir et des activités répondre multiple pour la même opération. Si vous possédez un processus métier avec plusieurs réponses
pour la même opération, assurez-vous que, si l'une d'elles a des paramètres client, toutes les réponses
pour cette opération ont les mêmes paramètres client, étant donné que dans la version 6.x, un
seul ensemble de paramètres client par réponse d'opération est pris en charge.
- Limitations pour la migration des fragments Java BPEL Le modèle de programmation a changé de manière significative entre WebSphere Studio Application Developer Integration Edition et WebSphere Integration Developer et les API WebSphere Studio Application Developer Integration Edition prises en charge ne peuvent pas toutes être migrées vers les API correspondantes de WebSphere Integration Developer. Toute logique Java peut être trouvée dans les fragments Java BPEL ; l'outil de migration automatique peut donc ne pas être capable de convertir chaque fragment Java vers le nouveau modèle de programmation. La plupart des appels d'API de fragments standard seront
automatiquement migrés du modèle de programmation de fragments
Java
5.1 au modèle de programmation de fragments
Java
6.x. Les appels API WSIF sont migrés vers les appels API DataObject lorsque cela est possible. Toutes les classes Java personnalisées qui acceptent les objets WSIFMessage auront besoin d'une migration manuelle afin qu'elles acceptent et retournent les objets commonj.sdo.DataObject :
- API des métadonnées WSIFMessage - Certaines métadonnées WSIFMessage et API WSIF auront peut-être besoin d'une migration manuelle.
- API EndpointReference/EndpointReferenceType.
Ces classes ne sont pas migrées automatiquement. La migration manuelle est nécessaire car les méthodes getter/setter des liens partenaires traitent les objets commonj.sdo.DataObject à la place des objets com.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType depuis la version 5.1.
- Types complexes avec noms en double Si une application déclare des types complexes (dans WSDLs ou XSDs) avec des espaces de nom et des noms locaux identiques, ou des espaces de nom différents mais des noms locaux identiques, les fragments Java qui utilisent ces types peuvent ne pas être migrés correctement. Vérifiez la validité des fragments quand l'Assistant de migration a terminé.
- Types complexes avec noms locaux identiques aux classes Java dans le package java.lang. Si une application déclare des types complexes (dans WSDLs ou XSDs) avec des noms locaux identiques aux classes dans le package java.lang package de J2SE 1.4.2, les fragments Java qui utilisent la classe java.lang correspondante peuvent ne pas être migrés correctement. Vérifiez la validité des fragments quand l'Assistant de migration a terminé.
- Variables BPEL en lecture seule et en lecture-écriture. Dans les fragments
Java
5.1, il était impossible de définir une variable BPEL en "lecture seule" (les modifications apportées à l'objet n'étaient pas répercutées sur la valeur de la variable). Il était également possible de définir une variable BPEL en "lecture-écriture" (les modifications apportées à l'objet étaient répercutées sur la valeur de la variable). L'exemple ci-dessous présente quatre moyens de rendre un fragment de code Java accessible en lecture seule dans un fragment Java BPEL 5.1 :
getMyInputVariable()
getMyInputVariable(false)
getVariableAsWSIFMessage("MyInputVariable")
getVariableAsWSIFMessage("MyInputVariable", false)
L'exemple ci-dessous présente deux moyens de rendre une variable BPEL accessible en lecture-écriture dans un fragment Java BPEL 5.1 :
getMyInputVariable(true)
getVariableAsWSIFMessage("MyInputVariable", true)
Dans la version 6.x, l'accès
en lecture seule et en lecture-écriture aux variables BPEL est géré sur une base "par fragment", ce
qui signifie que vous pouvez ajouter un commentaire spécial au fragment
Java BPEL
pour indiquer si les mises à jour de cette variable doivent être supprimées ou conservées après
l'exécution du fragment de code. Les paramètres d'accès par défaut pour les types de fragments
Java BPEL
6.x sont les suivants :
BPEL Java Snippet Activity
Default Access: read-write
Override Default Access with comment containing:
@bpe.readOnlyVariables names="variableA,variableB"
BPEL Java Snippet Expression (Used in a Timeout, Condition, etc)
Default Access: read-only
Override Default Access with comment containing:
@bpe.readWriteVariables names="variableA,variableB"
Lors de la migration, ces
commentaires sont créés automatiquement lors de l'accès à une variable d'une manière autre que
l'accès par défaut de la version 6.x. En cas de conflit (accès à une variable BPEL en lecture seule et en lecture-écriture dans un même fragment), un avertissement s'affiche et l'accès est défini sur lecture-écriture. Si vous recevez cet avertissement, assurez-vous que cette variable soit accessible en lecture-écriture. Sinon, corrigez ce point manuellement à l'aide de l'éditeur BPEL de WebSphere Integration Developer.
- Propriétés primitives à valeurs multiples dans des
types complexes. Dans la version 5.1, les propriétés à
valeurs multiples sont représentées par des tableaux de type de
propriété. Ainsi, des appels pour obtenir et définir la propriété utilisent des tableaux. Dans la
version 6.x, java.util.List est utilisé pour cette représentation. La migration automatique gère tous les cas où la propriété à valeurs multiples est un certain type d'objet Java, mais dans le cas où le type de la propriété est une primitive Java (int, long, short, byte, char, float, double et boolean), les appels pour obtenir et définir le tableau entier ne sont pas convertis. Dans un tel cas, la migration manuelle peut nécessiter l'ajout d'une boucle pour lier/délier les primitives dans/à partir de leur classe de conteneur Java correspondante (Integer, Long, Short, Byte, Character, Float, Double et Boolean) pour l'utilisation dans le reste du fragment.
- Instanciation de classes générées représentant des types complexes. Dans la version 5.1, les classes générées de types complexes définies dans une application pouvaient être facilement instanciées dans un fragment Java à l'aide du constructeur aucun argument par défaut. En voici un exemple :
MyProperty myProp = new MyProperty();
InputMessageMessage myMsg = new InputMessageMessage();
myMsg.setMyProperty(myProp);
Dans la version 6.x, une classe de fabrique spéciale
doit être utilisée pour instancier ces types, ou une instance du type contenant peut être utilisée
pour créer le sous-type. Si une variable de processus BPEL InputVariable a été définie comme ayant le type InputMessage, alors
la version 6.x du fragment précédent sera :
com.ibm.websphere.bo.BOFactory boFactory=
(com.ibm.websphere.bo.BOFactory)
com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService(
"com/ibm/websphere/bo/BOFactory");
commonj.sdo.DataObject myMsg =
boFactory.createByType(getVariableType("InputVariable"));
commonj.sdo.DataObject myProp =
myMsg.createDataObject("MyProperty");
Le convertisseur de fragments essaie d'effectuer ce changement, mais si l'ordre dans lequel s'effectuent les instanciations originales ne suit pas le schéma parent-puis-enfant, une migration manuelle sera nécessaire (c'est-à-dire que le convertisseur n'essaie pas de réorganiser intelligemment les déclarations d'instanciation dans le fragment).
- Dans WebSphere Business Integration Server Foundation 5.1, les références dynamiques étaient représentées comme des parties de messages WSDL du type EndpointReferenceType ou de l'élément EndpointReference à partir de l'espace de nom :
http://wsaddressing.bpel.srm.websphere.ibm.com
Ces références seront migrées de l'espace de nom du processus métier standard vers le type d'élément référence de service standard :
http://schemas.xmlsoap.org/ws/2004/03/business-process/
http://schemas.xmlsoap.org/ws/2004/08/addressing
Reportez-vous à la documentation sur l'éditeur BPEL pour obtenir des instructions sur l'importation manuelle de ces définitions de schéma dans votre projet afin de résoudre correctement toutes les références.
- BPEL variable message type : Un type de message WSDL doit être indiqué pour toutes les variables BPEL utilisées dans des fragments Java. Les fragments Java accédant à des variables BPEL sans attribut "messageType" ne peuvent pas faire l'objet d'une
migration.
Remarques
U.S. Government Users Restricted Rights - Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Le
présent document peut contenir des informations ou des références concernant
certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à
votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier
lui-même les installations et applications réalisées avec des
produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits mentionnés dans la présente documentation.
La remise de cette documentation ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez recevoir des informations concernant l'acquisition de licences, veuillez en faire la demande par écrit à
l'adresse suivante :
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
Les informations sur les licences concernant les produits
utilisant un jeu de caractères double octet peuvent être obtenues par
écrit à l'adresse suivante :
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays dans lequel il serait contraire aux lois locales. LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE OU CONDITION RELATIVE A CES INFORMATIONS EN CAS DE CONTREFAÇON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE. Certaines juridictions
n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Ce document est mis à jour périodiquement. Chaque nouvelle
édition inclut les mises à jour. IBM peut, à tout moment et sans préavis, modifier les produits et logiciels décrits dans ce document.
Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils
contiennent.
Les éléments figurant sur ces sites
Web ne font pas partie des éléments du présent produit IBM et
l'utilisation de ces sites relève de votre seule responsabilité.
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera
appropriée et sans aucune obligation de sa part,
tout ou partie des informations qui lui seront fournies.
Les licenciés
souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :
Intellectual Property Dept. for WebSphere Integration Developer
IBM Canada Ltd.
8200 Warden Avenue
Markham, Ontario L6G 1C7
Canada
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux dispositions de l'ICA, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé.
Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé.
Certaines mesures évaluées sur des systèmes en cours de développement ne
sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations.
Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des
fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits
non IBM doit être adressée aux fournisseurs de ces produits.
Toute instruction relative aux intentions d'IBM pour ses opérations à venir est susceptible d'être modifiée ou annulée sans préavis, et doit être considérée uniquement
comme un objectif.
Le présent document peut contenir des exemples de données et de
rapports utilisés couramment dans l'environnement professionnel. Ces exemples peuvent mentionner des noms fictifs de personnes, de sociétés, de marques ou de produits à des fins illustratives ou explicatives uniquement. Toute ressemblance avec des noms de personnes, de sociétés ou des données réelles serait purement fortuite.
LICENCE DE COPYRIGHT :
Le présent logiciel peut contenir des exemples de programme d'application en langage source destinés à illustrer les techniques de programmation sur différentes plateformes d'exploitation. Vous avez le droit de copier, de
modifier et de distribuer ces exemples de programmes sous quelque forme que ce
soit et sans paiement d'aucune redevance à IBM, à des fins de développement,
d'utilisation, de vente ou de distribution de programmes d'application
conformes aux interfaces de programmation des plateformes pour lesquels ils ont
été écrits ou aux interfaces de programmation IBM. Ces exemples de programmes n'ont pas été rigoureusement testés dans toutes les conditions. Par conséquent, IBM ne peut garantir expressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnement de ces programmes. Vous avez le droit de copier, de modifier et de distribuer ces
exemples de programmes sous quelque forme que ce soit et sans
paiement d'aucune redevance à IBM, à des fins de développement,
d'utilisation, de vente ou de distribution de programmes
d'application conformes aux interfaces de programmation IBM.
Toute copie totale ou partielle de ces programmes exemples et des oeuvres qui en sont dérivées doit comprendre une notice de copyright, libellée comme suit :
(C) (nom de votre société) (année). Des segments de code sont dérivés des Programmes exemples
d'IBM Corp. (C) Copyright IBM Corp. 2000, 2007. All rights reserved.
Si vous visualisez ces informations en ligne,
il se peut que les photographies et illustrations en couleur n'apparaissent pas à l'écran.
Documentation sur l'interface de programmation
La documentation sur l'interface de programmation aide les utilisateurs à créer des applications en utilisant le produit.
Les interfaces de programmation génériques permettent d'écrire des applications, qui bénéficient des services proposés par les outils du produit.
Toutefois, lesdites informations peuvent également contenir des données de diagnostic, de modification et d'optimisation
qui permettent de déboguer votre application.
Avertissement : N'utilisez pas les informations de diagnostic, de modification et d'optimisation en guise d'interface de programmation car elles peuvent être modifiées sans préavis.
Marques et noms de services
IBM, IBM Logo, WebSphere, Rational, DB2, Universal Database DB2, Tivoli, Lotus, Passport
Advantage, developerWorks, Redbooks, CICS, z/OS
et IMS sont
des marques déposées d'International Business Machines Corporation
aux Etats-Unis et/ou dans certains autres pays.
UNIX est une marque
déposée de The Open Group aux Etats-Unis et/ou dans certains autres pays.
Java
ainsi que tous les logos et toutes les marques incluant Java sont des marques déposées
de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
Microsoft et Windows sont
des marques déposées de Microsoft Corporation
aux Etats-Unis et/ou dans certains autres pays.
Linux est une marque de Linus Torvalds
aux Etats-Unis et/ou dans certains autres pays.
Adobe est une marque
déposée de Adobe Systems Incorporated aux Etats-Unis
et/ou dans certains autres pays.
Les autres noms de sociétés, de produits et de services
peuvent appartenir à des tiers.
Conditions d'utilisation
Les droits d'utilisation relatifs à ces publications sont soumis aux dispositions suivantes.
Usage personnel : Vous pouvez reproduire ces informations pour votre usage personnel, non commercial, sous réserve que toutes les mentions de propriété soient conservées.
Vous ne pouvez distribuer ou publier tout ou partie de ces publications ou en faire des oeuvres dérivées sans le consentement exprès d'IBM.
Usage commercial : Vous pouvez reproduire, distribuer et publier ces publications uniquement au sein de votre entreprise, sous réserve que toutes les mentions de propriété soient conservées. Vous ne pouvez reproduire, distribuer, afficher ou publier tout ou partie de ces publications en dehors de votre entreprise, ou en faire des oeuvres dérivées, sans le consentement exprès d'IBM.
Excepté les droits d'utilisation expressément accordés dans ce document, aucun autre droit, licence ou autorisation, implicite ou explicite, n'est accordé pour ces publications ou autres informations, données, logiciels ou droits de propriété intellectuelle contenus dans ces publications.
IBM se réserve le droit de retirer les autorisations accordées ici si, à sa discrétion, l'utilisation des publications s'avère préjudiciable à ses intérêts ou que, selon son appréciation, les instructions susmentionnées n'ont pas été respectées.
Vous ne pouvez télécharger, exporter ou réexporter ces informations qu'en total accord avec toutes les lois et règlements applicables dans votre pays, y compris les lois et règlements américains relatifs à l'exportation.
IBM N'OCTROIE AUCUNE GARANTIE SUR LE CONTENU DE CES PUBLICATIONS.
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
© Copyright IBM Corporation
2005, 2007. All rights reserved.