What this category's data looks like
The revision of undergraduate programs involves three types of materials: the program, course syllabi, and the credit structure table. The program serves as the master outline, the course syllabi support course setup, and the credit structure table verifies credit distribution. The materials come from exports of the academic affairs system and revision drafts submitted by departments, with updates advancing by semester or revision batch, and fields include course name, credits, class hours, semester offered, revision date, and signature field. When the materials enter the HTTP interface and external system feature, the program is referenced as the master record, while the course syllabi and credit structure table provide field-level evidence as attached materials, and together the three form the basis of the version ledger and change records.
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 version ledger and change records are parsed from the response by subsequent nodes, or handled and completed by the external system according to the agreement.
| Object | Check | Verification action |
|---|---|---|
| Program | Whether the course name, credits, revision date, and signature field are consistent between the program and the course syllabi | Check the field values and signature receipt of the same record in the two materials, and compare the revision date |
| Course syllabi | Whether the course name, class hours, semester offered, and credit structure table match | Use a sample request to compare the returned fields, and check the names, quantities, and dates |
| Credit structure table | Whether the total credits and distribution are synchronized with the current version of the program | Check the version number and reference relationships, and confirm that the old version is traceable |
| Request header | Authentication information is passed in according to the external system's requirements | Check the request header names and value sources, and confirm that the Authorization value is correct |
Three common errors
- Symptom: The name, quantity, or date of the same course does not match between the two materials. Cause: The program and course syllabi are maintained separately, without field-level comparison.
- Symptom: The old version of the program is still referenced by the external system. Cause: The version is not synchronized, and the reference relationships are not updated with the revision.
- Symptom: The materials lack signatures or receipts. Cause: The revision process is not closed-loop, and the signature field and receipt are not archived together with the version.
How to verify the setup
Feature acceptance: preview the rendered request, check the status code and returned fields, then compare the result against one sample; check the value sources of responseData and variables.
Business test: change one piece of content and see whether the version number and references are updated synchronously.
- In the variables panel, check the source of each placeholder and confirm that
variablesandresponseDatacan be traced to specific origins. - Use one sample request to compare the returned fields, and confirm that the external system receives non-empty fields and that there are no 401s or timeouts.