Can someone help me wrap my head around how I can best utilize ArcGIS Portal?

Question

We recently upgraded our ArcGIS enterprise server to the full ArcGIS Portal environment (data store, web adaptor, server and portal). What I'm struggling with is how best to use Portal. In the past, I have always published feature classes for online maps to AGOL. If those feature classes were updated by field editors, I would periodically manually sync them with the local copy of our data.

As explained to me, the main benefit of Portal is that is allows you to publish your data from your enterprise servers to the portal. You can then add it to a web map, and it syncs immediately. As the field workers make edits, it should update in the enterprise database as well.

That sounds great, but the first part that confuses me is that portal seems to be completely disconnected from ArcGIS Online. We have about 70 users in our AGOL setup, so it will be extremely inconvenient to have to move all of our users from AGOL over to portal. Is there a way to pass services published to portal into AGOL, so that AGOL users can make edits to data in our portal?

The next area I don't understand is how best to manage content published to the portal. Our Enterprise was configured using a single-machine base deployment. The guy that help us set it up told me that he would recommend limiting the number of services published to portal. He said that if too many people started hitting the services at once, and you had a lot of services, it could cause performance problems. How can I figure out how many services I can optimally publish at a time?

Building on that, how best should I publish services? We have around layers on our enterprise database, and of those, it would be helpful to have at least 60 of them published to Portal because they are regularly edited in the field. Should I publish each of those 60 services indidually? Or should I group them into one large service. Or is there an answer somewhere in between there?

Ultimately, my problem is that I can't figure out best to implement portal while respecting our current hardware system specs. I love the features promised by portal, but I want to make sure I implement it in the right way.

ZachBodenner · Answer

Many of my organization's web services are published kind of as "projects." For example, there's a service for monitoring invasive species that has multiple feature classes present (Invasive species, maintained native areas, boot brush stations, etc). These are all present in the authoring ArcPro document, so when you publish them to your server it looks like this:

So now you have multiple editable feature classes in one web service. It helps to bundle a bit of the service load. You can then add all of those layers to one web map, and/or split them up into different web maps depending on need.

For what it's worth, my org has a lot of web services and we don't have much in the way of performance issues, though our Network Admin has been able to add a bit of RAM to our server.

DavidPike · Answer

For making Portal content available to AGOL you may want to read up on https://doc.arcgis.com/en/arcgis-online/administer/understand-collaborations.htm

When it comes to publishing services to Portal you also have the distinction between Feature Services published as Hosted Feature services (static) to the relational data store in Portal or to ArcGIS Server (I guess federated?).  If these are ArcGIS Server services you will need to consider the memory pool utilisation which those services incur. https://enterprise.arcgis.com/en/server/latest/administer/windows/configure-service-instance-settings.htm

If you want services that a real-time with your database or FGDB source then you'll have to consider this instance usage when publishing to the ArcGIS Server.  Common practice is to group the services into multiple features in logical categories for publishing e.g. Demographic layers, Topography, environmental... If you were to publish individual features they would likely swamp your memory resources on the server.