- URL:
- https://[root]/portals/[portalID]/datastores/allDatasets/publishLayers
- Methods:
POST
- Version Introduced:
- 10.7
Example usage
The following is a sample ArcGIS Enterprise POST request for the publish
operation, which demonstrates performing an initial bulk publish:
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 publish
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 publish
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 publish
operation:
- Only the owner of the data store item can perform the
publish
operation.Layers - 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 publish
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:
datastore
Id template
Svc Config portal
Folder Id server
Id server
Folder
After the initial bulk publish, the system will remember the submitted values for the template
, portal
, server
, and server
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:
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 publish
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 publish
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 publish
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 datastore
parameter needs to be included in the request. All other parameters (such as template
and portal
) 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 datastore
parameter needs to be included in the request. All other parameters (such as template
and portal
) 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 publish
request will need to include the datastore
and sync
, 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 template
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 publish
request must include the template
parameter, with the new service configuration JSON, and the apply
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
Parameter | Details |
---|---|
(Required) | The Example
|
(Required; Optional after initial call) | A JSON object defining the template for service configurations, such as setting specific capabilities or service properties, used during bulk publishing. At 11.1, preferred time zone information can be included as part of a service's properties. This parameter only supports configuring map services with the feature service extension enabled. After the initial bulk publish, this parameter can be used to specify a new template for published layers that can be applied to pre-existing or new layers. Example
|
(Required; Optional after initial call) | The folder to which the datasets will be published. This parameter is not required after the initial call. Example
|
(Required; Optional after initial call) | The Example
|
(Required; Optional after initial call) | The name of the server folder. This parameter is not required after the initial call. Example
|
(Optional) | Specifies if layer item properties should be updated using the source dataset's metadata. When set to Values: |
(Optional) | Introduced at 11.1. Specifies if changes made to the template service configuration JSON should be applied to previously published layers. When set to Values: |
| The response format. The default format is Value: |
Additional example usages
The examples in this section demonstrate different synchronizations that can be performed using the publish
operation.
Example one: synchronizing tables and schema
The following example demonstrates a POST request for publish
that demonstrates synchronizing tables and schema after the initial bulk publish:
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 publish
that demonstrates synchronizing tables, schema, and item metadata:
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 publish
that demonstrates synchronizing tables and schema, and updating all published layers to include preferred time zone information.
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 publish
operation is performed asynchronously. If the request is successful, users will receive a success response that returns a job
and a job
:
{
"success": true,
"datastoreId": "42d41b6663c14e8699dc630ccaf87ca6",
"serverId": "nxlsPtE4opGe8KeN",
"jobType": "publishAllDatasets",
"jobId": "jdf92dcb90f39472495d92c84b9c0e240"
}
Users can make a GET request using the job
and job
returned in the success response to the status operation to see the current state of their request:
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:
{
"status": "completed",
"statusMessage": "completed",
"itemId": "42d41b6663c14e8699dc630ccaf87ca6"
}