Skip to main content
  • EN
  • Home
  • Forums
  • FME Form
  • Data
  • FME doesn't find existing Feature Service in AGOL then fails because it already exists / Update Token

I have a series of WorkSpaces that run in sequence (via WorkSpace Callers). I have the main WorkSpace scheduled to run a few times a day, and over the last few weeks they've been running fine.

Today I noticed some of them began to fail, and throw the same error that I would sometimes get when I set them up the first time, a few months ago:

Encountered an unexpected error. The error code from the server was 'none' and the message was: 'Service name 'SERVICE' already exists for 'xxxxxx''. 

 

Of the 5 Workspaces that write to AGOL, 4 started to fail. One is working fine. All have the same settings, use "Insert" and "Truncate".

Looking deeper in to the logs, I found that for all of the writers that are failing the following is happening (some names redacted):

 

 
ArcGIS Online Feature Service Writer: Requesting portal information
ArcGIS Online Feature Service Writer: Getting list of user content items in 'User_org'
ArcGIS Online Feature Service Writer: Searching for all groups in the organization accessible to user 'User_org'
ArcGIS Online Feature Service Writer: Could not find a Feature Service item matching the Feature Service directive 'User_org/Service_Name'. A new Feature Service will be created

 

I think that's where it begins to fail. Further down in the logs I see that the FME starts to create a new File Geodatabase - something that does not happen when the translation succeeds.

 

 

ArcGIS Online Feature Service Writer: Uploading File Geodatabase dataset as an Item named 'Service_Name'
ArcGIS Online Feature Service Writer: Publishing Feature Service using Item named 'Service_Name', Target SR is WKID 102100
ArcGIS Online Feature Service Writer: Deleting Item 'Service_Name'
ArcGIS Online Feature Service Writer: Encountered an unexpected error. The error code from the server was 'none' and the message was: 'Service name 'Service_Name' already exists for 'xxxxxxxxxx''. Details: ''
ARCGISONLINEFEATURES writer: A fatal error has occurred. Check the logfile above for details

 

So it seems that FME doesn't find the existing service, decides to create it, but then is surprised that it already exists and can't create/upload the new one.

 

Then I noticed one thing different in the translation that succeeds: it updates the token to AGOL:

 

 

ArcGIS Online Feature Service Writer: Requesting portal information
Updating access token for 'user.name Esri ArcGIS Online'
ArcGIS Online Feature Service Writer: Getting list of user content items in 'User_org'

 

Apart from this difference, all translations / writers / parameters are the same: 

  • same authenticated connection
  • same writer parameters (Insert, truncate)
  • etc.

 

So in short:

 

 

Translations that fail:
  • Connect to Portal
  • Searches user's content for existing service
  • Proceeds to search all accessible groups in organization for existing service
  • Doesn't seem to find it. Decides to create it.
  • When writing/uploading, AGOL says it already exists.
  • Fatal error

 

Translations that succeed:

  • Connect to Portal
  • Request new token
  • Searches user's content for existing service
  • Finds and updates it

 

If I delete the existing service, the translation succeeds.

 

I found that there's a custom transformer that allows on to update the token, it requires user name and password (I authenticate via single sign-on).

 

 

Besides, I'm not sure that (the token) is the cause: I re-authenticated the connection via FME settings, and that didn't make a difference. And, it's the same authentication used for both the translations that succeed and the ones that fail.

 

 

Any ideas? Why doesn't FME find the existing service? Why does one translation request a new token and the others don't? Why some translations that worked very well for weeks suddenly start to fail?

 

 

Thanks!

Hi @mike707

 

Why does one translation request a new token and the others don't?

 

To answer this can you confirm if you are using ArcGIS Online or ArcGIS Portal

 

If you are using Portal -- you need FME Desktop 2019.2. and newer, here are instructions to use SAML (with Web connections) https://knowledge.safe.com/questions/110816/how-to-create-an-fme-web-connection-for-your-esri.html

 

If you are using AGOL (ArcGIS Online, then the Webservice already exists)

 

Why some translations that worked very well for weeks suddenly start to fail?

 

The way OAuth2.0 token works is that there is an access token and refresh token, refresh token is exchanged to get a new token. Here is the process as explained in the dev notes https://developers.arcgis.com/rest/users-groups-and-items/authentication.htm

Normally this works, but based on each organization setting these tokens are required to be re-authenticated either after 30 days or 90 days.

Why doesn't FME find the existing service?

 

When using a specific user, it is possible that you do not have permission to access that FeatureService, and it's required to be either shared with All Organization or at least with a Group (user is member of).

 

Another option, When adding writer, Select from the drop-down (Import from Dataset...) and select the group name/featureservice and layers.

 

OR Under Writer drop-down menu, select Import Feature Class, and confirm if the Layer or FeatureService name can be selected.

Please verify the name of the feature service from AGOL WebUI and confirm it matches when adding the writer, and also confirm if the item is shared with the group.

Hi @mike707

 

Why does one translation request a new token and the others don't?

 

To answer this can you confirm if you are using ArcGIS Online or ArcGIS Portal

 

If you are using Portal -- you need FME Desktop 2019.2. and newer, here are instructions to use SAML (with Web connections) https://knowledge.safe.com/questions/110816/how-to-create-an-fme-web-connection-for-your-esri.html

 

If you are using AGOL (ArcGIS Online, then the Webservice already exists)

 

Why some translations that worked very well for weeks suddenly start to fail?

 

The way OAuth2.0 token works is that there is an access token and refresh token, refresh token is exchanged to get a new token. Here is the process as explained in the dev notes https://developers.arcgis.com/rest/users-groups-and-items/authentication.htm

Normally this works, but based on each organization setting these tokens are required to be re-authenticated either after 30 days or 90 days.

Why doesn't FME find the existing service?

 

When using a specific user, it is possible that you do not have permission to access that FeatureService, and it's required to be either shared with All Organization or at least with a Group (user is member of).

 

Another option, When adding writer, Select from the drop-down (Import from Dataset...) and select the group name/featureservice and layers.

 

OR Under Writer drop-down menu, select Import Feature Class, and confirm if the Layer or FeatureService name can be selected.

Please verify the name of the feature service from AGOL WebUI and confirm it matches when adding the writer, and also confirm if the item is shared with the group.

@mike707 Can you confirm which version of FME you are using. FME 2019.2 added connection retry in the event of a slower network.

@mike707 Can you confirm which version of FME you are using. FME 2019.2 added connection retry in the event of a slower network.

FME 2020.1.0.0 (20200609 - Build 20575 - WIN64)

Hi @mike707

 

Why does one translation request a new token and the others don't?

 

To answer this can you confirm if you are using ArcGIS Online or ArcGIS Portal

 

If you are using Portal -- you need FME Desktop 2019.2. and newer, here are instructions to use SAML (with Web connections) https://knowledge.safe.com/questions/110816/how-to-create-an-fme-web-connection-for-your-esri.html

 

If you are using AGOL (ArcGIS Online, then the Webservice already exists)

 

Why some translations that worked very well for weeks suddenly start to fail?

 

The way OAuth2.0 token works is that there is an access token and refresh token, refresh token is exchanged to get a new token. Here is the process as explained in the dev notes https://developers.arcgis.com/rest/users-groups-and-items/authentication.htm

Normally this works, but based on each organization setting these tokens are required to be re-authenticated either after 30 days or 90 days.

Why doesn't FME find the existing service?

 

When using a specific user, it is possible that you do not have permission to access that FeatureService, and it's required to be either shared with All Organization or at least with a Group (user is member of).

 

Another option, When adding writer, Select from the drop-down (Import from Dataset...) and select the group name/featureservice and layers.

 

OR Under Writer drop-down menu, select Import Feature Class, and confirm if the Layer or FeatureService name can be selected.

Please verify the name of the feature service from AGOL WebUI and confirm it matches when adding the writer, and also confirm if the item is shared with the group.

Comments:

  • Using ArcGIS Online (and FME 2020).
  • Token re-authentication:
    • Understood, but that doesn't seem to explain why some translations fail immediately (minutes) after they were first ran and the feature service created. This was a constant problem when I created the workbenches the first time, and that ceased when I split the scripts in to different workbenches (to force them to run in sequence) and re-created the services.
    • I took a look at the documentation on authentication, did some tests, but I couldn't find a way to "force" a new token / token refresh to be requested.
    • I ran two translations today: one worked (requested update token), the other did not (did not update token). Shouldn't all succeed or fail?
  • Why doesn't FME find the existing service?
    • All of the services are accessible to me and are shared to the whole organization.
    • Yes, the names do match the service names in AGOL. The services were created by FME and the workbenches successfully updated them until now.
    • Select from the drop-down (Import from Dataset...) and select the group name/featureservice and layers: interesting point there. I created a new writer and did exactly this, and the translation succeeded (it had failed minutes ago with the previous writer). I'll give it a try again later on and hopefully it continues to succeed. However, it doesn't really explain why it used to work before. And I presume that one will have to first create a Writer that creates the new service, than switch to a new writer where the service name is selected via "Import from Dataset"?

 

I'm not sure if the cause is one or more things, or if there's a "random" component in the mix. I would like to understand why some writers are requesting token updates and others are not, and if there's a way to force the update.

 

 

Thanks again!

Comments:

  • Using ArcGIS Online (and FME 2020).
  • Token re-authentication:
    • Understood, but that doesn't seem to explain why some translations fail immediately (minutes) after they were first ran and the feature service created. This was a constant problem when I created the workbenches the first time, and that ceased when I split the scripts in to different workbenches (to force them to run in sequence) and re-created the services.
    • I took a look at the documentation on authentication, did some tests, but I couldn't find a way to "force" a new token / token refresh to be requested.
    • I ran two translations today: one worked (requested update token), the other did not (did not update token). Shouldn't all succeed or fail?
  •  Why doesn't FME find the existing service?
    • All of the services are accessible to me and are shared to the whole organization.
    • Yes, the names do match the service names in AGOL. The services were created by FME and the workbenches successfully updated them until now.
    • Select from the drop-down (Import from Dataset...) and select the group name/featureservice and layers: interesting point there. I created a new writer and did exactly this, and the translation succeeded (it had failed minutes ago with the previous writer). I'll give it a try again later on and hopefully it continues to succeed. However, it doesn't really explain why it used to work before. And I presume that one will have to first create a Writer that creates the new service, than switch to a new writer where the service name is selected via "Import from Dataset"?

 

I'm not sure if the cause is one or more things, or if there's a "random" component in the mix. I would like to understand why some writers are requesting token updates and others are not, and if there's a way to force the update. 

 

 

Thanks again!

Hi @mike707 

 

After some more investigation, I think I have a possible explanation, why the subsequent run Fails for you.

ArcGIS Online does not support "spaces" in layer names, when the service with layer is published the first time, the name will be changed to "underscores"

 

When writing the Feature Service for the first time it will successes, for subsequent runs it will fails as the service name has be changed 

From my test

ArcGIS Online Feature Service Writer: Could not find a layer/table matching feature type 'Fire Halls

Screenshots (the layer was renamed automatically to Fire_Halls)

0684Q00000ArN7RQAV.png

Background:

When running workspace for the first time, FME packages the data(in a zip folder) and then the publish the service step is performed on the server side. Unfortunately, there is no logs(sent back to FME) indicating whether the publish was successful or the Layer names were changed. 

Workaround:  Import from DataSet... brings the correct Layers (the reason I asked to check WebUI vs FME) 

Hope this clarifies the behavior, for the web service not being validated might be something that can be investigated further, if you would like to file a support ticket to troubleshoot it further. https://www.safe.com/support/report-a-problem/ 

 

 

Hi @mike707 

 

After some more investigation, I think I have a possible explanation, why the subsequent run Fails for you.

ArcGIS Online does not support "spaces" in layer names, when the service with layer is published the first time, the name will be changed to "underscores"

 

When writing the Feature Service for the first time it will successes, for subsequent runs it will fails as the service name has be changed 

From my test

ArcGIS Online Feature Service Writer: Could not find a layer/table matching feature type 'Fire Halls

Screenshots (the layer was renamed automatically to Fire_Halls)

0684Q00000ArN7RQAV.png

Background:

When running workspace for the first time, FME packages the data(in a zip folder) and then the publish the service step is performed on the server side. Unfortunately, there is no logs(sent back to FME) indicating whether the publish was successful or the Layer names were changed. 

Workaround:  Import from DataSet... brings the correct Layers (the reason I asked to check WebUI vs FME) 

Hope this clarifies the behavior, for the web service not being validated might be something that can be investigated further, if you would like to file a support ticket to troubleshoot it further. https://www.safe.com/support/report-a-problem/ 

 

 

Hello

Good point, but none of the layer names set in FME (or in AGOL) have spaces. Only underscores are used.

FYI, after my previous answer, where in only one of the Writes I used "select from drop down" to pick the name of the existing service, all workbenches ran successfully (even the ones that did not request a token update - hence maybe the token has nothing to do with the problem).

Weird. I hope it continues working over the weekend, but I'd really like to find out what the cause is.

Thanks again.

Reply


Community Stats

30,121
Posts
114,324
Replies
37,749
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.