HTTP Import mandatory field changes - can't save my import!

Apparently a recent update has made the "Path to error field in HTTP response body" and "Path to success field in HTTP response body" mandatory - they didn't use to be. I can't update an Import because the API I'm calling returns true or false in the body; there is no path to provide.

Is there a special path value I can use that will work? This is a urgent change in production to fix an issue and there isn't time to experiment and test various guesses at what the syntax would be.

Celigo, when did the fields become mandatory? I didn't notice anything in the release notes about this.

0

Comments

9 comments
Date Votes
  • Can you share a screenshot? i.e. I just checked, and I am not seeing these fields as required in my account.

    0
  • My colleague David had a great idea to change the response media type to text and that avoids the required path fields. The side effect is the response is parsed by IIO has plain text so you get _json.raw as a response. This also isn't a big deal, just a result mapping change.

    But all of this shouldn't have been necessary and I'm hoping the change to make this mandatory will be reverted.

    0
  • The reason the fields are mandatory is because you are setting "Error values" and "Success value". These fields are dependent on the fields above them being set. If you unset these fields, then the other fields will no longer be required. Hope this helps.

    0
  • I appreciate the response, but I think you may have missed my point.

    The API I'm calling returns HTTP 200 regardless, the body of the response contains a boolean value indicating the success or failure of the request. This was working for the past year, but at some point Celigo made the path fields mandatory which breaks the solution.

    If an API returns true or false in a response, why is a path mandatory? It shouldn't be, an empty path (or $ if you want to support JSONpath) should be allowed. This did work as I'm describing, something changed.

    0
  • I def missed that point. Let me ask some questions to better understand this.

    Can you share the full HTTP response so we can see what it looks like? I am curious if we are getting back a JSON payload or just a simple string. If you cannot share the HTTP response, then are you saying that the HTTP response body is simply the raw text "true" and nothing else? i.e. no fields, no JSON, etc...? If the API returns a simple JSON structure like this: { "success": true } then you would set the "path to success field ..." to "success", and "success value" to "true", and then you dont even need to the path to error field always.

    0
  • The full response is simply 

    true

    for a successful request and 

    false

    for unsuccessful. I didn't create the API ;0)

    No fields, no object - it IS technically valid JSON to return a boolean, number or double-quoted string, just uncommon.

    1
  • You just taught me something new! I did not know this was valid JSON, and I was going to say that changing the expected response media to plain text is the correct solution, but now that is not accurate. I will pass this along to the team to see when/why we changed these validations, and hopefully get it reverted.

    0
  • Thanks Scott. Fingers crossed it's an easy thing to revert.

    In case you meet any resistance:

    A JSON text is a sequence of tokens.  The set of tokens includes six structural characters, strings, numbers, and three literal names.

    A JSON text is a serialized value.  Note that certain previous specifications of JSON constrained a JSON text to be an object or an array.

    That goes back to at least 2014, RFC 7159

    0
  • Hi Steve Klett,

    Thank you for your patience while we worked on finding a workaround to help unblock you.

    We plan to address this in the next release, but we’d like to gather a few more details from you and also provide a potential workaround in the meantime to see if it resolves your issue.

    Could you please try the changes as mentioned in the image below and let us know if you were able to successfully process this?

    Additionally, please share the flow details (id) to product_feedback@celigo.com 

    Best Regards,

    0

Please sign in to leave a comment.

 

Didn't find what you were looking for?

New post