Maintain Target Reports

This topic is related to the following sections:

• Mappings

• Create Reports

• Reporting Features

• Target Report Remediation

• Encrypt Decrypt and Mask Fields

About Target Reports

Reports are a vital tool needed to inform people of the status of your data. They provide details about what needs attention, and what is complete. Reports are also a good way to track defects, and can help reassure the client that any defects have been resolved.

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

Prerequisites for Creating Target Reports

• The Working database is manually created in database system

• The System Views (Pass Thru views) are created for the working database. Refer to section  Migrate > System Views for more details.

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

• The XML Build created the target tables and views for the working database. Refer to  Migrate > Mappings > Build XML Code for Dataset for more details.

• Manually create a Datastore called xAppMigrate pointed at the core database (if one is not already in Central Repository).

  • This Datastore contains tables XTVALUEMAP, COR_REPORTS, and COR_INTERFACE from core db in SSMS.

• Parameters are setup for Working DB Type. Refer to Administer > Setup > Parameters for more details.

After the above steps are completed to prepare the object for Reporting, the Reports may be created. Reports require System Views, Target and Working tables, and mapping rules to determine and build successful reports.

Add Target Reports

To build the basic Target Field Reports, navigate to the Mappings multi-panel page and then either the Datasets or Targets panel and click the CREATE REPORTS   button. Additional reports are added manually to the Target Reports page by the users. These reports provide more detailed views of critical data issues that may require detailed view building by the user.

Note

Automation only creates basic reports such as check reports or blank/null values in required fields. More advanced reports including those needing table joins and filters must be created manually. Automation for reports fails to build IF the report uses check tables that have not been built in the database.

RECON Reports provide information and counts for metrics. They do not build until the source table(s) is attached to the target within mappings, and the working table has been added to the working database  either automatically when BUILD XML is run, or by the user manually adding the table from the SQL Scripting within VIEW XML. If after the CREATE REPORTS button is clicked there are no Recon reports, then the user should check for these prerequisites. Never should the source table be CHANGED during a mapping. If the wrong source table is added, then mark it as Inactive, add the correct table as a new source, and map the new table.

The Postload report is dependent upon a working table being added to the database as well. The Report Generator throws an error for the Postload report build should it not find a working database table with the same naming convention as the sources attached.

From the Mappings multi-panel page, click Edit  icon for the selected Target Table to launch the Edit Dataset window. From the edit window, click Create Reports button at the top right of the window.

Click Cancel button to exit or OK button to proceed.

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 Monitor > Job Queue

The user may also check the Status of the report by viewing the reports and a click on field Status Indicator or they may click on Edit button to view the 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 with the detail of all reports that failed to build successfully. These reports require special attention to repair.

Note

The last column in the Target Reports panel represents the STATUS of the report run. It has no column header by design and provides status of either Success, Failed, or Unknown.

Target Reports

Within Migrate > Mappings for a Dataset, the target table reports are maintained. Click Reports button for the selected Target to view the specific reports associated to that target table.

Note

Only Roles of Developer, Validator, Administrator, and Functional Lead can access Target Reports as this allows for maintenance of the reports. The Mapper role cannot access the Target Reports section of Mappings.

Note

The last column in the Target Reports panel represents the STATUS of the report run. It has no column header by design and provides status of either Success, Failed, or Unknown.

Refresh All Reports Button

The REFRESH ALL REPORTS feature - This button is meant strictly for Debugging or Demo, never for actual Migration Report processing. That should always be done through Data Services or Migrate ETL processing. When a user refreshes a single report or all reports from this page, they only refresh and show the record count, they don't fire Remediation, or update zERROR_LOG, or update the zREADY flags on the target table.

In this case, click REFRESH ALL REPORTS to send all reports to Job Queue so they run in the background and don't lock up the page. The user must refresh the page to monitor when the Reports actually start running (based on how busy the job queue is...). The status icons flip to a QUEUED status, and then as the reports start running the info is updated and the status changes to show the report has finished running. But, the user must trigger the page refresh to see the updates.

Details Relevant to Target Reports list page

The reports on this page all have indexing so that the user may determine the order of the reports. The Priority column provides selection for Critical, Major, Info. Only the reports with record counts show with View and Download icons Active. The Status of the report is provided on the right side and the details of all errors are provided in the Report Details page -  click the Edit icon to open to display.

The second to last column provides options for the user such as displaying history, refreshing the report, viewing the report, or download to local drive. See the details for these icons below:

Icon	Name	Use
	History	The History icon displays a grid of history for each run of the report with count and date.
	Refresh	The Refresh icon updates the report and runs for current counts.
	Show/Hide	The Show/Hide icon displays the report on page.
	Download	The Download icon saves the current report to the user's local drive.

Edit a Target Report

Once the Target Reports are created and saved, they may be run as part of the ETL conversion process that has been built from the Dataset and Source XML scripting. Target Reports once saved to this page is included into the conversion run of reporting. The Reports are stored by the Report ID into a table in the database, and the data that produces from running each report is stored as tables in a database - REPORT. In doing this, the Report data is set and static once run. The user may continue to work on the system with assurance that the data from the Mock run is safely stored in tables in the REPORT database for the Validators to view.

Some Target Reports fail to generate a view within the Working database due to one or more of the following reasons:

• The Data Dictionary tables used to create report joins is not complete for SAP conversions

• The Working database has no System Views built for the check tables joins of the report

• The database lacks the Target table or Working table that would build during the Build XML transactions within Migration.

• The report lacks the Key fields required to produce a valid report (Ex: ZDEPLOY, ZSOURCE)

Click Edit   icon to enter the reports details page to maintain and adjust the fields for a report. A Bread crumb path is provided within Target Report Details in the upper left corner of the page.

Note

In this example of Report Details, the panel for Segment value and Record count is displayed as an example where Segmenting is active.

Within header of this page there are Quick Use icons:

Icon	Name	Use
	Save	Save icon displays as active once all required fields are filled.
	History	This icon displays history of actions for this report.
	Debug Log	Links to filter of the debug log for last run of this report.
	Help	Provides help text for this page.
	Cancel	Cancel the current changes and exit the details page.

The Report Details page provides the following fields:

Note

The fields Limit and Random Sample are contingent upon the type of Sampling Method selected ( Manual).

Note

If the user does not fill in values for fields Business Impact and Recommendation for an ERROR report, the system provides a Warning message upon attempt to set the report to Publish. These fields are provided in the details of the reports for the Validation team and so they should be filled with values for all Error reports that are Published to validation process. See warning message example below:

The Remediation process supports Dynamic Remediation (Use of sub views in the report to provide a min value or a value that depends upon other values, etc.). Refer to section Migrate > Target Report Remediation for more details of this process.

Report Details Buttons

The Report Details page contains two buttons:

Button	Name	Use
	ERROR STATUS	Provides a list of errors that prevent the report from building successfully. If there are no errors, a message indicates 'No validation errors.'
	View DDL	Provides the Report DDL dialog for the developer to use in a editor for debugging the code. This dialog may be copied.

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

Report Security

Each report provides a section within details for Security of sensitive data like Social Security numbers, or Credit Card numbers. Once the flag is active for Security and additional grid displays with a list of the users who may access the report in either the Migration Reports or Deployment Reports sections of the system.

Scroll to page bottom.

Click the Add icon to add users to the list with access to view this report that contains sensitive field data.

Should the report no longer contain sensitive data the Security toggle may be inactivated and a warning message displays upon saving the changes for this report. Click OK to proceed. This action removes all users from the list for access as well as marking the report open for all users to view in the Migration Reports or Deployment Reports sections of this system.

A report that has Security Enabled displays the Security icon within the Target Reports grid as shown below.

AQL Sampling Method

Used in the Sampling Method field the validation of a certain percentage of records in the Target Reports based upon the ANSI/ASQ STANDARD Z1.4-2003 standards is available. This standard is based upon a LOT SIZE of items (Ex: record count) and an Inspection Level (Ex: General 1-3 or Special 1-4). For a given Inspection Level, and a report record count, set the SAMPLE SIZE of the Report so the user gets a random sample size per that specification.

As an example, for an Inspection Level of General 1, and a Report Record Count of 1,500 records, the user should sample 50 records. See the AQL chart with this link:  https://www.intouch-quality.com/hubfs/pdf/AQLChart.pdf

For a report that contains from 35,001 to 150,000 records, the following samples are valid -

• General - I,     Inspection Level - L,     Sample - 200 = Only 200 records are seen in the report view and download

• General - II,    Inspection Level - N,     Sample - 500 = Only 500 records are seen in the report view and download

• General - III,    Inspection Level - P,     Sample - 800 = Only 800 records are seen in the report view and download

• Special - I,     Inspection Level - D,     Sample - 8 = Only 8 records are seen in the report view and download

• Special - II,     Inspection Level - E,     Sample - 13 = Only 13 records are seen in the report view and download

• Special - III,     Inspection Level - G,    Sample - 32 = Only 32 records are seen in the report view and download

• Special - IV,    Inspection Level - J,     Sample - 80 = Only 80 records are seen in the report view and download

Linking of Reports

In an effort to provide more detailed reporting, the system allows for a column in the report to LINK to a same column in another report. By linking reports, the user may click on the field link and open the subsequent report for that filtered data. From within Target Report details window for a report, click the Add icon.

Enter values for the required fields including Source link column, Subject Area, and Dataset. This produces a list of reports for the Subject Area and Dataset selected.

Enter values to the fields below:

Once the Subject Area and Dataset have been updated, the section for Select a report to link to provide a list of reports for selection. Highlight the report to use as the link report.

Click the ADD  button to create the Source Field and Target Field connections for key fields between the two reports where the Source Field is stored in the Target Report, and the Target Field is stored in the linked report.

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

This set of reports are joined from the versions that are stored within the Report database upon running the ETL process. Viewing the Target Report displays that the field for Territory ABEFTB is a linked field. Notice the values have underline and a hyper link.

Note

The header counts are Record Count and Count displayed.

Click a linked value for field Territory to open the linked report to show the matching row of data for the key fields.

Note

Security provides access to the user for both the Target Report and the associated linked report. Should the user not have access to view the data within the linked report, they are not able to open the link to view that report.

Child Table Readiness Reports

Should the Dataset contain multiple target tables that are dependent upon one another, the system will produce Child Table Readiness reports to support the conditional data and dependencies of the linked tables. As example, in material master the MARA table is dependent upon there being data within the MARC table. Should there be no plant data in MARC, then there may be no reason to mark the same material as active in general table MARA.

Validation Warning messages

In general, the update of data and saving checks for Errors and produce error messaging as well as providing Warning messages. These warnings allow for CONTINUE SAVE or CANCEL SAVE as response. The example below shows the warning message process for publishing a report. It provides clear messaging for the user to make decisions on a response.

Click CONTINUE SAVE button to save the changes or click CANCEL SAVE to exit and remain on the page.

Note

Within Report Details page, the validation process checks against these fields and access - Report OrderBy, Segment By, Remediation Field, Report (Name) to ensure that these fields contain valid entries. It also checks that the view is built correctly and makes sure that the Key fields are included.

View Debug Log for the Refreshed Report

During the process of Refreshing reports, the user may click Debug Log  icon to move to the Debug Log page for the entry that applies to the report selected.

Click Edit icon and then click Debug Log icon to view the log for this refresh.

Details of Report Refresh displays in the Debug Log for that specific report as shown in the example below.

Create Governance Rules from Target Error Reports

Syniti Knowledge Platform governance rules may be auto generated based upon the field and error produced within the Syniti Migrate system. The Syniti Knowledge Platform asset ID links the Migrate target report to the Syniti Knowledge Platform rule enforcement directly.

Within Migrate > Mappings for a dataset, target table reports are maintained. To add a governance rule to a target report perform the following steps:

1. Click the Reports button for the selected target to view the reports associated to that target table.

2. Click the Edit icon to view the Report Details dialog box.

3. Click the Create Governance Rule icon to display the Select Governance Rule list box, which provides the list of governance rules for that asset ID within Syniti Knowledge Platform.

4. Select a rule to link an existing Syniti Knowledge Platform rule

   OR

   Click the Add New Rule button to proceed.

   

   The Add New Rule button produces a warning message for confirmation that the action is correct.

   

5. The user clicks the OK button to proceed.

6. The system then creates the Syniti Knowledge Platform governance rule.

The system automatically opens a new page within Syniti Knowledge Platform that displays the auto generated rule. The asset ID is tied to the Migrate target report to provide this access.

Returning to the Migrate Target Report Details page, the field Governance Rule contains the same description value as the Description field. The Create Governance Rule icon is replaced by two icons:

The Create Governance Rule icon displays if the Clear Governance Rule icon is clicked to remove the link to the current Rule in Syniti Knowledge Platform. Otherwise, these two icons remain active.

Manually Created Reports

Although reports are auto generated during the Mapping process, they only complete part of the overall picture of reporting for each object. The auto generated reports cover the check table (Foreign Key Constraints) validation, missing values for required fields, or simple checks of data format for length and data type. There are many more advanced reports that need to be assembled manually within SQL database and then registered to the target table within Mappings.

Each custom report is first created within SQL db as a view or assembly of views using the Syniti preferred naming structure.

Advanced reports provide details for as example:

• Multiple field value checks

• Multiple table joins to check against dependent table/fields

• Comparison checks against dollar values for sales or accounting

Developer Defined Variables in Reports

Column Header Translations

The developer determines if the headers include the Field Name, the Field Description, or both fields.

Note

If the field is a newly added ZField, the user should setup a Report Column Translation within Migration to provide a description of this field. It may be added for just this one report, or multiple times for different situations with varying descriptions. OR, the translation may be entered with an asterisk (*) to be relevant for all uses. Refer to section Migrate > Report Column Translations  for more details of this process.

Note

The header counts are Record Count and Count displayed.

Limit Counts and Random Samples

Users may display reports to see the data on line as well as download reports. If the report has a Limit applied (Ex: 500 records), and the report contains a greater quantity than the Limit value, the report once displayed provides these details in the header of the displayed report on line. See example below.

Online viewing of reports is limited to 10,000 records max. The user may enter any value as a Limit, but the system outputs a Max Limit of 10,000 for online viewing. The download of reports allows for an unlimited number of records that are adjusted to the Limit value entered.

If the Limit value is left blank, the entire report downloads and 10,000 rows displays on line.

If the download exceeds the Excel Export Max Record Count and/or Excel Export Max Cell Count, it saves as CSV format. Otherwise, it saves as XLSX.

Note

The Limit field is contingent upon selection of Sampling Method = Manual within Target Report Details page. If the Sampling Method is blank or one of the AQL Sampling Methods as discussed in this section, the Limit field is hidden.

Note

The header counts are Record Count, Limit in browser count, and Count displayed.

As shown in the example below, if the Sampling Method = Manual, then Limit field and Random Sample toggle is provided. Random Samples help to provide a subset of records that are not sequential in nature but randomly selected. Once a value has been entered to Limit, the Random Sample field toggles on to output random rows of data and not just the first XXX of the Limit number.

Note

The header counts are Record Count, Limit in browser count, Sampled and Count displayed.

Warning Thresholds

Target Reports can now provide Threshold counts for Min and Max count. If a report generally produces 100 records in error, and you see a spike over the count entered, the system highlights the record count.

Segment By

A field may be added to Segment By field within the Target Report Details page. In this case, the system splits the report data into multiple reports based upon the segmented field. Users access the Details of a report to View or Download the report data, as the list of Segmented reports are listed within the REPORT DETAILS page.

Note

Never enter the field ZDEPLOY as a Segment By field. This field is already segmented to produce the Deployment reports, and so it would form a duplicate and cause error.

Note

Should the report use both Segment and Sampling Method, the counts for each of the Segment reports reflect the percentage for the sampling method against the segment count (not the total report count).

Report Order By

A field or fields may be listed within Report Order By field to enable a sorting of the values in the order of the fields entered. This is always sorted as ascending and each field is separated by a comma.

Remediation Field

The Remediation field prevents records from failing to load to the target system should there be a NULL or Blank value in a required field or an invalid value in a check table field. Reporting generates with the count and row details for these failed records first, then Remediation runs to update all rows where the field's value is incorrect.

The Remediation process uses Dynamic field values. Refer to section Migrate > Target Report Remediation for more details of this process.

Reporting Features for filtering, grouping, and other report functions on page

Once the user decides to view the report, they can use on page filters and grouping to pin point their results.

Refer to section Validate > Reporting Features for more details of this process.