What this category's data looks like
This page is for the compulsory education dropout prevention and school retention scenario. The materials come from three types of ledgers and receipts: dropout risk ledgers, persuasion-to-return records, and home visit records. The ledgers are updated weekly or monthly, and the fields include student identifiers, risk levels, persuasion-to-return dates, home visit dates, signatures, and receipt numbers. When the ledgers enter this function, they serve as the value sources for request bodies and path parameters, and the HTTP node in the workflow sends requests outward; the persuasion-to-return records and home visit records respectively play the roles of progress details and supporting evidence, and the statistical scope description is placed in the header for subsequent nodes to parse the response and then summarize.
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 "progress table and statistical scope description" is parsed by subsequent nodes, or handled externally by an external system according to the agreement. Path parameters, request bodies, and request headers can all use variable placeholders, and the variables come from global variables, system variables, or the output of preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Dropout risk ledger | The name, quantity, and date match the persuasion-to-return records | Use one sample request to compare the response, and check whether the ledger fields are consistent with the interface agreement |
| Persuasion-to-return record | The persuasion-to-return date, signature, and receipt are complete | Check each placeholder source in the variable panel, and confirm that the date and signature fields are non-empty |
| Home visit record | The home visit date and version are consistent with the ledger | View the fully rendered address in the request preview, and compare the home visit record date and version |
| Request header | Authentication information is passed in according to the external system's requirements | Check the request header name and value source, and confirm that the Authorization value comes from variables |
Three common errors
- Symptom: The name, quantity, and date for the same student do not match between the ledger and the persuasion-to-return record. Cause: The two materials are maintained separately and have not been checked against a unified scope.
- Symptom: The home visit record version is not synchronized, and the old version is still referenced. Cause: After the materials were updated, they were not synchronized to the request value source.
- Symptom: The persuasion-to-return record lacks a signature or receipt, but the statistics still include it in the total. Cause: Exceptions are not clearly stated in the header scope, and are not excluded during verification.
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 one sample to confirm that responseData contains the agreed fields.
Business test: use one week of records to verify the total, and see whether the scope and exceptions are clearly stated.
- Check the source of each placeholder in the variable panel, and confirm that
variablesandAuthorizationcan be traced to specific origins. - Use one sample request to compare the response, and check that the request body fields are consistent with the external interface agreement.