What this category's data looks like
This page addresses progress records and statistical verification in graduate training process management. The materials come from three types of process documents: training plans, proposal reports, and mid-term assessment forms, which are summarized and updated weekly or monthly by the training unit. The training plan determines course and stage milestones, the proposal report records the topic selection and timing, and the mid-term assessment form carries the stage evaluation and signatures. When these three types of materials enter this function, their roles differ: the training plan provides baseline fields and planned dates, the proposal report provides actual completion dates and review information, and the mid-term assessment form provides stage conclusions and signature receipts. Field characteristics include student name, student ID, stage name, planned date, actual date, quantity, signature and receipt status. The progress table and statistical scope description must state the statistical scope, exception handling, and date attribution rules in the header, so that subsequent nodes can parse the response or external systems can process it as agreed.
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 statistical scope description" is then completed by subsequent nodes parsing the response, or by external systems processing it as agreed.
| Object | Check | Verification action |
|---|---|---|
| Training plan | Whether the fields, dates, and signatures are consistent with the proposal report and mid-term assessment form | Check the planned stage names, planned dates, and signature columns, and compare the same record in the two materials |
| Proposal report | Whether the name, quantity, and date of the same record match the training plan and mid-term assessment form | Check the proposal date and review signature, and verify the returned fields against the sample request |
| Mid-term assessment form | Whether the version is synchronized and whether signatures or receipts are complete | Check the assessment form version number and receipt status, and check the request header Authorization and variable sources |
| Request and response | Whether placeholder variables can be resolved into actual values and whether the fields are consistent with the external interface agreement | View the fully rendered address in the request preview, and verify the variables and responseData fields |
Three common errors
- Symptom: The name, quantity, and date of the same record do not match between the training plan and the proposal report. Cause: The two materials were entered separately, and the fields and date attribution were not checked against a unified standard.
- Symptom: The mid-term assessment form version is not synchronized, and the signature column is missing in the old version. Cause: The material was not returned after updating, and the external system still processes it according to the old version.
- Symptom: The request returns 401 or the external system receives empty fields. Cause: The request header authentication information and request body fields were not passed in according to the external interface agreement.
How to verify the setup
This function's acceptance: preview the rendered request, check the status code and returned fields, and then compare the result against one sample.
Business test: use one week of records to verify the totals, and see whether the scope and exceptions are clearly stated.
- In the variable panel, verify the source of each placeholder and confirm that the request address and path parameters can be resolved into actual values.
- Verify the request header names and value sources, and use one sample request to compare the returned fields with the external interface agreement.