Monitoring and Troubleshooting

Goal: Understand the current state of the master pipeline at a glance.

1. Open the Global Master Data Sync Role Center on the master company.
2. In the Master Activities cue group Data Templates, read the three tiles:
   • Data Templates Development — templates not yet ready for exchange.
   • Data Templates Pending — templates awaiting release.
   • Data Templates Released — templates actively exchanging data.
     Clicking any tile filters the Data Template list to that status.
3. In the Partners cue group:
   • Partners Active — partners ready to receive data.
   • Partners On Hold — partners where exchange is blocked.
   • Data Template Subscribers — total active subscriber relationships.
4. In the Partner Groups cue group, review the Under Development / Pending Update / On Hold / Released counts, plus Unhandled Partner Group Updates and Failed Partner Group Updates for group-level pipeline health.
5. Any non-zero count in On Hold or Failed tiles warrants investigation.

Goal: Understand the current state of the subscriber pipeline at a glance.

1. Open the Global Master Data Sync Role Center on the subscriber company.
2. In the Record Data cue group:
   • Record Data - Not Sync. — records received from the master but not yet written to the local record set. Click to see the specific records.
   • Record Data - Sync. Skipped — records where Skip Synchronisation has been set; they will not sync until that flag is cleared.
   • Obsolete Record ID — deletion requests from the master that have not yet been applied.
   • IC File Log - Not Updated — IC file logs received but not yet processed into record data.
   • Data Templates - Imported — count of data templates imported from a master.
3. In the Record Action cue group:
   • Rec ID Update - Not Executed — pending delete/rename instructions; click to open Record Actions filtered to not-executed rows.
   • Rec Action Errors Not Reviewed — executed actions that failed and need review.
   • Rec Action Error Reviewed — acknowledged errors.
   • Rec ID Update - Executed — successfully executed actions.
4. A healthy subscriber shows zero in Not Updated, Not Executed, and Errors Not Reviewed.

Goal: On the master, verify that a file set was generated and review its structure.

1. Navigate to Global Master Detail File Log List (available under Reports and Analysis or via search).
2. The list shows one row per file set, with columns for Code, GM Data Template Code, Master Partner ID, Owner Company Name, No. Of File Lines, and creation timestamp.
3. Filter by GM Data Template Code to focus on a specific template, or by Master Partner ID to see all file sets from one master.
4. Use the creation timestamp to confirm when the last file set was generated.
5. Click a row to open the Detail File Log Card for that header.

Goal: Inspect the content and timing of each file line within a transfer set.

1. Open the Global Master Detail File Log Card for the relevant header (from the Detail File Log List).
2. The header section shows: Code, No. Of File Lines, Master Partner ID, GM Data Template Code, Owner Company Name, and aggregate timing fields (Files Creation Duration; on the subscriber, also Import Duration Total, Unpack Duration Total, Update Duration).
3. In the Lines subform, each row represents one payload file with columns:
   • Line No. — sequence within the transfer set.
   • Type — what the line contains (Data Template, Record Set, Media Buffer, Blob Buffer, Record Actions, Obsolete Records).
   • Blob Length (KB) — size of the stored payload.
   • File Creation Duration — how long the master took to build this line.
   • On the subscriber: Import Duration, Unpack Duration, Update Duration, Updated GM Record Ids, Updated Field Values, Updated.
4. A line where Updated is false (subscriber view) indicates the pipeline has not yet processed it.
5. Use the Download File Content action on a line to export the raw JSON payload for detailed inspection.
6. Use Show Import Json Blob to view the JSON formatted in the browser.

Goal: On the subscriber, see the full list of files received from master companies and their processing status.

1. Navigate to Global Master IC File Log (caption on the list page).
2. The list shows all IC file log entries. Key columns:
   • Subscriber Partner ID / Master Partner ID — identifies the exchange relationship.
   • GM Data Template Code — which template the file belongs to.
   • Creation Date — when the file was created on the master.
   • Data Sent / Data Sent On — whether and when the file was dispatched.
   • Data Updated (Subscriber) / Data Updated On (Subscriber) — whether and when it was processed locally.
   • Error Text — any processing error.
   • Detail File Log Header Code — the code of the associated Detail File Log.
3. Filter Data Updated (Subscriber) = No to see pending files.
4. Filter Error Text <> blank to see failed files.
5. Use Import IC File Logs to pull new files from the configured file storage (Azure Blob Storage or external file account).
6. Use Update Record Data to process all pending (not-yet-updated) IC file logs into the record set.
7. Use Download File Content to export the embedded XML payload (for legacy XML-format files).

Goal: On the subscriber, see which records synchronised successfully and which failed.

1. Navigate to Subscriber Log Entries.
2. The list shows one entry per synchronisation attempt, sorted by GM Data Template Code descending. Key columns:
   • GM Data Template Code — the template.
   • Entry No. — sequence number of the log entry.
   • Table Caption — the BC table being synchronised.
   • Primary Key — the record's primary key (shown when not filtered to a single record).
   • Synchronisation Date — when the attempt occurred.
   • Type — Success or Error.
   • Error Message — the full error text (up to 4,000 characters across four fields, reassembled on screen).
3. Click Show Record to open the affected record in BC (if it still exists).
4. This page is also accessible from Record Data pages via drill-down actions on specific records.

Goal: Quickly isolate all failed synchronisation attempts.

1. Open Subscriber Log Entries.
2. Apply a filter: Type = Error.
3. Review the Error Message column for the failure reason.
4. Optionally add a GM Data Template Code filter to narrow to one template, or a Synchronisation Date filter to scope to a specific run.
5. Use Show Record on any row to navigate to the affected record and assess whether the data issue has already been resolved.

Goal: Acknowledge errors in Record Actions that cannot be automatically resolved, so they no longer appear as outstanding in the cue.

1. Open Global Master Record Actions on the subscriber.
2. Enable the Show Only Non Reviewed Errors filter. The list now shows only executed actions that failed and have not yet been reviewed.
3. Select one or more rows.
4. Choose Set Error Reviewed. Confirm the prompt.
5. The Error Reviewed field is set to Yes on the selected rows.
6. Return to the Subscriber Activities Role Center cue — the Rec Action Errors Not Reviewed count decreases, and the Rec Action Error Reviewed count increases accordingly.

Note: Setting Error Reviewed confirms that the error has been assessed. It does not fix the underlying data; ensure any necessary manual corrections have been made first.

Goal: Push a specific IC file log from the master into a subscriber tenant that did not receive it automatically.

Context: The Insert IC File Log and Insert File Log Line are API pages used by the master's automated sending process. A consultant may need to invoke them manually when a file was lost in transit or a subscriber's file storage was temporarily unavailable.

1. On the master, locate the Subscriber IC File Log entry that was not received (Data Updated (Subscriber) = No, or the entry does not exist on the subscriber).
2. Use Download IC File Log to export the entry as an XML file.
3. On the subscriber, open the Global Master IC File Log and use Upload IC File Log to import the XML file. This creates the IC File Log entry and, if a Detail File Log Header Code is present, creates the corresponding Detail File Log Header.
4. If the file uses the Detail File Log format, the individual file lines must also be imported. Each line can be re-imported from the master's Detail File Log Card using the Download File Content action on the relevant line.
5. Once all file lines are present, use Update Record Data on the Subscriber IC File Log page to process the file into the record set.

Goal: Understand and resolve a pending deletion propagated from the master.

1. On the subscriber, check the Subscriber Activities cue — the Obsolete Record ID tile shows the count of pending deletion requests.
2. Drill down to open Global Master Obsolete Record IDs.
3. Each row represents one record that was deleted on the master, identified by GM Data Template Code, Record ID, Subscriber Partner ID, and Master Partner ID.
4. The IC File Log Entry No. links to the IC file log that carried the deletion signal. The Record Action Entry No. links to the originating Record Action on the master.
5. Normally, Obsolete Record IDs are processed automatically when Update Record Data runs on the Subscriber IC File Log. If an entry persists with an Error Text, the automatic deletion failed (for example, because the record is blocked by a posting group or has dependent entries).
6. Investigate the error text, resolve the blocking issue on the subscriber, then re-run Update Record Data to retry. Alternatively, delete the local record manually and then delete the Obsolete Record ID entry.

Goal: Clean up data template lines that reference fields that no longer exist in the current BC schema, preventing stale field references from causing errors during the next sync.

1. Navigate to Reports or search for Global Master Remove Obsolete Data Template Lines.
2. On the request page, optionally filter by Code to restrict the report to specific data templates. Leave the filter blank to process all templates.
3. Run the report. It scans every data template line across all templates and removes lines whose referenced field is no longer valid (field has been removed from the table or is no longer of a normal type).
4. For each line removed, associated field values, fixed values, media buffers, and filter rows are also cleaned up.
5. When the run completes, a message reports how many template lines were removed.
6. After running this report, generate a new IC file for affected subscribers so they receive an updated template definition without the obsolete lines.

This report is typically run after a BC upgrade that removes or reclassifies fields that were previously included in a data template.

Goal: Understand and confirm the propagation of a primary-key rename from the master to subscribers.

1. On the master, renames are captured automatically in Subscriber Rename Records when a record's primary key changes. Open Global Master Subscriber Rename Records to see the queue.
2. Each row shows: GM Data Template Code, Record ID (new key), Subscriber Partner ID, Master Partner ID, Created On, and the Record Action Entry No. that originated the rename.
3. Rename records are consumed during the next IC file creation for the affected subscriber: the system includes the rename as a Record Actions payload line in the outbound Detail File Log.
4. On the subscriber, the rename is received as part of the IC file and appears in Global Master Record Actions with Type = Rename. It is applied automatically during the next Update Record Data run.
5. If a rename action has an Error Text on the subscriber, investigate via Global Master Record Actions. A common cause is that the target key value already exists on the subscriber. Resolve the conflict, then either re-execute the action or mark it as Error Reviewed if a manual resolution was applied.
6. Once a Subscriber Rename Record has been included in an outbound IC file, it is deleted from the queue automatically — it will no longer appear in the list.

Goal: On the subscriber, inspect the full history of delete and rename actions received from the master and investigate any failures.

1. Navigate to Global Master Record Actions on the subscriber.
2. Use the filter options at the top of the page:
   • Show Only Not Executed Records — pending actions not yet applied.
   • Show Only Non Reviewed Errors — executed actions that failed and require attention.
   • Show Only Reviewed Errors — acknowledged errors (for reference).
   • Show Only Imported Records — actions that originated on a different master (useful in multi-master environments).
   • Table Filter — restrict to a specific table using the lookup.
3. Key columns per action:
   • Type — Delete or Rename.
   • Record ID — the record affected (new key for renames).
   • Record ID (Renamed) — the old key (renames only).
   • Table Caption — which BC table.
   • Executed / Execution DateTime — whether the action has been applied and when.
   • Error Text — failure message, if any.
   • Error Reviewed — whether the error has been acknowledged.
4. Select one or more pending Delete actions and choose Execute Record Actions to apply them immediately.
5. Use Show Record to navigate to the related record in BC.

Goal: Know the purpose of each type of file line in a Detail File Log so you can interpret log contents correctly.

Each Detail File Log Line carries a Type that identifies the kind of payload it holds. The possible values are:

When troubleshooting a stalled Detail File Log, look at the Type of the first line where Updated is false — this tells you exactly which phase of the import pipeline failed.