Hi,
I am trying to post a JSON String to SalesForce using pub.client:http and below are the parameters.

image704×611 25.5 KB

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?

Thanks!

Hi there,
Your content-type needs to be case sensitive
try
“Content-Type”

regards,
John

Hi,
Sorry that was a typo in my post. But I tired it as “Content-Type” under header and didn’t get to work.

Thanks!

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.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/d3ffc47c0456334d3cdc1b1812b1660969f505eb_2_918x750.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/d3ffc47c0456334d3cdc1b1812b1660969f505eb.jpeg 2x" data-dominant-color="383838">

Screenshot 2021-04-08 at 19.47.521152×940 110 KB

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.

regards,
John.

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.

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?

Yes, here it is.

image985×628 34.3 KB

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.

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.

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,

Please try with POSTMAN or any other way to see on which end the issue is.

Thanks

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.

ok, thank you. Can you please let me know where should I add this “newSession=yes”? Under which parameter?

Hi All,

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

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/f7876abc0d9cb7edf49729a379ada2fab352f714_2_1035x303.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/f7876abc0d9cb7edf49729a379ada2fab352f714_2_1380x404.jpeg 2x" data-dominant-color="393939">

Screenshot 2021-04-15 at 18.53.202104×616 139 KB

You should then see something like this.

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.

regards,
John.

ah,
ninja’d

Thanks a lot. That helps. I am new to webMethods and still learning. But really appreciate all your suggestions and guidance!

Or you can invoke the pub.flow:clearPipeline service where you specify the variables to be preserved in the output.

See IS Built-In-Services Reference fro details.

Regards,
Holger

Not a bad suggestion. Here’s a different point of view for consideration: avoid using pub.flow:clearPipeline. Instead, always explicitly drop vars as soon as they are no longer needed.

Here are some thoughts on this from posts many moons ago that may be informative:

(The last one refers to a notion of the pipeline being “copied over from services to services” but it is not – the pipeline is a global variable pool for the thread and all services run in that thread have access to the pipeline – with exceptions for services invoked as transformers or within a scope.)

Edit: A couple of the threads referenced above mention “best practices” – there is no such thing. Just practices that some find useful for their environment. You may find they work for you as well.

You can map the variables you need to keep to variables with different names then drop the originals.

ok, thanks. I did that. I dropped the variables instead of deleting and it worked fine.

Personally I don’t like clearPipeline, smacks of lazy programming
John.