topic Re: The relationship of GeoDatabase and ArcGIS Server in ArcGIS Enterprise Questions

The relationship of GeoDatabase and ArcGIS Server

LuyangRen — Mon, 02 Dec 2013 14:53:56 GMT

Hi All,

I am trying to figure out the architecture of ArcGIS Server. I figured that "copying the data to server" is not copying the data to the geodatabase but to the server directory. Then what the geodatabase used for in the architecture of ArcGIS server? We use ArcServer Enterprise and SQL server.

Thank you

Luyang

Re: The relationship of GeoDatabase and ArcGIS Server

DerekLaw — Mon, 02 Dec 2013 15:13:50 GMT

Hi Luyang,

I am trying to figure out the architecture of ArcGIS Server. I am wondering if "copying the data to server" is copying the data to the geodatabase.

FYI, when you publish a map from ArcMap to ArcGIS for Server and choose the "copy data" option, behind the scenes ArcMap will copy the source data for the map document and save it as a file geodatabase in the server directories of the ArcGIS Server site. Alternatively, you can define a data store so that source data for the map document is NOT copied into the server directories. It really depends on your workflow requirements,.

Learn more about this process here: Copying data to the server automatically when publishing.

To learn more about "the architecture of ArcGIS Server", please review this ArcUser technical article: ArcGIS for Server 101.

Hope this helps,

Re: The relationship of GeoDatabase and ArcGIS Server

DerekLaw — Mon, 02 Dec 2013 15:19:38 GMT

Hi Luyang,

... Then what the geodatabase used for in the architecture of ArcGIS server?

FYI, please review this ArcNews article: The Geodatabase: Modeling and Managing Spatial Data

Hope this helps,

Re: The relationship of GeoDatabase and ArcGIS Server

LuyangRen — Mon, 02 Dec 2013 16:47:58 GMT

Hi Luyang,

FYI, please review this ArcNews article: The Geodatabase: Modeling and Managing Spatial Data

Hope this helps,

Hi Derek,

Thank you for your quick reply.

After reading those information you shared with me, I think I got the answer to my question but not quite sure if it is correct. My understanding is that: a geodatabase is not necessary for publishing services through ArcGIS Desktop. But if we have multiusers and want to make full use of the capabilities of ArcGIS Server, it is better to use a multiuser geodatabase to manage datasets through versioning and replication. Is that correct?

Luyang

Re: The relationship of GeoDatabase and ArcGIS Server

KimPeter — Mon, 02 Dec 2013 20:05:00 GMT

My understanding is that: a geodatabase is not necessary for publishing services through ArcGIS Desktop.

That depends, really. If you want people to be able to edit the data through a service, you'll need a feature service. If you are using ArcGIS Server 10.1 or earlier, feature services require that the data be stored in an enterprise geodatabase.

Please elaborate on your specific set up and what you want to accomplish.

Re: The relationship of GeoDatabase and ArcGIS Server

MarcoBoeringa — Mon, 02 Dec 2013 21:06:45 GMT

That depends, really. If you want people to be able to edit the data through a service, you'll need a feature service. If you are using ArcGIS Server 10.1 or earlier, feature services require that the data be stored in an enterprise geodatabase.

Please elaborate on your specific set up and what you want to accomplish.

What Kimberley is trying to say is that ArcGIS for Server 10.2 has a new option: you can now also publish (editable) Feature Services from normal "non-geodatabase" spatially enabled enterprise database, that is, from any database with geographic data in it, possibly not maintained through ESRI software, but through third party software like AutoCAD. As long as the data is in a format ArcGIS can read (e.g. SDO_Geometry), you will be able to use it in a Feature Service as well (some caveats though regarding "being able to read"..., see the Help for that).

So you have two options at 10.2:

- 1) Create a geodatabase by enabling geodatabase storage on your enterprise database (Oracle, SQL Server etc.), and use ArcGIS for Server 10.2 to serve a Feature Service with most functionality specific to geodatabases (multi user versioned editing supported through replicas etc.). See also this Help topic: Tutorial: Performing web editing using data from an enterprise geodatabase

- 2) Create a "normal" spatial database on your enterprise database (Oracle, SQL Server etc.), and use ArcGIS for Server 10.2 to create a "light weight" variety of a Feature Service, that does allow editing with record locking, but no versioned editing with multiple users potentially editing the same features at the same time. Please note that editing requires an ArcGIS for Server "Standard" license minimum. See also this Help topic: Tutorial: Performing web editing using data from a database

After reading those information you shared with me, I think I got the answer to my question but not quite sure if it is correct. My understanding is that: a geodatabase is not necessary for publishing services through ArcGIS Desktop. But if we have multiusers and want to make full use of the capabilities of ArcGIS Server, it is better to use a multiuser geodatabase to manage datasets through versioning and replication. Is that correct?

So, probably yes, based on what I wrote above, but mind also that ArcGIS for Desktop is not yet capable of directly editing "normal", non-geodatabase spatial databases. With "directly", I mean through a normal Database Connection in ArcGIS for Desktop. So if you choose option 2), you can only edit the data through a Feature Service, or you need to use third party software to do the edits. ArcGIS for Desktop can import entire layers / Feature Classes though, so you can load data in non-geodabase enabled enterprise database. ArcGIS for Desktop can also edit a web Feature Service, so through that route, you can still indirectly edit the "normal" spatial database. See this Help topic: About editing data from feature services

Re: The relationship of GeoDatabase and ArcGIS Server

KimPeter — Tue, 03 Dec 2013 02:59:56 GMT

Well...I was only using feature services as an example. I just meant that without knowing your situation and what you're trying to accomplish, I can't make a blanket statement that you have to have an enterprise geodatabase or how you should use it with ArcGIS Server.

Luyang, based on your initial post, I thought you had a geodatabase and were trying to figure out how or if to register it with ArcGIS Server.

I figured that "copying the data to server" is not copying the data to the geodatabase but to the server directory. Then what the geodatabase used for in the architecture of ArcGIS server?

In which case, Derek's first post contained links to information about when to use specific registration options and what functionality they provide. Did you have further questions related to how or if to register your database or geodatabase with ArcGIS Server?

Your subsequent post led me to think, though, that you were actually trying to determine if you even needed a geodatabase.

My understanding is that: a geodatabase is not necessary for publishing services through ArcGIS Desktop.

Is that the case? Are you wondering how ArcGIS Server uses enterprise geodatabases so you can decide whether you need one or not?

Re: The relationship of GeoDatabase and ArcGIS Server

LuyangRen — Tue, 03 Dec 2013 15:17:21 GMT

Is that the case? Are you wondering how ArcGIS Server uses enterprise geodatabases so you can decide whether you need one or not?

Hi Kimberley,

Thank you for your informative response.

Our set up includes enterprise geodatabase(SQL Server) and 10.2 server. And our geodatabse has been registered with ArcGIS Server.

What I am trying to figure out is: how should we manage multiuser writing, editing, and publishing data with ArcGIS Server. And how should we manage the geodatabase permission with multiuser. I work in a college and we are going to let faculty and students publish their own services and build their web maps and web apps. So the architecture question is my first step to figure out how we should control multiuser permission and manage the database.

Thank you so much for your answers. And I am sorry for confusing you about what my question is.

Luyang

Re: The relationship of GeoDatabase and ArcGIS Server

MichaelVolz — Tue, 03 Dec 2013 17:25:24 GMT

Kimberly:

You can create a feature service from data other than SDE at v10.2? Can you show me a link to this documentation so I can read up on this topic.

Re: The relationship of GeoDatabase and ArcGIS Server

MarcoBoeringa — Tue, 03 Dec 2013 18:56:46 GMT

You can create a feature service from data other than SDE at v10.2? Can you show me a link to this documentation so I can read up on this topic.

See the links I posted before in this thread:

Tutorial: Performing web editing using data from a database

This option uses the new Query Layer functionality as introduced in 10.x.

Re: The relationship of GeoDatabase and ArcGIS Server

KimPeter — Tue, 03 Dec 2013 19:09:12 GMT

No worries, Luyang. 🙂

Will you load data for faculty and students to use? Or maybe faculty will load the data that students use? Whoever creates or loads data to the geodatabase will require permission to connect to the database, create table, create procedure, and create view privileges in the database, and will need a schema in the database that has the same name as their user name. If there will be multiple people creating/loading data, create a database role, grant the privileges to the role, and add the necessary users to that role. Each user who creates data will still need a matching schema, but using a role simplifies managing privileges.

Privileges for different types of geodatabase users can be found in this topic:
http://resources.arcgis.com/en/help/main/10.2/#/User_privileges_for_geodatabases_in_SQL_Server/002q0000002s000000/

If students are loading the data, publishing it, and editing it, grant them the privileges of a data creator and they'll be able to do what they need with their own data. If they need access to data someone else loaded, privileges must be granted to them on the individual datasets. (Again, if a group of students all need the same privileges on a dataset, create a role with those privileges and add the students' users to it.) Since you said you'll be using versioning and you may well be using other geodatabase functionality that involves system tables or procedures, grant dataset privileges through ArcGIS, not directly in the database. When done through ArcGIS, privileges are granted to all the tables, procedures, and views that make up a versioned geodatabase dataset. You can use the Privileges dialog box in ArcGIS Desktop to do this - http://resources.arcgis.com/en/help/main/10.2/#/Granting_and_revoking_privileges_on_datasets/002q0000002z000000/ - or the Change Privileges geoprocessing tool, which can be scripted, if you need it: http://resources.arcgis.com/en/help/main/10.2/#/Change_Privileges/0017000000n3000000/.

When publishing data, you have to think about the privileges of the person doing the publishing (they have to have access to the data to publish it) AND the privileges of the user that is specified in the .sde file you registered with ArcGIS Server. All the services will access the geodatabase data as the user in the registered .sde file.

Therefore, to publish a map service (or any other read-only service), connect permission to the database and select privileges on the datasets are required for:
-The user making the map (or accessing the data to be published)
-The user you have in the Database Connection file (.sde) that you registered with ArcGIS Server.
*Be aware that if you use Windows-Authenticated logins, the ArcGIS Server primary site administrator (that's the administrator account created when you set up the ArcGIS Server site) needs the same privileges: in this case, connect permission and select privileges on the datasets.

For services that allow you to edit or load data, such as editable feature services or image services, the privileges you grant to the user in the registered .sde file must be sufficient to perform the editing or data loading (image service) operations that you choose when publishing these services. For example, if you choose Query, Create, and Update operations for your feature service when publishing, the user needs select, create, and update privileges on the data that is in the service. Again, if using Windows Authentication, the ArcGIS Server primary site administrator also needs these privileges on the data.

As you read in the topic Copying data to the server automatically when publishing, you could also register an enterprise geodatabase as your managed database. Then, when feature services are published, the data gets copied from your source to the managed database. The data is owned by the user in the .sde file that you registered as the managed database. Therefore, that user needs privileges in the managed database sufficient to create data and a matching schema in the database. The data in the managed database is dependent on the feature service: if you delete the feature service, the data is deleted from the managed database.

Sorry...this is getting crazy long winded...
On the versioning side, as mentioned, granting privileges on the versioned datasets through ArcGIS grants the privileges needed on the delta tables and versioned view. Separate from that, geodatabase versions have coarse-grained permissions that the version owner can set to determine who has access to the version. That is described here: http://resources.arcgis.com/en/help/main/10.2/#/Creating_versions_and_setting_permissions/003n000000ws000000/. Your students might connect to a different version of the geodatabase and publish that data. The access level they set on that version could impact whether the published data can be edited. For example, if the version is protected but the .sde file registered with ArcGIS Server connects as someone other than the version owner or the geodatabase administrator, you won't be able to edit through the service.

You also mentioned using replication...for an overview of how geodatabase replication and ArcGIS Server are related, see this topic: http://resources.arcgis.com/en/help/main/10.2/#/Geodatabase_replication_and_ArcGIS_Server/003n000000rn000000/ Basically, it involves using a geodata service, so see the topics in the Geodata services section of the ArcGIS Server help for information on using those: http://resources.arcgis.com/en/help/main/10.2/#/What_is_a_geodata_service/015400000329000000/

Phew. I hope at least some of this is helpful. 🙂

@Marco: thanks for answering the subsequent post...it took me so long between meetings, etc. to compose the other answer, I missed Michael's question.

Re: The relationship of GeoDatabase and ArcGIS Server

LuyangRen — Tue, 03 Dec 2013 20:30:23 GMT

Hi Kimberly,

Thank you so much for writing such a long answer. I actually really appreciate it and it is pretty informative.

But based on my few knowledge, I still have several questions.

You can use the Privileges dialog box in ArcGIS Desktop to do this

When you talked about using privilege dialog box in ArcGIS Desktop, I think the entire paragraph is talking about dataset level privilege, is that right? If yes, then the owner of the dataset should be the one control the privilege, is that right? Then who should control the privilege of the database? the database administrator?

When publishing data, you have to think about the privileges of the person doing the publishing (they have to have access to the data to publish it) AND the privileges of the user that is specified in the .sde file you registered with ArcGIS Server. All the services will access the geodatabase data as the user in the registered .sde file.

Therefore, to publish a map service (or any other read-only service), connect permission to the database and select privileges on the datasets are required for:
-The user making the map (or accessing the data to be published)
-The user you have in the Database Connection file (.sde) that you registered with ArcGIS Server.
*Be aware that if you use Windows-Authenticated logins, the ArcGIS Server primary site administrator (that's the administrator account created when you set up the ArcGIS Server site) needs the same privileges: in this case, connect permission and select privileges on the datasets.

I don't understand who is "user that is specified in the .sde file you registered with ArcGIS Server."

And if I understand you correctly, if the owner of the data or the user in the .sde file would like the publish a map service, they both need the permission to connect tot he database and some privileges to the datasets. right?

Thank you! This is really helpful!

Luyang

Re: The relationship of GeoDatabase and ArcGIS Server

KimPeter — Wed, 04 Dec 2013 15:22:59 GMT

Yes; the Privileges dialog box in ArcGIS Desktop and Change Privileges geoprocessing tool allow the dataset owner to grant or revoke privileges on datasets. The database privileges (connect, create table, create view, create procedure) are granted by the database administrator.

When you register the data store that Derek mentioned, you are registering a database connection (.sde) file. That's the .sde file to which I was referring. This is the connection information that authenticates ArcGIS Server in the database. It requires a user name and password or, in the case of operating system authentication, will use the login of the connecting client (the ArcGIS Server primary administrator account for ArcGIS Server).

And if I understand you correctly, if the owner of the data or the user in the .sde file would like the publish a map service, they both need the permission to connect tot he database and some privileges to the datasets. right?

Pretty much...except the owner of the data already has full privileges on the datasets he/she owns. But if any other user besides the data owner needs to publish the data, that user needs connect permissions to the database and privileges on the data to be published. And, yes, the user specified in the .sde file that is registered as the ArcGIS Server data store (registered database) needs database connect and dataset privileges.