Say, for example we want to run some GIS automation against secured portal content that gets executed by a headless server, i.e., a non-human being.
TIA
Great question! The robot is owned by our organization. It does administration tasks, it does publishing tasks, it does user tasks. We could call him "Tyler Durden", but at the end of the day he's just a scheduled task...
Hi Dirk - who owns the robot? This might be a useful perspective to take when considering the Portal terms of use. For argument's sake, let's say you own the robot. My current understanding is that one human being is allowed to have more than one named Portal user account, and in fact Esri benefits financially from this condition. You may be able to delegate one of your named user accounts to your robot. Definitely talk to your Esri rep about it...
Thank you for the reply, Derek. we do intend to contact our account manager.
For the sake of disclosure and clarity, I’d like to add some backstory to my question.
For starters, all our published GIS content is secure - this is our prime directive. We get do decide how to secure it and we have chosen ADFS.
Before Portal for ArcGIS (PFA), ArcGIS Server (AGS) instances were licensed per-core. Our license level allowed unlimited users to consume our GIS content and for us to publish as many GIS services as our hardware could handle. The problem was that it was only GIS services that were published - this pattern forced us to write complex APIs to consume the ArcGIS services and serve them as web applications with rich functionality. Our end users enjoyed secure GIS content, a rich user experience, and our organization was not constrained by fixed number of users. Additionally, our offerings included some significant GIS automation - the sorts of things we used to do with ArcPy and an AGE or AGD license we could instead do with the ArcGIS Rest API, our licensed AGS instance, and scheduled tasks.
Along came ArcGIS Online (AGOL) and PFA and with it came the concept of a web map - i.e., a collection of GIS services (maps, mostly) with rich function functionality embedded in the map that could be consumed by a much simpler API. Because it is easier to design and configure web maps, it’s possible to publish more of them more efficiently. And because the ArcGIS Rest API is still available, our GIS automation doesn’t have to change.
Unless we’re constrained by a fixed number of named users who are real, live persons in our organization…
The bottom line for us is PFA has the potential to make us more efficient at doing awesome ArcGIS things. However, the named-user pattern is potentially a deal-breaker. Our end users don’t care about the portal, they only want the secured web map content presented in our APIs. We have to weight that against the efficiencies that web maps give us.
At the end of the day, our organization has only a few true “named users” (i.e., “content publishers) who really need everything PFA has to offer. We also have a robot who only needs the AGS Rest API. And several hundred “unnamed users” who only consume web map content served into our applications and nothing more regarding the PFA.
It seems to me that the PFA governance pattern does not support our organizational profile. We recognize that our organization is a statistical outlier, yet at the same time I can’t believe that we are the only organization that is struggling with what PFA means to them.
Cheers!
Hi Dirk,
Yes, a named user account is designed and meant to be assigned to a real, live person in your organization. Regarding your specific need, please contact your local Esri account manager/Distributor to discuss the requirement in more detail.
Hope this helps,
Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.