Informe sobre objetos defectuosos y dependientes de defectuosos
 |
Para facilitar el negocio, los ficheros de registro de fallos se proporcionan junto con el fichero ZIP de envío, ya que los registros del servidor de métodos no suelen mantenerse. Los errores y excepciones capturados en el registro de fallos pueden contener información que se considera confidencial o restringida a determinados usuarios de la organización.
Como práctica recomendada para controlar la revelación de información, asegúrese de que las tareas de exportación solo se realizan mediante un rol concreto, como un administrador de replicación. En este caso, el acceso a los ficheros de registro está restringido al rol del administrador de replicación. Se debe seguir ejerciendo la precaución adecuada al compartir este registro de fallos con otros roles de negocio.
|
Cuando se activa la tolerancia a fallos para los envíos, aparece un glifo junto al icono de ZIP en la tabla Envíos si el paquete contiene objetos y vínculos defectuosos.
En la tabla Adjuntos de la página de información del envío se muestran los siguientes ficheros que proporcionan detalles de los objetos defectuosos y dependientes de defectuosos:
• Fichero ZIP de envío: contiene datos no defectuosos y datos dependientes de defectuosos.
• Fichero CSV: muestra los objetos defectuosos y los objetos dependientes de defectuosos en formato de tabla. El ID de visualización y el ID de objeto se muestran para cada objeto junto con el mensaje de error correspondiente. Para obtener información sobre la información visualizada, consulte Fichero CSV. La convención de asignación de nombres del fichero CSV es:
Replication Package - <número de paquete de replicación>, <nombre de organización>, <versión del paquete de replicación>[número de fichero] - Faulty Object Report.csv
Por ejemplo: Replication Package - 000001, Demo Organization, A.0[1] - Faulty Object Report.csv
 | • Un objeto dependiente de defectuoso se puede enumerar varias veces en el fichero CSV si es dependiente de varios objetos defectuosos. • Cuando la asociación incluye VersionReference o MasterReference, el objeto asociado se marca como dependiente de defectuosos solo cuando todas las versiones e iteraciones del objeto principal son defectuosas. Si algunas versiones o iteraciones no son defectuosas, el objeto asociado no se marca como dependiente de defectuoso. • Cuando determinadas operaciones se realizan en un nivel de lote y cualquier objeto de dicho lote se identifica como defectuoso, el lote completo se notifica como defectuoso. Las etapas de exportación notificadas en el fichero CSV son IX - Prepare export (batch) y IX - Prepare attribute export (batch). • Para determinadas etapas de fallo, no se ejecutará la siguiente etapa de exportación. Por lo tanto, es posible que no se notifiquen todos los objetos defectuosos. • Si el maestro genérico de EPMVariantLink es defectuoso, es posible que la función de tolerancia a fallos no identifique FamilyTable Generic, FamiltyTable Instance, EPMSepFamilyTable, EPMContainedIn, etc. como objetos dependientes de defectuosos. La tabla de familia se puede exportar correctamente, pero no se puede importar en el sistema de destino. • Al exportar una instantánea gestionada, si algunos atributos, como FolderingInfo, se identifican como defectuosos, en los ficheros de registro de fallos y CSV se muestra la entrada solo para FolderingInfo. No se muestran otros atributos defectuosos. La etapa de exportación notificada en el fichero CSV es IX - getFolderPath. • Al exportar un objeto de negocio principal (PBO), si algunos atributos, como Vista o Estado, se identifican como defectuosos, los ficheros de registro de fallos y CSV mostrarán varias entradas para Vista. La etapa de exportación notificada en el fichero CSV es IX- Object metadata export. • Si un objeto que se muestra como defectuoso, se identifica posteriormente como dependiente de defectuosos, no se vuelve a enumerar en el fichero CSV como dependiente de defectuosos. |
• Registro de fallos: se muestran los errores y excepciones que se encuentran al procesar datos defectuosos existentes en el paquete de envío. También muestra errores si falla el proceso de compresión. Los errores y excepciones se extraen de los ficheros de registro del servidor de métodos.
La convención de asignación de nombres del registro de fallos es:
Replication Package - <replication package number>, <organization name>, <replication package version>[file number] - Failure.log
Por ejemplo: Replication Package - 000001, Demo Organization, A.0[1] - Failure.log
| | Si el número de paquete de replicación contiene caracteres especiales, como <, >, ?, etc., el fichero Failure.log no se genera en el ordenador cuando se utiliza un sistema operativo Windows. En el sistema operativo Linux, el fichero se genera, pero el número de paquete de replicación en el nombre de fichero se muestra parcialmente. |
| | • El límite de tamaño del fichero CSV y del registro de fallos es de 9 MB. Si un fichero alcanza ese umbral, se crea un nuevo fichero para el contenido restante. Por defecto, el primer nombre de fichero muestra el número de fichero como 1. Si se crea un segundo fichero, muestra el número de fichero como 2, y así sucesivamente. • En el fichero de registro de fallos también se muestran los errores que se encuentran al escribir en el fichero FaultyObjectForReplication.csv. • El registro de fallos se sobrescribe cuando se crea un nuevo fichero ZIP. |
Cuando la tolerancia a fallos está desactivada, los ficheros enumerados anteriormente no se generan.