WSO2 EI 6.4.0 基于本地API端点的消息重试机制调用失败问题

端点测试报错的本质原因 #

你碰到的Test按钮自动拼接?wsdl后缀、发起GET请求的行为，是WSO2 EI控制台针对SOAP类端点的默认连通性探测逻辑，本身不代表你的端点配置存在错误，也完全不会影响后续Scheduled Message Forwarding Processor（SMFP）的实际转发行为：

• 可以直接跳过Test按钮的探测报错，只要端点配置的URI、超时规则、认证参数和你用Postman测试的配置完全一致，就可以被转发处理器正常识别
• 如果想消除Test按钮的探测干扰，可以在端点URI后手动追加一个固定的无副作用请求参数，比如https://your-target-api-path?probe=ignore，此时控制台拼接的?wsdl会变为?probe=ignore&wsdl，不会造成接口连通性误报

核心问题解决：让SMFP支持POST方法调用目标接口 #

你遇到的SMFP默认发起GET调用、不支持POST重试的问题，本质是6.4.0版本默认的转发逻辑丢失了原始POST请求的上下文，同时开启了默认的WSDL探测规则，按以下步骤调整即可：

• 修正失败消息的入存逻辑
  • 不要手动构造空消息存入内存消息存储，必须在API调用失败的错误流中，直接用Store Mediator将当前完整的请求上下文（包含HTTP方法、请求头、请求体）原样存入你搭建的消息存储
  • 入存配置中必须开启preserveHeaders、preservePayload属性，避免后续转发时丢失原始POST请求的上下文信息

  注意：如果入存前对原始POST请求体做了格式转换、属性覆盖，会导致转发处理器无法识别原始请求方法，最终走默认的GET探测逻辑

• 显式指定端点的HTTP方法规则
  6.4.0版本的UI端点配置默认不暴露HTTP方法的强制设置入口，需要直接修改synapse目录下的端点配置，显式绑定POST方法：

  <endpoint name="TargetPostApiEndpoint">
    <address uri="https://your-target-api-full-path">
      <!-- 配置错误码触发重试的规则，覆盖400、500等可重试错误 -->
      <suspendOnFailure>
        <errorCodes>400,404,500,503</errorCodes>
        <initialDuration>1000</initialDuration>
        <progressionFactor>2.0</progressionFactor>
      </suspendOnFailure>
    </address>
  </endpoint>
  

• 关闭SMFP的默认WSDL探测逻辑
  6.4.0版本UI创建的SMFP没有暴露探测开关，需要直接编辑SMFP的配置文件，关闭WSDL探测、显式绑定对应的消息存储和端点：

  <scheduledMessageForwardingProcessor name="PostApiRetryProcessor">
    <targetEndpoint>TargetPostApiEndpoint</targetEndpoint>
    <messageStore>InMemoryMessageStoreForPostRetry</messageStore>
    <!-- 每30秒轮询一次消息存储 -->
    <processorInterval>30000</processorInterval>
    <!-- 单条消息最多重试5次 -->
    <maxDeliveryAttempts>5</maxDeliveryAttempts>
    <!-- 强制关闭WSDL探测，避免自动拼接?wsdl后缀 -->
    <wsdl1Service>false</wsdl1Service>
    <wsdl2Service>false</wsdl2Service>
  </scheduledMessageForwardingProcessor>
  

版本专属注意事项 #

• 6.4.0版本所有涉及SMFP的核心规则调整，不要依赖控制台UI操作完成：UI生成的默认配置会保留WSDL探测逻辑、不支持显式指定HTTP方法，必须直接修改synapse配置文件，部署后通过控制台校验配置是否加载成功
• 入存到消息存储的消息不要做额外的格式转换：如果在错误流中加入了payloadFactory、property等会改写请求上下文的中介器，会导致转发时丢失原始POST的方法和请求体
• 验证配置有效性的正确方式：不要依赖控制台的Test按钮做连通性校验，直接触发一次目标API的POST调用，人为制造可重试错误（比如临时中断目标API服务），观察消息存储的入存情况，待轮询周期结束后查看目标API的访问日志，确认收到的是携带完整请求体的POST调用，而非GET探测请求。

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