What the documents look like
Franchise supervision data centres on head office oversight of how franchisees carry out standards. The main sources are the supervision app, POS sales, the franchise system and store photographs, while the routine documents are store visit forms, franchise contracts, rectification notices and display standards. These materials sit across separate systems, so operating reports and anomaly reviews have to connect visit records, order verification and rectification tracking. Updates arrive weekly and monthly, and interface calls are mainly periodic summaries rather than real-time transaction triggers.
A hypothetical paper drill sample is used throughout this page. A franchise supervisor holds the following store visit form text during a paper-based review: "Week 2 of March 2024, Store A, display standard check item: end-cap goods match the head office display diagram, check result: rectification pending; rectification notice number: ZL-2024-031, rectification deadline: 20 March 2024; franchise contract number: JM-2023-088, contract valid until 31 December 2025." The proposed handover request reads: "Update Store A's rectification notice status to completed and synchronise it to the franchise system." That request lacks rectification completion confirmation material and is pending determination.
Constraints at the HTTP integrations step
The HTTP module sends a request to the corresponding address. Params carry path request parameters, Body carries the request body, and Headers carry special information. URL, Params, Headers and Body can all reference global variables, system variables and preceding node outputs through {{}}. Return values are extracted through JSON path, and when the output type is set to string the value of the corresponding key is converted into a json string.
The chat interface uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended, and Authorization: Bearer <apiKey>-<appId> is also supported. chatId and responseChatItemId do not exist in test mode, so an empty debug value is not a business fault. Passed-in fields such as model and temperature have no effect and are determined by the orchestration. When detail=true, intermediate values are stored in responseData.
For this task, the proposed handover request is a business action rather than a retrieval or form-filling step. The store visit form records a check result of rectification pending and a rectification notice with a deadline. No rectification completion confirmation appears in the supplied material. The request therefore remains pending determination, and the interface call cannot be treated as authorised execution.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point | Verification method |
|---|---|---|
| Request address | The address given in the external interface document | Check that the address and method match the interface contract |
| Params | Path parameters filled in per the interface document | Compare each parameter name and value against the interface document |
| Headers | Authorization injected using Bearer | Check that the credential is passed through secure configuration |
| Body | Request body written to the JSON structure | Check that fields match the external interface contract |
| Variable reference | Reference to a global variable or preceding node output | Check the actual passed value against the source node output |
| Return value extraction | key configured by JSON path | Check that the extraction path matches the response structure |
The starting point for the request address is chosen because the external interface document supplies the address and method, and it is compared against that contract rather than treated as a default. The variable reference starting point reflects the documented sources of variables, and it is compared against the actual value produced by the named source node.
Three common errors
- Treating an empty chatId in test mode as a business fault. Check: input a test-mode request, compare whether chatId is present, and observe whether the return lacks that field because of test mode.
- Referencing a string variable in Body without quotation marks, which breaks JSON parsing. Check: input a Body containing a string variable, compare the parsed result with and without quotation marks, and observe whether the field value type changes.
- Synchronising a rectification notice recorded as rectification pending directly as completed to the franchise system. Check: input the store visit form text and the proposed handover request, compare whether rectification completion confirmation material is present, and observe whether the request meets execution conditions.
How to verify the setup
- Verification one: input the store visit form text and the proposed handover request from the hypothetical drill sample. Compare whether the request statement "rectification notice status updated to completed" agrees with the source text "check result: rectification pending", and observe whether rectification completion confirmation material is absent. Where it is absent, the request does not meet execution conditions. This is an expected reading of the supplied material, not a record of a completed test.
- Verification two: input a chat request in test mode. Compare whether chatId and responseChatItemId are present, and observe whether those two fields are absent from the return. Absence is a normal condition of test mode and does not constitute a business fault. The expected observation is that the fields are missing; no actual run is claimed.
- Verification three: input a Body containing a string variable and a number variable. Compare the reference with quotation marks against the reference without them, and observe whether the field value type in the final parsed result matches the expectation. Where a string variable is referenced without quotation marks, the parsed result does not match the expectation. This remains a paper comparison rather than a performed test.
Across all three checks, the rectification notice status and the franchise system synchronisation are downstream business actions. The supplied material does not include a documented error code, a scheduled trigger, an approval record or an execution result, so those remain unknown. The store visit form, the franchise contract and the rectification notice are separate documents with separate states, and the contract validity date does not by itself establish the rectification status. Missing evidence stays missing.