What this category's data looks like
This page addresses the kindergarten home-school co-education communication scenario. The materials come from daily class records, parent feedback, and notification delivery receipts, with an update rhythm of weekly aggregation and monthly verification. The progress table and statistics specification are the core deliverables. When entering the HTTP interface and external system feature, class records serve as the source of request body fields, parent request categories and notification delivery status serve as path parameters or request header identifiers, and committed items with response times and child performance descriptions serve as the basis for determining the statistics specification. Field characteristics include: committed items and response times appear in pairs, child performance descriptions must be consistent with observation records, parent request categories must fall into fixed categories, and notification delivery must have a clear status. These materials each play different roles in the feature: records provide raw data, categories provide statistical dimensions, delivery status provides a verification baseline, and finally the HTTP node sends requests to the external system, with the response body and returned fields parsed by subsequent nodes, forming a verifiable progress table and statistics specification.
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 statistics specification" is completed by subsequent nodes parsing the response, or by the external system handling it according to the agreement. The request URL, path parameters, request headers, and request body can all reference global variables, system variables, or outputs from preceding nodes via variables, and authentication information is placed in the Authorization request header according to the external system's requirements.
| Object | Check | Verification action |
|---|---|---|
| Committed items and response times | Whether the commitment received a response within the agreed time, and whether the response time is traceable | Verify whether the committed item field and response time field in the request body appear in pairs, and check whether the returned fields include the corresponding timestamp |
| Child performance descriptions | Whether the description is consistent with the observation records, and whether there is subjective exaggeration or omission | Compare the return using a sample request, and verify whether the description field matches the original observation records |
| Parent request categories | Whether the feedback falls into the agreed categories, and whether there is uncategorized or miscategorized feedback | Check whether the category field values in the request body are within the agreed range, and verify the category statistics in the returned fields |
| Notification delivery | Whether the delivery status is clear, and whether there is undelivered or missing status | Verify the delivery identifier in the request headers and request body, and check the delivery status field returned in the response body |
Three common errors
- Phenomenon: A committed item is listed in the record but no response time is seen. Cause: The request body field is missing or the external system did not fill in the response time, making the statistics specification unable to close.
- Phenomenon: The child performance description differs from the observation records. Cause: The original observation materials were not referenced when recording, and the request body field values do not match the facts.
- Phenomenon: Parent requests are uncategorized or placed in the wrong category. Cause: The category field values exceed the agreed range, and the external system receives empty fields or invalid values.
How to verify the setup
Feature acceptance: preview the rendered request, verify the status code and returned fields, then compare the result against a sample; also verify whether the variables sources, the Authorization request header, and the responseData returned fields are consistent with the external interface agreement.
Business testing: use one week of records to verify the totals, check whether the specification and exceptions are clearly stated, confirm that the record count and statistics count match, and write the specification into the table header.
- In the variables panel, verify the source of each placeholder and confirm that the request URL and path parameters can be resolved into actual values.
- Compare the return using a sample request, verify whether the request body fields are consistent with the external interface agreement, and check whether the returned fields are complete.