Skip to main content

This may have a very simple solution. I have a workflow that runs a component with a Json Call that does an API call. If the API call succeeds the data is stored in a database table. No problem. But what to do if it fails?

 

In the Json Call I've created a Response Code Column called jsoncall_response. And if jsoncall_response=200 that means it was successful.

 

But what to do if it is not successful? I can use a text writer to write that data to file. Actually I would like to see the component and the workflow fail. But there isn't a "Break” or “Fail” step as far as I can see. The closest that I can find is the Stop Reading step.

BTW I've tried Stop Reading, but it seems to ignore my condition.

In the Jscon Call I put in a misformed url and in the debug it clearly gave a HTTP 405 response. That didn't seem to stop it from going further. In the SNOW response output file it even wrote that jsoncall_response was indeed 405.

 

Alternatively I've been thinking about maybe sending notifications from the error flow (though on our site I can't send mail from test and acceptance environments, so that would be harder to test).

What is the best way to approach this?

Hi Marcel.

True/False Conditions in ONE Desktop do not function like if/else conditions do in most other programming languages. Instead of being executed as “if <condition> is true, <do this> else <do that>”, remember that ONE Desktop is primarily a data tool. So it becomes “here is my <condition>. Do <this> with the true rows> and do <that> with the false rows. As a result, even if the API call fails, you will always execute your “API call successful” route and end up writing empty files. Unfortunately there is no way to break/stop execution.

As an aside, I’d also recommend doing a quick test by using the right click → debug functionality to manually walk through each step. You can then verify that a 2xx code gets correctly filtered in your logical check by copy/pasting the response from the JSON call into the “API call successful” step.

Best of luck!
 

Oliver

Hi Marcel-Jan

As Oliver says, the success status of a component in a workflow step isn’t dependant on the result of the data processing.

Your best approach may be to use a “Read SQL Result” step in your workflow to check the results in your database directly after the component has run. You could run a count(*) selecting for an update timestamp, for example, and check the result in the connector condition afterwards.

If you need an example for setting up the parameters of the SQL query and the Link properties, take a look at the workflow tutorial 07_01_Variables_in_SQL_Context.ewf

The advantage of this approach is that you can capture any data state that interests you, not just something that is defined as an “error” condition.

The workflow would look something like this:
 


Hope that helps
Phil

Thanks for the clarification.

This is kind of disappointing though. That means I have to jump from my workflow in and out of components to immediately check their work afterwards in the workflow before I can go on. I've got some rebuilding to do.

Hi @Marcel-Jan thank you for sharing your feedback, if you’d like you can create an idea post here. 

Thanks @Cansu . In the meanwhile I have completely changed my approach. I no longer use a workflow with a SQL iterator, but I have created a simple workflow that runs a component that reads all the DQ issues and sends them to the appropriate tasks.

In the workflow I can later check if any API call resulted in response calls other than 200. But that actually wasn't part of the goals this sprint yet.

 

Reply


Community Terms of Use & ConditionsCookie settings