What this category's data looks like
In the class scheduling and class-hour deduction scenario of training institutions, progress records and statistical reconciliation rely on three types of materials: the class schedule, the class-hour deduction records, and the class adjustment applications. The class schedule is generated by the academic affairs staff during the scheduling step, and contains the course name, teacher, classroom, class date, and time slot; the class-hour deduction records are registered by the teaching teacher or academic affairs staff after class, and contain the student, course, deduction date, and quantity; the class adjustment applications are initiated by the applicant, and contain the original class session, target class session, reason for adjustment, and signature or receipt. The materials are updated weekly, and summarized into weekly or monthly reports at the end of the month. When the three types of materials enter the HTTP interface and external systems, their roles differ: the class schedule serves as baseline data providing the class session and date basis, the class-hour deduction records serve as occurrence data providing the actual deducted class-hour quantity, and the class adjustment applications serve as exception data providing the basis for adjustments. In terms of field characteristics, the name, quantity, and date of the same class session in the three materials must be alignable, the signature or receipt must be complete, and the versions must be synchronized.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, and outputs the response body, status code, and returned fields. The progress table and statistical basis description are parsed from the response by subsequent nodes, or handled by the external system according to the agreement to complete the rest.
| Object | Check | Verification action |
|---|---|---|
| Class schedule | Whether the course name, teacher, classroom, class date, and time slot are aligned item by item with the class-hour deduction records and class adjustment applications, and whether the signature or receipt is complete | View the fully rendered address in the request preview, check the path parameters and request body fields, and confirm that the class schedule fields are consistent with the external interface agreement |
| Class-hour deduction records | Whether the deduction date, deducted quantity, and student information correspond to the class sessions in the class schedule, and whether the name, quantity, and date of the same record match across the two materials | Check the source of each placeholder in the variables panel, confirm that the class-hour deduction record fields are taken from the output of the preceding node, and then compare the response using a sample request |
| Class adjustment applications | Whether the original class session and target class session are consistent with the class schedule and class-hour deduction records, whether the reason for adjustment and the signature or receipt are clearly written, and whether the versions are synchronized | Check the request header names and value sources, confirm that Authorization is passed in according to the external system's requirements, and check whether the class adjustment application fields are sent with the request body |
| Variable sources | Each placeholder can be traced to a specific origin, and the fields returned by responseData are consistent with the fields required by the statistical basis description | Check the source of each placeholder in the variables panel, and confirm that global variables, system variables, or the output of the preceding node can be parsed into actual values |
Three common errors
- Symptom: The name, quantity, and date of the same class session do not match between the class schedule and the class-hour deduction records. Cause: The two materials are registered separately, are not checked against the same basis, and the fields are not aligned.
- Symptom: The class adjustment application lacks a signature or receipt, and the exception cannot be confirmed during statistics. Cause: The application process is not closed-loop, and the signature or receipt is not synchronized with the materials.
- Symptom: The request returns 401, and the external system receives empty fields. Cause: The source of the
Authorizationvalue is incorrect, or the request body fields are not passed in according to the interface agreement.
How to verify the setup
This feature's acceptance: preview the rendered request, check the status code and returned fields, and then compare the result against a sample.
Business test: use one week of records to check the totals, and see whether the basis and exceptions are clearly written.
- View the fully rendered address in the request preview, and check whether the placeholder variables in the path parameters, request headers, and request body can be parsed into actual values.
- Check the source of each placeholder in the variables panel, and confirm that the value origins of
variablesandresponseDataare traceable.