What this category's data looks like
This page addresses exception tracing and manual review in graduate training process management. Source materials include training plans, proposal reports, and mid-term assessment forms, updated by semester or milestone, with fields covering course name, credit count, proposal date, mid-term conclusion, and signature column. The training plan provides the course and credit baseline, the proposal report provides the topic and time milestone, and the mid-term assessment form provides the stage conclusion and supervisor comments. When these three types of materials enter this feature, each serves as a comparison side: the training plan is used to check course names and credit counts, the proposal report is used to check topic names and proposal dates, and the mid-term assessment form is used to check assessment conclusions and signature receipts. The exception list and review conclusions are parsed from the response by subsequent nodes, or handled by an external system as agreed to complete the process.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, outputting the response body, status code, and returned fields. The "exception list and review conclusions" are parsed from the response by subsequent nodes, or handled by an external system as agreed to complete the process. The HTTP module sends requests to the target address; path parameters, request body, and request headers can all use variable placeholders, with variables coming from global variables, system variables, or outputs of preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Training plan | Course names and credit counts must correspond item by item with the proposal report and mid-term assessment form; dates and signature columns must not be blank | In the request preview, view the rendered full address and check the sources of course names and credits in variables; compare the field values of the same record across the three materials |
| Proposal report | Topic name and proposal date must be consistent with the training plan and mid-term assessment form; the version must be the latest synchronized version | Check the Authorization request header and the source of its value; use a sample request to compare the response and check the topic name and date fields in responseData |
| Mid-term assessment form | Assessment conclusion, supervisor signature, and receipt must be complete; the name, count, and date of the same record must not mismatch the other two materials | In the variables panel, check the source of each placeholder and confirm that the signature and receipt fields are backed by original records; compare the returned fields with the original materials |
Three common errors
- Symptom: The same course name is written differently in the training plan and the mid-term assessment form, and the count and date also mismatch. Cause: The two materials are maintained separately, without field-level comparison and unification.
- Symptom: The proposal report has been updated, but the mid-term assessment form still references the old topic name and date. Cause: The version is not synchronized, and the request body fields come from an expired node output.
- Symptom: The mid-term assessment form lacks the supervisor signature or receipt, and the review conclusion has no original record backing. Cause: The signature column was not collected, and the external system did not return the confirmation field.
How to verify the setup
Feature acceptance: preview the rendered request, check the status code and returned fields, then compare one sample result; check whether the Authorization request header, the variables placeholder sources, and the responseData returned fields are consistent.
Business test: create one exception record, see whether it can be traced back to the source material, and confirm that the review conclusion is backed by original records and that the reviewer's signature is complete.
- In the request preview, check the rendered full address and path parameters, and confirm that each placeholder variable can be resolved to an actual value.
- In the variables panel, check the source of each placeholder, confirm that the request body fields are consistent with the external interface agreement, and use a sample request to compare the response.