What this category's data looks like
This category covers core business documents for manufacturing enterprise PMC, planning, shop scheduling, and material control departments, including sales orders, master production schedules, material requirement plans, weekly and daily production schedules, work orders, material shortage lists, and delivery change notices. Data sources include ERP orders and inventory, BOMs and process routes, equipment capacity, staff shifts, work-in-progress, and supplier delivery information. Update cycles are adjusted with daily routine scheduling and weekly reviews, and real-time updates are triggered when orders are placed or exceptions occur.
Constraints on workflow orchestration from these characteristics
The multi-source heterogeneous documents and fluctuating update cycles of this category require workflow orchestration to support unified parsing and verification of multiple input sources. Cross-department collaboration data circulation needs require clear variables transfer rules to avoid field conflicts. Real-time updates triggered by exceptions require workflows to support dynamic node activation, adapting to temporary adjustments in production scenarios. Additionally, time-consuming steps such as work order decomposition and rescheduling require configuring node timeouts and failure retry mechanisms to address recovery needs after production interruptions.
How to set up configurations
This configuration is compatible with FastGPT v4.17.0 workflow orchestration features.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
variables grouping configuration | Split into up to 5 variable groups by business document type, with 3-5 fixed fields associated per group | Adapts to multi-source heterogeneous business document structures, avoiding excessive load from single groups carrying too many fields |
| Node timeout setting | 1200 seconds | Covers the typical time required for work order decomposition and scheduling calculations, adapting to resource waiting cycles in production scenarios |
| Node retry count | 3 times | Addresses scenarios such as temporary fluctuations in equipment data or temporary jitter in ERP interfaces |
nodeId binding rule | Bind a unique nodeId to each process node | Ensures node state traceability during rescheduling, facilitating exception troubleshooting |
| Image upload domain configuration | Set based on actual measurements | Adapts to image storage requirements for internal enterprise domains, replacing the default IP plus port format |
| Workflow trigger condition | Triggered by order placement or exception changes | Matches the real-time update cycle of this category, avoiding unnecessary runs |
Three common mistakes
- Phenomenon: Interface lag or delayed drag-and-drop operations occur after selecting
variablesin the workflow, and normal function is restored after deleting the corresponding variable group. Cause:variablesare not split by business type, leading to a single group carrying too many fields and excessive parsing load. - Phenomenon: After configuring the image upload function, the generated image links use the IP plus port format and cannot be replaced with the enterprise's own domain. Cause: No custom domain is filled in the image upload configuration item, and the system's built-in address is called by default.
- Phenomenon: Workflow runtime errors include format exceptions for fields prefixed with
$schema. Cause: Input field formats are not verified during thenodeIdbinding step, leading to invalid fields being included in the workflow.
How to confirm the configuration is complete
- Import one typical sales order and work order document, trigger the workflow to run, and check if
variablesare split by type and the corresponding fields are passed correctly. - Upload one test image, and check if the generated link matches the enterprise's pre-configured own domain.
- Simulate one exception change such as delivery date adjustment, trigger workflow rescheduling, and check if the node state bound by
nodeIdis traceable. - Run the workflow to the timeout threshold node, and check if the retry mechanism is triggered and the workflow runs normally after recovery.
The values provided are common starting points and should be measured against the reader's own samples.