Reconcile Version

URL:: https://<LinearReferencingService-url>/reconcileVersion
Methods:: GET
Required Capability:: Event Editing
Version Introduced:: 10.6

Description

Reconcile an edit version against a target version with the option to post changes after a successful reconcile.

Version names are case sensitive and should take the form {'{'}owner{'}'}.{'{'}version{'}'}, for example, sde.DEFAULT.

Changes to the same row or feature in the target and edit versions may cause a conflict during the reconcile. The reconcile process will be aborted if conflicts are found. Conflicts must be resolved manually before the next reconcile, and the postprocess will not start until a reconcile is successfully completed.

If the option is chosen to post after reconcile (withPost=true), a shared version lock will be obtained on the target version during the reconcile process. This ensures that the target version is not modified between the reconcile and the post.

Request parameters

Parameter	Details
`f` (Optional)	Specifies the response format. The default response format is `html`. Values: `html` \| `json` \| `pjson`
`targetVersion` (Required)	The name of a version in the ancestry of the edit version, such as the parent version or the default version. Typically contains edits from other versions that can be pulled into an edit version.
`editVersion` (Required)	The name of the edit version to be reconciled with the target version.
`withPost`	If set to `true`, changes in the edit version will be posted to the target version after a successful reconcile. The default is `false`. If true, and `checkOnly` is also true, this parameter will be ignored. Values: `false` \| `true`
`lrsId`	A unique ID that identifies an LRS workspace. Refer to the LRS service resource for a list of LRS workspaces and their IDs. If there is only one LRS workspace referenced by the map service, that LRS is used by default. Otherwise, the `lrsId` parameter is required.
`checkOnly`	If set to `true`, this operation only checks if a reconcile is needed between the edit version and the target version. No actual reconciling or posting is performed. The default is false. Values: `false` \| `true`

Example usage

Example 1

The following is the URL for reconciling (but not posting) edit version data_owner.job_42 with target version sde.DEFAULT in the LRS workspace 387ad279-6026-4680-8171-fd17d1b9efd4.

Use dark colors for code blocksCopy
https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/reconcileVersion?f=json&targetVersion=sde.DEFAULT&editVersion=data_owner.job_42&lrsId=387ad279-6026-4680-8171-fd17d1b9efd4

Example 2

The following is the URL for reconciling and posting edit version data_owner.job_42 with target version sde.DEFAULT in the LRS workspace 387ad279-6026-4680-8171-fd17d1b9efd4.

Use dark colors for code blocksCopy
https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/reconcileVersion?f=json&targetVersion=sde.DEFAULT&editVersion=data_owner.job_42&withPost=true&lrsId=387ad279-6026-4680-8171-fd17d1b9efd4

JSON Response syntax

Example of a successful reconcile:

Use dark colors for code blocksCopy
{
  "hasConflicts": <true | false>  // whether there were conflicts during reconcile
}

Example of checkOnly=true:

Use dark colors for code blocksCopy
{
  "needsReconcile": <true | false>
}

JSON Response example

Example of an error:

Use dark colors for code blocksCopy
{
  "error": {
    "code": <errorCode>,
    "message": "<errorMessage>",
    "details": [ "<detail>", ... ]
  }
}