What this category's data looks like
This page addresses course selection, scheduling, and classroom resource dispatch scenarios; the materials include three categories: course offering plans, scheduling tables, and course selection rules. Course offering plans provide course names, course codes, credits, and offering semesters; scheduling tables provide class times, classroom numbers, instructors, and week numbers; course selection rules provide selection capacity, priority, and add/drop dates. When these materials enter the HTTP interface and external systems, they respectively serve as the source of request body fields, the values of path parameters, and the basis for request header authentication. The update cadence advances according to semesters and academic calendar milestones, and the field characteristics are mainly dates, classroom numbers, course codes, and signature fields. Data versions and change maintenance require that the current version be unique, old versions be traceable, and references be synchronized, so that the name, quantity, and date of the same record remain consistent across the course offering plan, scheduling table, and course selection rules, and that signatures or receipts are retained.
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 version ledger and change records are parsed from the response by subsequent nodes, or handled by the external system according to the agreement and then completed. The HTTP node does not replace the external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Course offering plan | The course code, course name, credits, and offering semester are consistent in the scheduling table and course selection rules, and the signature field is complete | Check that the request body fields align item by item with the course offering plan fields, and check that the course code is consistent in the scheduling table and course selection rules |
| Scheduling table | The class time, classroom number, week numbers, and instructor name are consistent in the course offering plan and course selection rules, and the receipt is traceable | Check the source of the path parameter and request header values, and use a sample request to compare the returned classroom number and week numbers |
| Course selection rules | The selection capacity, priority, and add/drop dates are consistent in the course offering plan and scheduling table, and the version number is unique | Check that the request body fields are consistent with the course selection rules agreement, and check whether the add/drop dates and capacity are updated synchronously |
| Variable sources | Each placeholder variable can be traced to a global variable, system variable, or the output of a preceding node, and the parsed value is non-empty | Check the source of each placeholder in the variables panel, and confirm that variables and responseData can be parsed |
Three common errors
- Symptom: The name, credits, or dates of the same course do not match between the course offering plan and the scheduling table. Cause: The two materials are maintained separately and are not updated synchronously under the same version number.
- Symptom: The external system receives empty fields or old values. Cause: The request body placeholder variables are not parsed, or the version is not synchronized, causing old content to be referenced.
- Symptom: The scheduling table lacks a signature or receipt, and the course selection rules have no confirmation record. Cause: Change records are not archived with the version ledger, and the reference chain breaks at an intermediate node.
How to verify the setup
Acceptance of this feature: preview the rendered request, check the status code and returned fields, then compare the result against one sample; also check whether Authorization, variables, and responseData appear as agreed.
Business test: change one piece of content and see whether the version number and references are updated synchronously
- In the request preview, view the complete rendered address and check that the path parameter placeholders have been parsed into actual values
- Check the request header names and the source of the
Authorizationvalue, and confirm that the authentication information is passed in according to the external system's requirements