Azure-docs: Handling Bad Requests

[rriley99]

Are there any recommended best practices for handling different results for the Rest API calls? Such as an expired token or a malformed request etc.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c9da1816-3f64-bd45-443f-5bdb48bacc24
• Version Independent ID: e649f787-62da-fc97-2e9a-ba89765beed4
• Content: Copy data from a REST source by using Azure Data Factory - Azure Data Factory
• Content Source: articles/data-factory/connector-rest.md
• Service: data-factory
• GitHub Login: @linda33wj
• Microsoft Alias: jingwang

[MartinJaffer-MSFT]

Thank you for your detailed feedback. We are looking into the issue, and we will respond when we have more information.

[MartinJaffer-MSFT]

@rriley99 I do not have _best practices_ for you at this time, but I have done some work to get you started.

Starting assumptions: This is in regards to failure of copy activity using REST dataset, not web activity. You want to differentiate and perform logic on the various http status codes.

The expired token and malformed request are outcomes we can assume will cause the copy activity to fail. If we want to do anything more, our next activity should have a red 'on-failure' dependency.

1. Create a Set Variable activity connected to the copy activity by a red 'on-failure' dependency. Also create a string type variable.

The activity has 3 properties we can use to get more information. Not all are immediately useful for our purpose.

• @activity('Copy data1').output.errors[0].message
• @{activity('Copy data1').Error}
• @{activity('Copy data1').StatusCode}

@activity('Copy data1').output.errors[0].message is the section which appears in the output when there is a failure. If the activity succeeds without error this property does not exist, so it should not be used outside of 'on-failure' dependencies. It is more readable, but may have less info.

@{activity('Copy data1').Error} is the section displayed when you click the 'error' icon in debug runs. If the activity succeeds without error, the value of this property is null. While this section has more attributes, the part we care about is functionally the same as above.

@{activity('Copy data1').StatusCode} is more about the activity itself, and does not map the http status code we are looking for. When the activity succeeds (generally with the rest returning a code of 200+) this has a value of exactly 200. When the activity fails (generally because the rest returned a code of 400+) this has a value of exactly 400. Do not use this property.

1. In the Set Variable activity, use the following expression to extract the status code from the error message:
   @substring(activity('Copy data1').output.errors[0].message,lastindexof(activity('Copy data1').output.errors[0].message,'HttpStatusCode '),18)
   This will return a value like "HttpStatusCode 403"

Now that we have a way to get the status codes, we need to branch our control flow.

1. Create a Switch activity connected to the Set Variable activity be a green 'on-success' dependency.
   In the switch activity expression, reference the variable.
   Create cases for each status code you want to handle. Name their case like httpstatuscode 403,httpstatuscode 404 , etc.

Now all that is left, is to place your handling logic inside.

[rriley99]

Thank you. I understand what you're saying. I will have to wait a few days before I can change the activities in the pipeline, so you may close this and I will comment if something doesn't add up/

[MartinJaffer-MSFT]

Thank you for letting me know @rriley99 . Have a good week!