Identification et résolution de problèmes liés au déploiement

Vous pouvez identifier et résoudre des problèmes courants lors du déploiement de modèles dans IBM® SOA Policy Gateway Pattern.

Echec de la connexion à DataPower au cours du déploiement

Essayez les solutions suivantes :

Identification et résolution de l'échec d'authentification de client s'agissant d'une authentification mutuelle

Essayez les solutions suivantes :

identification et résolution de l'échec d'authentification de serveur

Essayez les solutions suivantes :

Identification et résolution d'une erreur pour le domaine déjà existant

Essayez la solution suivante :

Identification et résolution de l'erreur de chevauchement de ports (port overlap) pour l'exemple d'application

Si l'un des exemples de services n'est pas disponible, vérifiez si les ports dans votre domaine sont en conflit avec d'autres domaines.
Essayez les solutions suivantes :
  • Ouvrez une session dans DataPower et passez à l'exemple de domaine. Puis, ouvrez le panneau de commande, puis cliquez sur l'icône du pare-feu XML (XML Firewall). Vérifiez que les pare-feux XML sont tous à l'état Up (Actif).
  • Recherchez un gestionnaire HTTP Front Side Handler. Vérifiez que le gestionnaire HTTP Front Side unique est à l'état Actif.

Identification et résolution de l'échec de connexion à SCP

Essayez les solutions suivantes :

Identification et résolution de l'échec d'extraction du fichier DomainZipFile.zip à partir du SCP ou du débogage des artefacts manquants

Essayez les solutions suivantes :

Identification et résolution de l'échec de promotion

De nombreux problèmes peuvent survenir dans une promotion, notamment l'échec de la connexion au maître de gouvernance au cours du déploiement.
Essayez les solutions suivantes :
  • Vérifiez les paramètres :
    • Vérifiez l'utilisateur du maître de gouvernance WSRRCELL.
    • Vérifiez le mot de passe de l'utilisateur de la cellule du maître de gouvernance WSRR.
    • Vérifiez le nom d'hôte de la cellule du maître de gouvernance WSRR.
    • Vérifiez le nom de cellule (CELL) de la cellule du maître de gouvernance WSRR.
  • Vérifiez l'échange de certificat de signataire :
    • Accédez à CellDefaultTrustStore de la cellule du maître de gouvernance et vérifiez qu'il existe une entrée de certificat pour le Dmgr ou que le serveur autonome de l'environnement d'exécution, SOA Policy Gateway Basic Runtime ou SOA Policy Gateway Advanced Runtime, existe.
    • Accédez à l'environnement d'exécution, SOA Policy Gateway Basic Runtime ou SOA Policy Gateway Advanced Runtime, puis vérifiez CellDefaultTrustStore (dans le cas d'un environnement de déploiement réseau (ND)) ou NodeDefaultTrustStore (pour des serveurs autonomes WSRR) pour vous assurer qu'il existe un certificat pour le Dmgr du maître de gouvernance (Governance Master).
    • Exportez les clés LTPA à partir des deux cellules en utilisant le même mot de passe, puis vérifiez qu'ils sont identiques (par exemple, en comparant le nombre d'octets).
  • Vérifiez que le fichier des propriétés de promotion contient des sections de serveur avec l'hôte et le port appropriés, ainsi que les informations d'utilisateur et de mot de passe. Vous pouvez trouver ces informations dans la console ServiceRegistry pour le maître de gouvernance :
    • Accédez à GovernanceMasterDMgrHost ou ServiceRegistry, puis à la perspective des configurations. Dans la section Actions, recherchez Promotion, puis ouvrez le fichier de propriétés de promotion. Pour chaque environnement, il doit exister des éléments XML pour chaque serveur dans le noeud ou cluster WSRR de transfert. Si un cluster ou noeud de production existe, il doit exister des entrées de port de serveur pour chacun d'eux, en outre, il doit y avoir des informations d'utilisateur et de mot de passe.
  • Vérifiez que la version de service et le noeud final SOAP disposent tous les deux d'une classification de transfert ou de production.
    • Dans la console Service Registry, sélectionnez la perspective de gouvernance SOA. Ouvrez la version de service, puis sélectionnez l'onglet Classifications. Staging (transfert) et Production doivent être activés.

Identification et résolution des échecs d'interfaces CLI personnalisées

Essayez les solutions suivantes :

Identification et résolution de défaillances SSL dues à des certificats DataPower manquants.

Si vous n'avez pas indiqué dans le fichier DomainZipFile.zip le nom d'hôte correct pour votre répertoire de certificats DataPower Certificates, les packages de script échoueront dans l'établissement de la connexion avec le serveur WSRR si une authentification de serveur ou mutuelle est activée sur l'hôte DataPower.

Identification et résolution des incidents de connexion WSRR/DataPower

Si vous voyez que le statut de WSDL dans un proxy de services Web (Web Service Proxy) indique un état Down (Arrêt) ou Synchronizing (Synchronisation) et qu'il ne change jamais pour Okay, procédez aux vérifications suivantes :
  1. Vérifiez que Crypto Certificate est valide pour le serveur WSRR (WSRRSVR).
  2. Vérifiez que DataPower dispose du serveur de noms de domaine (DNS) approprié et configuré pour reconnaître le nom d'hôte (Hostname) du serveur WSRR ou du Dmgr.
  3. Si le serveur de noms de domaine (DNS) est incorrect, une solution de contournement temporaire consiste à changer l'adresse URL dans la définition du serveur WSRR pour pointer directement sur l'IP en substituant le nom d'hôte (HostName) par l'IP dans l'adresse URL.
  4. Accédez à WSRR Subscription (Abonnement WSRR) et effectuez une synchronisation manuelle :
    1. Recherchez dans default.log des erreurs relatives à la connectivité du serveur WSRR.
  5. Vérifiez que les certificats requis correspondent à ceux qui figurent dans les données d'identification pour le profil Crypto du profil de proxy SSL de l'interface XMLManagement des dispositifs DataPower.

Concept Concept

Commentaires


Icône d'horodatage Dernière révision: 16 octobre 2012


http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr.doc/topics/csoa2_troubleshoot_deployment.htm