Remarque : avant
d'utiliser ces informations et le produit concerné, lisez les informations dans la rubrique “Remarques” à la fin de ce document.
16 mars 2005
Cette édition du présent document s'applique à WebSphere Product Center (5724-I68), version 5.2, ainsi qu'à toutes les éditions et modifications suivantes, sauf indication contraire dans de nouvelles éditions.
© Copyright International Business Machines Corporations 2001, 2005. All rights reserved.
US Government Users Restricted Rights Use, duplication or disclosure restricted
by GSA ADP Schedule Contract with IBM Corp.
Chapitre 1 - Contrôle de WebSphere Product Center
Services de WebSphere Product Center
Obtention du statut court d'un service
Obtention du statut long d'un service
Contrôle et gestion de la base de données
1. Allocation d'espace supplémentaire en cas de nécessité
2. Application de groupes de correctifs
3. Démarrage et arrêt de la base de données / du gestionnaire de bases de données
4. Analyse du schéma de la base de données et collecte des statistiques
5. Réorganisation des tables et des index
6. Vérification du statut des travaux de sauvegarde planifiés
7. Restauration et récupération de la base de données
8. Ajustement des performances de la base de données
Chapitre 2 - Performances de WebSphere Product Center
Gestion de l'espace disque
Fichiers temporaires
Mise en cache de pages Web
Spécifications matérielles
Chapitre 3 - Administration de la base de données
Utilisateur de la base de données
Sauvegarde de base de données
Sauvegardes physiques
Sauvegardes logiques
Vérification de l'état de santé de la base de données
Configuration des alertes du centre de contrôle DB2
Outil de développement de gestion de la base de données
Chapitre 4 - Magasin de documents
Répertoires
Architecture
Gestion de l'espace table
Suppression de fichiers
Opération GZIP facultative sur les BLOB
Défragmentation
Foire aux questions sur le magasin de documents
Chapitre 5 - Sauvegarde et récupération
Sauvegarde de WebSphere Product Center
Sauvegarde de base de données
Récupération
Chapitre 6 - Journal d'événements de WebSphere Product Center
Fichiers de configuration du journal de maintenance de WebSphere Product Center
Journaux générés à l'exécution
Configuration des fichiers journaux
Changement d'emplacement
Changement de taille de fichier
Modification de l'option de sauvegarde de fichier
Modification du modèle de conversion
Indicateurs de conversion
Modificateurs de format
Caractères de conversion
Fichiers de configuration de journalisation de WebSphere Product Center
Chapitre 7 - Configuration de la vérification orthographique
Limitations
Fonctions de
vérification orthographique
Activation de la vérification orthographique
Conditions requises
Configuration de WebSphere
Product Center pour l'exécution de la vérification
orthographique avec WinterTree
Intégration LDAP
Généralités sur les fonctions
Généralités d'ordre fonctionnel
Hypothèses
Limitations
Impact sur la migration pré-5.2
Intégration de LDAP à WebSphere Product Center
1. Configuration du schéma
LDAP pour des utilisateurs et des rôles
2. Modification du fichier de configuration LDAP
3. Redémarrage du système
Chapitre 9 - Identification des incidents
Outils
Problèmes relatifs au serveur d'applications
Problèmes liés à l'environnement
Paramètres de fichiers de configuration communs incorrects
Serveur d'applications sans réponse
Problèmes liés à la base de données
1. Conversion de caractères lors d'exportations/importations de données
2. Problèmes d'allocation d'espace de base de données
3. Ralentissements de WebSphere Product Center une fois un travail en cours d'exécution arrêté
4. Problèmes de commutation des fichiers journaux
5. Arrêt du logiciel intermédiaire WebSphere Product Center et gel de l'interface graphique
6. Arrêt de l'analyse du travail de schéma
Contrôle des erreurs dans les fichiers journaux
Problèmes liés à la connectivité
Erreurs d'enregistrement HTTP
Erreur d'extraction FTP
Test de connectivité Java
Autres problèmes
Arrêt et redémarrage de WebSphere Product Center
Migration de 4.2.0.x vers 5.2
Exportation d'une société
Importation d'une société
Impact sur la migration
Migration de 4.2.1 vers 5.1
Chapitre 11 - Prise en charge des services Web
Prise en charge du langage de définition de
services Web (WSDL)
Interface utilisateur de service Web
Opérations de script prenant en charge des
services Web
Prise en charge du style Document/Literal
Chapitre 12 - Pratiques d'intégration recommandées
Définitions et acronymes
Dimensions d'intégration
Utilisation de WebSphere Product Center en tant que système source ou cible
Système de contrôle
Protocole
Format
Taille des données
Types de communications
Fréquence
Unité d'exécution d'intégration
Acronymes
Principes de conception
Réutilisation
Partage d'informations
Traitement des informations
Gestion des événements
Suivi des modifications
Connecteurs réutilisables
Implémentation
Echelonnement de l'implémentation
Réglage des performances
Validation
Stabilité
Tests échelonnables
Visibilité
Génération de rapports
Documentation
Dix instructions à suivre pour l'intégration
à WebSphere Product Center
Utilisation d'une terminologie claire et commune pour décrire les intégrations
Réutilisation
Visibilité
Mini-intégrations
Environnements représentatif ou complet
Test des processus échelonnables
Performances
Etablissement rapide d'une unité d'exécution unique
Spécifications et documentation de la conception
Propriétaire unique
Intégrations de plateforme d'intégration
d'applications d'entreprise
Approche
Avantages complémentaires
Le contrôle de WebSphere Product Center peut s'effectuer via les scripts rootadmin et rmi_status ou l'interface graphique. WebSphere Product Center ne possède pas d'outil de contrôle autonome.
La création de l'outil de contrôle n'est pas abordée dans ce document ; cependant, plusieurs idées simples peuvent être mentionnées :
- Créer un hôte virtuel sur un serveur d'applications, voire sur un serveur de contrôle distinct. Les scripts rmi_status et rootadmin.sh créant une charge sur le système, l'utilisation d'un serveur de contrôle distinct peut être plus appropriée pour de nombreux environnements.
- Utiliser un langage de script tel que Perl pour créer un encapsuleur CGI pour le script rootadmin.sh qui contrôle et affiche le statut des services.
- Créer un alias dans le serveur Web pointant vers $TOP/logs pour une navigation facilitée dans les fichiers journaux.
- Créer un utilitaire analysant les journaux de $TOP/logs pour y trouver des exceptions et des erreurs, ainsi que pour y vérifier facultativement le statut des services. Cet utilitaire peut envoyer des e-mail ou informer de toute autre manière l'administrateur en cas d'erreurs. Exécutez cet utilitaire en dehors de cron.
Pour obtenir le statut court d'un service, fournissez les paramètres suivants :
-cmd=check -svc=<nom du service>
Le statut court renvoie l'une des conditions suivantes :
en cours d'exécution Le service est en cours d'exécution et répond à une fonction de "signal de présence". introuvable Le service est introuvable. Il n'est peut-être pas en cours d'exécution ou a connu une défaillance. détecté mais ne répond pas Le service a été détecté car il est inscrit dans le registre RMI, mais il ne répond pas à la fonction de "signal de présence". Le service doit éventuellement être redémarré.
Pour obtenir le statut long d'un service, spécifiez les paramètres suivants dans le script rootadmin.sh :
-cmd=status -svc=<nom du service>
Un fichier HTML consultable via un navigateur est alors créé. Sur un terminal, utilisez Lynx (ou un outil similaire) pour formater la sortie.
Le statut fournit une vue d'ensemble des différentes unités d'exécution du service, ainsi qu'un statut des connexions de base de données actuellement utilisées par le service.
Exemple :
Pour obtenir le statut du planificateur :
rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx /tmp/sch_status.html
ou
rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx -dump /tmp/sch_status.html
Remarque : Le symbole ">" utilisé dans l'exemple ci-dessus dirige les détails du statut vers un emplacement de sortie de fichier.
La base de données relationnelle constituant la zone de stockage principale d'une grande partie des informations produit, il est important d'y effectuer des actions de gestion empêchant toute dégradation et perte de performances.
Les alertes de configuration peuvent fournir des informations sur des problèmes susceptibles de survenir et pouvant être résolus avant qu'il ne soit trop tard. Un système de contrôle doit être également installé pour contrôler en permanence la base de données de WebSphere Product Center.
Les tâches suivantes doivent être effectuées régulièrement.
- Allocation d'espace supplémentaire en cas de nécessité
- Application de groupes de correctifs en cas de nécessité
- Démarrage et arrêt du gestionnaire de bases de données, de la base de données et d'autres services en cas de nécessité
- Analyse du schéma de la base de données et collecte des statistiques en cas de nécessité pour obtenir des performances optimales
- Réorganisation des tables et des index à intervalles réguliers pour obtenir des performances optimales
- Vérification du statut des travaux de sauvegarde planifiés
- Restauration et récupération de la base de données si nécessaire
- Réglage des performances de la base de données
1. Allocation d'espace supplémentaire en cas de nécessité
La gestion de l'espace est une tâche permanente pour la plupart d'entre vous. A moins que vous ne disposiez d'une base de données totalement statique, la taille des tables et des index fluctuera régulièrement. Vous devez vous assurer de disposer de suffisamment d'espace pour que le traitement s'effectue sans interruption. Vous devez également vous assurer de l'utilisation efficace de l'espace. Vous pouvez utiliser le Centre de contrôle DB2 pour allouer de l'espace lorsque cela est nécessaire. Vous pouvez également le faire via l'interface de ligne de commande.
2. Application de groupes de correctifs
Les groupes de correctifs sont des mécanismes du système de base de données du fournisseur permettant de disposer régulièrement de correctifs de produits intégrés et totalement testés. Ils ne corrigent que les bogues ; ils n'intègrent pas de nouvelles fonctionnalités et ne nécessitent pas de certification sur le système cible. Il est très important d'utiliser les groupes de correctifs disponibles afin d'éviter tout risque connu avec le système de base de données. Pour plus d'informations sur les correctifs, contactez le fournisseur du système de base de données.
3. Démarrage et arrêt du gestionnaire de la base de données et de la base de données
Il est nécessaire d'arrêter le gestionnaire de bases de données / la base de données dans le cadre de l'application des correctifs, du déplacement des bases de données entre serveurs, etc. Vous devrez démarrer / arrêter la base de données si besoin est.
4. Analyse du schéma de la base de données et collecte des statistiques
Le schéma de la base de données est analysé pour collecter les dernières statistiques sur les tables et les index dans la base de données. La méthode d'optimisation basée sur le coût utilise les statistiques pour estimer le coût de chaque exécution. Collectez ces statistiques régulièrement afin de fournir à l'optimiseur les meilleurs informations sur les objets du schéma. Par exemple, collectez de nouvelles statistiques pour la table après avoir chargé un nombre important de lignes dans une table.
Pour analyser le schéma de la base de données, exécutez le script de shell analyze_schema.sh, dont le chemin d'accès est $TOP/src/db/schema/util.
5. Réorganisation des tables et des index
Il est recommandé de réorganiser régulièrement les tables et les index pour obtenir des performances optimales
Les bases de données modernes se développant de plus en plus rapidement, l'administrateur de base de données typique doit s'employer longuement à gérer et réorganiser l'espace pour obtenir des performances optimales.
Par performances optimales, on entend temps de réponse optimum. Ce temps de réponse peut cependant se dégrader en raison de plusieurs problèmes de gestion de l'espace. La plupart de ces problèmes se répartissent en trois domaines : problèmes liés à la table, index stagnants et équilibrage et partition de données d'E/S
Les administrateurs de base de données connaissent bien les problèmes liés à la table. Il peut s'agir de l'espace sous-utilisé dans les blocs de tables, des lignes chaînées, de la médiocre proximité des données et des tables fragmentées (surétendues).
Les index stagnants (¾ index de taille importante et renseignés de façon éparse) constituent le deuxième problème majeur de performances.
Ce problème peut dégrader sérieusement les performances des analyses d'index. Il peut également provoquer l'occupation d'un espace disque substantiel.
Le troisième problème de performances est lié à l'équilibrage et à la partition de données d'E/S. Lorsque des objets fréquemment utilisés résident dans les mêmes fichiers de données, des goulots d'étranglement d'E/S peuvent survenir. Des outils, tels que reorgchk dans DB2, vous fourniront des informations sur les objets à réorganiser. Plusieurs méthodes et outils sont disponibles pour réorganiser les objets de base de données. Pour obtenir des informations sur la réorganisation des tables et des index, reportez-vous à la documentation spécifique du fournisseur du système de bases de données.
6. Vérification du statut des travaux de sauvegarde planifiés
Les sauvegardes font partie intégrante du processus de restauration et de récupération. Vérifiez le statut de tous les travaux de sauvegarde afin de vous assurer de la planification de leur exécution.
La vérification du statut de sauvegarde dépend de la définition de la procédure de la sauvegarde et des outils utilisés dans le cadre de cette opération. Pour plus d'informations sur les sauvegardes, reportez-vous à la documentation spécifique du fournisseur du système de bases de données.
7. Restauration et récupération de la base de données
En cas de défaillance de la base de données, déterminez le type et l'étendue de la défaillance. L'analyse doit vous permettre de déterminer les étapes nécessaires à la récupération du système. Utilisez le processus de restauration et de récupération défini par votre groupe d'assistance informatique.
Une fois restaurée, la sauvegarde est reconstruite et disponible dans le serveur de base de données. Pour récupérer un fichier de données restauré, vous devez utiliser des enregistrements de rétablissement, c'est-à-dire des enregistrements de modifications apportées à la base de données après que la sauvegarde a été effectuée.
8. Ajustement des performances de la base de données
L'une des responsabilités principales de l'administrateur de base de données consiste à s'assurer que la base de données est correctement ajustée. Les systèmes de gestion de base de données relationnelle sont ajustables et permettent de contrôler et d'ajuster les bases de données afin d'optimiser leurs performances.
Un ajustement des performances doit être effectué pour les raisons suivantes :
- La vitesse de traitement peut faire perdre un temps précieux aux utilisateurs (utilisateurs en attente de réponse) ;
- Permettre à votre système de répondre rapidement aux besoins du marché ; et
Optimisez l'utilisation du matériel afin d'économiser de l'argent (les sociétés dépensent des millions en matériel).
Pour plus d'informations sur les différentes méthodes d'ajustement des performances de la base de données, reportez-vous à la documentation du produit fournie avec DB2.
Il est recommandé de disposer d'un espace disque de 30-50 Go utilisé pour les partitions du logiciel intermédiaire et les partitions temporaires de WebSphere Product Center.
- Partition du logiciel intermédiaire de WebSphere Product Center : 30 Go sont recommandés. La taille du logiciel intermédiaire est d'environ 65-70 Mo.
- Partition temporaire : espace disque utilisable de 2-4 Go (la partition est utilisée pour conserver des fichiers de travaux temporaires importants qui sont créés, puis supprimés)
Dans une configuration en clusters, le stockage partagé est nécessaire pour les serveurs d'applications. Les fichiers HTML et image statiques peuvent être synchronisés via un utilitaire tel que rsync. Cependant, le stockage partagé est également recommandé pour les serveurs Web.
En ce qui concerne les serveurs d'applications, $TOP, le répertoire ftp et la racine du document du serveur Web (emplacement des fichiers HTML et image statiques) se trouvent généralement sur le périphérique partagé, tandis que les applications de prise en charge telles que Apache, JDK et le serveur d'applications sont stockées localement. Les journaux peuvent être stockés localement ou sur un périphérique partagé. Le répertoire temporaire spécifié dans common.properties doit être local.
Fichiers temporaires
Les répertoires suivants contiennent des fichiers temporaires générés lors de l'exécution. Ils se trouvent dans le système de fichiers :
Remarque : les répertoires de fichiers temporaires peuvent varier en fonction de la version de WebSphere Product Center installée.
$TOP/public_html/created_files/distributor
- Objectif : en ce qui concerne les distributions ftp sortantes, le gestionnaire de files d'attente télécharge un document de la base de données vers ce répertoire, puis envoie le fichier à sa destination via le protocole ftp
- Durée de vie : l'administrateur système doit supprimer tous les fichiers de ce répertoire à chaque arrêt d'applications planifiées. Triez tous les fichiers par date et supprimez tous ceux antérieurs à la période de roulement établie par la société pour les fichiers de ce répertoire. Une période de roulement de 7 jours est recommandée.
Exemple d'utilisation avec Linux
cd $TOP/public_html/created_files/distributor
find . -type f -mtime +7 -exec ls -l {} \; <-- pour afficher les fichiers à supprimer
find . -type f -mtime +7 -exec rm -f {} \; <-- pour supprimer les fichiers.
$TOP/public_html/suppliers/company code/aggregated_files/
- Objectif : les fichiers d'importation / d'exportation téléchargés qui sont extraits via une extraction ftp sont placés dans ce répertoire.
- Durée de vie : ne supprimez pas ce répertoire à partir du fichier système, mais plutôt à partir de l'interface graphique de WebSphere Product Center, si nécessaire.
$TOP/public_html/suppliers/company code/tmp_files:
- Objectif : ce répertoire contient les fichiers de travail temporaires.
- Durée de vie : il est recommandé d'enregistrer les fichiers dans ce répertoire pendant quelques semaines, puis de les supprimer à intervalles réguliers. Si vous le souhaitez, supprimez les fichiers automatiquement au redémarrage de WebSphere Product Center ou dans le cadre d'un planning défini (par exemple, fichiers datant de plus de deux semaines).
$TOP/logs
- Objectif : ce répertoire contient les journaux de logiciel intermédiaire de WebSphere Product Center.
- Durée de vie : un espace disque suffisant doit être prévu en fonction du niveau d'erreur (erreur--> débogage). L'administrateur dispose d'un contrôle complet sur la taille de ce répertoire. Il est recommandé de disposer de 2-3 Go d'espace disque si le mode de débogage s'avère nécessaire. Entre 30 et 40 Mo de journaux peuvent être générés en une journée. Vous pouvez décider de les supprimer automatiquement.
L'installation par défaut de WebSphere Product Center est définie dans les serveurs proxy directs, et NON dans les pages de cache. L'autorisation de mise en cache des pages limitera sérieusement la possibilité d'utiliser le bouton de retour du navigateur et produira des messages d'erreur / des pages expirées. Si vous souhaitez autoriser la mise en cache, utilisez les fonctions de navigation de l'interface graphique et évitez d'utiliser le bouton Retour.
Modifiez le fichier : common.properties
Parameter: no_cache_directive=on/offPar défaut, le paramètre est inactif
S'il est actif, les serveurs proxy ne mettront pas en cache les pages et l'utilisation du bouton Retour sera limitée
S'il est inactif, le bouton Retour du navigateur fonctionne et ne génère pas d'erreurs
Les spécifications matérielles doivent être définies selon les meilleures pratiques, l'expérience passée et les spécifications de capacité afin d'obtenir des performances optimales de WebSphere Product Center.
Serveur d'applications
La majorité des objets de données de WebSphere Product Center sont stockées dans le serveur de base de données. En conséquence, le stockage sur disque des serveurs d'applications ne sera utilisée que pour stocker les composants du système d'exploitation, les exécutables de WebSphere Product Center, les composants tiers, les fichiers de travail temporaires de WebSphere Product Center et les journaux de WebSphere Product Center.
Le logiciel intermédiaire de WebSphere Product Center utilise plusieurs composants J2EE, qui peuvent tous occuper une grande quantité de mémoire. WebSphere Product Center recommande de disposer d'un serveur d'applications de 4 Go de mémoire, dont 2,5 Go seraient généralement utilisés pour une instance du logiciel intermédiaire de WebSphere Product Center.
Serveur de base de données
La taille du serveur de base de données dépend de plusieurs facteurs. Il peut s'agir du nombre d'articles de catalogue, du nombre d'attributs associés à chaque article et de la taille des attributs de catalogue.
Par sécurité, il convient d'allouer 8 Ko d'espace à chaque attribut. Par exemple, dans un catalogue de 500 000 articles dont chacun contient 14 attributs, un espace de stockage minimum de 56 Go (500 000 articles x 14 attributs x 8 Ko) est requis.
Cet espace ne tient pas compte de l'espace nécessaire aux fichiers binaires de base de données, aux segments d'annulation, aux espaces table temporaires, etc.
Architecture recommandée
L'option permettant d'utiliser un serveur de planificateurs facultatif pour gérer les transactions en arrière-plan est recommandée si WebSphere Product Center doit gérer d'importants travaux par lots.
Le nom d'utilisateur et le mot de passe de base de données, qui ont été créés lors de l'installation de WebSphere Product Center, sont définis dans common.properties. La modification du mot de passe de l'utilisateur de base de données sans mise à jour du fichier common.properties provoquera une défaillance du logiciel intermédiaire de WebSphere Product Center. Si le mot de passe de l'utilisateur de base de données doit être modifié, assurez-vous de mettre à jour la propriété db_password du fichier common.properties. L'authentification du mot de passe s'effectue au niveau du système d'exploitation dans DB2.
La sauvegarde et la récupération de la base de données constitue l'une des opérations les plus critiques que doit effectuer un administrateur de base de données. En conséquence, il est extrêmement important de mettre en oeuvre une stratégie de sauvegarde et de récupération bien définie. Les stratégies de sauvegarde suivantes sont suggérées afin de maintenir WebSphere Product Center à un niveau de performances optimum.
Sauvegardes physiques
WebSphere Product Center recommande d'effectuer quotidiennement une sauvegarde physique de base de données. Vous pouvez effectuer une sauvegarde physique hors ligne (sauvegarde image) ou en ligne (sauvegarde à chaud) de la base de données, si le système est arrêté ou non. La plupart des bases de données WebSphere Product Center sont accessibles en permanence. Il peut donc ne pas y avoir de temps d'arrêt pour effectuer une sauvegarde hors ligne de la base de données. La base de données doit être exécutée en mode logretain dans DB2 pour pouvoir effectuer une sauvegarde en ligne de la base de données. La sauvegarde en ligne de la base de données vous permet de récupérer celle-ci dans son état défini à un moment donné. Pour plus d'informations, reportez-vous à la documentation du produit DB2.
Sauvegardes logiques
Les sauvegardes logiques stockent des informations sur les objets de schéma d'une base de données. L'utilitaire DB2MOVE de DB2 vous permet d'exporter de façon sélective les objets spécifiques, à des fins de protection supplémentaire et de flexibilité dans une stratégie de sauvegarde de base de données. Les exportations de base de données ne remplacent pas les sauvegardes physiques et ne peuvent pas fournir les mêmes avantages de récupération complète que la sauvegarde physique. Les sauvegardes logiques sont parfois pratiques pour configurer QA ou tester les instances avec les données de production. L'outil de développement WebSphere Product Center DBM dispose également d'instructions spécifiques à WebSphere Product Center sur la sauvegarde logique de schémas de base de données de WebSphere Product Center.
La vérification de l'état de santé du système de base de données à intervalles réguliers est essentielle pour obtenir un système hautement disponible.
Configuration des alertes du centre de contrôle DB2
Le centre de contrôle DB2 permet de contrôler l'état de l'environnement de base de données et d'y apporter les modifications nécessaires, le cas échéant. Le moniteur d'état contrôle en permanence un ensemble d'indicateurs d'état. Si la valeur courante d'un indicateur d'état est en dehors de la plage de fonctionnement autorisée, définie par des seuils d'avertissement et d'alarme, le moniteur d'état émet une alerte d'état. DB2 possède un ensemble de valeurs de seuil prédéfinies, qu'il est possible de personnaliser par la suite.
Les tâches suivantes sont disponibles dans le Centre d'état :
Affichage du statut de l'environnement de base de données.
Affichage des alertes d'une instance ou d'une base de données
Affichage détaillé des informations d'une alerte et actions recommandées.
Configuration des paramètres du moniteur d'état pour un objet spécifique et paramètres par défaut d'un type d'objet ou de tous les objets d'une instance.
Sélection des contacts qui seront informés de l'alerte par e-mail ou téléappel.
Révision de l'historique des alertes d'une instance.
Plusieurs scripts de gestion de base de données sont disponibles pour gérer les bases de données de WebSphere Product Center. Tous ces scripts sont regroupés sous forme d'outil de développement.
Parmi les différentes tâches couvertes par l'outil de développement de DB2, notons :
- l'élimination des données depuis la base de données WebSphere Product Center ;
- l'analyse du schéma de WebSphere Product Center et collecte des statistiques ;
- la sauvegarde logique du schéma de WebSphere Product Center ;
- la collecte des détails de configuration de la base de données de WebSphere Product Center à l'aide de sysinfo.sql.
Le magasin de documents est la zone de WebSphere Product Center où chaque fichier entrant et sortant est stocké. Il peut s'agir des sources d'importation, des scripts, des rapports et des fichiers de spécifications.
La structure de l'interface graphique fournit des hyperliens permettant d'accéder à des fichiers stockés dans la base de données. Il s'agit essentiellement d'éléments pointant vers l'emplacement des fichiers.
Répertoires
Le magasin de documents s'affiche sous forme d'une structure de fichiers. Les fichiers sont accessibles à partir des répertoires Magasin de documents suivants :
archives
html_public
processeur_événements
journaux_planning
fichiers_source
scripts
ftp
tmp
params
utilisateurs
Ftp et html_public sont des répertoires de système de fichiers situés dans le magasin de documents. Ils sont définis dans $TOP/etc/docstore_mount.xml. Ce fichier fournit l'emplacement de différents points d'installation du système de fichiers du système d'exploitation.
Les variables utilisées sont "$ftp_root_dir" et "$supplier_base_dir". Elles sont définies dans le fichier de configuration common.properties.
Architecture
La base de données possède un espace table désigné pour les fichiers stockés dans le magasin de documents. Lorsqu'un fichier est stocké dans le magasin de documents, un nouvel enregistrement est inséré dans la base de données. La base de données stocke le fichier sous forme de fichier BLOB (Binary Large Object - Objet binaire de grande taille).
Un fichier BLOB se réfère aux grands blocs d'octets devant être stockés dans une base de données. Par exemple, il peut s'agit d'un fichier image ou son. Un fichier BLOB est un objet qui ne peut pas être interprété dans la base de données.
La base de données stocke les fichiers BLOB dans un espace table de la base de données. L'avantage de cette méthode est que la base de données protège les données grâce aux mécanismes de serveur de base de données qui protègent tous les autres types de données de table, tels que les mécanismes de sauvegarde/récupération et de sécurité.
Gestion de l'espace table
La gestion de l'espace est une tâche permanente. La taille du magasin de documents est vouée à fluctuer. Assurez-vous qu'un espace suffisant est disponible pour prendre en charge les fichiers binaires sans interrompre le traitement permanent. En outre, assurez-vous que l'espace est utilisé de manière efficace.
Suppression de fichiers
Lorsque WebSphere Product Center supprime un fichier BLOB et les références correspondantes, le moteur de base de données ne libère pas l'espace alloué, mais l'attribue à de nouveaux fichiers.
En conséquence, chaque fichier est stocké dans un bloc mémoire. Une fois le fichier supprimé, le bloc mémoire est réutilisé dès que de nouveaux fichiers sont ajoutés.
Opération GZIP facultative sur les BLOB
Pour compresser les documents stockés dans les fichiers BLOB, procédez comme suit :
Fichier à modifier : common.properties
Paramètre : gzip_blobs=true/false
- Les valeurs correctes sont 'true' et 'false'
- Si ces valeurs sont absentes, la valeur par défaut est définie sur 'false'
- Si la valeur par défaut est définie sur 'true', les documents stockés dans les fichiers BLOB sont compressés
Défragmentation
Les multiples additions et suppressions de fichiers dans le magasin de documents provoquent la fragmentation des blocs mémoire. La fragmentation survient naturellement lorsque vous utilisez fréquemment un disque pour créer, supprimer et modifier des fichiers.
A un certain stade, le système d'exploitation doit stocker les parties d'un fichier dans des clusters non contigus. Cette opération est totalement invisible aux yeux des utilisateurs. Cela peut néanmoins ralentir la vitesse d'accès aux données car le lecteur de disque doit rechercher dans les différentes sections du disque les parties du fichier à regrouper
Pour optimiser les performances du magasin de documents, il est plus judicieux d'exporter, puis d'importer la table DBL à l'aide de compress=y. Cela permet de trancher tous les fichiers dans un cluster continu et, par conséquent, d'améliorer le temps d'exportation des fichiers.
Remarque : selon l'allocation de l'espace table, il peut ne pas être nécessaire d'effectuer l'opération de défragmentation régulièrement. Contrôlez la vitesse du disque régulièrement pour déterminer si la défragmentation de l'espace disque est nécessaire.
Foire aux questions sur le magasin de documents
Problème : une fois les fichiers BLOB supprimés, la vitesse de WebSphere Product Center est-elle toujours affectée ?
Non. Une fois les lignes supprimées, la vitesse s'améliore.
Problème : l'espace alloué génère-t-il toujours des exportations/importations lentes ?
Oui. La seule solution est d'exporter, puis d'importer la table DBL à l'aide de compress=y.
La méthode et le logiciel de sauvegarde employés ne sont pas abordés dans ce document ; cependant, les concepts de sauvegarde vous sont présentés ci-après.
La sauvegarde de WebSphere Product Center se compose en deux points : la sauvegarde des répertoires du système de fichiers à l'emplacement d'installation de WebSphere Product Center et la sauvegarde de la base de données.
Sauvegarde de WebSphere Product Center
Pour sauvegarder WebSphere Product Center, il vous suffit de sauvegarder le répertoire $TOP défini dans common.properties. Les fichiers étant modifiés en permanence dans ces répertoires, nous vous recommandons d'effectuer des sauvegardes quotidiennes. L'institution d'un planning de sauvegarde, composé d'une sauvegarde intégrale régulière et d'une sauvegarde incrémentielle quotidienne, est recommandée.
Sauvegarde de base de données
La méthode de sauvegarde de la base de données n'est pas abordée dans ce document, en raison particulièrement du nombre de méthodes disponibles : exportations, sauvegardes à chaud, sauvegardes à froid, fonction miroir, etc. Quelle que soit la méthode choisie, le schéma de l'utilisateur de la base de données WebSphere Product, défini dans common.properties, constitue tout ce qui doit être sauvegardé.
La base de données devant rester exécutable par WebSphere Product Center, il est recommandé d'effectuer quotidiennement une sauvegarde en ligne ou 'à chaud'. Les exportations ou sauvegardes hors ligne doivent également être effectuées régulièrement.
Pour plus d'informations sur les sauvegardes de bases de données, reportez-vous à "Sauvegarde de base de données".
Récupération
La récupération peut être répartie en deux catégories : la récupération de WebSphere Product Center et des fichiers de prise en charge et la récupération de la base de données.
Pour récupérer WebSphere Product Center et les fichiers de prise en charge, il vous suffit de restaurer les fichiers ou répertoires manquants à leurs emplacements d'origine, puis de démarrer WebSphere Product Center.
Pour récupérer la base de données, suivez les étapes suivantes :
- Arrêtez le serveurs d'applications
- Arrêtez le logiciel intermédiaire de WebSphere Product Center
- Restaurez le schéma
- Redémarrez le logiciel intermédiaire de WebSphere Product Center
- Démarrez le serveur d'applications
WebSphere Product Center fournit des fichiers préconfigurés générant des journaux, qui peuvent ensuite être utilisés pour identifier les problèmes dans WebSphere Product Center. Ce document fournit une présentation générale du mécanisme de connexion et explique le principe de configuration des fichiers journaux.
Les fichiers suivants contrôlent les différents sous-systèmes de WebSphere Product Center. L'emplacement du journal généré est défini dans chaque fichier.
Remarque : tous les chemins sont liés à $TOP
/etc/logs/processeurévénements.log.xml
/etc/logs/scheduler.log.xml
/etc/logs/system.log.xml
/etc/logs/appsvr.log.xml
/etc/logs/workflowengine.log.xml
Les journaux générés à l'exécution peuvent être affichés pour afficher les erreurs, qui permettent d'identifier si un problème est lié à WebSphere Product Center ou à l'infrastructure de support interne.
Les fichiers journaux générés par WebSphere Product Center sont stockés dans $TOP/logs/*.log.
Les propriétés des fichiers journaux WebSphere Product Center peuvent être modifiées le cas échéant (par exemple, localisation, taille maximale, format). Les sections suivantes décrivent les éléments utilisés pour configurer les journaux et fournir une liste de valeurs utilisables lors de la configuration d'un fichier journal de WebSphere Product Center.
Modification de l'emplacement
Remarque : ne s'applique qu'aux annexes Fichier et Roulement
Pour modifier l'emplacement d'un fichier journal généré, modifiez les paramètres des fichiers de configuration de journal spécifiés.
Par exemple :
<nom_paramètre="File" valeur="${TOP}/logs/webserver_db.log " />
Modification de la taille du fichier
Remarque : ne s'applique qu'aux annexes de roulement
La taille du fichier journal peut être définie à une taille de stockage spécifique avant de commencer le roulement et de supprimer la commande supérieure de sortie. Pour contrôler le début de la troncature du fichier, modifiez la valeur du paramètre de la taille du fichier journal.
Par exemple :
<nom_paramètre="maxFileSize" valeur="10MB" />
Modification de l'option de sauvegarde de fichier
Remarque : ne s'applique qu'aux annexes de roulement
Le journal d'événements peut être défini pour conserver un nombre spécifique de sauvegardes d'un fichier journal. Une fois la valeur maximale atteinte, le fichier le plus ancien est supprimé.
Par exemple :
<nom_paramètre="maxBackupIndex" valeur="2" />
Modification du modèle de conversion
La configuration de la présentation des journaux peut être modifiée en redéfinissant le modèle de conversion.
Par exemple :
<nom_paramètre="ConversionPattern" valeur=
"%d [%t] %-5p %c (%F:%L) %x- %m%n"/>Le modèle de conversion est étroitement lié au modèle de conversion de la fonction printf de C. Un modèle de conversion se compose de texte littéral et d'expressions de contrôle de format nommés spécificateurs de conversion.
Remarque : vous pouvez insérer du texte littéral dans le modèle de conversion.
Chaque spécificateur de conversion démarre par le symbole de pourcentage "%" et est suivi de modificateurs de format facultatifs et d'un caractère de conversion.
% (modificateurs de format)(caractère de conversion)
Par exemple,
%-5p [%t]: %m%n
- Les modificateurs de format contrôlent des paramètres tels que la taille du champ, le remplissage, la justification à gauche et à droite
- Le caractère de conversion définit le type de données (par exemple, catégorie, priorité, date et nom de l'unité d'exécution.)
Par défaut, les informations pertinentes sont sorties en l'état. Cependant, les modificateurs de format permettent de modifier la taille de champ, la taille de champ maximale et la justification.
Le modificateur de format facultatif est placé entre le symbole de pourcentage et le caractère de conversion. Dans l'exemple, le spécificateur de conversion
%-5p signifie que la largeur de justification à gauche de l'événement de journalisation est définie à cinq caractères.Le premier modificateur de format facultatif est la balise de justification à gauche représentée par le caractère moins (-). Il est suivi du modificateur de taille de champ minimale facultatif. Il s'agit d'une constante décimale qui représente le nombre minimum de caractères à sortir. Si l'élément de données nécessite moins de caractères, il est bloqué à gauche ou à droite jusqu'à ce que la taille maximale soit atteinte.
La valeur par défaut consiste à bloquer l'élément de données à gauche (justification à droite). Cependant, vous pouvez spécifier le blocage à droite à l'aide de la balise de justification à gauche. Le caractère de remplissage est l'espace. Si l'élément de données est supérieur à la taille de champ minimale, le champ est développé pour s'adapter aux données. La valeur n'est jamais tronquée.
Ce comportement peut être modifié à l'aide du modificateur taille de champ maximale, désignée par un point suivi d'une constante décimale. Si l'élément de données est plus long que la taille de champ maximale, des caractères sont supprimés au début de l'élément de données, et non à la fin.
Par exemple, si la taille de champ maximale est de huit et que l'élément de données contient dix caractères, les deux premiers caractères de l'élément de données sont supprimés.
Remarque : ce comportement diffère de celui de la fonction printf de C, où la troncature s'effectue par la fin.
Les pages suivantes fournissent les valeurs utilisées pour définir les spécificateurs de conversion.
La section ci-après contient différents exemples de modificateur de format du spécificateur de conversion de catégorie.
Modificateur de format
Justification à gauche
Taille
min
Taille max
Commentaire
%20c
Faux
20
Aucune
Remplissez d'espaces à gauche si le nom de la catégorie est inférieur à 20 caractères.
%-20c
Vrai
20
Aucune
Remplissez d'espaces à droite si le nom de la catégorie est inférieur à 20 caractères.
%30c
NA
Aucune
30
Effectuez une troncature au début si le nom de la catégorie est supérieur à 30 caractères.
%20.30c
Faux
20
30
Remplissez d'espaces à gauche si le nom de la catégorie est inférieur à 20 caractères. Cependant, si le nom de la catégorie est supérieur à 30 caractères, procédez à une troncature au début.
%-20.30c
Vrai
20
30
Remplissez d'espaces à droite si le nom de la catégorie est inférieur à 20 caractères. Cependant, si le nom de la catégorie est supérieur à 30 caractères, procédez à une troncature au début.
Voici une liste de caractères de conversion reconnus :
Caractère de conversion
Effet
c
Utilisé pour sortir la catégorie de l'événement de journalisation. Un spécificateur de précision peut facultativement suivre le spécificateur de conversion de catégorie, qui est une constante décimale entre crochets.
Si un spécificateur de précision est fourni, seul le numéro correspondant aux composants situés à l'extrême droite du nom de la catégorie sont est imprimé. Par défaut, le nom de la catégorie est imprimé totalement.
Par exemple, pour le nom de catégorie "a.b.c" le modèle %c{2} sort "b.c".
d
Utilisé pour sortir la date de l'événement de journalisation. Un spécificateur de format de date entre accolades peut suivre le spécificateur de conversion de date.
Par exemple, %d{HH:mm:ss,SSS} ou %d{jj MMM aaaa HH:mm:ss,SSS}. Si aucun spécificateur de format de données n'est fourni, le format ISO8601 est pris en compte.
Le spécificateur de format de date admet la même syntaxe que la chaîne de caractères temporelle de FormatDateSimple. Bien que faisant partie de la norme JDK, les performances de FormatDateSimple sont relativement médiocres.
Pour des résultats optimaux, nous vous recommandons d'utiliser les composants de formatage log4j. Vous pouvez spécifier respectivement FormatDateHeureAbsolu, FormatDateHeureDate et FormatDateISO8601 via l'une des chaînes "ABSOLUTE", "DATE" et "ISO8601". Par exemple, %d{ISO8601} ou %d{ABSOLU}.
Ces composants de formatage de date dédiés fonctionnent significativement mieux que FormatDateSimple.
m
Utilisé pour sortir le message de WebSphere Product Center associé à l'événement de journalisation.
n
Sort le caractère/les caractères de séparateur de ligne dépendant de la plateforme.
Ce caractère de conversion fournit pratiquement les mêmes performances que des chaînes de séparateur de ligne non portables, telles que "\n", ou "\r\n". Par conséquent, il s'agit de la méthode de spécification de séparateur de ligne à privilégier.
p
Utilisé pour sortir la priorité de l'événement de journalisation.
r
Utilisé pour sortir le temps écoulé en millisecondes du démarrage de WebSphere Product Center à la création de l'événement de journalisation.
t
Utilisé pour sortir le nom de l'unité d'exécution qui a généré l'événement de journalisation.
x
Utilisé pour sortir le Contexte de diagnostic imbriqué associé à l'unité d'exécution qui a généré l'événement de journalisation.
%
La séquence %% sort un symbole de pourcentage unique.
Les exemples suivants présentent la définition des fichiers journaux de WebSphere Product Center. Les entrées en gras définissent la configuration des fichiers journaux de WebSphere Product Center.
<!-- annexe ASYNC de base -->
<nom_annexe="ASYNC" class="org.apache.log4j.AsyncAppender">
<appender-ref ref="DEFAULT"/>
</appender>
<!-- annexe CONSOLE de base. Identique à system.out-->
<nom_annexe="STDOUT" class="org.apache.log4j.ConsoleAppender">
<classe_présentation="org.apache.log4j.PatternLayout">
<nom_paramètre="ConversionPattern" valeur="[%t] %-5p %c (%F:%L) %x- %m%n"/>
</présentation>
</appender>
<!-- Annexe FICHIER simple. Le fichier est ouvert et si l'annexe est vraie -->
<!-- il ne sera pas tronqué -->
<nom_annexe="DEFAULT" class="org.apache.log4j.FileAppender">
<nom_paramètre="File" valeur="${TOP}/logs/tomcat_default.log " />
<nom_paramètre="Append" valeur="true" />
<classe_présentation="org.apache.log4j.PatternLayout">
<nom_paramètre="ConversionPattern" valeur="%d [%t] %-5p %c (%F:%L) %x- %m%n"/>
</présentation>
</appender>
<!-- Annexe FILE de roulement. Le fichier est ouvert et si l'annexe est vraie -->
<!-- il ne sera pas tronqué -->
<!-- maxFileSize : Taille maximale de fichier avant de procéder à la rotation -->
<!-- maxBackupIndex : Nombre de sauvegardes à conserver ? -->
<nom_annexe="DB" class="org.apache.log4j.RollingFileAppender">
<nom_paramètre="File" valeur="${TOP}/logs/tomcat_db.log " />
<nom_paramètre="Append" valeur="true" />
<param name="maxFileSize" value="10MB" />
<nom_paramètre="maxBackupIndex" valeur="2" />
<classe_présentation="org.apache.log4j.PatternLayout">
<nom_paramètre="ConversionPattern" valeur="%d [%t] %-5p %c (%F:%L) %x- %m%n"/>
</présentation>
</appender>
<!-- En ce qui concerne la catégorie austin.db, vous souhaitez ne conserver que quelques journaux, donc -->
<!-- the rollingappender -->
<nom_catégorie="austin.db" additivité=" false">
<valeur_priorité="INFO" />
<appender-ref ref="DB" />
</catégorie>
<!-- CATEGORIE DE RACINE -->
<!-- DOIT TOUJOURS ETRE LA DERNIERE ENTREE ET POSSEDER UNE ANNEXE-->
<!-- Si un événement de journalisation n'est pas intercepté par un autre journal d'événements, il est géré par cette-->
<!-- règle. -->
<root>
<valeur_priorité="error"/>
<appender-ref ref="DEFAULT"/>
</root>
</log4j:configuration>
La fonctionnalité de vérificateur orthographique de WebSphere Product Center est rendue disponible grâce à l'infrastructure du produit tiers "Sentry Spell Checking Engine" de WinterTree. Pour cette raison, WebSphere Product Center n'est pas livré avec une fonctionnalité de vérificateur orthographique ; l'acquisition du logiciel Spelling Service Engine version 5.10 de WinterTree est nécessaire à l'activation de la vérification orthographique.
Avec l'activation de la vérification orthographique dans cette version, les utilisateurs peuvent uniquement vérifier l'orthographe dans les écrans de détails des articles et de modification unique de Content Authoring. La prise en charge de la vérification orthographique dans les écrans de modifications multiples ou globales sera disponible dans une prochaine version.
Le présent document décrit la configuration nécessaire à l'interaction de WebSphere Product Center avec le logiciel Spelling Service Engine version 5.10 de WinterTree.
Pour configurer WebSphere Product Center de manière à exécuter le vérificateur orthographique de WinterTree, trois fichiers de propriété doivent être modifiés :
REMARQUE : Après la modification de tous les fichiers de propriété, redémarrez WebSphere Product Center pour valider les paramètres de configuration du vérificateur orthographique.
common.properties
Emplacement : <WPC5.2_INSTALL_DIR>/etc/default/common.properties file
Valeurs : Modifiez le fichier common.properties de manière à ce qu'il inclue les valeurs de propriétés suivantes :
spell_check=true (Cette opération active le vérificateur orthographique)
spell_check_vendor=wintertree (Cette opération confirme l'origine du vérificateur orthographique)
spell_check_vendor_class=common.plugins.wintertree.WinterTreePlugin (Cette opération définit le
plugin pour Wintertree SSCE)
spell_license=<license_key> (la clé de la valeur de la clé de licence du
logiciel de vérificateur orthographique acquis (version 5.10) de WinterTree dans la
propriété <license_key)
spellservice.properties
Emplacement : <WPC5.2_INSTALL_DIR>/etc/default/plugins/wintertree/spellservice.properties file
Valeurs : Remplacez chaque occurrence de <WINTERTREE_INSTALL_DIR> dans les propriétés <n> de MainLexicon par l'emplacement du logiciel WinterTree Spelling Engine Software sur votre système. Cette opération configure les lexiques et dictionnaires, ainsi que les propriétés d'exécution du vérificateur orthographique.
ccd.rc
Emplacement : <WPC5.2_INSTALL_DIR>/setup/ccd.rc file
Créez un lien symbolique vers le fichier jar WinterTree nommé ssce.jar dans <WINTERTREE_INSTALL_DIR>/runtime/lib de<WPC_INSTALL_DIR>/jars/ssce.jar.
Cette opération peut être effectuée par l'ajout de la ligne sans commentaire, tel que dans l'exemple
ci-dessous, à ce fichier.
Par exemple :
- AddJar $JARDIR/ssce.jar
L'intégration LDAP (Lightweight Directory Access Protocol) améliore l'infrastructure de sécurité de WebSphere Product Center grâce à l'introduction de trois points de fonction dans WebSphere Product Center :
L'intégration LDAP permet d'utiliser des systèmes LDAP tiers à des fins d'authentification. Etant donné la complexité impliquée par l'utilisation des fonctionnalités LDAP
tiers pour l'autorisation, l'infrastructure d'autorisation existante
disponible dans WebSphere Product Center 5.2 est utilisée pour autoriser les utilisateurs LDAP
alors que l'authentification se situe dans LDAP. Les droits des utilisateurs et rôles
LDAP dans WPC sont en cours d'exécution et basés sur
les opérations de script appelées utilisateur/système. L'utilisateur LDAP de WebSphere Product Center
est différencié grâce à un indicateur LDAP.
L'intégration de LDAP à WebSphere Product Center fournit une infrastructure
d'authentification de sécurité améliorée permettant la prise en charge de plus de 1000
utilisateurs fréquents qui nécessitent une autorisation pour plusieurs rôles (internes et externes).
Par exemple, un gestionnaire produits a un rôle interne et un assistant chef de marques a un rôle externe.
Pour WebSphere Product Center 5.2, l'intégration LDAP est uniquement certifiée avec IBM
Tivoli Directory Server version 5.2 (prenant en charge LDAP v3). Cependant,
la mise en oeuvre permet une interaction avec les serveurs LDAP suivants : Sun
Java System Directory Server 5.2, Weblogic 8.1 – Serveur LDAP incorporé et
Novell® eDirectory™ 8.7.3.
Remarque : Il n'existe aucune prise en charge des fonctionnalités Single Sign dans cette version.
La mise en oeuvre Single sign est prévue pour une prochaine version.
Si un utilisateur est authentifié dans une session, il restera authentifié jusqu'à la fin de la session, même si son identité change pendant cette période (par exemple s'il modifie son rôle, son mot de passe, etc).
L'extraction de chaîne spécifique de valeur locale dans les recherches d'entrées LDAP n'a pas été certifiée pour cette version.
Il y a une modification dans l'entité WPC USER ENTITY suite à l'introduction du nouvel indicateur LDAP FLAG pour différencier les utilisateurs LDAP des utilisateurs WPC.
Cette section décrit les tâches à effectuer pour intégrer LDAP for IBM Tivoli Directory Server Version 5.2 à WebSphere Product Center 5.2. IBM Tivoli Directory Server Version 5.2 doit avoir été correctement installé. La configuration de LDAP nécessite un schéma LDAP configuré pour les utilisateurs et les rôles de IBM Tivoli Directory Server Version 5.2.
Pour intégrer LDAP à WebSphere Product Center, veuillez effectuer les opérations suivantes :
1. Configurez le schéma LDAP pour les utilisateurs et les rôles
2. Modifiez le fichier de configuration LDAP
3. Redémarrez WebSphere Product Center
Création d'un nouveau domaine
1. Créez un nouveau domaine depuis l'outil d'administration d'IBM Tivoli Directory Server Web en sélectionnant Realms and Templates > Add Realm.
2. Complétez toutes les zones nécessaires.
3. Sélectionnez le domaine de classe d'objet en DN parent.
Par exemple :
DN Relatif DN Parent
cn=mondomaine dc=wpcdomain.dc=isl.dc=com
Création d'un modèle de nouvel utilisateur
1. Créez un modèle de nouvel utilisateur à partir d'IBM Tivoli Directory Server Web Administration Tool en cliquant sur Realms and Templates Add User Template.
2. Clé dans l'entrée de domaine créée ci-dessus en DN Parent. Sélectionnez la classe d'objet structurelle en inetOrgPerson.
3. Modifiez l'onglet d'attribut de manière à inclure la liste complète suivante d'attributs obligatoires :
- Cn
- Sn
- Uid (Il s'agit de l'attribut de nom)
- TelephoneNumber
- TelexNumber
- postalAddress
4. Associez ce modèle d'utilisateur au domaine créé ci-dessus au moyen du chemin de menu Realms and Templates > Manage Realms > Edit.
Par exemple :
DN Parent
dc=wpcdomain,dc=isl,dc=com
cn=monmodele, dc=wpcdomain,dc=isl,dc=com
Création d'un nouvel utilisateur1. Créez un nouvel utilisateur à partir de l'outil d'administration Web d'IBM Tivoli Directory Server en sélectionnant Utilisateurs et groupes > Ajouter utilisateur.
2. Sélectionnez le domaine créé ci-dessus en domaine pour cet utilisateur.
3. Entrez l'onglet d'attribut "Obligatoire" pour inclure tous les attributs mentionnés ci-dessus.
Création d'un nouveau groupe
1. Créez un nouveau groupe à partir de l'outil d'administration d'IBM Tivoli Directory Server en sélectionnant Utilisateurs et groupes > Ajouter groupe.
2. Sélectionnez le domaine que vous venez de créer en domaine pour ce groupe. La classe d'objets de ce groupe est groupOfNames.
3. Associez les utilisateurs aux groupes.
Le fichier de configuration LDAP suivant est nécessaire à l'intégration à WebSphere Product Center :
<REP_INSTALL_WPC5.2>/etc/default/ldap_config.xml
Modifiez le fichier ldap_config.xml pour l'authentification LDAP en remplaçant les valeurs entre parenthèses par les valeurs appropriées de l'installation LDAP.
<?xml version="1.0" encoding="UTF-8"?>
<LdapConfiguration>
<connectionInfo>
<connectionParam name = "java.naming.provider.url"> (Entrez l'URL serveur LDAP)</connectionParam>
<connectionParam name = "java.naming.security.principal">(Entrez le nom d'utilisateur pour la connexion au serveur LDAP)</connectionParam>
<connectionParam name = "java.naming.security.credentials">(Entrez le mot de passe pour la connexion au serveur LDAP)</connectionParam>
<connectionParam name = "java.naming.security.authentication">simple</connectionParam>
<connectionParam name = "java.naming.referral">follow</connectionParam>
<connectionParam name = "java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</connectionParam>
<connectionParam name = "java.naming.ldap.version">3</connectionParam>
</connectionInfo>
<RoleMapping>
<Object name = "Role class">groupOfNames</Object>
</RoleMapping>
<WPCUserCredentialMappings ParentDN="(Entrez le DN de base pour les objets utilisateur)" ObjectClass="inetOrgPerson">
Dans l'exemple, le DN de base est : cn=myrealm,dc=wpcdomain,dc=isl,dc=com
<WPCUserParam name = "UserName">uid</WPCUserParam>
<WPCUserParam name = "FirstName">cn</WPCUserParam> >
<WPCUserParam name = "LastName">sn</WPCUserParam> >
<WPCUserParam name = "Email">mail</WPCUserParam> >
<WPCUserParam name = "Address">postalAddress</WPCUserParam> >
<WPCUserParam name = "Phone">telephoneNumber </WPCUserParam>
<WPCUserParam name = "Fax"> TelexNumber</WPCUserParam> >
</WPCUserCredentialMappings>
</LdapConfiguration>
Après avoir configuré les schémas LDAP pour les rôles et utilisateurs et avoir modifié le fichier de configuration LDAP, redémarrez WebSphere Product Center.
- Analyse des fichiers journaux
- netstat
- ps
- kill
- svrmgrl ou sqlplus
- telnet
- jar
- tar
- gunzip
- L'accès en tant que superutilisateur au Web et aux serveurs d'applications est souvent essentiel
Problèmes d'environnement
Avant de démarrer WebSphere Product Center, les variables d'environnement suivantes doivent être configurées pour le pseudo-utilisateur sur le serveur d'applications :
- TOP : le répertoire supérieur de WebSphere Product Center
- DB2_HOME : nécessaire pour les fichiers binaires client DB2
- JAVA_HOME : nécessaire pour JDK
- PATH : doit inclure $DB2_HOME/bin et si possible $JAVA_HOME/bin
De plus, avant de démarrer WebSphere Product Center, le script de shell init_ccd_vars.sh doit être approvisionné. Cela s'effectue généralement dans le fichier .bashrc de l'utilisateur.
La variable d'environnement CLASSPATH ne doit pas être modifiée après que init_ccd_vars.sh a été approvisionné.
Paramètres de fichiers de configuration communs incorrects
- common.properties
L'erreur la plus fréquente est un spécificateur de base de données incorrect dans common.properties. Une base de données incorrectement configurée présente les symptômes suivants :
vrapp, processeurévénements, gestionnairefilesattente, planificateur et moteurfluxtravaux ne démarrent pas
Erreurs dans les fichiers journaux logs/db_pool et logs/svc/
smtp_address. Smtp_address doit pointer vers un relais SMTP, soit l'envoi d'e-mail sur l'hôte local, soit un autre système capable d'envoyer des e-mail en dehors de l'organisation.
- Fichier de licence
Aucun service ne démarre si le fichier de licence (WPC_license.xml) est absent ou incorrect. Cette erreur est reflétée dans les fichiers journaux sous logs/svc
Serveur d'applications sans réponse
Scénario
Le serveur d'applications répond difficilement. Bien qu'il soit possible d'exécuter une commande ping sur le serveur, les utilisateurs et l'administrateur ne peuvent pas se connecter respectivement à l'environnement et au serveur d'applications
Eléments à surveiller :
Vérifiez si un utilisateur a récemment lancé un travail inhabituellement volumineux. Si le travail était intentionnel, vérifiez le script utilisé par le travail.
1. Conversion de caractères lors d'exportations/importations
2. Problèmes d'allocation d'espace de base de données
3. Problèmes de corruption de blocs de données et d'index
4. Arrêt de l'importation ou de l'exportation sans modification dans la barre d'état après une longue période
5. L'application devient très lente après l'arrêt d'un travail en cours d'exécution
6. Problèmes de commutation de journaux
7. Le logiciel intermédiaire de WebSphere Product Center s'arrête et l'interface graphique est gelée
8. L'analyse du travail de schéma s'arrête
9. La connexion SQL redémarre automatiquement
1. Conversion de caractères lors d'exportations/importations
Problème
Lors de l'exportation/importation d'une base de données visant à créer des environnement de test à l'aide d'une copie de la base de données, des messages d'erreur relatifs au jeu de caractères utilisé apparaissent.
Symptômes
Par exemple, si une base de données utilisant le jeu de caractères US7ASCII est exportée, le message d'erreur suivant apparaît dans le journal d'exportation :
L'exportation effectuée dans le jeu de caractères US7ASCII et dans le serveur de jeu de caractères UTF8 NCHAR utilise le jeu de caractères UTF8 (conversion de jeu de caractères possible)
Résolution
A chaque exportation/importation de base de données, définissez le paramètre NLS_LANG afin qu'il utilise le jeu de caractères american_america.utf8.
2. Problèmes d'allocation d'espace de base de données
Problème
Occasionnellement, les travaux d'importation et d'exportation échouent en raison d'un espace insuffisant alloué aux tables, index, segments de restauration et segments temporaires.
Symptôme
Si le segment de restauration ou l'espace table du segment de restauration est saturé, un message d'erreur identique au message ci-après s'affiche dans le fichier journal d'alerte :
ORA-1650 : impossible de développer le segment de restauration RBS8 par 512 dans l'espace table RBS
Echec du développement du segment de restauration 9 car le statut SATURE de condition 1650 y est défini.
Résolution
- Assurez-vous que les espaces table disposent de suffisamment d'espace libre. De l'espace supplémentaire peut être nécessaire dans les segments de restauration et les segments temporaires pour les travaux plus importants.
- Vérifiez le fichier journal d'alerte de la base de données chaque jour pour voir si des erreurs liées à des problèmes d'espace sont générées dans la base de données.
3. Ralentissements de WebSphere Product Center une fois un travail en cours d'exécution arrêté
Problème
Chaque fois qu'un travail, tel une importation ou une exportation, est arrêté, le système de base de données doit restaurer la transaction complète pour que la base de données possède un état correct. Ce processus de restauration utilise les ressources système maximales telles que le temps et la mémoire d'unité centrale.
Symptômes
Le logiciel intermédiaire de WebSphere Product Center ralentit une fois un travail en cours d'exécution arrêté.
Résolution
Attendez la fin de la restauration. Le système retrouve alors son état normal. N'arrêtez pas un travail en cours d'exécution, à moins que cela ne soit vraiment nécessaire.
4. Problèmes de commutation des fichiers journaux
Problème
Un nombre/Une taille de fichiers journaux incorrect(e) peut engendrer de l'attente pour une commutation de fichier journal.
Symptômes
Le système de base de données attend un long moment pour une commutation de fichier journal, ainsi que pour vérifier que tous les fichiers de reconstitution de journal sont actifs.
Résolution
- Augmentez le nombre de fichiers journaux
- Augmentez la taille des fichiers journaux
5. Arrêt du logiciel intermédiaire WebSphere Product Center et gel de l'interface graphique
Problème
Si des erreurs surviennent lors de l'accès au logiciel intermédiaire de WebSphere Product Center, la connexion à la base de données a peut-être été perdue.
Symptômes
Le logiciel intermédiaire de WebSphere Product Center est gelé ou en état d'attente permanent. Des erreurs surviennent lors de la tentative d'accès au logiciel intermédiaire de WebSphere Product Center.
Résolution
- Vérifiez le statut du processus de programme d'écoute
- Vérifiez le statut de la base de données chaque fois que la connexion à la base de données ou aux écrans du logiciel intermédiaire de WebSphere Product Center ne peut pas être établie.
6. Arrêt de l'analyse du travail de schéma
Problème
Il est recommandé d'analyser régulièrement le schéma lorsque vous chargez des données volumineuses dans la base de données ou que vous y supprimez des tables.
Avant d'exécuter l'analyse du schéma, le logiciel intermédiaire de WebSphere Product Center doit être arrêté. Si le logiciel intermédiaire n'est pas arrêté, l'analyse du travail de schéma peut se bloquer car les tables sont en cours d'utilisation dans le logiciel intermédiaire.
Symptômes
Arrêt de WebSphere Product Center lors de l'exécution de l'analyse du schéma.
Résolution
Si l'analyse du schéma se bloque, arrêtez l'analyse du travail, arrêtez le logiciel intermédiaire de WebSphere Product Center, redémarrez l'analyse du schéma, puis démarrez WebSphere Product Center.
Analysez régulièrement le schéma afin de collecter les plus récentes statistiques sur la distribution des données dans la base de données.
Le contrôle et la révision des fichiers journaux du système peuvent permettre de diagnostiquer et de résoudre de nombreux problèmes.
Remarque : ce chapitre sera développé dans la prochaine version du document. Des informations supplémentaires sur l'utilisation des fichiers journaux et des techniques d'identification des incidents seront fournies.
Erreurs de transmission de protocole HTTP
Lorsque des erreurs de transmission de protocole http surviennent, tenez compte des éléments suivants :
1. La zone WebSphere Product Center peut-elle voir la destination cible ?
- Utilisez un navigateur Linux/Unix http tel que "Lynx" et entrez l'adresse URL du logiciel intermédiaire de WebSphere Product Center pour vérifier si la cible est accessible.
- Si un navigateur n'est pas disponible dans le serveur WebSphere Product Center, essayez de vous connecter par telnet au port 80 de la destination. Par exemple, si l'adresse URL de destination est http://mon_serveur/>nom_url<, entrez "telnet mon_serveur 80" (le port 80 est le port http par défaut de la plupart des serveurs Web).
2. Si WebSphere Product Center peut voir la destination, le distributeur WebSphere Product Center fonctionne-t-il correctement ?
- Vérifiez si de nouveaux fichiers se trouvent dans $TOP/public_html/created_files/distributor. Vérifiez si des fichiers possèdent l'horodatage approximatif correspondant au moment de l'insertion du fichier.
- Un script ininterrompu peut avoir généré un fichier de sortie incorrect. Vérifiez la taille du fichier. La taille du fichier correspond-elle à vos attentes ? S'il s'agit d'un fichier XML ou de tout autre fichier lisible, générez-en une sortie. Contient-il les informations que vous attendiez ?
3. Si le fichier existe, le transfert est-il en cours ?
- Plusieurs outils sont à votre disposition pour voir si un transfert est en cours. Au minimum, vous devrez combiner "netstat" et "snoop" (sous Solaris) ou "tcpdump" (sous Linux).
- Gérez vos attentes. Si la taille de fichier est de 300 Mo et qu'il est enregistré dans une adresse URL via Internet, le fichier ne peut aller qu'à la vitesse maximale de la connexion Internet.
Erreur d'extraction FTP
Si WebSphere Product Center a tenté de se connecter à un serveur FTP cible et n'a pas trouvé le répertoire spécifié, une erreur survient, "Impossible de passer au répertoire distant."
Deux raisons peuvent être avancées pour expliquer cette erreur :
- L'adresse FTP cible n'est pas accessible à partir du serveur de WebSphere Product Center. A partir du serveur de WebSphere Product Center, essayez de vous connecter directement au FTP cible et vérifiez si le transfert de fichier a été pris en compte.
- Le nom de fichier utilisé peut être erroné. Vérifiez si des erreurs de capitalisation ou d'orthographe ne sont pas présentes.
Test de connectivité Java
L'adresse URL de JDBC est définie dans le fichier common.properties. Pour tester la connectivité Java du logiciel intermédiaire de WebSphere Product Center vers l'adresse URL de JDBC, utilisez le script suivant.
$TOP/bin/test_java_db.sh
Le script tente de se connecter à la base de données et d'exécuter une simple requête de type 'sélectionner compteur(*) depuis double'. Si la connexion est établie, les résultats du script de test apparaissent.
Arrêt et redémarrage de WebSphere Product Center
Une erreur a été signalée lors de l'utilisation de scripts d'arrêt normaux sous Linux/Solaris. Apparemment, WebSphere Product Center ne s'arrête pas correctement ni régulièrement. Si c'est le cas, arrêtez WebSphere Product Center, puis redémarrez-le en suivant les étapes suivantes :
1. Tentez d'arrêter normalement WebSphere Product Center à l'aide du script suivant :
$TOP/bin/go/stop_local.sh
2. Attendez environ une minute, puis entrez la commande suivante :
ps –u (NOMUTILISATEURSANS PARENTHESES)
3. Si des processus java sont actifs, un travail planifié est peut-être toujours en cours. Si vous le souhaitez, laissez le travail se terminer. Sinon, arrêtez-le manuellement à l'aide du script suivant :
$TOP/bin/go/abort_local.sh
4. Attendez environ trente secondes, puis entrez la commande suivante :
ps –u (NOMUTILISATEURSANS PARENTHESES)
5. Si des processus java sont toujours actifs, la machine JVM a vraisemblablement connu une défaillance. Le processus java doit être arrêté manuellement à l'aide de la commande suivante :
kill `ps -u (NOMUTILISATEURSANS PARENTHESES)
| grep java | cut -b10-15`Remarque : si des processus Java sont toujours présents, vous devrez peut-être redémarrer le système.
6. Une fois tous les processus java arrêtés, redémarrez WebSphere Product Center à l'aide du script suivant :
$TOP/bin/go/start_local.sh
7. Attendez approximativement une minute et vérifiez si WebSphere Product Center a correctement démarré. Exécutez le script $TOP/bin/go/rmi_status.sh ou connectez-vous à l'environnement de WebSphere Product Center.
Une structure de migration est disponible pour migrer de WebSphere Product Center version 4.2.0.x vers la version 5.2. Une autre permettant la migration de WebSphere Product 5.0 et 5.1 vers 5.2 sera fournie ultérieurement. Etant donné qu'il y a très peu de modifications de base entre les versions 5.0 et 5.2, il est possible d'effectuer la migration manuellement si nécessaire. Veuillez contacter votre représentant WebSphere Product Center pour obtenir plus d'informations.
Il existe des scripts de shell dans 4.2.0.x, qui aident l'exportation et l'importation de tous les objets pour une société donnée dans WebSphere Product Center :
Exportations
Importations
Pour faciliter l'exportation de tous les objets WPC de la version 4.2.0.x version en fichier zip, de manière à ce que le même fichier zip puisse être importé vers 5.2 pour effectuer une activité de migration.
Uns société dans WPC 4.2.0.x peut être exportée de deux manières différentes.
1. En utilisant un utilitaire de script de shell appelé $TOP/bin/exportCompanyAsZip.sh
Syntaxe :
exportCompanyAsZip --company_code=<code> --script_path=<path/to/trigo/script>
où,
Vous trouverez ci-dessous un exemple de script.
envObjList = nouvel EnvObjectList();
envObjList.addAllObjectsToExport("CATALOG");
envObjList.addAllObjectsToExport("HIERARCHY_MAPS");
envObjList.addAllObjectsToExport("MAPS");
envObjList.addAllObjectsToExport("FEEDS");
envObjList.addAllObjectsToExport("LOOKUP_TABLE");
envObjList.addAllObjectsToExport("ATTRIBUTE_COLS");
envObjList.addAllObjectsToExport("CONTAINER_ACCESSPRV");
envObjList.addAllObjectsToExport("HIERARCHY");
envObjList.addAllObjectsToExport("COMPANY_ATTRIBUTES");
envObjList.addAllObjectsToExport("SPEC");
envObjList.addAllObjectsToExport("DATASOURCE");
envObjList.addAllObjectsToExport("USERS");
envObjList.addAllObjectsToExport("ACG");
envObjList.addAllObjectsToExport("ROLES");
envObjList.addAllObjectsToExport("CATALOG_CONTENT");
envObjList.addAllObjectsToExport("HIERARCHY_CONTENT");
envObjList.addAllObjectsToExport("LOOKUP_TABLE_CONTENT");
envObjList.addAllObjectsToExport("DOC_STORE");
envObjList.addAllObjectsToExport("MY_SETTINGS");
envObjList.addAllObjectsToExport("DISTRIBUTION");
envObjList.addAllObjectsToExport("DOC_STORE");
sDocFilePath = "archives/company.zip";
exportEnv(envObjList, sDocFilePath);
2. En utilisant le script fourni ci-dessus et en l'exécutant directement dans un environnement activé de script WebSphere
Product Center (par exemple une importation, un rapport ou même directement
dans le Script Sandbox).
Certains objets WPC prédéfinis peuvent également être exportés depuis un environnement WPC en tant que
scripts au moyen du script shell $TOP/bin/exportCompany.sh qui exporte les objets
en tant que scripts de shell, de manière à ce que l'exécution de ces scripts dans un autre environnement,
ces objets WPC soient recréés. Mais dans la migration, cette opération ne sera pas utilisée
pour l'exportation d'objets WPC puisque cet utilitaire ne permet pas d'exporter
un contenu d'objet WPC (informations d'article ou de catégorie dans une
hiérarchie).
L'importation d'une société peut être effectuée de trois manières différentes.
1. En utilisant un utilitaire de script de shell, $TOP/bin/importCompanyFromZip.sh
Syntaxe : importCompanyAsZip --company_code=<code> --zipfile_path=<path/to/import/archive>
où,
company_code est le code de la société à importer et
zipfile_path est l'emplacement du magasin de documents dans lequel se situe une archive zip de la société.
2. En utilisant l'opération de script WPC importEnv(String sDocFilePath)
où,
sDocFilePath est l'emplacement du magasin de documents dans lequel se situe une archive zip de la société.
Une société WPC peut également être importée au moyen des résultats de exportCompany.sh. Mais dans la migration, cette opération ne sera pas utilisée puisque exportCompany.sh ne permet pas d'exporter un contenu d'objet WPC (informations d'article ou de catégorie dans une hiérarchie).
3. En utilisant l'option d'interface graphique d'application d'importation d'environnement.
Importation de données au moyen de l'interface graphique d'application
Dans l'infrastructure d'importation/exportation existante fournie dans WPC 4.2.0.x,
les objets WPC suivants ne sont pas exportés :
Sélections
Les fonctions d'exportation fournies dans 4.2.0.x seront mises à jour afin de prendre également en charge l'exportation de ces objets.
Dans WPC 5.2, il sera inclus une prise en charge des demandes SOAP Document/Literal en plus du style RPC/Encoded existant dans la version précédente. L'activité de migration devra être testée.
4.2.1 inclut la version officielle des outils d'importation et d'exportation. Cette fonctionnalité fournit un point de fonction d'interface graphique vers l'importation d'environnement pour importer des données exportées depuis une société dans la même version de WebSphere Product Center vers une autre société dans WebSphere Product Center via un fichier zip.
Un fichier de contrôle XML définit l'ordre des importations. Ce fichier de contrôle est créé et mis en forme dans le fichier zip pendant l'exportation. L'infrastructure de migration recommandée pour les clients serait d'utiliser exportCompanyAsZip.sh dans 4.2.0.x pour exporter toutes les données de la société. Le fichier zip de sortie de ce script devrait être compatible pour l'importation par importation d'environnement ou importCompanyFromZip.sh dans 5.2.
Prise en charge du langage de définition de services Web (WSDL) - prise en charge des demandes/réponses WSDL 1.2 et SOAP 1.2 pour des messages de demande. Le menu Gestionnaire de collaboration inclut un module de services Web pour configurer des services dans la console correspondante. Actuellement, SOAP sur HTTP est le seul protocole pris en charge.
Définitions
WebSphere Product Center fournit une couche de scripts pouvant servir de couche API. Ces scripts peuvent ensuite être exposés en tant que services Web. Un service Web est créé pour chaque fonction métier devant être exposée dans Product Center. Une application demandeuse correspondante est créée pour interagir avec le service Web. Ce dernier exécute un ou plusieurs scripts dans WebSphere Product Center et utilise également des services Web pour fournir la fonction métier souhaitée.
Le diagramme qui suit illustre une utilisation de demande/réponse WSDL 1.2 et SOAP 1.2 pour des messages de demande.
Les services Web sont configurés pour utiliser la console des services Web. La procédure ci-dessous s'appuie sur une utilisation générale de WSDL.
1. Console des services Web – cliquez sur Nouveau et entrez les informations requises dans les zones suivantes :
- Nom du service Web (par exemple, Demande_Article)
- Description du service Web (par exemple : permet à une application externe de demander des détails sur un article en fonction des attributs d'ID tels que GTIN ou UPC, GLN et le marché cible.)
- Fichier de définition des services Web (description ci-dessous)
- Script d'implémentation des Services Web (description ci-dessous)
2. Fichier de définition des services Web
Le fichier de définition des services Web est téléchargé à partir de la console des services Web et contient une description du service Web au format WSDL 1.2. Le service Web utilise le codage de demande/réponse SOAP 1.2 et le fichier WSDL inclut ce qui suit :
- XSD pour le message de demande
- XSD pour le message de réponse
- XSD pour le message d'erreur
- Le reste du contenu requis par WSDL 1.2
Remarque : le fichier de définition des services Web est publié sur le serveur HTTP par défaut, à savoir celui pour WebSphere Product Center. Sur ce serveur également est publié le script d'implémentation des services Web. Le système offre une assistance si vous cliquez sur le bouton d'aide.
3. Script d'implémentation des services Web - ce script est appelé par un message de demande entrant SOAP 1.2 respectant la définition précédente. Le script d'implémentation entreprend les actions suivantes :
- il analyse le message de demande SOAP 1.2 par rapport à la définition antérieure de service Web,
- il interroge généralement un ou plusieurs conteneurs WebSphere Product Center pour obtenir des informations produit,
- il génère un message de réponse SOAP 1.2 contenant les informations produit,
- il transmet le message de réponse SOAP 1.2 à l'application demandeuse.
- Facultatif par rapport à l'administrateur WebSphere dans le script - il consigne les messages de demande et de réponse dans le magasin de documents, ainsi qu'un lien vers ces messages de façon à ce que l'accès soit possible dans la console de messages.
4. Message de demande de l'application demandeuse - l'administrateur de l'application demandeuse écrit le processus de création d'un message SOAP 1.2 compatible avec la définition des services Web décrite à l'étape 2.
5. Message de réponse de l'application demandeuse - l'administrateur de l'application demandeuse écrit le processus de réception d'un message SOAP 1.2 compatible avec la définition des services Web décrite à l'étape 2.
Une fois les services Web configurés, les événements suivants se produisent :
1. L'utilisateur exécute dans l'application demandeuse le processus d'envoi du message SOAP 1.2 de cette application au serveur HTTP de WebSphere Product Center.
2. Le message de demande contient uniquement des attributs d'ID tels que GTIN ou UPC, GLN et le marché cible.
3. WebSphere Product Center exécute le script d'implémentation des services Web pour analyser le message de demande SOAP 1.2, accéder aux informations produit, générer un message de réponse SOAP 1.2 et transmettre celui-ci.
4. (Facultatif) Le système consigne le message de demande et celui de réponse dans le magasin de documents. Il enregistre également un lien à ces messages pour permettre l'accès depuis la console de messages.
5. L'application demandeuse reçoit le message de réponse.
6. L'application demandeuse traite le message de réponse.
Les fichiers suivants contrôlent les différents sous-systèmes de WebSphere Product Center. L'emplacement du journal généré est défini dans chaque fichier.
Remarque : tous les chemins sont relatifs à $TOP
/etc/logs/processeurévénements.log.xml
/etc/logs/scheduler.log.xml
/etc/logs/system.log.xml
/etc/logs/appsvr.log.xml
/etc/logs/workflowengine.log.xml
La console des services Web permet à l'utilisateur de créer et de gérer des services Web exposés par WebSphere Product Center. Un document WSDL peut être rédigé afin de définir un service et un script d'implémentation est créé pour contrôler le mode d'exécution du service.
La console des services Web compte les colonnes suivantes :
- Nom : nom du service Web. Cliquez sur ce nom pour afficher les détails sur le service Web.
- Description : brève description du service Web.
- Protocole : actuellement, SOAP_HTTP est le seul protocole disponible.
- Transactions : nombre de transactions pour le service. Cliquez sur ce nombre pour afficher la transaction ou sur le bouton de suppression pour supprimer le service Web de la console.
Pour accéder à la console des services Web, sélectionnez ce qui suit :
Gestionnaire de collaboration > Services Web > Console des services Web.
Pour créer un service Web, sélectionnez ce qui suit :
Gestionnaire de collaboration > Services Web > Nouveau service Web
L'écran "Détail du service Web" apparaît. Entrez les informations nécessaires pour définir le nouveau service Web.
Cette section présente chaque zone de l'écran Détail du service Web.
Remarque : voir la section suivante pour connaître les modifications apportées en matière de prise en charge du style Document/Literal pour les services Web.
Nom du service Web : entrez le nom du service Web. Ce nom devient partie intégrante de l'URL du service SOAP. Il ne doit pas contenir de blanc.
Description du service Web : entrez une description du service Web.
Protocole : protocole utilisé pour le service Web. Actuellement, SOAP sur HTTP est le seul protocole pris en charge. La valeur par défaut est “SOAP_HTTP”.
Style : "DOCUMENT_LITERAL" ou "RPC_ENCODED". Le script WPC implémentant un service Document/Literal reçoit l'intégralité du corps de demande et doit renvoyer en retour un corps entier de réponse. Un script WPC de service RPC/Encoded reçoit un tableau de paramètres de chaînes et doit renvoyer une chaîne unique. Les services RPC/Encoded peuvent s'avérer plus faciles d'emploi pour des applications simples, alors que les services Document/Literal offrent une plus grande souplesse pour des services plus complexes.
Adresse URL : indique l'URL à laquelle il est possible d'accéder au service. Cette zone est renseignée automatiquement après l'enregistrement du service Web.
Adresse URL du service Web : URL à laquelle il est possible d'accéder au document WSDL pour le service Web. Cette zone est renseignée automatiquement après l'enregistrement du service Web.
Document WSDL : entrez le document WSDL pour ce service. Un document WSDL est une description de l'interface, de l'adresse URL et du protocole du service au format XML. Vous devez entrer ce document manuellement ; vous trouverez un exemple ci-dessous. Vous devez entrer des données XML valides pour que le service Web s'enregistre avec succès.
Script d'implémentation : entrez un script WPC implémentant ce service. Pour un service RPC/Encoded, les paramètres d'entrée sont disponibles dans la variable de tableau "soapParams" et la valeur de retour doit être une chaîne inscrite dans la variable "out". Dans le cas d'un service Document/Literal, le corps de demande SOAP est indiqué dans la variable de chaîne "soapMessagee et le corps de réponse doit être inscrit dans la variable "out". Quel que soit le style, rédigez le code d'erreur dans la variable "soapFaultCode" et le message d'erreur dans la variable "soapFaultMsg" pour renvoyer une erreur SOAP. Un exemple de script d'implémentation est disponible ci-après.
Stocker les requêtes ? : si cette case est cochée, WPC stocke les paramètres de toutes les demandes entrantes dans le magasin de documents. Elles seront disponibles depuis la console des transactions.
Stocker les réponses ? : si cette case est cochée, WPC stocke le contenu de toutes les réponses dans le magasin de documents. Elles seront disponibles depuis la console des transactions.
Déployé : si cette case est cochée, le service est déployé. Dans le cas contraire, ce service ne sera pas disponible.
Le service Web Document/Literal qui suit renvoie une déclaration pour un symbole d'action donné. Cet exemple limité renvoie uniquement une valeur pour "IBM" ; tous les autres arguments entraînent une erreur soap.
Le noeud final de ce service Web est comparable à une méthode Java avec la signature suivante :
java.math.BigDecimal getStockQuote(String ticker);
Script d'implémentation
// analyser le document de demande
var doc = new XmlDocument(message);
// obtenir le paramètre d'action
var ticker = parseXMLNode("ticker");
// uniquement des déclarations IBM
if (ticker == "IBM") {
out.println("<ibm:getStockQuoteResponse
xmlns:ibm=\"http://ibm.com/wpc/test/stockQuote\">");
out.println(" <ibm:response>123.45</ibm:response>");
out.println("</ibm:getStockQuoteResponse>");
}
else {
soap_fault_msg.print("Prise en charge de déclarations pour IBM uniquement");
}
WSDL
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:y="http://ibm.com/wpc/test/stockQuote"
targetNamespace="http://ibm.com/wpc/test/stockQuote">
<types>
<xs:schema targetNamespace="http://ibm.com/wpc/test/stockQuote"
elementFormDefault="qualified">
<xs:element name="getStockQuote">
<xs:complexType>
<xs:sequence>
<xs:element name="ticker" type="xs:string" nillable="false"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getStockQuoteResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="response" type="xs:decimal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</types>
<message name="getStockQuoteRequest">
<part name="parameters" element="y:getStockQuote"/>
</message>
<message name="getStockQuoteResponse">
<part name="parameters" element="y:getStockQuoteResponse"/>
</message>
<portType name="StockQuotePortType">
<operation name="getStockQuote">
<input message="y:getStockQuoteRequest"/>
<output message="y:getStockQuoteResponse"/>
</operation>
</portType>
<binding name="StockQuoteBinding" type="y:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getStockQuote">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort" binding="y:StockQuoteBinding">
<soap:address
location="http://example.wpc.ibm.com/services/StockQuoteService"/>
</port>
</service>
</definitions>
Pour rechercher toutes les transactions de services Web, affichez la console des transactions en sélectionnant ce qui suit :
Gestionnaire de collaboration > Services Web > Console des transactions.
1. Dans la console des transactions, affichez la liste des transactions du tableau Transactions de service Web.
2. Cliquez sur le bouton Afficher dans la colonne Réponse ou Demande. Les détails sur la transaction apparaissent dans une nouvelle fenêtre de navigateur.
1. Dans la console des transactions, sélectionnez un intervalle de dates dans les zones Date de début de réception et Date de fin de réception du tableau Recherche de transaction de service Web.
2. Cliquez sur le bouton Rechercher. Tous les résultats apparaissent dans le tableau Transactions de service Web sous le tableau de recherche.
L'intégration de Supplier Portal présente un certain nombre d'avantages pour les commerçants, dont :
WebSphere Product Center offre une structure de services Web pour une intégration correcte à WebSphere Portal Server. Les fonctions suivantes sont disponibles :
Pour une intégration à WebSphere Portal Server, les fonctions des services Web incluent la prise en charge des fonctions suivantes :
Par conséquent, la structure de services Web comprend les fonctions suivantes :
La liste suivante d'opérations de script prennent en charge les services Web de WebSphere Product Center et sont disponibles dans Script Sandbox :
Remarque : pour plus de détails (prototype et description) sur chaque opération de script, voir Script Sandbox dans WebSphere Product Center.
· createWebService
· deleteWebService
· getDesc
· isDeployed
· getLoginString
· getImplScriptPath
· getName
· getProtocol
· getStoreIncoming
· getStoreOutgoing
· getStyle
· getUrl
· getWebServiceByName
· getWsdlDocPath
· getWsdlUrl
· invokeSoapServer
· saveWebService
· setDeployed
· setDesc
· setImplScriptPath
· setName
· setProtocol
· setStoreIncoming
· setStoreOutgoing
· setStyle
· setWsdlDocPath
Cette section explique la prise en charge du style Document/Literal pour la prise en charge des services Web dans WebSphere Product Center. Le style RPC/Encoded était déjà disponible dans des versions antérieures. Toutefois, les services Web RPC/Encoded prenaient uniquement en charge des types de chaînes simples. Pour répondre au besoin de pouvoir envoyer et recevoir des types complexes, une prise en charge de services Web de style Document/Literal est fournie dans WebSphere Product Center.
En vue du déploiement d'un service Web de style Document/Literal, un utilisateur doit créer le service en question incluant un document WSDL qui en définit le schéma et un script de déclenchement WebSphere Product Center pour lancer un appel lorsqu'une demande est détectée. Au moment de l'enregistrement du service Web, l'utilisateur doit indiquer de façon explicite qu'il sera déployé. Lors du déploiement, WebSphere Product Center crée une URL à laquelle le document WSDL est accessible. L'URL du service Web ressemble à ce qui suit :
http://<serveur-web-application>:<numéro-port-application>/services/<nom-service-web-stocké>
Si vous ajoutez la chaîne "?wsdl" à la fin de l'URL, vous obtenez le chemin du document WSDL stocké pour le service Web.
Une demande pour un service Web de style Document/Literal est placée dans une enveloppe SOAP et le corps du message SOAP comprend l'intégralité du document de demande. Ce document de demande doit se trouver dans un format XML correct et sera transmis en l'état au gestionnaire de services Web de WebSphere Product Center. Un appelant doit avoir établi cette demande en connaissant le format du noeud de schéma du document WSDL stocké pour le service Web appelé.
Le mécanisme de gestion de services Web de WebSphere Product Center reçoit cette demande et en valide le contenu par rapport au schéma WSDL pour les demandes de style Document/Literal. Si la demande n'obéit pas au schéma WSDL, une erreur Axis est lancée. Sinon, WebSphere Product Center élimine les références d'espace de nom du corps de la demande et transmet la demande modifiée au script de déclenchement stocké au moment du déploiement. La suppression de l'espace de nom est obligatoire en raison des limitations du contexte de script WebSphere Product Center ne pouvant pas gérer de documents XML avec espace de nom. Le script de déclenchement de WebSphere Product Center prend le contenu de la demande et s'en sert comme indiqué dans sa description. Le script doit envoyer les résultats comme réponse valide à la demande entrante. Par conséquent, la réponse est validée par rapport au document WSDL avant l'envoi des résultats.
Exemple :
Le schéma Document/Literal ressemble à ce qui suit :
<element name="getStockQuote"/>
<complexType>
<sequence>
<element name="ticker" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="getStockQuoteResponse"/>
<complexType>
<sequence>
<element name="response" type="xsd:decimal"/>
</sequence>
</complexType>
</element>
Si le client a appelé getStockQuote("IBM"), le flux ressemble à ce qui suit :
1. WebSphere Product Center reçoit une demande SOAP de la pile SOAP Axis.
2. WebSphere Product Center valide le message de demande par rapport au schéma précédent.
3. WebSphere Product Center élimine tous les préfixes d'espace de nom du corps de la demande. Inutile dans ce cas puisque le schéma définit tout dans l'espace de nom par défaut.
4. WebSphere Product Center appelle le script de déclenchement du service Web. Les variables d'entrée sont :
- operationName = "getStockQuote"
- message =
"<getStockQuote>
<ticker>IBM</ticker>
</getStockQuote>"5. Le script de déclenchement écrit la réponse dans la variable "out" :
- out =
"<getStockQuoteResponse>
<response>83.76</response>
</getStockQuoteResponse>"6. WebSphere Product Center valide la réponse par rapport au schéma précédent.
7. WebSphere Product Center renvoie l'intégralité de la réponse SOAP au client via la pile SOAP Axis.
La liste qui suit répertorie les modifications apportées à la prise en charge du style Document/Literal.
En fonction de la version de WebSphere Product Center, une légère modification de la base de données (DB2/Oracle) doit éventuellement être réalisée. Consultez votre représentant WebSphere Product Center pour tout problème de migration.
http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/
En raison des limitations imposées par l'implémentation d'analyse XML fournie avec WebSphere Product Center par Xerces version 2.4.0, la déclaration de l'espace de nom doit être définie en local sur le noeud de schéma du document WSDL. Ce point se vérifie notamment lors du déploiement de services Web de style Document/Literal. Par exemple, le document WSDL qui suit est valide mais ne serait pas correctement reconnu par WebSphere Product Center :
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:y="http://ibm.com/wpc/test/stockQuote" targetNamespace="http://ibm.com/wpc/test/stockQuote">
<types>
<xs:schema targetNamespace="http://ibm.com/wpc/test/stockQuote" elementFormDefault="qualified">
<xs:element name="getStockQuote">
<xs:complexType>
<xs:sequence>
<xs:element name="ticker" type="xs:string" nillable="false"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getStockQuoteResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="response" type="xs:decimal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</types>
<message name="getStockQuoteRequest">
<part name="parameters" element="y:getStockQuote"/>
</message>
<message name="getStockQuoteResponse">
<part name="parameters" element="y:getStockQuoteResponse"/>
</message>
<portType name="StockQuotePortType">
<operation name="getStockQuote">
<input message="y:getStockQuoteRequest"/>
<output message="y:getStockQuoteResponse"/>
</operation>
</portType>
<binding name="StockQuoteBinding" type="y:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getStockQuote">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort" binding="y:StockQuoteBinding">
<soap:address location="http://localhost/axis/services/StockQuoteService"/>
</port>
</service>
</definitions>
Le document WSDL devrait être rédigé comme suit pour être correctement analysé :
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:y="http://ibm.com/wpc/test/stockQuote" targetNamespace="http://ibm.com/wpc/test/stockQuote">
<types>
<xs:schema targetNamespace="http://ibm.com/wpc/test/stockQuote" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="getStockQuote">
<xs:complexType>
<xs:sequence>
<xs:element name="ticker" type="xs:string" nillable="false"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getStockQuoteResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="response" type="xs:decimal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</types>
<message name="getStockQuoteRequest">
<part name="parameters" element="y:getStockQuote"/>
</message>
<message name="getStockQuoteResponse">
<part name="parameters" element="y:getStockQuoteResponse"/>
</message>
<portType name="StockQuotePortType">
<operation name="getStockQuote">
<input message="y:getStockQuoteRequest"/>
<output message="y:getStockQuoteResponse"/>
</operation>
</portType>
<binding name="StockQuoteBinding" type="y:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getStockQuote">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort" binding="y:StockQuoteBinding">
<soap:address location="http://localhost/axis/services/StockQuoteService"/>
</port>
</service>
</definitions>
ID de cas : P16473
Problème : créer un service Web et redémarrer WebSphere Product Center. Une erreur apparaît lors de la tentative d'appel du nouveau service Web créé.
Solution : octroyer l'accès en écriture au fichier de configuration Axis "server-config.wsdd" dans le répertoire "public_html/WEB-INF". En outre, pour les environnements utilisant WebLogic, l'instance WebSphere Product Center doit être déployée dans un format de répertoire étendu. Dans le cas contraire, la fonctionnalité de déploiement automatique ne déploie pas les services Web créés par WebSphere Product Center au redémarrage, d'où une erreur.
ID de cas : P16059
Créer un service Web avec le style DOCUMENT/LITERAL. L'enregistrer, choisir le style to RPC/ENCODED et faire un nouvel enregistrement. Le style DOCUMENT/LITERAL est affiché.
Il s'agit d'une limitation connue. Un utilisateur ne peut pas changer le style d'un service Web déployé.
1. Ouvrez common.properties. Définissez une valeur pour "soap_company" et "soap_user". Il s'agit de la société et de l'utilisateur employé par les demandes SOAP entrantes afin d'accéder à la base de données et d'exécuter des scripts. Définissez également une valeur pour "wpc_web_url".
Par exemple :
soap_company=acme
soap_user=Admin
wpc_web_url=http://myinstance.acme.com:1234/
2. Quittez WebSphere Product Center. Sélectionnez Gestionnaire de collaboration->Services Web->Nouveau service Web. Entrez ou sélectionnez des valeurs comme ci-dessous.
<?xml version="1.0" encoding="UTF-8"?>
<!-- modifié avec XMLSPY v2004 éd. 4 U (http://www.xmlspy.com) par Dave Marquard (IBM) -->
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:y="http://ibm.com/wpc/test/stockQuote" targetNamespace="http://ibm.com/wpc/test/stockQuote">
<types>
<xs:schema targetNamespace="http://ibm.com/wpc/test/stockQuote" elementFormDefault="qualified">
<xs:element name="getStockQuote">
<xs:complexType>
<xs:sequence>
<xs:element name="ticker" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getStockQuoteResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="response" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</types>
<message name="getStockQuoteRequest">
<part name="parameters" element="y:getStockQuote"/>
</message>
<message name="getStockQuoteResponse">
<part name="parameters" element="y:getStockQuoteResponse"/>
</message>
<portType name="StockQuotePortType">
<operation name="getStockQuote">
<input message="y:getStockQuoteRequest"/>
<output message="y:getStockQuoteResponse"/>
</operation>
</portType>
<binding name="StockQuoteBinding" type="y:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getStockQuote">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort" binding="y:StockQuoteBinding">
<soap:address location="http://localhost/axis/services/StockQuoteService"/>
</port>
</service>
</definitions>
// analyser le document de demande
var doc = new XmlDocument(soapMessage);
// obtenir le paramètre d'action
var ticker = parseXMLNode("ibm:ticker");
// uniquement des déclarations IBM
if (ticker == "IBM") {
out.println("<ibm:getStockQuoteResponse xmlns:ibm=\"http://ibm.com/wpc/test/stockQuote\">");
out.println("<ibm:response>123.45</ibm:response>");
out.println("</ibm:getStockQuoteResponse>");
}
else {
// faut-il aussi imprimer soapFaultCode ?
soapFaultMsg.print("Prise en charge de déclarations d'IBM uniquement");
}
3. Cochez Stocker les requêtes pour afficher l'historique de demandes dans la console des transactions.
4. Cochez Stocker les réponses pour afficher l'historique de réponses dans la console des transactions.
5. Cochez Déployé pour déployer le service Web. Celui-ci n'est pas disponible si cette option n'est pas sélectionnée.
6. Appelez le service Web à l'aide de com.ibm.ccd.soap.test.StockQuoteTest.java.
Syntaxe : $JAVA_RT com.ibm.ccd.soap.test.StockQuoteTest <URL>
<NUM_CAS>
Exemple : $JAVA_RT com.ibm.ccd.soap.test.StockQuoteTest http://trillian:9099/services/DocumentWebServiceTest 0
<NUM_CAS> peut correspondre à tout entier compris entre 0 et 5.
0 peut servir à demander une déclaration d'article d'IBM. Voir
StockQuoteTest.java pour en savoir plus.
6. La réponse est :
Services SOAP appelé à l'URL
'http://trillian:9099/services/TestingDocumentStyle14'
La demande était : '<ibm:getStockQuote
xmlns:ibm="http://ibm.com/wpc/test/stockQuote">
<ibm:ticker>SNM</ibm:ticker>
</ibm:getStockQuote>'
L'appel SOAP a abouti.
Le résultat était '<ibm:getStockQuoteResponse
xmlns:ibm="http://ibm.com/wpc/test/stockQuote">
<ibm:response>123.45</ibm:response>
</ibm:getStockQuoteResponse>'
Ce chapitre a pour objectif de résumer les pratiques d'intégration recommandées dans une implémentation WebSphere Product Center. L'utilisation de ces pratiques recommandées vous permettra d'obtenir une intégration fiable et de qualité entre les systèmes. Pour couvrir tous les aspects de l'intégration, ce document a été développé pour identifier les pratiques recommandées associées à chaque aspect d'intégration.
Eléments clés de l'intégration :
- Principes de conception
- Implémentation
- Validation
- Visibilité
Dimensions de l'intégration : nous pouvons utiliser les dimensions ci-après pour connaître les différentes sortes d'implémentation de WebSphere Product Center. Le reste du document établit la correspondance entre pratiques ou instructions recommandées et dimensions ou types d'implémentation.
Utilisation de WebSphere Product Center en tant que système source ou cible
La dimension la plus évidente est de savoir si WebSphere Product Center est le système source ou le système cible des informations échangées. Un système source place ses contraintes dans une intégration, dont les plus importantes sont (a) la possibilité d'exécuter des syndications delta, (b) la possibilité de lancer une intégration, (c) la possibilité de recevoir une notification sur le succès/l'échec des données transmises et d'agir en conséquence, puis (d) les protocoles et formats pris en charge, ainsi que la prise en charge d'une infrastructure Intégration d'applications d'entreprise.
Système de contrôle
Un système de contrôle est un système qui agit en fonction du déclenchement interne d'une intégration. Par exemple, il peut s'agir de WebSphere Product Center exécutant une syndication de façon planifiée en tant que travail. Il peut s'agir sinon du déclenchement SAP d'un adaptateur WBI suite à l'ajout d'un article. Que WebSphere Product Center soit le système source ou cible d'une intégration ne dépend pas du système de contrôle d'une intégration. Plusieurs cas sont possibles. Lorsqu'un élément intermédiaire, tel un serveur FTP ou un outil Intégration d'applications d'entreprise, est impliqué, les systèmes source et cible peuvent être les systèmes de contrôle : un système central insère de façon planifiée un fichier sur le serveur FTP, tandis que WebSphere Product Center récupère de façon planifiée le fichier. Par exemple, WebSphere Product Center est un système de destination contrôlé (il attend des éléments externes pour déclencher une importation de données) lorsque IBM WBI enregistre un message dans WebSphere Product Center via l'auteur de l'appel avec le contenu du message sous forme de mise à jour d'article depuis Transora. WebSphere Product Center est un système source contrôlé (il attend des éléments externes pour déclencher une exportation de données) lorsque IBM WBI interroge périodiquement une file d'attente de WebSphere Product Center pour vérifier si un fichier est prêt à être sélectionné.
Protocole
Une grande confusion existe dans les équipes de mises en oeuvre de WebSphere Product Center et les ressources client au sujet du protocole, du format et du message et l'intégration basée sur les fichiers. Par conséquent, un des objectifs de ce document est d'établir une nomenclature commune pour ces concepts. File Transfer Protocol (FTP), Hyper Text Transfer Protocol (HTTP), Simple Message Transfer Protocol (SMTP, e-mail), Java Messaging Service (JMS) et IBM WebSphere Message Queuing (IBM WebSphere MQ) sont des protocoles. Un protocole définit des éléments tels que les enveloppes, le codage de données telles que les numéros et une réponse attendue. Cependant, un protocole est totalement étranger au contenu des informations transmises. Dans toutes les intégrations, nous devons être très clairs sur les protocoles utilisés car il y en aura toujours un au minimum. De plus, les différentes étapes d'une intégration peuvent utiliser différents protocoles : l'adaptateur WBI de SAP peut transmettre des données de SAP vers le serveur d'interconnexions (Inter Connection Server - ICS) WBI via HTTP, qui transmet ensuite ces données à un gestionnaire de files d'attente auquel WebSphere Product Center est connecté en tant que client MQ.
Format
Le format des données est indépendant du protocole. CSV, pipe delimited, XML, ou tout champ et structure d'enregistrement prédéfinis tels que pour les messages EDI, sont des exemples de formats. Chaque format définit des champs via des paramètres d'emplacement/de longueur ou des balises. Il est important de ne pas oublier le codage nécessaire à un format particulier. Par exemple, on oublie souvent dans les mises en oeuvre que les chevrons ('<', '>') doivent être ignorés dans XML ou que le contenu d'un format CSV peut contenir des virgules.
Taille des données
Cette dimension est souvent confondue avec la communication "basée sur les messages" ou la communication "basée sur les fichiers". Il est donc important de bien définir cette dimension. L'intégration "basée sur les messages" est généralement utilisée dans le cadre d'échanges de données peu volumineux et de propriétés telles que :
- Les données sont échangées plus fréquemment et en tranches moins volumineuses afin que les modifications soient communiquées plus régulièrement que dans les systèmes par "lots" traditionnels où les exportations/importations peuvent être hebdomadaires.
- Les deux systèmes (source et destination) sont en contact afin qu'un message envoyé soit traité et accompagné d'un accusé de réception ; cela permet d'éviter de générer un fichier à envoyer par FTP ou à stocker dans un système de fichiers pendant une semaine avant qu'il ne soit traité.
Cependant, il n'existe pas de limite clairement définie entre intégration basée sur des messages, intégration basée sur des fichiers et intégration par lots. Il est important de définir un ensemble clair de dimensions, de ne pas les confondre et de ne pas en oublier. Par conséquent, la taille globale des données doit être une dimension plus importante que de savoir s'il s'agit d'une intégration "basée sur les messages" ou "par lots".
Types de communication
Une autre dimension à prendre en compte est le type de communication de l'intégration. La communication synchrone fournit des appréciations en retour à un utilisateur ou un système sur le résultat d'une action particulière. Par exemple, si vous utilisez le protocole HTTP pour communiquer, le système ou l'utilisateur reçoit un feedback automatique après qu'une action a été enregistrée. La communication asynchrone utilise quant à elle une stratégie "sans feedback automatique". Si l'intégration nécessite de déposer un fichier sur un serveur FTP, qui sera ensuite sélectionné par un système par exemple, aucun feedback automatique sur le résultat de l'action n'est renvoyé au système ayant déposé le fichier.
Fréquence
Associée à la dimension de "taille des données", la dimension de "fréquence" capture le volume total de données qui devra être traité sur une base périodique.
Unité d'exécution d'intégration
Cette dimension d'infrastructure et de système intermédiaire capture si une infrastructure Intégration d'applications d'entreprise est utilisée ou non. A certains moments dans des intégrations avec des systèmes centraux, des programmes intermédiaires doivent être enregistrés pour télécharger ou extraire des données dans le système central. Il est important de comprendre et de documenter ces systèmes ou programmes intermédiaires puisqu'ils constituent souvent le maillon le plus faible de la chaîne d'intégration.
Dans les intégrations complexes nécessitant plusieurs tronçons (WebSphere Product Center vers WBI vers système de destination, par exemple), des moyens non standard (tels que des mises à jour directes de bases de données), des protocoles multiples ou d'autres situations de communication particulières (communication via un pare-feu), établissez rapidement une unité d'exécution unique ou un chemin complet d'intégration opérationnel. Cela permet d'identifier les problèmes et de donner aux autres personnes (administrateurs réseau ou équipes travaillant sur IBM WBI) du temps pour résoudre parallèlement ces problèmes de connectivité.
Les dimensions d'une intégration listées ci-avant doivent devenir la terminologie standard de description de l'intégration dans des implémentations WebSphere Product Center. La documentation fournie par les équipes PS lors des étapes d'analyse/de conception doit utiliser ces dimensions clairement et de façon cohérente.
Acronymes
Acronyme
Définition
EAI
Intégration d'application d'entreprise
FTP
File Transfer Protocol (Protocole de transfert de fichiers)
HTTP
Hyper Text Transfer Protocol
MQ
Logiciel intermédiaire de mise en file d'attente des messages d'IBM. Souvent nommé IBM WebSphere MQ car toutes les solutions de connectivité sont des produits WebSphere.
ICS
IBM's WBI Inter Connect Server (Serveur d'interconnexions WBI d'IBM)
WBI
IBM WebSphere Business Integration suite (Suite WebSphere Business Integration), suite Intégration d'applications d'entreprise d'IBM.
Possibilité de réutilisation
La notion de base de la méthodologie d'implémentation de l'intégration est la possibilité de réutilisation. WebSphere Product Center et les mises en oeuvre client se développant, il est nécessaire de pouvoir faire évoluer et résoudre rapidement les intégrations avec les systèmes précédemment non intégrés et ceux qui ont été intégrés dans les mises en oeuvre précédentes. Pour répondre à cette attente, il est nécessaire de garder à l'esprit la possibilité de réutilisation dans toutes les opérations d'intégration, de telle manière que, si nous devons effectuer l'intégration avec le même système pour un autre client, nous puissions le faire avec une efficacité optimale.
La possibilité de réutilisation s'obtient grâce : (a) aux outils Intégration d'applications d'entreprise tels que IBM WBI et son modèle d'objets de gestion génériques, (b) au choix des formats indépendants du modèle de données, (c) à l'écriture de bibliothèques de scripts WebSphere Product Center (accusé de réception, interrogation, etc.) qui sont indépendantes du modèle de données et peuvent être réutilisées dans d'autres mises en oeuvre.
Partage des informations
La communication comme vecteur d'intégration
De façon conceptuelle, l'intégration peut être résumée comme étant simplement une série d'événements qui peuvent être déclenchés par une communication entre un système WebSphere Product Center de contrôle et un/des système(s) contrôlés. Ces événements peuvent être déclenchés par des messages transmis entre les systèmes, des processus automatisés qui interrogent le contenu des fichiers ou tout autre moyen de communication rudimentaire. Les communications comprennent, par exemple, le type de modification à apporter (ajout, mise à jour, suppression), un ID de communication unique (pour le suivi / la confirmation) et le contenu approprié pour effectuer les modifications dans WebSphere Product Center ou dans le/les système(s) intégral/intégraux.
Mesures de fiabilité
Outre la transmission des informations entre système pour communiquer les modifications, un moyen de communication permettant de transmettre le succès ou l'échec d'une transaction particulière doit également être installé. Ces communications par protocole d'établissement de liaison peuvent être mises en oeuvre de façon intuitive avec les formes synchrones de communication, et permettent aux systèmes intégrés de savoir si une transaction particulière doit être renvoyée en raison d'un échec de réception à l'autre extrémité et, par conséquent, d'assurer la fiabilité de l'intégration.
Formats d'informations
Le format spécifique de ces communications doit être conçu de façon assez générique afin que le format et la fonctionnalité de traitement puissent être réutilisés dans d'autres implémentations.
Lors du choix du format général à utiliser pour les communications entre systèmes, il est important d'évaluer la convivialité d'un format à la lumière des besoins suivants :
- Jeux de caractères internationaux et caractères spéciaux (virgules, guillemets, crochets obliques, etc)
- Structures complexes (par exemple, hiérarchies de contenu et relations)
- Capacité de gestion d'instances multiples d'un contenu ou d'une marque de réservation d'article avec plusieurs valeurs par instance
Traitement des informations
Bien qu'il soit concevable que le format des informations envoyées entre les systèmes soit générique, il est compréhensible que toutes les mises en oeuvre ne pourront pas s'adapter à un format prédéfini, particulièrement si nous considérons l'intégration comme un lien direct entre WebSphere Product Center et le/les système(s) intégral/intégraux. Pour éviter de reconcevoir les formats et les mises en correspondance entre les formats et les spécifications de WebSphere Product Center à chaque implémentation en raison de différences (par exemple, modèles de données), il est recommandé d'utiliser des fonctionnalités de mise en correspondance réutilisables entre les formats XML et les spécifications de WebSphere Product Center.
Utilisation de plateformes Intégration d'applications d'entreprise
Pour ce faire, vous pouvez utiliser des plateformes Intégration d'applications d'entreprise, telles que la suite WBI ou webMethods, qui permettent de concevoir des connecteurs réutilisables, eux-mêmes permettant à WebSphere Product Center, par exemple, de communiquer via un format de message unique et totalement réutilisable (par exemple, DTD XML unique). Les différences survenant en raison de particularités d'une implémentation peuvent ensuite être translatées par WBI. Il n'est donc pas nécessaire de reconcevoir la fonctionnalité WebSphere Product Center pour traiter les informations. La reconception de la fonctionnalité WebSphere Product Center n'étant pas nécessaire, la même fonctionnalité peut être utilisée dans toutes les implémentations.
Autres options
Cependant, il faut tenir compte des clients particuliers qui peuvent avoir besoin de réutiliser un format déjà utilisé dans d'autres systèmes de leur société. WebSphere Product Center aurait, dans ce cas, des difficultés à introduire une DTD totalement distincte. Celle-ci devra être alors translatée afin que les autres systèmes de la société puissent l'utilisent, et non pas afin que WebSphere Product Center utilise la DTD existante. Dans ces conditions, nous devrions employer la fonctionnalité réutilisable pour effectuer la translation entre les spécifications de WebSphere Product Center et la DTD.
Même avec une plateforme Intégration d'applications d'entreprise en cours d'utilisation, cette méthode sera plus utile pour un client particulier souhaitant établir la mise en correspondance des informations gérées par WebSphere Product Center et leur DTD interne afin de communiquer les informations.
Gestion des événements
Idéalement, un processus automatisé dans WebSphere Product Center gère les événements. Par exemple, la fonctionnalité de mise en file d'attente introduite dans la version WebSphere Product Center peut être utilisée pour gérer l'envoi de messages (files d'attente sortantes) et la réception de réponses et de messages entrants (files d'attente entrantes). Les scripts de traitement de files d'attentes peuvent ainsi être utilisés pour gérer le traitement des messages et, par conséquent, gérer les événements qui sont déclenchés suite à un message spécifique.
Cependant, la gestion des événements n'est pas forcément directement liée à la fonctionnalité spécifique ou à des versions spécifiques de WebSphere Product Center. D'autres moyens de gestion des événements peuvent inclure des travaux planifiés qui interrogent un serveur FTP dans WebSphere Product Center, des travaux planifiés qui recherchent un fichier dans un système de fichiers local (via le magasin de documents). Ceux-ci disposent d'un script déclencheur basé sur un invoker qui met les événements en application en fonction des informations transmises, ou d'autres moyens. La méthode choisie doit dépendre de la taille des données et des dimensions de fréquence d'une intégration particulière.
Modification du suivi
Pour mettre en oeuvre une synchronisation totale entre systèmes, WebSphere Product Center doit disposer d'un moyen de suivi des modifications apportées au contenu et aux éléments permettant de signaler qu'ils ont été communiqués ou non au(x) système(s) intégral/intégraux. Par exemple, si un article est supprimé dans WebSphere Product Center (en tant que système source), il est probable que nous souhaitions non seulement déclencher un message vers le système cible afin de l'informer de supprimer le même article, mais également effectuer le suivi du succès ou de l'échec de cette communication, afin que WebSphere Product Center puisse être informé de la suppression ou non de l'article dans le système cible.
Connecteurs réutilisables
Référentiel de connecteurs
Au fur et à mesure de la progression de nos implémentations et de l'évolution de nos partenariats, nous mettons en place un référentiel de connecteurs réutilisables destinés à divers systèmes. Dans la mesure du possible, nous devons nous efforcer de réutiliser ces connecteurs, car ils peuvent être réutilisés sans quasiment de modifications dans une implémentation spécifique. Bien sûr, cela aura pour conséquence d'accélérer le temps d'exécution global de l'implémentation et de renforcer la fiabilité et la stabilité des connecteurs et des implémentations qui les utilisent car les problèmes sont détectés et résolus au fur et à mesure.
Lors d'une intégration avec des systèmes qui ne disposent pas encore de connecteurs définis, un expert en intégration doit être impliqué dans le processus. Celui-ci doit concevoir rapidement un connecteur réutilisable pouvant être utilisé dans le cadre de l'intégration dans une implémentation spécifique et stocké dans le référentiel de connecteurs en vue d'une utilisation ultérieure, au cas où il serait nécessaire de procéder à l'intégration du système sur une autre implémentation.
Utilisation du connecteur
Les connecteurs doivent être utilisés de telle façon que les modifications soient effectuées via une couche Intégration d'applications d'entreprise gérant les translations de toutes les informations transmises entre les systèmes. En d'autres termes, avant de récrire les fonctionnalités réutilisables de WebSphere Product Center pour traiter les informations transmises via Intégration d'applications d'entreprise, nous devrions tirer parti de la plateforme Intégration d'applications d'entreprise, capable d'effectuer toute translation et ne nécessitant pas de récrire toutes les fonctionnalités incluses dans WebSphere Product Center.
Echelonnement de l'implémentation
Mini-intégrations
La tâche importante d'une intégration globale doit être décomposée en tâches plus réduites et facilement administrables. Par exemple, cela peut s'effectuer en décomposant une intégration complète en plusieurs intégrations réduites : intégrations "séparées" pour chaque type d'article (spécification), intégrations pour chaque conteneur (catalogue) et intégrations pour un groupe d'attributs (si nécessaire). Une fois le fonctionnement de ces "mini-intégrations" garanti sans défauts, elles peuvent être combinées et former l'intégration complète.
Granularité de la fonctionnalité
Une attention particulière doit être donnée aux niveaux auxquels doit survenir l'intégration entre les systèmes. Par exemple, lors de l'envoi de modifications à un système cible, il serait judicieux de pouvoir envoyer toutes les modifications depuis une date particulière, uniquement les modifications d'un catalogue particulier depuis l'envoi des dernières modifications, uniquement les modifications survenues dans un groupe d'articles spécifique ou uniquement les modifications survenues dans un attribut spécifique partagé par tous les articles. Les exigences spécifiques dépendent de l'implémentation mais il est important de prendre rapidement en considération la granularité requise dans le processus de conception de l'implémentation, afin qu'elle soit correctement définie.
Réglage des performances
Commentaires sur les performances générales
Ne sous-estimez pas les problèmes de performances. il est facile de modifier et réparer les formats d'autres aspects de l'intégration plus tardivement. Cependant, un goulot d'étranglement de performances peut nécessiter une reconception importante et l'implication des ingénieurs. Insérez des points de mesure de performances dans les scripts en cours de développement.
Mesure des performances
Lors des mini-intégrations (détaillées dans la section Implémentation), les performances doivent être mesurées à chaque étape de l'intégration. Pour ce faire, il s'agit de mesurer le temps nécessaire à l'exécution de chaque tâche de la mini-intégration. Les zones potentielles de performances médiocres peuvent ainsi être identifiées à un niveau granulaire approprié et plus facilement ciblées en vue d'une mise au point des performances.
Mise au point des performances
Une fois les zones posant des problèmes de performances identifiées, une analyse détaillée doit être effectuée pour déterminer l'origine de la lenteur de fonctionnement. Une analyse détaillée peut être effectuée grâce à des outils tels que le profilage du logiciel intermédiaire de WebSphere Product Center et l'onglet de performances de l'écran des détails du travail. L'analyse peut alors se concentrer sur une zone particulière d'un script ou d'une requête SQL et l'action appropriée peut être prise (modification ou réécriture du script, ou implication des ingénieurs pour optimiser la requête de base de données).
Validation
Stabilité
Avantages des mini-intégrations
L'implémentation de mini-intégrations (détaillées dans la section Implémentation) doit fournir un niveau de confiance supérieur permettant d'affirmer que l'intégration a été effectuée avec succès, en fournissant une liste détaillée de toutes les zones dans lesquelles l'intégration a fonctionné. Sans la visibilité des mini-intégrations, il est plus difficile d'obtenir les détails du fonctionnement de l'intégration. En outre, la totalité de l'intégration est, dans ce cas, plus exposée à des problèmes difficiles à identifier, diagnostiquer et déboguer. L'implémentation de mini-intégrations améliore la stabilité globale de l'intégration.
Test évolutif
Avantages des mini-intégrations
L'implémentation de mini-intégrations (détaillées dans la section Implémentation) permet de lancer le test de l'intégration à un niveau de détail plus précis, afin que toutes les erreurs ou tous les problèmes qui y surviennent ne soient pas masqués par un niveau de complexité trop important (et potentiellement inutile). Par conséquent, et tel que cela est mentionné ci-avant, les processus de diagnostic, débogage et résolution de problèmes détectés sont grandement accélérés grâce aux mini-intégrations.
Environnements représentatif ou complet
Le test d'intégration doit s'effectuer dans un environnement représentatif possédant la même configuration que l'environnement final (spécifications, règles de validation, règles de valeur, vues identiques) et un minimum d'entités représentatives (paramètres nationaux, catalogues, arbres de catégorie, article, catégories, organisations, utilisateurs, rôles). Cela permet de réduire le temps nécessaire à l'exécution des tests et au chargement des écrans. De plus, cela permet en général d'accélérer la durée du test par rapport à un test en environnement totalement renseigné. Tous les tests et les débogages doivent s'effectuer dans cet environnement.
L'intégration n'est vérifiée dans un environnement complet et totalement renseigné qu'après un test totalement concluant dans un environnement représentatif. Cependant, cette étape doit toujours être effectuée afin de garantir qu'aucun scénario annexe n'a été accidentellement ignoré dans l'environnement représentatif et de tester les performances de production de l'intégration.
Test de processus évolutif
Tout travail planifiable (par exemple, importations, exportations) doit d'abord être exécuté sur un petit nombre d'articles représentatifs (10 maximum). Ce nombre peut augmenter en fonction du niveau de confiance obtenu dans le script qui traite ces articles. Cela vous permet de garantir qu'un travail volumineux n'est pas exécuté pendant des heures pour aboutir à une défaillance. Ainsi, le processus ne connaîtra pas de défaillances dès les premières minutes de l'exécution.
Le travail ne doit être exécuté avec un jeu complet de données qu'après avoir déterminé le niveau de confiance du fonctionnement du script associé au travail. Tout comme la recommandation concernant l'environnement complet, cette étape doit être effectuée afin de garantir qu'aucun scénario annexe n'a été accidentellement ignoré dans les exécutions de travaux moins importants et de tester les performances de production du travail.
Visibilité
Génération de rapport
Avantages des mini-intégrations
L'implémentation de mini-intégrations (détaillées dans la section Implémentation) permet d'obtenir un niveau de génération de rapports plus détaillé en raison de tranches d'intégration plus réduites et plus rapidement exécutables. Si on le compare à la génération de rapports sur le progrès de l'implémentation au niveau de l'intégration complète, ce niveau de génération de rapports plus précis permet d'obtenir un suivi plus concret et quantitatif de l'implémentation.
Les mini-intégrations peuvent être listées et leurs relations au niveau de la globalité de l'intégration peuvent être détaillées dans un graphique. Ainsi, une image précise de la progression globale de de l'implémentation est facilement disponible à partir de la génération de rapports sur le progrès des tâches de mini-intégration.
Propriété
Même lors de travaux avec plusieurs équipes, attribuez la propriété à une personne de l'intégration. Cette personne est chargée de garantir que l'unité d'exécution unique est rapidement établie, que les équipes travaillent conformément aux instructions de ce document et que le cycle de conception incrémentielle/test dans les (a) mini-intégrations, (b) le test de processus évolutif et (c) les environnements représentatif ou complet est synchronisé entre les différentes équipes.
Documentation
Identification claire des formats et méthode
Décidez d'une méthode d'exécution claire et documentez clairement tous les formats qui seront utilisés lorsque plusieurs équipes travaillent sur l'intégration. Par exemple, une équipe de WebSphere Product Center travaille sur les données d'exportation depuis WebSphere Product Center, tandis qu'un client ou une équipe SI travaille sur le téléchargement de ces données dans un système cible. Ne commencez pas à travailler sans avoir défini de spécifications pour le format commun et mettez cette documentation à jour quotidiennement. Il s'agit d'une obligation absolue que le chef de projet doit imposer.
Cette méthode n'est pas incompatible avec l'utilisation d'environnements représentatifs et l'exécution de mini-intégrations. Les deux équipes doivent effectuer une conception et des tests de façon incrémentielle pour garantir une progression régulière et visible.
Utilisation d'une terminologie claire et commune pour décrire les intégrations
Toutes les implémentations doivent utiliser les dimensions présentées dans la section Dimensions d'intégration.
Possibilité de réutilisation
La clé de l'évolutivité tient dans l'expérience acquise lors des intégrations précédentes et dans le regroupement des intégrations, en gardant à l'esprit les principes de possibilité de réutilisation décrits dans la section Possibilité de réutilisation.
Visibilité
Instaurez un système de mesure global permettant de générer des rapports de progression et de fournir un point précis sur la situation à intervalles réguliers au responsable de projet.
Mini-intégrations
Segmentez la complexité d'une intégration importante en fonction des différentes dimensions (catalogues, attributs) qui composent cette intégration. Concentrez-vous sur une mini-intégration à la fois et mettez cette mini-intégration en relation directe avec le système de mesure de visibilité.
Environnements représentatif ou complet
Conservez un environnement représentatif permettant d'exécuter facilement débogages et tests. N'accédez à l'environnement complet qu'après avoir testé le niveau de confiance de la validité des scripts et des spécifications dans l'environnement représentatif. Etablissez une relation avec le système de mesure.
Test de processus évolutif
Testez tous les travaux avec de petits jeux de données pour vérifier leur exactitude avant de les utiliser avec des jeux de données complets. Etablissez une relation avec le système de mesure.
Performances
Sans tenir compte de l'exactitude de la logique ou du formatage, exécutez des tests de performances rapidement lors du cycle de développement, puis régulièrement ensuite pour identifier les problèmes.
Etablissement rapide d'une unité d'exécution unique
Etablissez rapidement une unité d'exécution unique, particulièrement dans les intégrations complexes nécessitant plusieurs tronçons, protocoles ou moyens non standard.
Spécifications et documentation de la conception
Définissez et documentez une méthode d'exécution claire et documentez clairement les formats qui seront utilisés, particulièrement lorsque plusieurs équipes travaillent sur l'intégration.
Propriétaire unique
Même lors de travaux avec plusieurs équipes, attribuez la propriété à une personne de l'intégration.
Méthode
Format de communications générique
Dans la mesure du possible, un format de communication générique doit être conçu ou réutilisé à partir d'un projet précédent. Plus le format est général, plus nombreux sont les systèmes à pouvoir être intégrés sans retouche spéciale des formats, afin que tous les systèmes puissent communiquer entre eux. Bien sûr, lorsqu'un format devient général, des compromis de performances doivent être faits. Le format peut être adapté à un projet et ne pas l'être dans un autre cas de figure. Les dimensions d'intégration doivent toujours être prises en compte lors de la détermination d'un format spécifique à utiliser.
Mises en correspondance de contenu
Dans la mesure du possible, les mises en correspondance entre le modèle de contenu de WebSphere Product Center et le modèle du format de communication doivent être effectuées via des moyens dynamiquement actualisables. Ici encore, une recherche des dimensions d'intégration permettra de conclure que certaines exigences de projet empêchent la mise à jour dynamique de toutes ces mises en correspondance, en raison d'une priorité haute placée sur le rendement maximum absolu du traitement, par exemple. Pour ce faire, vous pouvez utiliser les arbres de catégorie (représentant une structure XML, par exemple) reliés à une spécification à noeud unique qui peut indiquer le chemin du noeud de spécifications de l'attribut d'un noeud particulier des correspondances de l'arbre de catégorie du modèle contenu dans WebSphere Product Center. Un script de traitement récurrent peut être utilisé pour traiter la mise en correspondance d'un article dans un fichier XML basée sur cet arbre de catégorie et ses mises en correspondance définies. Il peut même fournir facilement des occurrences multiples imbriquées.
Conversion / Transformation des informations
Les systèmes impliqués dans l'intégration ne doivent pas avoir besoin de gérer par eux-mêmes les restrictions d'informations ou de contenu et les exigences des autres systèmes dans l'intégration. Les plateformes Intégration d'applications d'entreprise peuvent être immédiatement utilisées pour gérer la translation et la transformation de ce contenu. Par exemple, tandis que WebSphere Product stocke une valeur FLAG "TRUE" ou "FALSE", un système d'intégration peut stocker la valeur "Y" ou "N". Les plateformes Intégration d'applications d'entreprise peuvent être utilisées pour effectuer ces translations de telle manière que WebSphere Product Center puisse toujours envoyer une valeur TRUE/FALSE tandis que les systèmes intégrés puissent toujours envoyer une valeur Y/N. Cela permet de garantir que, si plus de systèmes sont impliqués dans l'intégration, aucun recodage n'est requis pour ces systèmes complémentaires.
Compréhension du client
Puisque nous pouvons réutiliser une plateforme qu'un client est habitué à utiliser, ce client sera d'autant plus confiant que l'intégration utilise une fonctionnalité connue : la plateforme Intégration d'applications d'entreprise. En outre, si un format de communication spécifique au client existe déjà et qu'il est réutilisé dans le cadre de l'intégration à WebSphere Product Center, les développeurs du côté du client n'auront besoin que d'un minimum de formation (voire aucune) pour comprendre le format de communication avec lequel WebSphere Product Center établira la mise en correspondance.
Flexibilité et fiabilité des communications
La plupart des plateformes Intégration d'applications d'entreprise disposent d'une fonctionnalité native permettant des communications sur divers protocoles et de garantir la livraison par courtage de ces communications. Cela permet à WebSphere Product Center de se concentrer sur la génération du document à communiquer et ne de pas s'occuper de l'éventuelle prise en charge des différents moyens permettant de communiquer ce document à divers systèmes. Il ne se charge pas non plus de vérifier si le document a été reçu ou non par le système (la couche et la plateforme Intégration d'applications d'entreprise s'en chargent), WebSphere Product Center n'ayant besoin que d'être informé par eux au niveau des unités d'exécution d'intégration).
IBM peut ne pas fournir les produits, services ou fonctions abordés dans ce document dans tous les 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 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 ce document ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Vous pouvez adresser des demandes de licence par écrit à l'adresse suivante :
Direction des licences IBM
IBM Corporation
Tour Descartes
92066 Paris-La Défense Cedex 50
France. Pour le Canada, veuillez adresser votre courrier à : IBM Director of Commercial Relations IBM Canada Ltd 3600 Steeles Avenue East Markham, Ontario L3R 9Z7, Canada
Le paragraphe suivant ne s'applique pas au Royaume-Uni ni dans aucun autre pays où de telles dispositions sont contraires à la législation locale :
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT. IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE NON-CONTREFACON ET 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. Les informations contenues dans ce document sont régulièrement mises à jour ; ces modifications seront incorporées dans les nouvelles éditions. IBM se réserve le droit d'apporter à tout moment et sans préavis des améliorations et/ou des modifications au(x) produit(s) et/ou programme(s) décrit(s) dans cette publication.
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 titulaires de licence de ce logiciel qui souhaiteraient obtenir des informations relatives à l'utilisation du logiciel pour permettre : (i) l'échange d'informations entre logiciels créés de façon indépendante et d'autres logiciels (y compris celui-ci) et (ii) l'utilisation mutuelle des informations qui ont été échangées, doivent contacter :
IBM Burlingame Laboratory
Director IBM Burlingame Laboratory
577 Airport Blvd., Suite 800
Burlingame, CA 94010
U.S.A
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux dispositions de l'ICA, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas nécessairement testé ces produits et ne peut pas confirmer l'exactitude des performances, de la compatibilité ou de toute autre déclaration liée aux produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
Ces informations peuvent contenir des exemples de données et des rapports utilisés dans des opérations commerciales courantes. Pour les illustrer le mieux possible, les exemples peuvent comporter des noms de personnes, de sociétés, de marques et de produits. Toute ressemblance avec des noms de personnes, de sociétés ou des données réelles serait purement fortuite.
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.
Les informations relatives à l'interface de programmation, le cas échéant, ont pour objectif de vous aider à créer une application à l'aide de ce programme.
Les interfaces de programmation génériques vous permettent d'écrire une application bénéficiant des services des outils de ce programme.
Cependant, ces informations peuvent également contenir des informations relatives au diagnostic, à la modification et au réglage. Les informations de diagnostic, de modification et de réglage sont fournies afin de vous aider à déboguer l'application.
Avertissement : n'utilisez pas ces informations en tant qu'interface de programmation, car elles sont susceptibles d'être modifiées.
Les termes suivants sont des marques d'International Business Machines Corporation aux Etats-Unis et/ou dans d'autres pays :
IBM
le logo IBM
AIX
CrossWorlds
DB2
DB2 Universal Database
Domino
Lotus
Lotus Notes
MQIntegrator
MQSeries
Tivoli
WebSphere
Microsoft, Windows, Windows NT et le logo Windows sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.
MMX, Pentium et ProShare sont des marques d'Intel Corporation aux Etats-Unis et/ou dans certains autres pays.
Java et les marques Java sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
D'autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document.
IBM WebSphere Product Center contient certains composants dits
exclus (tels qu'ils sont définis
dans le document d'informations sur la licence approprié), pour
lesquels les dispositions supplémentaires
suivantes sont applicables. Ce logiciel fait l'objet de l'octroi
d'une licence en vertu des
Conditions Internationales d'Utilisation de Logiciels IBM, qui est
soumise aux
dispositions relatives aux composants exclus. IBM est dans
l'obligation de fournir les consignes
suivantes en relation avec ce logiciel :
i.) IBM WebSphere Product Center inclut le logiciel suivant dont IBM
a obtenu la licence d'Apache Software Foundation en application des termes et
conditions de la licence d'Apache 2.0 :
- Apache Regular Expression version 1.2
- Apache Axis version 1.1
- Apache XML4J version 3.0.1
- Apache Log4j version 1.1.1
- Apache Jakarta Commons DBCP Package version 1.1
- Apache Jakarta Commons Pool Package version 1.1
- Apache Jakarta Commons Collections Package version 3.0
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION,
AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement You may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of Your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to Your work.
To apply the Apache License to Your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with Your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [aaaa] [nom du détenteur de copyright]
Licensed under the Apache License, Version 2.0 (the "License");
You may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
ii.) IBM WebSphere Product Center inclut le logiciel suivant dont IBM
a obtenu la licence de Scott Hudson, Frank Flannery et C. Scott Ananian dans
les termes et conditions suivants :
- Cup Parser Generator version 0.10k
CUP Parser Generator Copyright Notice,
License, and Disclaimer
Copyright 1996-1999 by Scott Hudson, Frank Flannery, C. Scott Ananian
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided that
the above copyright notice appear in all copies and that both the copyright
notice and this permission notice and warranty disclaimer appear in supporting
documentation, and that the names of the authors or their employers not be
used in advertising or publicity pertaining to distribution of the software
without specific, written prior permission. The authors and their employers
disclaim all warranties with regard to this software, including all implied
warranties of merchantability and fitness. In no event shall the authors or
their employers be liable for any special, indirect or consequential damages
or any damages whatsoever resulting from loss of use, data or profits, whether
in an action of contract, negligence or other tortious action, arising out of
or in connection with the use or performance of this software.
iii.) IBM WebSphere Product Center inclut le logiciel suivant dont IBM
a obtenu la licence d'Elliot Joel Berk et C. Scott Ananian dans les
termes et conditions suivants :
- JLex version 1.2.6
JLEX COPYRIGHT NOTICE, LICENSE AND DISCLAIMER.
Copyright 1996-2003 by Elliot Joel Berk and C. Scott Ananian
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided that
the above copyright notice appear in all copies and that both the copyright
notice and this permission notice and warranty disclaimer appear in supporting
documentation, and that the name of the authors or their employers not be used
in advertising or publicity pertaining to distribution of the software without
specific, written prior permission. The authors and their employers disclaim
all warranties with regard to this software, including all implied warranties
of merchantability and fitness. In no event shall the authors or their
employers be liable for any special, indirect or consequential damages or any
damages whatsoever resulting from loss of use, data or profits, whether in an
action of contract, negligence or other tortious action, arising out of or in
connection with the use or performance of this software. Java is a trademark
of Sun Microsystems, Inc. References to the Java programming language in
relation to JLex are not meant to imply that Sun endorses this product.
iv.) IBM WebSphere Product Center inclut le logiciel suivant dont IBM
a obtenu la licence d'International Business Machines Corporation et autres
dans les termes et conditions suivants :
- ICU4J version 2.8
ICU License - ICU 1.8.1 and later
COPYRIGHT AND PERMISSION NOTICE
Copyright (c) 1995-2003 International Business Machines Corporation and others
All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, and/or sell copies of the Software, and to permit persons
to whom the Software is furnished to do so, provided that the above
copyright notice(s) and this permission notice appear in all copies of
the Software and that both the above copyright notice(s) and this
permission notice appear in supporting documentation.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL
INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING
FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Except as contained in this notice, the name of a copyright holder
shall not be used in advertising or otherwise to promote the sale, use
or other dealings in this Software without prior written authorization
of the copyright holder.
Toutes les marques mentionnées dans le présent document appartiennent à
leurs propriétaires respectifs.