What this category's data looks like
This category's data comes in three layers: the course offering plan, the scheduling table, and the course selection rules. The course offering plan comes from academic affairs and departments, and contains the course name, course number, semester, start and end dates, and a signature field; the scheduling table comes from the scheduling role, and contains the classroom, week numbers, period numbers, the instructor, and a receipt; the course selection rules come from course selection management, and contain the course selection cap, prerequisite requirements, and exception notes. The three types of materials are updated weekly, with concentrated revisions at the start of the semester. When entering the progress records and statistical verification function, the course offering plan serves as the course baseline, the scheduling table serves as the classroom and time baseline, and the course selection rules serve as the headcount and exception baseline; the fields, dates, and signatures of the three must be aligned item by item in order to form the progress table and the statistical scope statement, for reference in weekly or monthly reports.
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 statement must be produced by subsequent nodes parsing the response, or handled by an external system according to the agreement. The HTTP module sends requests to the target address; variables can be used as placeholders in all three places: path parameters, request body, and request headers. Variables come from global variables, system variables, or the output of preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Course offering plan | The course name, course number, semester, and start and end dates must match the scheduling table item by item, and the signature field must be complete | In the variables panel, check the source of each placeholder, and confirm that after the course offering plan fields enter the request body they have the same names and values as in the scheduling table |
| Scheduling table | The classroom, week numbers, period numbers, and instructor must match the time and location description in the course selection rules, and the receipt must be complete | Use one sample request to compare the return, and check whether the scheduling table dates match the course selection rule dates |
| Course selection rules | The course selection cap, prerequisite requirements, and exception notes must match the capacity field of the course offering plan, and the versions must be in sync | Check the request header names and the source of their values, and confirm that the course selection rule version is in sync with the course offering plan version |
| Request address and path parameters | The placeholder variables can be resolved into actual values, and the path parameters match the external interface agreement | In the request preview, look at the full rendered address, and check the variables and responseData fields |
Three common errors
- Symptom: the same course has mismatched names, quantities, or dates in the course offering plan and the scheduling table. Cause: the two materials are maintained by different roles, and no field-level comparison was done.
- Symptom: the course selection rules have been updated, but the scheduling table still uses the old version, causing deviations in the statistical totals. Cause: the versions are not in sync, and there is no unified update node.
- Symptom: the scheduling table lacks a signature or receipt, and the progress table cannot confirm classroom occupancy. Cause: the signature step was not included in the verification checklist, and the receipt was not returned with the request.
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; in the variables panel, check the sources of variables and responseData.
Business test: use one week of records to check the totals, see whether the scope and exceptions are clearly stated, and check the fields, dates, and signatures of the course offering plan, scheduling table, and course selection rules.
- In the request preview, look at the full rendered address, and check the
Authorizationrequest header name and the source of its value. - Use one sample request to compare the return, and check whether the request body fields match the external interface agreement.