/allDatasets/publishLayers: Publish Layers

Example usage

The following is a sample ArcGIS Enterprise POST request for the publishLayers operation, which demonstrates performing an initial bulk publish:

1
2
3
4
5
6
POST /webadaptor/sharing/rest/portals/0123456789ABCDEF/datastores/allDatasets/publishLayers HTTP/1.1
Host: machine.domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []

datastoreId=55d87f404a7e420bb969ccb70254bfec&templateSvcConfig={"type":"MapServer","capabilities":"Map,Query,Data","properties":{"datesInUnknownTimeZone":false,"dateFieldsTimezoneID":"Pacific Standard Time","dateFieldsRespectsDayLightSavingTime":true},"extensions": [{"typeName": "FeatureServer","capabilities":"Query","enabled":"true","properties":{"maxRecordCount":"4000"}}]}&portalFolderId=f26efae67a7644499d43a6251e7df613&serverId=9sQswqEpB31ymiCD&serverFolder=TestFolder&f=pjson

Description

The publishLayers operation publishes one map layer item and one feature layer item for each accessible dataset (tables and feature classes) from a database data store item.

When this operation is first called, it performs an initial bulk publish, which produces layers that reflect the database's current datasets. However, if the database is updated, or if changes need to be made to the template service configuration, additional calls to the publishLayers operation will synchronize all published layers. For more information on performing an initial bulk publish or synchronizing published layers, see the Initial bulk publishing and Synchronization sections below.

Bulk published layers are only accessible to the user who published them. However, the user (or organization administrator) can choose to share these layers within the organization or with the public.

Additional considerations

The following information should be taken into consideration before performing the publishLayers operation:

• Only the owner of the data store item can perform the publishLayers operation.
• The data store item owner must be assigned a role that includes the Publish server-based layers and Create feature layers in bulk from a data store privileges to perform bulk publishing.
• Bulk publishing from a cloud data warehouse is not supported.
• Data is published using default renderers and scales.
• Map services on the federated server use shared instances.

For additional requirements and considerations, see the Publish layers in bulk from a user-managed data store in the Portal for ArcGIS publication.

Initial bulk publishing

When the publishLayers operation is called to publish layers from a database for the first time, it is referred to as the initial bulk publish. When calling the operation for the first time, the following parameters are required to be included in the request:

• datastoreId
• templateSvcConfig
• portalFolderId
• serverId
• serverFolder

After the initial bulk publish, the system will remember the submitted values for the templateSvcConfig, portalFolderId, serverId, and serverFolder parameters. This information will be stored with the data store item in the Enterprise portal. The template configuration will also be available as a resource in the Sharing API directory, which can be located using the following URL path:

1
https://machine.domain.com/webadaptor/sharing/rest/ content/items/<database item ID>/resources/templateServiceConfiguration.json

Synchronization

After the initial bulk publish, the data store item owner may choose to perform additional calls to publishLayers to synchronize layers with the database, or to apply changes to all published layers. The following sections outline specific changes that may require additional calls to the publishLayers operation.

Tables were added to, or deleted from, the database

If tables have been added to, or removed from, the database since the initial bulk publishing took place, making an additional call to the publishLayers operation will synchronize the previously published layers by adding layers for newer tables and deleting layers for tables that are no longer a part of the database. When synchronizing tables, only the datastoreId parameter needs to be included in the request. All other parameters (such as templateSvcConfig and portalFolderId) are remembered by the system from the initial bulk publishing call.

Table fields are updated

If a table's fields are updated after the initial bulk publish call, their associated layers may not function as expected. In these instances, performing a synchronization will ensures that each layer is checked to see if there have been any schema changes and, if there has, refresh the map document powering the service. When synchronizing schema, only the datastoreId parameter needs to be included in the request. All other parameters (such as templateSvcConfig and portalFolderId) are remembered by the system from the initial bulk publishing call.

Table metadata was updated

If the title, snippet, description, min and max scale, extent, tags, credits, and access constraints metadata properties have changed, synchronizing bulk published layers can copy the updated metadata properties to the table's corresponding layer item. When synchronizing metadata properties, the publishLayers request will need to include the datastoreId and syncItemInfo, set as true, in the request.

Service configuration changes

During the initial bulk publish, layers were created that used a specific template service configuration (set with the templateSvcConfig parameter). After publishing, changes to the template service configuration, such as specifying different capabilities or specifying a preferred time zone, can be made and applied to all published layers. When synchronizing template service configuration changes, the publishLayers request must include the templateSvcConfig parameter, with the new service configuration JSON, and the applySvcConfigChanges parameter. Once completed, the new service configuration will be stored with the data store item as a resource in the Sharing API directory.

Request parameters

1
datastoreId=55d87f404a7e420bb969ccb70254bfec

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
templateSvcConfig={
  "serviceName": null,
  "type": "MapServer",
  "capabilities": "Map",
  "extensions": [
    {
      "typeName": "FeatureServer",
      "capabilities":"Query",
      "enabled":"true",
      "properties": {
        "maxRecordCount":"3500"
      }
    }
  ]
}

1
portalFolderId=f26efae67a7644499d43a6251e7df613

1
serverId=9sQswqEpB31ymiCD

1
serverFolder=TestFolder

Additional example usages

The examples in this section demonstrate different synchronizations that can be performed using the publishLayers operation.

Example one: synchronizing tables and schema

The following example demonstrates a POST request for publishLayers that demonstrates synchronizing tables and schema after the initial bulk publish:

1
2
3
4
5
6
POST /webadaptor/sharing/rest/portals/0123456789ABCDEF/datastores/allDatasets/publishLayers HTTP/1.1
Host: machine.domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []

datastoreId=55d87f404a7e420bb969ccb70254bfec&f=pjson

Example two: synchronizing tables, schema, and metadata

The following example demonstrates a POST request for publishLayers that demonstrates synchronizing tables, schema, and item metadata:

1
2
3
4
5
6
POST /webadaptor/sharing/rest/portals/0123456789ABCDEF/datastores/allDatasets/publishLayers HTTP/1.1
Host: machine.domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []

datastoreId=55d87f404a7e420bb969ccb70254bfec&syncItemInfo=true&f=pjson

Example three: synchronizing tables, schema, and updating all layers

The following example demonstrates a POST request for publishLayers that demonstrates synchronizing tables and schema, and updating all published layers to include preferred time zone information.

1
2
3
4
5
6
POST /webadaptor/sharing/rest/portals/0123456789ABCDEF/datastores/allDatasets/publishLayers HTTP/1.1
Host: machine.domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []

datastoreId=55d87f404a7e420bb969ccb70254bfec&templateSvcConfig={"type": "MapServer","capabilities": "Map,Query,Data","properties":{"datesInUnknownTimeZone": false,"dateFieldsTimezoneID": "Pacific Standard Time","dateFieldsRespectsDayLightSavingTime": true,"preferredTimeZoneID": "Pacific Standard Time","preferredTimeZoneRespectsDayLightSavingTime": true},"extensions": [{"typeName": "FeatureServer","capabilities": "Query,Create","enabled": "true","properties": {"maxRecordCount": "4000"}}]}&applySvcConfigChanges=true&f=pjson

JSON Response example

The publishLayers operation is performed asynchronously. If the request is successful, users will receive a success response that returns a jobType and a jobId:

1
2
3
4
5
6
7
{
  "success": true,
  "datastoreId": "42d41b6663c14e8699dc630ccaf87ca6",
  "serverId": "nxlsPtE4opGe8KeN",
  "jobType": "publishAllDatasets",
  "jobId": "jdf92dcb90f39472495d92c84b9c0e240"
}

Users can make a GET request using the jobType and jobID returned in the success response to the status operation to see the current state of their request:

1
https://machine.domain.com/webadaptor/sharing/rest/content/users/admin/items/<datastoreId>/status?jobType=publishAllDatasets&jobID=<jobID>&f=pjson

The status operation has three possible values it can return: partial, completed, or failed. If successful (completed), the following message is returned:

1
2
3
4
5
{
  "status": "completed",
  "statusMessage": "completed",
  "itemId": "42d41b6663c14e8699dc630ccaf87ca6"
}