This article provides an explanation about how WATS receives reports, and what happens to the report after it is received.
When the report is first received WATS performs a quick sanity check on the report.
WATS adds the user's username as origin to the report if it is missing. When using the WATS Client API the client automatically sets origin as itself. Origin is used to tie the report to a client in system manager, for filtering and restricting access to reports.
If the start date time of the report is in the future it will be accepted, but will not be processed until the start date time is not in the future anymore. In the mean time, the report can be found in Quarantined reports.
WATS checks if the report already exists; if the report ID exists or if the header data is the same as an existing report, the new report replaces the old report. The header data that is checked is:
- Report type (UUT or UUR)
- Serial number
- Part number (but not if the 'IsSerialNumberUnique' setting is true)
- Process code
- Start date time (+/- 500 ms)
When a report is replaced, the new report is processed as usual, and the old report is scheduled for deletion.
When a report is replaced, it inherits the old reports receive count. If a report has been received more than the maximum 100 times it will not be processed again, which means that only the UUT or UUR report is changed, and the aggregated data will not be changed.
The report is added to the database with header data and queued for processing, the raw report is saved in storage, and the report reception statistics (how many reports and how many bytes per day) are updated. At this point the report show up in Test Reports or Repair Reports and can be viewed.
If an error occurs at any point during the sanity check, the report insertion, or while saving to storage, the report is not accepted, and the changes made to WATS so far are rolled back.
The report processing queue is checked every 3 minutes and also every time a new report is received. There are three types of processing: New, Delete, and Datawarehouse delete.
The raw report is unpacked and put into the database so it can be used in analysis. Aggregated data is also updated.
Origin is used to find which client the report belongs to. If origin is a username, that user's web client will be used. If origin is a client MAC address, that client is used. If no client is found, processing ends with an error.
If the report's process code does not exist, processing ends with an error.
Step and measurement data is unpacked and put into the database, but only the top 15 levels. That means that when there are more than 15 nested sequence calls in a row the steps below sequence call number 15 are not used. The steps and measurements that are deeper than 15 are not used in analysis and aggregation, but will still be visible in the UUT or UUR report.
If the report replaced another report, the data for that report is deleted and the data for the new report is added.
If an error occurs during processing, the report is put in quarantine, and will be attempted again later, up to 20 times.
The data for the report is deleted from the database and the raw report is deleted from storage. Aggregated data is not updated. This type is used when the report was never processed, so attempting to update the aggregated data would not change anything.
The data for the report is deleted from the database, and the raw report is deleted from storage. The report's data is subtracted from the aggregated data.
Please sign in to leave a comment.