What the documents look like
Wholesale stall trading runs on spot bargaining and consignment shipping. Purchase notes, handwritten sales slips, stall lease contracts and payment receipts form the daily document set, and records update by day or by order. Stall inventory and supplier records sit across paper slips, WeChat payment records and consignment notes. For one batch of goods, the arriving quantity, the settled amount and the balance status can each appear on a different material. This shapes the HTTP integration step: work concentrates on checking document fields one by one and on matching an external system's returned values against the actual business state of the stall.
Constraints at the HTTP integrations step
The HTTP module sends a request to a target address. Params carry path request parameters, Body carries the request body, and Headers carry request headers. All three can reference variables through {{}}. Variables come from global variables, system variables and upstream node outputs. The URL can also reference variables. Return values are extracted through JSON path syntax by configuring a key; when the output type is set to string, the value at that key is converted into a JSON string. Among system variables, chatId and responseChatItemId do not exist in test mode, so an empty debug value is not a business fault. A wrong variable reference, a Body structure that does not match the external interface contract, or an extraction path that does not match the response structure will leave downstream steps without the expected purchase or supplier fields.
Hypothetical paper exercise sample. A stall owner provides a handwritten sales slip whose text reads: "March 12, supplier A, potatoes 200 jin, unit price 1.2 yuan, paid 100 yuan, balance 140 yuan, goods already dispatched by Shunda consignment." A second item is a draft handover request intended for an external system: "Mark this order's balance status as settled and synchronize the supplier record." The request carries no settlement evidence and states neither the synchronization scope nor the authorizing person. On the available material the balance status remains unsettled, and the handover request goes beyond what the material supports.
Configuration and implementation checks
| Configuration item | Hypothetical starting point | Note and checking method |
|---|---|---|
| Request address | The interface address supplied by the external system | The address can reference variables; check it against the external interface document |
| Request method | Chosen according to the external interface document | The method decides whether Params and Body take effect; check each item |
| Headers | Authorization uses Bearer plus a credential | The credential is injected through secure configuration and kept out of public samples |
| Body | JSON built to the external interface contract | Used only under the corresponding request type; check field names and types |
| Variable reference | Upstream node outputs or global variables | Check each passed value and confirm the source node has run |
| Return value extraction | A key configured with JSON path syntax | Check the extraction path against the response structure; choose the output type as needed |
The "hypothetical starting point" column records the starting configuration for this paper exercise. This starting point was chosen so that the sales slip fields in the sample have a definite landing place; it is adjusted after checking against the external interface document.
Three common errors
- Submitting the sample's "paid 100 yuan, balance 140 yuan" directly as a settled status. The input is the handwritten sales slip text; the comparison is between the balance field and settlement evidence; the observable result is that the material contains no settlement evidence, so the status stays unsettled.
- Referencing a string variable in Body without quotation marks. The input is the two forms
"{{string}}"and{{string}}; the comparison is the JSON structure the external interface receives; the observable result is that the unquoted form is parsed as another type. - Treating the absent
chatIdorresponseChatItemIdin test mode as a business fault to troubleshoot. The input is the request record from test mode; the comparison is the system variable description; the observable result is that these two fields do not exist in test mode and must be checked in a formal session.
How to verify the setup
- Input the handwritten sales slip text from the hypothetical sample together with the draft handover request; compare the balance field against the settlement marker in the request; the observable result is that the two disagree, so the request is judged to exceed what the material supports.
- Input the two ways of writing a string variable in Body; compare the JSON structure the external interface actually receives against the expected structure; the observable result is that the quoted form keeps the string type while the unquoted form does not match the type.
- Input one formal session request and one test mode request; compare the values of
chatIdandresponseChatItemId; the observable result is that these two fields do not exist in test mode, and in a formal session they are checked against the values actually passed.
After configuration, the correspondence between the return value extraction path and the external response structure needs item-by-item checking, and the execution state of each variable's source node needs confirmation. A value obtained through retrieval or a form does not constitute business authorization. Balance settlement, supplier record synchronization, database writes and external system synchronization each require separately confirmed implementation and authorization boundaries.