IBM WebSphere Integration Developer
Version 6.2
Guide de migration
Version 6.2
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 2009. Tous droits réservés.
Copyright International Business Machines Corporation 2005, 2009. All Rights Reserved.
Chapitre 1. Migration vers WebSphere Integration Developer
WebSphere Integration
Developer version 6.2 fournit les outils nécessaire pour migrer votre
environnement existant.
Remarque : Une fois WebSphere Integration
Developer 6.2 mis à niveau, vous ne pouvez pas réutiliser de projets dans WebSphere Integration Developer 6.1.x.
Aucune prise en charge n'est possible si vous utilisez la version 6.2 pour vérifier votre code
dans un référentiel ou exporter des projets, puis les partager avec un utilisateur WebSphere Integration
Developer 6.1.x.
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 de versions antérieures de WebSphere Integration Developer vers WebSphere Integration Developer
6.2 est prise en charge. Il s'agit d'une migration d'une version à une autre.
Pourquoi et quand exécuter cette tâche
La migration vers WebSphere Integration
Developer 6.2 conserve 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
Lors de la migration d'une version antérieure de WebSphere Integration Developer vers une version
6.2, une grande partie de la migration s'effectue 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 contrôle WebSphere Integration
Developer ne peuvent pas être créés mais ils peuvent être utilisés dans WebSphere Integration Developer
6.2 s'ils existent déjà.
- Editeur de définitions d'événement
- Cet éditeur est obsolète dans WebSphere Integration
Developer 6.1.
- Synchronisation
- La synchronisation entre WebSphere Business
Modeler et WebSphere Integration
Developer ne fonctionne que si le modèle a été créé dans WebSphere Business Modeler version 6.1.2 ou ultérieure
et est utilisé dans WebSphere Integration
Developer version 6.1.2 ou ultérieure. La synchronisation avec Rational Asset Manager 7.1 ne fonctionne que si les projets ont été migrés vers
WebSphere Integration Developer 6.2.
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.2 et WebSphere Integration
Developer 6.2 sont compatibles avec les versions précédentes de la manière suivante :
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.2.x ou 6.1 sur WebSphere Process
Server 6.2 est pris en charge.
- Les applications créées et générées à l'aide de WebSphere Integration Developer 6.0.2.x ou
6.1 peuvent être publiées sur les serveurs WebSphere Process
Server 6.2.
- Les applications créées et générées dans WebSphere Integration Developer
6.0.2.x ou 6.1, puis exportées à partir de celui-ci peuvent être installées sur les serveurs WebSphere Process Server 6.2.
- L'exécution d'artefacts WebSphere Process
Server 6.2 sur WebSphere Process
Server 6.0.2.x ou 6.1 n'est pas prise en charge.
- Les applications créées à l'aide WebSphere Integration
Developer 6.2 ne peuvent pas être publiées ou installées sur les serveurs WebSphere Process Server 6.0.2.x ou
6.1 (ou toute version antérieure). Un tel contenu ne sera pas exécuté correctement
sur WebSphere Process Server
6.0.2.x ou 6.1, et les modifications apportées à la génération du code vont entraîner une exécution incorrecte des applications sur WebSphere Process Server 6.0.2.x ou
6.1.
- Les applications créées à l'aide de WebSphere Integration
Developer 6.0.2.x ou 6.1 et générées dans WebSphere Integration Developer 6.2 ne peuvent pas être publiées ou installées sur les serveurs WebSphere Process
Server 6.0.2.x ou 6.1. Les modifications apportées à la génération du code vont entraîner une exécution incorrecte des applications sur WebSphere Process Server 6.0.2.x ou
6.1.
- Les applications créées à l'aide de serviceDeploy depuis
un serveur WebSphere Process Server
6.2 ne peuvent pas être installées sur un serveur WebSphere Process Server 6.0.2.x ou
6.1. Les modifications apportées à la génération du code vont entraîner une exécution incorrecte des applications sur WebSphere Process
Server 6.0.2.x ou 6.1.
Chapitre 3. Migration de WebSphere
InterChange Server vers
WebSphere
Process Server
WebSphere Integration
Developer fournit les outils nécessaires pour migrer à partir de WebSphere InterChange Server.
Pourquoi et quand exécuter cette tâche
La migration de WebSphere InterChange
Server vers WebSphere Process
Server est prise en charge grâce aux fonctions suivantes dans 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 :
- Via le menu Fichier -> Importation -> Intégration métier de WebSphere Integration Developer.
- A partir de la page Bienvenue de WebSphere Integration
Developer.
- Prise en charge native dans l'exécution de plusieurs interfaces de programme d'application WebSphere InterChange Server.
- Prise en charge de la technologie d'adaptateur WebSphere Business
Integration actuelle de sorte que les adaptateurs existants sont compatibles avec WebSphere Process
Server.
- Options permettant de migrer les configurations de connecteur d'adaptateur WebSphere Business
Integration vers des liaisons natives ou des adaptateurs WebSphere Process Server équivalents.
- Migration de connecteurs vers des modules de médiation.
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
Remarque : WebSphere Business
Integration Server Express (WBISX) inclut les mêmes types d'artefacts
que WebSphere InterChange
Server. Seules deux fonctions, à savoir les règles métier et l'analyse métier, ne
sont pas prises en charge par la migration.
Chemins de migration pris en charge
Les outils de migration WebSphere Process
Server prennent en charge la migration à partir des versions 4.3 et ultérieures de WebSphere InterChange Server ou de versions 4.4 et ultérieures de WebSphere Business
Integration Server Express.
Avant d'effectuer la migration, notez les exigences suivantes :
Remarque :
- Toute édition de WebSphere InterChange
Server antérieure à la version 4.3 doit d'abord migrer vers
la version 4.3 avant de migrer vers WebSphere Process Server.
- Toute édition de WebSphere Business
Integration Server Express antérieure à la version 4.4 doit d'abord
migrer vers la version 4.4 avant de migrer vers WebSphere Process Server.
Avant de migrer de WebSphere InterChange
Server vers WebSphere Process
Server à l'aide de WebSphere Integration
Developer, vous devez d'abord vérifier que vous avez correctement préparé votre environnement.
Pourquoi et quand exécuter cette tâche
Ces outils de migration peuvent être appelés à partir :
- Le menu Fichier -> Importation -> Intégration métier de WebSphere Integration Developer.
- La page Bienvenue 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 qui peut être migrée vers WebSphere Process
Server. Voir la rubrique "Chemins de migration pris en charge pour
WebSphere
InterChange Server".
- Exportez vos artefacts source de WebSphere InterChange Server dans un fichier de référentiel .jar à l'aide de la commande repos_copy de WebSphere InterChange Server comme décrit dans 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
doivent également être intégrés à 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).
Migration de WebSphere Business
Integration Server Express (WBISX)
Vous pouvez utiliser l'assistant de migration WebSphere Integration
Developer pour migrer les artefacts WebSphere InterChange Server à partir d'un environnement WebSphere Business
Integration Server Express.
Pourquoi et quand exécuter cette tâche
Pour obtenir plus d'informations sur la migration à partir d'un environnement WebSphere Business Integration Server Express,
consultez la rubrique Migration de WebSphere InterChange
Server ou WebSphere Business
Integration Server Express dans le centre de documentation WebSphere Process Server.
Si vous avez installé localement le centre de documentation
WebSphere Process
Server ou WebSphere Enterprise Service Bus,
recherchez ces informations dans la rubrique Migration de WebSphere InterChange
Server ou WebSphere Business
Integration Server Express.
Pour obtenir des informations sur comment télécharger la documentation serveur, consultez la rubrique Affichage ou téléchargement de la documentation WebSphere Process Server.
Scénarios de migration
WebSphere InterChange
Server
Plusieurs scénarios de migration WebSphere InterChange
Server sont pris en charge par WebSphere Integration Developer.
Les scénarios ci-après expliquent le processus de migration à partir de WebSphere InterChange Server :
Migration d'un adaptateur EJB WebSphere Business
Integration vers un bean session sans état WebSphere Process
Server
L'assistant de migration offre une option
pour migrer vers une liaison JMS connectée à l'adaptateur WebSphere Business Integration
existant ou vers un nouveau bean session sans état. La migration va générer des artefacts squelette.
Migration d'un adaptateur HTTP WebSphere Business
Integration vers une liaison native WebSphere Process
Server
Si le connecteur HTTP a été configuré
à l'aide d'un programme d'écoute de protocole, vous allez devoir modifier votre application
client avant de connecter le connecteur migré. Par exemple, si le connecteur est
appelé HTTPConnector, écoute le port
8080 et utilise l'URL /wbia/samples/webservices, lorsque vous
le migrez vers WebSphere Process
Server, le port devient 9080 (le port WC_defaulthost)
et l'URL, /HTTPConnectorWeb/wbia/samples/http.
Dans WebSphere InterChange
Server, vous pouvez y accéder à l'aide de l'adresse http://localhost:8080/wbia/http/samples alors que dans WebSphere Process Server,
cette adresse devient http://localhost:9080/HTTPConnectorWeb/wbia/http/samples .
L'assistant de
migration offre une option pour migrer vers une liaison JMS
connectée à l'adaptateur WebSphere Business
Integration existant ou vers une nouvelle liaison HTTP. L'assistant va vous permettre de
sélectionner un gestionnaire de données ICS par défaut, de créer un squelette de gestionnaire de données WPS ou d'utiliser un gestionnaire de données personnalisé. Le gestionnaire de données par défaut dans l'assistant de migration est le gestionnaire de données XML.
Ce scénario de
migration prend également en charge le routage de noeud final dynamique.
Migration d'un adaptateur JMS WebSphere Business
Integration vers un JMS WebSphere Process
Server ou une liaison native JMS générique
L'assistant de migration donne la possibilité
de migrer vers une liaison JMS connectée à
l'adaptateur WebSphere Business
Integration existant, vers un nouveau JMS ou vers une liaison JMS générique. L'assistant va vous permettre
de sélectionner un gestionnaire de données ICS par défaut, de créer un squelette de gestionnaire de données WPS ou d'utiliser un gestionnaire de données personnalisé. Le CwDataHandler permet de choisir le gestionnaire de données par défaut.
Si vous sélectionnez la liaison
JMS, vous allez devoir créer le JMS générique, la fabrique de connexions de file d'attente, les files d'attente JMS ainsi que les ports d'écoute JMS, et vous allez devoir générer
un nouveau fichier de liaisons incluant les entrées pour les files d'attente. Pour obtenir plus d'informations sur l'utilisation des liaisons JMS, consultez le centre de documentation WebSphere Process
Server à l'adresse suivantes : http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.soacore.620.doc/doc/cadm_jmsbinding.html. Si vous avez installé localement la documentation WebSphere Process Server, vous pouvez rechercher ces informations dans la rubrique Liaisons JMS. Pour obtenir des informations sur le téléchargement de la documentation serveur,
consultez la rubrique Affichage ou téléchargement de la documentation WebSphere Process Server.
Si vous avez sélectionné la liaison JMS générique, vous allez devoir créer la liaison JMS générique, la fabrique de connexions de file d'attente ainsi que les files d'attente JMS, et vous allez devoir générer un nouveau fichier de liaisons incluant les entrées pour les nouvelles files d'attente.
Les ports d'écoute sont créés lors du déploiement. Pour obtenir plus d'informations sur l'utilisation des liaisons JMS génériques, consultez la rubrique éponyme du centre de documentation WebSphere Process Server, à l'adresse suivante : http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.soacore.620.doc/doc/cadm_scagenbinding.html. Si vous installé localement la documentation WebSphere Process Server,
vous pouvez rechercher ces informations à l'adresse suivante : ../../com.ibm.websphere.soacore.620.doc/doc/cadm_scagenbinding.html. Pour obtenir des informations sur comment télécharger la documentation serveur,
consultez la rubrique Affichage ou téléchargement de la documentation WebSphere Process Server.
Le JMS et le JMS générique
prennent en charge le routage de noeud final dynamique. C'est la raison pour laquelle la file d'attente d'envoi
dans l'importation n'est pas utilisée et la migration a laissé cette valeur indéfinie. Vous allez devoir indiquer une valeur avant de pouvoir déployer et démarrer le module.
Migration d'un adaptateur MQ WebSphere Business
Integration vers un MQ WebSphere Process
Server ou une liaison native JMS MQ
L'assistant de migration donne la possibilité de
migrer vers une liaison JMS connectée à l'adaptateur WebSphere Business Integration
existant, à un nouveau MQ ou à une nouvelle liaison JMS MQ.
Le MQ et le JMS MQ prennent en charge le
routage de noeud final dynamique. C'est la raison pour laquelle la file d'attente de requêtes
n'est pas utilisée et la migration a laissé cette valeur indéfinie. Vous allez devoir
indiquer une file d'attente valide (mais il est recommandé qu'elle soit inutilisée en cas de problème) avant de pouvoir déployer et démarrer le module. Indiquez également une file d'attente de
réponses valide pour l'exportation.
L'assistant va vous permettre de sélectionner
un gestionnaire de données ICS par défaut, de créer un squelette de gestionnaire de données WPS ou d'utiliser un gestionnaire de données personnalisé. Le
CwDataHandler permet de choisir le gestionnaire de données par défaut.
Si vous sélectionnez le JMS MQ, vous allez devoir configurer également la file d'attente de destination et la fabrique de connexions. Ouvrez la mappe sortante pour le MFC et éditez l'URL dans l'étape de personnalisation
#3 afin d'inclure le nom de la fabrique de connexions. Un exemple d'URL ressemble à cela :
jms:/queue?destination=MQOUTPUT&connectionFactory=&targetService=Output
Entrez la valeur entre connectionFactory= et le &.
La chaîne finale ressemble à cela :
jms:/queue?destination=MQOUTPUT&connectionFactory=MYCONNECTIONFACTORY&targetService=Output
Migration d'un adaptateur de services Web WebSphere Business
Integration vers une liaison HTTP native WebSphere Process Server
Si le connecteur WS a été configuré à l'aide d'un programme d'écoute de protocole,
vous allez devoir modifier votre application
client avant de connecter le connecteur migré. Par exemple, si le connecteur est
appelé WSConnector, écoute le port
8080 et utilise l'URL /wbia/samples/webservices, lorsque vous
le migrez vers WebSphere Process
Server, le port devient 9080 (le port WC_defaulthost)
et l'URL, /WSConnectorWeb/wbia/samples/webservices.
Pour ce type de migration, il existe deux scénarios possibles :
- Si l'adaptateur de services Web utiliser le protocole de transfert HTTP,
l'assistant de migration donne la possibilité de migrer vers
une liaison JMS connectée à l'adaptateur WebSphere Business Integration existant ou vers une nouvelle liaison HTTP.
- S'il utilise le protocole de transfert JMS,
la seule option de migration est la liaison JMS connectée
à l'adaptateur WebSphere Business
Integration existant.
Notez que dans ce type de migration, l'assistant ne vous permet pas
de sélectionner un gestionnaire de données personnalisé.
Ce scénario de migration
prend également en charge le routage de noeud final dynamique.
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é.
- 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 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
Si possible, il est recommandé d'éviter de développer des bibliothèques
d'utilitaires de codes communs et de les utiliser pour des artefacts d'intégration dans l'environnement WebSphere InterChange
Server. 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. Par conséquent, il est recommandé d'éviter de conserver les transactions actives de bases de données dans les 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
Pour développer des objets métier, vous devriez n'utiliser que les
outils fournis pour configurer les artefacts, des types de données et
des longueurs d'attributs de données explicites ainsi que les interfaces de programme d'application documentées.
Les objets métier de WebSphere Process
Server sont basés sur les objets SDO (Service Data Objects), qui disposent d'attributs de données fortement typés. Les attributs de données des objets métier de WebSphere InterChange Server et des adaptateurs 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 d'utiliser la longueur maximale d'attribut de chaîne, soit 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 les mappes et/ou relations.
L'architecture
WebSphere Process Server
vers 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 définitions d'objet métier et pour utiliser uniquement les interfaces de programme d'application publiées pour les
objets métier des artefacts d'intégration.
Remarques : modèles de collaboration
La plupart des instructions décrites ci-dessus 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 interfaces de programme d'application documentées dans les modèles de collaboration.
Evitez d'utiliser des variables statiques. Préférez leur 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. Les caractères qui ne
respectent pas les conventions de dénomination ne sont pas valides dans les noms des
propriétés BPEL vers 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 exempne, au lieu de
"this.inputBusObj", utilisez simplement "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;".
Vérifiez 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 d'utiliser des variables statiques et préférez leur des variables non statiques. Evitez d'utiliser des 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
vers 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 puissent être migrées pour être utilisées dans WebSphere Process
Server, 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.
N'utilisez que les outils fournis pour configurer les composants connexes et les interfaces de programme d'application pour les relations dans les artefacts d'intégration.
N'utilisez que l'éditeur 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 sous aucun prétexte directement le schéma de table de relations
à 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.
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
Si une application migrée entraîne la réalisation de plusieurs événements simultanément 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. Vous pouvez empêcher les collisions de base de données en
planifiant les événements afin qu'ils se produisent à des moments différents.
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 en fonction des
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.
Pour obtenir des informations sur comment télécharger la documentation serveur,
consultez la rubrique Affichage ou téléchargement de la documentation WebSphere Process Server.
Migration d'artefacts WebSphere InterChange
Server à laide de l'assistant de migration
Vous pouvez utiliser l'Assistant de migration de WebSphere Integration Developer pour migrer vos artefacts WebSphere InterChange Server.
Pourquoi et quand exécuter cette tâche
L'assistant effectue la migration d'après les considérations suivantes :
- Les adaptateurs sont migrés vers des liaisons natives s'ils sont pris en charge en tant
que liaisons natives.
- Si un adaptateur est détecté en tant qu'ayant un connecteur JCA équivalent,
vous avez la possibilité de l'importer. En important le connecteur,
vous définissez l'environnement afin qu'il soit migré vers l'adaptateur JCA à l'aide
de l'assistant de migration.
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 -> Importation -> Intégration métier -> Référentiel WebSphere InterChange Server et cliquez sur
Suivant. Remarque : Vous pouvez aussi ouvrir
l'assistant de migration depuis la page Bienvenue en cliquant sur l'icône Pour ceux qui sont déjà utilisateurs pour ouvrir la page correspondante (vous pouvez toujours revenir à la page Bienvenue en cliquant sur AideBienvenue).
Cliquez sur Migration du côté gauche de la page
Pour ceux qui sont déjà utilisateurs afin d'ouvrir la page Migration et sélectionnez l'option Migrer
le référentiel WebSphere ICS.
- L'Assistant de migration apparaît. Entrez le chemin d'accès au référentiel WebSphere InterChange Server ou cliquez sur Parcourir les fichiers JAR pour sélectionner le fichier JAR
à utiliser lors du processus de migration.
- Entrez le nom d'une nouvelle bibliothèque ou d'une bibliothèque WebSphere Integration Developer existante.
- Vous pouvez aussi ajouter un modèle d'éditeur d'assemblage WebSphere InterChange
Server à charger et à utiliser lors de la conversion de XML à Java. Si les interfaces de programme d'application
personnalisées (Ma Bibliothèque) sont créées afin d'être utilisées dans l'éditeur d'activités, l'outil de migration doit se référer au modèle d'éditeur d'activités personnalisé afin de déterminer comment migrer l'interface de programme d'application personnalisée vers Java.
Vous trouverez ces modèles dans le répertoire racine .wbiActEditorSettings
situé dans le répertoire d'espace de travail WebSphere InterChange
Server. En règle générale, les fichiers modèle ont une extension de fichier .bbt. Vérifiez que vous chargez ces modèles dans la boîte de modèles. Si vous n'ajoutez pas de modèle, le modèle Standard Assembly Editor
v4.3.3 sera utilisé pour la conversion de XML à Java.
- Cliquez sur Suivant pour configurer les paramètres de migration
de chaque connecteur. A partir de cette page, vous pouvez sélectionner la liaison cible ainsi que les gestionnaires de données appropriés pour chaque connecteur en cours de migration.
Sélectionnez le connecteur dans la liste et choisissez une liaison cible ainsi que le fichier JAR de gestionnaire de données personnalisé. Notez que l'assistant de migration
n'autorise pas l'exécution du processus de migration tant que toutes les valeurs de connecteur ne sont pas définies.
- Cliquez sur Suivant. La page Options de conversion
s'ouvre. A partir de cette page, vous pouvez accepter les options recommandées ou les modifier :

Le tableau ci-dessous explique plus en détails
les options de conversion de migration :
Option |
Description |
Les erreurs de syntaxe Java
rencontrées au cours du processus de migration doivent être traitées de la manière suivante : |
- Erreurs (recommandé)
- Tous les problèmes de conversion Java
sont traités comme des erreurs et vous devez consulter le journal des erreurs pour obtenir plus de détails.
- Avertissements
- Tous les problèmes de conversion Java
sont uniquement traités comme des avertissements et l'artefact sera migré
par l'assistant de migration autant que faire se peut.
|
En cas d'erreur, le processus de migration devrait : |
- Poursuivre jusqu'à la fin (recommandé)
- L'assistant de migration continue à traiter les artefacts restants
dans un fichier JAR même si une erreur se produit lors du traitement d'un artefact donné.
- S'interrompre immédiatement
- Le processus de migration 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.
|
Séquencement d'événements pour toutes les méthodes : |
- Désactiver (recommandé)
- Le processus de migration désactive le séquencement d'événement, quelle que soit la méthode WSDL.
- Activer
- Le processus de migration active le séquencement d'événements pour toutes les méthodes WSDL asynchrones.
|
- Cliquez sur Suivant. Une page Récapitulatif de migration
similaire à l'exemple ci-après s'ouvre :
- Une fois que vous en avez vérifié les détails, cliquez sur Terminer afin de commencer
le processus de migration.
Que faire ensuite
Une barre de progression située dans la partie inférieure de la boîte de dialogue Migration indique la
progression de la migration. Lorsque le processus de migration est terminé, la boîte de dialogue
disparaît et la fenêtre Résultats de la migration s'ouvre :
. Cliquez sur Fermer pour terminer le
processus et générer le nouvel espace de travail. Vous pouvez désélectionner l'option Générer
l'espace de travail lors de la fermeture si vous ne voulez pas générer maintenant l'espace de travail.
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 l'exécution de la
migration n'a pas correctement abouti, une liste d'erreurs, d'avertissements et de messages d'information s'affiche dans la fenêtre Résultats de la migration. Vous pouvez utiliser ces messages
pour vérifier la migration de
WebSphere
InterChange Server.
Pourquoi et quand exécuter cette tâche
Remarque : En raison de la complexité de la 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 vérifier qu'elles fonctionnent correctement avant de les mettre en production.
Si vous décidez de ne pas arrêter lors du premier échec, une icône ayant la forme d'une coche verte s'affiche dans la fenêtre Résultats de la migration, mais des croix rouges peuvent également apparaître dans la liste. Par conséquent, vous devez les vérifier dans la liste. Si vous décidez de ne pas arrêter lors du premier échec et que vous recevez un message d'erreur ou un échec, une croix rouge s'affiche dans la fenêtre Résultats de la migration à la place de la coche verte. Vous devez alors vérifier les échecs dans la liste.
Résolution des échecs de migration dans WebSphere InterChange Server
Si le processus de migration depuis WebSphere InterChange Server échoue, vous pouvez résoudre ce problème de deux manières.
Pourquoi et quand exécuter cette tâche
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étiers deviennent des objets métier WebSphere Process
Server.
- les mappes deviennent des mappesWebSphere 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 de médiation WebSphere Process Server contenant des importations et des exportations SCA ainsi que des composants de flux de médiation si le connecteur est migré vers une liaison native. Les définitions de connecteur
deviennent des modules WebSphere Process
Server contenant des importations et des exportations SCA ainsi que des composants de flux de médiation permettant de communiquer avec les adaptateurs existants, avec l'artefact d'administration de l'adaptateur existant
ainsi que 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
Interfaces de programme d'application WebSphere InterChange
Server prises en charge
Outre les outils de migration d'artefacts source WebSphere InterChange
Server fournis dans WebSphere Process Server et dans WebSphere Integration Developer,
de nombreuses interfaces de programme d'application (API) de WebSphere InterChange Server sont prises en charge.
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 d'objets de données WebSphere Process Sever à partir d'un fichier XML WebSphere InterChange
Server
Si vous utilisez les adaptateurs existants pour vous connecter à WebSphere Process Server, l'algorithme suivant vous permet de mieux comprendre comment l'objet données WebSphere Process Server a été créé à partir du fichier XML WebSphere InterChange Server. 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é fichier XML WebSphere InterChange
Server XML, CxBlank et CxIgnore seront 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 de WebSphere MQ Workflow vers WebSphere Integration Developer
WebSphere Integration Developer fournit les outils nécessaires pour migrer à partir de WebSphere MQ Workflow.
Pourquoi et quand exécuter cette tâche
L'assistant de migration convertit les définitions FDL des processus métier
que vous avez exportés à partir du composant build time de WebSphere MQ Workflow en artefacts WebSphere Integration
Developer 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. Vérifiez également que toutes les définitions de serveur d'exécution de processus définies par l'utilisateur
(UPES) et référencées dans votre modèle de processus WebSphere MQ Workflow sont sélectionnées lorsque vous exportez FDL à partir du composant build time de WebSphere MQ Workflow.
Remarque : L'Assistant de migration ne couvre pas la migration des :
- instances d'exécution de WebSphere MQ Workflow,
- 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 obtenir plus d'informations sur la migration à l'aide de l'outil de conversion FDL2BPEL, consultez le Site de support 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.
Pourquoi et quand exécuter cette tâche
L'étendue des mappages et leur complétude dépendent 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é Recevoir 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 identiques. 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. Parmi les artefacts générés figurent 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.
Pourquoi et quand exécuter cette tâche
Remarque : L'Assistant de migration ne couvre pas la migration des :
- instances d'exécution de WebSphere MQ Workflow,
- 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.
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 -> Importation -> Intégration métier -> Fichier FDL de WebSphere MQ Workflow et cliquez sur
Suivant. Remarque : Vous pouvez aussi ouvrir
l'assistant de migration depuis la page Bienvenue en cliquant sur l'icône Pour ceux qui sont déjà utilisateurs pour ouvrir la page correspondante (vous pouvez toujours revenir à la page Bienvenue en cliquant sur AideBienvenue).
Cliquez sur Migration du côté gauche de la page
Pour ceux qui sont déjà utilisateurs afin d'ouvrir la page Migration et sélectionnez l'option Migrer
un processus de 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. Vous devez également indiquer un nom de module avant que cette tâche puisse être exécutée. Cliquez sur Suivant:
- La page Options de migration de WebSphere
MQ Workflow permettant de définir les paramètres de création d'artefacts 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 Créer 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 Suivant. La page Options de migration de WebSphere MQ Workflow permettant d'optimiser les processus métier migrés s'ouvre :
A l'aide de cette page, vous pouvez définir les options afin d'optimiser
les processus métier migrés. Pour obtenir plus d'informations sur ces options,
consultez la rubrique "Optimisation des processus métier migrés" dans les liens connexes
ci-dessous ou cliquez sur F1 lorsque vous sélectionnez/désélectionnez
chaque rubrique.
- Lorsque vous avez sélectionné et vérifié vos options d'optimisation,
cliquez sur Terminer.
Que faire ensuite
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 le processus de migration terminé,
la boîte de dialogue de migration disparaît et la fenêtre Résultats de la migration s'ouvre :
Afin de conserver tous les messages pour
vous y référer ultérieurement, cliquez sur le bouton Générer les tâches de l'agenda
pour créer une liste des tâches "d'agenda" dans la vue Tâches ou cliquez sur le bouton Sauvegarder
sous pour sauvegarder les messages dans fichier texte du 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 consulter
la liste des tâches d'agenda générée, cliquez sur Fenêtre -> Afficher la vue -> Autre -> Général -> Tâches et cliquez sur OK.
La vue Tâches affiche la liste de l'agenda généré à partir du processus de migration.
Optimisation du processus métier migré
Lors de la migration de processus métier, il existe plusieurs options
d'optimisation qui vont améliorer l'efficacité globale, la performance et la
convivialité de vos processus métier migrés. Par exemple,
vous pouvez réduire le nombre de fragments Java,
supprimer les éléments structurels superflus et réduire le nombre de variables BPEL à l'aide des options d'optimisation de l'assistant de migration.
Le tableau ci-dessous détaille les options de migration de WebSphere MQ Workflow ainsi que les résultats associés à chacune d'elles :
Tableau 3. Options d'optimisation de la migration de WebSphere MQ Workflow
Option |
Résultat |
Fusionner les fragments Java adjacents |
Cochez cette case pour optimiser le processus métier
en associant les fragments Java si possible
(en série, parallèle ou mixte). Le processus s'exécute plus efficacement lorsque
les variables sont partagées dans un fragment Java et que les morceaux de code dupliqués peuvent être éliminés.
Si vous ne cochez pas cette case, le processus reste valide mais plusieurs fragments Java distincts resteront dans le processus BPEL. |
Supprimer les éléments structurels superflus |
Cochez cette case pour optimiser le processus métier
en supprimant les éléments structurels. Une imbrication non essentielle d'activités BPEL structurelles ralentit le flux du processus. |
Réduire le nombre de variables |
Cochez cette case pour optimiser le processus métier en
réduisant le nombre de variables BPEL. Utilisez la barre de défilement pour sélectionner le niveau de réduction. Lors de la migration d'un processus FDL vers un processus BPEL,
plusieurs variables BPEL sont créées sur la base des variables FDL. Vous pouvez décider de supprimer toutes, certaines ou aucune de ces variables FDL à transférer vers le processus BPEL.
- Niveau 0 de réduction de variables : cette option permet de partager
un minimum de variables. Les variables FDL correspondantes
des conteneurs en entrée et de sortie sont fusionnées en une seule variable BPEL.
- Niveau 1 de réduction de variables : cette option permet de limiter
le partage de variables. Les variables FDL de conteneur en entrée et de sortie
correspondantes sont fusionnées en une seule variable BPEL. Les variables sont
également partagées tout en tolérant un conflit potentiel avec un membre de données prédéfini "Priorité".
- Niveau 2 de réduction de variable : cette option permet
un partage moyen des variables. Les variables FDL de conteneur en entrée et de sortie
correspondantes sont fusionnées en une seule variable BPEL. Les variables sont partagées
tout en tolérant des conflits potentiels avec les membres de données prédéfinis
"Priorité" et "Notification".
Remarque : Dans de rares cas, une variable
BPEL est partagée de façon incorrecte. Dans de tels cas, ré-exécutez la migration
en diminuant le niveau d'optimisation.
- Niveau 3 de réduction de variables : cette option permet de partager
environ la totalité des variables. Les variables FDL de conteneur en entrée et de
sortie correspondantes sont fusionnées en une seule variable BPEL.
Les variables sont partagées tout en tolérant des conflits potentiels avec les membres de données prédéfinis "Priorité", "Notification" et "Personnel".
Remarque : Dans de rares cas,
une variable BPEL est partagée de façon incorrecte. Dans de tels cas,
ré-exécutez la migration en diminuant le niveau d'optimisation.
- Niveau 4 de réduction de variable : cette option permet de
partager autant de variables que possible. Les variables FDL des conteneurs en entrée
et de sortie correspondantes sont fusionnées en une seule variable BPEL.
Les variables sont partagées tout en tolérant des conflits potentiels
avec les membres de données prédéfinis "Priorité", "Notification", "Personnel" et avec
les paramètres de données par défaut.
Remarque : Dans de rares cas, une variable BPEL est
partagée de façon incorrecte. Dans de tels cas, ré-exécutez la migration en diminuant
le niveau d'optimisation. |
Pour obtenir plus d'informations sur les options d'optimisation ainsi que sur l'outil de ligne de commande pour la migration du
workflow MQ, consultez le Site de support WebSphere Process
Server.
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 ferme dans le cas où la migration a abouti.
Pourquoi et quand exécuter cette tâche
La page suivante apparaît si les messages de migration ont été générés lors 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 s'y référer ultérieurement,
cliquez sur le bouton Générer les tâches de l'agenda pour créer une liste
des tâches d'"agenda" dans la vue Tâches ou cliquez sur le bouton Enregistrer sous pour sauvegarder les messages dans un fichier texte du 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 consulter
les tâches d'agenda générées, 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ée à 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 à partir de WebSphere Studio
Application Developer Integration Edition
Il est possible de migrer les artefacts source des projets de la version 5.1 de WebSphere Business Integration Server Foundation (WBISF)
à 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.
Migration de votre espace de travail
Dans WebSphere Integration
Developer 6.2, vous ne pouvez migrer qu'un espace de travail valide (c'est-à-dire un espace de travail
qui contient au moins un projet de service). Cette section vous donne des informations sur la migration
de votre espace de travail WebSphere Studio
Application Developer Integration Edition.
Pourquoi et quand exécuter cette tâche
Afin de migrer totalement un espace de travail WebSphere Studio
Application Developer Integration Edition, les tâches essentielles suivantes doivent être exécutées :
- Préparez les artefacts source à la migration. Vous devrez peut-être effectuer ces actions dans WebSphere Studio Application Developer Integration Edition.
- Utilisez l'assistant de migration ou le script de ligne de commande WSADIEWorkspaceMigration pour migrer l'espace de travail.
- S'il y a lieu, utilisez WebSphere Integration
Developer pour terminer manuellement la migration. 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. Des informations supplémentaires sur ces tâches sont disponibles dans la section "Informations supplémentaires sur la
migration".
Que faire ensuite
Remarque : La migration d'exécution (chemin de mise à niveau) n'est pas fournie dans
WebSphere
Process Server 6 x. Par conséquent, ce mode de migration des artefacts source est la seule option
pour migrer les espaces de travail
WebSphere
Studio Integration Edition dans la version 6 x.
Avant de migrer des artefacts source de WebSphere Studio Application Developer
Integration Edition, vérifiez que les espaces de travail avec des projets WebSphere Business Integration Server Foundation
contiennent un ou plusieurs projets de service.
L'assistant de migration offre la possibilité de migrer un espace de travail WebSphere Studio Application Developer Integration Edition version 5.1 (ou ultérieure) à la fois.
L'assistant de migration ne migre pas les fichiers binaires d'application
- il migre uniquement les artefacts source détectés dans un espace de travail WebSphere Studio Application Developer
Integration Edition.
Avant de migrer les artefacts source de WebSphere Studio Application
Developer Integration Edition vers WebSphere Integration Developer, vous devez d'abord vérifier que vous avez correctement préparé votre environnement pour le processus de migration.
Pourquoi et quand exécuter cette tâche
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.
- 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 vous n'avez pas activé ces fonctions, 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 Fenêtre -> Préférences.
- Cliquez sur Général et sélectionnez la catégorie Capacités.
- Sélectionnez toutes les fonctionnalités dans les catégories suivantes :
- Développeur de logiciels Java Enterprise
- Integration Developer
- Java Developer
- Web Developer (standard)
- Web Service Developer
- XML Developer
- Cliquez sur OK.
- Utilisez un nouvel espace de travail en tant que cible pour la migration.
- Par défaut, WebSphere Integration
Developer génère le code de déploiement lors de la phase de création des projets WEB, EJB et EAR pris en charge pour les modules WebSphere Integration
Developer.
Remarque : Le code de déploiement des autres projets (par
exemple, J2EE) ne sont pas générés.
- Afin de migrer complètement les fichiers BPEL au sein d'un espace de travail, vous devez vérifier que
tous les fichiers WSDL et XSD référencés par les fichiers BPEL peuvent être résolus par
un projet d'intégration métier du nouvel espace de travail :
- Si les fichiers WSDL ou XSD font partie du projet en cours, référencent un projet ou se trouvent dans une bibliothèque commune avec le fichier BPEL, aucune autre action n'est requise.
- Si les fichiers WSDL ou XSD se trouvent dans un autre projet que celui en cours de migration,
les artefacts de la version 5.1 doivent être réorganisés à l'aide de WebSphere Studio Application Developer Integration Edition avant la migration car les projets de module d'intégration métier ne peuvent pas partager d'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 partagés par plus d'un projet dans ce nouveau
projet Java.
Ajoutez à tous les projets utilisant ces artefacts communs une dépendance
avec ce nouveau projet Java.
- Sinon, vous pouvez conserver une copie locale de ces artefacts WSDL et
XSD partagés dans chaque projet de sorte qu'il n'existe aucune dépendance entre les projets.
- Si les fichiers WSDL ou XSD se trouvent dans un autre type de projet (souvent, il s'agit d'autres projets
Java), vous devez créer un projet de bibliothèque d'intégration métier portant
le même nom que le projet de la version 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. Notez que deux fichiers WSDL ne peuvent pas
définir un type de port, un service ou un port ayant le même nom et le même espace de nom cible.
Vous devriez corriger cela manuellement avant la migration pour éviter la survenue d'erreurs.
Remarque : WebSphere Integration
Developer ne prend pas en charge les types XML-SOAP comme indiqué dans l'espace de nom http://xml.apache.org/xml-soap.
Il est recommandé de supprimer les références à ces types dans WebSphere Studio Application Developer Integration Edition avant la migration afin d'éviter un échec du processus de migration.
Que faire ensuite
Vous êtes maintenant prêt à commencer le processus de migration.
Remarques concernant la pré-migration
Il existe un certain nombre de remarques relatives au processus de migration d'artefact
source à partir 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 :
- L'espace de travail cible WebSphere Integration
Developer doit être vide, c'est-à-dire que les projets doivent être supprimés de l'espace de travail. Les dossiers et fichiers contenus dans le dossier d'espace de travail du système de fichiers doivent eux aussi être supprimés.
- Les types de projet WebSphere Studio Application
Developer Integration Edition pris en charge par l'assistant de migration sont les suivants :
les projets de service, les projets Java,
les projets EJB, les projets de connecteur, les projets d'application entreprise, les projets client d'application, les projets Web dynamiques et les projets Web statiques. Tout autre type de projet pouvant exister dans WebSphere Studio Application Developer
Integration Edition sera copié dans l'espace de travail WebSphere Integration Developer workspace,
mais sa migration ne pourra pas être traitée.
- 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).
- Indiquez un composant par message WSDL si le langage WSDL est un style de document
et par spécification d'interopérabilité de services Web (WS-I), ainsi que le style préféré de la version 6.x. Cela ne s'applique pas aux WSDL de style appel de procédure distant.
- 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 par la version 6.x alors que les services Web Apache
ne le sont pas.
- 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 dans un projet Java pouvant être référencé par l'espace de travail.
- Conservez une copie locale de tous les fichiers WSDL/XSD qu'un projet référence dans
le projet lui-même. Les projets WebSphere Studio
Application Developer Integration Edition seront migrés vers un module d'intégration métier
dans WebSphere Integration Developer. Un module
ne peut pas avoir de dépendances sur d'autres modules (un projet ayant des dépendances
sur un autre projet dans le but de partager 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'interface de programme d'application 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 d'envoyer des paramètres WSIFMessage à une classe Java personnalisée. Dès que cela est possible, essayez de ne pas dépendre du format de données WSIFMessage.
- Evitez, si possible, l'utilisation d'interfaces de programme d'application 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 vos interfaces WSDL précisément et évitez, dans la mesure du possible, 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 même nom et de même espace
de nom cible ne sont pas autorisées. Cette situation se produit souvent lorsque l'assistant de services Web ou la commande Java2WSDL est utilisée sans indiquer explicitement l'espace de nom cible
(l'espace de nom cible sera unique pour le nom de package de l'EJB
ou du bean Java,
mais pas pour la classe elle-même. Des problèmes peuvent donc se produire lorsqu'un service Web est généré pour plusieurs EJB ou beans Java dans le même package). 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 espaces de travail à l'aide de l'assistant de migration WebSphere Integration Developer
L'assistant de migration WebSphere Integration
Developer permet la migration d'espaces de travail avec tous les projets qu'ils contiennent.
Pourquoi et quand exécuter cette tâche
Dans le cadre de la migration de projets de service, l'assistant de migration exécute les tâche suivantes :
- Création d'un module d'intégration métier (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 processus 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 : Utilisez un nouvel espace de travail WebSphere Integration
Developer comme cible de migration.
Afin de migrer les espaces de travail
à l'aide de l'assistant de migration WebSphere Integration
Developer Migration, procédez comme suit :
- Appelez l'assistant en sélectionnant Fichier -> Importation -> Intégration métier -> Espace de travail WebSphere Studio Application Developer Integration Edition et cliquez sur Suivant. Remarque : Vous pouvez aussi
ouvrir l'assistant de migration à partir de la page Bienvenue en cliquant sur l'icône Pour ceux qui sont déjà utilisateurs afin d'ouvrir la page
correspondante (Notez que vous pouvez toujours revenir à la page Bienvenue en cliquant sur Aide -> Bienvenue ). Cliquez sur Migration dans la partie gauche
de la page Pour ceux qui sont déjà utilisateurs afin d'ouvrir la page Migration et sélectionnez l'option Migrer un espace de travail Integration Edition 5.1.
- L'Assistant de migration apparaît. Entrez le chemin d'accès de l'espace de travail
à migrer ou cliquez sur Parcourir afin de le rechercher. Cliquez sur Suivant.
- Dans la page d'options de migration, vous pouvez éditer l'option afin de conserver les fragments BPEL Java originaux dans les commentaires.
- Cliquez sur Terminer pour commencer le
processus de migration. Une barre d'état de migration s'affiche en base de
la fenêtre de l'assistant de migration.
- Une fois le processus terminé, le message suivant s'affiche :
Cliquez sur Suivant pour lancer le processus
de validation de la migration.
- Sélectionnez les projets d'espace de travail à migrer :
Cliquez sur Suivant.
- Les ressources de projet sur lesquelles le processus de migration peut
avoir un impact sont répertoriées dans :
Vérifiez cette liste
et cliquez sur Suivant.
- Une fois que vous être prêt, cliquez sur Terminer pour
commencer la migration des projets sélectionnés.
- Lorsque le processus de validation de la migration est terminé, le message suivant devrait s'afficher :
- Lorsque ce processus est terminé, la fenêtre Résultats de la migration
s'ouvre :
Un fichier journal
contenant ces messages de migration est automatiquement générée
dans le doffiser .metadata de l'espace de travail 6.x. Ce fichier journal
a une extension .log.
- Pour
conserver tous les messages afin de vous y référer ultérieurement, cliquez sur le bouton
Générer une liste d'agenda pour créer une liste des tâches à effectuer
dans la vue des tâches 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 voir visualiser la liste des tâches à exécuter,
cliquez sur Fenêtre -> Afficher la vue -> Autre -> Général -> Tâches et cliquez sur OK.
La vue Tâches affiche la liste de l'agenda généré à partir du processus de migration.
Que faire ensuite
Une fois l'assistant de migration terminé, générez l'espace de travail créé et essayez de résoudre les éventuelles erreurs de génération. Vérifiez tous les fichiers
BPEL migrés et assurez-vous qu'ils sont tous migrés en totalité et qu'ils peuvent être ouverts dans l'éditeur BPEL WebSphere Integration
Developer. Certains fragments BPEL Java ne peuvent pas être automatiquement migrés.
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 espace de travail, ouvrez l'éditeur de dépendances pour vérifier que les dépendances sont définies correctement. Pour cela, basculez dans la perspective Intégration métier et cliquez deux fois sur le
projet de module d'intégration métier. 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 d'espaces de travail à l'aide de WSADIEWorkspaceMigration
La commande WSADIEWorkspaceMigration
permet la migration d'espaces de travail.
Pourquoi et quand exécuter cette tâche
Dans le cadre de la migration de projets de service, la commande de migration exécute les tâches suivantes :
- Création d'un module d'intégration métier (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 processus BPEL
- Génération d'un fichier de contrôle avec une extension .mon pour chaque processus BPEL
afin de conserver le comportement de contrôle par défaut de WebSphere Studio Application Developer
Integration Edition (s'il y a lieu).
- 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).
Afin d'exécuter le script WSADIEWorkspaceMigration,
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 se situe sous un chemin de répertoire
similaire à celui ci-après : <wid_root>\wstools\eclipse\plugins\com.ibm.wbit.migration.wsadie_6.2.0.v20081112_0200
- Appelez le script de la manière suivante : WSADIEWorkspaceMigration.bat
-WIDstartup eclipse_dir -WIDworkspace WID_target_workspace -WSADIEworkspace source_WSADIE_Workspace_dir
Définitions de paramètre :
- -WIDstartup
- Emplacement de votre dossier Eclipse (runtime Eclipse).
- -WIDworkspace
- Nouvel espace de travail dans lequel le nouveau module d'intégration métier sera créé.
- -WSADIEworkspace
- Chemin d'accès complet à l'espace de travail WebSphere Studio
Application Developer Integration Edition 5.1.
Par exemple :
WSADIEWorkspaceMigration.bat -WIDstartup "C:\IBM\WID\eclipse" -WIDworkspace
"c:\WID Workspaces\myWIDWorkspace" -WSADIEworkspace "c:\wsadie workspaces\myWSADIEWorkspace"
- Une fois l'exécution de la commande terminée, démarrez le nouvel espace de travail dans WebSphere Integration
Developer.
- Générez l'espace de travail créé et essayez de résoudre les erreurs de génération. Vérifiez tous les fichiers BPEL migrés et assurez-vous qu'ils sont complètement migrés et qu'ils peuvent être ouverts dans l'éditeur
BPEL WebSphere Integration Developer.
Il existe certains fragments BPEL Java qui ne peuvent pas
être automatiquement migrés. 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 et vérifiez que les dépendances sont définies correctement. Pour cela, basculez dans la perspective Intégration métier
et cliquez deux fois sur le projet de module d'intégration métier.
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.
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 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.
Pourquoi et quand exécuter cette tâche
La page suivante apparaît si les messages de migration ont été générés
lors du processus de migration :
Dans la fenêtre Résultats de la
migration, vous pouvez visualiser 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 les tâches de l'agenda pour créer une liste des tâches à effectuer
dans la vue des tâches 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 Intégration métier 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 d'intégration métier, 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.
Pourquoi et quand exécuter cette tâche
Voici quelques exemples de ces échecs :
Si l'assistant de migration se termine sans que ce message s'affiche, une liste d'informations, d'avertissements et de messages 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 de la migration d'artefacts source
Il existe des limitations au processus de migration d'artefacts source 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
- Les types de projet WebSphere Studio Application
Developer Integration Edition pris en charge par l'assistant de migration sont les suivants :
les projets de service, les projets Java,
les projets EJB, les projets de connecteur, les projets d'application entreprise, les projets client d'application, les projets Web dynamiques et les projets Web statiques. Tout autre type de projet pouvant exister dans WebSphere Studio Application Developer
Integration Edition sera copié dans l'espace de travail WebSphere Integration Developer, mais sa migration ne pourra pas être traitée.
- 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.) sont du type :
<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 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 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.
- WebSphere Integration
Developer ne prend pas en charge les types XML-SOAP comme défini dans l'espace de nom http://xml.apache.org/xml-soap.
Il est recommandé de supprimer les références à ces types dans WebSphere Studio Application Developer Integration Edition avant la migration afin d'éviter un échec de la procédure de migration.
- Lorsqu'un espace de travail est migré, certains modules peuvent avoir des dépendances sur d'autres modules. WebSphere Integration Developer ne le vérifie pas, mais des erreurs similaires à celle ci-après
peuvent se produire après le déploiement de l'application :
======== TravelOperationsApp ========
L'application ne parvient pas à démarrer : TravelOperationsApp
com.ibm.ws.exception.RuntimeWarning : javax.resource.ResourceException :
Echec de la recherche ActivationSpec.sca/TravelOperations/ActivationSpec
Après la
migration, il est recommandé de vérifier les modules, de supprimer manuellement le projet et de créer des dépendances de chemin d'accès entre les modules. Pour ce faire, il se peut que vous deviez déplacer certains WSDL et fichiers Java dans un projet de bibliothèque commun.
- Les projets de type J2EE ne sont pas migrés vers le niveau J2EE le plus courant.
Par exemple, si des projets dans l'espace de travail WebSphere Studio Application Developer Integration Edition sont au niveau 1.3
et sont conservés à ce niveau une fois migrés au lieu d'être passés au niveau 1.4 (le niveau le plus courant dans
V6.2), cela n'entraîne aucun incident. Si vous voulez les mettre au niveau
le plus courant, vous pouvez utiliser le menu Outils J2EE en cliquant avec
le bouton droit de la souris sur ces projets (Web, EJB, EAR, client d'application)
et en sélectionnant Outils J2EE -> Migration J2EE.
Limitations de la migration de projets EJB
Il se peut que vous rencontriez
un problème de migration si l'espace de travail source WebSphere Studio Application Developer Integration Edition dispose d'un projet EJB
sans projet de client EJB. Si le projet EJB est une dépendance d'un ou plusieurs projets de service,
l'espace de travail migré va se créer correctement
mais son déploiement sera incorrect. Cela se produit car WebSphere Integration Developer tente de déployer le projet EJB en tant que module J2EE et non en tant que fichier JAR d'utilitaire. Pour résoudre ce problème, procédez comme suit :
- Migrez l'espace de travail.
- Dans WebSphere Integration
Developer, cliquez avec le bouton droit de la souris sur Projet EJB -> Outils J2EE -> Créer un projet de client. Un projet de client EJB est créé.
- Remplacez toutes les références au projet EJB dans les modules à l'aide du client
EJB.
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 interfaces de programme d'application 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'interface API de fragments standard seront automatiquement
migrés du modèle de programmation de fragments Java 5.1
vers le modèle Java 6.x. Les appels API WSIF sont migrés vers les appels d'interface 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 les fichiers WSDL ou XSD) 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 les
fichiers WSDL ou XSD) avec des noms locaux identiques aux classes dans le package
java.lang 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 dans 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 est 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.
Informations supplémentaires concernant la migration
A l'issue d'une migration réussie, il se peut que vous vouliez vérifier les sections suivantes afin d'identifier les tâches nécessaires pour terminer la migration de espace de travail. Vous pouvez utiliser les informations de cette section pour vérifier que la migration
a réussi.
Pourquoi et quand exécuter cette tâche
- Ouvrez WebSphere Integration Developer et accédez à Intégration métier. Vous pouvez voir le ou les modules créés par l'Assistant de migration (un module par projet de service migré). Le premier artefact
répertorié dans le projet est le fichier d'assemblage du module (portant le 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 existe des processus BPEL
dans l'espace de travail WebSphere Studio
Application Developer Integration Edition, l'assistant de migration
doit avoir créé des composants SCA par défaut pour chacun de ces processus 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 une nouvelle connexion après la migration afin de reconnecter les
services comme ils étaient dans la version 5.1. Les informations suivantes expliquent plus en détails
comment relier manuellement l'application à l'aide des 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, une importation 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.
Pourquoi et quand exécuter cette tâche
Remarque : L'assistant de migration tente d'effectuer cette action automatiquement. Toutefois, vous pouvez vous référer 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.
Pourquoi et quand exécuter cette tâche
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.
L'utilisation de l'assistant de migration aboutit à la création d'un module d'intégration métier contenant les messages
WSDL, les types de port, les liaisons et les services générés dans WebSphere Studio Application
Developer Integration Edition.
Dans Intégration métier, 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).
Remarque : Si l'assistant de migration n'a pas totalement migré tous vos projets de service, les options suivantes s'offrent à vous :
Création d'un composant personnalisé Java (option 1)
Si l'assistant de migration n'a pas totalement migré tous vos projets de service, vous pouvez utiliser le type de composant Java WebSphere Integration Developer
pour 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.
Pourquoi et quand exécuter cette tâche
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 d'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 le même 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 le même 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 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
à 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)
Si l'assistant de migration n'a pas totalement migré tous vos projets de service, vous pouvez alternativement utiliser les outils de services Web
Rational Application Developer
qui vous permettent de créer un service Web autour d'une classe Java.
Pourquoi et quand exécuter cette tâche
Remarque : Cette option demande de configurer un environnement d'exécution 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 cette opération peut
prendre quelques minutes.
- 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
JavaBeans.
- Cliquez sur Suivant. Notez que cette opération peut prendre
quelques minutes.
- 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.
- Accédez à la vue Intégration métier 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 Importation 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é à cette importation pour terminer les étapes
de migration de la reconnexion manuelle.
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 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
Si l'assistant de migration n'a pas totalement migré tous vos projets
de service et si avez choisi de le faire manuellement, notez qu'il existe des avantages et des inconvénients pour chaque option de nouvelle connexion du 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.
Pourquoi et quand exécuter cette tâche
Importation de l'espace de travail à l'aide de l'assistant de migration. Cela va créer un module d'intégration métier contenant les messages WSDL, les types de port, les liaisons et les services créés dans WebSphere Studio Application Developer Integration Edition.
Dans Intégration métier,
développez le module pour voir son contenu. 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).
Si l'assistant de migration n'a pas totalement migré tous vos projets de service, les options suivantes s'offrent à vous :
Création du composant EJB personnalisé (option 1)
Si l'assistant de migration n'a pas totalement migré tous vos projets de service, vous pouvez utiliser l'importation WebSphere Integration
Developer avec le type liaison session sans état, ce qui vous permet d'appeler un EJB 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.
Pourquoi et quand exécuter cette tâche
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. 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 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 le même 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 le même 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)
Si l'assistant de migration n'a pas totalement migré tous vos projets de service, vous pouvez alternativement utiliser les outils de services Web
Rational Application Developer
qui vous permettent de créer un service Web autour d'un EJB.
Pourquoi et quand exécuter cette tâche
Remarque : Cette option demande de configurer un environnement d'exécution de service Web dans
WebSphere
Integration Developer avant d'appeler 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é à
cette importation 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 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 à 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
Si l'assistant de migration n'a pas totalement migré tous vos projets
de service et si avez choisi de le faire manuellement, notez qu'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 explique comment migrer un
BPEL vers un appel de service BPEL à l'aide d'une connexion ou d'une importation/exportation avec liaison SCA si l'assistant de migration n'a pas totalement migré tous vos projets de service.
Pourquoi et quand exécuter cette tâche
Pour migrer un projet de service de connexion (BPEL) pour un service en sortie, procédez comme suit :
- Dans Intégration métier, 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 une exportation avec liaison SCA pour le deuxième processus métier dans son diagramme de module.
- Dans Intégration métier, développez l'icône de l'assemblage du deuxième module dans le navigateur. Vous devez voir l'exportation que vous venez de créer.
- Effectuez un glisser-déposer de l'exportation de Intégration métier sous le deuxième module vers l'éditeur d'assemblage ouvert du premier module.
Une importation avec liaison SCA est créée 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'exportations SCA afin d'accéder au service migré".
- Connectez la référence appropriée sur le premier processus métier à l'importation 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)
Si l'assistant de migration n'a pas totalement migré tous vos projets de service,vous pouvez migrer un service Web (SOAP/JMS) vers une importation
SCA avec liaison de services Web.
Pourquoi et quand exécuter cette tâche
Pour migrer un projet de service SOAP/JMS sortant, procédez comme suit :
- Importation de l'espace de travail à l'aide de l'assistant de migration. Cette opération crée un module d'intégration métier 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 Intégration métier, 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).
- Ajoutez une importation qui autorise l'application à 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 Intégration métier, 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 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 à cette importation.
- Sauvegardez le diagramme d'assemblage.
Migration d'un service Web (SOAP/HTTP)
Si l'assistant de migration n'a pas totalement migré tous vos projets de service,vous pouvez migrer un service Web (SOAP/HTTP) vers une importation
SCA avec liaison de services Web.
Pourquoi et quand exécuter cette tâche
Pour migrer un projet de service SOAP/HTTP sortant, procédez comme suit :
- Importation de l'espace de travail à l'aide de l'assistant de migration. Cette opération crée un module d'intégration métier 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/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 Intégration métier, 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).
- Ajoutez une importation qui autorise l'application à 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 Intégration métier, 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 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 à cette importation.
- Sauvegardez le diagramme d'assemblage.
Migration d'un service JMS
Si l'assistant de migration n'a pas totalement migré tous vos projets de service, vous pouvez migrer un service JMS vers une importation SCA avec liaison
JMS.
Pourquoi et quand exécuter cette tâche
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 :
- Importation de l'espace de travail à l'aide de l'assistant de migration. Cette opération crée un module d'intégration métier 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 Intégration métier, 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).
- Ajoutez une importation qui autorise l'application à 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
la liaison JMS 5.1 JMS et les fichiers de service WSDL 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'importation 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 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 à cette importation.
- Sauvegardez le diagramme d'assemblage.
Migration d'un service J2C-IMS
Si l'assistant de migration n'a pas totalement migré tous vos projets de service,
vous pouvez migrer un service J2C-IMS vers une importation SCA
avec liaison EIS ou d'une importation SCA avec liaison de services Web.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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 cré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).
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
La mappe de données et les composants de la mappe d'interface offrent une fonction similaire
au service de transformateur de la version 5.1 mais n(ont pas les mêmes capacités 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.
Pourquoi et quand exécuter cette tâche
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 :
- Vérifiez que le projet Java
se trouve dans l'ancien espace de travail (le projet Java
sera migré automatiquement par l'assistant de migration).
- 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
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.
- Revenez à 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. Puis, sélectionnez le package
dans lequel l'implémentation Java
doit être 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.
Vous devez ensuite remplir les lignes de code contenant "//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 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.
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 à 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'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'assistant de migration
crée automatiquement les exportations. Toutefois, vous pouvez vous reporter aux informations suivantes pour vérifier les tâches réellement exécutées par l'outil.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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 BPEL dans les onglets Description et Contenu du
serveur de l'éditeur BPEL :
Tableau 4. 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 5. 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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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'export 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).
Pourquoi et quand exécuter cette tâche
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 les
interfaces à exporter avec ce type de liaison.
- 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.
Pourquoi et quand exécuter cette tâche
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'export 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.
Pourquoi et quand exécuter cette tâche
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 6. 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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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'export 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).
Pourquoi et quand exécuter cette tâche
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 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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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 JMS 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 car 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.
Pourquoi et quand exécuter cette tâche
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 association entre le nom du
BPEL, de l'espace de nom cible, 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 7. 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 8. 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.
Pourquoi et quand exécuter cette tâche
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'export 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 devez 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 une importation SDL 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 d'intégration métier 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 Importations 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).
Pourquoi et quand exécuter cette tâche
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 si nécessaire.
- 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.
Pourquoi et quand exécuter cette tâche
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 association entre le nom du BPEL, de l'espace de nom cible, 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 9. 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 10. 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.
Pourquoi et quand exécuter cette tâche
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'export 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 devez 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, des
messages d'erreur peuvent s'afficher 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 d'intégration métier 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
exportation utilisant 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 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 consultez la définition de service Web
IBM
WSDL réutilisée à partir de la version 5.1, vous visualiserez l'adresse de service
sur laquelle est codé le client de la version 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).
Pourquoi et quand exécuter cette tâche
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 si nécessaire.
- S'il existe plusieurs interfaces pour le processus, sélectionnez les
interfaces à 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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
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
migrés automatiquement par l'assistant de migration. Toutefois, certains d'entre eux ne peuvent pas être complètement migrés par l'assistant, ce qui signifie que des étapes manuelles sont nécessaires pour 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.
Pourquoi et quand exécuter cette tâche
Tableau 11. 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.
Pourquoi et quand exécuter cette tâche
Migration du client EJB
Cette rubrique traite de la migration de clients qui utilisent une interface EJB pour appeler un service.
Pourquoi et quand exécuter cette tâche
- 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.
Pourquoi et quand exécuter cette tâche
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
exportation 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.
Pourquoi et quand exécuter cette tâche
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
service Web, puis cliquez avec le bouton droit de la souris et sélectionnez Services Web -> Générer client.
- 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.
Pourquoi et quand exécuter cette tâche
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 service Web, puis cliquez avec le bouton droit de la souris et sélectionnez Services Web -> Générer client.
- 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.
Pourquoi et quand exécuter cette tâche
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 service
Web, puis cliquez avec le bouton droit de la souris et sélectionnez Services Web -> Générer client.
- 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.
- Terminez 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.
Pourquoi et quand exécuter cette tâche
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.
Pourquoi et quand exécuter cette tâche
Une nouvelle version de l'API d'EJB générique 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 générique 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 EJB génériques dans lesquels des opérations de tâche manuelle sont disponibles en tant qu'EJB séparé. Les noms JNDI de ces EJB génériques 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
Pour obtenir des informations sur les interfaces de programme d'application de messagerie génériques dans WebSphere Process Server, consultez la rubrique
"Développement d'applications client JMS" dans le lien ci-dessous.
Pourquoi et quand exécuter cette tâche
Développement d'applications client JMS.
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.
Pourquoi et quand exécuter cette tâche
L'assistant de migration conserve les paramètres client Web 5.1. Vous ne pouvez
pouvez pas les éditer dans l'éditeur 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 du BPEL WebSphere Business Integration Server Foundation
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.
Pourquoi et quand exécuter cette tâche
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 12. Modification et solutions concernant la migration de fragments BPEL Java de WebSphere Business Integration Server Foundation
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. |
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
d'objet de données 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 ayant plusieurs définitions de message WSDL à plusieurs parties sont traitées
différemment : il existe encore un encapsuleur autour des composants et ce dernier doit être explicitement
initialisé 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 objet de données. |
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
d'objet de données 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
d'objet de données 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
d'objet de données 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
d'objet de données 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.
Pourquoi et quand exécuter cette tâche
Pour accéder aux outils de service externe, procédez comme suit :
- Naviguez jusqu'à
Fichier -> Nouveau -> Autre -> Intégration
métier 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.
Que faire ensuite
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.
Pourquoi et quand exécuter cette tâche
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"));
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é.
Pourquoi et quand exécuter cette tâche
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/
Remarques
Ces informations concernent
certains produits et services annoncés aux États-Unis.
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 le présent document. 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-0032, 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 RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON 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 Software
IBM Corporation
3600 Steeles Ave. East
Markham, Ontario
Canada L3R 9Z7
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 pour ce dernier sont
fournis par IBM d'après les termes du contrat client IBM, des conditions internationales
d'utilisation de logiciels IBM ou de tout contrat équivalent entre nous.
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.
Tous les tarifs indiqués sont les prix de vente actuels suggérés
par IBM et sont susceptibles d'être modifiés sans préavis. Les tarifs
appliqués peuvent varier selon les revendeurs.
Ces informations sont fournies uniquement à titre de planification. Elles sont susceptibles d'être modifiées avant la mise à disposition
des produits décrits.
Le présent document peut contenir
des exemples de données et de rapports utilisés couramment dans l'environnement
professionnel. Ces
exemples mentionnent 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.
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 :
© (nom de votre société) (année). Des segments de code sont dérivés
des Programmes exemples d'IBM Corp. © Copyright IBM Corp. _entrez l'année ou les années_. 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, le logo IBM, ibm.com, sont des marques d'International Business Machines aux Etats-Unis et/ou dans certains autres pays. Si ces expressions ou d'autres expressions déposées par IBM apparaissent suivis d'un symbole ( or ),
ces derniers indiquent qu'il s'agit de marques déposées aux Etats-Unis et dont IBM était propriétaire au moment de la publication de ce document.
Ces marques peuvent être également déposées dans d'autres pays. La liste actuelle des marques déposées IBM est consultable sur le Web dans la rubrique :
«Copyright and trademark information» à l'adresse
www.ibm.com/legal/copytrade.shtml.
Adobe, le logo Adobe, PostScript, et le logo PostScript
sont des marques déposées de Adobe Systems
Incorporated aux Etats-Unis et/ou dans d'autres pays.
Java ainsi que tous les logos et toutes les marques incluant Java sont des marques de Sun Microsystems, Inc. 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.
Microsoft, Windows, Windows NT et le logo Windows sont des marques de
Microsoft Corporation aux Etats-Unis et/ou dans
certains autres pays.
Intel, le logo Intel, Intel Inside, le logo Intel Inside, Intel Centrino, le logo Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, et Pentium sont des marques d'Intel Corporation ou de ses filiales aux Etats-Unis et dans certains autres pays.
UNIX est une marque enregistrée de The Open Group 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, 2008. All Rights Reserved.