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. Vous pouvez utiliser les liens pour accéder directement aux informations concernant votre problème. 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.
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.
L'un des messages SAP suivants s'affiche dans le journal des transactions de Windchill Enterprise Systems :
"No unit of measure found in ISO code __ in field BASE_UOM_ISO"
ou
"The field MARA-MEINS/BAPI_MARA-BASE_UOM(_ISO) is defined as a required field; it does not contain an entry" (Le champ MARA-MEINS/BAPI_MARA-BASE_UOM(_ISO) est un champ obligatoire ; il ne contient aucune entrée)
Les causes possibles de ce problème sont les suivantes :
• Les fichiers de consultation des références croisées contiennent des valeurs non valides.
• L'unité de mesure par défaut est manquante ou non valide dans Windchill.
• Utilisation des codes natifs d'unités de mesure de SAP à la place des codes ISO requis.
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 de l'application SAP n'est pas disponible.
• Les connexions disponibles entre l'adaptateur et SAP sont insuffisantes.
• Le flux de messages est supérieur à la capacité des adaptateurs à les traiter.
|
|
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 incorrects 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.
• Les services Windchill ESI ne peuvent ni lire ni écrire dans une file d'attente JMS (les causes de ce problème sont les mêmes que pour #ESISAPTroubleOther/WCPDMLinkCannotSubscribeEMSQueue).
• 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 :
• 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 ESIVé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 la machine sur laquelle 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.
Pour résoudre ce problème, procédez comme suit :
• 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, le Concepteur de TIBCO ou l'Administrateur TIBCO, selon l'endroit vous exécutez ESI) sur = tibjmsnaming://<nomdemachine sur laquelle le serveur EMS est exécuté> : 7222.
|
|
L'emplacement du serveur EMS n'a pas d'importance. Le serveur EMS peut se trouver sur le même ordinateur que Windchill, sur le même ordinateur que le moteur intergiciel TIBCO ou sur tout autre ordinateur. 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 le middleware 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.
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. Cela peut être confirmé en consultant le journal de l'adaptateur.
• Vérifiez les paramètres de limite maximale de tâche et de flux de bwengine sur l'interface utilisateur graphique de l'administrateur TIBCO, Gestion de l'Application, <Nom de l'application>, Configuration, Process Archive.par, Configurations du Processus BusinessWorks TIBCO, ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_End_PD. Ce doit être un nombre fini non nul basé sur l'essai de charge effectué dans l'environnement de l'utilisateur.
• Si les adaptateurs TIBCO commencent à expirer alors que leur connexion à l'ERP n'est pas arrêtée, vérifiez l'interface utilisateur graphique de l'administrateur TIBCO, Gestion de l'Application, <Nom de l'application>, Configuration, ESISAPAdapterConfiguration.aar, Avancé, valeur adr3.maxconnections. Cette valeur doit être égale aux paramètres de limite maximale de tâche de bwengine
Un message d'erreur relatif au 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.
L'adaptateur ne démarre pas avec le transport JMS
Après avoir installé TIBCO Runtime Agent 5.6 et TIBCO Runtime Agent 5.6.1, les projets de l'adaptateur TIBCO utilisant Enterprise Message Service pour leur transport ne démarrent pas à partir de TIBCO Designer. Le message d'erreur suivant s'affiche :
Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms.
Pour résoudre ce problème, procédez comme suit :
• Sous Windows : sauvegarde, puis suppression de libeay32.dll et ssleay32.dll de <TIBCO_HOME>/adapters/sdk/version/<lib>
• Sous UNIX : sauvegarde, puis suppression des bibliothèques libssl et libcrypto openssl de TIBCO_HOME/adapters/sdk/version/lib directory
L'adaptateur ne démarre pas, le statut reste sur "Starting up" dans l'Administrateur
Si l'identifiant de processus "-1" est alloué à un processus d'adaptateur, une erreur s'est produite lors du lancement de l'adaptateur. Cette erreur dépend en général de la bibliothèque.
Les erreurs suivantes sont courantes :
• Erreur lors du chargement des bibliothèques partagées : librfccm.so: wrong ELF class: ELFCLASS64
Cette erreur peut se produire si vous avez utilisé des bibliothèques SAPJCo de 64 bits. Sur certaines plateformes, comme Windows X64 et Linux ia64, l'adaptateur SAP est une application de 32 bits. L'utilisation de bibliothèques de 32 bits résoudra le problème.
• Erreur lors du chargement des bibliothèques partagées : librfccm.so: wrong ELF class: ELFCLASS32
Cette erreur peut se produire si vous avez utilisé des bibliothèques SAPJCo de 32 bits. Sur certaines plates-formes, comme HPUX IA64 et Solaris SPARC, l'adaptateur SAP est une application à 64 bits. L'utilisation de bibliothèques de 64 bits résoudra le problème.
Des problèmes semblables ont été observés sur les bibliothèques suivantes :
• libresolv.so.2 sunw_2.2.2
• libstdc++-libc 6.2-2.so.3
• libstdc++.so.5
Vérifiez les éléments suivants :
• Les kits de compatibilité corrects ont été installés. Cela résoudra toutes les interdépendances.
• Si les variables environnementales de Java ont été définies, vérifiez que les versions sont compatibles. Les applications TIBCO installent également JRE 1.5 et 1.6. Vous pouvez supprimer tous les paramètres Java que vous avez déjà configurés et laisser l'application TIBCO définir les variables Java appropriées.
• SUR les machines HPUX et Solaris, si les variables Java ont déjà été définies, vérifiez que le chemin de classe contient des bibliothèques Java de 64 bits, car l'adaptateur SAP est une application de 64 bits sur ces plateformes.
Le connecteur Coyote n'a pas été démarré
Vérifiez les variables ESIOthers/WSHost et ESIOthers/WSPort.
La publication reste dans l'état "Pending" 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
Ceci 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 l'utilitaire ping continue d'échouer, contactez votre administrateur de 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 même 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. Vérifiez le nombre de connexions ESISYS en naviguant jusqu'à Outil d'administration EMS > Afficher les connexions. Vérifiez en naviguant jusqu'à Outil d'administration EMS > Afficher les connexions.
• 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.
• Les valeurs spécifiées pour les attributs ID Client et système lors de la création de la destination de publication ne correspondent pas aux valeurs correspondantes spécifiées lors de l'exécution de l'utilitaire MICU pour l'instance de SAP 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.
L'analyseur syntaxique JAX-M ou l'analyseur syntaxique XML a échoué à analyser le message à l'aide du schéma XML ResultResponse
Le message d'erreur suivant apparaît :
2,,2,2,1,20021,Windchill sent an invalid ResultResponse message. JAX-M Parser or XML Parser failed to parse message using ResultResponse XML schema. See Windchill logs for details,,,,,Job-1 Error in [ProcessDefinitions/Services/WCResult_Service.process/RepeatUntilTrue_SendAllResults/RepeatOnError_Result_ResultResponse/Java_ParseESIResultResponse]While executing [invoke] encountered [com.ptc.windchill.esi.ext.ESISoapException]: [Unable to create envelope from given source: at com.ptc.windchill.esi.ext.SoapResponseFinder.getResult(SoapResponseFinder.java:216)]
Ce problème concerne les bibliothèques Java expédiées avec JRE 6. Il n'a pas été observé avec JRE 1.5 et JRE 1.6.0.18.
Un message "Input data invalid" apparaît dans le Journal des transactions d'Enterprise
Cette erreur indique un échec de validation du schéma dans l'activité "Appeler un service de réponse à la demande de l'adaptateur". Une description détaillée et un suivi d'empilage sont enregistrés dans les journaux processArchive. Les journaux indiquent la raison exacte du défaut de correspondance du schéma. Par exemple :
validation error: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs ({com.tibco.xml.validation}SIMPLE_E_LENGTH_TOO_LONG) at /aeRequestInputType[1]/{http://www.tibco.com/xmlns/ae2xsd/2002/05/ae/700/basic/functionModules}__caret_request_caret_BAPI__MATERIAL__SAVEREPLICA_caret_BAPI__MATERIAL__SAVEREPLICA[1]/MATERIALDESCRIPTION[1]/item[2]/MATL__DESC[1]com.tibco.xml.validation.exception.k: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs
La transaction reste dans l'état "Pending" dans le Journal des transactions d'Enterprise
Ceci peut être dû à l'une des causes suivantes :
• Les services ESI n'ont pas pu écrire la réponse ESIResponse dans la file d'attente DataResponse du serveur EMS. Pour vérifier ceci, naviguez jusqu'à Administration Info*Engine > Editeur de propriétés > Propriétés JMS fondamentales et confirmez que l'URI de base JMS est correcte. Puis reportez-vous aux journaux du serveur de méthodes pour confirmer que la file d'attente DataResponse est souscrite avec succès.
• Echec de la connexion au serveur JMS tcp://<JMSServer> :7222. 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.
• Le serveur JMS n'est pas accessible ou le nom d'hôte n'est pas résolu à l'adresse IP correcte. Une version inexacte du fichier tibjms.jar pourrait provoquer ce problème. Pour vérifier :
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 l'utilitaire ping continue d'échouer, contactez votre administrateur de 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 même 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 a été souscrite, vérifiez la file d'attente DataResponseQueue en accédant à TIBCO Administrator > Application Management > Application Name > Configuration > Deployment Name > Advanced > ESIJMS/DataResponseQueue.
Toutes les configurations du serveur EMS disparaissent après que le serveur EMS a été démarré manuellement
La commande de démarrage du serveur EMS a été modifiée dans la version 5.1.4. Dans les versions EMS 4.x, la commande de démarrage était "./tibemsd". Dans la version EMS 5.1.4, la commande est ./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf. La commande utilise un chemin relatif et il doit être exécuté depuis " <TIBCO_HOME>\ems\5.1\bin."
Pour résoudre ce problème, arrêtez le processus démarré par la commande "./tibemsd" et démarrez le serveur EMS à l'aide de la commande correcte :.
"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf"
L'adaptateur TIBCO pour une instance SAP cesse de fonctionner et un statut d'erreur apparaît
Ce problème se produit à cause d'une erreur de dépassement de la pile d'adaptateur. Le support TIBCO l'a accepté comme un problème connu et a suggéré d'augmenter un paramètre adr3.stacksize à une valeur appropriée pour résoudre ce problème. Ceci a été testé avec succès avec 524288 (512 Ko).
Ce problème n'apparaît actuellement que sur les machines HPUX v3.
Pour augmenter adr3.stacksize, naviguez jusqu'à l'interface utilisateur graphique TIBCO> Gestion de l'Application > <Nom de l'application> Configuration > ESISAPAdapterConfiguration.aar > Avancé.
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é.