Rapport sur les objets défectueux et dépendants d'objets défectueux
* 
Pour plus de facilité, les fichiers journaux des échecs sont fournis avec le fichier ZIP de livraison car les journaux du serveur de méthodes ne sont généralement pas conservés. Les erreurs et les exceptions capturées dans le journal des échecs peuvent contenir des informations considérées comme confidentielles ou limitées à certains utilisateurs de l'organisation.
Pour contrôler la divulgation d'informations, assurez-vous que les tâches d'exportation ne sont effectuées que par un rôle particulier, tel qu'un gestionnaire de réplication. Dans ce cas, l'accès aux fichiers journaux est limité au rôle de gestionnaire de réplication. Il convient de continuer à procéder avec prudence lors du partage de ce journal des échecs avec d'autres rôles métier.
Lorsque vous activez la tolérance de panne pour les livraisons, un glyphe apparaît en regard de l'icône de compression ZIP dans le tableau Livraisons si le lot contient des objets et des liens défectueux.
Le tableau Pièces jointes de la page d'informations de la livraison affiche les fichiers suivants, qui fournissent des détails sur les objets défectueux et dépendants d'objets défectueux :
Fichier ZIP de la livraison : contient des données non-défectueuses et des données dépendantes d'objets défectueux.
Fichier CSV : affiche les objets défectueux et les objets dépendants d'objets défectueux sous la forme d'un tableau. L'ID d'affichage et l'ID d'objet s'affichent pour chaque objet ainsi que le message d'erreur correspondant. Pour plus d'informations sur les informations affichées, consultez la rubrique Fichier CSV. La convention de désignation du fichier CSV est la suivante :
Replication Package - <numéro de lot de réplication>, <nom de l'organisation>, <version du lot de réplication>[numéro de fichier] - Faulty Object Report.csv
Par exemple : Replication Package - 000001, Demo Organization, A.0[1] - Faulty Object Report.csv
* 
Un objet dépendant d'objets défectueux peut être répertorié plusieurs fois dans le fichier CSV s'il dépend de plusieurs objets défectueux.
Lorsque l'association inclut VersionReference ou MasterReference, l'objet associé est marqué comme étant dépendant d'objets défectueux uniquement lorsque toutes les versions et itérations de l'objet principal sont défectueuses. Si certaines versions ou itérations ne sont pas défectueuses, l'objet associé n'est pas marqué comme étant dépendant d'objets défectueux.
Lorsque certaines opérations sont effectuées au niveau d'un lot et qu'un objet de ce lot est identifié comme défectueux, l'ensemble du lot est signalé comme défectueux. Les étapes d'exportation signalées dans le fichier CSV sont IX - Prepare export (batch) et IX - Prepare attribute export (batch).
Pour certaines étapes de l'échec, l'étape suivante de l'exportation ne sera pas exécutée. Par conséquent, tous les objets défectueux ne peuvent pas être signalés.
Si le modèle maître générique d'EPMVariantLink est défectueux, la fonction de tolérance de panne peut ne pas identifier FamilyTable Generic, FamiltyTable Instance, EPMSepFamilyTable, EPMContainedIn, etc. en tant qu'objets dépendants d'objets défectueux. La table de famille peut être exportée avec succès, mais pas importée dans le système cible.
Lorsque vous exportez une configuration de référence gérée, si certains attributs, tels que FolderingInfo, sont identifiés comme défectueux, les fichiers journaux CSV et d'échec affichent l'entrée uniquement pour FolderingInfo. Les autres attributs défectueux ne sont pas répertoriés. L'étape d'exportation indiquée dans le fichier CSV est IX - getFolderPath.
Lors de l'exportation d'un objet métier principal, si certains attributs, tels que la Vue ou l'Etat, sont identifiés comme étant défectueux, les fichiers journaux CSV et d'échec affichent plusieurs entrées pour la Vue. L'étape d'exportation indiquée dans le fichier CSV est IX- Object metadata export.
Si un objet répertorié comme défectueux est identifié par la suite comme étant dépendant d'un objet défectueux, il n'est pas répertorié à nouveau dans le fichier CSV comme dépendant d'un objet défectueux.
Journal des échecs : répertorie les erreurs et les exceptions rencontrées lors du traitement des données défectueuses dans le lot de livraison. Il affiche également les erreurs en cas d'échec du processus de compression. Les erreurs et les exceptions sont extraites des fichiers journaux du serveur de méthodes.
La convention de désignation du journal des échecs est la suivante :
Replication Package - <replication package number>, <organization name>, <replication package version>[file number] - Failure.log
Par exemple : Replication Package - 000001, Demo Organization, A.0[1] - Failure.log
* 
Si le numéro de lot de réplication contient des caractères spéciaux, tels que <, >, ?, etc., le fichier Failure.log n'est pas généré sur votre machine lorsque vous utilisez un système d'exploitation Windows. Sur le système d'exploitation Linux, le fichier est généré, mais le numéro de lot de réplication dans le nom de fichier ne s'affiche que partiellement.
* 
La taille limite du fichier CSV et du journal des échecs est de 9 Mo. Si un fichier atteint ce seuil, un nouveau fichier est créé pour le reste du contenu. Par défaut, le premier nom de fichier affiche le numéro de fichier 1. Si un deuxième fichier est créé, il affiche le numéro de fichier 2, et ainsi de suite.
Le fichier journal des échecs répertorie également les erreurs rencontrées lors de l'écriture dans le fichier FaultyObjectForReplication.csv.
Le journal des échecs est écrasé lors de la création d'un nouveau fichier ZIP.
Lorsque la tolérance de panne est désactivée, les fichiers répertoriés ci-dessus ne sont pas générés.
Est-ce que cela a été utile ?