Latest Contributions by JohnMDye

ArcGIS Online/ArcGIS Enterprise's Feature Layer Templates are a pretty neat capability. With just a couple of clicks, you can publish a fully functional hosted feature layer. Unfortunately, Esri has tried to be prescriptive here in terms of the schemas of a Hosted Feature Layer which might be helpful if GIS technology were used in just a handful of industries, but its not. It's used in practically every industry imaginable. I've yet to come across a single industry that doesn't use GIS somewhere - and therein lies the problem.  GIS is simply too broad of a technology for Esri to make their feature templates the only templates available. The only other option after this is using the Build a Layer capability to build one from scratch and that is a great capability too, but then what if you want to share this awesome layer as a template within the Layer Templates? There's no way to do that and further, there's no way even for an Administrator to create Feature Layer templates for their organization that appear in the Feature Layer templates gallery. Here's the idea - you go through the process of building your awesome hosted feature layer from scratch using the Build a layer functionality in the Create a feature layer dialog. However, when you get to the last screen, there is an option to save it as a "Hosted Feature Layer Template". Doing this does not actually publish a Hosted Feature Layer. Instead, it creates a template, that can be used by others to publish the Hosted Feature Layer as defined by your template, using the same schema, geometry and one would hope, even domains, subtypes, default values and more. The Hosted Feature Layer Template item could also be shared, so that only certain users see it in the Template Gallery under perhaps an "Organization" tab at the bottom beneath "Natural Resouces". To be honest, what would really be fantastic would be to be able to customize all of those industry categories to something that applies to my organization. I really have no use for any of them but if I could customize the dialog with different categories (eg. Tabs), and populate them with templates that apply to each of the categories relevant to my organization, this could become a much more useful capability. ... View more

ArcGIS Online/ArcGIS Enterprise's Feature Layer Templates are a pretty neat capability. With just a couple of clicks, you can publish a fully functional hosted feature layer. Unfortunately, Esri has tried to be prescriptive here in terms of the schemas of a Hosted Feature Layer which might be helpful if GIS technology were used in just a handful of industries, but its not. It's used in practically every industry imaginable. I've yet to come across a single industry that doesn't use GIS somewhere - and therein lies the problem.  GIS is simply too broad of a technology for Esri to make their feature templates the only templates available. The only other option after this is using the Build a Layer capability to build one from scratch and that is a great capability too, but then what if you want to share this awesome layer as a template within the Layer Templates? There's no way to do that and further, there's no way even for an Administrator to create Feature Layer templates for their organization that appear in the Feature Layer templates gallery. Here's the idea - you go through the process of building your awesome hosted feature layer from scratch using the Build a layer functionality in the Create a feature layer dialog. However, when you get to the last screen, there is an option to save it as a "Hosted Feature Layer Template". Doing this does not actually publish a Hosted Feature Layer. Instead, it creates a template, that can be used by others to publish the Hosted Feature Layer as defined by your template, using the same schema, geometry and one would hope, even domains, subtypes, default values and more. The Hosted Feature Layer Template item could also be shared, so that only certain users see it in the Template Gallery under perhaps an "Organization" tab at the bottom beneath "Natural Resouces". To be honest, what would really be fantastic would be to be able to customize all of those industry categories to something that applies to my organization. I really have no use for any of them but if I could customize the dialog with different categories (eg. Tabs), and populate them with templates that apply to each of the categories relevant to my organization, this could become a much more useful capability. ... View more

When Sharing a Webmap or Feature Layer in ArcGIS Pro to Portal for ArcGIS, a user may see the option to "Reference Registered Data". This option is only valid however, if two conditions are met: The data source where the data is currently hosted must actually be registered with the Portal's Hosting Server or another Federated Server. The user must have the 'Publish Server-based Layers' privilege because layers published in this manner are not Hosted Services, but traditional ArcObjects-based services.   In the event either of these conditions are not met, the Pro UI disables the Analyze and Share buttons, preventing the user from publishing the service. THIS BAD UI/UX DESIGN. A GOOD UI/UX DESIGN CONTINUALLY EVALUATES REQUIRED CONDITIONS AND UPDATES THE UI TO GUIDE THE USER TOWARDS THE PROPER SELECTIONS. IT DOESN'T DISABLE BUTTONS FOR NO OBVIOUS REASON WITHOUT EXPLANATION.   Obviously, there is some mechanism detecting that the required conditions to publish the layer are not being met by the user. So why show the 'Reference registered data' option at all? It only serves to confuse and frustrate the user, especially considering that no error message or explanation is given as to why the Analyze and Share buttons are disabled.    ESRI: The user can just click the Info button icon next to the Select a Configuration option to read what each option means.   Fine, but you could also just design the UI/UX to avoid the situation entirely. The mechanism to evaluate the conditions clearly already exists, its just be implemented in the UI in an unintuitive fashion. ... View more

Add additional webhook triggers that are triggered just before an event occurs, allowing Administrator and developers to intercept events occurring on some or all items, to perform validation. Items: Trigger event URI example Before an item is added to the portal /items/beforeAdd Any item is deleted /items/beforeDelete Any item is updated /items/beforeUpdate Any item is moved or it's ownership is changed /items/beforeMove Any item is published /items/beforePublish Any item is shared /items/beforeShare Any item is unshared /items/beforeUnshare The ownership of any item has been reassigned /items/beforeReassign A specific item is deleted /items/<itemID>/beforeDelete A specific item's properties are updated /items/<itemID>/beforeUpdate A specific item's ownership is changed or the item is moved /items/<itemID>/beforeMove A specific item is published /items/<itemID>/beforePublish A specific item is shared /items/<itemID>/beforeShare A specific item is unshared /items/<itemID>/beforeUnshare The ownership of a specific item has been reassigned /items/<itemID>/beforeReassign Obviously, these "before" webhooks should be applied to all existing and future webhooks, including Group, User and Role webhooks. Having pre-event webhooks would be useful for administrators that work in highly regulated industries where we may need to "sniff" out a an item for sensitive information and possibly strip that information, deny the publication or tokenizing that information. ... View more

Add additional webhook triggers that are triggered just before an event occurs, allowing Administrator and developers to intercept events occurring on some or all items, to perform validation. Items: Trigger event URI example Before an item is added to the portal /items/beforeAdd Any item is deleted /items/beforeDelete Any item is updated /items/beforeUpdate Any item is moved or it's ownership is changed /items/beforeMove Any item is published /items/beforePublish Any item is shared /items/beforeShare Any item is unshared /items/beforeUnshare The ownership of any item has been reassigned /items/beforeReassign A specific item is deleted /items/<itemID>/beforeDelete A specific item's properties are updated /items/<itemID>/beforeUpdate A specific item's ownership is changed or the item is moved /items/<itemID>/beforeMove A specific item is published /items/<itemID>/beforePublish A specific item is shared /items/<itemID>/beforeShare A specific item is unshared /items/<itemID>/beforeUnshare The ownership of a specific item has been reassigned /items/<itemID>/beforeReassign Obviously, these "before" webhooks should be applied to all existing and future webhooks, including Group, User and Role webhooks. Having pre-event webhooks would be useful for administrators that work in highly regulated industries where we may need to "sniff" out a an item for sensitive information and possibly strip that information, deny the publication or tokenizing that information. ... View more

ArcGIS Enterprise uses the concept of "Server Roles" to support workload isolation across a multi-machine deployment. Meaning, typically you have your base deployment of Portal, Hosting Server and Datastore on one or more machines. Then, you have additional servers federated with the Portal to enable extended capabilities on your Portal, such as Raster Analytics, Image Hosting, GeoAnalytics, Mission, Business Analyst, etc. These Role Servers exists purely for workload isolation and only perform workloads associated with those roles. For example, only the Business Analyst's Geoenrichment Server will perform GeoEnrichment jobs. Only the Raster Analytics Server will perform Raster Analysis jobs. This makes sense for workload isolation but the problem is that its an incredibly inefficient utilization of hardware resources as those servers sit idle when no members of the Enterprise Deployment those servers are federated with, performing those tasks. When discussing distributed collaboration, Esri likes to use the example of a city with multiple departments, each department having its own dedicated ArcGIS Enterprise deployment and those departments sharing select content with each other through distributed collaboration. For example, the Fire Department might share arson data with the Police Department. The Police Department might share crime data with the Mayor's Office. The Public Works department might share project information with the Police and Fire Department as well as the Mayor's Office. While each city department has its own distinct ArcGIS Enterprise deployment, making them members of different ArcGIS Organizations, the reality is that they are all members of the same organization - the City of Anytown, USA. So what if each of these departments has a need for some specific server role such as GeoAnalytics. Let's say the Fire and Police Department need GeoAnalytics while the Mayor's Office and Public Works department both need Business Analyst. Under the current architecture and licensing pattern, the expectation is that the City of Anytown, USA must purchase those Server Roles repeatedly, once for each organization in order to enable the capabilities across each of the organizations. That. Is. Silly. These Server Roles should be able to federate with multiple ArcGIS Enterprise Deployments and the organizations should be able to split the licenses across those organizations however they want. In thinking about this as I write it, it might not be a federation issue but more of a distributed collaboration issue. I'm not sure which. In any case, the status quo seems unfair. Now, the licensing for many of these servers roles is not that terrible (BA is an exception), so its not a cost play from Esri's perspective but it does cost money to run infrastructure and keep those capabilities available. The established pattern of only being able to federate those servers with a single enterprise deployment results in capacity going unused. ... View more