Associating the Metadata Definitions

In order to associate and synchronize objects and their metadata between different vaults, the metadata definitions must also be associatable between different vaults.

Associations between metadata definitions can be made in several ways depending on how the vaults are used. Certain metadata definitions are always associated automatically. Some of them are associated automatically according to the vault structure, but for some of them, it must be done manually using aliases.

Purpose of the vault vs. metadata associations

Associations between metadata can be created in several ways, depending on the purpose of use of the vaults. The target vault can be used in archiving, replication, backups, and publication. For this reason, you should consider – before creating a vault that might be used as a target vault – which implementation is the easiest and best for creation of the desired vault.

If the association and synchronization is performed between two or more existing vaults, check the association of the metadata definitions and define the scheduled export and import between vaults.

Perfect copy (for example replication, archiving, and backup)

If you want the vaults to be perfect – full and complete – copies of each other in terms of both metadata and contents, you should first create a target vault through backup or copy of the relevant vault and then define the export and import. This way, especially the metadata definitions are automatically matched with the names and IDs and any separate definition of aliases need not be performed one metadata definition at a time.

Note: Metadata definitions created after creation of the vault must be manually associated between vaults by using aliases.

Partially the same metadata structure and partially the same contents (for example vaults intended for different purposes in the company)

If you want the metadata largely matching each other between vaults, you should consider first creating the metadata structure of the target vault through metadata structure export (see Export Structure) and then define the export and import. After this, you should verify in the target vault that the metadata structure corresponds to the use of the target vault.

Note: Metadata created after creation of the vault must be manually associated between vaults by using aliases.

Different metadata structure but partially the same content (for example, publication of certain objects from one vault to another)

If you want to publish only certain objects and metadata in the so-called publishing vault, you should create the metadata structure of the publishing vault separately from that of the source vault.

In this case, aliases must be defined for all other metadata structures than built-in ones, so that metadata can be associated when the synchronization is performed.

Association of the metadata

By default, M-Files associates metadata by the following methods (in order of relevance):

Aliases for association of the metadata between vaults

Because only the built-in metadata definitions and those matching the GUID or ID and name are associated automatically, for other metadata definitions the association must be performed by using aliases.

Aliases can be used for identifying semantically equivalent metadata. For example, when importing objects from another vault, their Date and Description properties can be mapped to the target vault's equivalent properties on the basis of aliases even if the properties' internal IDs and/or names are different. That is, the aliases refer to semantically equivalent metadata in different vaults. In other words, alias is a common identifier for the same metadata definition between several vaults.

The alias is defined as a common ID with the same name in both source and target vault.

When defining the alias, you can use various external data type and archive standards, such as SÄHKE2, MoReq2, and Dublin Core.

Check that there are sufficient definitions for all desired metadata definitions so that the association can be performed. Check the following: object types, value lists, property definitions, classes and class groups, workflows and workflow states, user groups, and named access control lists. In the properties of these metadata definitions, you can find the Advanced tab, where you can define the alias(es) for the metadata definitions.

For example, the source vault has the property definition Telephone number, whose vault-specific ID is 1001. The semantically equivalent property definition is also in the target vault, but the vault-specific ID is 1005 – the name can be the same ("Telephone number") or different (for example, "Phone" or "Phone number"), in the default language. If you want to associate these, you must define a common alias for this property definition in both vaults. The alias can be anything, such as Telephone number or dc.PhoneNumber, as long as it is the same in both vaults.

The alias is not shown to the users in M-Files Desktop; that is, the users see the name of the vault-specific property definition, just as before.

Note: If there are several metadata definitions with the same alias in the target vault, the association is bypassed for these and the data will not be imported to the target vault.

Login Accounts

Depending on the purpose of use of the target vault, the users of the target vault may be the same as, or entirely different from, those of the source vault. If you want to grant certain users permissions for both vaults and/or synchronize the metadata for the Users value list, you should create user accounts with the same name for these users for both vaults. User accounts are not automatically synchronized between vaults.

Related objects in separate vaults

The interaction between several vaults enables creation of relationships between objects across vaults. The objects are not exported from one vault to another; instead, the relationship is created by reference to an object in another vault; that is, a link is created to the original object. The object types of the objects must be associatable, but synchronization of the objects (replication of content) is not required, because the objects are not transferred from one vault to another. For more information, see Relationships between objects in separate vaults under Relationships.