目前我们在WSO2 ESB中使用存储转发模式。因此,当消息进入代理时,我们使用序列将其移动到存储(队列)中,然后让消息处理器处理排队的消息并将它们发送到我们的REST API,即异步处理消息。但是,当REST API抛出400,404,409或422时,处理器停止(50X错误相同)。我们希望将4XX状态代码的这些失败消息移动到可以诊断和处理的单独队列中。这意味着如果有一条错误消息,它不会停止正在处理的剩余排队消息。我们只想为4XX故障做这件事。 5XX或网络问题/超时应继续停止处理器。我查看了死信频道(https://docs.wso2.com/display/IntegrationPatterns/Dead+Letter+Channel),但这似乎只与Proxy(同步请求)兼容。因此,我试图使用故障序列将消息移动到另一个队列,但故障序列似乎只适用于SOAP故障。是否有可能使它与REST API状态代码错误一起使用? https://docs.wso2.com/display/ESB481/Error+Handling
我注意到可以添加状态代码,但这似乎只对减少重试尝试很有用。提前谢谢。
关注
我尝试按照@ Jean-Michel的建议触发我的REST API的故障序列,但故障序列仍然没有运行。通过这些步骤亲自尝试。
第1步:添加代理
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="TestProxy"
transports="https,http"
statistics="disable"
trace="disable"
startOnLoad="true">
<target faultSequence="DeadLetterQueueSequence">
<inSequence>
<log level="custom" category="ERROR">
<property name="TEST" value="Proxy was hit"/>
</log>
</inSequence>
<endpoint>
<address uri="http://localhost:8080/sampleService/failEndpoint400"/>
</endpoint>
</target>
<description/>
</proxy>
步骤2:添加死信序列:
<sequence xmlns="http://ws.apache.org/ns/synapse" name="DeadLetterQueueSequence" trace="disable">
<log level="full" category="ERROR">
<property name="Test" value="DeadLetterQueueSequence was hit"></property>
</log>
</sequence>
第一个日志条目出现但从不出现第二个(来自DeadLetter序列)。
似乎WSO2 ESB不具备REST友好性,只适用于SOAP服务。
答案 0 :(得分:0)
在Message Processor conf(forwardnig)中,不是将消息从商店直接发送到REST API,而是将它们发送到ESB内部的代理服务,在它的outSequence中,您可以测试状态代码,响应的内容等最终决定将消息移动到另一个商店。
在此outSequence中,您可以选择使用状态代码
来回复您的消息处理器答案 1 :(得分:0)
您可以使用消息处理器的参数“Non retry http status codes”来防止它进入停用状态。然后在回复序列中,您可以通过将失败的消息发送到死信队列或任何您想要的方式来处理失败的消息。
<messageProcessor name="SampleProcessor" class="org.apache.synapse.message.processor.impl.forwarder.ScheduledMessageForwardingProcessor" targetEndpoint="stockEP" messageStore="SampleStore" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="interval">1000</parameter>
<parameter name="client.retry.interval">1000</parameter>
<parameter name="message.processor.reply.sequence">replySeq</parameter>
<parameter name="message.processor.fault.sequence">faultSeq</parameter>
<parameter name="is.active">true</parameter>
<parameter name="non.retry.status.codes">500</parameter>
</messageProcessor>