Select to view content in your preferred language

R-bridge on Server deployments: derived output files URLs not working

811
2
Jump to solution
04-04-2018 11:36 AM
FrancescoTonini2
Frequent Contributor

I am still encountering a series of severe issues when deploying custom GP services that use R-bridge on Server architectures. I am using ArcServer 10.4.1, R 3.4.0 (64bit) and have installed R-bridge. Seems like the issue of "bug in arc.env()$workspace READ-ONLY on server deployments" still has not been solved to allow use of the arc.env() setting for writing derived output of a GP service into the default ESRI scratch folder. However, even when hardcoding the full path on the server to one of my own folders registered in the data store (see image below), the GP service will not create a working output URL for textual files.

...

 

 As you can see the derived output is set up correctly in out_params[[1]] <- out_pdf and when run on ArcGIS Desktop the GP tool work as expected, generating the output file in the hardcoded folder on the server.

When published as a GP service however, this leads to an error (below) where the URL does not point to the hardcoded file in the D:\\ drive. Error says INVALID URL (Code 400).

Can anyone provide some help with this and let me know if there is any workaround?

0 Kudos
1 Solution

Accepted Solutions
FrancescoTonini2
Frequent Contributor

It appears that the way around it for Server deployments is to use arc.env()$scratchWorkspace instead of arc.env()$workspace in your R script when writing the derived output to the scratch folder (equivalent of the arcpy.scratchFolder in Python). This functionality is not well documented so I had to go through ESRI customer support to figure this out. If possible, please make sure the arcgisbindings R package has the env$scratchWorkspace function documented. Closing the issue with this solution.

View solution in original post

0 Kudos
2 Replies
FrancescoTonini2
Frequent Contributor

MPobuda-esristaff SWalbridge-esristaff could any of you guys in the R team help me figure this out? Server deployments of GP services using R tools seem to be having these sort of issues explained above as well as the one posted on github for writing to scratch workspaces. Thanks!

0 Kudos
FrancescoTonini2
Frequent Contributor

It appears that the way around it for Server deployments is to use arc.env()$scratchWorkspace instead of arc.env()$workspace in your R script when writing the derived output to the scratch folder (equivalent of the arcpy.scratchFolder in Python). This functionality is not well documented so I had to go through ESRI customer support to figure this out. If possible, please make sure the arcgisbindings R package has the env$scratchWorkspace function documented. Closing the issue with this solution.

0 Kudos