0

We have one licence for Data-Interoperability server extension and one for Arcmap 10.6.

I want to share some of the tools that I created with some colleagues who do not have the extension. Basically, I want to run, share, and then allow them to connect to the server and run the tools with their own data.

I have a tool which has two parameters. Reader and writer. The reader is an SQL Server and the user must select the database which has to run through the whole flow. The output is a GDB with two polygon layers.

Problem 1: From some reason the published tool doesn't have the list of SQL Databases.

Problem 2: The writer is static, even during publishing, and will not let me change it, no matter what.

1

I'll start my answer with noting its been probably 3+ years since I've worked with Data Interop and GP Services, so some of my knowledge might be out of date. I can't comment exactly on your workflow, but I can provide some information on these two components.

First, GP Services have a limited number of accepted Input and Output parameters. These parameters are generally pretty simple; double, string, date, linear unit, feature class, table and a few more. The outputs mostly match the ones permitted for inputs. With that knowledge in mind, one of your inputs is a SQL Database (ie Workspace). This could be considered a "complex" input. As such, when publishing a GP Service from a model or script that made use of this input, it's going to try and help you match this parameter to a supported input. The best it'll be able to do in this case is convert to a STRING. Thus, when you try to run the GP Service, you don't see a way to select from a list of databases, you just have a box you can type in. In this situation you might be able to provide a path to a database, like c:/temp/mydatabase.sde, but for your end users, that's a poor workflow (not to mention is going to fail for more reasons than I care to type out). You really need to go through the GP Service documentation to understand supported inputs and outputs and think about how you could possibly design your tool within the confines of those supported parameters.

The next part, using the Data Interop tools -- I think you can only really publish the Quick Import or the Quick Export tools and be successful with them in a service. You can setup inputs and outputs based on my previous explanation and make use of these. You could try publishing something created in the workbench, but the inputs and outputs will simply not be supported. If this does publish both the inputs and outputs will most likely be hardcoded and the end users of your geoprocessing service wont be able to supply their own inputs. The service will provide little to no value for them.

You may want to look into something like FME Server if you want to share your Data Interop workflows in a better way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.