Skip to main content

I'm unable to run a Workbench on FME Server 2017.0.1.1 that reads and writes to a feature service at ArcGIS Online. I've read the other streams related to this but can't work out the correct workflow, or if we have some problem with the server accessing the online resources for OAUTH2 from inside the corporate network. 

The workbench works from FME Desktop 2017.0.1.1 with no a problem.

I've created an app at ArcGIS Online to obtain a Client ID and Client Secret with the redirect Uri of urn:ietf:wg:oauth:2.0:oob and this all works in Desktop. 

These same elements were entered into the "Client Information panel" of the Web Service page in FME Server for service "Esri ArcGIS Online". 

0684Q00000ArD4nQAF.png

I then created a new Web Connection "g9k Esri ArcGIS Online02" using the  "Esri ArcGIS Online" Web Service defined above.

0684Q00000ArCqhQAF.png

 

I can then use the "Authorize" button and enter the AGSOL credentials...

0684Q00000ArD4sQAF.png

After clickiong on Sign In", we get a code string back from OAuth2 Approval with "Please copy this code, switch to your application and paste it there" message above a 192 character string. 

0684Q00000ArD0TQAV.png

At this point, I don't think I've successfully authenticated our new connection because if we try to run a Workbench uploaded with that same connection name (i.e. without uploading the connection from Desktop), the log shows the following:

ERROR: Access token not found for connection 'g9k Esri ArcGIS Online02'
ERROR: Python Exception <FMEWSException>: Type: 3, Number: 1, Message: Failed to get authorization header.
ERROR: A fatal error has occurred. Check the logfile above for details

0684Q00000ArCi1QAF.png

If we try uploading a connection that works on FME Desktop to FME Server we get the same issue where I don't think the connection is getting authorised properly when we attempt to authorise the uploaded connection.

Is this workflow correct and if it is what can be wrong? 

I suspect a proxy server issue in relation to OAUTH2.

Your redirect URIs should be http(s)://SERVERNAME/fmeoauth

I don't know if your method works, but we generated the Client ID & Client Secret by registering a new application with ArcGIS Online: https://developers.arcgis.com/applications/new

Once you have that, you should then use that with FME server for all the ArcGIS Online authentications that you need in the future.


I tried http(s)://SERVERNAME/fmeoauth but get the same error.

We had it working before as described above but it was intermittent so we set up a separate test instance of FME Server 2017.1 on a machine that had a direct internet connection using a 90-day trial license and it seemed to work there consistently using the same configuration and approach. The problem is that the 90-trial license has now expired so we can't do any more testing. The production server inside the corporate network no longer seems to work at all so that's why I suspect a problem with the proxy settings or firewall, but I'm unable to troubleshoot any further as I don't have a Windows login to the server machine.


I tried http(s)://SERVERNAME/fmeoauth but get the same error. 

We had it working before as described above but it was intermittent so we set up a separate test instance of FME Server 2017.1 on a machine that had a direct internet connection using a 90-day trial license and it seemed to work there consistently using the same configuration and approach. The problem is that the 90-trial license has now expired so we can't do any more testing. The production server inside the corporate network no longer seems to work at all so that's why I suspect a problem with the proxy settings or firewall, but I'm unable to troubleshoot any further as I don't have a Windows login to the server machine.

Yes this is a redirect URI issue here.

 

Looking at the screen shot I would use the following as the redirect URI. 

 

http://pwdchsdp01:8080/fmeoauth
It should be this in both FME Server and the ArcGIS Online app you created with the corresponding Client ID and Client Secret. Remove any existing redirect URI from AGOL so only the one above is being used. Then re-authenticate the connection

 

Here's a little vid: https://www.screencast.com/t/PqPDj31TSb7

 


Thanks for the video. We have tried that before and we always get the following.


@MattAtSafe I tried following your instructions on our temporary FME Server instance that I built at my home office in December using a trial license, it all works perfectly with the redirect URI of http://cadbase03:8088/fmeoauth (the internal address). Despite the fact that the trial license has now expired, I can still use it to test the authorization of Web connections. Unfortunately, when I repeat the same test at work it fails the authorization step with.

In a post from @rudy_v, he got a similar result but talked of a proxy issue that he subsequently fixed but I'm not clear on what he had to change. The server is in a government network where we don't have much access to proxy or firewall settings so we would need to involve the outsourced IT firm to make any changes - and we must know what changes to ask for precisely before they will act.


@MattAtSafe I tried following your instructions on our temporary FME Server instance that I built at my home office in December using a trial license, it all works perfectly with the redirect URI of http://cadbase03:8088/fmeoauth (the internal address). Despite the fact that the trial license has now expired, I can still use it to test the authorization of Web connections. Unfortunately, when I repeat the same test at work it fails the authorization step with.

In a post from @rudy_v, he got a similar result but talked of a proxy issue that he subsequently fixed but I'm not clear on what he had to change. The server is in a government network where we don't have much access to proxy or firewall settings so we would need to involve the outsourced IT firm to make any changes - and we must know what changes to ask for precisely before they will act.

Hi @grahamkeencadba,

 

Hmm this does sound like some kind of proxy/firewall issue. One thing you could try is using the IP address for the server instead of the server name in the redirect URI. That has worked in some cases. Here is some more general information on using the web services: http://docs.safe.com/fme/2017.1/html/FME_Server_Documentation/Content/AdminGuide/Planning-Access-to-Web-Services.htm I'm sorry I'm not more help here. Perhaps @rudy_v can provide some more details.

@MattAtSafe

As I suspect it's a proxy issue, I'm wondering if Safe could advise if we need to set FME Server to use a proxy specifically as detailed at:

http://docs.safe.com/fme/2017.1/html/FME_Server_Documentation/Content/AdminGuide/Using_FME_Server_with_Proxy_Server.htm

where we use these commands:

fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Setting" "Use System Proxy"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Authentication Method" "<Basic|Digest|NTLM>"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Server Require Authentication" "true"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Username" "<UserName>"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Password" "fme_encrypt(<password>)"

To set Windows registry entries for a system account with a non-expiring password that has access to the proxy, and if we do this, do we also need to change the services to run as that system account instead of the default local system account?

 


@MattAtSafe

As I suspect it's a proxy issue, I'm wondering if Safe could advise if we need to set FME Server to use a proxy specifically as detailed at:

http://docs.safe.com/fme/2017.1/html/FME_Server_Documentation/Content/AdminGuide/Using_FME_Server_with_Proxy_Server.htm

where we use these commands:

fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Setting" "Use System Proxy"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Authentication Method" "<Basic|Digest|NTLM>"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Server Require Authentication" "true"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Username" "<UserName>"
fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Password" "fme_encrypt(<password>)"

To set Windows registry entries for a system account with a non-expiring password that has access to the proxy, and if we do this, do we also need to change the services to run as that system account instead of the default local system account?

 

Changing the services to run as an account is recommend for sure. Just make sure the around has all the appropriate permissions for the system share and database. You could definitely try and set up the proxy on FME Server. How did you figure out it was a proxy issue?

 

 


Hi I have faced same issue with arcgis online and I fix it by follow certain configuration steps ; for more details see the below link video

https://drive.google.com/file/d/1PpdXgfZxNB5aC3450yd5VYNJ2RjKXFTJ/view?usp=drivesdk


Reply