New cross-portal d-t-p application management capabilities for Web and Mobile

With the release of Web and Mobile 5.15 the application management functionality for deploying and updating applications from development through testing, staging, and production now includes the ability to work across multiple Esri portals. Previously this functionality was limited use within a single Esri portal.

Primary use cases include scenarios such as:

• Developing your application within your on-prem Esri portal and then deploying the production version to your ArcGIS Online organization.
• Developing your application within your development on-prem Esri portal, deploying the testing version of your application to a testing on-prem Esri portal, and finally deploying the production version of your application to a production on-prem Esri portal.

Many additional scenarios were tested including some less likely scenarios such as deploying applications between ArcGIS Online organizations or developing in ArcGIS Online and deploying to an on-prem Esri portal.

For simplicity, the rest of this post refers only to development and production, the same information applies to testing and staging environments.

Here are some important things to be aware of as you venture into cross-portal application management.

First, more thought and planning are required for where your map data lives.

When an application is first deployed from development to production, copies of portal items are created for webmaps, web scenes, application configuration, workflows, print templates, and reports. Subsequent deployments from development to production updates the existing portal items, ensuring that portal item IDs and URLs remain consistent.

The map data referenced by your portal items is not copied or updated by application management. Map data can refer to hosted layers, hosted tables, hosted mmpks, or hosted (v)tpk packages.

Application management includes the ability to set environment values to search and replace item content when moving between environments. This is most often used when an organization uses different map services in development and production and needs to update service URLs within their webmap.

Applying this information, you must consider:

• If you are hosting your map data in an ArcGIS GIS Server environment and your webmaps consume the same data from development through production; you shouldn’t have any problems.
  • You may be using environment values to change the URLs of map services your webmaps reference between development and production.
• If you are hosting some of your map data directly in ArcGIS Enterprise Portal, you need to consider how an application in another Esri portal or ArcGIS Online will access it.
  • You may need to copy or re-publish your data into both the development and production portal to ensure access.
    • Environment values will be required to update the URLs or map services your webmaps reference between development and production. The IDs of your data will not be the same between your portals.
  • If the data is shared to the organization, your end-users running the application from other Esri portals will be prompted directly for access credentials to view the map data hosted in another portal. There are known issues where when logged into one ArcGIS Online account end users will not be correctly prompted for access to the second ArcGIS Online organization.
  • If the data is shared publicly, end-user access is straightforward.

Bonus - similar to map data, some customer using the Visibility Filtering features to show and hide tools or UI elements in Web have noted that even when similar groups exist in different portal environments they have different IDs behind the scenes. This means to make your visibility filtering work across portals you will need to use environment values to map the IDs as they will not be the same in source and destination. 

Second, the only credentials Designer has immediate access to are those you used to sign into your development environment with. This means that each new session that involves deploying application between portals will require signing in to each Esri portal with valid credentials.

Third, depending on what capabilities you are using, you may need to supply URLs for Workflow, Reporting, and Printing as part of your application management configuration in addition to supplying your viewer location, your Esri portal URL, and the App ID for OAuth for that portal.

Fourth, if your application is using reports or prints and you would like to deploy cross portal you must ensure your reporting and print service is current. These products were updated to support cross-portal application management (Reporting 5.14, Printing 5.12). If only deploying to the portal you used to sign into Designer then this is not a requirement.