roemhildtg

Thoughts on Federation of ArcGIS Server/Portal

Blog Post created by roemhildtg on Apr 17, 2018

We recently decided to federate our portal with our server in order to start publishing layers from Pro. So we began this process. Type in your url to your server in portal, and click Add. Simple, right?

 

Sure, it looks simple, and when it works, it probably is. But this was not my experience, and along the way I've learned a bit about what can be done when the transition isn't this smooth.

 

Web Adapters

Before federating, it is important to note that web adapters should be configured properly first. Otherwise this will lead to a ton of redirect issues where you can't log in to Manager, rest pages, etc and lots of other headaches. First, you should have two web adapters: one for server, one for portal. They should be configured so that the web adapter URL is the external domain name, not the internal server name. For instance if you want to hit your server from www.example.com/arcgis, that is the URL you should have configured in your adapter. To do this, you actually need to log in to the server hosting web adapter. Then open your web browser, and go to the URL that you want your web adapter url to be. In this example, you would type in www.example.com/arcgis/webadaptor

 

Always use the full domain name when you register your server also. So in web adapter, when it asks you for your internal Server URL you should use https://my-server.internal-domain.com:6443 Alternatively, other users have reported that an internal ip address will work.

 

URLS

If you had accessed ArcGIS server before through its internal server network name you might have to change the address you regularly type in to a web browser.

 

For instance, I had always accessed my server's manager from http://server-name:6080/arcgis/manager.

 

To work with portal now, I use https://server-name.internal-domain.org:6443/arcgis/manager.

 

Services

The next thing to worry about is actually publishing services with Pro.Once federated, ArcGIS Portal will add all the services it finds in Server to your content. It turns out, services originally published with ArcMap cannot be overwritten by Pro. They must be completely removed (both from portal and server) before being published. To do this properly, I've found this specific order to work well:

 

  1. Delete service in Portal. Delete Feature Services and WMS, etc. and anything with the same name as that service.
  2. Navigate to ArcGIS Server Manager (or ArcGIS Server Admin backend)
  3. Delete the service from ArcGIS Server. Sometimes this won't work and an error will occur. A reboot of ArcGIS Server should fix this.
  4. Open the map document in ArcGIS Pro
  5. Go to Share -> Web Layer -> Publish Web Layer (Don't choose "Overwrite Web Layer")
  6. If you want to publish the layer to a folder in Server, type in the name like this: folder_name\service_name
  7. Analyze -> Publish to publish the service.

 

You'll have to repeat these steps the first time you publish each service from Pro. But once they are published, you can use the Web Layer -> Overwrite Web Layer instead of having to use the delete, publish from scratch method.

 

Other publishing notes:

  • With Pro/Portal publishing and diagnosing publishing issues becomes much more difficult. Instead of giving an error message if there's an issue with a layer, Pro will give you "Staging failed" errors. Not very helpful
  • Publishing from Pro -> Portal -> Server seems to take much longer. Not sure why, but a service that used to take about 30 seconds to publish in ArcMap now takes around 2 minutes or more in Pro.
  • All the same issues that occurred with ArcMap publishing are still issues...those little things you had to watch out for are still there but are now more difficult to find since you have to log into your server logs in order to find the error, which is often something cryptic like "Base table string is invalid"

 

Authentication

After federating, you immediately lose access to ArcGIS Server's internal user store. Instead, ArcGIS Server will now use usernames/passwords and tokens from ArcGIS Portal's user store. This simply means that any services you have protected and not set to public will need to be changed a bit to the new authentication scheme.

 

In ArcGIS Server, manager will now require Portal usernames/passwords as well. Or, if you can't access manager, due to some issue with web adapter (as noted above) you can manually generate a Portal Token and log in to the Server Admin pages using that token. You can generate a token for Server Admin by following these steps:

 

  1. Navigate to your portal token url: https://domain.com/portal/sharing/rest/generateToken
  2. Type in your portal username/password and the web app url for your arcgis admin url https://internal-servername:6443/arcgis/admin 
  3. Copy that token and paste it into the login form at https://internal-servername:6443/arcgis/admin/ 
  4. Login to ArcGIS Server Admin using your portal username and password

 

In the JS API, apps that use tokens will have to be changed so they are fetching tokens from ArcGIS Portal. A node js example would look like this:

const axios = require('axios');
const querystring = require('querystring');

class Service {
  constructor (options) {
    this.options = options || {};
  }

  find (params) {
    const arcgis = this.options.arcgis;
    const {expiration, username, password, referer} = arcgis;

    // auth data
    const data = {
      f: 'json',
      client: 'referer',
      referer,
      request: 'getToken',
      expiration, // 60 minutes
      username,
      password
    };

    // token url
    const url = arcgis.tokenUrl;

    // some headers for passing form data
    const headers = {
      'Content-Type': 'application/x-www-form-urlencoded',
      'Accept': 'application/json'
    };

    return axios.post(url, querystring.stringify(data), {
      headers
    }).then(portalTokenResult => {
      Object.assign(portalTokenResult.data, {
        server: arcgis.portalUrl + '/sharing/rest',
        userId: arcgis.username,
        scope: 'portal'
      });

      return [portalTokenResult.data];
    });
  }
}

 

When serialized, the response of this service will return something like this:

[{
    token: "<token>",
    expires: 1524001549062,
    ssl: true,
    server: "https://domain.com/portal/sharing/rest",
    userId: "username",
    scope: "portal"
}]

 

And can be used in the api like this:

esriConfig.request.corsEnabledServers.push('domain.com');
ajax('domain.com/arcgis-token').then(tokens => {
    tokens.forEach(token => {
        IdentityManger.registerToken(token);
    });
});

 

Additional Notes:

  • Always refresh ArcGIS Pro Browse Dialog when overwriting layers. This dialog doesn't automatically refresh and you might accidentally cause some issues, like publishing a new layer, rather than overwriting the existing layer.
  • You can't specify options about the service, like number of instances, pooling, etc when you publish to pro. The default options will automatically create 2 process instances of each service so if you want to update this, you'll need to configure this in ArcGIS Server manager. 

Outcomes