What this category's data looks like
This page addresses the degree conferral and certificate information reporting scenario; the materials include degree application forms, thesis review forms, and defense resolutions. The degree application form carries the applicant's identity, discipline, and proposed degree level; the thesis review form carries the review conclusion, review date, and reviewer signature; the defense resolution carries the defense conclusion, voting result, defense date, and chair signature. The three types of materials enter the reporting process aggregated by batch or by week, and the field characteristics center on name, student ID, thesis title, date, quantity, signature, and receipt status. When the materials enter this function, their respective roles are to provide the raw basis for progress records and statistical verification: the degree application form is used to verify the number of application and conferral records, the thesis review form is used to verify the number of completed reviews, and the defense resolution is used to verify the number of passed defenses. The update cadence rolls forward on a weekly basis, comparing name, quantity, and date item by item, forming a progress table and a statement of statistical criteria that can go into weekly or monthly reports.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, which outputs the response body, status code, and returned fields. The progress table and the statement of statistical criteria are completed by subsequent nodes parsing the response, or by an external system handling it as agreed. The HTTP node is only responsible for sending the request and retrieving the result; it does not replace the external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Degree application form | Fields, dates, and signatures must be aligned item by item with the thesis review form and the defense resolution; name, quantity, and date must not mismatch | In the request preview, look at the fully rendered address, check whether the request body fields and returned fields corresponding to this material are consistent, and confirm the source of the Authorization request header value |
| Thesis review form | The review conclusion, review date, and reviewer signature must be synchronized with the degree application form and the defense resolution; unsynchronized versions must be flagged | Check the request header names and value sources, confirm that the authentication information is passed in as required by the external system, then compare one sample response and check whether the variables placeholders are parsed into actual values |
| Defense resolution | The defense conclusion, voting result, defense date, and chair signature must be complete; missing signatures or receipts must be recorded separately | In the variables panel, check the source of each placeholder, confirm that responseData can be traced to a specific origin, and record the array length and the referenced text tokens |
| Progress table and statement of statistical criteria | Record counts and statistical counts must match, the criteria must be written in the header, and exceptions must be clearly stated | Use one week of records to check the totals, check whether the returned fields support the total criteria, and once the status code is 200, confirm the fields are complete |
Three common errors
- Symptom: the name, quantity, or date of the same record does not match between the degree application form and the defense resolution. Cause: the two materials are entered separately and are not compared item by item under the same criteria.
- Symptom: the thesis review form version is not synchronized, and the review conclusion and the defense resolution reference are inconsistent. Cause: after the material was updated, it did not re-enter the reporting process for verification.
- Symptom: the defense resolution is missing a signature or receipt, yet the progress record still counts it in the total. Cause: the statistical criteria did not list exceptions separately, causing the record count and the statistical count to mismatch.
How to verify the setup
This function's acceptance: preview the rendered request, check the status code and returned fields, then compare the result against one sample; at the same time confirm that variables and responseData are traceable, and that the fields are complete when the status code is 200.
Business test: use one week of records to check the totals, see whether the criteria and exceptions are clearly stated, and check whether the Authorization request header is passed in as required by the external system.
- In the request preview, look at the fully rendered address, check that the placeholder variables are parsed into actual values, and check that the request body fields are consistent with the external interface agreement.
- In the variables panel, check the source of each placeholder, confirm that global variables, system variables, or upstream node outputs are traceable, and record the array length and the referenced text tokens.