This configuration is written based on FastGPT v4.17.0.
What the data for this category looks like
This category's data covers the full lifecycle of individual products. Data sources include design BOMs, silicon steel sheet and insulating material procurement data, vacuum drying equipment operation logs, oil test reports, partial discharge and withstand voltage test data from test stations, and nameplate parameter tables. The data update rhythm follows that each product has a separate dedicated ledger, and each batch of raw materials updates corresponding batch records. Daily documents include winding and core assembly records, vacuum drying records, insulating oil test reports, partial discharge and withstand voltage test reports, and nameplate parameter tables. Core fields involve insulation structure parameters, cleanliness indicators, lead connection status, tap positions, partial discharge abnormal values, and similar items. Full field summary must be completed for each individual product.
What constraints these characteristics impose on the "workflow orchestration" link
The traceability requirement for individual products requires the workflow to bind a unique product identifier to avoid cross-batch data confusion. Multiple data sources require the workflow to configure multiple independent data access nodes, each connected to different data sources such as design BOMs, equipment operation logs, and test reports. The update rhythm for each unit or batch requires workflow variables to only take effect within the current product session, avoiding interference from global variables across instances. Core fields involve high-voltage test abnormal values. A verification node must be added to the workflow to filter abnormal data that does not meet industry conventional thresholds. Large-volume product documents require the workflow to adapt to large file reading and parsing to ensure complete extraction of ledger data. At the same time, since products require full-lifecycle traceability, the workflow must retain source records of each step of data to facilitate subsequent audits.
How to set the configuration
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
variables | Isolated per individual product instance | Individual products require independent storage of ledger data to avoid cross-instance data confusion |
| Node ID binding | Bind to the product's unique nameplate number | Ensure each workflow node corresponds to a unique product, avoiding data misuse |
| Multi-source data access | Configure nodes classified by data source | Cover multiple types of data sources including design BOMs, test reports, equipment logs, and similar items |
| Abnormality verification trigger | Trigger an alert when partial discharge data exceeds the industry conventional range | Core fields involve high-voltage test data, requiring abnormal value verification |
| Session variable validity period | 300–600 seconds | Matches the average processing duration for individual product ledger summary |
| Large file parsing configuration | Calibrated based on actual measurements | Adapt to large-volume documents such as insulating oil reports and withstand voltage test reports |
Three common mistakes
- Phenomenon: The
variablesparameter values configured in the workflow are not retained in subsequent sessions, resulting in empty core fields. Cause: Thevariableswere not configured for single-instance isolation mode, leading to global variables being reused across sessions. - Phenomenon: When calling a data node, only some ledger fields are obtained, missing core parameters such as insulating oil moisture content and partial discharge values. Cause: No parameter supplement node was configured in the workflow, and missing multi-source data parameters were not guided to be entered through interactive steps.
- Phenomenon: The workflow runs normally in local debugging, but partial discharge data is not correctly summarized during front-end testing. Cause: Inconsistent node ID binding rules between the debugging environment and the front-end environment, leading to incorrect product identifier matching.
How to confirm the configuration is complete
- Check whether the
variablesparameter is isolated per individual product instance, verify that ledger data from different product sessions does not overlap - Verify that the binding identifier of each data access node is the product's unique nameplate number, ensuring that data sources match the corresponding product
- Trigger the workflow, view the trigger logs of the abnormality verification node, and confirm that the core field verification rules are in effect
- Upload a large-volume test report, verify that the workflow can correctly parse the document content and extract corresponding fields
The values provided are common starting points and should be measured against the reader's own samples.