对Subflows调用Scatter Gather时如何保持执行顺序？

你遇到的顺序不稳定问题是因为Scatter-Gather并行执行子流时，子流完成时间不固定，如果你直接把所有返回报文拼接而没有区分路由归属，就会出现Status顺序随机的问题，可通过以下三种方案解决：

方案1：按路由索引取数（业务逻辑适配首选） #

Scatter-Gather的聚合结果天生和你配置的子流路由顺序一一对应，和子流执行完成的先后顺序无关：

• 你配置的第一个子流的响应，永远对应聚合结果列表的第1个元素（索引为0）
• 你配置的第二个子流的响应，永远对应聚合结果列表的第2个元素（索引为1）

你只需要按索引分别取出两个子流的响应，再做后续处理或拼接，就能完全保证顺序符合预期，不需要修改子流本身的逻辑。你场景里的两个子流返回的Status分别为：

<!-- 第一个子流返回的Status -->
<Status>
    <StatusCode>-1000</StatusCode>
    <Severity>Error</Severity>
    <StatusDesc>ERROR</StatusDesc>
</Status>

<!-- 第二个子流返回的Status -->
<Status>
    <StatusCode>0</StatusCode>
    <Severity>Info</Severity>
    <StatusDesc>INFO</StatusDesc>
</Status>

按索引取值后再拼接，就不会出现顺序随机的问题。

方案2：给子流返回结果加排序标识 #

如果业务逻辑要求必须先合并所有子流响应再统一处理，可以给每个子流的返回新增自定义排序字段：

• 第一个子流返回的报文中新增<FlowOrder>1</FlowOrder>，和Status节点同级
• 第二个子流返回的报文中新增<FlowOrder>2</FlowOrder>，和Status节点同级

聚合后按FlowOrder字段对Status节点做升序排序，即可固定最终输出的顺序。

方案3：优化JUnit断言逻辑（单元测试场景首选） #

单元测试的核心目标是验证功能正确性，而非并行执行的顺序，你可以把原本依赖报文顺序的断言，调整为不校验顺序的断言：
比如改用XPath断言替换整段报文模糊匹配：

• 断言存在//Status[StatusCode='-1000' and Severity='Error' and StatusDesc='ERROR']
• 断言存在//Status[StatusCode='0' and Severity='Info' and StatusDesc='INFO']

这种写法不需要调整任何业务逻辑，就能彻底解决用例偶发失败的问题。

内容的提问来源于stack exchange，提问作者Harish