- URL:
- https://<root>/<serviceName>/FeatureServer/createReplica
- Methods:
POST
- Required Capability:
- Sync
- Version Introduced:
- 10.0
Description
The create
operation creates the replica between the feature service and a client based on a client-supplied replica definition. This operation requires that the feature service has the Sync
capability enabled. For more information on the Sync
capability, see Sync overview.
Creating a replica as either an owner or administrator for a service that only has Query and Sync set as capabilities creates a bidirectional replica, which allows sync upload. Creating a replica as a non-owner for a service that only has Query and Sync set as capabilities creates a download replica that only allows sync downloads and edits cannot be uploaded during sync. The difference between the replicas created by different users allows owners and administrators to sync edits and manage data while providing read-only access to other users.
However, there's an exception to this rule for feature services running on versioned data with only Query
and Sync
capabilities. In this case, a download
replica is created for all users, including owners and administrators. To administer the data, owners or administrators can use direct connections to the back end enterprise geodatabase in ArcGIS Pro. This exception means that all replicas created from these services will download from the published version on sync.
The response for create
includes the replica
property, server generation number, and data similar to the response from the feature service query
operation. As the response returned by the create
operation has data for the layers in the replica, the response type for this operation is esri
. If the operation is called to register existing data using the replica
parameter, the response won't contain data for the layers in the replica, and the response type will be esri
.
For detailed examples of synchronization workflows, see Sync workflow examples.
New at 11.3
-
The
esri
,Field Type Time Only esri
,Field Type Date Only esri
, andField Type Timestamp Offset esri
field types have exited beta and are now supported at ArcGIS Enterprise 11.3.Field Type Big Integer -
Setting
sync
to 1024 (10 bit) is now supported whenData Option sync
is set asModel per
, which creates a syncable replica that includes the full model utility network. This requires that the feature service includes the Utility Network layer and its associated layers and tables. SettingReplica sync
to 1024 was added in 11.2, but was limited to cases whereData Option sync
was set asModel none
, which creates a copy but does not support sync. -
Feature services now support one-way feature service-to-feature service synchronization.
-
Support has been added for sync on services with 64 bit objectID fields and Utility Network data. The sync capability is not supported on services without Utility Network layers when 64 bit objectID fields are present.
New at 11.2
-
New
sync
values are supported for theData Options replica
parameter. Support for these new values are indicated by the service-levelOptions supported
property, which incorporate the values below:Sync Data Options sync
: SettingData Option Include Utility Network sync
to 1024 (bit 10) is supported. Doing this will include the full model utility network without network diagrams. SettingData Options sync
to 1024 is only supported if theData Options sync
parameter is set asModel none
. To include network diagrams, also setsync
(bit 12).Data Option Include Network Diagrams sync
: SettingData Option Include Parcel Fabric sync
to 2048 (bit 11) is supported. Doing this will include the full model parcel fabric. Replicas created with this option support offline editing and syncing workflows.Data Options sync
: SettingData Option Include Network Diagrams sync
to 4096 (bit 12) is supported, but only when it is combined with bit 10. When set with bit 10 will include the full model utility network with network diagrams. This value is only supported whenData Options sync
is set asModel none
and applied only when bit 10 is also set.sync
: SettingData Option Return High Precision Dates sync
to 8192 (bit 13) is supported. If the feature service has high precisionData Options esri
fields (indicated by the field propertyField Type Date precision
being 1), this option will include the high precision values in the offline data (millisecond precision). When the value is not set, the offline data date values are low precision (second precision).
-
Feature services support one-way feature service-to-feature service synchronization, which is a beta feature at ArcGIS Enterprise 11.2.
-
Feature services now support WKT2. Parameters in this operation that accept spatial references as input values (
replica
) will also accept WKT2 values and generate an appropriate response. For an example of WKT2, see this JSON example. For WKT2 values, see the Using spatial references documentation.SR
New at 11.1
- The service- and layer-level
supported
properties have been expanded to includeExport Formats csv
andgeojson
as supported formats for exported data for both hosted and non-hosted feature services. - Starting at ArcGIS Enterprise 11.1, this operation will not require the
geometry
parameter when thesync
parameter is set asModel none
. This will cause all records to be included for the feature layer unless other filters are set. However, thegeometry
parameter is required ifsync
values other thanModel none
are used.
New at 11.0
-
The service- and layer-level
supported
property has been expanded to include shapefile as an accepted value for both ArcGIS Enterprise hosted and non-hosted feature services.Export Formats -
At this release, a file geodatabase extracted from a feature service using the
create
operation now includes aReplica GDB
table. This table contains the feature service and feature service layer resource JSON information of the service the table was extracted from._Service Items -
The
replica
parameter has expanded itsOptions sync
accepted property values, support for which is indicated by the feature service'sData Options supported
service-level properties listed below:Sync Data Options - The
sync
property, set asData Options Include Missing Utility Network Layers 128
. This will include additional utility network system tables when thesync
property is set toData Option Include Utility Network System 16
. - The
sync
property, set asData Options Preserve True Curves 256
. This will preserve true curves when taking data offline and syncing.
- The
New at 10.9.1
Feature service and feature service layer resources now include a supported
property that describes the formats supported when exporting data. Data can be exported when either the extract or sync capabilities are enabled and the create
operation is called with the sync
parameter set as none
.
New at 10.9
- The
create
operation can be used to enable bidirectional syncing with another service. Hosted feature services, feature services running on branch versioned data or a feature services running on non-versioned with archiving data can support bidirectional syncing. Currently, bidirectional sync workflows require the target to be a hosted feature service running on either ArcGIS Online or ArcGIS Enterprise 10.9. Bidirectional syncing requires theReplica create
operation should be run withReplica server
target
andType bidirectional
sync
parameter values. These values can only be set if the service'sDirection sync
object has theCapabilities supports
property set asBi Directional Sync For Server true
. For more information, see Share content with collaboration groups. - A new parameter,
time
, has been added at 10.9. SettingReference Unknown Client time
asReference Unknown Client true
indicates that the client is capable of working with date field data values that are not in UTC. For more information on this parameter, see the Request parameters table below. - The
create
operation'sReplica sync
parameter has been expanded to add full annotation and an option to include a subset of Utility Network system information when taking data offline. See theData Options replica
parameter description below for more information.Options
New at 10.8.1
Feature services published with the Create a version for each downloaded map option will create a version for each replica that is created with branch versioned data. In order to ensure that replica version names are unique, each name is derived using the name of the feature service, the name of the portal account that downloaded the map, and a unique ID. Note that the service name and user name sections of the replica version name may be truncated if the resulting name is longer than what the replica version name allows as it's maximum character length. For more information, see Offline Maps and Branch Versioned Data.
Request parameters
Parameter | Details |
---|---|
(Optional) | The name of the replica on the server. The replica name is unique per feature service. If not specified, a replica name will be assigned and returned in the Syntax
Example
|
(Required) | The list of layers and tables to include in the replica. Syntax
Examples
|
(Optional) | This parameter allows you to set properties on a per-layer or per-table basis. In addition to the The properties include the following:
Syntax
Example
|
(Required; optional starting at ArcGIS Enterprise 11.1 when | The geometry to apply as the spatial filter. All the features in layers intersecting this geometry will be replicated. The structure of the geometry is the same as the structure of the JSON geometry objects returned by the ArcGIS REST API. In addition to the JSON structures, for envelopes and points, you can specify the geometry with a simpler comma-separated syntax. Syntax
Example
|
(Optional) | The type of geometry specified by the Values: |
(Optional) | The spatial reference of the input |
(Optional) | The spatial reference of the replica |
(Optional) | This parameter represents the response format. If Values: |
(Optional) | This parameter is only applicable if the feature service has attachments. If Values: |
(Optional) | This parameter is only applicable if the feature service has attachments and if Values: |
(Optional) | This parameter is available when the service resource Values include the following:
When When All other combinations are not valid. Values: |
(Optional) | If Values: |
(Optional) | This parameter is used to indicate that the replica is being created for per-layer sync or per-replica sync. To determine which model types are supported by a service, query the If If
Values: |
(Optional) | The format of the replica geodatabase returned in the response. The default is Syntax: |
(Optional) | This parameter instructs the Syntax
Example
For Syntax
Example
At ArcGIS Enterprise 11.2, support for one-way feature service-to-feature service sync workflows have been introduced at a beta feature. This feature uses a new Syntax
|
(Optional) | A At 10.9, passing a request with the A Values: |
(Optional) | A At 10.9, passing a request with the This parameter defaults to bidirectional when the See the Values: |
(Optional) | Introduced at 10.8. This parameter applies a datum transformation on each layer when the spatial reference used in geometry is different than the layer's spatial reference. This parameter is a list of datum transformations. For each layer, if one of the transformations in the list is applicable with the layer's geometry, the transformation will be applied. For a list of valid datum transformation ID values ad well-known text strings, see Using spatial references. Syntax
Examples
|
| Setting Its possible to define a service's time zone of date fields as unknown. Setting the time zone as unknown means that date values will be returned as-is from the database, rather than as date values in UTC. Non-hosted feature services can be set to use an unknown time zone using ArcGIS Server Manager. Setting the time zones to unknown also sets the Most clients released prior to ArcGIS Enterprise 10.9 will not be able to work with feature services that have an unknown time setting. The Value: |
| The response format. The default format is Values: |
Replica options
When included in a request, the replica
parameter causes the create
operation to create a new replica based on an existing replica definition (ref
). The replica
parameter can be used to create a new replica based on an existing replica definition (using register
) or to include layers that are not of either the feature layer or table types in the replica (using sync
). You cannot use both types of replica options in the same request.
Using registerExistingData
This section describes the syntax and properties for register
that can be provided with the replica
parameter. The codeblock below outlines the syntax for the register
JSON object:
Syntax
replicaOptions={"registerExistingData":{"refReplicaId": "<replica_guid>","refReplicaServerGen": <genNum>, "refLayerServerGens": [{"id": <layer1Id>, "serverGen": <genNum>}, {"id": <layer2Id>, "serverGen": <genNum>}]}}
Property | Description |
---|---|
| A JSON object that includes the |
| This property references an existing replica definition GUID, and is required to create a new replica based on an existing replica definition. The new replica created in this way will have the definition of the reference replica, which is identified by
If |
| This property references the generation number of the data from the reference replica. It applies to the reference replica created when |
| This property is an array of layer generation numbers in the reference replica. It applies to the reference replica created when |
Using syncDataOptions
This section describes the sync
values that can be provided with the replica
parameter.
Accepted values
The table below includes all of the supported sync
values, each representing a different bit and can be bitwise ORd.
Value | Description |
---|---|
1 | Bit 0. This option includes annotation features. Example
|
2 | Bit 1. This option includes dimension feature layers. Example
|
4 | Bit 2. This option includes contingent values. Example
|
16 | Bit 4. This option includes a subset of Utility Network system information, including the utility network layer metadata, associations, rules, and subnetworks. Example
|
32 | Bit 5. This option includes full model annotation. Example
|
128 | Bit 7, introduced at ArcGIS Enterprise 11.0. This option includes additional utility network system tables. Example
|
256 | Bit 8, introduced at ArcGIS Enterprise 11.0. This option preserves true curves when taking data offline and syncing. Example
|
1024 | Bit 10, introduced at ArcGIS Enterprise 11.2. This option includes the full model utility network. At 11.2, this value is only supported when The support and conditions for setting
If If If Example
|
2048 | Bit 11, introduced at ArcGIS Enterprise 11.2. This option includes the full model parcel fabrics. Replicas created with this option support offline editing and syncing workflows. Example
|
4096 | Bit 12, introduced at ArcGIS Enterprise 11.2. This option can be used with bit 10 to include the full model utility network with network diagrams. Specifying bit 10 without bit 12 will include a full model utility network without network diagrams. Example
|
8192 | Bit 13, introduced at ArcGIS Enterprise 11.2. This option includes the high precision values in the offline data (e.g. millisecond precision) if the feature service has high precision Example
|
Setting multiple values
To set multiple sync
, the values can be summed (i.e, bitwise OR of these values). For example, to include annotation (1) and dimension layers (2), you can specify the following value for sync
:
{“syncDataOptions”: 3}
To include annotation layers (1), dimension layers (2), and contingent values (4), you can specify the following values for sync
:
{“syncDataOptions”: 7}
Note in these cases that the layer
parameter is required to include the annotation or dimension layers you want to add to the replica.
The value of the supported
property indicates which values can be used with the feature service. It is also a bitwise ORd value. For example, a value of 3
for supported
indicates that there is at least one annotation layer (1) and one dimension layer (2) in the service. If sync
is 0
, the input will be treated as if no value for sync
has been set.
Annotation and dimensions
The sync
values that are needed to include annotation or dimensions layers are as follows:
{"sync
: Includes annotation feature layers.Data Options" : 1} {"sync
: Includes dimension feature layers.Data Options" : 2} {"sync
: Includes annotation feature layers with full model (added at 10.9).Data Options" : 32}
Either bit 0 (1) or a combination of bit 0 and bit 5 (resulting in 33 as a sync
value) can be used to add standard or feature-linked annotation layers to the replica.
Bit 0 is more appropriate for clients that do not support the full high quality annotation data model. When used, the synchronization process will apply behavior for edits involving feature-linked annotation. For example, if the layer has feature-linked annotation, during sync upload the annotation will be generated on the service for feature inserts.
The combination of bit 0 and bit 5 (33) should be used by clients that support the full high-quality annotation data model, such as ArcGIS Pro. In this case, feature-linked annotation behavior is not applied on the server during sync, as clients are expected to provide the high-quality annotation edits. An exception to this would be when the replica includes a layer that has feature-linked annotation, but the annotation is not added to the replica. In that case, feature-linked annotation behavior is applied on the server as the client does not have annotations to send.
Dimension layers are included with bit 1 (2). These layers function similarly to standard annotation layers where edits are applied on sync without additional behavior.
Contingent values
Contingent values are included when using bit 2 (4). Even though contingent values will be included, they are not updated when the service is synced. Any violations resulting from incorrect contingent values will be caught during the validation process on the service, not during the sync process.
Utility networks
A subset of utility network system information is included with bit 4 (16). The subset includes the utility network layer metadata, associations, rules, and subnetworks. This option is used by clients for workflows that require visualizing utility networks in the field with associations. It will not include network topologies, network diagrams, or support for tracking offline.
The following example demonstrates using this bit value and including the data from all layers. The layers in this example are:
The utility network system layers are as follows:
The required create
parameter values, using the utility network layers and system layer information, that can be passed in the request are outlined below:
layers=[0,1,2,3,4,5,6,7,8,10,11,12,13,500001,500002,500003]
layerQueries={"0":{"queryOption": "all", "useGeometry": false},
"1":{"queryOption": "all", "useGeometry": false},
"2":{"queryOption": "all", "useGeometry": false},
"3":{"queryOption": "all", "useGeometry": false},
"4":{"queryOption": "all", "useGeometry": false},
"5":{"queryOption": "all", "useGeometry": false},
"6":{"queryOption": "all", "useGeometry": false},
"7":{"queryOption": "all", "useGeometry": false},
"10":{"queryOption": "all", "useGeometry": false},
"11":{"queryOption": "all", "useGeometry": false},
"12":{"queryOption": "all", "useGeometry": false},
"13":{"queryOption": "all", "useGeometry": false},
"500001":{"queryOption": "all", "useGeometry": false},
"500002":{"queryOption": "all", "useGeometry": false},
"500003":{"queryOption": "all", "useGeometry": false}}
Geometry={"xmin": 6801882.314009005,"ymin": 1833711.8672784641,"xmax": 6818205.939993581,"ymax": 1854497.4691263959}
replicaOptions={"syncDataOptions":16}
async=true
Bit 7 (128) can be set along with bit 4 (16) to also include utility network system tables:
{“syncDataOptions”: 144}
This is supported when the service-level sync
property is 128
and the service-level sync
property is 16
. When set, this will include the utility network layer and system tables that were not included with the layers
parameter. Missing system tables, which include Associations, Rules, and Subnetworks, are added to the replica with the query
is set to all
. If a system table is already included in the layers
parameter, it is added with the query
property that is set as part of the layer
parameter. All other layers that are part of the utility network, but not present in the layers
parameter, are added with an empty schema (when query
is set as none
).
At ArcGIS Enterprise 11.2, bit 10 (1024) can be used to take the full model utility network offline. Using this option allows clients to support tracing in the field on the offline copy. However, this option only supports having the sync
set as none
, which means that only copies can be generated to get the latest changes, as sync is not supported. At 11.3, this option was expanded to support for setting sync
as per
, which creates a syncable replica that includes the full model utility network. For more information, see the trace utility network features workflow in the Offline Utility Networks in ArcGIS Maps SDKs for Native Apps blog post.
Additional considerations for bit 4
This section outlines additional considerations when using bit 4 (16) for sync
:
-
It allows you to add utility network layers, as well as their associations, rules, and subnetwork system layers to the layers parameter. Other system layers are not supported with this option.
-
Only utility network version 4 or higher supports this option for
sync
. An error is returned if this option is used with older versions of utility network.Data Options -
If you attempt to submit layers that include utility network layers, association layers, rules layers, or subnetworks system layers, and do not have this option set for
sync
, an error is returned. However, non-system utility network layers can be included and taken offline as simple features.Data Options -
Advanced fillers can be applied to the associations, rules, and subnetworks system layers using the
layer
parameter.Queries -
All utility network layers are typically included when using this option for
sync
, as together they make up the utility network data model.Data Options -
If you plan to use sync options that require replica tracking, you will need to run the enable replica tracking GP tool in ArcGIS Pro 2.7 (or higher) on the utility network data. This will enable replica tracking on the system layers. As of 10.9, replica tracking is required when:
-
The service is configured with Create a version for each downloaded Map.
-
The replica is created with a
target
ofType server
andsync
ofDirection bidirectional
. -
The dirty area layer cannot be included in the replica.
-
Preplanned workflows which use the
register
Existing Data replica
can be used with replicas generated by using this value forOption sync
.Data Options -
Synchronization supports uploading inserts, updates, and deletes to associations, as well as inserts and deletes to subnetworks, from client to server. Inserts, updates, and deletes to rules are not supported with sync uploads. Sync downloads from the server includes all edit types (inserts, updates, and deletes) made to associations, subnetworks, and rules within the definition of the replica.
True curves
Using bit 8 (256) will preserve true curves. When not used, features with curves are returned with the curves densified for both the create
and synchronize
operations. Clients that can work with true curves can use bit 8 when using this operation, which will result in the true curves being preserved when taking the data offline and returning edits from the server upon synchronization.
Parcel fabrics
At ArcGIS Enterprise 11.2, bit 11 (2048) can be used to take the full model parcel fabric offline. Replicas created with the option support offline editing and syncing workflows. This option also allows you to use client side parcel editing and topology tools on offline data in clients such as ArcGIS Pro. When using this option, you must include the parcel fabric layer in the layers list, which will cause the operation to expand to include the layers needed to support the full model. The data in the replica will also be expanded to include complete parcels when using the create
and sychronize
operations.
High precision date fields
Geodatabases in ArcGIS Pro 3.2 and ArcGIS Enterprise 11.2 support a high precision esri
field (indicated by the field property precision
being 1). These fields can store timestamp values to the millisecond, as opposed to low precision geodatabase date fields, which store timestamps to the second. Users can run a tool on their geodatabase datasets to upgrade their date fields to high precision. Once upgraded, the geodatabase datasets can't be opened in older clients. Hosted feature services always have high precision date fields. By default, the feature service will downgrade the offline data generated from the create
and synchronize
operation from high to low precision date fields. This downgrade allows older clients to continue to work with the date fields. Clients that are able to support high precision date fields will call create
and use bit 13 (8192) to generate offline data with high precision date fields.
64 bit objectID columns
Geodatabses in ArcGIS Pro 3.2 and ArcGIS Enterprise 11.2 can support a 64 bit object
column (indicated by the field property length being 8). Users need to run a tool on their datasets to upgrade the objectID column to 64 bit. The tool will return an error if there are existing replicas in the data store. You will also not be able to upgrade a 64 bit object
and then, later, take data offline using the feature service, since the sync capability is not supported with 64 bit object
columns.
Starting at 11.3, support has been added for sync on services with 64 bit objectID fields and Utility Network data. The sync capability is not supported on services without Utility Network layers when 64 bit objectID fields are present.
Using registerReplicaForServer
This section describes the use and workflow for register
, which was a beta feature at 11.2.
Starting at ArcGIS Enterprise 11.3, replica
can be used to facilitate a one-way sync pattern for feature service-to-feature service sync workflows. This pattern has simple features similar to what is supported with geodatabase replication and traditional versioned data. However, register
differs by working with sync-enabled feature services, which means it is supported on non-versioned archived data, as well as branch versioned data. Sync-enabled hosted feature services also support using register
.
Support for register
is indicated when the service-level supports
property is true
, under sync
.
At 11.3, non-versioned reference feature services may be used as the target replica for one-way feature sync using register
. The target replica is on the service that receives the changes in the one-way sync workflow. Non-versioned reference feature services do not support the sync capability, but do allow for an upload-only, server
target
replica to be created and synced. Non-versioned reference feature services include the following service level properties to describe what is supported for this workflow:
"syncCapabilities": {
"supportsRegisterReplicaForServer": true,
"supportsSyncDirectionControl": true,
"supportsPerLayerSync": true,
"supportsPerReplicaSync": true,
"supportsAttachmentsSyncDirection": true,
}
Property | Description |
---|---|
supports | When true , indicates support for the register option. For services that do not have sync enabled, supports being true means register can only be used when target is set as server and sync is set as upload . |
supports | When true , indicates support for sync being set as per . |
supports | When true , indicates support for sync being set as per . |
supports | When true , supports replicas that sync attachment edits and replicas that do not sync attachment edits. |
supports | When true , indicates support for setting the sync parameter. Non-versioned data only supports sync being set as upload . |
Workflow for one-way sync
The following section describes how to setup and use one-way sync workflows using register
.
At a high-level, this workflow uses the create
operation, with register
as the replica
value, to create a replica of the feature service that references the original data without providing the ref
and reading the replica
from the operation response. Another replica is then created on the feature service that references the copied data service that uses the replica
from the previous response. Once this is complete, and the replica pair is established, the Synchronize Replicas operation can be run on the feature service referencing the original data and the feature service referencing the copied data to export and import changes, respectively.
Before performing this workflow, the following steps should be taken to prepare your data:
-
Prepare your enterprise geodatabase data for sync by enabling branch versioning or by archiving non-versioned data and adding globalids.
-
Copy the data to another enterprise geodatabase by either copy and pasting the data or using the database backup and restore features.
-
Get the current timestamp and ensure that the timestamp in Unix format.
You can use an app or website to get this value.
-
Convert the Unix timestamp to milliseconds (for example, the Unix timestamp of1690749452 will be 1690749452000 when converted to milliseconds). This value is important as it records the moment in which the copy was made and is later used to get any changes that have occurred since that moment.
-
Ensure the copied data is prepared for sync (e.g. enabling branch versioning or archiving non-versioned data).
-
Publish a feature service from each database, making sure that the layer IDs in each service reference the same corresponding dataset. These feature services should have Sync enabled.
Once the above steps have been completed, you can then create a replica for the feature service referencing the original data, and a replica referencing the copied data.
-
To create a replica from the service referencing the original data, craft a
create
request on that service that uses the following parameters and values:Replica -
Use the
replica
parameter to name the replica. For example:Name Use dark colors for code blocks Copy replicaName=Ags_Fs
-
Use the layers
parameter
to list the layers present in the feature service.Use dark colors for code blocks Copy layers=0,1,2,3
-
Use the
geometry
parameter to specify the geometry of the replica. Specify thegeometry
asType esri
if envelope geometry is provided.Geometry Envelope Use dark colors for code blocks Copy geometryType=esriGeometryEnvelope&geometry={xmin: -1.98388060889E7,ymin: 2146082.1816000007,xmax: -7455049.400699999,ymax: 1.1542768540600002E7}
-
Set the
sync
parameter toModel per
.Replica -
Use the
register
format as input for theReplica For Server replica
parameter. The information for theOptions ref
andReplica Server Gen ref
should be the converted timestamp information from the preparatory steps mentioned previously (step 4).Replica Server Sib Gen Whether you use
ref
andReplica Server Gen ref
, or just useReplica Server Sib Gen ref
, depends on whether you've setLayer Server Gens per
orReplica per
as theLayer sync
option. This workflow usesModel per
.Replica Use dark colors for code blocks Copy replicaOptions={"registerReplicaForServer":{"refReplicaServerGen": 1690749452000, "refReplicaServerSibGen": 1690749452000}}
-
Set the
target
parameter toType server
. -
Set the
sync
parameter toDirection download
.
-
-
Once the request has been made, run the operation. The operation will return a response that matches the following:
Use dark colors for code blocks Copy { "replicaName": "Ags_Fs", "replicaID": "CB873E6D-CF44-4515-A867-598A82DB94C3", "transportType": "esriTransportTypeUrl", "responseType": "esriReplicaResponseTypeInfo", "syncModel": "perReplica", "replicaServerGen": 1690749452000, "replicaServerSibGen": 1690749452000 }
-
Copy the
replica
value returned in the response.ID -
To create a replica from the service referencing the copied data, craft a
create
request on that service that uses the following parameters and values:Replica -
Use the
replica
parameter to name the replica.Name Use dark colors for code blocks Copy replicaName=Bgs_Fs
-
Use the
layers
parameter to list the layers present in the feature service.Use dark colors for code blocks Copy layers=0,1,2,3
-
Use the
geometry
parameter to specify the geometry of the replica. Specify thegeometry
hasType esri
.Geometry Envelope Use dark colors for code blocks Copy geometryType=esriGeometryEnvelope&geometry={xmin: -1.98388060889E7,ymin: 2146082.1816000007,xmax: -7455049.400699999,ymax: 1.1542768540600002E7}
-
Set the
sync
parameter toModel per
.Replica -
Use the
register
format as input for theReplica For Server replica
parameter. This will use theOptions replica
value retrieved from the previous replica's response, as well as the timestamp data from the preparatory steps (step 4) as input forID ref
andReplica Server Gen ref
.Replica Server Sib Gen The steps in this workflow assumes you have branch versioned your data, which supports the
per
sync model. If your data, instead, is non-versioned and archived, or hosted on Enterprise, theReplica sync
isModel per
. This requires setting theLayer server
andGen server
for each layer as part of theSib Gen register
JSON object rather than oneReplica For Server replica
andServer Gen replica
value for the sync process. It is also possible to have one replica that isServer Sib Gen per
and one replica that isLayer per
. In these instances, you will be required to translate the parameter information between theReplica per
andLayer per
models accordingly.Replica Use dark colors for code blocks Copy replicaOptions={"registerReplicaForServer":{"refReplicaId": CB873E6D-CF44-4515-A867-598A82DB94C3,"refReplicaServerGen": 1690749452000,"refReplicaServerSibGen": 1690749452000}}
-
Set the
target
parameter toType server
. -
Set the
sync
parameter toDirection upload
.
-
-
Once the request has been made, run the operation.
The replica pair has been established and they can now be synchronized when edits have been made to the feature service that references the original data. Once changes have been made, the following workflow is used to keep the feature services in sync:
-
Once changes have been made, perform the
synchronize
operation on the feature service referencing the original data (the service that has had edits made to it) to export the changes. To do this, use the following parameters and values:Replica -
Use the
replica
returned from the first replica (step 2) as the value forID replica
.ID Use dark colors for code blocks Copy replicaID=CB873E6D-CF44-4515-A867-598A82DB94C3
-
Retrieve the
replica
value from the JSON view of the replica of the service referencing the copied data. For example:Server Sib Gen Use dark colors for code blocks Copy https://machine.domain.com/webadaptor/rest/services/featre_service_copy/FeatureServer/replicas/92A36775-54D3-447C-8AD7-4E1A9161BAE2?f=pjson
Use this value as the input for the
replica
parameter.Server Gen -
Set the
sync
parameter toDirection download
.
-
-
Once the request has been made, run the operation. If the response includes a URL property with a delta mobile geodatabase then there are edits to sync and you should proceed with following steps. However, if there are no edits to sync and no delta mobile geodatabase in the response, then you do not need to perform any additional steps until the next time you sync.
- Download the delta file from the URL in the response.
- Save the
replica
andServer Gen replica
properties from the response as input for the next synchronization operation.Server Sib Gen
-
Go to the service referencing the copied data and upload the delta file using the
uploads
operation. Use the following URL format to access the operation:Use dark colors for code blocks Copy https://machine.domain.com/webadaptor/rest/services/featre_service_copy_name/FeatureServer/uploads
After uploading the delta file, save the resulting upload item ID.
-
Once the changes have been uploaded, perform the
synchronize
operation on the feature service referencing the copied data to import the changes. To do this, use the following parameters and values:Replica -
Use the
replica
returned from the first replica (step 2) as the value forID replica
. For example:ID Use dark colors for code blocks Copy replicaID=CB873E6D-CF44-4515-A867-598A82DB94C3
-
Use the
replica
value from the previousServer Gen synchronize
response (performed on the feature service referencing the original data) and use that as the input for theReplica replica
parameter.Server Sib Gen -
Set the
sync
parameter toDirection upload
. -
Use the upload item ID retrieved from the
uploads
operation (step 3) as the value for theedits
parameter.Upload ID
-
-
Once the request has been made, run the operation. This will import the changes from the replica of the feature service referencing the original data to the replica of the feature service referencing the copied data.
Its recommended that you run through several rounds of edits and synchronizations between the replicas to ensure that the one-way synchronization is working.
Additional notes:
- The source and target replicas must have the same replicaId in order for the synchronization to complete successfully.
- The services are required to be sync enabled except for the case where the target feature service has non-versioned data. Even in this case, however, the data must have globalIds.
- The target replica feature service needs to have editing capabilities enabled.
- Feature services with traditional versioned data are not supported with the
register
option.Replica For Server - A simple features model only is supported for Utility Networks and Parcel Fabrics with
register
.Replica For Server - The source and target feature services can be running on the same server but must reference different databases or data stores. For example, the source and target feature services can’t both be hosted feature services in the same deployment of ArcGIS Enterprise.
- With one-way feature service-to-feature service sync and branch versioned data, the source replica exports changes from the default branch regardless of whether
version creation
isnone
orversion creation
isversion
. The target replica supports bothPer Downloaded Map version creation
asnone
andversion creation
asversion
service settings. IfPer Downloaded Map version creation
isnone
, edits will be uploaded into default on the target during sync. Ifversion creation
isversion
, edits will be uploaded into a named branch on the target during sync. This allows the edits to be quality controlled on the target and then reconciled and posted to default.Per Downloaded Map - Make sure the URLs are in the correct case when running the operations. For example, if using hosted feature services and the folder name is Hosted, use a URL such as:
Use dark colors for code blocks Copy https://myserver.esri.com/server/rest/services/Hosted/myservice/FeatureServer/createReplica
rather than
https://myserver.esri.com/server/rest/services/hosted/myservice/FeatureServer/createReplica
to create the replicas.
- When creating the replicas, you must use a supported
sync
as described by theModel supports
andPer Replica Sync supports
properties in the service resource'sPer Layer Sync sync
. If one type ofCapabilities sync
is supported on both the source and the target, it is easiest to use that one. However, if there is no match (e.g. source supportsModel per
only and target supportsReplica per
only) then you can map the servergens when you run the operations. For example, theLayer replica
from the result when you export changes from theServer Gen per
source can be used as theReplica server
when importing changes on theSib Gen per
target.Layer
Example usage
Example one
The following is a sample POST request for the create
operation that has data
set to sqlite
:
POST /webadaptor/rest/services/LandUser/FeatureServer/createReplica HTTP/1.1
Host: machine.domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []
replicaName=Marshes&layers=0&layerQueries={"0":{"where":"Type=5"}}&geometry={"xmin": -120.8, "ymin": 35.14, "xmax": -120.66, "ymax": 35.2}&geometryType=esriGeometryEnvelope&inSR=4326&replicaSR=&transportType=esriTransportTypeURL&returnAttachments=true&returnAttachmentsDataByUrl=true&attachmentSyncDirection=none&async=true&syncModel=perReplica&dataFormat=sqlite&replicaOptions=&targetType=client&syncDirection=&datumTransformations=&f=json
The above request uses the following parameters and values:
replicaName=Marshes&
layers=0&
layerQueries={"0":{"where":"Type=5"}}&
geometry={"xmin": -120.8, "ymin": 35.14, "xmax": -120.66, "ymax": 35.2}&
geometryType=esriGeometryEnvelope&
inSR=4326&
replicaSR=&
transportType=esriTransportTypeURL&
returnAttachments=true&
returnAttachmentsDataByUrl=true&
attachmentSyncDirection=none&
async=true&
syncModel=perReplica&
dataFormat=sqlite&
replicaOptions=&
targetType=client&
syncDirection=&
datumTransformations=&
f=json
Example two
The following is a sample POST request for the create
operation that has data
set to json
:
POST /webadaptor/rest/services/LandUser/FeatureServer/createReplica HTTP/1.1
Host: machine.domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []
replicaName=Marine&layers=0&layerQueries={"0":{"where":"Type=2"}}&geometry={"xmin": -120.8, "ymin": 35.14, "xmax": -120.66, "ymax": 35.2}&geometryType=esriGeometryEnvelope&inSR=4326&replicaSR=&transportType=esriTransportTypeURL&returnAttachments=true&returnAttachmentsDataByUrl=true&attachmentsSyncDirection=none&async=false&syncModel=perReplica&dataFormat=json&replicaOptions&targetType=client&syncDirection=&datumTransformations=&f=pjson
The above request uses the following parameters and values:
replicaName=Marine&
layers=0&
layerQueries={"0":{"where":"Type=2"}}&
geometry={"xmin": -120.8, "ymin": 35.14, "xmax": -120.66, "ymax": 35.2}&
geometryType=esriGeometryEnvelope&
inSR=4326&
replicaSR=&
transportType=esriTransportTypeURL&
returnAttachments=true&
returnAttachmentsDataByUrl=true&
attachmentsSyncDirection=none&
async=false&
syncModel=perReplica&
dataFormat=json&
replicaOptions&
targetType=client&
syncDirection=&
datumTransformations=&
f=pjson
JSON Response syntax
Example one
When transport
is set to esri
, the file returned in the URL contains a JSON or a sqlite payload (as specified with the data
parameter) with a syntax as follows:
{
"transportType": "esriTransportTypeURL",
"responseType": "<esriReplicaResponseTypeData | esriReplicaResponseTypeInfo>",
"layerServerGens": [{"id": "<layerId>", "serverGen": "<serverGen>"}],
"URL":"<url>"
}
Example two
When async
is set to true
, the request is processed as an asychronous job, and a URL that a client can visit to check the status of the job is returned:
{
"statusUrl": "<url>"
}
The following is the syntax of the status
resource:
{
"transportType": "esriTransportTypeURL",
"responseType": <esriReplicaResponseTypeData | esriReplicaResponseTypeInfo>,
"replicaName": "<replicaName>",
"resultUrl": "<url>", //path to JSON (dataFormat=JSON) or a SQLite geodatabase (dataFormat=sqlite)
"submissionTime": <T1>, //Time since epoch in milliseconds
"lastUpdatedTime": <T2>, //Time since epoch in milliseconds
"status": "<Pending | InProgress | Completed | Failed | ImportChanges | ExportChanges | ExportingData | ExportingSnapshot
| ExportAttachments | ImportAttachments | ProvisioningReplica | UnRegisteringReplica | CompletedWithErrors>"
}
Example three
If transport
is set to esri
and data
is set to json
, a JSON object response is directly returned with the following syntax:
{
"replicaName": "<replicaName>",
"replicaID": "<replicaID>", // unique value that identifies the replica/server
"transportType": "<esriTransportTypeUrl | esriTransportTypeEmbedded>",
"responseType": "<esriReplicaResponseTypeData | esriReplicaResponseTypeInfo>",
"syncModel": "<perReplica | perLayer>",
"layerServerGens": [
{"id": <layer1Id>,"serverGen":<genNum>},
{"id": <layer2Id,"serverGen":<genNum>}
], // read only values for clients. Only if syncModel = perLayer
"replicaServerGen: "<replicaServerGen>", // read only value for clients. Only if syncModel = perReplica
"layers": [
{
"id": <layerId1>,
"features": [ //features will include geometry for feature layers only
<feature1>, <feature2>
],
"attachments": [
"<attachment1>, <attachment2>
]
},
{
"id": <layerId2>,
"features": [ //features will include geometry for feature layers only
<feature1>, <feature2>
],
"attachments": [
"<attachment1>, <attachment2>
]
}
]
}
JSON Response example
Example one
When async
is set to true
, the request is processed as an asynchronous job and a URL that a client can visit to check the status of the job is returned. The file returned in the result
is a sqlite geodatabase. The sqlite replica geodatabase contains the same information and data as the JSON file content in the subsequent example:
{
"statusUrl": "https://services.myserver.com/arcgis/rest/services/LandUse/FeatureServer/jobs/j0b4b6064db0f44e6b5f39c4ef301d1f9"
}
Response example for the status resource:
{
"transportType": "esriTransportTypeUrl",
"responseType": "esriReplicaResponseTypeData",
"replicaName": "Soils",
"replicaID": "99F979B0-A93A-4EBF-9015-D4FDB567218E",
"targetType": "server",
"resultUrl": "https://services.myserver.com/arcgis/rest/services/directories/replicafiles/_ags_data{422DCB2CDD8340A7B73639846E9AB43C}.geodatabase"
"submissionTime": 1379366479000,
"lastUpdatedTime": 1379366482000,
"status": "Completed"
}
Example two
When creating a replica with transport
set as esri
and data
is set to sqlite
, the response includes layer
and a sqlite geodatabase:
{
"transportType": "esriTransportTypeUrl",
"responseType": "esriReplicaResponseTypeData",
"layerServerGens": [
{
"id": 0,
"serverGen": 1526605677436
}
],
"URL": "https://services.myserver.com/arcgis/rest/directories/arcgisoutput/Sync_MapServer/_ags_dataE00E0CEDE72B4526BBD3B659088FE365.geodatabase"
}
Example three
Where transport
is set to esri
and data
is set to json
:
{
"transportType":"esriTransportTypeUrl",
"responseType": "esriReplicaResponseTypeData",
"replicaName": "Meters",
"resultUrl": "https://arcgis.com/lidGgNLxw9LL0SbI/ArcGIS/rest/services/SaveTheBay/replicafiles/c2f366ffbf5549a48727d2529b2c6ed5.json",
"submissionTime": 1379366479000,
"lastUpdatedTime": 1379366482000,
"status": "Completed"
}
The file content:
{
"replicaName": "Marine",
"replicaID": "{5016655f-4db8-4745-b1ab-995081dfcb52}",
"layerServerGens": [
{
"id": 0,
"serverGen": 8411
}
],
"responseType": "esriReplicaResponseTypeData",
"syncModel": "perLayer",
"layers": [
{
"id": 0,
"features": [
{
"geometry": {
"x": -120.73650757099995,
"y": 35.165736219000053
},
"attributes": {
"OBJECTID": 5,
"Type": 2,
"Confirmed": 0,
"Comments": "",
"creator": "user1",
"editor": "user1",
"Submitted": 1298911207000,
"GlobalID": "85e499ac-8bff-42e8-9897-12f121898565"
}
},
{
"geometry": {
"x": -120.74290998099991,
"y": 35.157279059000075
},
"attributes": {
"OBJECTID": 6,
"Type": 2,
"Confirmed": 0,
"Comments": "",
"creator": "user1",
"editor": "user1",
"Submitted": 1298911207000,
"GlobalID": "a699a609-8cbd-4a18-a363-42ac87e75e19"
}
},
{
"geometry": {
"x": -120.73939627999994,
"y": 35.175259875000052
},
"attributes": {
"OBJECTID": 1627,
"Type": 2,
"Confirmed": 0,
"Comments": "",
"creator": "user1",
"editor": "user1",
"Submitted": 1298652153000,
"GlobalID": "ed8e7ee8-4a91-4d5e-8bed-9f609c66387b"
}
}
],
"attachments" : [
]
}
]
}
Example four
Where data
is set to json
and the data contains attachments:
{
"transportType":"esriTransportTypeUrl",
"responseType":"esriReplicaResponseTypeData",
"URL": "https://machinename:6443/arcgis/rest/directories/arcgisoutput/Canada/test113c26d11b80f049c09aef1e6c1327641c.json"
}
The file content:
{
"replicaName": "ags_gfs_4",
"replicaID": "D4B2D34C-61DD-4AED-BF37-B7AC363CDB08",
"transportType": "esriTransportTypeUrl",
"responseType": "esriReplicaResponseTypeData",
"syncModel": "perReplica",
"replicaServerGen": 0,
"responseType": "esriReplicaResponseTypeData",
"layers": [
{
"id": 0,
"features": [
{
"geometry": {
"x": -123.06999969499992,
"y": 49.159999847000051
},
"attributes": {
"OBJECTID": 1,
"NAME": "Vancouver",
"CAPITAL": "N",
"PROV_NAME": "British Columbia",
"GLOBALID": "{C74D42DB-5D07-4AB8-8C91-11AE1E52E6A3}",
"POPULATION_DOMAIN": 4,
"RepRowID": 1
}
},
{
"geometry": {
"x": -114.05000305199991,
"y": 51.029998779000039
},
"attributes": {
"OBJECTID": 2,
"NAME": "Calgary",
"CAPITAL": "N",
"PROV_NAME": "Alberta",
"GLOBALID": "{6A33F63A-AA90-4970-AB76-76B32E702745}",
"POPULATION_DOMAIN": 5,
"RepRowID": 2
}
},
{
"geometry": {
"x": -113.27999877899992,
"y": 53.330001831000061
},
"attributes": {
"OBJECTID": 3,
"NAME": "Edmonton",
"CAPITAL": "Y",
"PROV_NAME": "Alberta",
"GLOBALID": "{4D809477-4994-4B8C-80E7-1631E0AD3FA9}",
"POPULATION_DOMAIN": 4,
"RepRowID": 3
}
},
{
"geometry": {
"x": -97.124443053999926,
"y": 49.921169281000061
},
"attributes": {
"OBJECTID": 4,
"NAME": "Winnipeg",
"CAPITAL": "Y",
"PROV_NAME": "Manitoba",
"GLOBALID": "{CDB3FD57-2E2A-4FBF-998D-B84E5E26167D}",
"POPULATION_DOMAIN": 3,
"RepRowID": 4
}
},
{
"geometry": {
"x": -75.650749206999933,
"y": 45.374221802000079
},
"attributes": {
"OBJECTID": 6,
"NAME": "Ottawa",
"CAPITAL": "C",
"PROV_NAME": "Ontario",
"GLOBALID": "{0F2F8880-4763-481A-9379-62B573ED3154}",
"POPULATION_DOMAIN": 4,
"RepRowID": 6
}
},
{
"geometry": {
"x": -73.653526305999947,
"y": 45.541019440000071
},
"attributes": {
"OBJECTID": 7,
"NAME": "Montreal",
"CAPITAL": "N",
"PROV_NAME": "Quebec",
"GLOBALID": "{BE529DB3-D879-476F-B3CA-FF4E9B32A36B}",
"POPULATION_DOMAIN": 6,
"RepRowID": 7
}
},
{
"geometry": {
"x": -71.244926452999948,
"y": 46.802070618000073
},
"attributes": {
"OBJECTID": 8,
"NAME": "Quebec",
"CAPITAL": "Y",
"PROV_NAME": "Quebec",
"GLOBALID": "{99FD4EF2-4548-4FD6-97A4-CAC6B3185373}",
"POPULATION_DOMAIN": 3,
"RepRowID": 8
}
},
{
"geometry": {
"x": -123.34989929199992,
"y": 48.451988220000032
},
"attributes": {
"OBJECTID": 9,
"NAME": "Victoria",
"CAPITAL": "Y",
"PROV_NAME": "British Columbia",
"GLOBALID": "{8F558B76-98E1-41AE-92D0-148547E344A6}",
"POPULATION_DOMAIN": 2,
"RepRowID": 9
}
}
],
"attachments": [
{
"attachmentId": 2,
"globalId": "{A8AFEC66-516B-40E9-9BAC-2F26AB0E0253}",
"parentGlobalId": "{C74D42DB-5D07-4AB8-8C91-11AE1E52E6A3}",
"contentType": "application/pdf",
"size": 762519,
"name": "celebrate_CND.pdf",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach1c2b660372a64876944b1e874c930b3f.pdf"
},
{
"attachmentId": 3,
"globalId": "{B5B41B49-73C4-48C1-A5B0-4DFDDCA73F25}",
"parentGlobalId": "{C74D42DB-5D07-4AB8-8C91-11AE1E52E6A3}",
"contentType": "image/jpeg",
"size": 35277,
"name": "vancouver.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach83633fbcc78e400cbe669f16700d467f.jpg"
},
{
"attachmentId": 4,
"globalId": "{4E430844-01C2-41F5-A540-B9BE97A0D187}",
"parentGlobalId": "{8F558B76-98E1-41AE-92D0-148547E344A6}",
"contentType": "image/jpeg",
"size": 4424,
"name": "rockies.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach54cc055852e64c589b5cd60b51ee4645.jpg"
},
{
"attachmentId": 5,
"globalId": "{E71B2FC1-1173-424E-9B01-57B6FD2CBCD6}",
"parentGlobalId": "{8F558B76-98E1-41AE-92D0-148547E344A6}",
"contentType": "image/jpeg",
"size": 18813,
"name": "novascotia.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach80bea2ecd080460cbe6155fa1ec79532.jpg"
},
{
"attachmentId": 6,
"globalId": "{CB299B1F-736D-4080-B01E-C07B1B6ABA88}",
"parentGlobalId": "{6A33F63A-AA90-4970-AB76-76B32E702745}",
"contentType": "image/jpeg",
"size": 52568,
"name": "mountains.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach60fbca550b944f4b855f2fb1f0375955.jpg"
},
{
"attachmentId": 7,
"globalId": "{5B2D5F6C-8495-4BB4-9D09-B4DA9EE8D3B9}",
"parentGlobalId": "{4D809477-4994-4B8C-80E7-1631E0AD3FA9}",
"contentType": "application/pdf",
"size": 84256,
"name": "cnd_doc.pdf",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach8bffd96db040439694bde39b23f8f392.pdf"
},
{
"attachmentId": 24,
"globalId": "{17686592-E726-40F0-8B73-2168C7543E43}",
"parentGlobalId": "{BE529DB3-D879-476F-B3CA-FF4E9B32A36B}",
"contentType": "image/jpeg",
"size": 4424,
"name": "rockies.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach981c1c88d9194ac3b6382b67f410d629.jpg"
},
{
"attachmentId": 25,
"globalId": "{998ECBE2-6D27-4244-82A2-5E05D7A6655D}",
"parentGlobalId": "{BE529DB3-D879-476F-B3CA-FF4E9B32A36B}",
"contentType": "image/jpeg",
"size": 118371,
"name": "politics.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach9093c7c9ea9748f0a5b41a2972a8db0e.jpg"
},
{
"attachmentId": 29,
"globalId": "{913DCE0B-0655-410C-8697-95EB872F2EA8}",
"parentGlobalId": "{0F2F8880-4763-481A-9379-62B573ED3154}",
"contentType": "image/jpeg",
"size": 52568,
"name": "mountains.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach6c2bb62d0c1d43ff8810c2485ca5e21b.jpg"
},
{
"attachmentId": 30,
"globalId": "{E39194E1-A2B5-4920-9BB2-1189EA5E5FA4}",
"parentGlobalId": "{0F2F8880-4763-481A-9379-62B573ED3154}",
"contentType": "image/jpeg",
"size": 19530,
"name": "polarbear_cub.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach55256b8ad9724574a17c47f960959cc1.jpg"
},
{
"attachmentId": 31,
"globalId": "{C7BF62B1-D8DB-4ECD-ACB7-42BEC64DB59B}",
"parentGlobalId": "{0F2F8880-4763-481A-9379-62B573ED3154}",
"contentType": "image/jpeg",
"size": 118371,
"name": "politics.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach9dc1d884ed0e45e0b1ea1a2ef96f17e4.jpg"
},
{
"attachmentId": 32,
"globalId": "{CAD4BFAA-F6D6-43A5-8594-DCA86C468F88}",
"parentGlobalId": "{99FD4EF2-4548-4FD6-97A4-CAC6B3185373}",
"contentType": "image/jpeg",
"size": 118371,
"name": "politics.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attachd807f2238bf04074836a3e2648bb740d.jpg"
},
{
"attachmentId": 33,
"globalId": "{21A265D7-87BE-4C46-B59F-FBFF5FE8A533}",
"parentGlobalId": "{99FD4EF2-4548-4FD6-97A4-CAC6B3185373}",
"contentType": "image/jpeg",
"size": 28588,
"name": "flag.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach27740a4f7c4d422a893a6c263bd79575.jpg"
},
{
"attachmentId": 34,
"globalId": "{FF4E9E9E-BC4C-48F5-B2DA-EA9D243EB6B3}",
"parentGlobalId": "{99FD4EF2-4548-4FD6-97A4-CAC6B3185373}",
"contentType": "image/jpeg",
"size": 69583,
"name": "highway.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attachc225fced338547cf81f0f6eb575e60e8.jpg"
},
{
"attachmentId": 35,
"globalId": "{1C6F43AD-68F7-4C27-A683-639D7B973909}",
"parentGlobalId": "{99FD4EF2-4548-4FD6-97A4-CAC6B3185373}",
"contentType": "image/jpeg",
"size": 52568,
"name": "mountains.jpg",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach31d77279e58e4fec8cc3c6f30a714bb5.jpg"
},
{
"attachmentId": 48,
"globalId": "{90234EC7-0D60-4178-993A-0D132E63A9EF}",
"parentGlobalId": "{CDB3FD57-2E2A-4FBF-998D-B84E5E26167D}",
"contentType": "application/pdf",
"size": 331959,
"name": "CND_goose.pdf",
"url": "https://myserver:6443/arcgis/rest/directories/arcgisoutput/Canada/_ags_fsRep_attach6b4143202a1445ac81f1218b9b28c503.pdf"
}
]
}
]
}