I'm testing setting up a Distributed Collaboration with a consultant organisation. They are the host, as they have AGOL, and we are a guest as we have Portal. We set up the collaboration so that the Guest receives content only. The Host tested adding a csv file to the collaboration group and I was able to download it from the Guest group with no issues. However, when they added a Hosted Feature Service to the group (empty, shared only to the group), I (as the guest) am prompted to log into ArcGIS Online in order to access the item: A quick check on the ESR workflow and I found this section on Copy vs Reference: https://doc.arcgis.com/en/arcgis-online/administer/create-a-collaboration.htm Choose one of the following to specify how hosted feature layers will be sent to the collaboration workspace: * References—Collaboration participants will receive live access to feature layers. If the item is secured (not shared with everyone), users must sign in to the origin environment to access the item. * Copies—Collaboration participants will receive a copy of the feature layer, and updates from the origin will be synchronized at a scheduled interval defined by the guest.Note: If you choose this option, the collaboration guest must set a sync interval in the collaboration workspace, and sync must be enabled on each item in the collaboration. A copy of the feature layer and its data will be extracted and published as an item in each recipient's environment. Once the item has been created, subsequent synchronizations will only sync updates of that item. Am I missing something here? Or is this red text essentially telling me that Guests can't access Host content as References unless they have login credentials for the Host organisation or if the layer has Public access enabled? If so, what on earth is the point in Distributed Collaborations?? Furthermore, if the only option that works is to set layers as Copies rather than References, then we'll be duplicating the data and increasing the load on our Portal, negating the benefit of the Collaboration in the first place. If I wanted to copy data, then I could just use AGOL Assistant. Surely I'm missing a key point here?

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

Portal to AGOL Distributed Collaboration asking for AGOL sign in.

David_Brooks

I'm testing setting up a Distributed Collaboration with a consultant organisation. They are the host, as they have AGOL, and we are a guest as we have Portal.

We set up the collaboration so that the Guest receives content only. The Host tested adding a csv file to the collaboration group and I was able to download it from the Guest group with no issues.

However, when they added a Hosted Feature Service to the group (empty, shared only to the group), I (as the guest) am prompted to log into ArcGIS Online in order to access the item:

A quick check on the ESR workflow and I found this section on Copy vs Reference:

https://doc.arcgis.com/en/arcgis-online/administer/create-a-collaboration.htm

Choose one of the following to specify how hosted feature layers will be sent to the collaboration workspace:

References—Collaboration participants will receive live access to feature layers. If the item is secured (not shared with everyone), users must sign in to the origin environment to access the item.
Copies—Collaboration participants will receive a copy of the feature layer, and updates from the origin will be synchronized at a scheduled interval defined by the guest.
Note:
If you choose this option, the collaboration guest must set a sync interval in the collaboration workspace, and sync must be enabled on each item in the collaboration. A copy of the feature layer and its data will be extracted and published as an item in each recipient's environment. Once the item has been created, subsequent synchronizations will only sync updates of that item.

Am I missing something here? Or is this red text essentially telling me that Guests can't access Host content as References unless they have login credentials for the Host organisation or if the layer has Public access enabled? If so, what on earth is the point in Distributed Collaborations??

Furthermore, if the only option that works is to set layers as Copies rather than References, then we'll be duplicating the data and increasing the load on our Portal, negating the benefit of the Collaboration in the first place. If I wanted to copy data, then I could just use AGOL Assistant.

Surely I'm missing a key point here?

Trouver plus de publications taguées avec

Accepted answers

All comments

ZacharyHart

If so, what on earth is the point in Distributed Collaborations??

@David_BrooksI kid you not I am in the middle of writing a nearly exact post to Geonet in this very same forum right now. You're summarizing all my concerns exactly.

After much research (and for various reason) our organization needs to implement a AGO-Enterprise hybrid environment (for our organization only). After creating the collaboration I too discovered that trying to access a referenced service layer from AGO would prompt for our Enterprise authentication as well. Note, this isn't just for HFLs or referenced (eGDB) feature layers; this happens for simple map image layer as well.

Now, in our case, we could configure SSO on both sites for our users, but that would mean you'd need to have the user assigned to both AGO & Enterprise (2 licenses for each user). Am I missing something here?

Right now I've lost site of what the benefits of the collaboration are if this cannot be resolved. Why wouldn't I just manually add content to AGO from URLs from our Enterprise site and just embed/store the credentials in the item?

David_Brooks

@ZacharyHart exactly!

We were looking at this as a way of collaborating with many consultant organisations, who all have AGOL and want to share their content with us for QA/QC. Since posting the above, I have now discovered that a Portal can only have one collaboration with an AGOL Org

As far as I can tell, this isn't documented anywhere...

...So it would seem that my best alternative would be to give all QA/QC users AGOL Viewer accounts, and then ask the consultant organisations to add these viewers to their AGOL Groups. Not really what we had in mind.

I did wander if it was possible to have an AGOL organisation as a Host, which we use with partnered collaborations with our consultants, and then access the Partnered Collab layers via the distributed collaboration on our Portal, but I highly doubt this would work.

ZacharyHart

While our use cases are different, we definitely have overlapping concerns, so i proceeded to start another thread for visibility.

ZacharyHart

@David_Brooks

Relevant I'd say:

https://www.esri.com/arcgis-blog/products/arcgis-enterprise/sharing-collaboration/whats-new-in-arcgis-enterprise-10-8-1-saving-credentials-in-collaboration/

DavidColey

Hello -

I have 17 collaborations set up between our Enterprise portal (guest) and our ArcGIS Online org (host)., for about 7 yeas now. All of the collaborations are by reference. As a county government, we have to provide data, and so for us, this means I can manage all of our layers in Enterprise and then send them to our ArcGIS Online org in the collaborations' groups, where those groups are part of our Hub / Open Data site.

All of the layers that participate in the Open Data site are shared publicly in Enterprise, and the share level of the ArcGIS Online, by-reference version of the layer is also public, as are the AGOL groups that participate in the Open Data site. In this way, no login prompts are ever displayed. We protect the Enterprise by not allowing anonymous access, and by disabling the Hosting site REST directory.

We chose not to collaborate webmaps (for say basemaps) but just the layers to make the basemap for the AGOL side. Nor do we have any Enterprise Configurable or Instant Apps that participate. We DO have Enterprise-registered, WAB developer-edition apps and Enterprise-registered, JavaScript api apps that do participate in a collaboration.

I also have a collaboration where I am sending content from our Org to the Enterprise. If the Org layer is public, then no login prompt is asked for the Enterprise user, but you have to be signed into the Enterprise. If I don't want the Org layer shared with the public, then yes - the Enterprise user will have to provide their AGOL login. All of this by design.

More: the reason we use by-reference collaborations is due to how we manage data to keep it updated for the public: GIS staff update layers in an SDE traditional version space, we extract to file gdb via python and upload/overwrite SD-generated hosted layers via the arcpy sharing module.

We don't use the as-copies model because the as-copies model requires that the hosted layer have editing and sync enabled (as shown earlier) but that means the hosted layer is never over-written. Should you want to use the as-copies model, then you are then instead setting up a workflow where the hosted layer is the edit layer, and edits are synced at maybe a shorter interval.

Point is, we and I went through all of this pain to make this work precisely because we no longer wanted to use the add-item, stored credential method for several hundred layers. And although the arcgis api will let you script doing that (now, but not when we started this) you are still adding performance overhead as the layer has to go through the ArcGIS Online proxy to read those stored credentials every time the layer is accessed.

Hope this helps.

David_Brooks

@DavidColey ah that sounds like you're using collaborations to excellent effect. Unfortunately for us, all our services have strict group sharing, so it's rendered the whole endeavour obsolete.

Im now wandering, if we have a single user AGOL org that could act as a host, whether we could use that to create Partnered Collaborations, and then consume the services that way

DavidColey

Yes hello @David_Brooks - I don't know how that would help you, unless you don't belong to an existing agol org. Because even in a partnered collab there will still be sign-in prompts for layers depending on their share level, whether as-copies or by-reference. It really comes down to workflows and trust.

One thing you could do would be to have the agol org host that you are working with add you and members of your team to their agol org (without using up their seats as long you have an agol org) - i.e they add you to their agol org using your orgs agol credentials.

That way, when you get the prompt, you login using your own agol credentials.

Another thing you could explore: If the collab is a send and receive workflow you could try setting up the participating group or groups as shared update groups.

ODWC_GIS

@David_Brooks & @ZacharyHart

My agency's GIS Shop was recently told to use Distributed Collaborations to share information between the two: specifically for the sharing of Survey123 datasets created in AGO to be imported into our already-existing Enterprise deployment.

We had always published from Enterprise to Portal, taken the Portal Item and added it to AGO and attached our Credentials, such that users in AGO could add/update information to be kept internally. But recent "advancements" means that methodology has become untenable as we try to keep up.

So, we set up our Distributed Collaboration...

Y'know, your Post and this series of Replies has been the single most useful resource I've found after scouring every nook of the ESRI sites I've been able.

Slightly over 3 years since you posted your plea, and the Distributed Collaboration still doesn't function as advertised.

My colleague is going to contact ESRI to ask about some of our more depressing realizations, but I will not be optimistic this time.

ESRI Tech: "Oh, yeah. The system can do that easy!"
Reality: The system could not do that.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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