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.