What this category's data looks like
In the scientific research project task book signing scenario, the materials entering this function include the project task book, the subject task breakdown table, and the budget book. The project task book is usually drafted by the lead unit after project approval, with fields including project name, number, undertaking unit, start and end dates, and signature column; the subject task breakdown table is filled in by each subject leader, with fields including subject name, leader, participants, and task milestones; the budget book is consolidated by finance or the budget preparer, with fields including account name, amount, source, and year. The three types of materials update at different rhythms: the task book flows with the signing process, the breakdown table changes with subject adjustments, and the budget book changes with funding allocation or adjustments. When the materials enter the Q&A acceptance and missing-item follow-up function, the task book serves as the main record, and the breakdown table and budget book serve as the basis for cross-checking, used to identify whether the name, quantity, and date of the same record match across the two materials, and whether the version, signature, and receipt are complete.
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 record and the completed follow-up questions are parsed from the response by subsequent nodes, or handled by an external system as agreed to complete the process. The HTTP node only sends requests to the target address; it does not write to the database or approve on behalf of the external system.
| Object | Check | Verification action |
|---|---|---|
| Project task book | Whether the project name, number, undertaking unit, start and end dates, and signature column are complete and consistent with the project approval | Check the task book fields and dates, inspect the signature and receipt; trace the source of each placeholder in the variable panel |
| Subject task breakdown table | Whether the subject name, leader, and task milestones match the task book main record | Compare the name, quantity, and date in the breakdown table and the task book; check whether the variables placeholders are parsed into actual values |
| Budget book | Whether the account name, amount, source, and year are consistent with the task book and breakdown table | Compare the name, quantity, and date in the budget book and the other two materials; view the rendered complete address in the request preview |
| HTTP request | Whether the request header authentication information and request body fields are consistent with the external interface agreement | Check the Authorization request header name and value source, and use a sample request to compare the responseData returned fields |
Three common errors
- Symptom: The name, quantity, and date of the same record do not match between the task book and the breakdown table. Cause: The two materials are filled in separately without cross-checking.
- Symptom: The budget book version is not synchronized, and the amount and account are still the old version. Cause: After funding adjustment, only one place is updated and the other is not written back.
- Symptom: The task book lacks a signature or receipt, but the process continues. Cause: Missing-item identification does not cover the signature column and receipt fields.
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; check whether Authorization, variables, and responseData appear as agreed.
Business test: submit a question missing key information and see whether it asks follow-up questions before answering.
- In the variable panel, check the source of each placeholder and confirm whether it comes from a global variable, system variable, or the output of a preceding node.
- Use a sample request to compare the returned fields and confirm that the request body fields are consistent with the external interface agreement.