Content within Distributed Collaboration Group does not load from outside Local Network

[PaulMcCord]

I've set up Distributed Collaboration between my organization's installation of ArcGIS Enterprise 10.7.1 and ArcGIS Online. My goal is to have the content on Portal for ArcGIS that is shared to the Distributed Collaboration workspace viewable to the public. This would primarily be web apps that reside on our internal servers but that we want the general public to be able to view. 

I believe the Distributed Collaboration configuration is set up correctly. In other words, if I share content from Portal to the Distributed Collaboration group, then I see that content in the appropriate folder on ArcGIS Online. I can click on an application, for example, and it displays with no issues.

My issue, however, is that when I'm not on my organization's network and I go to, for example, the same link to my application within the Distributed Collaboration folder, then I get the following error: "Unable to create map: Cannot read property 'spatialReference' of undefined." I've also attached a screenshot of the error. Again this only occurs if I'm not on my organization's network.

The layers that are on the web map within the application that is not displaying were published from ArcGIS Pro to ArcGIS Server. We've federated Server with Portal, and everything seems to be behaving appropriately in both programs.

Is this issue related to our configuration of Enterprise and/or our Distributed Collaboration, or is this something related to my organization's network settings.

Any assistance would be greatly appreciated. Thank you.

[JonathanQuinn]

What types of services are you adding to your map? If they're non-hosted services, I think they're copied by-reference, meaning the URLs will stay the same, (https://internal.domain.com/server/rest/services... for example), but the map and app would be moved to ArcGIS Online. If they're hosted services, the data can be copied to ArcGIS Online and the service will be created in ArcGIS Online. The new URL will be used in the webmap instead of the internal one.

[PaulMcCord]

Thanks for your response Jonathan. The map is displaying a Map Image Layer with three Feature Layers. The Map Image Layer and the Web Map that it's loaded to are shared with Everyone (public). The data were published to our ArcGIS Server from Pro by referencing data in a registered folder (in other words, when I publish from Pro, I'm pointing to a registered location). However, I set up our Distributed Collaboration so that Feature Layers would be sent by reference and not copied. Is this the reason why I'm getting the error?

I can change it so that Feature Layers will be copied, but my understanding is that this would then consume service credits since a copy of the data would be placed on AGO rather than on our own internal servers. Is that true? 

[AdrienLepoutre]

Hi Jonathan,

I've been researching one thing that you mention and wanted to ask you about it.

I've been trying to figure out if a specific setup is possible. I would like to know if it is possible to have a feature layer, initially published by reference (pointed to a map image layer by reference) to then be collaborated as a copy to leverage the hosting capability and keep it in sync.

When I tried setting up the workspace for the collaboration, you get the following option:

That being said, there seems to be a conditional aspect added to the selection - from what I would understand from the text below, on a layer by reference, since there is no "Enable Sync" option in the settings, then a layer initially published by reference is not become a copy in AGOL but will still point to the intial map image layer - thus not leveraging the hosted/sync capabilities?

 You seem to imply that if they were published by reference initially then when collaborated to AGOL, the URLs will still point to the original layer by reference (even if copies is selected in setting up the workspace) ?

Thanks,

Adrien

[Anonymous User]

Hi Adrien,

The setting you have a screenshot of there is for feature layers only and does not apply to map image layers. Feature layers can be copied as long as they are sync-enabled - this is possible for both hosted feature layers and referenced feature layers.

Map image layers (map services) can only be shared by reference using collaboration - this will create an item in fellow collaborators' environments but point back to the original service.

So I think to answer your question: it is possible to copy your feature layer published by reference so long as it supports sync and you have chosen to send it as a copy through collaboration.

[AdrienLepoutre]

Thanks Hilary. I managed to get the copies to work with feature layers. It's unfortunate that this setup can only work with enterprise databases and not file geodatabases.

Thanks,

Adrien

[BPriyaK]

Hello @Paul McCord and @Jonathan Quinn

Im trying to accomplish the same thing  outlined in the question  , I setup a collaboration between our ArcGIS Online organization and Portal for ArcGIS 10.6.1 (not public) and encountering issues with accessing content shared to our ArcGIS online organization via collaboration outside our organizations network.

The items shared to the group appear in our ArcGIS Online page as collobaration items but when you access the application, it says that the layers in the web map could not be loaded.

All our map services (map image layers) /and map services with feature access (feature layers ) are published from our enterprise sde as reference.

The collaboration workspace is setup as reference.

Would I have to change this copies ? 

How would it work if it were copies for map services (map image layers) vs feature layers.

Any help on how guys configured it for your organizations would be really helpful !!

Thank you

Bhanu

[MarcBateEA]

Is work being done to copy all of the mapimage server layers or scene service layers over to the collaboration, or with the cloning tools of the python API?  It seems like more things are being added and just want to know to inform our team.