Though it’s been available for years now, distributed collaboration is an unsung feature when it comes to sharing content between ArcGIS Enterprise and other ArcGIS organizations. Maybe you’ve never heard of it. Or maybe you have but you’re not quite sure where to start; there are a lot of details to consider, and the functionality has evolved since its introduction in ArcGIS Enterprise 10.5.
Regardless of your relationship with distributed collaboration, which may be referred to simply as “collaboration” throughout this blog, we will take you through best practices, tips and tricks, and more to ensure you get the most out of distributed collaboration in ArcGIS Enterprise.
Quick Links
Breaking it all down | Collaboration management | Workspace management | Content management | Putting it all together
Breaking it all down
To break down best practices around collaboration, let’s think about it in three different pieces:
- Collaboration management
- Workspace management
- Content management
It may help to think about these three different pieces as nesting dolls.
For your largest nesting doll, you have your collaboration. This is a way to establish a formal relationship of trust between two ArcGIS Enterprise organizations or an ArcGIS Online and ArcGIS Enterprise organization.
Collaborations contain one or more workspaces. A workspace is a conceptual space, joined to a group, that represents a project, an initiative, or another organizing principle. While content isn’t shared directly to a workspace, content is shared to groups that are designated as part of a workspace. Going back to our nesting doll example, you still have your large nesting doll representing collaboration. Within this doll is a medium doll, representing workspaces.
Lastly, within each workspace is your content. These are the actual items shared back and forth between organizations via collaboration. Going back to our nesting doll example, you still have your large nesting doll representing collaboration, your medium doll representing workspaces, and – within that medium doll – is the small doll, representing content.
Your collaboration contains your workspace, which contains your content.
Collaboration management
When configuring a collaboration, it’s important to consider the goals of the collaboration. Which organizations are involved – are they both within your agency or is there cross-collaboration between agencies? Is it ArcGIS Online and ArcGIS Enterprise or an ArcGIS Enterprise and ArcGIS Enterprise? Is this a pattern you’ll have to follow just once or multiple times? This comes down to architecture, which then leads to additional collaboration and workspace considerations.
Architectural considerations
When setting up collaboration between ArcGIS Enterprise deployments, consider who the host should be and who should be the guest. The host initiates the collaboration, defines the workplaces, which guests are invited, how content is shared and access. The guest controls the sync schedule and runs the synchronization jobs as well. This means it’s important to consider the performance impact of being the guest in collaborations with multiple workspaces – those synchronization jobs can add up and, depending on resources available, may impact the performance of your Enterprise deployment.
When setting up a collaboration between ArcGIS Enterprise and ArcGIS Online, ArcGIS Online will always be the host. Do note that ArcGIS Enterprise can only participate in a collaboration with one ArcGIS Online organization – and that is by design. Content can be shared with multiple ArcGIS Online organizations using a combination of distributed and partnered collaborations instead! Share content from the ArcGIS Enterprise to the main ArcGIS Online organization via distributed collaboration first. Then share the content from the main ArcGIS Online organization to other ArcGIS Online organizations via partnered collaboration.
Once the collaboration is set up, it’s necessary to understand if a retention policy is configured correctly for both the host and guest organizations This is important to understand what happens to items sent from or received by the organization when the collaboration or any of its workspaces is deleted and when leaving a collaboration or a workspace.
- Sign in to the host or guest organization as an administrator.
- Browse to Organization > Edit Settings > Collaborations.
- Locate the name of the collaboration you want to edit in the table, click the Action button drop-down arrow, and choose Edit Collaboration.
Security considerations
Collaboration only allows communication over HTTPS and trusted certificates. To ensure secure communication among collaboration participants, each participant must trust the certificate used by the other participants. This means when ArcGIS Enterprise is the collaboration host, it must trust the certificate used on each of the guest participants and each guest participant must trust the certificate used on the collaboration host. If the certificates are not trusted, creating a collaboration will fail. See Configure the portal to trust certificates from your certifying authority for details on how to trust certificates. If ArcGIS Online is the collaboration host, the certificates for the guest participants do not need to be imported.
When collaborating between ArcGIS Enterprise and ArcGIS Online, all communication is initiated by the ArcGIS Enterprise portal. In order to allow this communication, network firewall rules must support outbound communication over port 443.
To allow communication in an ArcGIS Enterprise-to-ArcGIS Enterprise collaboration, guests’ network firewall rules must support outbound communication over port 443. See Restrict cross-domain requests to your portal and work with your IT/Security team on how to restrict cross-domain requests to your ArcGIS Enterprise portal.
When to use just one collaboration or multiple
When setting up an ArcGIS Enterprise to ArcGIS Enterprise collaboration, there comes a point where it’s important to decide if only one collaboration should be used or if multiple makes more sense.
If setting up a single collaboration, adding participants to the same collaboration will grant them access to the workspaces and content – this is great if you’re disseminating the same items to many other organizations.
If setting up multiple collaborations, adding participants to different collaborations will separate their access to the workspaces and content – this is great if you’re wanting to disseminate different items to different organizations. Collaboration configurations are synchronized on the guest every 15 minutes. For example, if the collaboration name is edited or a workspace is added or updated. Increasing the number of collaborations would increase the number of collaboration configuration synchronizations.
Workspace management
Now that you’ve decided how to set up the collaboration itself, the next step is to consider how the workspace, or workspaces, should be set up. It depends on how much content is being shared, the frequency at which the data is edited and how often it’s being synced. It may take a bit of trial and error to find the best fit for your organization.
When to use just one workspace or multiple
Next, it’s time to decide on if only one workspace should be used or if multiple workspaces are needed. A single workspace means adding content to that one workspace will make it easier to manage content shared to that group. You need to share content with one group in order to share it through a collaboration. Multiple workspaces means that there is potential for improved performance and synchronization time: instead of putting the load on one workspace, it is spread across many. More on this in a bit.
Other workspace considerations
For faster workspace scheduled synchronizations, streamline workspaces to include fewer services, which can optimize and reduce synchronization time. Use separate workspaces for different synchronization requirements based on multiple factors, including:
How feature layers need to be shared
Consider setting up separate workspaces for feature layers that need to be shared as references or copies. Consider how the data and updates need to flow across participants. This will help prepare and manage your content more efficiently. Ultimately, this can improve performance as more work is done when trying to share feature layers as copies instead of references or when trying to share feature layers as bidirectional copies instead of one-way copies.
- By reference. Creates an item for collaboration recipients and does not copy the data. The item in the recipient’s organization references back to the original feature layer. To access the referenced layer, members must have access to the original organization, or the layer must be shared with Everyone, or have credentials saved. If the layer is secured, members must authenticate in the original organization as a member who has access to the layer. A common workflow is to share an ArcGIS Enterprise map, feature and image services by reference with another ArcGIS Enterprise organization to collaboratively work on a project. Viewer credentials can be stored in the workspace so that users can easily access the content. See Saving Credentials in Collaboration for more information on this.
- As one-way copies. When layers are shared as copies, the data is copied to the recipient’s organization and a new item is published. The copied item is hosted by the receiving organization, which is indicated by the item’s service URL. For sharing edits one-way, the owner of the original feature layer can edit the layer and synchronize changes to all participants through sync intervals. Guests choose the interval at which edits are synchronized in the collaboration workspace.
- As bidirectional copies – Support for sharing edits two-way was introduced at ArcGIS Enterprise 10.9. Shared feature layers can be edited by both the owner and the receiving collaboration participants. The types of edits supported include adding new features, editing features, or deleting existing features. See Distributed Collaboration with Shared Editing for more information. A popular workflow is to share ArcGIS Enterprise data to ArcGIS Online to support field operations. The content will need to be shared as copies and have two-way editing configured. See Collaborate between ArcGIS Enterprise, ArcGIS Online and ArcGIS Field Maps for more information.
Guest access mode
Setup separate workspaces based on Send, Receive, Send and Receive guess access modes. For example, if an ArcGIS Enterprise feature layer needs to be shared as a read only copy in ArcGIS Online, then use a workspace configured to ‘Send only’ but another workspace will help if another layer in ArcGIS Enterprise needs to be both shared and received with ArcGIS Online.
Sync frequencies
Consider the timing of sync processes. Reduce the scheduled sync frequency if updates are not shared often or pause the scheduled sync if content does not need to be synchronized regularly and can be synchronized on-demand instead. Creating separate workspaces for content that needs to be synchronized at different intervals can improve performance. Lastly, consider when other processes that may be taking place when a collaboration sync is scheduled – for example, whether that is a regular WebGIS DR backup or edits being reconciled and posted. Strive to have the least amount of conflict between ongoing events. It’s worth noting that the minimum sync interval is one hour; this is because collaboration is not intended for real-time edits.
Item size
There is a 1GB size limit to how much data can be sent back and forth per item as copies. If this limit is being reached, consider reducing the content size by creating a view; this can filter out features or field attributes or layers and then share the view instead. If this isn’t an option, another option is to reduce the size by disabling attachments.
Number of items
There is a 5GB size limit for how much content can be shared back and forth per sync. There is also a limit on how long synchronization jobs can run to ensure they don’t go on too long. If either of these limits are hit, this is a sign to consider an additional workspace.
Naming conventions
Name your workspaces and groups using names that are intuitive for you and your colleagues to remember and understand the configuration of that workspace.
Understanding logging in workspaces
With everything set up within your workspace, be sure to take advantage of the messaging and logging to ensure that the collaboration workspace synchronizations are successful, and data is being shared as expected. The simplest way to view the sync status of a collaboration is directly in ArcGIS Online or ArcGIS Enterprise by navigating to Organization > Settings > Collaborations > Collaboration_Name > Workspace_Name > Sync Status.
If workspace synchronizations are unsuccessful, be sure to check the ArcGIS Enterprise portal logs and the ArcGIS Portal directory for more information.
Content management
You have your collaboration set up. You have your workspace, or workspaces, configured. Now it comes down to what content you are sharing via this collaboration. Be sure to note the item types supported, as they can vary between release versions as more are supported.
Thinking about item dependencies
It’s important to consider item dependencies and how they are managed throughout a collaboration. Item IDs are maintained when sharing content and dependencies via collaboration, from the source to the destination. This doesn’t matter if content is shared as copies or as references. As long as the item ID in the source remains unchanged, the destination item ID will match and remain consistent. For example, if you share a web application to a collaboration group, the dependent web map and feature layers will be prompted to be shared too. When configuring web maps and web apps, it is crucial to add the content using the item ID rather than the service URLs. Stand-alone item URLs added directly are not shared and will remain the same on the recipient.
Web applications have their own considerations. Though web mapping applications can be shared with participants in a collaboration, they cannot be edited by the recipient. If the recipient needs to edit the web applications, be sure to share the source feature layers, web maps, etc. From here, the recipient can create their own web application.
Making content changes once a collaboration is set up
Sometimes you may need to make changes to your content that has been shared via collaboration, and that’s okay. But there are some additional factors to think about, as there may be follow up necessary on your side to ensure these changes are made smoothly.
Unsharing and resharing content
If you are unsharing and resharing content, make sure that the item doesn’t exist on the destination environment before you reshare it – otherwise the synchronization may fail. Make sure that all edits are synchronized before you unshare the item from the sending organization or delete the item on the receiving organization.
Item changes
When you share content with collaboration participants, the item information, item metadata and sublayer metadata are also shared. Only the sending organization can make edits to the metadata. Edits made to the item information or metadata are synchronized from the sending organization to the receiving organization.
Data changes
Edits made to feature layer attributes are synchronized based on the workspace configurations. Collaboration uses replication and global IDs to synchronize feature layer edits between participants when shared to a collaboration workspace as copies. Preserving global IDs ensures that any data edits for existing features will be sent as updates rather than new features.
Schema changes
On the back end, feature layers are shared as copies using the principles of replication. If you change the schema of a feature layer or view in either the sending or receiving organization, those changes are not applied when the workspace is synchronized.
Examples of schema changes include adding or deleting fields, adding or deleting layers in a feature layer, and enabling or disabling attachments. The workspace sync includes only edits to layers or tables that were available at the time the feature layer was shared to the workspace. When there are schema differences, sync applies edits to the matching parts of the schema. For example, if a field is added in the sending organization, the new field is ignored when edits are applied during sync to the receiving organization’s copy. To send schema changes to receiving organizations, unshare and reshare the layer to the workspace.
Managing replicas
Synchronization of edits by collaboration participants utilizes replicas to identify which feature layer must be synchronized. Due to various reasons, such as multiple synchronizations between collaboration workspaces, stale replicas may be created. A stale replica is a replica that has not been synchronized in the last 30 days. These unused replicas consume disk space unnecessarily and cause performance issues. Portal checks for stale replicas and logs this information. See Delete unused replicas from a distributed collaboration in Portal for ArcGIS for more information.
Putting it all together
Now that we’ve broken down distributed collaborations into collaborations, workspaces, and content, you’re set to try creating collaborations of your own. We hope that thinking about these considerations makes distributed collaboration successful – for both you and your colleagues.
Article Discussion: