What the data for this category looks like
Multi-app routing data is sourced from business sub-app metadata created within the platform, real-time traffic request logs, and preset routing rules. Data updates take effect in real time when routing rules are modified or traffic allocation is adjusted. Traffic statistics are refreshed at the minute level. The structure of a single routing data document includes fields such as route unique identifier, associated sub-app ID list, trigger match condition, traffic weight proportion, and standby application configuration. All field types use standard JSON format. traffic_weight is an integer percentage value. trigger_condition is a string-formatted match rule. update_time uses ISO 8601 time format.
Constraints imposed by these characteristics on the "model access and configuration" link
The feature of associating multiple sub-apps requires the model access layer to support batch configuration of model keys, call addresses and other parameters for different sub-apps. This avoids permission conflicts caused by global unified configuration. Binding of traffic weights and standby rules requires the model access layer to dynamically schedule model call requests based on preset traffic allocation ratios. It must also configure timeout thresholds and trigger logic to automatically switch to standby configurations when a single sub-app’s model encounters an exception. Dynamic updates to trigger match conditions require the model access layer to support real-time loading of routing rules, without requiring a service restart to take effect. Additionally, multi-app context isolation requires the model access layer to maintain session contexts separately for each sub-app, to avoid data crossover.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
multi_app_batch_model_config | Enabled | Supports separate configuration of model keys, call addresses and parameters for each associated sub-app, adapting to differentiated requirements in multi-routing scenarios |
model_fallback_trigger_threshold | 30 seconds | Meets the traffic scheduling delay requirements for multi-app routing, avoiding single model timeouts from impacting the overall request link |
traffic_weight_concurrent_limit | 80-300 concurrent | Calibrated based on sub-app model call costs and server resource limits, avoiding traffic overload |
route_trigger_match_rule | Match by request path prefix | Aligns with the business division logic of multi-app routing, quickly distinguishing requests from different business sub-apps |
app_session_isolation | Enabled | Ensures session contexts between multiple apps do not interfere with each other, avoiding data crossover that affects call results |
The parameter values provided on this page are general recommendations that serve as a starting point for configuration. Actual values are affected by data form, data volume and business rules. Specific issues require targeted analysis. It is recommended to test on your own samples before finalizing settings.
Three common mistakes
- Phenomenon: Model calls return a timeout, and logs show the
request_timeoutstatus code. Cause: No reasonable timeout threshold is configured for multi-app routing traffic scheduling, causing single model call delays to exceed the tolerance range of the overall request link. - Phenomenon: Workflow run results cannot be passed to model calls, and the interface prompts an
ai_input_is_efield exception. Cause: The workflow variable injection switch is not enabled in the multi-app routing model access configuration, causing run results to not be correctly mounted to model request parameters. - Phenomenon: Locally deployed Ollama models cannot be accessed normally, and calls return a connection failure. Cause: Correct local service address and port are not filled in the model access configuration, and allowed access source rules are not configured.
How to confirm the configuration is complete
- Enter the multi-app routing management interface, verify the model keys, call addresses and other configuration items for each associated sub-app, ensuring they match the actual deployment status of the sub-apps.
- Construct test requests that comply with routing trigger rules, check whether the platform logs correctly match the target sub-app and load the corresponding model parameters to initiate calls.
- Simulate model call timeout or exception scenarios, verify whether the system triggers the standby app according to preset rules and completes request fallback.
- Submit test requests containing workflow run results, confirm that the model request parameters correctly include workflow output content, with no missing fields or abnormal errors.
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.