-
Notifications
You must be signed in to change notification settings - Fork 203
API Provider Data Type Mismatch #3807
Comments
@gaughan this is due to the fact that the start step has the shape of the request and the end step has the shape of the response. They might differ, and this is quite common. On this particular case we have a difference due to the same reason behind #3788. The response, or the input shape of the end step, is not wrapped in our standard wrapper for APIs that looks something like: {
"parameters": {},
"body": {}
} So with #3788 fixed I hope this particular case will not have a mapping difference. Are you concerned about this case (Create new Task operation) that happens to have the same request/response defined in the OpenAPI specification, or are you concerned that the users might end up with data type mismatch warnings in general with API provider-based integrations? |
The reason of the mismatch is now more obvious: Reason being that there is an extra 'parameters' section on the Target. So the question now becomes:
|
We can totally drop those, I was on the verge of dropping them but I used the fact that they were there. Could be done better... |
@zregvart ok so we go for option 4 and drop them from the Target side? |
@KurtStam side question, is that icon your own local environment or did we update the atlasmap icon? |
Yeah, I'd drop them they really have no use and it was silly of me to add them: the status is set on the end step and the Content-Type is determined via the OpenAPI specification. Wasn't very lean of me... Anyhow now that I've thought of a better way to determine if the data shape is unified or not (via the Syndesis unified JSON schema URN) those are no longer needed. |
cc @syndesisqe Can this be verified? |
@asmigala can you please provide feedback to eng? |
@asmigala I think the |
@zregvart right, but is that the expected behaviour? The orange triangle should advise the user that the route in the current state will not return any data unless they do something about it (i.e. add a data mapper). Now I will concede that returning an empty array would be ok here, but what happens in reality is that the response is completely empty. |
I'd say that for any data shape mismatch the user should be warned. That is no data shape is not matched by some data shape. In this specific case perhaps we need a void datashape on the start (the WDYT @gaughan? |
@zregvart I agree, we want to give as much help to enable the user to successfully deploy. |
What is the status of this issue? Are the concerns mentioned in my comment above going to be addressed, or should I close as is and open a new issue for those concerns? |
My 2c is that we should create a new issue(s) for refinements. Skimming through seems that we have just one case that we should handle better; the one outlined in #3807 (comment). |
@zregvart I think we should keep this in mind with other API provider enhancements, a more seamless UX is ideal |
@zregvart I think this is still the same issue ("When you provider Todo App swagger to API Provider a data type mismatch occurs on unimplemented flows" as in the original report). I am ok with closing this and opening a new issue, as this in particular is fairly minor issue, but I think it sets a dangerous precedent on what it means an issue is "fixed". |
@asmigala I'll move it to backlog so your last point in #3807 (comment) gets addressed. |
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions! |
Migrated to https://issues.jboss.org/browse/ENTESB-11568 |
For cases where action's descriptor has data shape of type 'none' we would assert that the data shape does not exist. This would cause us not to recommend adding a mapping step between a input step with data shape of 'none' and a step containing a data shape other than 'none'. In that case we do wish to suggest adding a mapping step as mapper can operate without inputs, i.e. it can add constant values and map those to the output. Fixes syndesisio#3807 Ref https://issues.redhat.com/browse/ENTESB-11568
For cases where action's descriptor has data shape of type 'none' we would assert that the data shape does not exist. This would cause us not to recommend adding a mapping step between a input step with data shape of 'none' and a step containing a data shape other than 'none'. In that case we do wish to suggest adding a mapping step as mapper can operate without inputs, i.e. it can add constant values and map those to the output. Fixes syndesisio#3807 Ref https://issues.redhat.com/browse/ENTESB-11568 (cherry picked from commit bd11698)
See also https://issues.jboss.org/browse/ENTESB-11568
This is a...
Description
When you provider Todo App swagger to API Provider a data type mismatch occurs on unimplemented flows:
The text was updated successfully, but these errors were encountered: