nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

permision level on sde dataset , feature layer , feature layer fields

anwarawad

hi all
I am working on a project that targets a none professional users for high level functionalities
in my project I am to build a module to control SDE administration work , and I have some Q's
1. I suggested building the application as a desktop based application rather than to be a web based , cause I think there will be lots of trade-offs if iam to use web , trade-offs related transactions that are highly critical ,,,,,, can anyone advice for that ? and if you can , can you send me the specific critical/danger point's trade-offs
2. I know that the policy of ESRI SDE is that privileges are given for the dataset level , not for feature layer nor feature layer field , can you help me if its possible to achieve that with some other way like using Oracle commands ? and if it wont make any collisions if I use it ? ,,,,,, if not and its no way to achieve that , can you point me to some official ESRI documentation that state's "its impossible" to do it

please help me ASAP , its urgent so I can decide what to do

thanks all for the help in advance

awad

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

VinceAngelo

Marco is right -- this isn't the right Forum to be asking SOE questions, but there was
a key part of your question that was relevant here:

I mean am I stuck to the map services and other services published on the arc
server or it can work and manage the resources on the sde ?????

The key piece is "on the sde". First off, the name for the spatial database engine of
ArcGIS has been "ArcSDE" for years. Second, ArcSDE is only the access protocol to
reach the database -- nothing is done "on" or "in" ArcSDE, only in the database or
on the geodatabase, through ArcSDE. The distinction is not solely pedantic -- if you
are thinking "geodatabase" instead of "sde", then it would be evident that any
ArcObjects application (like an SOE or a geoprocessing service) would have the
opportunity to manage resources within a geodatabase.

Just to clarify one part of Marco's post, you can't access an SOE without a
map service, since SOEs are published under a map service, and the REST
access URL for SOEs passes through that map service, but the SOE is not
restricted to the resources exposed by that service.

- V

MarcoBoeringa

then if it lives in arcserver ,, is it connected to any service of arc server ???
I mean am I stuck to the map services and other services published on the arc server or it can work and manage the resources on the sde ?????

You should probably ask this particular question in another sub-forum, like:

ArcGIS REST API
ArcGIS Runtime SDK for Java
ArcGIS Server (10.0 and prior) SOAP API

as there will be far more expertise there for answering your questions.

That said, just looking at the documentation in the Help, I get the feeling you should be able to make calls to such a SOE service without involving map services, just like calling any ordinary SOAP/REST based webservice. To do what you want, the ArcGIS for Server would of course need a (ArcSDE) Direct Connect connection to your enterprise geodatabase, so all prerequisites for that, like a proper database driver installed on the server where ArcGIS for Server resides, would need to be fulfilled.

Also see this remark on the What is a server object extension? Help page:

"Additionally, if you want to write custom property pages for your SOEs beyond those automatically generated, you must have a knowledge of Windows forms development or Java Swing (for ArcCatalog pages) or web forms development using Hypertext Markup Language (HTML) and JavaScript (for Manager pages)."

anwarawad

then if it lives in arcserver ,, is it connected to any service of arc server ???
I mean am I stuck to the map services and other services published on the arc server or it can work and manage the resources on the sde ?????

sorry for being annoying with my questions but I need to know these stuff before I go through the SOEs

thanks a lot for your help fellows

VinceAngelo

can server object extensions be used separately from any Arc Server service or instance ???
and away from any Arc Serve API's ????

No, they cannot. SOEs live inside an ArcGIS Server installation, and require the resources
of both ArcGIS Server and the ArcObjects SDK to operate.

- V

anwarawad

can server object extensions be used separately from any Arc Server service or instance ???
and away from any Arc Serve API's ????

MarcoBoeringa

my question is : can I use the arcobjects "server object extensions" to apply these functions ?? or do you recommend me to use something else ???

If it needs to be a web based solution, than yes, although I have never used it, from what I read about Server Object Extensions, you should be able to make use of that for accessing both ArcObjects based functionality, and geoprocessing functionality related to geodatabase management.

Don't forget though the possibility for arcpy geoprocessing services on ArcGIS Server as well, as also highlighted by this Help topic (although more related to webmapping and editing, and not so much to the geodatabase management tasks you seek):
Alternatives to server object extensions

anwarawad

my question is : can I use the arcobjects "server object extensions" to apply these functions ?? or do you recommend me to use something else ???

MarcoBoeringa

regarding to the application environment , the application shall have the following :
creating a version , reconcile & post versions , adding users and groups and assigning permissions , reading KPI's for the SDE ,
in other language is this applicable to be built in a web application ??

Looking at your list of requirements, I really have no clue as to why you, or your clients, aren't looking at all the new Geodatabase Administration geoprocessing tools and dialogs ArcGIS for Desktop has on offer, and the RDBM's management tools, for a solution to these requirements.

Simply upgrading to the latest version of ArcGIS for Desktop (10.2 and now 10.2.1), may give you all you need without programming a single line of code, and without endless worries about incompatibility between a custom implemented solution targeting vital access rights management features of an ESRI Geodatabase (actually in reality for a large part RDBMs features, but thoroughly managed by ArcSDE / ArcGIS for Desktop / ArcObjects).

Sometimes, the best advice to a potential client is simply "upgrade to the latest version"... even if it means losing a project... (If it is good client, they will come back to you for more sensible requests - where you are needed - after giving them good advice instead of a costly and maybe unnecessary custom solution).

Anyway, it may be that part of a "custom solution" might consist of creating a few ModelBuilder models, or Python scripts, exploiting the geoprocessing tools in the Geodatabase Administration toolset to automate some of the workflows your client requires more control, or simplification, off.

Another point is the possible use of Query Layers versus enabling a geodatabase, or Query Layers in combination with geodatabase usage. Maybe you can "join" sensitive column information to a Versioned View of the geodatabase data, and than set appropriate permissions to the new view and access this view as a Query Layer. Since the sensitive information won't be in the original geodatabase Feature Classes, and since the Query Layer accesses an essentially ordinary RDBMS database view, you will less likely run into issues related to the geodatabase. This will be a read-only solution though, since you can't edit the Query Layers.

VinceAngelo

There is no reason why you could not do all of those things in a web application.
Many of the administrative tasks shouldn't be done in any application
(huge security issue), but you still haven't provided a reason why a Desktop
solution is the best available option (hint: you should be thinking in terms
of numbers of users, numbers of available license seats, application complexity,
relative skill of the users,...).

ArcGIS only supports permissions given at the table level (for standalone feature
classes; it's at table collection for feature dataset access). Any further security
resolution implemented at the database level results in undefined behavior (can't
say if it will work, or not work, or cause some possible failure).

There are thousands of pages of documentation on how ArcGIS works; adding
"you can't do this" notes would increase the doc size by at least an order
of magnitude, making it difficult to find anything. It's doubtful that you'll be
able to find any documentation that justifies an assertion of "Esri recommends
we use row-level security in Desktop for this application."

- V

anwarawad

regarding to the application environment , the application shall have the following :
creating a version , reconcile & post versions , adding users and groups and assigning permissions , reading KPI's for the SDE ,
in other language is this applicable to be built in a web application ??

for the permission levels :
in oracle I can give permission levels varying from database level and to field level , my question is : can I force oracle permissions over the SDE data without affecting the SDE ???? well the SDE still be working normally ???

and for both , if you know any official document or link from ESRI that states that so I can justify my reasons

and sorry for the "urgent" part -v 🙂

thanks all for everything

VinceAngelo

1) No one here can tell you if a Desktop application is better than a web-based
one without a lot more information about the trade-offs that concern you.

2) The fact that accesses are granted at the feature dataset level shouldn't
concern you one bit, IF you are following best-practices and NOT using
feature datasets except for feature classes which always must be edited
together (e.g. poles, wires, and transformers). Permissions are usually granted
at the feature class (table) level, and row-level permission is not supported by
the ArcSDE API. There is no way to defeat the permissions granted to feature
datasets, since they are evaluated at runtime as an AND of the available
permissions (if one table is only granted SELECT access, then all tables are
granted SELECT access; if one table has NO access granted, the entire feature
dataset is displayed as empty).

Demanding urgent assistance from fellow users, many of whom are on holiday,
is probably not the best way to make use of these User Forums.

- V

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.