What this category's data looks like
Student status establishment and changes in primary and secondary schools involve three types of materials: student status archives, transfer applications, and suspension/resumption materials. Student status archives include students' basic information, family information, enrollment date, and homeroom teacher's signature; transfer applications include the names of the transferring-out and transferring-in schools, application date, seals from both parties, and receipt; suspension/resumption materials include the reason for suspension, start and end dates, hospital certificate, and approval signature. The three types of materials are summarized weekly by the school's student status administrator and entered into the system after verification by the district/county education department. When materials enter this function, student status archives serve as the main record providing student identifiers and status fields, while transfer applications and suspension/resumption materials serve as change events providing date and signature fields; together, the three support progress records and statistical verification. The update cadence is once per week, and field characteristics are concentrated in four categories: name, quantity, date, and signature, which need to be aligned item by item with the fields returned by the external system interface.
Configuration and implementation checks
The HTTP node in the workflow only outputs the response body, status code, and returned fields. The progress table and statistical scope description must be handled by subsequent nodes parsing the response, or by the external system according to the agreement.
| Object | Check | Verification action |
|---|---|---|
| Student status archive | Fields include student identifier, enrollment date, and homeroom teacher's signature, and must be consistent with the name, quantity, and date in the transfer application | In the request preview, check the rendered complete address and request body fields, and confirm that the archive fields in responseData align item by item with the paper materials |
| Transfer application | Fields include the names of the transferring-out and transferring-in schools, application date, and seals and receipt from both parties, and must match the dates in the student status archive | Check the request header names and value sources, confirm that Authorization is passed in according to the external system's requirements, and then compare the application date and receipt fields in the response |
| Suspension/resumption materials | Fields include the reason for suspension, start and end dates, and approval signature, and must be synchronized with the status fields in the student status archive | In the variable panel, check the source of each placeholder, confirm that variables can be traced to a specific origin, and then check whether the signature and receipt fields in the response are complete |
Three common errors
- Symptom: The name, quantity, and date for the same student do not match between the student status archive and the transfer application. Cause: The two materials are entered separately, and the field definitions are not unified in the request body.
- Symptom: The version of the suspension/resumption materials is not synchronized, and the old version's signature is missing. Cause: The request header does not pass authentication information according to the external system's requirements, and no retry is made after a 401 response.
- Symptom: The external system receives empty fields, and the statistical count does not match the record count. Cause: The path parameter placeholder variables are not parsed into actual values, and no resend is made after the request times out.
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 to confirm that the fields in responseData are consistent with the materials.
Business test: use one week of records to verify the totals, check whether the scope and exceptions are clearly stated, and confirm that the record count and statistical count match and that the scope is written in the header.
- In the request preview, view the rendered complete address and check that the path parameter placeholder variables can be parsed into actual values
- In the variable panel, check the source of each placeholder and confirm that the value sources of
variablesandAuthorizationare traceable