Skip to main content
  • EN

At a client, a proces runs consisting of a master workspace, controlling four workspaces being triggered with FMEServerJobSubmitters, waiting for job completion 'yes'. The FME Server version is 2016.1.3.1 and the host-OS Windows Serer 2012 and FME engine running under a service account within the local network.

In one of the slave workspaces a (custom transformer containing a) HTTPCaller calls a service on a different machine in the same local domain. This fails, giving a time-out, with the usual proxy warnings etc....

Putting the custom transformer with HTTPCaller in the master workspace works fine.

What could be the network related difference between having this HTTPCaller in the master workspace and in a slave workspace?

There is some proxy on this machine which is supposed to be non-existent to the local network domain. Having the thing work in the master workspace (and separate test workspaces) shows this is the case. We tinkered and tampered with proxy settings on FMEServer level as well as service-user level , but this did not change the behaviour. We have no rights to completely shut the proxy off and still have network connections so we can't test that one.

Thanks for reading and kind regards,

Martin

This is an issue that I run into fairly often. Unfortunately it can be a game of whack-a-mole to get everything right. As far as I know, FME Server does not recognize proxy exceptions containing wildcards. This means that if your main proxy is proxy.internal and you want to avoid internal requests to pass through the proxy, you would normally configure the Windows proxy settings with an exception on *.internal, which FME Server won't honor, leading e.g. the HTTPCaller to ask proxy.internal for a connection to webservice.internal, which will return a 404 or similar.

You will therefore probably have to define a custom proxy map for this. Unfortunately the FME Server proxy maps only work with exact URLs, meaning that you have to know the exact URL in advance, which of course is impossible for e.g. REST services.

But if you do know that the HTTPCaller will always connect to the same identical URL, you can configure a custom proxy map where that URL points to itself, rather than the global proxy.

This is an issue that I run into fairly often. Unfortunately it can be a game of whack-a-mole to get everything right. As far as I know, FME Server does not recognize proxy exceptions containing wildcards. This means that if your main proxy is proxy.internal and you want to avoid internal requests to pass through the proxy, you would normally configure the Windows proxy settings with an exception on *.internal, which FME Server won't honor, leading e.g. the HTTPCaller to ask proxy.internal for a connection to webservice.internal, which will return a 404 or similar.

You will therefore probably have to define a custom proxy map for this. Unfortunately the FME Server proxy maps only work with exact URLs, meaning that you have to know the exact URL in advance, which of course is impossible for e.g. REST services.

But if you do know that the HTTPCaller will always connect to the same identical URL, you can configure a custom proxy map where that URL points to itself, rather than the global proxy.

I'll just add that more recent versions of FME Server have improved some aspects of this compared to FME Server 2016, so you may want to consider an upgrade at some point.

I'll just add that more recent versions of FME Server have improved some aspects of this compared to FME Server 2016, so you may want to consider an upgrade at some point.

Thanks @david_r. I am not at this particular client today, but I pointed the collegues over there to this thread, and I already got a very hopeful e-mail from them.

So, I can't confirm yet it fixed all problems, but it definitely improved the matter.

Reply


Community Stats

30,184
Posts
114,569
Replies
37,847
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.