What the documents look like
Central chain procurement and distribution draws its fulfilment data from ERP purchasing, WMS, store POS, and supplier delivery records. The working documents are central purchase contracts, replenishment plans, distribution notes, and store requisition forms. Order fulfilment and after-sales answering therefore handle materials that cross systems and cross parties: one distribution note can involve headquarters purchasing, a distribution centre, and a receiving store, while one after-sales answer can cite both the delivery clause of a central purchase contract and the actual quantity on a store requisition form.
The HTTP integration step takes key fields from these materials, sends them to an external business service through the HTTP module, and reads back a result that can be checked against the source. Two facts shape this step. First, the HTTP module sends a request to a stated address, with Params for path request parameters, Body for the request body, and Headers for request headers; all three can reference variables with {{}}, and the URL can also reference variables. Second, the return-value configuration does not represent the interface's own return; it uses JSON path syntax to extract values from the response. When the output type is set to string, the value of the corresponding key is converted into a json string. These two facts mean that the transfer of fulfilment fields depends on variables and extraction rules already defined in the orchestration, and that an API parameter passed from outside does not change the orchestration's behaviour.
Constraints at the HTTP integrations step
Variables come from global variables, system variables, and upstream node outputs. The system variables include appId, chatId, responseChatItemId, variables, cTime, and histories. Of these, chatId and responseChatItemId do not exist in test mode, so an empty value seen during debugging is a difference of the running environment and is not a business fault. The histories variable takes at most 10 records by default and its length cannot be changed.
For chat interface calls, passing body.appId in the request body is recommended. The header form Authorization: Bearer <apiKey>-<appId> is also supported, and in that case body.appId need not be passed. Some SDKs need a v1 path on BaseUrl and some do not; if a 404 appears, adding v1 and retrying is the documented step. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. Fields such as model and temperature passed into the call have no effect; these are decided by the orchestration and do not change with API parameters. The actual consumed Token value is not returned; setting detail=true and manually calculating the tokens value inside responseData is the documented route.
A hypothetical paper exercise (written material used to explain the checking method, not actually executed):
Material one, an excerpt from a central purchase contract between a chain supply chain centre and a supplier: "Distribution notes under this contract take the number generated by the headquarters purchasing system as authoritative. The receiving store shall complete receipt confirmation within two working days after the arrival date stated on the distribution note."
Material two, an excerpt from the replenishment plan for the same batch: "This replenishment plan covers 12 stores in the East China region. The planned distribution date is 10 March; actual distribution follows the distribution note."
Draft sentence to be judged: "The distribution note has been signed for by the store, and the after-sales answer can cite the receipt result directly."
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Request address and method | Fill in according to the external business service document; the address may reference variables | Compare the path and method item by item against the external interface contract |
| Params and Headers | Authentication credentials injected through secure configuration, not written into public samples | Check whether the credential source in the request header is a configured variable |
| Body structure | Used only under the corresponding request type; field names match the external contract | Compare the Body declaration field by field against the external interface document |
| Variable references | Reference global variables, system variables, or upstream node outputs | Check item by item whether the actual passed value corresponds to the source material |
| Return-value extraction | Configure key and output type using JSON path syntax | Use a known field in the material to verify that the extracted result matches the source |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | When a test-mode value is empty, record it as an environment difference, not a fault |
The values in this table are hypothetical starting points for this exercise, used to explain the comparison method; they are not official default values.
Three common errors
- Treating an empty chatId or responseChatItemId in test mode as a business fault. Check: send a test-mode request, compare whether these two fields exist in the response, and observe whether this matches formal mode. The document states they do not exist in test mode, so an empty value on its own is not evidence of a fault.
- Treating the return-value configuration as the interface's own return. Check: supply a response with known fields, compare the configured key against the JSON path extraction result, and observe whether the extracted value equals the corresponding field in the response. The configuration only decides how to parse; it does not change what the interface returns.
- Treating the receipt-confirmation clause in the central purchase contract as a completed receipt. Check: supply material one and material two above, compare "has been signed for by the store" in the draft sentence against "shall complete receipt confirmation within two working days after the arrival date" in the material, and observe whether the material records an actual receipt action and a receipt date. The material gives only a required standard, not an actual receipt fact, so the draft sentence is unsupported.
How to verify the setup
- Supply material one, material two, and the draft sentence. Compare "has been signed for by the store" in the draft against the receipt wording in the source material, and observe whether the material contains an actual receiving party, a receipt date, and a receipt result. If only a required standard is present, record the sentence as unsupported and keep the evidence gap open.
- Supply a response sample containing known fields. Compare the configured key against the JSON path extraction result, and observe whether the extracted value matches the corresponding field in the response. If it does not match, record the difference between the actual extracted value and the expected field.
- Supply a test-mode request. Compare whether chatId and responseChatItemId exist in the response, and observe whether this matches the test-mode behaviour described in the document. If they are empty, record this as an environment difference and do not use it to decide a business fault or an authorization state.