What this category's data looks like
This category's data involves three types of materials: student registration forms, teaching plans, and skills training records. Student registration forms are updated by the admissions and registration department at each semester's registration checkpoint, with fields including student name, ID number, major, class, registration date, and handler signature; teaching plans are published by the academic affairs office before the course starts, with fields including course name, class hours, week number, instructor, and approval signature; skills training records are filled in by the training instructor after each training session, with fields including training item, number of workstations, consumable quantity, training date, and student signature. When these three types of materials enter the Q&A acceptance and missing-item follow-up function, student registration forms are used to confirm identity and enrollment status, teaching plans are used to verify the basis for courses and class hours, and skills training records are used to support the training process and signature receipts. The update rhythm is: registration forms by semester, teaching plans by course offering cycle, and training records by week number. Field characteristics are concentrated in four categories: dates, names, quantities, and signatures, and missing-item follow-up revolves around these fields.
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 the completed follow-up items 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 all 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 |
|---|---|---|
| Student registration form | Whether name, ID number, major, class, registration date, and handler signature are complete, and whether the name and date of the same record match across the two materials | In the request preview, view the complete rendered address, check that the request body fields are consistent with the external interface agreement, and compare the return using a sample request |
| Teaching plan | Whether course name, class hours, week number, instructor, and approval signature are complete, and whether the version is synchronized | Check the request header names and value sources, and verify whether Authorization is passed in according to the external system's requirements |
| Skills training record | Whether training item, number of workstations, consumable quantity, training date, and student signature are complete, and whether missing signatures or receipts are identified | In the variables panel, check the source of each placeholder, and confirm that variables and responseData can be traced to specific origins |
| Acceptance records and completed follow-up items | Whether missing items are identified and followed up on, and whether answers are based on materials | Use a sample request to compare the returned fields, and confirm that subsequent nodes can parse the response and forward it to the handler |
Three common errors
- Symptom: The name and date of the same record do not match between the student registration form and the teaching plan. Cause: The two materials are maintained by different steps, and no field-level comparison or version synchronization has been done.
- Symptom: A skills training record is still accepted as complete material even though the signature or receipt is missing. Cause: The acceptance step does not list signatures and receipts as missing-item determination conditions, so follow-up is not triggered.
- Symptom: The request returns 401, or the external system receives empty fields or the request times out. Cause: Authentication information is not passed in according to the external system's requirements, and placeholder variables are not resolved into actual values.
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; at the same time, check whether the value sources of the three identifiers Authorization, variables, and responseData are consistent with the returned fields.
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 complete rendered address, and check whether the placeholder variables in the three places—path parameters, request body, and request headers—are resolved into actual values.
- In the variables panel, check the source of each placeholder, confirm whether it comes from a global variable, system variable, or output of a preceding node, and use a sample request to compare the returned fields.