Syniti Migrate

Create Reports

This topic is related to sections:

This page contains the following sections:

About Creating Reports

Reports are a vital tool to inform people of the status of the data. They draw attention to issues and provide details of completeness. Reports are also a good way to track defects and can help reassure the client that defects have been resolved.

The Target Reports of a migration project are stored within the Target Table panel of Mappings. These reports are generated as part of an automated process, but require individual attention to ensure that they contain all relevant fields, keys, and information for the user to make an informed decision about the health of the data being loaded to the target system. Along with the auto generated reports, there are many additional manually designed and built reports to support the extract, translation and loading of data to the target to make sure that the expected results are accurate and without issues. Finally, these reports are generated for use in Oracle, HANA, and SQL Server database systems.

Migration Report Types

The types of reports automatically generated depend upon the target table and setup:

An ERROR is any record that should not exist at go live. Not all errors are critical errors, some are simple cleanup errors.

The Readiness reports are a set designed to flag the row of data as NOT relevant to load due to the missing readiness indicator. They are defined below:

Data Readiness -

Ideally every vendor would have a phone, fax, and email. But we would still want to load these vendors even if they are missing this data, so this would be a Data Readiness Error.

Business Readiness -

Some errors are not critical such that they prevent data loads, but they may cause Business harm or confusion. For example, the Business may decide that if we cannot load ALL the components of a BOM, then we should not load any of the BOM, because a partially correct BOM would invalidate testing, cause confusion, etc.

NOTEThis is a business decision that can only be made by the business and should be very rare. This type of error is excluded from the load files. If the client changes thier mind and decides to load this data, change the report type from Business Readiness to Data Readiness. No changes to ETL Rules are required.

Stage Readiness -

The most common error reports. These are records that do not load because of missing required fields or missing configuration. Run these reports anytime to get an idea of the records that fail to load into the system. For transactional data, these reports look at the other target tables to see if the master data is relevant.

Target Readiness -

These are very similar to Stage Readiness but are separated because of TIMING. These reports are looking for data to have been loaded into the Target System by other migration objects in scope. Therefore, the TIMING of these reports is dependent on other objects first being loaded into the Target System. For example, prior to the start of a Data Load, if the report to check tgtS4H.dbo.MARA for materials was run on a PO Line, every record would show an error because the new Materials have not yet been loaded into the target system. This report is only valid to run after the Materials have been loaded. Avoid running this before the data loads because it shows false positive errors and confuse the users.

The next set of reports are used in every mock testing of conversion and are used by the Validation users to determine that the correct rows of data are ready to load and loaded successfully to the target system. The Info reports provide additional information for the client's requirements.


These reports are meant to help with the preload process. Preload Reports, Relevancy Reports, Rulebook Reports, etc. Any report that would help the validator in the Preload process. Preload reports use the ZCRITICAL field to help focus on the most important records.


These reports are meant to help with the postload process. Postload Reports should be used to verify the TECHNICAL load of the data to prove what loaded. They are not used to verify that the data is correct in the system. Yes – it loaded. But it may not actually work for transactions because it was loaded with incorrect values. Validation must be done primarily in the System looking at a sample of records. ZCRITICAL field is used to help focus on the critical data.


These reports are any other report, often requested by the business, to help them understand the legacy or target system. These reports are most often created specifically for individual business users to help them understand their data in order to make better decisions.

If after the CREATE REPORTS button is clicked there are no Recon reports, then the user should check for the prerequisites.

NOTEIf the wrong source table is added, then mark it as Inactive, add the correct table as a new source, and map the new table.

NOTEView section of Mapping for Migrate > Maintain Target Reports to view the details of these reports.

Prerequisites for Creating Target Reports

  • The Working database is created in database system

  • The Pass Thru Views are created for the working database. These are the check table views Ex: dbo.T000_ECC. Refer to Migrate > System Views for more details.

    • The Data Dictionary tables are complete so that check table reports build successfully.

  • The Target tables, Working tables, and views for the working database have been created

  • If using Data Services for the ETL, manually create a Datastore called xAppMigrate pointed at the core database (if one is not already in Central Repository). This Datastore contains tables XTVALUEMAP and COR_REPORT from core database in SSMS. Refer to Migrate > Build xAppMigrate Datatores for more details.

  • If using Data Services for the ETL, create the Report Refresh Token within User Profile section of Syniti Migrate application to add to the xAppMigrate Datastore in Data Services to be able to run the reports generation without issues. This token is required for each user who runs the DS Jobs to include reporting.

  • Parameters are setup for Working DB Type. These parameters are set in pathway Administer > Setup > Parameters

After the XML automation build tasks are completed and the SQL objects have been created from the SQL (DDL) Scripts, target reports can be generated as SQL Scripts that can be executed in the working database environment.

NOTEThis section provides information on how to build reports, while the Validate > Reports section of the guide is meant for general users and shows how to view, download, and filter reports.

NOTEView section of Mapping for Migrate > Maintain Target Reports to view the details of using and maintaining these reports.

Create the Reports

There are two places within Mappings where target level reports may be created.

View the following page by navigating to Migrate > Mappings on the Syniti Construct Homepage. Select a Dataset and click on Edit icon to view the Release Dataset Details window. The CREATE REPORTS button is provided in Details section.

The other option is within the Target Details dialog box. Select the Target and click the Edit icon to view the Target Details dialog box.

Mappings: Target: Create Reports

Click the Create Reports button  to create SQL scripts that create report views in the working database environment.

Mappings: Dataset - Create Reports

After the automation build is complete, a "Reports created successfully" message appears at the bottom right of the Mappings multi-panel page. The user should at this point view the Job Queue to confirm that all of the target reports have generate successfully by using pathway Administer > Job Queues.

Mappings: Target Reports: Display Reports

The Target Reports grid displays the following fields:




Allows reports to be filtered into groups as Critical, Major, Moderate, Minor, or Info.


Sequence of the Reports. Value increases by factor of 10 for each new entry.


Name of the Target Report.


The Report Type categorizes each report and setup for flagging in the All Errors report for errors produced .


The detailed description of the report.


Toggle to set status of the Dataset for future-state design mapping and migration.

NOTE:  Defaults as Active.


Toggle to mark relevant to Publish or not publish the report within the Validate pages.

Record Count History

These are spark lines that show the progression of counts for the report in a graph.

Last Run

Date this report was run last.


Count of records processed successfully


The time in seconds that it took this report to run.


The quantity of records that defaults as output to prevent excessively large reports.

NOTE:  Default value of 1000 at time of save may be changed after saving.


Check Box to show if report is using a random sample of data within the output of this report. This field works with Limit field. NOTE:  The check box is selected within Edit Details.

Security Provides icon to indicate that this report contains sensitive data that only a list of users may view.


This column contains four icons (History, Refresh, View, and Download). Each icon produces the outcome indicated in their name.

Status Indicator

This icon shows the current status of the report. (Check mark is Success, Red X is Error)

NOTE:  The user may also check the status of the report by clicking field Status Indicator or they may click Edit icon to view Report Details page to see the status of last run.

NOTE:  Always check against the working database to ensure that the reports are built.

Should there be any report failures during the build, a message displays in the job steps with the detail of reports that failed to build successfully. These reports require special attention to repair.

Mappings: Reports Generate Error Log

Refer to section Maintain Target Reports for details of the fields and processes associated with reporting.