cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

How to log the Raw request sent by HTTP Get snap to end point?

ddangler
New Contributor III

I have a HTTP GET snap to send requests to Zendesk API. But sporadically, it fails saying โ€œREST API service endpoint returned error result: status code = 422, reason phrase = Unprocessable Entity, refer to the error_entity field in the error view document for more detailsโ€

I would like to trouble shoot this further and want to log the actual raw request that is sent by REST GET snap to the end point. How do I do this? I looked at the Get snap documentation but didnโ€™t find anything.

Can someone help me on this?

EDIT: I added error view for the HTTP GET snap and logging the output to a file. I am guessing this might give more details when it fails the next time.

9 REPLIES 9

ddangler
New Contributor III

@robin Thanks for the reply.

My situation is that it is failing randomly and I donโ€™t know what is causing it. I want to log each and every request and write to a log file so that when it fails next time, I will be able to look at what was the actual request sent.

These tools are useful when every request or scenario based requests are failing so that we know how to reproduce and catch the request. Thanks again!

kw917
New Contributor II

I know that this hasnโ€™t been reviewed in a few years but I just want to upvote the need for this functionality. Without trying to be too blunt, it is actually a little ridiculous that an enterprise tool like Snaplogic doesnโ€™t have the ability to inspect the HTTP requests that are being generated by, for example, the REST GET Snap.

In my case, I am using the REST GET snap and the native pagination and everything looks like it would be calculating perfectly with the limit + offset and has next. But the output of what Iโ€™m getting back for documents shows a different story.

I need to be able to inspect the HTTP request input through the Snaplogic console. As it stands, I cannot even inspect the requests that are being made in a developer console because they seem to be wrapped/obfuscated.

I would expect that any enterprise product that deals with fetching data via REST would be able to allow the customer to inspect the HTTP request and not just the response. Looking for what the Service URL / URI has become after being dynamically calculated (partially possible), what the HTTP headers were, what the query parameters were, what the payload/body is if a POST request, etc.

What do we need to do to have this feature request re-considered?

Please let me know if I need to elaborate or escalate through our company contacts.

  • Kurt

Hi @kw917

Let me assure you that this feature doesnโ€™t need to be re-considered and is very much on our radar. Everything you mentioned are absolutely valid points.

For our SOAP Execute snap, we offer a debug view which dumps the raw SOAP request. This has been super helpful in debugging SOAP issues. Iโ€™m not sure that we will do exactly this for our REST snaps, but it may be something similar.

https://docs-snaplogic.atlassian.net/wiki/spaces/SD/pages/1437963/SOAP+Execute#SOAPExecute-Usingthed...

What I canโ€™t guarantee is exactly when, but it may be sooner than you think. I donโ€™t think it is necessary to escalate on your end, but you certainly can if you want. Itโ€™s a little embarrassing that youโ€™re replying to a 4 year old thread, but this is actively being discussed!

kw917
New Contributor II

Hi @mbowen - this is so great to hear! I wasnโ€™t even sure if a post this old would be monitored and was planning to reach out via our CSM in a week or two if I didnโ€™t hear back. Appreciate the quick reply and good news.

Much appreciated โ€“ how will we find out about this new feature as it potentially approaches being released?

Thank you,

  • Kurt

@kw917

As soon as this feature becomes a scheduled committed deliverable, it will be more visible. It will certainly be mentioned in our release notes and possibly a blog post here in community. You can ping this thread for status too. I want this feature too! Many do.