none
Logic Apps conditional logic, is it flawed? RRS feed

  • Question

  • When I am coding this, I expect the http return to be SOMETHING other than 200 on error condition, as you can see here, it is in fact 400 with our vendors prebuilt in error message that the json doesn't match with expected schema..valid 'error' condition, code = 400, yet...when the return condition is checked - logic apps hiccups? What in the world does the 'runafter' condition for the action http have to do with the condition just doing what is expected next in the flow and checking for return value?

    Am I implementing this incorrectly? This tool is really something of an enigma machine.

    Wednesday, November 8, 2017 7:00 PM

Answers

  • As you See the Condition is Skipped, Since the HTTP Condition did not Satisfy. if you want it to move to next step, Configure the run After Condition for the Failure and Success as well.

    you can do that by clicking on the Right side of the Condition as below

    Click on Configure Run After and check the Options you need.

    For your HTTP Condition to configure retries as well, you can go into Settings Choose retry policy and have a Custom Value.

    Thanks,

    Sujith.


    Sujith

    • Marked as answer by Echo5Tango Wednesday, November 8, 2017 8:57 PM
    Wednesday, November 8, 2017 7:55 PM
  • By default, an action will run after the previous one had succeed. In your case, a non-2xx status code indicate a failed HTTP call, and the HTTP action is marked as so. So condition will be skipped, as the error message suggested, "failed != success".

    So to have a different response base on HTTP action's status code, you should have two response in parallel, without the condition. "Response" will run after HTTP has succeed, which is the default. "Response 2" will run after HTTP has failed, which you can configure in the "Run after" page.


    Wednesday, November 8, 2017 8:02 PM

All replies

  • To make it worse; the retries goes into a loop that appears to be infinite. This tool is really something people use for production systems?

    SO ... have mercy, I tried to do the do 'after' the HTTP condition to keep going after any condition and it is still running. All this was to produce was one message down to our vendor, whom, correctly is rejecting for bad Json. 

    Wednesday, November 8, 2017 7:11 PM
  • As you See the Condition is Skipped, Since the HTTP Condition did not Satisfy. if you want it to move to next step, Configure the run After Condition for the Failure and Success as well.

    you can do that by clicking on the Right side of the Condition as below

    Click on Configure Run After and check the Options you need.

    For your HTTP Condition to configure retries as well, you can go into Settings Choose retry policy and have a Custom Value.

    Thanks,

    Sujith.


    Sujith

    • Marked as answer by Echo5Tango Wednesday, November 8, 2017 8:57 PM
    Wednesday, November 8, 2017 7:55 PM
  • By default, an action will run after the previous one had succeed. In your case, a non-2xx status code indicate a failed HTTP call, and the HTTP action is marked as so. So condition will be skipped, as the error message suggested, "failed != success".

    So to have a different response base on HTTP action's status code, you should have two response in parallel, without the condition. "Response" will run after HTTP has succeed, which is the default. "Response 2" will run after HTTP has failed, which you can configure in the "Run after" page.


    Wednesday, November 8, 2017 8:02 PM
  • I think this answers my question the closest. I was under the impression, if they forced an error condition of any code higher than 200, then an if/else block would be sufficient to capture either the failed condition or success. I think what you are saying, forego the if/else conditional block and just do the run after and provide two different 'flows' - counter intuitive to what traditionally is used for an if/else condition.

    I can try it, but sadly do not see the point for conditional logic then if we hide the logic in these special 'run-after' conditions.

    Thank you.

     
    Wednesday, November 8, 2017 8:52 PM
  • Condition is designed for taking different actions depending on a previous output, where as run-after is designed for exception handling. This matches to how you'd do in programming world: use if() if you need to check a value, and do something; use try-catch if you need to handle an exception.

    Just different construct for different scenarios.

    With that said, there may be time where you want to combine the two, for example:

    If you want to response with a different payload for HTTP 400 and HTTP 500, then you may have a switch-case that runs after HTTP failed, and switch on error code.

    Wednesday, November 8, 2017 9:06 PM
  • Ok, I get what you are saying with the try-catch. The vendor is trying to send back to me 3 codes.

    200 if success

    400 if json message doesn't met one of their internal conditions custom handled error on their end...

    500 if any other error happens

    In my HTTP response, I am getting the 400 status code as EXPECTED, so the condition component does not see it as completed. Therefore, it has to go into a try-catch all situation? Is there any point in using anything other than a 200 code for 'other than' success response? 

    Wednesday, November 8, 2017 9:19 PM