What this category's data looks like
This category covers three types of materials: the project application form, the budget application form, and the cooperation agreement. The project application form is written by the lead institution and contains the research content, assessment indicators, participating institutions, and task division; the budget application form is prepared by the finance staff and the project leader and contains budget categories, amounts for each category, and the basis for calculation; the cooperation agreement is signed by the cooperating parties and contains task division, funding allocation, intellectual property ownership, and signature and seal pages. The three types of materials are exported from the application system or uploaded after offline signing, and then enter the HTTP interface and external system stage. The update rhythm follows the application milestones: preliminary application, formal application, budget review, and task book signing; each adjustment produces a new version. Field characteristics are concentrated in four categories: name, quantity, date, and signature: the name of the same participating institution in the project application form and the cooperation agreement must be consistent, the quantity and unit price of the same equipment in the budget application form and the project application form must correspond, and the start and end dates and signature dates must fall within the application period.
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 exception list and review conclusions are parsed from the response by subsequent nodes, or handled by the external system as agreed and then completed. The HTTP node does not replace the external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Project application form | Participating institution names are consistent with the cooperation agreement, and the start and end dates and signature dates fall within the application period | Check the participating institution names, task start and end dates, and signature page of the project application form; view the fully rendered address in the request preview and compare the returned fields |
| Budget application form | Budget category amounts correspond to the task volume in the project application form, and equipment quantity and unit price are consistent | Check the budget application form's category amounts, equipment quantity, and calculation basis; use a sample request to compare the response and check the responseData field |
| Cooperation agreement | Partner names, task division, and funding allocation are consistent with the project application form, and signatures and seals are complete | Check the signature page and receipt of the cooperation agreement; check the request header names and value sources, and pass authentication information into Authorization as required by the external system |
| HTTP request variables | Path parameters, request body, and request header placeholders can be resolved into actual values | Check the source of each placeholder in the variables panel; variables come from global variables, system variables, or the output of preceding nodes, and check the variables source |
Three common errors
- Symptom: the same participating institution has different name spellings in the project application form and the cooperation agreement, and the external system cannot match them after receiving them. Cause: the two materials were filled in separately, without comparing names and unified social credit codes.
- Symptom: the equipment quantity in the budget application form does not match the task volume in the project application form, and the returned fields are inconsistent with the sample. Cause: versions were not synchronized; after modification only one material was updated, while the other remained the old version.
- Symptom: the cooperation agreement lacks a signature or receipt, and the external system receives empty fields. Cause: the signing process was not completed before upload, and the request body fields are inconsistent with the external interface agreement.
How to verify the setup
Acceptance of this feature: preview the rendered request, check the status code and returned fields, then compare the result against a sample to confirm that the value sources of responseData and variables are traceable.
Business test: create an exception record and see whether it can be traced back to the source material; the exception has original record support and a reviewer's signature, and is handed to the responsible person for handling.
- Check that the request address and path parameter placeholder variables can be resolved into actual values, and view the fully rendered address in the request preview.
- Check the request header names and value sources, pass authentication information as required by the external system, and confirm that the request body fields are consistent with the external interface agreement.