Maintain Migration

This topic relates to the following sections:

• Create & Maintain Datasets

• Maintain Data Elements

• Bulk Edit of Existing Data Elements

• Maintain Tables and Fields

• Import / Export Datasets

About Maintaining the Migration Tab

Within the Dataset, the Tables that are imported into a Mapping Release are set as Migration relevant. This action is reflected by activating the tab Migration within the Dataset. This tab provides the details for each table and field that is part of the migration process.

The Migration tab is only visible if the Dataset was imported into a Mapping Release, therefore making the Dataset migration relevant.  If the Dataset is not migration relevant, there is no tab for Migration.  Refer to section Migrate > Mappings > Import Datasets to Mappings for details of importing a dataset to a Mappings Release. 

Details of the Migration Tab

View the following page by navigating to Catalog > Dataset Design from Syniti Migrate Home page.

From within the Dataset, click tab Migration to display the page data. The Migration tab displays all the fields from Tables and Fields tab.  From this tab, only the fields marked as Element Active OR Active for Mapping copy into the Mapping process.  

This page contains two panels like Tables and Fields page where each table is listed in the Tables panel, and the associated fields of the highlighted table are provided and editable within the Columns panel.

Note

The Migration Key toggle may be updated on the Migration page, but all other fields are maintained within the Edit page. The fields Element Key, and Element Active are display only for the Migration page.

The Data Type value for the Fields is set to the Working Database translation.  It varies from the Data Type format used in Data Elements or Tables and Fields Tabs.

Note

The standard for Migration Key fields is to use the legacy Key fields and ZSOURCE and ZDEPLOY.  The target table for the object uses these key fields so that if the Target table KEY fields are built during the loading of data to the Target system (internally generated) there is still a valid unique set of key fields.  Reading back the new key fields from target system requires loading to that system a unique key field value that can then be used in updating the Object after loading the data.

Users may decide to mark the target key fields as the Key fields if they know that these fields are externally generated.  However, doing this may run the risk of downstream issues and visibility of the legacy key fields for use in mapping these fields for other related Objects may be lost. 

Data Types within the Dataset

Data Types vary depending upon the Working Database used and the Target System used.  In the most basic situation, where SQL Server is the Working Database, and SAP ECC or S4H is the Target System, the Data Types for the Tables and Fields and Data Elements tabs is set to the Target System (ECC, S4H) Example:  CHAR, DATS, or NUMC. 

The Migration tab contains Data Types for the Working Database being used.  As example, the user sees Data Types as:

Add a Field to a Migration Table Independent of Dataset Design

The Developer may add a new field to the Migration target table by clicking Add  button.  The fields are generally used to benefit the process of validation of the data. Examples of fields are ZOpenPO, ZOpen2Yr, ZACTIVESales, etc.  The Data Element page displays to allow for adding details of this data element that is relevant to Migration. 

Note

If the project team has added a new field to a Target table in the target system, the user would add the field by first adding it to the Datasources tables of the Datasource, and then performing a Sync of the fields to pull that field into the Dataset Design process.  Refer to section Catalog > Dataset Design > Maintain Tables and Fields  for more detailed information on this process.  

Refer to section Catalog > Dataset Design > Maintain Data Elements for more detailed information on creating this new data element. 

Note

During this process, the user updates field Active for Mapping to = Yes as this new field is active for the mapping process.  Once the Data Element is saved, the system automatically updates the field Is Migration Specific to Active.

Regardless of whether the Active for Mapping field has been set to Active, the new field is added to both the Target table and Working table automatically within a few minutes of saving the changes. The new field is also added to the Mapping page automatically.

Syniti Standard Fields for Use in Mapping

When the tables are added to the Tables and Fields page, the Syniti Standard fields (EX: ZACTIVE, ZCRITICAL, ZLEGACYXX, ZSOURCE, or ZDEPLOY) are left off the list.  The Syniti Standard fields are not a part of Data Elements or Tables and Fields tabs. 

They are only present in the Migration tab, but the Dataset must first be assigned to a Release within Mappings before these Syniti Standard Fields are added to the tables.  Any added tables for the same Dataset automatically populates the Syniti Standard fields at time of adding the table. 

Note

At the point that the Dataset is imported and assigned to a Release within Mappings, Syniti Standard Fields are added to each of the Target tables stored in the Migration tab.  These are fields that are automatically added to each of these target tables for use in mapping and migration of data and have no relevance to data governance. Also, at this point, the data types for each of the Migration page Target table fields are translated to represent the Working Database Translations (ex: SQL Server, HANA DB, or Oracle DB).

To edit the details of the fields, click on the Edit  icon on the left side of the row you want to edit. From this window, the field details can be edited, as shown below.

Dataset Design: Migration: Data Element Details

At this point, the page opens to provide access to maintain the Data Element Details. For more details of this process, navigate to Catalog > Dataset Design > Maintain Data Elements.

Data Elements are Active or Inactive for Mapping

Depending upon the use of a field, it becomes Active or Inactive for Migration Mapping.  In the example page below, the Syniti Standard fields are all marked as Active for Mapping.  This is due to these fields being part of the mapping process, but NOT part of the actual load of data into SAP.  The Migration Key fields all default as Active for Mapping as well as ZACTIVE and ZCRITICAL.  However, all other fields default with no value as this field only requires a value if the situation is not standard (Element active fields s/b Active for Mapping). 

A field may be marked as Element Active for use in Data Elements yet also be marked as Inactive for Mapping (Ex: Field MANDT may not be necessary for loading data into the target system, but yet may be relevant for data elements). 

When the field is marked as Active for Mapping, the system automatically updates field Is Migration Specific for Active as well.  This indicates that the user plans to use this field for Mapping but not for Dataset Design.  This is the Hard Wall between the Dataset Designer adding fields for the actual Dataset, and the Migration Team adding fields for data migration.

When finished with edits, click the Save  icon to complete.