Select to view content in your preferred language

ArcGIS Enterprise (ArcGIS Pro 3.0.1): Why versioned feature classes with “branch” type get uneditable?

1618
11
08-29-2022 08:37 AM
JamalNUMAN
Legendary Contributor

ArcGIS Enterprise (ArcGIS Pro 3.0.1): Why versioned feature classes with “branch” type get uneditable?

 

I couldn’t figure out why versioned feature classes with “branch” type get uneditable

 

Is this by design?

 

Clip_1107.jpgClip_1108.jpg

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
0 Kudos
11 Replies
DavidColey
Honored Contributor

Hi Jamal - pretty sure this is by design.  You have to edit a branch feature through a feature access connection after the layer(s) have been published to portal

Scott_Tansley
MVP Regular Contributor

Branch editing is only available via a published feature service.  The data becomes read only in a Pro to database connection.

basically a web service controls the versioning process and so the editing has to be via a feature service as well. 

Scott Tansley
https://www.linkedin.com/in/scotttansley/
JamalNUMAN
Legendary Contributor

Then what are the benefits when getting the branch versions exclusively editable as they are published in the form of feature service?

 

Traditional versions can be edited either form feature class or feature service

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
0 Kudos
ScottTansley3
Occasional Contributor

Branch editing was specifically designed to provide high performance web editing and (initially) to support specific operations like Parcel Fabric and Utitlity Network Modelling which use a mix of desktop and web workflows.  

Branch versioning can be used more widely than those initial use cases, but if you're editing from Pro to GeoDatabase then use traditional versioning workflows.

 

JamalNUMAN
Legendary Contributor

I scanned the document but couldn’t find an answer to my simple question: why disallowing editing from feature class and making it possible for feature service should be of benefits?

 

With branch versions, disallowing editing at the level of feature class is a limitation

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
0 Kudos
ScottTansley3
Occasional Contributor

Your original question was "Is this by design".  Answer:  YES!

ArcGIS Pro communicating with a geodatabase direct uses ODBC drivers, and not web services.  Branch Version Editing is 'Web Service' based.  They are different architectural paradigms.  You need to publish a map service, configured for Feature Access after making the layers Branch Versioned.  You then connect ArcGIS Pro to the web service via your Enterprise Portal.  That is how they are designed to work.

I agree that it limits functionality, looking at it from one perspective.  But from the Enterprise GIS perspective, it offers many opportunities and it was IMHO the correct design decision.  

If you want to use direct ODBC editing, then you still have recourse to Traditional Versioning models.

JamalNUMAN
Legendary Contributor

In other words: what I lose if I go for traditional version and publish the feature classes as feature service? This way, editing is still possible either from feature class or feature service.

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
0 Kudos
ScottTansley3
Occasional Contributor

Branch Versioning is designed for optimum performance.  Versioned Editing is 'highly functional' but recognised as being slow. 

Publishing with Feature Access on Traditional Versioning offers up numerous options/complications (in my opinion) which serves some end use cases and not others.  Branch Versioning is much more simple to publish and "just works" with supported client applications.

Rather than asking many questions about can this or that work, it may be better to present your use cases and ask which option is better?  Start from your requirements of what you're actually trying to do.  It's hard to understand, currently, what it is that you want to achieve.