Skip to main content

Please add here what is actually sent to an API provider. I have been struggling with the web connector and it's great to see all the variables but apparently a lot of things get done which resulted in a body request json that wasn't parsable. With trial and error I figured it out, but would be more easy to see what the platform actually sends to the provider. 

@Freddy Your idea might be solved with the solution that will be released with 2024.3 Release next week as a result of this Idea: 

Please have a look into the Release Notes and the functionality (once available) and let us know if that is sufficient.


@Freddy Your idea might be solved with the solution that will be released with 2024.3 Release next week as a result of this Idea: 

Please have a look into the Release Notes and the functionality (once available) and let us know if that is sufficient.

@Arie V Nope, because the problem remains after I installed 2024.3. There is no way to see what the platform makes of the request. I only see my variables and the result that the request_body has an error. As I don't see what is actually being sent to in this  case Klippa ..  there is no remedy.  If I generate it manually and put it in insomnia for example it works.. just in TW it doesn't . 

I'm really getting frustrated with the web connector and flows in general. It feels so fragile, with a lot of unhelpful logging information..    

 

 


It's probably hard, but it would be awesome to get to the user-friendliness level of the flow builder  of this tool I experienced with: N8N. 

I create workflows in minutes that in TW would cause days, due to a couple of facts:

  • step by step testing. This allows to see if the code / variables you use actually are filled the way you expect
  • You can create and test imediately without the need to finalize the complete process. 
  • When you test you can see in the flow what step it is, and whether the glow was successfully finished or with error. Of course, when an error occurred, you see very clearly what went wrong

Compared to Thinkwise, editing the code is many clicks separated from the flow. This make some loose a lot of time.

But the worst is the debugging. Often you just do not get any feedback about what happened (often something very small). You might have forgotten to fill the variables, link the nodes or a small error in the code and things don't give the result you expect, but there is no feedback from Thinkwise. 

If you connect with external api, you do not see the body of the call that was sent, for example. 

 

Making the code closer to the node and being able to debug (even when no error occurs, just seeing what happens) would help a lot. 

At


Hello @Freddy,

I agree that  debugging web connections is currently challenging due to the lack of insight into the actual request that was sent. We have already started working on incorporating this information in the process flow monitor and I hope to make this available in the November 18 release.

And @tiago, thank you for your input as well. We will look into ways to further improve the debugging experience. In particular, I think that methods to allow testing/give feedback at an earlier stage is one of the better ways to boost productivity.


NewOpen