Conditional flow fails with collections in API Provider

This is a…

[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Documentation issue or request

Description

Conditional flows cannot be used with collections in Syndesis, but API Provider makes a collection around its request body, even when it is specified in the API specification to contain only one object of specified type. Example: conditional-provider.zip In this integration you can see that in the specification in the POST method it expects request body of Task. I’d expect that to be one Task. So if I create a condition ${body.completed} it should work, or at least ${body["completed"]}. I tried also splitting it, but split doesn’t work well on these types of collections (see #4862). Also I tried ${body[0]["completed"]} but that also didn’t work for some reason. The log reported something along the lines of cannot call method [0]["completed"] on ArrayList.

[zregvart]

With most HTTP-related functionality (custom API connectors, API provider, webhook) we use something that we call “unified” data shape, this is the shape that we try to standardize on so we can easily both use it in the mapping step and have a common data format when using different HTTP-related functionality in the same flow/integration. The origins of this shape are from the inability to specify multiple data shapes for one step, in this case we need two one for HTTP headers (parameters) and one for the HTTP body, so therefore we create a new data shape that contains both.

This shape has a specific JSON schema defining it which is auto-generated (custom API connectors, API provider) or provided by the user (webhook).

The fact that there’s a body property in the body of the Camel message is because of this. This also reflects in the use of mapper, filter steps or here in the conditional flows.

We have made provisions in split/aggregate for this specific data shape in order for the experience to be better for the end user. I think there are some improvements for conditional flows planned for next release.

In the long term I would look to support defining the data shape(s) differently, this is a limitation we have with the mapper and the way it can only express the shape of the Camel message body and needs to be addressed there first.

[mmuzikar]

@christophd Yes you are right, that works. It is certainly not the most obvious solution though. If this is the intended solution, it should be at least documented somewhere (@TovaCohen can you elaborate if it is already documented, or add a mention of that in the documentation?). But this is a thing you don’t really expect that you have to read documentation for, maybe a little mention in the UI where there is the “Provide a condition that you want to evaluate (for example, ${in.header.type} == 'note' or ${in.body.title} contains 'Important').” Or in a perfect world if the datatype is a JSON schema there could be a note added or something. (cc @syndesisio/uxd )