I have no idea the answer, but I would start with eliminating things. For example, to find out if your 3rd party app is a problem, try using a different app. The easy way to try is to use FileMker's PHP API to make the same URL call to FileMaker Server. If that works, then clearly there is a problem at the 3rd party's end of things because you could do it both manually as well as via another app (PHP). However, if PHP fails, then it is probably a FileMaker handling problem. By the way, is this a single system FileMaker setup or multiple systems? Windows 2008 R2? FMS 12 v2?
Have you taken a very close look at the API of the third-party app to see if there is a setting in the URL-invoking functionality that allows you to turn off URL-encoding for the URL data you enter?
Very best & good luck,
Thanks, Taylor and Steve, for your responses. This is Win 2008 Standard R2 SP1 running FMS 12.0v2.
The third-party app doesn't have many options, and it is unfortunately irreplaceable at this time. But even still, the problem seems to be with how the WPE does its encoding or decoding.
Our first workaround attempt at resolving this after my post yesterday was to have the third party app send its parameters to a custom PHP page we set up, and then have the PHP page do a proper cURL on it and forward it to the same FMS XML url as above. That all went great until the script.param had an "%26" in it (an ampersand), cURL sent it on and WPE choked on it.
Our next (and for now final) workaround was to simply avoid the XML engine and just call the FMS script directly from the intermediate PHP page, and passing it the parameter in doing so. This seems to be the most reliable.