This endpoint is used to create a configuration for MergeFork transformation.

MergeFork transformation is used for synchronizing changes in the "reverse" (fork -> main) direction. Forked iModel must be created using one of CreateFork, FilterIModel, FilterSubCategories, FilterByViewDefinition transformations and it must have at least one new changeset with modifications for merging to succeed.

Source and target (project & iModel) properties mark the data flow direction. That said MergeFork configuration's sourceProjectId/IModelId and targetProjectId/IModelId properties must be switched places as compared to the configuration that was used to fork the iModel.

{
    "sourceProjectId": "00000000-0000-0000-0000-000000000000", // forked iModel's project id
    "sourceIModelId": "00000000-0000-0000-0000-000000000000",  // forked iModel's id
    "targetProjectId": "00000000-0000-0000-0000-000000000000", // main iModel's project id
    "targetIModelId": "00000000-0000-0000-0000-000000000000",  // main iModel's id
    "transformParameters": {
        "configurationId": "00000000-0000-0000-0000-000000000000" // id of a configuration that was used to create the fork
    }

Explanation of specific properties configuration.

configurationId - required property that specifies configuration id, which was used to fork the main iModel.

Running consecutive transformations for this configuration will keep synchronizing newly added changes from fork iModel back into the main iModel.

In addition to exported data, the transformer will also push some additional metadata. This metadata contains:

1. BisCore:RepositoryLink and BisCore:ExternalSource elements that mark the source where the data was imported from.
2. A "Scope" BisCore:ExternalSourceAspect that contains Synchronization changeset metadata that is needed by the transformation service to process any later changes correctly.
3. Element provenance information (BisCore:ExternalSourceAspects) for elements that do not have federation guids.

Differently from other transformation types, MergeFork transformation synchronizes changes in a "reverse" direction. This means that the metadata will be pushed to the source (fork) iModel instead of the target iModel.

Limitations: Since an iModel can contain multiple forks there is a possibility that any given fork and the main iModel end up with conflicting schemas, e.g., the same ECProperty in one schema is of type "number" and in another schema it is of type "string". Schema conflicts are not handled by the transformations service and in these cases the transformation will fail.

Note: Creating a configuration does not run the transformation. To run the transformation, please see transformations reference.

Authentication

Requires Authorization header with valid Bearer token for scope itwin-platform.

For more documentation on authorization and how to get access token visit OAUTH2 Authorization page.

Authorization

You must have imodels_write assigned at the target project level and imodels_read assigned at the source project level within related configuration. If permissions at the project level are not configured, then you must have same assigned at the iModel level.

Alternatively, you must be an Organization Administrator for the Organization that owns a given project the iModel belongs to.

An Organization Administrator must have at least one of the following roles assigned in User Management: Account Administrator, Co-Administrator, or CONNECT Services Administrator. For more information about User Management see Bentley Communities Licensing, Cloud, and Web Services wiki page.

Rate limits

All iTwin Platform API operations have a rate limit. For more documentation on that visit Rate limits and quotas page.