What this category's data looks like
In the training institution scheduling and class cancellation scenario, materials mainly fall into three categories: class schedules, class cancellation records, and class adjustment applications. Class schedules come from the academic affairs system's scheduling export, with fields including course, class, teacher, classroom, week number, period, and effective date; class cancellation records come from check-in or teacher confirmation, with fields including student, course, cancellation date, number of class hours, and signature or receipt; class adjustment applications come from the approval workflow, with fields including original class session, target date, reason, approval status, and signature. In terms of update cadence, class schedules are refreshed weekly or based on class adjustment results, class cancellation records are generated per occurrence, and class adjustment applications advance with approval nodes. When materials enter the Q&A acceptance and missing-item follow-up function, class schedules are used to verify scheduling facts, class cancellation records are used to verify completed class hours and signatures, and class adjustment applications are used to verify dates and approval receipts. The field definitions of the three material categories need to be aligned, and the name, quantity, and date of the same record must be mutually verifiable.
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 "acceptance records and items to be completed" are parsed from the response by subsequent nodes, or handled by an external system according to the agreement to complete the process. The HTTP module sends requests to the target address, and variables can be used as placeholders in three places: path parameters, request body, and request headers. Variables come from global variables, system variables, or outputs of preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Class schedule | Whether course, class, teacher, classroom, week number, period, effective date, and signature are complete, and whether the date of the same class session is consistent between the class adjustment application and the class schedule | View the fully rendered address in the request preview, check the path parameters and request body fields, and compare the response using a sample request |
| Class cancellation record | Whether student, course, cancellation date, number of class hours, and signature or receipt are complete, and whether the name, quantity, and date of the same record match between the class cancellation record and the class schedule | Check the request header names and value sources, confirm that Authorization is passed in according to the external system's requirements, and inspect the origin of each placeholder in variables |
| Class adjustment application | Whether original class session, target date, reason, approval status, and signature are complete, and whether the version is synchronized with the latest class schedule | Compare the response using a sample request, and check whether the fields returned in responseData cover the fields required for acceptance records and items to be completed |
| Variable source | Each placeholder can be traced to a specific origin, and the request body fields are consistent with the external interface agreement | Check the origin of each placeholder in the variables panel, and confirm that global variables, system variables, or outputs of preceding nodes can be parsed into actual values |
Three common errors
- Symptom: The request returns 401. Cause: The value source of
Authorizationis inconsistent with the external system's requirements, and the authentication information is not passed in according to the agreement. - Symptom: The external system receives empty fields. Cause: The name, quantity, and date of the same record do not match between the class schedule and the class cancellation record, and the placeholder variables are not parsed into actual values.
- Symptom: The request times out. Cause: The class adjustment application version is not synchronized, the target address or path parameters point to an expired interface, and the returned fields cannot cover the acceptance records and items to be completed.
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 a sample; check the origin of each placeholder in variables, and confirm that the values of Authorization and responseData conform to the external interface agreement.
Business test: submit a question missing key information, and see whether it asks a follow-up question before answering.
- In the request preview, view the fully rendered address, and check whether the path parameters, request headers, and request body fields are consistent with the external interface agreement.
- In the variables panel, check the origin of each placeholder, and confirm that global variables, system variables, or outputs of preceding nodes can be parsed into actual values.