What the data for this category looks like
Power yield data comes primarily from public APIs of provincial power trading centers and structured operational data submitted by grid dispatch teams. Data updates follow a daily T+1 cadence, with full transaction information for the prior trading day released each day. The document structure is a JSON array grouped by trading entities. Core fields include trading entity code, trading period, settlement electricity price, marginal cost, and calculated yield. Settlement electricity price and marginal cost use the unit yuan/megawatt-hour. Calculated yield is a dimensionless value. Data is categorized by generation type, including thermal power, wind power, photovoltaic, and other subtypes, with each subtype containing independent transaction record entries.
Constraints on workflow orchestration
The multi-source, heterogeneous nature of power data requires workflows to include multiple API pull nodes. Each node connects to interfaces of different trading entities, and unifies field naming and units. The daily T+1 update cadence requires workflows to use scheduled trigger rules, to avoid running tasks before data updates. The specialized attributes of fields require workflows to add validation nodes. These nodes filter abnormal settlement electricity price and yield values, preventing invalid data from entering subsequent calculations. Different generation types use distinct calculation logic. Workflows must include branch nodes to split traffic by transaction type, and run different yield accounting rules for each type.
How to Set Configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
Scheduled Trigger Configuration | Trigger daily at 02:00, set retry count to 2 | Power yield daily reports use T+1 data, so execution must run after trading center data updates. The retry mechanism handles temporary interface fluctuations |
Multi-source API Node Mapping Rule | Unify the settlement electricity price fields returned by different interfaces to trade_price, and unify units to yuan/megawatt-hour | Power data comes from multiple trading entity interfaces with inconsistent field naming, so standardization processing is required |
Field Validation Threshold | Filter entries where trade_price is less than 0, set the value range of calculated yield to 0-2 | Power transaction settlement electricity prices cannot be negative, and yields fall within a reasonable range to avoid invalid data entering subsequent processes |
Knowledge Base Associated datasetID | Fill in the datasetID of the corresponding power trading rules knowledge base, reference via the global variable {{dataset_id}}` | Resolves issues with direct global variable references, requires binding variable mapping in node configuration |
Node Output Hide Configuration | Set the output of the data cleaning node to not be publicly displayed | Only retain the output of the final broadcast node, meeting the information simplification requirements of internal workflows |
User-level Variable Scope | Enable the user-level variable switch for the workflow, bind user_id as a scope variable | Configurations of different users must be isolated to avoid global variable conflicts |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by material form, data volume and business rules. Specific issues require specific analysis. It is recommended to test on your own samples before finalizing settings.
Three Common Misconfigurations
- Phenomenon: Knowledge base retrieval node returns empty results, log shows
dataset_idfield not found. Cause: Global variable was not correctly mapped to the node's datasetID configuration item, only set in the global variable panel without binding to a specific node. - Phenomenon: When testing a workflow based on question classification, only the first question triggers the knowledge base reference, subsequent questions return no results. Cause: Context reset rule for the loop trigger node was not set, residual context from previous retrieval blocks subsequent requests.
- Phenomenon: After configuring multiple AI dialogue nodes, the output of one node still appears in the final result. Cause: The
Hide Outputconfiguration item for that node was not enabled, all node outputs are retained by default.
How to Confirm Proper Configuration
- Check the workflow's scheduled trigger logs to confirm execution records exist at the specified daily time, with no interface errors or timeout prompts.
- Manually trigger the workflow, check the output of the field validation node to confirm abnormal data has been filtered, and standardized fields match the expected format.
- Trigger the workflow using different user IDs to confirm user-level variable values are isolated from each other, with no cross-user data sharing.
- Check the output of the final broadcast node to confirm only the required display information is retained, and outputs from hidden nodes do not appear in the results.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.