What the documents look like
Fruit-store procurement in this category works from four document types: purchase orders, acceptance records, pesticide-residue test reports, and loss records. A purchase order records the variety, quantity, and supplier. An acceptance record records the grade received and any discrepancy against the order. A pesticide-residue test report ties a batch to a compliance conclusion. A loss record reflects what the store actually discarded. Updates arrive daily or per batch, and order fulfilment plus after-sales answering depends on matching purchase-order status against acceptance-record status.
Compared with convenience-store fresh-food ordering, fruit procurement relies more on wholesale-market pricing and grade-based acceptance, so the source material is spread across market pricing, supplier quotes, store sales, and test reports rather than a head-office standard meal list. For HTTP integration work, that spread matters because the request payload and the extracted return value must carry the same identifiers that appear on these documents: variety, quantity, grade, supplier, and batch number.
Constraints at the HTTP integrations step
The HTTP module sends a request to an external address. Params carry path request parameters, Body carries the request body, and Headers carry request headers. Variables come from global variables, system variables, and upstream node outputs, and can be referenced with {{}}. System variables include appId, chatId, responseChatItemId, variables, cTime, and histories; chatId and responseChatItemId do not exist in test mode. Return values are extracted with JSON path, and when the output type is set to string, the value of the corresponding key is converted to a JSON string.
The chat interface uses APIKey authentication, and when calling chat/completions the recommendation is to pass body.appId in the request body. Passed fields such as model and temperature have no effect, because the orchestration decides them. With detail=true, intermediate values are returned, and in stream mode they are distinguished by event. An interactive node returns an interactive object containing only type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs, and nodeResponseId are not returned. Form input must be serialised as an object into a string and passed as the messages value, with the same chatId maintained.
Hypothetical drill sample: a store fresh-produce supervisor submits a purchase order on 10 March 2025. The supplier is "Qinghe Fruit and Vegetable", the variety is Red Fuji apple, the quantity is 200 boxes, and the acceptance grade is Grade 1. The acceptance record shows 195 boxes actually arrived, of which 5 boxes had surface bruising. Pesticide-residue test report number JC-20250310-07 concludes as compliant. The loss record shows 3 boxes discarded at the store that day. The handover request to be judged is: "Please use the HTTP interface to synchronise this batch's acceptance discrepancy to the supplier system and automatically generate a replenishment order."
Configuration and implementation checks
| Configuration item | Assumed trial starting point for this page | How to check |
|---|---|---|
| Request address and method | Chosen from the external interface document; the address may reference a supplied variable | Compare the address and method against the external interface contract |
| Params and Headers | Authentication credentials injected through secure configuration | Check request parameters and headers; do not place credentials in a public sample |
| Body | Used only under the corresponding request type | Compare the JSON structure against the external interface contract |
| Variable references | Reference global variables, system variables, or upstream node outputs | Check each value actually passed in |
| Return-value extraction | Extract the required field by JSON path | Check the key and the output type |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | Do not treat a debug empty value as a business fault |
Reason for this assumed trial starting point: the sample involves four document types, so the request address, authentication, request body, and return-value extraction all need checking. What to compare against: compare the values actually passed in against the quantity, grade, and batch number recorded in the sample, item by item.
Three common errors
- Treating retrieval or a form as authorised execution. In the sample, the handover request asks for the acceptance discrepancy to be synchronised and a replenishment order generated; a value collected by a form is not supplier confirmation and is not replenishment authorisation. Check input: the handover request text. Comparison object: whether a supplier confirmation or authorisation record exists. Observable result: the request is unsupported.
- Treating a chatId and responseChatItemId that do not exist in test mode as a business fault. In the sample, if the call is made in test mode, these two fields do not exist. Check input: the test-mode call record. Comparison object: the system-variable description. Observable result: the empty value is not judged as a fault.
- Treating the display configuration returned by an interactive node as the complete runtime state. In the sample, if the workflow reaches an interactive node, the returned interactive object contains only type and params. Check input: the interactive-node response. Comparison object: the field scope stated in the documentation. Observable result: fields such as entryNodeIds do not appear.
How to verify the setup
- Input the purchase order and acceptance record text from the sample, compare the ordered quantity of 200 boxes with the accepted quantity of 195 boxes, and observe whether the discrepancy field in the HTTP module's return value matches 5 boxes. Expected: the discrepancy field can be extracted; no claim is made that this was actually tested.
- Input the handover request text from the sample, compare whether a supplier confirmation or authorisation record exists, and observe whether form input is judged as authorised execution. Expected: unsupported, with the evidence gap retained.
- Input pesticide-residue test report number JC-20250310-07 from the sample, compare the key extracted from the return value against the report-number field, and observe whether the value is converted to a JSON string when the output type is string. Expected: checkable; the first match is not guaranteed.