Appending shapefile to SQL Database through Web Application

391
2
09-30-2013 11:32 PM
StephenPage
New Contributor
Hi,

OUR TASK:
We have an (non-GIS) operator, who needs to occasionally upload a shapefile and append it to two databases. This is done through a python script that makes a backup copy of the two databases and appends the new records to the database/s, using arc tools (Spatial Join, Append etc).

The two access issues here are the arc 10.1 licence (currently stored on a server), and database access permissions.

OUR ENVIRONMENT:
The databases are SQL Server enterprise databases. We are running ArcSDE and ArcGIS Server 10.1. We have a web mapping Client interface that serves published map services. Arc licences are stored on a server.

THE SOLUTION?:
Rather than giving them edit access to the server etc, we would like to enable them to run the python script (preferably as a tool within a browser) that uploads, accesses arc tools, and appends to the database.

To do this via a web browser would be cleaner for us �??
i) allowing access to editing the database without giving general login permissions to the server
ii) access to arc license without a local installation on their desktop machine

We can utilise Python, AGS or ArcObjects, or whatever

Any advice would be greatly appreciated. Please bear with any ignorance on my part, as I�??m only starting to get my head around this.

This thread seems to have some similarities to a recent thread 'Managing Database through web application'.  I have made a new thread because it may be quite a different issue, as we already have a python script to do the tasks - the issue is with access to licences and access permissions.

Thanks,

Steve Page
0 Kudos
2 Replies
VinceAngelo
Esri Esteemed Contributor
The edit access has to exist, whether it's protected by a Desktop application or
a web application, so that part of your argument doesn't make sense.  It's
certainly easier to make a Desktop application (with a limited-use user's
password saved within the project), but a web-based geoprocessing tool
is certainly a possibility.

- V
0 Kudos
StephenPage
New Contributor
Thanks Vince,

I�??m not sure what you mean about a �??Desktop application�??. Is this an Arc Desktop installation?
(we were hoping to avoid the IT overhead of installing Arc on multiple desktops, where people only need it for a single task taking about 5 minutes.)

Where would I find more information about a web-based geoprocessing tool? I�??ve been investigating Feature Services and Geoprocessing Services - eventually we plan to publish Feature Services and allow editing. But at this stage it may be a step further than we require.

At this stage, we don't need to be able to edit features or attributes, or be able to visualise what we are doing.

The operator just needs to run a script or tool that:
�?� Deletes existing files (used in the geoprocessing)
�?� Creates a backup of the Databases ( 2 off)
�?� Spatial Join of eg suburbs, etc to the shapefile
�?� Calculate Field (recalculate Suburb name field)
�?� Append the new features to one of the 2 existing databases (based on a SQL WHERE statement)
�?� Compress the database

By using a script/tool, the Database Connection (containing the database server login) applies only to that instance of updating the database. Therefore the operator is not given a general Login access to the Database Server. (probably this would be the case no matter how we implemented, as you pointed out)

A copy of Arc Desktop, and the Licence Manager is held on a server. If the user runs the script/tool from their desktop, they would need an arc installation on their PC, to access the Arc Tools.

I�??ve been told that a major feature of ArcGIS Server is that with licences able to be stored on the server, this enables editing to be accessed via a web page.

We would like to be able to give access to a web page (or a folder) on the server, from where the operator could run the script/tool, using the Arc Desktop/Tools hosted on the server. Thus, we would avoid:
i) providing a desktop installation  of Arc (requiring more IT support!)
ii) providing a general login access to the server holding the Arc Desktop/Tools. Access would be limited to running that script/tool

Please feel free to point out where my assumptions are incorrect.

Thanks,

Steve
0 Kudos