Use the modernization REST APIs to migrate third-party MDM objects from enterprise providers, such as IBM and Semarchy, to MDM SaaS.
The modernization REST APIs require a ZIP file that contains multiple canonical JSON files. The canonical JSON files contain the configuration details of the third-party MDM objects. The number of JSON files in the archive depends on the number of MDM objects.
Note:
You can't use the modernization REST APIs to migrate objects from the Multidomain MDM to MDM SaaS.
Before you begin, ensure that you have the required canonical JSON files ready.
The following table describes the required canonical JSON files:
Required JSON File
Description
Migration Mapping Index
List of all migration mapping JSON files included in the ZIP file.
Migration Mapping
Field mapping details of the source and target business entities.
The following table describes the optional JSON files that you can include in the canonical archive file:
Optional JSON File
Description
Data Model
Field properties of the target fields that you map in the migration mapping JSON file.
Reference Data Mapping
Mapping details of reference data objects from third-party providers and code lists from Reference 360.
Model Configuration Overwrites
Field properties, such as searchable, facetable, and auto suggest, of business entity fields in the migration mapping JSON file.
Survivorship
Survivorship rules of source entity fields.
Match Configuration
Match rules set configurations of source entity fields.
Security Configuration
Field-level and record-level privileges assigned to user roles.
Source System
Source systems that are associated with source entities.
Distinct Source System
Distinct source systems that are associated with source entities.
Hierarchy Relationship
Hierarchical relationships between source entities.
Network Relationship
Non-hierarchical relationships between source entities.
Users
Details of user accounts in source entities.
Guidelines for creating canonical files
Before you create canonical JSON files, consider the following guidelines:
•Identify and analyze the source business entities and their fields that you plan to migrate to MDM SaaS. Understand the data types of each field and resolve any issues related to data type mismatch before you begin.
•Create a migration mapping JSON file for each source business entity. Define the field-level mappings between the source and target business entities, and ensure data types match the target business entity.
•In the migration mapping index JSON file, list all migration mapping JSON files and include the required parameter for each entry.
•Place the migration mapping index JSON file at the root level of the ZIP archive, along with the migration mapping JSON files referenced in the index file.
Generate Canonical Schema
Use the Generate Canonical Schema API to retrieve the standardized schemas of the required and optional canonical JSON files. The API retrieves all schemas along with the data types of parameters used in the required and optional canonical JSON files.
The API supports the GET method.
GET request
To retrieve the canonical schemas of the required and optional JSON files, submit a GET request with the following URI:
GET <baseApiURL>/public/api/v1/modernization/canonical/schemas
GET response
The response is in the JSON format and returns canonical schema of all the required and optional canonical JSON files. You can use the meta information in the response to create the required and optional canonical JSON files.
GET example
To retrieve the canonical schemas of the required and optional JSON files, you might use the following request:
GET https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/canonical/schemas Content-Type: application/json Accept: application/json
The following sample response shows the retrieved canonical schemas of the required and optional JSON files:
After you run the Generate Canonical Schema API, you can use the meta information in the response to create the required canonical JSON files. To modernize third-party MDM objects, you require the migration mapping index and migration mapping JSON files.
The following table describes the migration mapping index and migration mapping JSON file contents:
File Name
Description
Migration mapping index
Names of the migration mapping files to include in the modernization process and mapping details of source and target entities.
You can list all migration mapping JSON files that you want to include in the modernization process in this file. The APIs consider only those files that have an entry in the migration mapping index file as candidates for modernization. The rest of the migration mapping files are excluded from the modernization process even if they are present in the ZIP file.
Migration mapping
Mapping details of fields mapped in the source and target entities.
You can create a migration mapping file for each source entity that you plan to modernize. For example, you can create an file named Organization-MigrationMapping for a source entity called Organization and another file named Person-MigrationMapping for a source entity called Person.
MDM SaaS assigns the default field properties to the target field when you map source entity fields to predefined MDM SaaS fields. However, if you map the source entity fields to custom fields in MDM SaaS, you can define the properties for those custom fields in the data model JSON file.
Migration Mapping Index
Create the migration mapping index JSON file to add entries to the migration mapping JSON files that you plan include in the modernization process. In this file, specify the names of the migration mapping JSON files and also the mapping details of source and target entities.
To create the migration mapping index JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the migration mapping index JSON file:
Parameters
Description
formatType
Type of the JSON file. Specify the type as MIGRATION_MAPPING_INDEX.
generationDate
Date and time when the file was created. Specify the date and time value in MM/DD/YYYY HH:mm:ss format.
checksum
Optional. Checksum for file integrity.
category
Category of the mapping used in the file. Specify the category as BUSINESS_ENTITY.
entries
List of migration mapping JSON files that you plan include in the modernization process.
The following table describes the key parameters that you can define within the entries array:
Parameter Name
Description
sourceGUID
Unique identifier of the source business entity. The sourceGUID field can be empty.
targetGUID
Internal identifier of the target business entity, such as c360.organization.
baseObjectSource
Optional. Specifies whether the source entity is a base object source column. Set the value to false.
mappingDocumentName
Name of the migration mapping JSON file, such as Person-MigrationMapping.
sourceEntity
Name of the source business entity, such as Account.
targetEntity
Name of the target business entity, such as Person.
onPremOriginalBEName
Optional. Specify the value as null.
Note:
You don't require this parameter for third-party MDM objects.
onPremRootBE
Optional. Specify the value as null.
Note:
You don't require this parameter for third-party MDM objects.
Migration Mapping
Create a migration mapping JSON file to define the field mappings of the source and target entities. In this file, specify the source and target entity details, source and target field mappings, and data types of custom fields mapped in target entities.
To create the migration mapping JSON file, use the following sample schema:
The following table describes the root parameters that you can define in the migration mapping JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as MIGRATION_MAPPING.
generationDate
Date and time when the file was created. Specify the date and time value in MM/DD/YYYY HH:mm:ss format.
checksum
Optional. Checksum value for file integrity verification.
category
Category of the mapping used in the file. Specify the category as BUSINESS_ENTITY.
mapping
List of fields to map between source and target business entities.
name
Name of the target business entity, such as Person.
guid
Internal identifier of the target business entity, c360.person.
The following table describes the key parameters that you can define in the mapping array:
Parameter Name
Description
sourceEntity
Name of the source business entity from which the data is migrated, such as Person.
sourceElement
Name of the field to map in the source business entity, such as displayName.
targetEntity
Internal identifier of the target business entity to which the data will be mapped to in MDM SaaS, such as c360.person.
targetElement
Internal identifier of the target field in the target business entity, such as x_lastname_custom.
targetElementType
Optional. Data type of the target business entity.
You can configure the field name to include data type and length or precision in parentheses, such as String(255).
The targetElementType parameter supports the following data types:
- String
- Date
- Decimal
- Integer
- Boolean
- Picklist
If you don't specify a data type, the default data type of the target field is assigned to the field.
targetFieldPath
Path to the target field. Specify the path to the target field in the <targetEntity>.<targetElement> format.
For example, specify the value as c360.person.x_lastname_custom for a target field in the Person business entity.
Naming convention for required canonical files
The modernization REST APIs identify the type of each JSON file in the canonical archive based on its file name.
The following table describes the recommended file name format for the canonical files:
File Type
Format
Migration mapping index file
<Index_File_Name>-MigrationMapping.json
Replace <Index_File_Name> with a name that reflects your project, such as SaasIndex. Ensure that the file name uses the suffix -MigrationMapping.
Migration mapping file
<Entity_Name>-MigrationMapping.json
Replace <Entity_Name> with the name of the business entity, such as Person. Ensure that the file name matches the mappingDocumentName attribute value specified in the migration mapping index JSON file.
Note:
Ensure that you use the recommended naming convention for the JSON files in the archive so that the modernization APIs can identify them correctly.
Create optional JSON files
You can include optional JSON files in the canonical archive to enhance data governance, security, and survivorship capabilities of third-party MDM objects.
You can include the following optional JSON files in the canonical archive:
Create the data model JSON file to define the field properties of custom target fields in migration mapping JSON files. The modernization process assigns default field properties of MDM SaaS to predefined target fields.
To create the data model JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the data model JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as DATA_MODEL_CHANGE.
generationDate
Date and time when the file was created. Specify the date and time value in MM/DD/YYYY hh:mm:ss format.
checksum
Optional. Checksum for file integrity.
category
Category of the mapping used in the file. Specify the category as BUSINESS_ENTITY.
businessEntityGuid
Internal identifier of the target business entity.
changes
Field properties of custom target fields in migration mapping JSON files.
path
Path to the custom field in the target entity. Specify the path to a target field in the <targetEntity> format.
For example, specify the value as c360.organization for a target field in the Organization business entity.
fieldGroupName
Optional. Specifies the custom field groups defined in the target business entity. The value can be empty if there are no field groups.
Specify the path to a custom nested field group in the <FieldGroup1>.<FieldGroup2>....<FieldGroupN> format.
For example, specify the value as PostalAddress.x_HomeAddress for a nested field group in the Organization business entity.
allowMany
Specifies whether multiple values are allowed for the field.
smartFieldGroup
Specifies whether the custom target field is a part of smart fields.
fieldDesignator
Properties of the custom target field.
The following table describes the key parameters that you can define within the fieldDesignator array:
Parameter Name
Description
id
Unique identifier of the custom field in the target business entity.
name
Internal identifier of the custom field in the target business entity.
label
Display name of the custom field in the target business entity.
description
Description of the custom field in the target business entity.
type
Data type of the custom field in the target business entity. Use one of the following values:
- String
- Picklist
- Date
- Double
- Boolean
- Integer
lookupCodeList
Name of the code list mapped to the target picklist fields. The value can be empty if the field property is not applicable.
masterCodeList
Name of the master code list mapped to the dependent picklist field in the target entity. Specify the value as null if the field property is not applicable.
beReferenceEntity
Business entity referenced to the field. You can leave the field empty if there is no references to other business entities.
length
Length of the custom field.
minLength
Minimum length of the custom field.
maxLength
Maximum length of the custom field.
precision
Precision of numeric fields, such as Double.
scale
Numeric scale used for numeric fields, such as Double.
mandatory
Specifies whether the custom field is a mandatory field in the target business entity. Use either true or false.
allowMany
Boolean. Specifies whether multiple values are allowed for the custom field. Use either true or false.
unique
Boolean. Specifies whether the custom field must be a unique field in the target business entity. Use either true or false.
position
Position or order of the custom field in the user interface.
searchable
Boolean. Specifies whether the custom field is searchable in the target business entity. Use either true or false.
autosuggest
Boolean. Specifies whether the auto suggest property is enabled for the custom field in the target business entity. Use either true or false.
facetable
Boolean. Specifies whether the custom field is facetable in the target business entity. Use either true or false.
reportable
Boolean. Specifies whether the custom field is reportable in the target business entity. Use either true or false.
The following table describes the data types of business entity fields:
Data Type
Description
String
Specifies the maximum character length, such as 255.
Picklist
Specifies the picklist fields that contain a list of values. If you specify picklist fields, then lookupCodeList field is required. The masterCodeList field is required for dependent picklist fields.
Dependent Picklist
Specifies the picklist fields that are dependent on another picklist field value. For example, picklist values of the States field dependent on the picklist values of the Countries field. If you specify dependent picklist fields, then masterCodeList must reference the parent picklist.
Date
Specifies the date data type.
Double
Specifies the numeric fields with decimals, such as currency and measurements.
Boolean
Specifies a boolean value. Use either true or false.
Integer
Specifies the numeric fields.
Naming convention for data model JSON file
The modernization APIs identify the type of each JSON file in the canonical archive based on its file name.
The following table describes the recommended file name format for the data model JSON file:
File Type
Format
Data model file
<mappingDocumentName>-ModelChanges.json
Replace <mappingDocumentName> with the mappingDocumentName attribute value in the migration mapping index file. For example, if the mappingDocumentName attribute value is Organization, then specify the file name as Organization-ModelChanges.json.
Ensure that the file name uses the suffix -ModelChanges.json. Additionally, ensure that the file name matches the attribute values of the targetEntity and mappingDocumentName specified in the migration mapping index file.
Note:
Ensure that you use the recommended naming convention for the JSON files in the archive so that the modernization APIs can identify them correctly.
Reference Data Mapping
Create the Reference Data Mapping JSON files to define field mappings between third-party reference data objects and Reference 360 code lists.
Create the following JSON files to modernize and migrate third-party reference data:
•Reference 360 Mapping Index file
•Reference 360 Mapping file
•Reference 360 Model Changes file
The following table describes the contents of the Reference 360 mapping index, migration, and model changes JSON files:
File Name
Description
Reference 360 mapping index
Name of the mapping file to include in the modernization process along with the mapping details of reference data objects from third-party providers and Reference 360 code lists.
You can list all mapping files that you want to include in the modernization process in this file. The APIs consider only those files that have an entry in the mapping index file as candidates for modernization. The rest of the mapping files are excluded from the modernization process even if they are present in the ZIP file.
Reference 360 mapping
Field Mapping details between third-party reference data objects and Reference 360 code lists.
You can create a mapping file for each third-party lookup table that you plan to modernize. For example, you can create an file named LookupCountryType-R360Mapping for a lookup table called LookupCountryType and another file named LookupStateType-R360Mapping for a lookup table called LookupStateType.
Reference 360 model changes
Field properties of target fields in the Reference 360 code lists.
Reference 360 Mapping Index
Create the reference 360 mapping index JSON file to add entries to the Reference 360 mapping files that you plan include in the modernization process. In this file, specify the name of the Reference 360 mapping JSON files and also the mapping details between reference data objects and Reference 360 code lists.
To create the Reference 360 mapping index JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the reference data mapping index file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as MIGRATION_MAPPING_INDEX.
category
Category of the mapping file. Specify the category as REFERENCE.
entries
List of Reference 360 mapping JSON files that you plan to include in the modernization process.
The following table describes the key parameters that you can define within the entries array:
Parameter Name
Description
mappingDocumentName
Name of the Reference 360 mapping JSON file.
sourceEntity
Name of the reference data object in the source entity.
targetEntity
Name of the Reference 360 code list.
sourceGUID
Optional. Unique identifier of the reference data object in the source business entity.
targetGUID
Internal identifier of the Reference 360 code list.
baseObjectSource
Optional. Specifies whether the source entity is a base object source column. Set the value to false.
onPremOriginalBEName
Optional. Specify the value as null.
Note:
You don't require this parameter for third-party MDM objects.
onPremRootBE
Optional. Specify the value as null.
Note:
You don't require this parameter for third-party MDM objects.
Reference Mapping
Create the reference mapping JSON file to define field mapping details between third-party reference data objects and fields in the Reference 360 code lists.
To create the reference mapping JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the Reference Mapping JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as MIGRATION_MAPPING.
category
Category of the mapping used in the file. Specify the value as REFERENCE.
mapping
List of fields to map between third-party reference data objects tables and Reference 360 code lists.
name
Name of the Reference 360 code list used in the mapping.
The following table describes the key parameters that you can define within the mapping array:
Parameter Name
Description
sourceEntity
Name of the reference data object in the source entity.
sourceElement
Name of the field to map in the third-party reference data object..
targetEntity
Name of the Reference 360 code list.
targetElement
Name of the field to map in the Reference 360 code list.
targetFieldPath
Optional. Path to the target field in the Reference 360 code list.
Reference Model Change
Create the reference model change JSON file to define the properties of the fields mapped in the Reference 360 code list. The Reference 360 model change JSON file is an optional file because you can't define custom fields in Reference 360 code lists for third-party reference data objects.
To create the reference model change JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the reference model change JSON file:
Field Name
Description
formatType
Type of the JSON file. Specify the type as REFERENCE_MODEL_CHANGE.
category
Category of the mapping used in the file. Specify the category as REFERENCE.
codelistName
Name of the target business entity where the code list is used. Ensure that the values defined in targetEntity and codelistName match exactly.
changes
Properties of the fields in the code list.
The following table describes the key parameters that you can define within the changes array:
Parameter Name
Description
id
Unique identifier of the target field.
name
Internal identifier of the target field.
label
Display name of the target field.
description
Description of the target field.
type
Data type of the target field. Use one of the following values:
- String
- Picklist
- Date
- Double
- Boolean
- Integer
lookupCodeList
Optional. Name of the code list mapped to the target picklist field.
masterCodeList
Optional. Name of the code list mapped to the dependent picklist field in the target entity.
beReferenceEntity
Optional. Business entity referenced to the field.
length
Length of the field.
minLength
Minimum length of the target field.
maxLength
Maximum length of the target field.
precision
Precision of numeric target fields, such as Double.
scale
Numeric scale used for numeric target fields, such as Double.
mandatory
Specifies whether the target field is mandatory. Use either true or false.
allowMany
Boolean. Specifies whether multiple values are allowed for the field. Use either true or false.
unique
Boolean. Specifies whether the target field must be a unique field. Use either true or false.
position
Position or order of the target field in the user interface.
searchable
Boolean. Specifies whether the target field is searchable. Use either true or false.
autosuggest
Boolean. Specifies whether the auto suggest property is enabled for the target field. Use either true or false.
facetable
Boolean. Specifies whether the target field is facetable. Use either true or false.
reportable
Boolean. Specifies whether the target field is reportable. Use either true or false.
Naming convention for Reference Data Mapping files
The modernization APIs identify the type of each JSON file in the canonical archive based on its file name.
The following table describes the recommended file name format for the reference 360 mapping index, reference mapping, and reference model change JSON files:
File Type
Format
Reference 360 migration mapping index file
<Index_File_Name>-R360MigrationMapping.json
Replace <Index_File_Name> with a name that reflects your project, such as SaasIndex-R360MigrationMapping.json.
Ensure that the file name uses the suffix -R360MigrationMapping.
Reference 360 migration mapping file
<Entity_Name>-R360Mapping.json
Replace <Entity_Name> with the name of the business entity, such as Person.
Ensure that the file name matches the mappingDocumentName attribute value specified in the reference 360 migration mapping index file.
Reference 360 model changes file
<mappingDocumentName>-ReferenceModelChanges.json
Replace <mappingDocumentName> with the mappingDocumentName attribute value in the Reference 360 Migration Mapping Index file. For example, if the mappingDocumentName attribute value is LookupAddressType, then specify the file name as LookupAddressType-ReferenceModelChanges.json.
Ensure that the file name matches the attribute value of the mappingDocumentName specified in the Reference 360 Migration Mapping Index file. Additionally, the targetEntity attribute value specified in the index file must match with the name or codelistName attribute value specified in the reference mapping and reference model change files.
Note:
Ensure that you use the recommended naming convention for the JSON files in the archive so that the modernization APIs can identify them correctly.
Model Configuration Overwrites
Create the model configuration JSON file to configure field properties, such as searchable, facetable, and auto suggest, for fields that are mapped in the migration mapping JSON files.
The modernization process validates the field configurations of the mapped fields against MDM SaaS limits and thresholds. If the field configurations, such as searchable, facetable, and auto-suggest exceed the defined MDM SaaS limits and thresholds, you can't continue the modernization process until you meet the limits.
The following table describes the key parameters that you can define in the model configuration overwrites JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as BE_CONFIGURATION_OVERWRITES.
category
Category of the mapping used in the file. Specify the category as BUSINESS_ENTITY.
businessEntityName
Name of the target business entity. Ensure that the name matches the targetEntity field value defined in the migration mapping JSON file.
businessEntityGuid
Internal identifier of the target business entity. Ensure that the identifier matches with the targetGUID field value defined in the migration mapping JSON file.
path
Full path of the target field in the business entity, such as c360.organization.PostalAddress.
name
Internal identifier of the target field.
label
Display name of the target field.
existingField
Boolean. Specify whether the target field is an existing field in the business entity.
configOptions
Field properties, such as searchable, facetable, or auto suggest enabled for the business entity fields.
Naming conventions for model configuration JSON file
The modernization APIs identify the type of each JSON file in the canonical archive based on its file name.
The following table describes the recommended file name format for the model configuration JSON file:
File Type
Format
Model configuration file
<mappingDocumentName>-ModelConfigOverwrites.json
Replace <mappingDocumentName> with the mappingDocumentName attribute value in the migration mapping index file. For example, if the mappingDocumentName attribute value is Organization, then specify the file as Organization-ModelConfigOverwrites.json.
Ensure that the file name uses the suffix -ModelConfigOverwrites.json. Additionally, ensure that the prefix in file name matches the attribute value of the targetEntity and mappingDocumentName specified in the migration mapping index file.
Note:
Ensure that you use the recommended naming convention for the JSON files in the archive so that the modernization APIs can identify them correctly.
Survivorship
Create the survivorship JSON file to define the survivorship rules of source entity fields that you want migrate to target fields in MDM SaaS. In this file, specify how trust scores decay over time, assign ranks to source systems, and configure field-level survivorship rules.
To create the survivorship JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the survivorship JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as TRUST_SURVIVORSHIP.
category
Category of the mapping used in the file. Specify the category as TRUST_SURVIVORSHIP.
entityName
Internal identifier of the target business entity, such as c360.person.
The following table describes the key parameters that you can define within the decayRule array:
Parameter Name
Description
maxTrustScore
Maximum trust score that you can configure. The maximum value you can specify is 1.
minTrustScore
Minimum trust score that you can configure. The minimum value you can specify is 0.1.
decayUnit
Unit of time for the decay period, such as Day, Month, or Year.
decayPeriod
Time taken for the trust score to decay.
decayPattern
Pattern in which the trust score decreases during the decay period.
Specify one of the following values:
- Slow
- Initial
- Rapid
- Later
The following table describes the key parameter that you can define within the systemRanking array:
Parameter Name
Description
sourceSystem
List of source systems that are ranked based on their trustworthiness, such as or dnb.
The following table describes the key parameters that you can define within the fields array:
Attribute Name
Description
fieldName
Name of the target field for which the survivorship rules apply, such as x_lastname_custom.
rules
Survivorship rules to migrate to the target field.
Guidelines for creating the survivorship JSON file
Consider the following guidelines when you create the survivorship JSON file:
•Ensure that you include all business entities that require survivorship rules in the entities field.
•Set the entityName value to the business entity name.
•Define the decay rule parameters and source system for the ruleConfiguration field.
•List all fields with survivorship rules in the fields field and specify the fieldName value.
•Optionally, include specific survivorship rules in the rules attribute.
•Validate the JSON schema and ensure all required fields are present.
•Ensure that you use Survivorship.json as the file name.
Match Configuration
Create the match configuration JSON file to define the match configurations of source entity fields that you want to migrate to target fields in MDM SaaS.
To create the match configuration JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the match configuration JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as MATCH_CONFIGURATION.
category
Category of the mapping used in the file. Specify the category as MATCH_CONFIG.
matchDefinitions
Match model configurations defined for a business entity. Specify at least one match definition.
The following table describes the key parameters that you can define within the matchDefinitions array:
Parameter Name
Description
entityName
Internal identifier of the target business entity, such as c360.person.
modelName
Name of the match model.
modelId
Optional. Unique identifier of the model.
modelDescription
Optional. Description of the model.
modelObjective
Objective of the match model. Specify the objective as Resolve Duplicates.
defaultPopulation
Default population used in the match model, such as usa.
declarativeRules
List of declarative match rules used in the match model.
name3InfoItem
Optional. Additional information about the NAME3 algorithm used in the match model.
candidateSelectionCriteria
Optional. Criteria used for selecting the match candidates.
The following table describes the key parameters that you can define within the candidateSelectionCriteria array:
Parameter Name
Description
fieldType
NAME3 field type used for matching. NAME3 is an algorithm that generates match scores and rule sets.
fieldName
Internal identifier of the target field.
keyGenerationalLevel
Optional. Specifies the key generation level specified for generating the match keys.
Use one of the following values:
- Extended
- Limited
- Standard
candidateSearchLevel
Optional. Match candidate search level.
Use one of the following values:
- Exhaustive
- Narrow
- Typical
- Extreme
The following table describes the key parameters that you can define within the rulePropertyThresholds array:
Parameter Name
Description
matchStrategy
Strategy used for matching, such as FUZZY or EXACT.
mergeStrategy
Strategy used for merging records.
matchCriterion
Match criteria used for FUZZY match strategy, such as Person_Name.
matchLevel
Indicates the level of fuzzy matching.
description
Optional. Specifies the description of the match rule.
automatedMerge
Optional. Threshold score for automated merge.
The following table describes the key parameters that you can define within the requiredExactFields array:
Parameter Name
Description
fieldName
Internal identifier of the target field.
comparisonOutcome
Expected comparison outcome of match fields.
sourceColumnName
Optional. Display name of the source object column, such as C_PARTY|DISPLAY_NAME.
matchColumnName
Optional. Display name of the match column in the source entity, such as Organization_Name.
segmentMatching
Optional. Specifies whether segment matching is enabled.
matchSegmentDataWithOtherData
Optional. Specifies whether segment data matches with other data.
segmentValues
Optional. List of segment values.
nullMatchIndicator
Optional. Specifies whether null matching is enabled.
The following table describes the key parameters that you can define within the requiredFuzzyFields array:
Parameter Name
Description
fieldType
NAME3 field type used for matching.
fieldName
Internal identifier of the target field.
comparisonOutcome
Expected comparison outcome of match fields.
sourceColumnName
Optional. Display name of the source object column, such as C_PARTY|DISPLAY_NAME.
matchColumnName
Optional. Display name of the match column in the source entity, such as Organization_Name.
The following table lists the populations that you can use within the matchDefinitions array:
Population
Description
Arabic
Standard script for the Arabic population.
Arabic_m
Contains a mix of Arabic, Romanized Arabic, English, and Arabicized English scripts for the Arabic population.
Arabic_r
Romanized Standard script for the Arabic population.
Argentina
Standard script for the Argentine population.
Australia
Standard script for the Australian population.
Belgium
Standard script for the Belgian population.
Brasil
Standard script for the Brazilian population.
Bulgaria_c
Bulgarian Cyrillic Standard script for the Bulgarian population.
Bulgaria_r
Bulgarian Romanized script for the Bulgarian population.
Canada
Standard script for the Canadian population.
Chile
Standard script for the Chilean population.
Chinese
Standard script for the Chinese population.
Chinese_i
Traditional Chinese Standard script for the Chinese population.
Chinese_r
Chinese Romanized Standard script for the Chinese population.
Chinese_s
Simplified Chinese Standard script for the Chinese population.
Chinese_t
Traditional Chinese Standard script for the Chinese population.
Colombia
Standard script for the Colombian population.
Croatia
Standard script for the Croatian population.
Czech
Standard script for the population of Czech Republic.
Denmark
Denmark Standard script for the Danish population.
Estonia
Standard script for the Estonian population.
Finland
Standard script for the Finnish population.
France
Standard script for the French population.
Gaelic
Standard script for the Gaelic-speaking population.
Germany
Standard script for the German population.
Greek
Standard script for the Greek population.
Greek_l
Greek Mixed Standard script for the Greek population.
Hebrew
Standard Hebrew script for the Israeli population.
Hk_r
Romanized Standard script for the population of Hong Kong.
Hungary
Standard script for the Hungarian population.
India
Standard script for the Indian population.
Indo_chin_r
Standard script for the Indo-Chinese population.
Indonesia
Standard script for the Indonesian population.
International
International Latin-1 Standard script.
Ireland
Standard script for the Irish population.
Italy
Standard script for the Italian population.
Japan
Standard script for the Japanese population.
Japan_r
Romanized Standard script for the Japanese population.
Kazakhstan
Standard script for the population of Kazakhstan.
Korean
Standard script for the Korean population.
Korean_r
Romanized Standard script for the Korean population.
Luxembourg
Standard script for the population of Luxembourg.
Malaysia
Standard script for the Malaysian population.
Malta
Standard script for the population of Malta.
Mexico
Standard script for the Mexican population.
Netherlands
Standard script for the Dutch population.
New Zealand
Standard script for the population of New Zealand.
Norway
Standard script for the Norwegian population.
Peru
Standard script for the population of Peru.
Philippines
Standard script for the population of Philippines.
Poland
Standard script for the Polish population.
Portugal
Standard script for the Portuguese population.
Puerto_rico
Standard script for the Puerto Rican population.
Romania
Standard script for the Romanian population.
Russia
Standard script for the Russian population.
Singapore
Standard script for the population of Singapore.
Slovakia
Standard script for the Slovak population.
South_africa
Standard script for the South African population.
Spain
Standard script for the Spanish population.
Sweden
Standard script for the Swedish population.
Switzerland
Standard script for the Swiss population.
Taiwan_r
Romanized Standard script for the Taiwanese population.
Thai
Standard script for the Thai population.
Thai_r
Romanized Standard script for the Thai population.
Turkey
Standard script for the Turkish population.
Uk
Standard script for the population of UK.
Usa
Standard script for the population of USA.
Vietnam_r
Romanized Standard script for the Vietnamese population.
Guidelines for creating the match configuration JSON file
Consider the following guidelines when you create the match configuration JSON file:
•Specify the formatType field value as MATCH_CONFIGURATION.
•Specify required values for all attributes within the matchDefinitions field.
•Ensure that the entityName field value in the Match Configuration file matches with the targetGUID field value from the Migration Mapping Index file.
•Populate the defaultPopulation value for each match definition.
•Define at least one declarative rule with appropriate thresholds and field configurations.
•Validate JSON syntax and ensure all mandatory fields are present.
•Use MatchConversion.json as the file name.
Security Configuration Overwrites
Create the security configuration JSON file to define the field-level and record-level privileges of source entity fields that you want to migrate to target fields in MDM SaaS. In this file, specify which user roles have privileges to create, read, update, delete, merge, and execute operations on specific fields or records.
To create the security configuration JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the security configuration JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as ENTITY_SECURITY.
generationDate
Date and time when the file was created. Specify the date and time in MM/DD/YYYY HH:mm:ss format.
checksum
Optional. Checksum for file integrity.
category
Category of the mapping used in the file. Specify the category as SECURITY.
The following table describes the key parameters that you can define within the list array:
Parameter Name
Description
entityName
Name of the target business entity associated with the user role. Ensure that the entityName attribute value matches the entityName field value specified in the migration mapping index file.
entityGuid
Internal identifier of the target business entity, such as c360.organization. The value must exactly match the targetGUID value in the migration mapping index file.
elements
Security privileges associated with target business entity fields.
The following table describes the key parameters that you can define within the elements array:
Parameter Name
Description
elementType
Type of the target object to which the security privileges is assigned.
Specify the elementType parameter value as FIELD.
fieldSecurity
Optional. Security privileges assigned to the field. This attribute is required only if you specify the elementType as FIELD.
The following table describes the key parameters that you can define within the fieldSecurity array:
Parameter Name
Description
fieldName
Path to the target field. Specify the path to the target field in <targetEntity>.<targetElement> format.
For example, specify the value as c360.organization.x_custom for a target field in the Organization business entity.
matrix
User role privileges associated with the field. If you specify the matrix attribute, then roleName attribute values must be present.
The following table describes the key parameters that you can define within the matrix array:
Parameter Name
Description
roleName
Unique name of the user role within each matrix attribute. Ensure that you don't use any special characters or trailing spaces.
create
Create privilege assigned to the user role. Specify either true or false.
read
Read privilege assigned to the user role. Specify either true or false.
update
Update privilege assigned to the user role. Specify either true or false.
delete
Delete privilege assigned to the user role. Specify either true or false.
merge
Merge privilege assigned to the user role. Specify either true or false.
execute
Execute privilege assigned to the user role. Specify either true or false.
Guidelines for creating the security configuration JSON file
Consider the following guidelines when you create the security configuration JSON file:
•Specify the formatType field value as ENTITY_SECURITY.
•Validate whether the JSON file is correctly formatted and syntactically correct.
•Ensure that the entityname and entityGuid attribute values match with the corresponding values specified in the migration mapping files.
•Define security privileges for fields, entities, or lists of entities using the appropriate elementType attribute.
•Ensure that names don't contain special characters and are unique within each matrix attribute.
•Specify all security privileges, such as create, read, update, delete, merge, execute as boolean values.
•Ensure that fieldName attribute value includes the full path with the business entity name added as prefix.
•Use consistent date and time format for the generationDate field.
•Use Security.json as the file name.
Source System
Create the source system JSON file to define source systems that you want to migrate to MDM SaaS. In this file, specify a unique internal ID for each source system and include metadata, such as display name, description, and location.
To create the source system JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the source system JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as SOURCE_SYSTEM.
generationDate
Date and time when the file was created. Specify the date and time value in MM/DD/YYYY HH:mm:ss format.
checksum
Optional. Checksum for file integrity.
category
Category of the mapping used in the file. Specify the category as SOURCE_SYSTEMS.
entries
List of source systems.
The following table describes the key parameters that you can define within the entries array:
Parameter Name
Description
displayName
User-defined name of the source system.
internalId
Internal identifier of the source system. The internalId attribute is referenced by fields within distinct source system JSON file. Additionally, the internalId attribute value must match with the sourceSystem attribute value in the Survivorship.json file.
description
Description of the source system.
location
Location of the source system.
Guidelines for creating the source system JSON file
Consider the following guidelines when you create the source system JSON file:
•Specify the formatType field value as SOURCE_SYSTEM.
•Ensure that entries field includes at least one source system.
•Assign a unique identifier to each source system.
•Specify all mandatory fields, such as displayName, internalId, and location.
•Use SourceSystem.json as the file name.
Distinct Source Systems
Create the distinct source systems JSON file to define distinct source systems that you want to migrate to MDM SaaS. When source systems are marked as distinct, the match process doesn't match records from the same source system.
To create the distinct source systems JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the distinct source systems JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as DISTINCT_SOURCE_SYSTEM.
category
Category of the mapping used in the file. Specify the category as DISTINCT_SOURCE_SYSTEM.
entries
List of distinct source systems.
The following table describes the key parameters that you can define within the list array:
Parameter Name
Description
targetEntityName
Name of the target business entity. Ensure that the targetEntityName attribute value matches with the targetEntity attribute value in the migration mapping index file.
targetEntityGUID
Internal identifier of the target business entity. Ensure that the targetEntityGUID attribute value matches with the targetGUID attribute value in the migration mapping index file.
distinctSourceSystems
List of distinct source systems in the target entity.
sourceSystemName
Name of the source system. Ensure that the sourceSystemName attribute value matches with the internalId attribute value in the SourceSystem.json file.
autoMerge
Specifies whether automated merge is enabled. Specify either true or false.
Guidelines for creating the distinct source systems JSON file
Consider the following guidelines when you create the distinct source systems JSON file:
•Ensure that the list field includes all required attribute values, such as targetEntityName, targetEntityGUID, distinctSourceSystems, sourceSystemName, and autoMerge.
•Use DistinctSourceSystem.json as the file name.
Hierarchy Relationship
Create the hierarchy relationship JSON file to define hierarchical relationships between business entities that you want to migrate to MDM SaaS. Specify the parent-child relationships, organizational structures, and other hierarchical associations that exist within or across business entities in this file.
To create the hierarchy relationship JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the hierarchy relationship JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as PROVISIONING_HIERARCHY.
category
Category of the mapping used in the file. Specify the category as PROVISIONING_HIERARCHY.
generationDate
Date and time when the file was created. Specify the date and time value in MM/DD/YYYY HH:mm:ss format.
checksum
Optional. Checksum for file integrity.
hierarchies
List of hierarchy relationships within a business entity.
The following table describes the key parameters that you can define in the hierarchies array:
Parameter Name
Description
name
Name of the hierarchy.
guid
Internal identifier of the hierarchy.
description
Description of the hierarchy.
location
Location of the hierarchy.
rootEntity
Name of the parent business entity in the hierarchy.
relationships
Relationship details of the hierarchy.
The following table describes the key parameters that you can define in the relationships array:
Parameter Name
Description
name
Name of the relationship.
description
Description of the relationship.
direction
Direction of the relationship.
The direction parameter can contain one of the following values:
- ENTITY_1_TO_ENTITY_2
- ENTITY_2_TO_ENTITY_1
- BIDIRECTIONAL
fromEntity
Source business entity in the relationship.
toEntity
Target business entity in the relationship.
biDirectional
Specifies whether the relationship is bidirectional. Specify the value as true if the bidirectional relationship is enabled. Otherwise, specify the value as false.
Guidelines for creating the hierarchy relationship JSON file
Consider the following guidelines when you create the hierarchy relationship JSON file:
•Specify the formatType field value as PROVISIONING_HIERARCHY.
•Specify at least one hierarchy relationship.
•Ensure that the fromEntity and toEntity field values reference corresponding targetGUID field value in the Migration Mapping Index file.
•Ensure that the rootEntity field value matches the corresponding business entity name in the migration mapping file.
•Use ProvisioningHierarchies.json as the file name.
Network Relationship
Create the network relationship JSON file to define non-hierarchical relationships between business entities that you want to migrate to MDM SaaS. Specify non-hierarchical relationships, such as employment, partnerships, affiliations, or other non-hierarchical relationships between entities in this file.
To create the network relationship JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the network relationship JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as PROVISIONING_NETWORK.
category
Category of the mapping used in the file. Specify the category as PROVISIONING_NETWORK.
generationDate
Date and time when the file was created. Specify the date and time value in MM/DD/YYYY HH:mm:ss format.
checksum
Optional. Checksum for file integrity.
relationships
List of non-hierarchical relationships within a business entity.
The following table describes the key parameters that you can define in the relationships array:
Parameter Name
Description
name
Name of the relationship.
description
Optional. Description of the relationship.
direction
Direction of the relationship.
The direction parameter can contain one of the following values:
- ENTITY_1_TO_ENTITY_2
- ENTITY_2_TO_ENTITY_1
- BIDIRECTIONAL
fromEntity
Source business entity in the relationship.
toEntity
Target business entity in the relationship.
biDirectional
Specifies whether the relationship is bidirectional. Specify the value as true if the bidirectional relationship is enabled. Otherwise, specify the value as false.
Guidelines for creating the network relationship JSON file
Consider the following guidelines when you create the network relationship JSON file:
•Specify the formatType and category field values as PROVISIONING_NETWORK.
•Specify at least one non-hierarchical relationship.
•Ensure that the fromEntity and toEntity field values reference corresponding targetGUID field value in the migration mapping index file.
•Identify and include all non-hierarchical relationships between entities correctly in the JSON file.
•Define the direction of the relationships, such as unidirectional or bidirectional, clearly.
•Provide meaningful names to the relationships, such as Employs, SuppliesTo, or PartneredWith.
•Use ProvisioningNetworks.json as the file name.
Users
Create the users JSON file to define the user accounts that you want to migrate to MDM SaaS. In the file, specify essential user profile information, such as contact details, security role assignments, and account status. The modernization process requires this file to set up user access and privileges in MDM SaaS.
To create the users JSON file, use the following sample schema:
The following table describes the key parameters that you can define in the users JSON file:
Parameter Name
Description
formatType
Type of the JSON file. Specify the type as USER_SECURITY.
category
Category of the mapping used in the file. Specify the category as SECURITY.
userDetails
Details of the user accounts.
The following table describes the key parameters that you can define in the userDetails array:
Parameter Name
Description
USER_NAME
Unique user name associated with the user account.
Note:
Ensure that the names don't contain Unicode characters.
FIRST_NAME
First name of the user.
LAST_NAME
Last name of the user.
EMAIL
Email address of the user.
ROLES
List of user roles associated with each user. Specify a comma-separated list of role names. Ensure that you associate at least one role with each user and the role names match user names defined in the security configuration JSON file.
USER_ENABLED_IND
Specifies whether the user is active. Specify the value as 1 if the user is active. Otherwise, specify the value as 0.
ADMIN_IND
Specifies whether the user is an administrator.
IS_EXTERNAL
Specifies whether the user is an external user.
Guidelines for creating the users JSON file
Consider the following guidelines when you create the users JSON file:
•Ensure that user names have unique values and don't contain Unicode characters.
•Assign at least one user role to every user.
•Specify all required fields, such as USER_NAME, FIRST_NAME, LAST_NAME, EMAIL, ROLES, USER_ENABLED_IND, ADMIN_IND, and IS_EXTERNAL.
•Use Users.json as the file name.
Create Modernization Project
Use the Create Modernization Project API to define modernization projects for migrating third-party MDM objects from enterprise providers, such as IBM and Semarchy, to MDM SaaS.
The API supports the POST method.
POST request
To define a modernization project, submit a POST request with the following URI:
POST <baseApiURL>/public/api/v1/modernization/create-mod-project
You can use the following parameters in multipart form data in the request body:
Parameter
Type
Description
projectName
String
Name of the modernization project.
applicationId
String
MDM SaaS business application in MDM SaaS to which you want to add the modernized business entities.
Use one of the following values:
- c360.c360
- p360.p360
- s360.s360
- mde.mde
projectType
String
Type of modernization project. Specify the project type as THIRD_PARTY_MDM.
canonicalArchive
ZIP File
A ZIP file that contains the configuration details of third-party MDM objects that you want to migrate.
The ZIP file size limit is 99 MB.
POST response
The response is in the JSON format and returns the HTTP 200 OK response code along with the project name, status, and ID.
POST example
You might use the following sample request to define a modernization project:
POST https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/create-mod-project Content-Type: multipart/form-data IDS-SESSION-ID: XXXXXXXXXXXXXXXXXXXXXX Body (form-data): projectName: Modernization_Demo_doc_test10 applicationId: c360.c360 projectType: THIRD_PARTY_MDM canonicalArchive: [file: canonical_files.zip]
The following sample response returns the HTTP 200 OK response code with the name, status, and ID of the project:
Use the Download Canonical File API to download the canonical ZIP archive file that you can use for creating a third-party modernization project.
The API supports the POST method.
POST request
To download a canonical file, submit a POST request with the following URI:
POST <baseApiURL>/public/api/v1/modernization/download-canonical?projectId=<projectId>
The following table describes the query parameters for the POST request:
Parameter
Type
Description
projectId
String
Unique identifier of the modernization project.
POST response
The response body is a binary ZIP file. To view the contents of the file, save the response to a local drive and extract the archive using any standard ZIP utility.
POST example
You might use the following sample request to download a canonical file:
POST https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/download-canonical?projectId=69d49dd4f7377b9a125d33c9 Content-Type: application/json IDS-SESSION-ID: XXXXXXXXXXXXXXXXXXXXXX
The following sample response returns the HTTP 200 OK response code and the contents of the binary ZIP file:
HTTP/1.1 200 OK Content-Type: application/zip <Binary ZIP file content>
After you save and extract the ZIP file, you can view the canonical file formats, such as Migration Mapping Index, Migration Mapping, and Data Model, that are used in the project.
View Modernization Project Status
Use the View Modernization Project Status API to view the status of a third-party modernization project.
The API supports the GET method.
GET request
To view the status of a modernization project, submit a GET request with the following URI:
GET <baseApiURL>/public/api/v1/modernization/projectstatus?projectId=<projectId>
The following table describes the query parameters for the GET request:
Parameter
Type
Description
projectId
String
Unique identifier of the modernization project.
GET response
The response is in the JSON format and returns the status of the modernization project.
The following table describes the response body parameters:
Parameter
Type
Description
projectStatusList
String
Status of the modernization projects.
skip
Boolean
Specifies whether the project status entry is skipped.
id
String
Unique identifier for the project status entry.
projectId
String
Unique identifier of the modernization project.
projectName
String
Name of the modernization project.
group
String
Group to which the project status belongs.
status
String
Status of the project.
The status parameter can contain one of the following values:
- SUCCESS
- IN PROGRESS
FAILED
step
String
Details of the step.
totalCount
Integer
Total count of the modernization projects.
The following table describes the step object with the following parameters:
Parameter
Type
Description
id
String
Unique identifier for the step.
type
String
Type of the step. Returns null if not applicable.
name
String
Display name of the step.
status
String
Status of the step. Returns null if not applicable.
errorStatus
Array
Error statuses associated with the step. Returns an empty array when the step has no metrics.
metrics
Array
Metrics associated with the step. Returns an empty array when the step has no metrics.
GET example
You might use the following sample request to view the status of a modernization project:
GET https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/projectstatus?projectId=69d49dd4f7377b9a125d33c9 Content-Type: application/json IDS-SESSION-ID: XXXXXXXXXXXXXXXXXXXXXX
The following sample response contains the HTTP 200 OK response code and the status of the modernization project:
Use the View Canonical Formats API to view the list of required and optional canonical file formats that you can use in third-party modernization projects.
The API supports the GET method.
GET request
To view the list of canonical file formats, submit a GET request with the following URI:
GET <baseApiURL>/public/api/v1/modernization/canonical/formats
GET response
The response is in the JSON format and returns the list of required and optional canonical file formats.
GET example
You might use the following sample request to view the list of canonical file formats:
GET https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/canonical/formats Content-Type: application/json IDS-SESSION-ID: XXXXXXXXXXXXXXXXXXXXXX
The following sample response returns the HTTP 200 OK response code and the canonical file formats:
Use the Generate Canonical Schema API to retrieve the standardized schemas of the required and optional canonical JSON files. The API retrieves all schemas along with the data types of parameters used in the required and optional canonical JSON files.
The API supports the GET method.
GET request
To retrieve the canonical schemas of the required and optional JSON files, submit a GET request with the following URI:
GET <baseApiURL>/public/api/v1/modernization/canonical/schemas
GET response
The response is in the JSON format and returns canonical schema of all the required and optional canonical JSON files. You can use the meta information in the response to create the required and optional canonical JSON files.
GET example
To retrieve the canonical schemas of the required and optional JSON files, you might use the following request:
GET https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/canonical/schemas Content-Type: application/json Accept: application/json
The following sample response shows the retrieved canonical schemas of the required and optional JSON files:
Use the Download Event Logs API to download the event logs as a binary ZIP file. Use the event logs file to analyze important events or troubleshoot issues encountered during the modernization process.
The API supports the GET method.
GET request
To download an event logs file, submit a GET request with the following URI:
GET <baseApiURL>/public/api/v1/modernization/download-events?projectId=<projectId>
The following table describes the query parameters for the GET request:
Parameter
Type
Description
projectId
String
Unique identifier of the modernization project.
GET response
The response body is a binary ZIP file. To view the contents of the file, save the response to a local drive and then use a standard ZIP utility to extract the archive.
GET example
You might use the following sample request to download an event logs file:
GET https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/download-events?projectId=69d4d7f2c1593500962e1cae Content-Type: application/json IDS-SESSION-ID: XXXXXXXXXXXXXXXXXXXXXX
The following sample response contains the HTTP 200 OK response code and the contents of the binary ZIP file:
HTTP/1.1 200 OK Content-Type: application/zip <Binary ZIP file content>
The extracted files contain the event logs captured during the modernization process.
View Modernization Project Details
Use the View Modernization Project Details API to view the details of a third-party modernization project.
The API supports the GET method.
GET request
To view the details of a modernization project, submit a GET request with the following URI:
GET <baseApiURL>/public/api/v1/modernization/project/<projectId>
The following table describes the query parameters for the GET request:
Parameter
Type
Description
projectId
String
Unique identifier of the modernization project.
GET response
The response is in the JSON format and contains the details of the modernization project.
The following table describes the response body parameters:
Parameter
Type
Description
canonicalArchiveFileName
String
Name of the canonical archive ZIP file used in the project.
projectType
String
Type of the modernization project.
The project type parameter can contain one of the following values:
- AUTO_BE_MAPPING. Projects that use automated or smart field mappings for migration.
- BASIC. Projects that use manual field mappings for migration.
- THIRD_PARTY_MDM. Projects that use third-party MDM objects for migration.
projectName
String
Name of the modernization project.
applicationId
String
Unique identifier of the business application in MDM SaaS to which the third-party MDM objects are migrated.
currentStep
String
Current step in the project workflow.
The currentStep parameter can contain one of the following steps:
Use the migrate hierarchical relationships API to migrate hierarchical relationships associated with third-party MDM objects that are ready for modernization.
The API supports the POST method.
POST request
To migrate third-party hierarchical relationships, submit a POST request with the following URI:
POST <baseApiURL>/public/api/v1/modernization/migration/migrate-saas-tenanthierarchyrelationship?projectId=<projectId>
The following table describes the query parameters for the POST request:
Parameter
Type
Description
projectId
String
Unique identifier of the modernization project.
POST response
The response is in the JSON format and returns a success message.
POST example
You might use the following sample request to migrate third-party hierarchical relationships:
POST https://use4-mdm.dm-us.informaticacloud.com/public/api/v1/modernization/migration/migrate-saas-tenanthierarchyrelationship?projectId=69d49dd4f7377b9a125d33c9 Content-Type: application/json IDS-SESSION-ID: XXXXXXXXXXXXXXXXXXXXXX
The following response contains the HTTP 200 OK response code and the success message: