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; } } }

ArcSDE and Runtime 10.1.1

JohnWass

We have an existing ArcObjects thick client application that makes workspace connections to SDE database using a local connection string (ie, sde:postgresql:hostname). This application provides a full range of feature editing through custom controls.

We want to port over as much of this application as possible to Java Runtime 10.1.1 to take advantage of the pure Swing implementation. Understanding there are limitations currently in the Runtime API, we are willing to leave certain custom functionality behind.

Unfortunately my initial prototyping is getting hung up right away on the database connection capabilities. I am understaning that Runtime is focused mainly on the MapPacks, but for us they are not an option as we do not use Desktop products at all. I need some form of direct connection to a feature store.

Looking at WorkspaceInfo in the API docs, it apppears to be the only available hook to an SDE database. So from that I get a WorkspaceInfo instance that is connected to SDE. Then from there, what can I do to get from the WorkspaceInfo to editable Feature layers?

The only other option I suspect is available right now in the API is to expose a Feature service through ArcServer. I could probably make that work though it would be a major change to our current architecture, as we do not currently deploy ArcServer.

Any suggestions on options would be appreciated. Please let me know if any further details would be useful.

Thanks,
john

Find more posts tagged with

Accepted answers

All comments

JohnWass

Thanks for the info Eric.

EricBader

Yes, you guys have correctly assessed the situation.

The 10.1.1 SDK model for editing geodatabases utilizes Feature Services for maintaining geometry and attributes for simple features only.
Direct reading of datasources using WorkspaceInfo is very basic, and read-only at this time. Not many folks are trying to use dynamic layers like this. The API doesn't really support it.
In short, the API will continue to be improved to better support direct reading/querying of "ad-hoc" datasources that are added to the Map, free from the map package requirement, but this will still not be there for 10.2. It is on the radar for a future release, but very important for us to get done.

John, I would not say that your use case and current implementation is "fringe" at all, by any stretch. There are many requests for this kind of direct editing and access to GDB feature classes, and there are many current Engine apps all over the world doing this, as Esri has trained Engine/ArcObjects developers to do this. The Runtime SDKs and their editing frameworks are designed more for a simpler/streamlined editing model and experience, one that is not so granular, which eases things a lot, but does make migration from ArcObjects to Runtime sometimes difficult.

Marco, your comments are excellent. As you've stated, many more options are on the horizon.

JohnWass

Agreed. I can understand you cant cater to all the corner cases in the SDK and API, and mine may very well be one of those.

Bloat was not the right term anyways, enlarged would have been better used. Ive used Desktop @ 9.3 and know the capabilites it has, so I bet we will find additional uses for it as we go on.

My initial shock was (sorta still is) just due to the fact that Desktop is a large footprint for what my purposes are right now, because I will essentially be using a 1GB (guessing) application to write a config file.

In the end its worth it to get the Swing implementation to replace the ArcObjects interop beans that we have now. Id purchase 40 subscriptions to Vibe in addition to Desktop to get rid of those... 🙂

john

MarcoBoeringa

John,

I agree with most of what you write, but I do think there are pros and cons to the approach ESRI chose:

pro:

- You only need to worry about a single "Feature Service" type of connection when interacting with your data in the development process. No plethora of different connection or datasource types to worry about as supported by ArcGIS. The Map Package and Runtime hide the complexity. This simplifies the development process.

- You can do all the basic preparatory work with all the advanced tools of ArcGIS, meaning an almost unlimited set of possibilities for authoring the maps.

con:

- You may find, like you are stating, the ArcGIS a bloated addition to the web application development platform. Alas, but not many people run a pure Engine environment like you, and most organizations have the necessary licences and skills to do the preparatory work and author the maps and export to a Map Package.

I agree it is likely there will be more options in the future...

JohnWass

Thanks for the reply Marco, and for the links. I had read over that blog post previously, it was one of the credible mentions of SDE support I had found.

I watched the entire video today, and even though they only mentiond SDE in passing I do get the gist of how Runtime is intended to be used at this time. Ill have to see about getting Desktop again to get up and running. Its not too bad of a situation to be in, Ill create the MPK and deploy it with the app. It should never have to change, as the feature tables themselves are constant. The only downside to that is development environment bloat and the potential cost of Desktop.

Essentially, as the ESRI Australia blog explains, Runtime acts like a mini local web server ("...uses an embedded web server to create/communicate with worker processes that do things like draw map..."). You interact with this embedded web server's Feature Services based on your SDE connections (or whatever datasource you have, e.g. shapefile) via SOAP, not with the data "directly".

Understood. But somewhere, something has to interact with the SDE data directly. I assume in this example its the LocalFeatureService. From my point of view, which is completely ignorant to the underlying implementation of these components, it would make sense that: Since you have a handle on SDE through the WorkspaceInfo, and are using a MapPack to define the data the service provides, what if instead of using a MapPack, you could just specify a SDE feature class that the service to connect to. Maybe you just specify the Feature Class name as a string, or in some way that is comparable to how the MapPack is doing it?

Well that is where I was going with the previous comment. If that were possible, I would not need Desktop in my pure Engine dev process at all from what I can tell. Of course, the API would have to have all the other stuff that makes the layer useable, ie query strings, and whatever else to make it fully capable. Im sure its far more complicated than my brief thoughts, but hopefully something similar is on the roadmap for the future.

Anyways, I believe I can move forward once I get access to Desktop. Thanks again for the info,

john

MarcoBoeringa

John,

You may wish to have a look at this video:

http://resources.arcgis.com/en/communities/runtime-java/video1668.htm

Move to 33:30 for the start of the topic about editing.

You need to create a Map Package containing the data referencing your SDE database. I think you won't be able to circumvent running at least one Desktop licence to author these... You can than consume this Map Package in Runtime and edit, but Simple Features only!

And see this page for a nice compact introduction about Runtime and how it functions:
http://esriaustraliatechblog.wordpress.com/2012/01/03/a-bit-more-on-arcgis-runtime-for-windows-and-linux/

Essentially, as the ESRI Australia blog explains, Runtime acts like a mini local web server ("...uses an embedded web server to create/communicate with worker processes that do things like draw map..."). You interact with this embedded web server's Feature Services based on your SDE connections (or whatever datasource you have, e.g. shapefile) via SOAP, not with the data "directly".

JohnWass

Ended up trying this

// create connection to the sde feature store using sde connection file
final WorkspaceInfo info = WorkspaceInfo.CreateSDEConnection("test", "feature.sde");

// try to create a new feature service using the blank map pack
final LocalFeatureService lfs = new LocalFeatureService("mpk_blank.mpk");
lfs.getDynamicWorkspaces().add(info);
lfs.start();

// create a feature layer using the local service
final ArcGISFeatureLayer layer = new ArcGISFeatureLayer(lfs.getUrlFeatureService());

It seems the limitation in the API is that I cannot specify what feature class to connect to when creating the LocalFeatureService. Setting the blank map pack allows it to start up, but there does not seem to be a binding to the SDE workspace. Which makes sense, it was just worth a shot to see what would happen.

So it seems I would need something similar to the ArcObjects IFeatureLayer method setFeatureClass, so that I can specify what feature class to connect to from my WorkspaceInfo object.

Also found this:
http://forums.arcgis.com/threads/73206-Can-I-load-the-GeoDatabase-in-the-ArcSDE-via-ArcGIS-RunTime

The lack of response there does not inspire much hope here.

JohnWass

Ok, so perhaps I can do something like this:

WorkspaceInfo info = WorkspaceInfo.CreateSDEConnectionFromFilePath(..)
LocalFeatureService lfs = new LocalFeatureService()
lfs.getDynamicWorkspaces().add(info)
ArcGISLocalFeatureLayer lfl = new ArcGISLocalFeatureLayer();
lfl.setUrl(lfs.getUrl());

Will test that out.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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