What this category of data looks like
Data sources for this category include real-time collected data from molten iron and scrap steel, L2 process control data, laboratory composition test data, MES production management data, energy medium system data, and equipment condition monitoring data. Update cycles cover per heat, real-time, and shift-based periods. Daily documents include heat plans, batching lists, converter smelting records, composition reports, continuous casting process records, and slab judgment sheets. Fields include production-related parameters such as tapping temperature (degrees Celsius), molten iron silicon content value, continuous casting pulling speed (meters per minute), and slab thickness (millimeters).
What constraints these characteristics impose on the "workflow orchestration" link
Data for this category comes from multiple sources with varying update frequencies. Workflow orchestration must support parallel pulling of heterogeneous data from different systems across multiple nodes, to avoid delays caused by serial data pulling. Independent production data per heat requires workflows to bind the heat ID as the variables parameter, to ensure precise binding of data to its corresponding heat. High-temperature continuous processes cannot be shut down arbitrarily, so workflows must be configured with breakpoint continuation and failure retry mechanisms, to avoid a single heat’s abnormal interruption disrupting the overall production rhythm. The need for validation of multiple document fields requires workflows to include built-in field validity check nodes, to intercept parameters that do not meet process requirements in advance. The strong coupling between casting sequence and heat requires workflows to set node trigger dependencies, to ensure that previous process data is completed before starting the current audit link.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
variables | Bind heat ID and cast ID as global variables, in the format {"furnaceId": "current heat number", "castId": "current cast number"} | Ensure precise binding of each heat’s production data to the audit process, avoid cross-heat data confusion |
| Node trigger condition | Start only when the preceding node’s status is "successful" | Ensure that collected data from previous processes is complete before executing audit steps, avoid missing necessary production parameters |
| Failure retry count and interval | 3 times, 60-second interval | Respond to temporary system interface fluctuations, avoid workflow interruption caused by a single interface exception |
| Form node popup mode | Enable silent submission mode | When the workflow is nested as a sub-flow, avoid repeated popups interfering with main flow operations |
| Workflow timeout threshold | 1800 seconds | Cover the full process duration from multi-source data pulling, audit to result pushing, avoid timeout caused by large data volume |
Three common mistakes
- Scenario: When calling a custom Python code function, the workflow node status stays at "running" for a long time with no return results. Cause: No timeout threshold is configured for code execution, leading to long waits for unfinished code logic.
- Scenario: When a form input node is nested as a sub-flow, the popup persists and cannot be submitted automatically. Cause: Silent submission mode for the form node is not enabled; the default configuration only hides popups in independent workflows.
- Scenario: Workflow runs slowly, and single-heat audit time exceeds the preset threshold. Cause: Multi-node parallel data pulling is not configured, serial pulling of data from multiple systems leads to increased overall delay.
How to confirm the configuration is correct
- Check the
variablesparameter configuration of the workflow, confirm that the unique identifiers of the current heat and cast are bound. Simulated parameters can be passed through a test node to verify the validity of data binding. - Trigger the workflow’s preceding node, verify that subsequent audit nodes start only when the preceding node’s status is successful. Node trigger order can be checked against expected logic via logs.
- Check whether the
nodeIdof each node matches the preset trigger logic, ensure that the dependency relationships between nodes are correct. FastGPT v4.17.0’s node debugging tool can be used to verify this. - Nest the workflow into the main flow, verify that the form node does not display a popup. Popups only appear when the workflow runs independently. Confirmation can be completed via interface operations in the test environment.
- Simulate a single interface exception scenario, verify that the workflow automatically triggers retries, and that the retry count and interval match the preset configuration.
The values provided here are common starting points, and should be evaluated against the relevant operational datasets.