What this category's data looks like
This page addresses kindergarten safety protection and emergency drill scenarios, and the materials come from daily inspection records, drill plans and sign-in sheets, access control and school bus checklists, and hazard rectification ledgers. When these materials enter the HTTP interface and external system functions, they each play different roles: hazard items and rectification deadlines serve as fields to be verified, drill headcounts and sign-ins serve as statistical bases, access control and school bus check items serve as the basis for item-by-item ticking, and responsible person signatures serve as closed-loop evidence. The update rhythm is weekly aggregation and monthly verification, and the field characteristics include date, class, check item, expected and actual attendance counts, rectification status, and signature column. The progress table and statistical scope description need to state the statistical scope, exception handling, and total rules in the header, so they can be directly referenced when entering weekly or monthly reports.
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 from the response by subsequent nodes, or handled by the external system according to the agreement to complete the next step.
| Object | Check | Verification action |
|---|---|---|
| Hazard items and rectification deadlines | Whether the hazard is closed-loop and whether the rectification deadline falls within the agreed range | In the request preview, view the complete rendered address, and verify the rectification status and deadline in the returned fields |
| Drill headcounts and sign-ins | Whether the drill records are consistent with the plan and whether the sign-in headcount matches the expected attendance count | Use one sample request to compare the response, and verify the headcount and sign-in details in responseData |
| Access control and school bus check items | Whether any check items are missing and whether the responsible person signatures are complete | Verify the request header names and value sources, and confirm that the Authorization authentication information is passed in according to the external system requirements |
| Request body and variable sources | Whether the fields are consistent with the external interface agreement and whether each placeholder can be traced to a specific source | In the variable panel, verify the source of each placeholder in variables, and compare one sample request |
Three common errors
- Symptom: hazard records show as not closed-loop but are included in the total. Cause: the statistical scope does not separate rectification deadlines from closed-loop status, and exceptions are not stated in the header.
- Symptom: drill records do not match the plan, and the headcounts do not add up. Cause: the sign-in sheet is not grouped according to the plan, and expected and actual attendance are mixed together during statistics.
- Symptom: access control and school bus check items are missing, and the signature column is blank. Cause: the request body fields are inconsistent with the external interface agreement, and missing returned fields are not backfilled.
How to verify the setup
This function's acceptance: preview the rendered request, verify the status code and returned fields, then compare the result against one sample.
Business test: use one week of records to verify the total, and check whether the scope and exceptions are clearly stated.
- In the request preview, view the complete rendered address, and confirm that placeholder variables can be parsed into actual values.
- Verify the request header names and value sources, and confirm that authentication information is passed in according to the external system requirements.