What this category's data looks like
This page addresses the compulsory education dropout prevention and control scenario, and the materials come from three types: dropout risk ledgers, return-to-school persuasion records, and home visit records. The ledger provides students' basic information and risk levels, the persuasion records carry the date, participants, and results of each persuasion attempt, and the home visit records supplement family circumstances and signed receipts. When these three enter the Q&A intake and missing-item follow-up feature, their roles differ: the ledger is the primary index, while the persuasion records and home visit records are retrieved and cited as supporting materials. Field characteristics center on name, student registration number, date, number of persuasion attempts, signature, and receipt status. The update cadence is weekly or event-triggered, and new records must be aligned with existing versions after entry. After the materials enter this feature, they are first parsed into retrievable segments, and then the HTTP node sends requests to external systems, handing the intake records and the completed follow-up items to subsequent nodes or external systems for processing.
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 "intake records and completed follow-up items" are parsed from the response by subsequent nodes, or handled and completed by the external system according to the agreement. The HTTP node is only responsible for sending requests and retrieving results; it does not replace the external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Dropout risk ledger | Fields include name, student registration number, risk level, date, and signature; the name and date of the same record in the two materials must be consistent | In the variables panel, check the source of each placeholder, and compare the names, quantities, and dates in the ledger and the persuasion records |
| Persuasion records | The number of persuasion attempts, date, participants, and receipt status must align with the ledger; when versions are not synchronized, the latest signed version prevails | Use one sample request to compare the response, and check whether the request body fields are consistent with the external interface agreement |
| Home visit records | Missing home visit dates, signatures, and receipts will be identified as items pending follow-up | Check the request header names and value sources, and confirm that authentication information is passed in according to the external system's requirements |
| HTTP request preview | Placeholder variables in the request URL and path parameters can be resolved into actual values | In the request preview, view the fully rendered URL, and confirm that the variables and responseData fields are traceable |
Three common errors
- Symptom: the name or date of the same student does not match between the ledger and the persuasion records. Cause: the two materials were entered separately, no consistency check of names and dates was performed, and the versions were not synchronized.
- Symptom: a home visit record is missing a signature or receipt but is still cited as complete material. Cause: the missing item was not identified as an item pending follow-up, and the intake record did not trigger a follow-up question.
- Symptom: the request returns 401 or the external system receives empty fields. Cause: the value source of
Authorizationwas not checked, and the request body fields are inconsistent with the external interface agreement.
How to verify the setup
This feature's acceptance: preview the rendered request, check the status code and returned fields, then compare the result against one sample; confirm that Authorization, variables, and responseData are all traceable.
Business test: submit a question missing key information and see whether it asks a follow-up question before answering.
- In the variables panel, check the source of each placeholder, and confirm that the variables in the request URL, request headers, and request body can all be resolved into actual values.
- Use one sample request to compare the response, check whether the request body fields are consistent with the external interface agreement, and record the number of array entries and the tokens of the cited text.