Catching HTTP Errors from BPMN Tasks containing Send HTTP Request Actions

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • sekjal
    Junior Member
    • Jun 2021
    • 4

    Catching HTTP Errors from BPMN Tasks containing Send HTTP Request Actions

    Is it possible to tell whether a Task that executed a Send HTTP Request action completed successfully or with errors, and then follow a different workflow path based on that? I've tried putting the Task in a Sub-Process and having a Error Intermediate Event, but it's not working as I expected.

    My end goal is to be able to do regular checking of URL fields in a custom entity
  • yuri
    Member
    • Mar 2014
    • 8453

    #2
    I tested whether Boundary Error is caught when Request return error (code not in a 200..300 range) and it worked.

    Click image for larger version

Name:	error.png
Views:	335
Size:	21.7 KB
ID:	72655
    If you find EspoCRM good, we would greatly appreciate if you could give the project a star on GitHub. We believe our work truly deserves more recognition. Thanks.

    Comment


    • esendino
      esendino commented
      Editing a comment
      And how can be retrieved information on what error it was or any available detail?

    • rabii
      rabii commented
      Editing a comment
      After Boundary error you can still access the like this ($errors = json\retrieve($_lastHttpResponseBody, 'errors')) and you can check the error. Or you can add multiple Boundary Errors on the same task e.g one for error 404 - another on error 401 etc
  • sekjal
    Junior Member
    • Jun 2021
    • 4

    #3
    Thank you so much! I wasn't using the Boundary Event in the right place, but your visual showed me what to do!

    Comment

    • dimyy
      Active Community Member
      • Jun 2018
      • 569

      #4
      Cool if $ _lastHTTPrequestBode is full and on error. 4 * error does not mean no response from external service

      Comment

      • esendino
        Senior Member
        • May 2019
        • 158

        #5
        Hi rabii

        Thanks a lot for your answer, I tried to follow what you mentioned but couldn´t make it work

        You offered two possibilities:

        1.-"you can still access the like this ($errors = json\retrieve($_lastHttpResponseBody, 'errors'))"
        2.- can add multiple Boundary Errors

        I was trying to see how to d what you suggested.

        I have this BPM. That works perfect when the endpoint exists. Now I'm testing what happens if rhe endpoint doesn't exist.

        Click image for larger version

Name:	image.png
Views:	232
Size:	15.9 KB
ID:	99411

        1.- based on _lastHttpResponseBody

        As per documentation _lastHttpResponseBody can be accessed in a following workflow action.

        So In the HTTP Request i have these two actions in the task "HTTP Request"

        Click image for larger version

Name:	image.png
Views:	205
Size:	25.3 KB
ID:	99412

        But the issue is that the second action (blue) is not executed if the first fails

        I tried in the next task "Error Answer" to retrieve _lastHttpResponseBody, both directly and with workflow\lastHttpResponseBody() and neither worked.

        So, I don't know how to implement this 1st suggestion

        2.- Based on multiple Boundary Errors

        The issue here is that I don't know how to include conditions for the different types of errors


        I appreciate very much any light you could provide

        Comment

        • rabii
          Active Community Member
          • Jun 2016
          • 1250

          #6
          Hey,

          Yes as per documentation the second action won't be executed because the first one failed. What you need to do is to remove the second action and just add different Boundary errors depending on what is returned from your api endpoint.
          Rabii
          Web Dev

          Comment

          • rabii
            Active Community Member
            • Jun 2016
            • 1250

            #7
            I suggest that you add multiple Boundary Errors (if you know what errors return from your endpoint api) and then just redirect the flow to next action based on your logic. By the way if you don't know what error is returned you can always check the log under Data/Logs and you will find out which error is returned. Otherwise if you keep a Boundary Error (code) empty then it will catch any errors from the request. See attached screenshot for your reference (i have defined multiple Boundary errors on my flowchart each has a specific code e.g 403 - 404 and it catch the correct code).

            From your pic which error code you defined on your Boundary Error??
            Attached Files
            Rabii
            Web Dev

            Comment

            • esendino
              Senior Member
              • May 2019
              • 158

              #8
              Thanks a lot rabii

              It works perfect!!

              The complete answer from my API is (in this particular case) this

              {
              "code": "woocommerce_rest_invalid_payment_data",
              "message": "No se pudieron establecer las fechas de la suscripcion. Mensaje de error: Suscripcion #44223: La fecha de next_payment debe ocurrir despues de la fecha de inicio.",
              "data": {
              "status": 400
              }
              }​

              espocrm is getting the 400 as the code error

              But how I can get the "code" and "message" information within the BPM?

              Comment


              • rabii
                rabii commented
                Editing a comment
                tbh i am not sire if possible to access the returned response if it failed. you need to double check with the team to see if this is possible.
                Last edited by rabii; 11-06-2023, 08:55 AM.

              • esendino
                esendino commented
                Editing a comment
                Thank you very much

              • rabii
                rabii commented
                Editing a comment
                you are welcome
            Working...