What this category of data looks like
Data sources for this category include DCS/APC systems, LIMS laboratory information management systems, tank farm metering systems, crude oil evaluation databases, equipment management systems, and energy management systems. Daily documents cover operating procedures, production plans, material balance reports, distillate export quality reports, interlock ledgers, shift handover records, and change management documents.
Data update frequencies fall into three categories: real-time, shift-based, and daily. Different systems correspond to different fields. For example, DCS-collected process parameters include pressure and temperature units. LIMS-generated quality test data includes qualification judgment standards.
What constraints these characteristics impose on workflow orchestration
The varying update frequencies of multiple data sources require workflow orchestration to support triggering corresponding data pull nodes on real-time, shift-based, and daily cycles.
Mixed input of multiple document types and structured parameters requires orchestration nodes to support preprocessing and field mapping for raw data in different formats.
The process characteristic of multiple units coupled via a material logistics network requires orchestration to chain nodes in material flow order, and reserve branch judgment nodes for process fluctuations.
The high risk level of data association requires orchestration to configure automatic retry and status return links for abnormal nodes. This prevents unqualified data from entering subsequent processes.
How to set configurations
| Configuration Item | Recommended Practice | Rationale |
|---|---|---|
| Custom tool variables | Bind core fields from DCS, LIMS, and tank farm metering systems | Adapt to parameter call requirements for multiple data sources |
| Number of parallel nodes per run | Use the first 3 core data source nodes | Avoid parallel requests exceeding system carrying limits |
| HTTP request timeout period | 600 seconds | Adapt to the pull delay of real-time data from refining systems |
| Node flow trigger condition | Trigger based on the verification results of upstream nodes | Ensure only qualified data enters the next process |
variables reference scope | Only call defined variables within the current workflow | Avoid parameter conflicts across workflows |
| Node ID configuration | Bind the exclusive nodeId of the corresponding unit | Accurately locate process nodes for each unit |
Three common errors
- Symptom: The output of the HTTP request node does not appear in conversation results, for FastGPT v4.17.0. Cause: The output variable of the HTTP node is not bound to the workflow's
variablesparameter, so the result is not included in the final output link. - Symptom: Custom tool variables cannot normally call data source fields after configuration. Cause: The variable trigger timing does not match the data source's update cycle. For example, configure a real-time data variable to trigger daily.
- Symptom: Node flow abnormalities occur after workflow orchestration, with a status code showing timeout. Cause: The HTTP request timeout period is not adjusted according to the actual delay of the refining system. The default timeout duration is insufficient to cover the delay of DCS data pulling.
How to confirm the configuration is complete
- Trigger a test workflow, and check whether the output fields of each data source node match the preset custom tool variables.
- Simulate a process fluctuation scenario, and verify whether the branch judgment node can correctly trigger the exception handling process.
- View the workflow running logs, and confirm that the HTTP request node's timeout period meets actual pulling requirements.
- Check the node ID configuration, and ensure that the process nodes of each unit are bound to the exclusive
nodeId.
The values provided here are common starting points, and should be evaluated against the reader's own samples.