What this category's data looks like
In the course selection, scheduling, and classroom resource allocation scenario, materials fall into three categories: course offering plans, scheduling tables, and course selection rules. Course offering plans are generated by the academic affairs side and include course name, course code, offering semester, planned enrollment, and approval signature; scheduling tables are produced by the scheduling side and include course name, class time, classroom number, week range, and class adjustment/suspension receipt; course selection rules are maintained by the course selection side and include selection rounds, capacity limits, priority fields, and effective dates. The three types of materials are updated by semester batch, and versions are appended during the class adjustment/suspension and add/drop stages. When materials enter the HTTP interface for integration with external systems, course offering plans serve as the baseline source, scheduling tables serve as execution records, and course selection rules serve as constraints. The fields of the three must corroborate one another in name, quantity, date, and signature, and during exception tracing the original materials are looked up by record identifier.
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 "exception list and review conclusion" is parsed from the response by subsequent nodes, or handled and completed by the external system according to the agreement.
| Object | Check | Verification action |
|---|---|---|
| Course offering plan | Whether course name, course code, planned enrollment, offering semester, and approval signature correspond item by item with the scheduling table | Take one course offering plan record, compare the course name, enrollment, and date in the scheduling table, and check the signature field |
| Scheduling table | Whether class time, classroom number, week range, and class adjustment/suspension receipt are consistent with the dates in the course selection rules | Extract the date and classroom fields for the same course in the two materials, and check the receipt number |
| Course selection rules | Whether selection rounds, capacity limits, priority fields, and effective dates are version-synchronized | Compare the rule version number and effective date, and confirm that no old version remains |
| Request URL and path parameters | Whether placeholder variables can be resolved into actual values | View the fully rendered URL in the request preview |
Three common errors
- Symptom: The name or enrollment of the same course does not match between the course offering plan and the scheduling table. Cause: The two materials are written by different nodes and are not looked up by the same record identifier.
- Symptom: The course selection rules have been updated, but the scheduling table still references the old version date. Cause: The version is not synchronized, and the HTTP request body fields are taken from expired variables.
- Symptom: Class adjustment/suspension records lack a signature or receipt. Cause: The external system does not return the confirmation field as agreed, and subsequent nodes cannot parse it.
How to verify the setup
Acceptance for this feature: preview the rendered request, check the status code and returned fields, then compare the result against one sample; check whether the Authorization request header, the variables variable sources, and the responseData returned fields are consistent.
Business test: create one exception record and see whether the source material can be traced
- In the variables panel, check each placeholder source and confirm that
variablescan be traced to global variables, system variables, or outputs from preceding nodes - Use one sample request to compare the response body, and check whether the
responseDatafields are consistent with the external interface agreement