Create Reports

This topic is related to the following topics:

• Mappings

• Create Target Tables

• Create & Maintain Target Sources

• Mapping the Fields of a Datasource

• Create Working Tables

• Maintain Target Reports

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 the working 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 clean-up 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.

Note

This 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 their 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.

PRELOAD

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.

POSTLOAD

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. The ZCRITICAL field is used to help focus on the critical data.

INFO

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

If Recon reports were not generated after clicking the Create Reports button, the user must revisit prerequisites to resolve this issue.

Refer to Maintain Target Reports for more information on these reports.

Note

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

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 System Views for more information.

  • 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 Build xAppMigrate Datatores for more information.

• 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 the following 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. Refer to Maintain Target Reports for more information on using and maintaining these reports.

Note

This 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.

Create the Reports

You can create target level reports in two methods on the Mappings page.

Method A

1. Access Migrate > Mappings on the Syniti Migrate Homepage.

2. Select a Dataset and click the Edit icon to view the Release Dataset Details dialog box.

3. In the Details section, click the Create Reports button.

Method B

1. Access Migrate > Mappings on the Syniti Migrate Homepage.

2. Select a Target and click the Edit icon to view the Target Details dialog box.

3. Click the Create Reports button.

The Create Reports button creates SQL scripts to create report views in the working database environment.

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

The Target Reports grid displays the following fields:

Note

The user may also check the status of the report by clicking the Status Indicator field or they may click the 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.

Refer to Maintain Target Reports for more information on the fields and processes associated with reporting.