Identification des autres problèmes
Cette section décrit les principaux problèmes et les causes possibles relatifs à des catégories différentes de celles mentionnées ci-dessus. Vous trouverez ci-dessous une liste des principaux problèmes. Si le problème que vous rencontrez n'apparaît pas dans la liste ou que les opérations proposées ne permettent pas de résoudre complètement le problème, contactez votre administrateur système.
• Impossible de créer un document (impossible de l'afficher dans Oracle Applications).
• Windchill ESI renvoie un message d'expiration de l'adaptateur.
• Windchill ESI a bien créé un ou plusieurs objets métier dans Oracle Applications, mais indique un échec.
• Windchill PDMLink ne peut pas s'abonner à une file d'attente EMS
• Des erreurs apparaissent dans PostResult.
• Aucune destination de publication n'a été affectée pour un objet publié.
• Aucune modification ne s'est produite depuis la dernière publication.
• Impossible de se connecter à TIBCO BusinessWorks ; EMS et/ou Windchill sont incapables de se connecter.
• Lorsque je consulte le journal des transactions ESI et le journal EAI, je constate qu'un échec se produit lors de la publication d'un objet avec Windchill ESI et qu'un message d'erreur apparaît en regard du/des objet(s) publié(s).
• Réponse aux conflits d'attributs principal/secondaire
• Expiration des adaptateurs TIBCO pour les transactions ESI
• Un message d'erreur de fichier de métadonnées de réponse ESI apparaît
• Le démarrage de l'agent ADB sur les serveurs Windows a échoué.
• La publication reste dans l'état "En attente" dans le Journal des transactions d'Enterprise
• Définir un ensemble d'objets métier via une demande de promotion entraîne la création d'un processus RTM pour chacun de ces objets.
• Le fichier réponse ESI qui est généré lors de la promotion d'un ou de plusieurs objets métier ne contient aucune information sur la demande de promotion, indépendamment de son ID.
Tibco BusinessWorks Designer affiche des erreurs de type "Cannot create Transport" et "Process Definition Load" au début de l'archivage de processus
Pour configurer BusinessWorks, procédez comme suit :
1. Sauvegardez le fichier
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
.
2. Dans un éditeur de texte, ouvrez le fichier
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
.
3. Recherchez la chaîne
tibco.env.CUSTOM_CP_EXT
.
4. Remplacez cette chaîne par
tibco.env.CUSTOM_CP_EXT %RV_HOME%/lib/tibrvj.jar:%RV_HOME%/lib:%RV_HOME%/lib/64:
.
|
Le chemin peut contenir des dossiers supplémentaires. Conservez ces entrées lorsque vous remplacez la chaîne.
|
5. Recherchez la chaîne
tibco.env.CUSTOM_LIB_PATH
.
6. Remplacez cette chaîne par
tibco.env.CUSTOM_LIB_PATH %RV_HOME%/lib:%RV_HOME%/lib/64:
.
|
Le chemin peut contenir des dossiers supplémentaires. Conservez ces entrées lorsque vous remplacez la chaîne.
|
7. Enregistrez et fermez designer.tra.
8. Ouvrez TIBCO Designer et lancez l'archivage.
Impossible de créer un document (impossible de l'afficher dans Oracle Applications).
Du fait des limitations de l'API d'Oracle Applications, Windchill ESI ne prend pas en charge la publication des documents (pièces jointes) vers Oracle Applications.
Windchill ESI renvoie un message d'expiration de l'adaptateur.
• La configuration de l'adaptateur est incorrecte.
• La destination ESI n'est pas valide.
• Les instances de l'adaptateur ne fonctionnent pas.
• Le serveur Oracle Applications n'est pas disponible.
• Le réseau est encombré entre l'adaptateur et Oracle Applications
|
Vous aurez peut-être besoin de l'aide de votre administrateur Windchill ESI pour résoudre ce problème.
|
Windchill ESI a bien créé un ou plusieurs objets métier dans Oracle Applications, mais indique un échec.
• La configuration de l'adaptateur est incorrecte.
• Windchill ESIa publié correctement le ou les objets, mais le délai d'attente d'affichage par Oracle Applications du message suivant de la table de consignation a été dépassé.
|
Vous aurez peut-être besoin de l'aide de votre administrateur Windchill ESI pour résoudre ce problème.
|
Windchill PDMLink ne peut pas s'abonner à une file d'attente EMS
Les causes possibles de ce problème sont les suivantes :
• Les services Windchill ESI ne sont pas installés correctement.
• Le serveur EMS ne fonctionne pas.
• Erreur réseau entre le serveur de méthode Windchill et le serveur EMS.
• La configuration EMS de l'adaptateur Windchill n'est pas correcte.
• Les préférences de Windchill ESI spécifient un ou plusieurs noms, utilisateurs ou mots de passe pour la file d'attente EMS.
|
Vous aurez peut-être besoin de l'aide de votre administrateur Windchill ESI pour résoudre ce problème.
|
Des erreurs apparaissent dans PostResult.
Les causes possibles de ce problème sont les suivantes :
• Un problème relatif aux données apparaît dans les données à publier.
• Un ou plusieurs des composants TIBCO requis sont hors ligne.
• Oracle Applications est hors ligne
• L'adaptateur TIBCO pour Oracle Applications n'est pas configuré correctement
• Les Services Windchill ESI sont incapables de lire ou d'écrire sur une file d'attente JMS. Ceci a les mêmes causes que Windchill PDMLink ne peut pas s'abonner à une file d'attente EMS.
• Une erreur de base de données s'est produite dans Windchill PDMLink.
• Le format de la requête RPC PostResult n'est pas correct à cause d'une erreur de programmation dans l'intergiciel Windchill ESI.
|
Vous aurez peut-être besoin de l'aide de votre administrateur Windchill ESI pour résoudre ce problème.
|
Aucune destination de publication n'a été affectée pour un objet publié.
Les causes possibles de ce problème sont les suivantes :
• La préférence Windchill ESI
Utilitaire de recherche des destinations de publication est définie sur
"com.ptc.winchill.esi.tgt.ESIRootInheritTargetFinder" afin que les objets héritent
de l'affectation de destination de publication de l'objet racine.
• L'objet est un composant d'une nomenclature et hérite des affectations de destinations de publication de l'assemblage ou de la nomenclature parent.
• Vous avez essayé de publier un objet avant d'affecter des destinations de publication.
• Vous avez essayé de publier un objet après avoir supprimé toutes les affectations des destinations de publication.
Aucune modification ne s'est produite depuis la dernière publication.
Les causes possibles de ce problème sont les suivantes :
• La préférence Windchill ESI Vérifier les itérations est définie sur Non, et seule l'itération de l'objet qui est publié a changé.
• Aucune modification n'a été apportée aux données depuis la dernière publication.
• Vous avez déjà publié l'objet avec succès dans toutes les destinations de publication qui y sont associées.
• Une tentative a été faite pour publier un objet déjà publié après avoir lui ajouté de nouvelles affectations de destination de publication.
Impossible de se connecter à TIBCO BusinessWorks ; EMS et/ou Windchill sont incapables de se connecter.
Les causes possibles de ce problème sont les suivantes :
Le serveur EMS n'est pas configuré correctement. Lorsque vous spécifiez le nom "localhost" du serveur EMS, ce serveur est reconnu uniquement sur l'hôte sur lequel il est exécuté. Aucune autre machine ne peut s'y connecter. Une application définie pour se connecter au serveur EMS "localhost" essaie de trouver le serveur EMS exécuté sur la même machine. Si aucun serveur n'est trouvé, une erreur se produit. Si vous définissez un nom de machine en tant que nom de serveur, les autres machines pourront se connecter au serveur EMS.
Définissez la propriété d'url associée à QueueConnectionFactory dans le fichier factories.conf à tcp://<nom de la machine> : 7222
où <nom de la machine> correspond à la machine sur laquelle est exécuté le serveur EMS.
- Définissez la variable globale ESIJMS\JNDIContextURL (dans le Moteur BW, Concepteur de TIBCO ou dans l'Administrateur TIBCO, selon où vous exécutez ESI) à = tibjmsnaming://<nomdemachine sur laquelle le serveur EMS est exécuté> : 7222.
L'emplacement du serveur EMS n'a pas d'importance. Il peut se trouver sur le même hôte que Windchill, que le moteur intergiciel ou sur un hôte différent. Si les valeurs décrites ci-dessus sont configurées correctement (et si les ordinateurs se trouvent sur le même réseau), Windchill PDMLink et l'intergiciel pourront se connecter au bon serveur EMS.
Pour déterminer quelle machine et quel nom d'utilisateur sont connectés à un serveur EMS, entrez la commande suivante dans l'outil d'administration EMS :
>show connections
Vous obtenez ainsi une liste des utilisateurs connectés et des machines à partir desquelles ils sont connectés. Pour plus d'informations, reportez-vous à la documentation relative TIBCO Enterprise for EMS.
Lorsque je consulte le journal des transactions ESI et le journal EAI, je constate qu'un échec se produit lors de la publication d'un objet avec Windchill ESI et qu'un message d'erreur apparaît en regard du/des objet(s) publié(s).
Le message d'erreur suivant apparaît en regard des objets publiés :
Input Data Invalid
Cette erreur indique que les données n'ont pas atteint l'adaptateur. La validation du schéma de l'adaptateur a échoué lors de l'invocation de l'activité de l'adaptateur.
Dans Oracle Applications, avant d'envoyer des données à un adaptateur, certaines valeurs font l'objet de références croisées (depuis le fichier ESIORALookup.properties) et certaines valeurs sont utilisées par défaut (depuis le fichier ESIORADefault.properties). Si ces fichiers de propriétés ne sont pas configurés correctement (par exemple, la valeur d'utilisation de nomenclature est vide ou l'identifiant de modèle n'est pas mis en correspondance), les données vides sont transmises à l'adaptateur et l'activité de l'adaptateur génère l'exception ci-dessus. Pour savoir exactement quel élément n'est pas correctement rempli, un Administrateur ESI doit consulter le journal du moteur de traitement ; le message d'exception détaille le nom de l'élément et l'erreur de validation.
Réponse aux conflits d'attributs principal/secondaire
Oracle Inventory peut être configuré de façon à ce que certains attributs d'articles soient contrôlés au niveau de l'organisation principale ou secondaire. Si un article est publié par ESI, et si l'opération tente de définir des attributs d'articles qui entrent en conflit avec les paramètres de contrôle des attributs, l'interface Oracle Item Open Interface renvoie une erreur. Le message d'erreur contient le texte indiqué ci-dessous, suivi par la liste des attributs à l'origine de l'erreur.
Master - Child Conflict in one of these Attributes (Conflit principal-secondaire dans l'un de ces attributs) :
Ce message indique que l'opération de publication ESI tente de définir un attribut d'article dans une organisation secondaire, contrôlée par l'organisation principale, et que la valeur de l'attribut de l'article secondaire ne correspond pas à celle de l'article principal.
Pour résoudre ce problème, il convient de passer les paramètres de contrôle des attributs en revue afin d'identifier le conflit. Notez qu'il est également possible que le modèle d'article utilisé pour créer l'article secondaire renvoie par défaut à un attribut d'article incorrect. Consultez le chapitre consacré à la configuration et au contrôle des articles dans le guide de l'utilisateur Oracle Inventory pour plus d'informations sur la configuration des contrôles d'attributs et des modèles d'articles.
Expiration des adaptateurs TIBCO pour les transactions ESI
• En cas d'expiration des adaptateurs TIBCO après l'arrêt de la connexion avec le système ERP, vérifiez le statut de la connexion et redémarrez les adaptateurs.
• Lorsque vous utilisez Windchill Enterprise Systems Integration pour Oracle Applications, l'adaptateur TIBCO "MasterConfiguration" s'arrête si un avis de modification est publié avec un numéro d'avis de modification qui dépasse la limite de 10 caractères.
Pour résoudre ce problème, effacez les fichiers registre avec une extension .ldr des deux dossiers suivants sous le répertoire d'installation de TIBCO ESI :
1. <Install_Home>\tibco\bw\5.13\
2. <Install_Home>\tibco\tra\domain\<DOMAIN_NAME>\application\Oracle_Apps\ledger
|
Tous les adaptateurs doivent être arrêtés avant d'être en mesure d'effacer les fichiers registre.
|
Un message d'erreur de fichier de métadonnées de réponse ESI apparaît
Un message d'erreur relatif au fichier de métadonnées de réponse ESI apparaît lorsque vous cliquez sur Terminer depuis la fenêtre Nouvelle destination de publication ou Modifier la destination de publication
Ceci peut être dû à l'un des problèmes suivants avec la valeur spécifiée pour le chemin de fichier de métadonnées de réponse ESI de l'attribut de destination de publication :
• Le chemin du fichier n'existe pas.
• Le contenu du fichier ne se conforme pas au schéma sous-jacent (standard, le schéma est fourni par le fichier ESIResponseMetaInformation.xsd).
• Le contenu du fichier est incorrect. Par exemple, un élément MapInformation dans le fichier référence un élément Map inexistant. Il peut y avoir plusieurs autres raisons pour lesquelles le contenu du fichier peut être considéré comme incorrect.
• L'attribut d'identifiant associé à un élément Map au moins dans le fichier est déjà en cours d'utilisation avec un élément Map différent qui n'est pas identique au premier. C'est le cas notamment si l'utilisateur fait pointer la destination de publication (créée ou modifiée) vers un fichier de métadonnées de réponse ESI dont l'élément Map des articles est modifié pour prendre en charge un attribut global supplémentaire, mais dont l'attribut d'identifiant conserve la valeur ESIPart, alors qu'une autre destination de publication pointe déjà vers le fichier de métadonnées de réponse ESI fourni par défaut.
Le démarrage de l'agent ADB sur les serveurs Windows a échoué.
Le message d'erreur suivant apparaît :
The ordinal 3823 could not be located in dynamic link library LIBEAY32.dll
Pour résoudre ce problème, exécutez les commandes suivantes :
1. MOVE /Y <Tibco_Home>/adapter/sdk/6.0/bin/libeay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/libeay32_bk.dll
2. MOVE /Y <Tibco_Home>/adapter/sdk/6.0/bin/ssleay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/ssleay32_bk.dll
3. COPY /Y <Tibco_Home>/tibrv/8.4/bin/libeay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/libeay32.dll
4. COPY /Y <Tibco_Home>/tibrv/8.4/bin/ssleay32.dll <Tibco_Home>/adapter/sdk/6.0/bin/ssleay32.dll
La publication reste dans l'état "En attente" dans le Journal des transactions d'Enterprise
Ceci peut être dû à l'une des causes suivantes :
• Il y a eu un échec de la connexion au Serveur JMS tcp://<JMSServer> : 7222
Cela a pu arriver si le serveur JMS n'est pas accessible ou si le nom d'hôte n'est pas résolu à l'adresse IP correcte. Une version inexacte du fichier tibjms.jar pourrait également provoquer ce problème. Pour résoudre ce problème, vérifiez que le fichier tibjms.jar du serveur Windchill utilise la version correcte de JMS sur le serveur de TIBCO.
1. Ouvrez une fenêtre de commande depuis le serveur Windchill.
2. Vérifiez la connexion au serveur à l'aide de l'utilitaire ping <JMSServer> en utilisant la chaîne exacte telle qu'elle apparaît dans les journaux du serveur de méthodes Windchill.
3. Si la demande échoue, exécutez l'utilitaire ping <JMSServer_IP>.
4. Si la demande réussit, utilisez l'adresse IP affichée ou ajoutez l'entrée suivante au fichier %Windir%\System32\drivers\etc\hosts : <JMSServer_IP> <JMSServer>
5. Si la vérification de la connexion au serveur à l'aide de l'utilitaire ping continue d'échouer, contactez votre administrateur réseau.
• Il y a eu un échec de la connexion à la file d'attente DataResponse.
Pour vérifier que c'est bien la cause du problème, connectez-vous au serveur JMS et vérifiez si la file d'attente DataResponse a été créée et si l'utilisateur WCESI s'est vu accorder des droits d'envoi sur la file d'attente DataResponse. Si un astérisque (*) apparaît devant le nom de la file d'attente DataResponse, la file d'attente est temporaire et doit être créée. Ce problème peut se produire lorsque l'EAR a été déployé manuellement. Pour résoudre ce problème, exécutez les commandes suivantes dans la fenêtre d'administration JMS :
1. Create queue <DataResponse>
2. Setprop queue <DataResponse> secure
3. Grant queue <DataResponse> <EAIUser> receive
4. Grant queue <DataResponse> <WCESIUser> send
5. Setprop factory QueueConnectionFactory url=tcp://<JMSServer> :7222
6. Commit
• L'archive de processus n'est pas connectée à la file d'attente DataResponse.
Ouvrez la fenêtre d'administration JMS pour confirmer que la file d'attente DataResponse est bien souscrite par l'archive de processus. Lors d'un déploiement manuel, cette étape est souvent omise, ce qui crée une erreur. Si la file d'attente DataResponse n'a pas été souscrite, vérifiez la valeur de la file d'attente DataResponseQueue en accédant à TIBCO Administrator > Application Management > Application Name > Configuration > Deployment Name > Advanced > ESIJMS/DataResponseQueue.
• Un seul utilisateur WCESI est connecté au serveur EMS. Vérifiez en naviguant jusqu'à Outil d'administration EMS > Afficher les connexions.
• Le nombre de connexions ESISYS avec le ClientID (file d'attente BW-ESIMaster_JMSConnection-queue- <Nom de l'application> - Archive_Processus) doit être égal au nombre d'instances ERP configurées. Si tel n'est pas le cas, il est possible que les instances supplémentaires des archives de processus en cours d'exécution consomment le message de réponse ESI. Vérifiez le nombre de connexions ESISYS en naviguant jusqu'à Outil d'administration EMS > Afficher les connexions.
• Vérifiez que toutes les connexions proviennent du TIBCO ou du serveur Windchill dans l'essai actuel et qu'aucune connexion ne provient de l'ensemble précédent ou d'une machine étrangère. Si tel n'est pas le cas, il est possible que les instances supplémentaires des archives de processus en cours d'exécution consomment le message de réponse ESI.
• Les archives Windchill et les archives de processus sont connectées à la même File d'attente JMS. Vérifiez en naviguant jusqu'à Outil d'administration EMS > Afficher les files d'attente.
• La file d'attente com.ptc.windchill.esi.Result a un seul récepteur. Vérifiez en naviguant jusqu'à Outil d'administration EMS > Afficher les files d'attente.
• Il reste des messages dans une file d'attente. Vérifiez en naviguant jusqu'à Outil d'administration EMS > Afficher les files d'attente.
• La valeur spécifiée pour l'attribut Nom de source de données lors de la création de la destination de publication ne correspond pas à la valeur correspondante spécifiée lors de l'exécution de l'utilitaire MICU pour l'instance d'Oracle Applications donnée. Ceci a pour résultat que les services Windchill ESI placent le message de réponse ESI sur une file d'attente EMS inexistante, ce qui à son tour a pour effet que la transaction ESI reste dans un état en attente.
Définir un ensemble d'objets métier via une demande de promotion entraîne la création d'un processus RTM pour chacun de ces objets.
Cela peut se produire si la préférence Publier les demandes de promotion a pour valeur Non. Définissez cette préférence sur Oui pour que les objets de la demande de promotion soient publiés via un processus RTM simple.
Le fichier réponse ESI qui est généré lors de la promotion d'un ou de plusieurs objets métier ne contient aucune information sur la demande de promotion, indépendamment de son ID.
Cela n'est pas surprenant. Si vous souhaitez envoyer d'autres attributs de la demande de promotion avec la réponse ESI dans un élément XML séparé, vous devez configurer le fichier de métadonnées de réponse ESI comme souhaité.