Latest Contributions by JohnDye

Thanks Hanna, that makes a good amount of sense. ... View more

Please add a Registry Key to Wow6432Node\ESRI\License<desktop-version> for setting Portal Connection Properties and implement a new command-line switch – ADDPORTAL=url – on the ArcGIS for Desktop setup.exe file to specify Portal Connection properties I envision this operating similarly to the SEAT_PREFERENCE and SOFTWARE_CLASS switches available on the setup.exe file. Just as those switches simply write their values to the Esri License Registry (eg. Wow6432Node\ESRI\License10.3), the ADDPORTAL=url – switch could write one or more portal connections to the system registry. ArcGIS Desktop would then read those registry keys at inialization to determine which Portal Connections, if any, are available and possibly another to determine which connection is the active connection. One could still manage Portal Connections through the ArcGIS Administrator GUI if they found that easier and had Admin permissions to do so, but just as is the case with setting your SOFTWARE_CLASS or SEAT_PREFERENCE through the ArcGIS Administrator instead of the Registry, all ArcGIS Administrator would really be doing is modifying the appropriate registry keys by writing new keys for new connections, modifying existing keys for changes to existing connections and deleting keys for removed connections. This Registry Key approach combined with the addition of the ADDPORTAL switch to ArcGIS for Desktop's setup.exe file would allow Administrators to establish Portal Connections for users during installation of ArcGIS for Desktop by calling the ADDPORTAL switch on the setup.exe. This would prevent our organization (and I expect many others) from being required to remote into a user's system to configure their Portal Connections after an automated install deployed over the network. ... View more

Paul, where are you referencing AppFramework from? I tried to import it but that didn't work. Update: Looked up AppFramework, seems to be something specific to AppStudio which I'm not using. ... View more

Thanks Lucas!, I actually did find that in the Runtime docs but wasn't aware of the Component.onCompleted piece. While this makes sense and for most it is probably the right answer, it didn't work for me after I inserted our proxy url and port. I then updated the proxy to localhost and fired up fiddler to see if I could get any insight from the network requests. Tunneling through Fiddler it worked fine, but once I closed Fiddler I lost the WebMap again if I rebuilt the solution. ... View more

"Enterprise app—An enterprise version of Player that acts as a home to a collection of your apps." Neat...how do you use it? In AppStudio when I click on the Enterprise Apps category, it just says no apps found for the selected category. ... View more

Well, I dont work for Esri but I suppose it depends on the intent of what mean when you say keeping things up to date. The Datastore, in my humble opinon, is meant to be a wild-wild-west of sorts. That is, since you don't want users creating, editing and deleting authoritative data but you also want them to be able to do some self-servicing of their basic GIS needs, you need a place for them to host their own data. That's the point of the datastore. It's a database that you can set up and pretty much not have to worry about. It's a decentralized database to host all the crazy permutations of end user data. The data within the datastore is not authoritative - it's user data. All their little files and personal layers. When it comes to authoritative content - which where I work, we tend to define as content that a team of GIS Professionals creates, validates and publishes for end users to leverage within the Portal - that's where setting up an Enterprise Geodatabase and registering it with your federated server(s) comes into play. To do this, you set up a normal Enterprise Geodatabase on SQL Server/Oracle/PostgreSQL/etc. - whatever your DB technology of choice is and then register that enterprise geodatabase with each of your federated servers. Once that's done, you load your authoritative content into that enterprise geodatabase and work with it the same way you always have. Direct-Connect from Catalog and run GP tools against it or if you're brave, work with it at the DB level. The key to making this work seamlessly with Portal is federation. You must federate your Portal with ArcGIS for Server. Doing so means that anything you publish to ArcGIS for Server will be made available in Portal. It also means that your Portal Groups and Roles will determine who has access to the services being sourced from your Enterprise Geodatabase. So once you're federated and you've got your data loaded into your enterprise geodatabase and you've added it to an ArcMap session, go ahead and get it all nice and pretty and then publish it directly to your ArcGIS Server Site (Not Portal!). At this point, since ArcGIS Server is Federated with the Portal, it automagically gets picked up by the Portal as well and that resulting feature service will be added to your My Content directory in Portal. Depending on how your database is set up and registered with your Server, you may need to ensure that your Portal Users have database accounts in order to access the service.  With this approach, what you're essentially doing is offering a decentralized data management system (ArcGIS Datastore) for end-user data so they can go nuts and do whatever they want with their personal data while simultaneously offering a centralized data system (your Enterprise Geodatabase) for authoritative/enterprise data. In terms of managing data hosted in ArcGIS Datastore via Python, you don't. With the above approach, it's not your data to manage, it's the user's. You manage the Enterprise Geodatabase, user's manage their own data within Portal and the Datastore will take care of itself. If you're really edit data hosted in the Datastore through programmatic means, you're going to need to get familiar with the REST API and manage the data through the Service's REST Endpoints. ... View more

In short; Yes. You must access it from the Feature Service exclusively. You can add the Feature Service to ArcMap and then right click and export it to a local FC. However, I don't understand why you would. You'd essentially be creating a standalone copy of that data. A better idea might be to right-click on the service, choose editing and create local copy for editing. That way, you can synchronize your edits back to the Service, which will update the data in the datastore. The problem with thinking about Hosted Services in the same way that you might think about traditional services is that Hosted Services do not have the SDE middleware sitting on top of the Database to expose it to ArcObjects. Without that there to act as the liason between ArcCatalog and the Databas, converting those ArcObjects commands to a valid DB operation, any GP tool you try to run, even an export which relies on ArcObjects, can't be performed. ... View more