Conseils d'identification et de résolution des incidents liés aux services Web activés par un bus

Suivez ces conseils pour identifier et résoudre les incidents liés aux services Web activés par un bus d'intégration de services.

[z/OS]Pour faciliter l'identification et la résolution des incidents des services Web activés par un bus, utilisez les fonctions de trace et de consignation de WebSphere Application Server comme indiqué dans Configuration du service de trace des composants (CTRACE).

Pour activer la fonction de trace pour les services Web activés par un bus, définissez la chaîne de fonction de trace du serveur d'applications, com.ibm.ws.sib.webservices.*=all=enabled. Si un problème qui semble être lié aux services Web activés par un bus se produit, recherchez les éventuels messages d'erreur dans la console d'administration WebSphere Application Server et le fichier SystemOut.log du serveur d'applications. Vous pouvez également activer la trace de débogage du serveur d'applications pour fournir un vidage détaillé des exceptions.

La liste des principales limitations connues s'appliquant lors de l'utilisation des services Web activés par un bus se trouve dans la rubrique Services Web activés par un bus : Limitations connues.

Les messages système WebSphere Application Server sont journalisés à partir de nombreuses sources, y compris les applications et composants de serveur d'applications. Les messages consignés par les composants de serveur d'applications et les produits IBM associés commencent par un identificateur de message unique qui indique le composant ou l'application à l'origine du message. Le préfixe du composant des services Web activés par un bus est CWSWS.

La rubrique Messages contient des informations sur tous les messages WebSphere Application Server, indexées par préfixe de message. Une explication de l'incident et des détails sur les éventuelles actions à entreprendre pour résoudre l'incident sont fournis pour chaque message.

Conseils non relatifs à la sécurité :

Les services Web activés par un bus ne peuvent pas se connecter à un bus d'intégration de services sécurisé.

Lorsque le composant des services Web activés par un bus ne peut pas se connecter à un bus sécurisé, le message d'erreur suivant apparaît pendant le démarrage du serveur (dans le fichier SystemOut.log du serveur d'applications) lorsque l'adaptateur des ressources d'intégration de services tente de se connecter à la destination du bus :
CWSIV0801E : L'exception javax.resource.ResourceException : 
CWSIV0958E : L'exception d'autorisation 
com.ibm.wsspi.sib.core.exception.SINotAuthorizedException : 
CWSIP0302E : Un utilisateur du serveur hôte n'est pas autorisé à accéder au moteur de messagerie 
xyzNode01.server1-xyz sur le bus xyz. a été émise lors de la tentative de création d'une 
connexion au moteur de messagerie 221C86B845BE5E8B à l'aide de la spécification 
d'activation [<trace_zone_spécification_activation>]. 
a été émise lors de la création d'une connexion au moteur de messagerie xyzNode01.server1-xyz sur le bus xyz.

Par défaut, le composant des services Web activés par un bus peut se connecter à une destination de bus sécurisée via l'adaptateur des ressources d'intégration de services. Par conséquent, la configuration a dû être modifiée d'une façon ou d'une autre.

La configuration par défaut que les services Web activés par un bus utilisent pour accéder au bus sécurisé est la suivante :
  • L'accès à un bus est configuré via le rôle de connecteur de bus. Par défaut, chaque rôle de connecteur de bus inclut un groupe appelé serveur. Les membres de ce groupe sont autorisés à se connecter au bus.
  • L'adaptateur de ressources d'intégration de services utilise une spécification d'activation J2C pour communiquer avec le bus. Par défaut, cette spécification d'activation possède la propriété personnalisée booléenne useServerSubject à laquelle la valeur true est attribuée. Cette propriété permet à l'adaptateur de ressources d'intégration de services de se connecter au bus en tant que sujet (membre) du groupe de serveurs.

Vous pouvez remplacer cette configuration par défaut en définissant un alias d'authentification que l'adaptateur de ressources d'intégration de services utilise pour accéder au bus. Pour plus d'informations, voir Remplacement de la configuration de sécurité par défaut entre les services Web activés par un bus et un bus sécurisé.

Pour obtenir des informations détaillées sur la configuration par défaut, et sur les conséquences de la modification ou du remplacement de cette configuration, voir Configuration par défaut des services Web activés par un bus pour l'accès à un bus sécurisé.

Pour réduire la zone du problème, définissez la chaîne de trace du serveur d'applications sur com.ibm.ws.sib.webservices.*=all=enabled, car plusieurs composants peuvent être la cause du problème. Dans la trace, vérifiez SibRaMessagingEngineConnection.createConnection() :
  • La phrase Création d'une connexion avec un ID utilisateur et un mot de passe indique que le système a trouvé et tente d'utiliser un alias d'authentification configuré pour la spécification d'activation J2C.
  • La phrase Aucun ID utilisateur/mot de passe transféré. Création d'une connexion à l'aide d'un sujet de serveur indique le système a trouvé et tente d'utiliser le sujet de serveur.

Le bus d'intégration de services arrive à expiration, tandis qu'un service sortant attend la réponse d'un service cible

L'erreur suivante peut se produire dans le bus d'intégration de services quand un service sortant attend une réponse d'un service Web cible :
java.net.SocketTimeoutException : L'opération du connecteur a expiré avant qu'elle ne soit terminée

Le délai d'attente par défaut est de 60 secondes. Par conséquent, cette erreur se produit donc si le service Web cible met plus de 60 secondes pour répondre. Vous pouvez augmenter la valeur du délai d'attente en définissant une propriété personnalisée de délai d'attente sur le port de communications entrantes, tel que défini dans Ports entrants [Paramètres].

Une application ou une ressource de services Web activés pour un bus doit être installée manuellement

Les ressources et les applications de services Web activés par un bus suivantes sont installés automatiquement lorsqu'elles sont requises pour la première fois :
  • L'application de services Web activés par un bus (application qui permet de configurer et d'accéder aux services Web via un bus d'intégration de services).
  • L'adaptateur de ressources des technologies d'intégration de services (utilisé pour appeler les services Web sur les ports sortants).
  • Les applications de module d'écoute de noeud final (utilisées pour activer les noeuds finaux sur lesquels les messages des services de communications entrantes sont reçus).
Par exemple, une application de module d'écoute de noeud final est installée dans le cadre du processus de création de la configuration d'un nouveau module d'écoute de noeud final.

Toutefois, si vous devez installer manuellement l'une de ces applications, vous pouvez le faire à l'aide du script sibwsInstall.jacl fourni, puis en suivant les instructions de la rubrique WebSphere Application Server Version 6.0.x : Installation d'applications et de ressources de services Web activés par un bus.

L'application client fonctionne sous WebSphere Application Server Version 5.1, mais il existe des problèmes avec les versions ultérieures

Vous disposez d'une application client qui fonctionne sous WebSphere Application Server Version 5.1 mais des problèmes surviennent dans les versions ultérieures en raison de demandes ou de réponses mal structurées.

Les services Web activés par un bus vérifient plus en détail la validité des messages des services Web que dans WebSphere Application Server Version 5.1. Suite à ces opérations, certaines applications client qui utilisent des demandes ou des réponses dont la syntaxe est incorrecte (où les noms des parties de message sont incorrects) et qui fonctionnent avec Version 5.1 sont identifiées comme ayant une syntaxe incorrecte dans les versions ultérieures. Pour connaître les étapes à suivre pour résoudre l'incident, voir Tolérance des messages SOAP dont la syntaxe est incorrecte.

Erreur lorsque le client JAX-RPC qui s'exécute sous WebSphere Application Server Version 5.1 utilise SOAP sur JMS pour appeler un service Web

Un client JAX-RPC en cours d'exécution sur WebSphere Application Server Version 5.1 utilise SOAP sur JMS pour appeler un service Web en cours d'exécution sur un serveur d'applications version 5. Aucun ID utilisateur ou mot de passe n'est requis sur la file d'attente MQ Series cible. Une fois le serveur d'applications migré vers une version ultérieure et lorsque vous utilisez la messagerie par défaut, les demandes client n'aboutissent pas car l'authentification de base est activée.

Le problème se manifeste par le message suivant dans le journal :
SibMessage W [:] CWSIT0009W: Une requête client a échoué sur le 
serveur d'applications avec le noeud final <nom_noeud_final> dans le bus votre_bus 
pour la raison suivante : CWSIT0016E: L'authentification de l'ID utilisateur n'a pas abouti 
dans le bus votre_bus.

Pour connaître la procédure à suivre pour résoudre l'incident, voir le conseil de résolution des incidents pour les technologies d'intégration de services suivant : Migration d'un serveur d'applications Version 5.1 vers WebSphere Application Server Version 7.0 ou ultérieures

Message d'erreur lors de la tentative de création d'une base de données Informix à utiliser avec le référentiel SDO

Vous avez effectué une tentative infructueuse de création de base de données Informix à utiliser avec le référentiel SDO et vous avez reçu le message No Transaction Isolation on non-logging databases.

Si le message indiquant qu'il n'existe aucun isolement de transaction dans les bases de données autres que celles de journalisation s'affiche dans le message d'exception, cela est dû au fait que la journalisation est désactivée dans la base de données Informix utilisée. Pour utiliser une base de données Informix avec le référentiel SDO, vous devez activer la journalisation.

Le texte complet de l'exception est le suivant :
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; 
nested exception is:
org.omg.CORBA.TRANSACTION_ROLLEDBACK: 
javax.transaction.TransactionRolledbackException: ; 
nested exception is:
javax.ejb.TransactionRolledbackLocalException:  ; 
nested exception is: 
com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: 
PMGR1013E : Exception lors de la vérification de l'ID du système dorsal en cours 
INFORMIX_V94: javax.resource.spi.ResourceAllocationException: 
DSRA0080E : Une exception a été reçue par l'adaptateur de stock de données. 
Voir le message de l'exception d'origine : 
Aucun isolement de transaction dans les bases de données autres que celles de journalisation, code d'erreur : 
DSA_ERROR, code d'erreur : DSA_ERROR vmcid : 0x0  code mineur : 0  
terminé : Non
La journalisation est désactivée par défaut, ainsi l'instruction de création de bases de données CREATE DATABASE SDOREP; génère une exception lors de l'exécution. Lorsque vous créez la base de données, utilisez une des instructions de création de base de données suivantes :
  • CREATE DATABASE SDOREP WITH LOG;
  • CREATE DATABASE SDOREP WITH BUFFERED LOG:
  • CREATE DATABASE SDOREP WITH LOG MODE ANSI;

Un service entrant publié sur un registre UDDI n'est pas répertorié et sa nouvelle publication échoue

Vous disposez d'un service de communications entrantes, en fonction de la console d'administration, publié sur un registre UDDI. Lorsque vous consultez le registre UDDI, vous constatez que le service n'en fait pas partie. Lorsque vous tentez d'utiliser la console d'administration pour publier à nouveau le service sur le registre UDDI, la tentative échoue.

Le service a été publié sur le registre UDDI et la configuration du service affichée dans la console d'administration de WebSphere Application Server inclut une clé de service UDDI, mais la publication du service a ensuite été annulée sans que la mise à jour correspondante ne soit appliquée à la configuration principale de WebSphere Application Server. Cette situation peut survenir lorsque vous utilisez la console d'administration pour supprimer un service de communications entrantes publié sur un registre UDDI puis que vous vous connectez de la console d'administration sans sauvegarder les modifications. Dans ce cas, l'annulation de la publication sur le registre UDDI du service est effectuée, mais le service n'est pas supprimé de WebSphere Application Server (car la demande de suppression n'est pas confirmée et n'est donc pas appliquée).

Pour mettre à jour les informations de configuration du service et publier à nouveau le service sur le registre UDDI, utilisez la console d'administration pour suivre la procédure ci-après.
  1. Dans le panneau de navigation, cliquez sur Intégration des services -> Bus -> nom_bus -> [Services] Services entrants -> nom_service. Les paramètres actuels de ce service de communications entrantes sont affichés.
  2. Cliquez sur Recharger le modèle de document WSDL puis sauvegardez les modifications.
  3. Cliquez sur Annuler la publication à partir d'UDDI puis sauvegardez les modifications.
  4. Cliquez sur Publier vers UDDI puis sauvegardez les modifications.
La nouvelle publication du service aboutit et ce dernier est installé à nouveau dans le registre UDDI.

WSDL doit être extrait via la ligne de commande si le bus doit transmettre des messages via un serveur proxy d'authentification pour extraire des documents WSDL

Si le bus doit transmettre les messages via un serveur proxy d'authentification pour extraire des documents WSDL, vous devez utiliser les outils de ligne de commande pour extraire le WSDL.

Ni les panneaux de la console d'administration utilisés pour créer une configuration de service Web, ni le bouton Recharger WSDL des panneaux utilisés pour modifier une configuration de service Web existante ne permettent d'entrer un alias d'authentification J2C pour l'extraction WSDL. C'est pourquoi, lorsque vous créez ou modifiez des services de communications entrantes et sortantes, si le bus doit transmettre des messages via un serveur proxy d'authentification pour extraire des documents WSDL, vous devez utiliser les outils de ligne de commande suivants pour extraire les éléments WSDL :

Lors de l'utilisation de JMS pour établir une connexion avec un bus distant, une configuration supplémentaire est requise pour permettre aux clients des services Web de se connecter au bus

Si vous utilisez JMS pour vous connecter à un bus distant, une configuration supplémentaire est requise pour permettre aux clients des services Web de se connecter au bus.

Une application client de service Web exécutée sur un serveur appartenant à un bus peut rechercher un moteur de messagerie dans ce bus. Une application client de service Web exécutée en dehors d'un serveur d'applications (par exemple, en dehors de l'environnement WebSphere Application Server) ne peut pas localiser directement un moteur de messagerie approprié auquel elle peut se connecter dans le bus cible. De même, une application client de service Web exécutée sur un serveur d'une cellule qui doit se connecter à un bus cible dans une autre cellule ne peut pas localiser directement un moteur de messagerie approprié auquel elle peut se connecter dans le bus cible.

Pour permettre à l'application client du service Web de contacter un moteur de messagerie cible d'un bus distant, configurez la fabrique de connexions JMS utilisée par le client de sorte que ce dernier puisse se connecter à un moteur de messagerie d'amorçage du bus distant. Le moteur de messagerie d'amorçage identifie alors le moteur cible et les informations requises pour accéder à ce dernier sont retransmises au client. Le processus d'amorçage n'est possible que si vous configurez un ou plusieurs noeuds finaux de fournisseur dans la fabrique de connexions utilisée par le client. Pour plus d'informations, voir Configuration d'une connexion à un serveur d'amorçage autre que celui par défaut.

Erreur liée à une insuffisance de mémoire dans la machine virtuelle Java lors de la transmission d'une pièce jointe volumineuse via le bus d'intégration de services

Vous transmettez une pièce jointe de grande taille via le bus d'intégration de services et recevez une erreur de mémoire insuffisante dans la machine virtuelle Java.

Si cette erreur se produit, augmentez la taille du segment, comme il est décrit dans la rubrique Optimisation des services Web activés par un bus.

Erreur lors de la tentative de création d'une nouvelle configuration de programme d'écoute de noeud final à l'aide de la console d'administration

Lorsque vous essayez de créer une configuration de programme d'écoute de noeud final via la console d'administration et que vous cliquez sur Nouveau dans le panneau de collecte des programmes d'écoute de noeud final, l'icône "Veuillez patienter" est affichée, mais le panneau cible n'apparaît pas.

Ce problème ne se produit que dans les versions antérieures du navigateur Web Mozilla. Migrez votre navigateur vers la version 1.4 ou une version ultérieure. Une solution consiste à cliquer à nouveau sur Nouveau ; le panneau cible est alors affiché.

Erreur lors de la tentative de création d'un nouveau service entrant via la console d'administration

Lorsque vous essayez de créer un service entrant via la console d'administration, la liste déroulante des destinations est vide et l'assistant vous arrête à l'étape 1 avec un message d'erreur vous demandant de sélectionner une destination.

Cela ne peut se produire que si le bus d'intégration de services sur lequel vous créez votre service de communications entrantes ne contient aucun moteur de messagerie. Créez un moteur de messagerie, créez une destination de service, puis exécutez de nouveau l'assistant pour créer une configuration de service de communications entrantes.

Erreur de syntaxe d'URL incorrecte lors de la tentative d'envoi d'un message SOAP via HTTPS

Vous essayez d'envoyer un message SOAP via HTTPS et vous recevez une erreur de syntaxe d'URL incorrecte.

Les technologies d'intégration de services peuvent utiliser SSL (Secure Sockets Layers) pour appeler des services Web externes qui comportent https:// dans leurs adresses. Pour plus d'informations, voir rubrique Appel de services sortants via HTTPS.

Erreurs de recherche JNDI lorsque des ressources JMS situées sur différentes machines possèdent les mêmes noms

Des erreurs de recherche JNDI sont générées lorsque vous utilisez les mêmes noms pour des files d'attente de messagerie JMS et des fabriques de connexions de file d'attente qui s'exécutent sur des serveurs d'applications installés sur des machines différentes.

Vous ne devez pas utiliser les mêmes noms pour les files d'attente de messagerie et les fabriques de connexions de file d'attente qui s'exécutent sur des serveurs d'applications installés sur des machines différentes, car les technologies d'intégration de services recherchent toujours en priorité les destinations JMS en local et n'utilisent la référence JNDI complète que si elles ne trouvent pas la destination en local. Si vous configurez comme service sortant un service Web hébergé sur une machine distante et que vous utilisez les mêmes noms pour les files d'attente de la messagerie et les fabriques de connexions de file d'attente sur la machine distante et sur la machine sur laquelle le service sortant est hébergé, les technologies d'intégration de services recherchent et utilisent les files d'attente locales, même si la destination JNDI éloignée est fournie intégralement dans la définition du service WSDL.

Erreur lors de l'installation du fichier sibwsauthbean.ear

Vous protégez à l'aide d'un mot de passe une opération de service Web, mais lorsque vous installez le fichier sibwsauthbean.ear, un message d'erreur s'affiche dans la console d'administration WebSphere Application Server. Ce message détaille un problème JNDI (Java Naming and Directory Interface).

Lorsque vous protégez à l'aide d'un mot de passe une opération de service Web, vérifiez que vous entrez, dans les "références EJB" du bean de la session d'autorisation, le nom JNDI correct du bean enterprise du service Web importé. Notez que la casse de ce nom doit être respectée.

Impossible de déterminer le problème précis à partir des messages d'erreur SOAP

Vous recevez des messages d'erreur SOAP mais ceux-ci ne vous permettent pas de déterminer la cause exacte du problème.

Si vous recevez un message d'erreur SOAP dont la chaîne d'erreur correspond à la valeur de l'un des paramètres de l'appel, cela signifie que cette valeur n'est pas valide. Par exemple, si l'un de vos services attend un paramètre int et que vous lui envoyez un message contenant la valeur "1.1", le message d'erreur que vous recevez contient 1.1 comme chaîne d'erreur :
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring>1.1</faultstring>

Ce message est cohérent avec le comportement SOAP Apache et ne peut pas être corrigé par les services Web activés par un bus.

Des erreurs de délai d'expiration dépassé sont générées lorsque des messages de grande taille sont transmis à l'aide du module d'écoute de noeud final SOAP sur JMS

Comme pour un module d'écoute de noeud final synchrones, des erreurs de délai d'expiration dépassé peuvent survenir. Pour minimiser la fréquence des erreurs de délai d'expiration dépassé, augmentez la valeur des paramètres du délai d'expiration pour le module d'écoute de noeud final. Si le problème persiste, désactivez la trace et la journalisation pour les technologies d'intégration de service en attribuant la valeur com.ibm.ws.sib.webservices.*=all=disabled à la chaîne de la trace du serveur d'applications.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rjw_prob0
Nom du fichier : rjw_prob0.html