Les instructions suivantes sont fournies pour vous assister lors du développement des 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é.
Aussi évident que cela puisse paraître, les solutions d'intégration doivent respecter l'architecture et le modèle de programmation fournis par WebSphere InterChange Server. Ce modèle est le plus approprié aux solutions permettant l'intégration automatique de processus en temps réel. Par ailleurs, chaque composant d'intégration de WebSphere InterChange Server joue un rôle bien défini dans l'architecture. Plus vous déviez de ce modèle, plus la migration des contenus vers les artefacts WebSphere Process Server appropriés deviendra complexe.
Le fait de documenter la conception du système est également un facteur crucial pour la réussite des projets de migration futurs. Vous devez faire en sorte de décrire la conception et l'architecture d'intégration, y compris les besoins en termes de fonctionnalités et de qualité de service, les interdépendances entre des artefacts partagés par plusieurs projets et les décisions de conception prises lors de la phase de déploiement. Ces informations vous permettront de mieux analyser le système et d'alléger les tâches devant être effectuées après la migration.
Il est essentiel d'utiliser uniquement les outils de développement fournis pour créer, configurer et modifier des définitions d'artefacts. Evitez tout traitement manuel des métadonnées (modification directe des fichiers XML, etc.) qui risquerait d'altérer les artefacts devant faire l'objet d'une migration.
Utilisez uniquement les interfaces API mentionnées dans la documentation du produit concernant les artefacts. Celles-ci sont présentées en détail dans les guides de développement de WebSphere InterChange Server. Bien que des API de compatibilité soient souvent fournies dans WebSphere Process Server, seules les API mentionnées seront incluses. WebSphere InterChange Server comprend un grand nombre d'interfaces internes pouvant intéresser les développeurs, mais rien ne garantit leur prise en charge ultérieure.
Lors de la conception de la logique métier et des règles de transformation dans les mappes et les modèles de collaboration, utilisez le plus possible l'éditeur d'activités. Cet outil permet de s'assurer que la logique est décrite via des métadonnées pouvant être converties plus facilement vers les nouveaux artefacts. Faites appel à la fonction "My Collections" de l'éditeur d'activités pour toutes les opérations que vous souhaitez réutiliser dans les outils. Evitez d'inclure des fichiers .jar correspondant à des bibliothèques de code développées sur site dans le chemin de classe de WebSphere InterChange Server ; vous seriez contraint de les faire migrer manuellement.
Pour tout fragment Java pouvant nécessiter un développement, il est recommandé de limiter le code utilisé aux instructions de base définissant l'ordre des scripts (évaluations, opérations et calculs de base, formatage des données, conversions de types, etc.). Si une logique d'application plus complexe est requise, il est préférable de l'encapsuler dans des EJB fonctionnant sous WebSphere Application Server et d'utiliser des 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 devant être migrées séparément. Regroupez tous les éléments connexes dans un fragment de code unique et évitez d'utiliser une logique basée sur des contextes de connexion et de transaction répartis sur plusieurs fragments. Par exemple, en ce qui concerne les bases de données, le code permettant d'obtenir une connexion, de démarrer et d'arrêter une transaction ou de fermer la connexion doit être regroupé dans un seul fragment.
D'une manière générale, vérifiez que le code conçu pour fournir l'interface avec un système EIS est intégré à des adaptateurs et non à des mappes ou à des modèles de collaboration. Cette méthode est recommandée en matière de conception d'architecture. Elle permet également d'éviter que les contraintes liées à la configuration requise pour des bibliothèques tierces et d'autres considérations ne doivent être intégrées au niveau du code (gestion des connexions et implémentations JNI (Java Native Interface) possibles.
Utilisez un traitement des exceptions rendant le code aussi sécurisé que possible. Faites en sorte que le code puisse 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 sur disque. Ces pratiques ont fait leurs preuves et s'avèrent particulièrement efficaces en matière de portabilité.
Pour garantir une portabilité optimale, évitez les situations impliquant des transactions de bases de données actives sur plusieurs noeuds de fragments Java dans un modèle de collaboration ou une mappe. Par exemple, le code permettant d'obtenir une connexion, de démarrer et d'arrêter une transaction ou de fermer la connexion doit être regroupé dans un seul fragment.
Les points essentiels devant être pris en compte lors du développement d'objets métier sont les suivants : utilisation exclusive des outils fournis pour la configuration des artefacts, définition explicite du type et de la longueur des attributs de données, utilisation exclusive des API documentées.
Les objets métier de WebSphere Process Server sont basés sur des objets SDO (Service Data Objects) dont les attributs sont définis de façon très spécifique. Les objets métier sous WebSphere InterChange Server et les adaptateurs ne présentant pas les mêmes exigences de précision, il arrive que les utilisateurs associent des données de type chaîne à des attributs d'une autre nature. Pour éviter tout incident sous WebSphere Process Server, soyez le plus explicite possible dans la spécification des types de données.
Etant donné que les objets métier de WebSphere Process Server peuvent être sérialisés en cours d'exécution lorsqu'ils sont transférés d'un composant à l'autre, il est important de définir explicitement la longueur des attributs afin de minimiser l'utilisation des resfacts source système. Pour cette raison, évitez, par exemple, d'utiliser la longueur maximum d'attribut de chaîne (255 caractères). Ne définissez pas non plus une valeur de 0 ; la valeur par défaut de 255 caractères serait alors prise en compte. Indiquez la longueur exacte requise pour les attributs.
Etant donné que les règles XSD NCName s'appliquent aux noms des attributs d'objet métier sous WebSphere Process Server, n'utilisez pas les espaces ni les deux points (:) dans ces noms. Ces caractères ne sont pas reconnus par WebSphere Process Server pour les noms d'attributs des objets métier. Renommez les attributs des objets métier avant la migration.
Si un objet métier contient un tableau, notez qu'il est possible que l'ordre d'origine ne soit pas respecté lors de son indexation dans les mappes et/ou les relations. Il n'est pas garanti que l'ordre d'indexation soit conservé lorsque de la migration sous WebSphere Process Server, particulièrement si des entrées sont supprimées.
Comme indiqué précédemment, il est primordial de modifier les définitions des objets métier exclusivement à l'aide de l'outil fourni, et d'utiliser uniquement les API publiées pour les objets métier des artefacts d'intégration.
La plupart des instructions décrites plus haut s'appliquent également au développement de modèles de collaboration.
Pour vous assurer que les processus sont décrits de façon appropriée par les métadonnées, utilisez toujours l'outil de conception de processus fourni pour créer et modifier les 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 des métadonnées décrivant la logique requise.
Pour alléger les tâches manuelles nécessaires après la migration, utilisez uniquement les API documentées dans les modèles de collaboration. Evitez l'utilisation de variables statiques. Utilisez plutôt des variables non statiques et des propriétés de collaboration pour gérer les conditions requises par 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 les fragments Java BPEL résultant de la migration des modèles de collaboration.
Pour assurer une portabilité du code optimale, évitez d'utiliser des appels de fin de connexion explicites et la mise entre parenthèses de transactions (validations et annulations) explicites pour les pools de connexion aux bases de données définis par l'utilisateur. Utilisez plutôt les fonctions de nettoyage implicite et de mise entre parenthèses implicite des transactions gérées par le conteneur. Evitez les situations impliquant des transactions et des connexions systèmes actives sur plusieurs noeuds de fragments Java dans un modèle de collaboration. Cela s'applique à toutes les connexions à un système externe ainsi qu'aux pools de connexion aux bases de données définis par l'utilisateur. Comme indiqué précédemment, les opérations impliquant un service EIS externe doivent être gérées au sein d'un adaptateur, et le code lié aux opérations portant sur les bases de données doit être contenu dans un fragment de code unique. Cela peut s'avérer nécessaire dans une collaboration qui, lorsqu'elle est présentée sous la forme d'un composant de processus métier BPEL, peut être déployée sélectivement en tant que flux interruptible. Dans ce cas, le processus peut comporter plusieurs transactions distinctes ; seules les informations sur les variables d'état et les variables globales sont alors transmises entre les activités. Le contexte de toutes les connexions système ou transactions associées impliquées par ces transactions de processus serait perdu.
N'utilisez pas de caractères spéciaux dans les noms de propriétés des modèles de collaboration. Une fois ces noms migrés en noms de propriétés BPEL, ces caractères ne seront pas reconnus. Renommez les propriétés de manière à supprimer ces caractères avant de procéder à la migration. Vous éviterez ainsi la création d'erreurs de syntaxe BPEL lors de la migration.
Ne faites pas référence à des variables en utilisant le terme "this". Par exemple, au lieu d'utiliser "this.inputBusObj", utilisez "inputBusObj".
Définissez la portée des variables au niveau des classes et non au niveau des scénarios. Une portée limitée à un scénario n'est pas conservée lors de la migration.
Initialisez toutes les variables déclarées dans les fragments Java avec une valeur par défaut. Exemple : "Object myObject = null;". Assurez-vous que toutes les variables sont initialisées lors de la déclaration, avant la migration.
Vérifiez qu'aucune instruction d'importation Java ne se trouve dans les sections modifiables par l'utilisateur des modèles de collaboration. Dans la définition de ces derniers, utilisez les zones d'importation pour indiquer les packages Java à importer.
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 par les métadonnées, utilisez toujours l'outil de conception fourni pour créer et modifier les 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 des métadonnées décrivant la logique requise.
Utilisez une sous-mappe lorsque vous faites référence à des objets métier enfant dans une mappe.
Evitez d'utiliser du code Java comme valeur d'une instruction SET : cette opération n'est pas valide sous WebSphere Process Server. Utilisez plutôt des constantes. Par exemple, la valeur définie est "xml version=" + "1.0" + " encoding=" + "UTF-8" n'est pas reconnue par WebSphere Process Server. Indiquez "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 modèles de collaboration. Evitez l'utilisation de variables statiques. Utilisez plutôt des variables non statiques et des propriétés de collaboration pour gérer les conditions requises par la logique métier. Evitez l'utilisation de qualificatifs Java finaux, transitoires et natifs dans les fragments Java.
Si un objet métier contient un tableau, notez qu'il est possible que l'ordre d'origine ne soit pas respecté lors de son indexation dans les mappes. Il n'est pas garanti que l'ordre d'indexation soit conservé lorsque de la migration sous WebSphere Process Server, particulièrement si des entrées sont supprimées.
Pour assurer une portabilité du code optimale, évitez d'utiliser des appels de fin de connexion explicites et la mise entre parenthèses de transactions (validations et annulations) explicites pour les pools de connexion aux bases de données définis par l'utilisateur. Utilisez plutôt les fonctions de nettoyage implicite et de mise entre parenthèses implicite des transactions gérées par le conteneur. Evitez les situations impliquant des transactions et des connexions systèmes actives sur des fragments Java répartis sur plusieurs noeuds de transformation. Cela s'applique à toutes les connexions à un système externe ainsi qu'aux pools de connexion aux bases de données définis par l'utilisateur. Comme indiqué précédemment, les opérations impliquant un service EIS externe doivent être gérées au sein d'un adaptateur, et le code lié aux opérations portant sur les bases de données doit être contenu dans un fragment de code unique.
Bien que les définitions de relations puissent être migrées pour être utilisées sous WebSphere Process Server, n'oubliez pas que le schéma et les données d'instances des tables de relations peuvent être réutilisés par ce même programme, tout comme ils peuvent être partagés par WebSphere InterChange Server et WebSphere Process Server.
En ce qui concerne les relations, les points cruciaux à prendre en compte sont les suivants : vous devez faire appel uniquement à l'outil fourni pour configurer les composants associés, et vous ne devez utiliser que les API publiées pour les relations incluses dans les artefacts d'intégration.
Les définitions de relations ne doivent être modifiées qu'à l'aide de l'outil de conception de relations fourni. En outre, seul WebSphere InterChange Server doit être utilisé pour configurer le schéma des relations, qui est généré automatiquement lors du déploiement des définitions de relations. Ne modifiez pas le schéma des tables de relations directement à l'aide d'outils de base de données ou de scripts SQL.
En outre, si vous devez modifier manuellement les données d'instances des relations faisant partie de ce schéma, assurez-vous d'utiliser les fonctions de l'outil de conception approprié.
Comme indiqué précédemment, vous ne devez utiliser que les API publiées pour les relations incluses dans les artefacts d'intégration.