Report on Faulty and Dependent-on-Faulty Objects
 |
For the ease of business, failure log files are provided along with the Delivery zip file as method server logs are generally not maintained. The errors and exceptions captured in the failure log might contain information that is considered confidential or restricted to certain users in the organization.
As a best practice to control information disclosure, ensure that the export tasks are performed only by a particular role, such as a Replication Manager. In this case, access to log files is restricted to the Replication Manager’s role. Appropriate caution should continue to be exercised when sharing this failure log with other business roles.
|
When you enable fault tolerance for deliveries, a glyph appears next to the zip icon in the Deliveries table if the package contains faulty objects and links.
The Attachments table in the delivery information page displays the following files that provide details of the faulty and dependent-on-faulty objects:
• Delivery zip file: Contains non-faulty data and dependent-on-faulty data.
• CSV file: Displays the faulty objects and dependent-on-faulty objects in a tabular format. The display ID and the object ID are displayed for each object along with the relevant error message. For information on the information displayed, see CSV File. The naming convention of the CSV file is:
Replication Package - <replication package number>, <organization name>, <replication package version>[file number] - Faulty Object Report.csv
For example: Replication Package - 000001, Demo Organization, A.0[1] - Faulty Object Report.csv
 | • A dependent-on-faulty object may be listed multiple times in the CSV file if it is dependent on multiple faulty objects. • When the association includes VersionReference or MasterReference, the associated object is marked as dependent on faulty only when all the versions and iterations of the primary object are faulty. If some versions or iterations are not faulty, the associated object is not marked as dependent on faulty. • When certain operations are performed at a batch level and any object in that batch is identified as faulty, the entire batch is reported as faulty. The stages of export reported in the CSV file are IX - Prepare export (batch) and IX - Prepare attribute export (batch). • For certain stages of failure, the next stage of export will not be executed. Therefore, not all faulty objects may be reported. • If the generic master of EPMVariantLink is faulty, the fault tolerance feature may not identify FamilyTable Generic, FamiltyTable Instance, EPMSepFamilyTable, EPMContainedIn, and so on as dependent-on-faulty objects. The family table may be successfully exported, but not imported in the target system. • When exporting a managed baseline, if some attributes, such as FolderingInfo, are identified as faulty, the CSV and failure log files display the entry only for FolderingInfo. Other faulty attributes are not listed. The stage of export reported in the CSV file is IX - getFolderPath. • When exporting a Primary Business Object (PBO), if some attributes, such as View, State are identified as faulty, the CSV and failure log files display multiples entries for View. The stage of export reported in the CSV file is IX- Object metadata export. • If an object that is listed as faulty, is later identified as dependent on faulty, it is not listed again in the CSV file as dependent on faulty. |
• Failure log: Lists the errors and exceptions encountered when processing faulty data existing in the delivery package. It also displays errors if the zipping process fails. The errors and exceptions are extracted from the method server log files.
The naming convention of the failure log is:
Replication Package - <replication package number>, <organization name>, <replication package version>[file number] - Failure.log
For example: Replication Package - 000001, Demo Organization, A.0[1] - Failure.log
| | If the replication package number contains special characters, such as <, >, ?, and so on, the Failure.log file is not generated on your machine when using a Windows operating system. On Linux operating system, the file is generated but the replication package number in the file name is partially displayed. |
| | • The size limit of the CSV file and the failure log is 9 MB. If a file reaches that threshold, a new file is created for the remaining content. By default, the first file name displays the file number as 1. If a second file is created, it displays the file number as 2, and so on. • The failure log file also lists the errors encountered while writing to the FaultyObjectForReplication.csv file. • The failure log is overwritten when a new zip file is created. |
When fault tolerance is disabled, the files listed above are not generated.