URL = SalesForce URL
Method = Post
Under Data - string = JSON String
Under Header - Authorization = Necessary Token Info
encoding = tried both UTF-8 and also empty
content-type = tried empty and application/json
But when this is sent, on SalesForce side, the JSON String that is posted is being received as a paramater in the URL and not in the body and it is empty in the body and also the content-type is received as application/x-www-form-urlencoded in the URL parameter.
Can you please let me know if there is a way to send this JSON string as body from webMethods so that it can be received in the body on SalesForce side instead of URL param?
That’s really strange, it should work unless the problem is on the salesforce side.
Find attached, the header for Content-Type to double check on your side.
You could try calling a webMethods service and check that the json string is converted to a document that’s visible in the pipeline. If it isn’t perhaps you have a badly formatted json document.
Yes, I believe it’s the issue on SalesForce too. The problem is I am able to see the formatted JSON string in the pipeline and the same is seen on SalesForce side too but in the URL as a parameter instead of body. In the body, SalesForce is seeing it empty from which they are trying to read this JSON string.
SalesForce should read each parameter from the URL to parse that JSON if this is not send as body which is not recommended as it’s not secure to send the data over the URL.
So, I was trying to see why would this JSON string be sent in the URL from pub.client:http and if there is a way to send it as body.
Yes I understand your problem, but what you are doing is perfectly fine, the data should be sent in the body and not in the url.
The only other thing I can think of is to ask, have you made any http calls prior to this in your service ?
I have noticed strange behaviour when using more than one http invoke in a flow. I had to ensure that all input/outputs of the previous http call were dropped before calling the next.
John.
In the screen shot in the first post, I don’t see that the Content-Type header is being set. The screen shot show only the Authorization header being set. Do you have a newer screen shot showing it under headers?
Looking at your pipeline in, it looks like you have already called http prior to this step. Can you try as I said before and drop all of the service in/out vars of the the previous http call and see if that works.
John.
Hi,
Yes I made a prior call to http first to get the tokenID from Salesforce initial URL. That TokenID as authorization along with the JSON String is passed to the second URL to post the JSON. If I delete that, then my second http post would not be authorized by SalesForce.
Hi,
I didn’t ask to delete your token, just all of the input/outputs that were generated by your prior http request. You can keep the token. Just make sure that attributes like url, data, auth, method etc. are no longer in your pipeline prior to this call,
John.
Hi @mm4wm,
If you cannot drop the variables, try adding “newSession=yes” on both your http calls.
Under the covers, http service needs to use a httpcontext from the session and making it to use a new session will avoid reusing the httpcontext from the previous call.
The line that maps data to data and the setting of data/string is a bit odd. Normally, a parent and a child cannot be mapped like that. Map one or the other, not both. Most likely, as @John_Carter4 has indicated, you need to be dropping variables as soon as they are no longer needed. In the second screen shot you should be dropping url, method, loadAs, data, auth, headers in the “Pipeline Out” area – in both steps where you call pub.client:http. In the “Pipeline In” area there are a few variables that look like “pipeline litter” to me – variables that should have been dropped in earlier steps.
Also the mapping of body/bytes to auth (I assume to field under auth) is likely not correct.
If you’re okay with doing so, you might post a package with your FLOW service so it can be reviewed. Then someone can provide concrete feedback about what needs to be changed. Of course do not share any private info like credentials. Those aren’t needed. Someone will be able “desk check” this without needing to run it.
Thank you so much for all your suggestions. When I tried to invoke the second pub.client:http separately (from a different flow service) without having any out variables from the previous client call, it worked as expected without any issues.
So, how do I delete the out variables from the previous calls coming in as In variables in the next call? If I delete them and save, they are coming back again. Please let me know how this can be achieved.
You need to use the drop button. Select the attributes that you want to remove in the pipeline out of the previous step to your http call. Then click on the drop button as shown here
After which if you click on the next flow step you will no longer see them in the pipeline anywhere.
It is good practice to drop variables that are no longer needed and also to add a map step to the end of the every service with the comments “clean up”. In this step you should drop all pipeline variables that are not documented as outputs from your service.
