What this category's data looks like
In the course selection, scheduling, and classroom resource dispatch scenario, the materials entering the Q&A intake and missing-item follow-up stage are mainly of three types: course offering plans, scheduling tables, and course selection rules. The course offering plan provides the course name, number of classes, start date, and department signature; the scheduling table provides classrooms, time slots, week numbers, and adjustment/suspension records; the course selection rules provide capacity, priority, conflict determination, and effective version. The materials are usually submitted by the academic affairs office or departments by semester batch, updated centrally before the start of the semester, and incrementally synchronized during the semester according to the pace of class adjustments and supplementary selection, with fields mainly consisting of course code, classroom number, date range, version number, signature, and receipt. The three types of materials play different roles in the function: the course offering plan and course selection rules serve as the basis for intake and the source for follow-up questions, while the scheduling table serves as the comparison draft for classroom resource occupancy, and missing items and inconsistencies are identified here and formed into items pending follow-up.
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 "intake record and completed question items" are parsed by subsequent nodes from the response, or handled by an external system according to the agreement to complete the process. The request URL, path parameters, request headers, and placeholder variables in the request body come from global variables, system variables, or outputs of preceding nodes; authentication information is placed in the request headers according to the external system's requirements.
| Object | Check | Verification action |
|---|---|---|
| Course offering plan | Whether the course name, number of classes, start date, and signature match the scheduling table and course selection rules | Take the same course code and compare the name, quantity, and date item by item in the two materials; those missing a signature or receipt are recorded as pending items |
| Scheduling table | Whether the classroom, time slot, week number, and version are synchronized, and whether adjustment/suspension is traceable | Check the classroom number and week range, compare the version number and class adjustment receipt, and transfer inconsistencies to the handler |
| Course selection rules | Whether the capacity, priority, and effective version are consistent with the current semester | Check the effective date and version number, confirm that the rule fields are consistent with the external interface agreement, and ask follow-up questions before answering when items are missing |
| HTTP request | Whether the request URL, request headers, and placeholder variables in the request body can be resolved into actual values | View the fully rendered URL in the request preview, use the variables panel to trace the source of each placeholder, and check the Authorization and responseData returned fields |
Three common errors
- Symptom: The name or number of classes of the same course does not match in the two materials. Cause: The course offering plan and scheduling table are maintained separately and are not checked against the same course code.
- Symptom: The course selection rule version is not synchronized, and intake is handled according to the old capacity. Cause: The new rule version does not carry an effective date and version number, and no comparison is made during follow-up.
- Symptom: Class adjustment lacks a signature or receipt, and classroom occupancy does not match. Cause: The adjustment/suspension record is traceable on only one side, and the other side has not confirmed with a receipt.
How to verify the setup
Acceptance of this function: preview the rendered request, check the status code and returned fields, then compare the result against one sample to confirm that variables, Authorization, responseData are consistent with the agreement.
Business test: submit a question missing key information and see whether it asks follow-up questions before answering.
- In the request preview, check the fully rendered URL, request header names, and value sources, and confirm that placeholder variables can be resolved into actual values.
- Use one sample request to compare the returned fields with the external interface agreement, organize missing items and inconsistencies into an intake record, and transfer them to the handler.