What the documents look like
Outlet discount operations exist to clear out-of-season stock, so the working materials differ from those of full-price brand stores. The main data sources are ERP stock age, POS sales, outlet mall campaigns, and historical discount records, and they update weekly or monthly. The documents that order fulfilment and after-sales question handling must reconcile are discount approvals, slow-moving stock lists, price tags, and gross margin calculation sheets. These materials decide whether a handover request can be accepted by an external system: a discount approval shows an authorization state, a slow-moving list shows the object scope, and a price tag or margin sheet shows field values. An HTTP request sends a request against an external contract and parses the response. It does not verify whether an approval was granted, does not check whether a price tag was printed, and does not write to a business database.
Constraints at the HTTP integrations step
The HTTP module sends a request to a corresponding address. Params carry path request parameters, Body carries the request body, and Headers carry request headers; all three can reference variables through {{}}, and variables come from global variables, system variables, and upstream node outputs. The URL can also reference variables. A return value is a parsing rule that extracts a value from the interface response through JSON path syntax, and when the output type is set to string, the value of the corresponding key is converted into a json string. Among system variables, chatId and responseChatItemId do not exist in test mode, so empty values seen during debugging are an environment difference. When calling the chat completions interface, passing body.appId in the request body is recommended, and Authorization: Bearer <apiKey>-<appId> is also supported. Passed fields such as model and temperature have no effect because the orchestration decides them. With detail=true, non-streaming results are stored in responseData, while streaming distinguishes them through event; an interactive node returns interactive containing only type and params. Forms collect values, and business verification, approval, database writes, and external synchronization each need their own downstream implementation.
Hypothetical paper exercise sample: the material text reads "Discount approval form: SKU A-1042, store M-07, requested discount 40 percent, approval status is pending review, application date 2024-06-03" and "Slow-moving stock list: A-1042 stock age 210 days, clearance recommended." The draft sentence to be judged is "The discount for A-1042 has been approved; please push the price tag change through the interface." The judgment point: the approval status is pending review, which is an unauthorized state, and the draft sentence writes pending review as approved, so the interface push request lacks an authorization basis.
Configuration and implementation checks
The table below centers on that sample and lists settings or implementation checks that the official documents describe. The values are starting points for this hypothetical exercise, used for comparison against the sample materials, and are not official defaults.
| Configuration item | Hypothetical starting point for this exercise | Basis for checking |
|---|---|---|
| Request address and method | POST to the external price tag service address | Chosen per the external interface document; the address can reference variables |
| Headers authentication | Authorization references a configured credential variable | Credentials are injected through secure configuration and not written into public samples |
| Body structure | Contains SKU, store, discount, and approval status fields | Used only under the corresponding request type; check the JSON contract |
| Variable reference | References the approval status output by an upstream node | Check the actual passed value item by item |
| Return value parsing | key set to the approval status field path, output type string | Extracted through JSON path, following JS object access rules |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | Do not treat a debug empty value as a business fault |
Three common errors
- Treating pending review as approved. The input is the sample approval form's "approval status is pending review," the comparison is the draft sentence "the discount has been approved," and the observable result is that the two status values do not match, so the draft sentence is unsupported.
- Treating retrieval or a form as an authorization execution. The input is the slow-moving stock list and the discount value collected by the form, the comparison is whether an approval-passed record exists, and the observable result is that only a clearance recommendation is present, so the interface push lacks an authorization basis.
- Treating a similarity score or retrieval result as a permission or entity filter. The input is the score field in a return value, the comparison is that field against the authorization status field, and the observable result is that score is a relevance measure and cannot replace the approval status judgment.
How to verify the setup
- Input the sample approval form text and the draft sentence, compare "pending review" with "approved," and the expected observation is that the status mismatch is identified and the draft sentence is judged unsupported.
- Input the sample slow-moving stock list and the interface push request, compare whether the request carries an approval-passed record, and the expected observation is that the push is confirmed to lack an authorization basis and remains pending verification.
- Input one return value sample, compare the parsed result of the approval status field path with the original response, and the expected observation is that the extracted value matches the response; if the response does not contain that field, record the gap and do not infer a business result.