What this category's data looks like
During the admissions season, primary and secondary school admissions organizations must publicly release admissions plans, application material checklists, and admission lists, and report data to higher authorities. The admissions plan contains the admissions scope, time nodes, and signature fields; the application material checklist lists the names, number of copies, and dates of materials such as household registration, real estate, and residence permits; the admission list contains student names, admission batches, and receipt status. The three materials come respectively from the admissions working group, the material review post, and the admission release post, and are updated by batch: the plan is issued first, the checklist starts with applications, and the list is publicly announced in batches. When the materials enter this function, the plan and checklist serve as visible content at the external entrance, while the list serves as the authorization object for restricted access, with the HTTP interface returning the corresponding fields by identity.
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 "externally available entrance and authorization scope" is completed by subsequent nodes parsing the response, or by external systems handling it according to the agreement.
| Object | Check | Verification action |
|---|---|---|
| Admissions plan | The fields, dates, and signatures of the admissions scope, time nodes, and signature fields must be consistent with the higher-level filing | View the complete rendered address in the request preview, and check the plan version number and signature receipt fields |
| Application material checklist | The material names, number of copies, and dates match across the three materials | Use a sample request to compare the response, and check whether the checklist entries match the plan dates |
| Admission list | Names, admission batches, and receipt status are consistent between the list and the receipts | Check the request header Authorization and the variable sources, and confirm that the restricted identity only retrieves the corresponding batch |
| Variable sources | Each placeholder can be traced to a specific origin | Check the sources of variables and responseData in the variable panel |
Three common errors
- Symptom: The same student's name and batch do not match between the list and the receipt. Cause: The two materials are maintained separately, versions are not synchronized, and the interface returns based on the old version.
- Symptom: The number of copies in the application material checklist is inconsistent with the number of plan attachments. Cause: After the checklist was updated, it was not written back to the plan, and the field sources are not unified.
- Symptom: The externally returned admission list is missing signature or receipt fields. Cause: The request body was not passed in according to the external interface agreement, returning empty fields.
How to verify the setup
Acceptance for this function: preview the rendered request, check the status code and returned fields, then compare the result against a sample.
Business test: access once with a restricted identity and see whether the visible scope matches the setting.
- Check the request header name and value source, and confirm that
Authorizationis passed in according to the external system's requirements. - Use a sample request to compare the response, and check that the
responseDatafields are consistent with the agreements for the admissions plan, material checklist, and admission list.