Can a GXW web app be copied/synced from one ArcGIS Enterprise portal to another using distributed collaboration?
Hi community.
I am trying to understand the ability for a GXW site hosted in ArcGIS Enterprise (10.8.1) to participate in a distributed collaboration with another ArcGIS Enterprise portal. For quick context, please refer to my post on GeoNet: https://community.esri.com/t5/aec-architecture-engineering-and/geocortex-related-project-delivery-collaboration-concerns/m-p/1019545#M387
What I understand so far:
- Given the GXW site and associated webmaps/scenes/feature layers will be secured (not shared to Everyone), referencing from a guest portal to a host portal won't work without a login in each portal. From an Esri licensing and security perspective, this isn't an option for us. Therefore, copying/syncing of content from the host portal to the guest portal is required. I am happy to be proven wrong here.
- Esri templated apps (web app builder, storymaps, etc.) and associated content are able to be copied and synced, with all content references changing in the process so they will still work in the guest portal.
Is there the ability to achieve the same with GXW sites?
What would need to occur for the same GXW site to work across two or more collaborated portals?
- Webmaps and scenes should copy/sync across the collaboration and work
- GXW web app files should be able to copy/sync across to another portal, but I assume references to participating webmaps and scenes would need to be updated in the GXW config files. Could this be scripted and sent to the guest portal using the ArcGIS API? (e.g. find and replace text, then post). I assume a similar process is undertaken during the staged deployment process of GXW sites.
I'm keen to understand what is right and wrong from the above, or if there are any other suggested solutions to make this work.
Are there plans for VertiGIS to support this collaboration pattern if it's not currently possible?
Thanks,
Leon.
-
Hi Leon,
Some fantastic questions.
You are correct, the logic that does application management between dev - test- staging - prod handles updating references to newly created items (and also has environment variables that allows you to do search/replace on content between environments for situations where you want to point to completely different underlying map services as an example).
Reading through your GeoNet post, it seems like you could likely use ArcGIS Enterprise Portal groups to solve most of your issues.
Here is what I'm thinking.
Do a standard dev - test - prod flow for your GXW app (that handles making copies of all associated app items).
Once you hit prod, use the Sharing Permissions feature in GXW Designer to assign access the the Prod app and its dependencies to an Enterprise Portal Group.
Anyone within that Enterprise Portal group would then have access to that production app and all of its dependent items (e.g. workflows, reports, etc.) without having access to anything else and without having access to the dev or test versions.
Is that pretty close to what you are trying to achieve?
0 -
Thanks for getting back to me Cam.
I have been looking at the ability for the tiered workflow to assist us with solving this issue also. The primary issue we have is for members of another portal to access our GXW app, which is accessing the secured content in our portal, without having to have logins to both.
I've posted a potential architecture diagram below that hopefully illustrates a solution.
In this diagram, our ArcGIS Enterprise is on the left and an AEC Project Delivery System ArcGIS Enterprise is on the right. AEC PDS is there so that users who are not from our organisation (who due to Esri licensing, we legally cannot invite into it - e.g. our client) can access our shared content. The right ArcGIS Enterprise could be any ArcGIS Enterprise, it doesn't have to be AEC PDS in this example.Because those users are in another portal, we need to use a collaboration group to sync and copy our secured content to their portal. I don't believe it is possible for us to reference our content, as the users would need logins to both portals for that to work (secured content remember). During the sync and copy process, any feature layers, web maps and web scenes would get new item IDs. My understanding, is that Esri templated apps can cope with these changes and will "re-reference" themselves as part of the collaboration process. I think a GXW app could participate in a collaboration group and be copied across also, but I don't think the underlying linkages to content will "re-reference". Is that true?
Also, from a Geocortex licensing perspective, my understanding is that we are only licensed for a single production ArcGIS Enterprise deployment up to a number of cores. Even if I was to copy a GXW app to another portal, it wouldn't be licensed to run anyway - it would be running against a completely separate portal with its own cores, above what we're licensed for.
So to get around these assumptions... (I am really trying to find out if these assumptions are true). My plan is to use Enterprise to Enterprise collaboration groups to sync and copy the underlying content that GXW references (see red dotted boxes). As you know, the Dev > Test > Staging > Prod workflow creates copies of web maps and web scenes in our portal, and we can change any variables in that process. What I'm thinking, is to use the Staging version of the app as the "external" access app, rather than Prod, which will be used by our own people. To do that, we would:
- Include the Staging web map and web scene in the collaboration group (gets copied to the other portal and receives a new Item ID)
- Update the references in the Staging GXW app to point to the new web map and web scene Item IDs in the external portal
- Revert the references in the Prod GXW app to point to our internal Prod web map and web scene
- Set sharing on the Staging GXW app (still in our portal) to Everyone (public).
In this way, I believe a user from the external ArcGIS Enterprise will be able to use the Staging GXW app in our portal as their entry point, with content coming from their own portal (which they're already authenticated against). Any member of the public who tries to use the publicly shared Staging GXW app will get an Access Denied error.
Thoughts?
I haven't even started to look at Reporting, Printing or Workflow yet. To be honest, that adds a level of complexity I'm not ready to contemplate yet!
Many thanks,
Leon.
0 -
Hi Leon,
Let me start by helping you validate your assumptions:
"I don't believe it is possible for us to reference our content, as the users would need logins to both portals for that to work (secured content remember)."
Agreed. I think you are thinking about this correctly.
"I think a GXW app could participate in a collaboration group and be copied across also, but I don't think the underlying linkages to content will "re-reference". Is that true?"
True. I don't think Esri's tricks would work on a GXW app and it's dependencies.
I can't say with 100% certainty if your idea/proposal would work, but it has at least a chance of success. If anything was going to burn you, it would be that by loading the public staging app at portal XYZ, Geocortex Web may make assumptions that the webmaps it is looking for are in the same Portal (not saying for sure, but might be an issue).
Ultimately what you need is someting we've started looking at but are hesitant to tackle (because it is complex and difficult) ... allowing the d-t-p application management to work across portals natively (i.e. you could specify a different portal for your production app).
There are a number of stakeholders who would benefit from this if we could pull it off. The biggest obstacle is the limited set of tools Esri gives us for handling multiple Esri identity tokens simultaneously. (i.e. in many cases Esri is also making assumptions that if you are authenticated, then everything you are looking for must use that same token).
@Michael Heavenor? ... an interesting use case with a fair bit of detail here for our ongoing d-t-p across Portals conversations.
0 -
Thanks Cam.
I like the thought of deploying across multiple portals, though agree that the challenge will be authenticating against them with a single Esri identity.
I think you've given me enough confidence to start trialing the approach above. Will come back with some results soon.
0 -
Hi Cam,
are you able to comment on my above assumption regarding licensing?
"Also, from a Geocortex licensing perspective, my understanding is that we are only licensed for a single production ArcGIS Enterprise deployment up to a number of cores. Even if I was to copy a GXW app to another portal, it wouldn't be licensed to run anyway - it would be running against a completely separate portal with its own cores, above what we're licensed for."
Can you please confirm that I cannot send a GXW application to another portal via collaboration and have that item run there, accessed by that portal's users? I'm thinking primarily of our third party users, but assume that would also restrict sending a GXW app from our ArcGIS Enterprise to our own AGOL environment.
If that is the case, is there the requirement for a separate Geocortex license per portal?
Thanks,
Leon.
0 -
Hi Leon - please double-check with your account manager. In general we have a tierd pricing model based on the "magnitude" of your GIS infrastructure. The magnitude is determined by considering both your active ArcGIS identities, and the number of production ArcGIS server cores. We've tried to simplify this as much as possible so we are generally focused only on production cores.
0
Please sign in to leave a comment.
Comments
6 comments