2016-07-23 3 views
0

Я использую до тех пор, пока не удастся повторить вызов веб-службы только тогда, когда она не работает.
Ниже то, что я пробовал:Mule 3.7 до успешного failExpression не работает

<until-successful maxRetries="10" failureExpression="#[(message.inboundProperties['http.status'] != 200) &amp;&amp; (message.inboundProperties['http.status'] != 500)]" synchronous="true" millisBetweenRetries="5000"> 

<flow-ref name="callSubFlow" doc:name="Flow Reference"/> 

Если я получаю ответ HTTP 500 Я также не хочу, чтобы повторить попытку вызова веб-службы. Я издевался над веб-сервисом, и когда он возвращает ответ HTTP 500, пока он не удастся повторить вызов веб-службы. Что случилось с выводом Expression выше?

Thanks

ответ

0

Вот как исправлена ​​моя проблема. Я создал другой поток, который ловит только ошибку Web Service 500. До тех пор, пока не будет успешным, он не повторит попытку снова вызвать веб-службу.

<until-successful maxRetries="${webservice.timeout.max.retries}" failureExpression="#[exception != null &amp;&amp; (exception.causedBy(java.net.ConnectException) || exception.causedBy(java.net.SocketTimeoutException) || exception.causedBy(java.util.concurrent.TimeoutException) || exception.causedBy(java.net.SocketException))]" 
synchronous="true" millisBetweenRetries="5000" > 
<processor-chain doc:name="Processor Chain"> 


     <set-payload value="#[payLoad]" /> 
     <flow-ref name="Flow1" /> 

    </processor-chain> 
</until-successful> 

<flow name="Flow1"> 
<ws:consumer config-ref="WSConsumerConfig" operation="execute" /> 
    <choice-exception-strategy doc:name="Choice Exception Strategy"> 


     <catch-exception-strategy doc:name="Catch Exception Strategy" when="#[exception != null &amp;&amp; exception.causedBy(org.mule.module.ws.consumer.SoapFaultException)]"> 

     <logger message="SoapFaultException occurred." level="INFO" doc:name="Logger"/> 
     <set-payload value="#[exception]" doc:name="Set Payload"></set-payload> 
    </catch-exception-strategy> 

    </choice-exception-strategy> 
</flow> 
1

Существует много путаницы вокруг этого выражения. Согласно документации,

НЕИСПРАВНОСТЬ: «Процессор сообщений в пределах до успешного диапазона генерирует исключение или содержит полезную нагрузку на исключение. Кроме того, если выражение представлено в выражении failExpression и оно принимает значение true».

https://docs.mulesoft.com/mule-user-guide/v/3.6/until-successful-scope#success-and-failure

Подвох в том, что при текущей реализации мул «failureExpression» проверяется и используется когда исключение не брошено. В противном случае он всегда повторяет попытку в случае исключения. Решение вашей проблемы состояло бы в том, чтобы иметь блокирующий блок для конкретного исключения, а затем установить свойство, при вызове failExpression это свойство повторяет попытку до тех пор, пока не будет успешным. В принципе, вы бы использовали метод рекурсии, тип кода для повторной попытки.

Пример кода:

<until-successful maxRetries="10" failureExpression="#[flowVars['errorInActualOutboundFlow']]" synchronous="true" millisBetweenRetries="5000"> 
    <flow-ref name="callActualOutboundFlow" doc:name="Flow Reference"/> 
</until-successful> 

Actual Исходящий поток:

<flow name="callActualOutboundFlow" processingStrategy="synchronous">   
    <http:request config-ref="HTTP_Request_Configuration" path="/" method="GET" doc:name="HTTP"/> 
    <choice-exception-strategy doc:name="Choice Exception Strategy"> 
     <catch-exception-strategy doc:name="Catch Exception Strategy" when="#[exception.causedBy(java.net.ConnectException)]"> 
      <logger message="#### Until-Successful will retry in this case " level="INFO" doc:name="Logger"/> 
      <set-variable variableName="errorInActualOutboundFlow" value="#[true]" doc:name="Variable"/> 
     </catch-exception-strategy> 
     <catch-exception-strategy doc:name="Catch Exception Strategy"> 
      <set-variable variableName="errorInActualOutboundFlow" value="#[false]" doc:name="Copy_of_Variable"/> 

0

Вы также должны сообщить компоненту запроса HTTP, что 500 сценарий Безотказная в этом случае. Потому что по умолчанию 200 - это сценарий успеха, кроме всего, что нужно упомянуть в «валидаторе успеха-статуса-проверки».

<until-successful maxRetries="5" synchronous="true" doc:name="Until Successful" failureExpression="#[ message.inboundProperties['http.status'] != 200 &amp;&amp; message.inboundProperties['http.status'] != 500  ]" millisBetweenRetries="1000"> 
     <http:request config-ref="HTTP_Request_Configuration" path="test1" method="GET" doc:name="HTTP"> 
      <http:success-status-code-validator values="200,500"/>. 
     </http:request> 
</until-successful> 

Вместо непосредственного использования HTTP здесь веруй вы использовали callSubFlow там, где вы использовали HTTP-запрос, указать в качестве <http:success-status-code-validator values="200,500"/> успеха. Поэтому в этом случае он не повторится, работает, как ожидалось. Если вы хотите обрабатывать 500 в качестве отдельной логики, отличной от 200, вы можете выполнить проверку состояния после http:request, проверив его message.inboundProperties ['http.status'] и может продолжить логику на основе 200 или 500.

Это не сработало в вашем случае, потому что Http-запрос говорит «500» как отказ и до тех пор, пока не упоминается как отказ.

+0

Спасибо за ваш ответ.Например: Мне просто нужно выяснить, где добавить http: success-status-code-validator. Мой http-конфиг: max

Смежные вопросы