What this category's data looks like
Enterprise independent skill talent evaluation involves three types of materials: the evaluation filing form, the evaluation specification, and the candidate roster. The filing form contains the evaluation agency, occupation name, level, batch, and date, and requires a signature or receipt; the evaluation specification contains the assessment method, weights, and scoring rules; the roster contains candidate names, ID numbers, declared levels, and quantities. The materials come from the declaration, review, and examination administration stages, and their update cadence changes with batch adjustments, specification revisions, and personnel changes. When entering the HTTP interface and external system functions, the filing form is used to trigger filing status synchronization, the evaluation specification is used to pull or push the version number and effective date, and the roster is used for batch verification and receipt confirmation. Fields, dates, and signatures are the key verification points. If the name, quantity, or date of the same record does not match across two materials, or if the version is not synchronized, or a signature or receipt is missing, the ledger and change records will be distorted.
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 version ledger and change records are completed by subsequent nodes parsing the response, or by the external system handling it according to the agreement. The HTTP node is only responsible for sending requests and receiving returns; it does not replace the external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Evaluation filing form | The filing form fields, dates, and signatures must be consistent with the evaluation specification and roster, and the current version must be unique | Verify the filing form fields and signature receipt in the request body, and compare the returned fields with the local ledger |
| Evaluation specification | The specification version number and effective date must be synchronized with the references in the filing form and roster, and old versions must be traceable | Verify the version placeholders in the request address and path parameters, and use variables to trace the source of each placeholder |
| Candidate roster | The roster names, quantities, and dates must be consistent with the filing form and specification; a missing signature or receipt is an anomaly | Verify the request header Authorization and request body fields, and compare the receipt status in responseData |
| HTTP request preview | The placeholder variables in the request address, request headers, and request body can all be resolved into actual values | In the request preview, view the rendered complete address and check the request header names and value sources |
Three common errors
- Symptom: The name or quantity of the same candidate does not match between the roster and the filing form. Cause: The two materials are maintained separately, and the same variable source is not uniformly referenced in the request body.
- Symptom: The evaluation specification has been revised, but the external system still processes according to the old version. Cause: The version is not synchronized, and the version placeholder in the request address or request body has not been updated with the ledger.
- Symptom: The filing form lacks a signature or receipt, but the returned fields still show success. Cause: The request header authentication information is inconsistent with the external system agreement, or the request body fields are empty.
How to verify the setup
This feature acceptance: preview the rendered request, check the status code and returned fields, then compare the result against one sample; at the same time, check whether the request header Authorization, the variable variables, and the returned responseData are consistent.
Business test: change one piece of content and see whether the version number and references are updated synchronously.
- In the variable panel, check the source of each placeholder and confirm that the variables in the request address, request headers, and request body can all be resolved into actual values.
- Use one sample request to compare the return, and verify whether the version number, date, and signature receipt in the returned fields are consistent with the ledger.