configuring informatica mdm multidomain edition lab guidegwinup.com/infa/configuring mdm multidomain...

Configuring Informatica MDM Multidomain Edition

(Release 9.x)

Lab Guide

Version: MDM9x_MDE_Config_201209

ii

Configuring Informatica MDM Multidomain Edition (Release 9.x)

Version: MDM9x_ MDE_Config__201209

September 2012

Copyright (c) 1998–2012 Informatica Corporation. All rights reserved.

This educational service, materials, documentation and related software contain proprietary information of Informatica Corporation and are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright law. Reverse engineering of the software is prohibited. No part of the materials and documentation may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica Corporation. The related software is protected by U.S. and/or international Patents and other Patents Pending.

Use, duplication, or disclosure of the related software by the U.S. Government is subject to the restrictions set forth in the applicable software license agreement and as provided in DFARS 227.7202-1(a) and 227.7702-3(a) (1995), DFARS 252.227-7013(c)(1)(ii) (OCT 1988), FAR 12.212(a) (1995), FAR 52.227-19, or FAR 52.227-14 (ALT III), as applicable.

The information in this educational service, materials and documentation is subject to change without notice. If you find any problems in this educational service, materials or documentation, please report them to us in writing.

Informatica, Informatica Platform, Informatica Data Services, PowerCenter, PowerCenterRT, PowerCenter Connect, PowerCenter Data Analyzer, PowerExchange, PowerMart, Metadata Manager, Informatica Data Quality, Informatica Data Explorer, Informatica B2B Data Transformation, Informatica B2B Data Exchange Informatica On Demand, Informatica Identity Resolution, Informatica Application Information Lifecycle Management, Informatica Complex Event Processing, Ultra Messaging and Informatica Master Data Management are trademarks or registered trademarks of Informatica Corporation in the United States and in jurisdictions throughout the world. All other company and product names may be trade names or trademarks of their respective owners.

Portions of this educational service, materials and/or documentation are subject to copyright held by third parties, including without limitation: Copyright © Adobe Systems Incorporated. All rights reserved. Copyright © Microsoft. All rights reserved. Copyright © Oracle. All rights reserved. Copyright @ the CentOS Project.

This Software is protected by U.S. Patent Numbers 5,794,246; 6,014,670; 6,016,501; 6,029,178; 6,032,158; 6,035,307; 6,044,374; 6,092,086; 6,208,990; 6,339,775; 6,640,226; 6,789,096; 6,820,077; 6,823,373; 6,850,947; 6,895,471; 7,117,215; 7,162,643; 7,243,110, 7,254,590; 7,281,001; 7,421,458; 7,496,588; 7,523,121; 7,584,422, 7,720,842; 7,721,270; and 7,774,791, international Patents and other Patents Pending.

DISCLAIMER: Informatica Corporation provides this educational services, materials and documentation “as is” without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of non-infringement, merchantability, or use for a particular purpose. Informatica Corporation does not warrant that this educational service, materials, documentation or related software is error free. The information provided in this educational service, materials, documentation and related software may include technical inaccuracies or typographical errors. The information in this educational service, materials, documentation and related software is subject to change at any time without notice.

iii

Preface Welcome to the “Configuring Informatica MDM Multidomain Edition (Release 9.x)” course.

This 4-day, instructor-led course provides students with the knowledge and skills necessary to configure a data model and business rules in Informatica MDM Multidomain Edition (MDM Hub) for a given data model and business rules design. The course provides extensive hands-on labs and exercises to allow students to gain confidence in the use of the MDM console. Topics covered include: Master Data Management (MDM) Concepts, the MDM Data Model, Configuring the Land, Stage, Load, and Match and Merge processes, Data Access Views, Batch Processes, Utilizing Data Management Tools, System Information and Logs, and User Objects. Prerequisites:

Knowledge of Structures Query Language (SQL) Familiarity with Oracle Database systems.

Additional prerequisites include: Microsoft Windows Graphical User Interface Microsoft Windows Command line

Course Objectives:

Describe the terminology, components, and key concepts used in Master Data Management as foundational knowledge prior to your using the MDM Multidomain Edition (MDM Hub) solution.

Create the elements of the data model that are used to contain data from different kinds of tables for batch processing using the Hub Console Schema tool.

Define relationships within the data model that is used to create affiliation between base object tables using the Hub Console Schema tool.

Define lookups in a data model to help retrieve data from parent tables during the load process using the Hub Console Schema tool.

Configure the stage process for the Informatica MDM Hub by creating mappings that use functions and cleanse lists to map, move, and cleanse data between the landing and the staging table using the Mapping tool.

Configure the stage process for the Informatica MDM Hub by setting options for Delta Detection, Raw data retention, and the Cleanse Server to prepare to run the Stage batch job using the Schema tool, the Match Server tool, and the Batch Viewer tool.

Configure the load process for the Informatica MDM Hub to compare the relative reliability of column data from different source systems (Trust) and to specify the conditions under which the column data values are not valid (validation rules) using the Schema tool, the Batch Viewer tool, and System & Trust tool.

After successfully completing this course, students should be able to:

iv

Provide an overview of the match and merge process and its configuration as foundational knowledge of the match and merge process in the MDM Hub.

Configure exact matching in the Informatica MDM Hub to match identical records in base objects using the Schema tool

Configure fuzzy matching in the Informatica MDM Hub to perform a Probabilistic match in base objects using the Schema tool

Configure the merge process by setting rules in the Informatica MDM Hub to consolidate data from matched records into a single, master record.

Create queries and packages to provide data views for Data Manager (used to view records in the base object), Merge Manager (used to review records queued for consolidation), Informatica Data Director, and Security Integration Framework using the MDM Hub Queries tool.

Configure Batch Jobs to execute the stage, load, match and merge processes from within Stored Procedures

Utilize data management tools in the Informatica Hub to manually search, edit, flag, and merge records queued for merging and additionally unmerge records in the base object.

Utilize Enterprise Manager to view properties, version history, and environment reports for MDM Hub components and to configure database logs for ORS databases.

Find log files to collect troubleshooting information for support purposes Provide an overview of User Exists and recognize the function of each type. Provide an overview of product features not covered in this course to learn about

additional functionality in the product that could not be covered in this course because of time constraints.

Complete a full implementation of Informatica MDM Multidomain Edition, using the concepts covered in modules 1–9 of this training course.

Audience: This course is designed for those responsible for configuring the Informatica MDM Hub Multidomain Edition. This includes MDM Multidomain Hub users, such as the follows:

Business Analysts Data Architect MDM configuration/implementation specialists/architects

v

Document Conventions This guide uses the following formatting conventions:

If you see… It means… Example

> Indicates a submenu to navigate to. Click Repository > Connect. In this example, you should click the Repository menu or button and choose Connect.

boldfaced text Indicates text you need to type or enter.

Click the Rename button and name the new source definition S_EMPLOYEE.

UPPERCASE Database tables and column names are shown in all UPPERCASE.

T_ITEM_SUMMARY

italicized text Indicates a variable you must replace with specific information.

Connect to the Repository using the assigned login_id.

Note: The following paragraph provides additional facts.

Note: You can select multiple objects to import by using the Ctrl key.

Tip: The following paragraph provides suggested uses or a Velocity best practice.

Tip: The m_ prefix for a mapping name is…

vi

Other Informatica Resources In addition to the student and lab guides, Informatica provides these other resources:

Informatica Documentation Informatica Customer Portal Informatica web site Informatica Developer Network Informatica Knowledge Base Informatica Multimedia Knowledge Base Informatica How-to Library Informatica Professional Certification Informatica Technical Support

Obtaining Informatica Documentation The Informatica Documentation team takes every effort to create accurate, usable documentation. If you have questions, comments, or ideas about this documentation, contact the Informatica Documentation team through email at [email protected]. We will use your feedback to improve our documentation. Let us know if we can contact you regarding your comments. The Documentation team updates documentation as needed. To get the latest documentation for your product, navigate to Product Documentation from http://mysupport.informatica.com.

Visiting the Informatica Customer Portal

http://mysupport.informatica.com As an Informatica customer, you can access the Informatica Customer Portal site. The site contains product information, user group information, newsletters, access to the Informatica customer support case management system (ATLAS), the Informatica How-To Library, the Informatica Knowledge Base, the Informatica Multimedia Knowledge Base, Informatica Product Documentation, and access to the Informatica user community.

Visiting the Informatica Web Site You can access Informatica’s corporate web site at:

http://www.informatica.com

The site contains information about Informatica, its background, upcoming events, and locating your closest sales office. You will also find product information, as well as literature and partner information. The services area of the site includes important information on technical support, training and education, and implementation services.

Visiting the Informatica Technology Network The Informatica Developer Network is a web-based forum growing online community and interactive forum for data integration and data quality professionals around the globe. You can access the Informatica Developer Network at the following URL: http://community.informatica.com/

The site contains information on how to create, market, and support customer-oriented add-on solutions based on interoperability interfaces for Informatica products.

vii

Visiting the Informatica Knowledge Base As an Informatica customer, you can access the Informatica Knowledge Base at http://mysupport.informatica.com. Use the Knowledge Base to search for documented solutions to known technical issues about Informatica products. You can also find answers to frequently asked questions, technical white papers, and technical tips. If you have questions, comments, or ideas about the Knowledge Base, contact the Informatica Knowledge Base team through email at [email protected].

Visiting the Informatica Multimedia Knowledge Base As an Informatica customer, you can access the Informatica Knowledge Base at http://mysupport.informatica.com. Use the Knowledge Base to search for documented solutions to known technical issues about Informatica products. You can also find answers to frequently asked questions, technical white papers, and technical tips. If you have questions, comments, or ideas about the Knowledge Base, contact the Informatica Knowledge Base team through email at [email protected].

Visiting the Informatica How-To Library As an Informatica customer, you can access the Informatica How-To Library at http://mysupport.informatica.com. The How-To Library is a collection of resources to help you learn more about Informatica products and features. It includes articles and interactive demonstrations that provide solutions to common problems, compare features and behaviors, and guide you through performing specific real-world tasks.

Obtaining Informatica Professional Certification You can take, and pass, exams provided by Informatica to obtain Informatica Professional Certification. For more information, go to:

http://www.informatica.com/products_services/education_services/certification/Pages/index.aspx

Providing Feedback Email any comments on this guide to [email protected].

Obtaining Technical Support There are many ways to access Informatica Technical Support. You can call or email your nearest Technical Support Center listed in the following table, or you can use our WebSupport Service.

Use the following email addresses to contact Informatica Technical Support:

[email protected] for technical inquiries [email protected] for general customer service requests

WebSupport requires a user name and password. You can request a user name and password at:

http://mysupport.informatica.com.

viii

Informatica Global Customer Support You can contact a Customer Support Center by telephone or through the Online Support. Online Support requires a user name and password. You can request a user name and password at http://mysupport.informatica.com.

Use the following telephone numbers to contact Informatica Global Customer Support:

North America / South America

Europe / Middle East / Africa Asia / Australia

Informatica Corporation Headquarters 100 Cardinal Way Redwood City, California 94063 United States Toll Free 877 463 2435 Standard Rate United States: 650 385 5800

Informatica Software Ltd. 6 Waltham Park Waltham Road, White Waltham Maidenhead, Berkshire SL6 3TN United Kingdom Toll Free 00 800 4632 4357 Standard Rate Belgium: +32 15 281 702 France: +33 1 41 38 92 26 Germany: +49 1805 702 702 Netherlands: +31 306 022 797 United Kingdom: +44 1628 511 445

Informatica Business Solutions Pvt. Ltd. 301 & 302 Prestige Poseidon 139 Residency Road Bangalore 560 025 India Toll Free Australia: 00 11 800 4632 4357 Singapore: 001 800 4632 4357 Standard Rate India: +91 80 5112 5738

Table of Contents

Training Environment Overview ................................................................................................................... 1

Module 2 Lesson 1 Lab 1: Create a Customer Data Model ........................................................................... 7

Module 2 Lesson 2 Lab 1: Define Relationships between Base Objects ..................................................... 23

Module 2 Lesson 3 Lab 1: Define Lookups .................................................................................................. 39

Module 3 Lesson 1 Lab 1: Register a Cleanse Match Server ....................................................................... 45

Module 3 Lesson 1 Lab 2: Create a Basic Mapping ..................................................................................... 49

Module 3 Lesson 1 Lab 3: Create a Cleanse List and a Graph Function in a Mapping ............................... 79

Module 3 Lesson 2 Lab 1: Define Delta Detection Options and Raw Data Retention Periods ................... 95

Module 3 Lesson 2 Lab 2: Run Staging Jobs ................................................................................................ 99

Module 4 Lesson 1 Lab 1: Set Trust, Validation Rules, Cell Update, and Null Update ............................. 105

Module 4 Lesson 1 Lab 2: Run Loading Jobs ............................................................................................. 117

Module 5 Lesson 1 Lab 1: Setting Match Strategy, Match Columns, and Match Path ............................. 123

Module 5 Lesson 2 Lab 1: Configure an Exact Match Rules Set ............................................................... 137

Module 5 Lesson 3 Lab 1: Configure a Range Search ............................................................................... 143

Module 5 Lesson 3 Lab 2: Configure a Fuzzy Match Rule Set ................................................................... 149

Module 5 Lesson 4 Lab 1: Set Merge Options for Match Rules ................................................................ 159

Module 6 Lesson 1 Lab 1: Queries and Packages ..................................................................................... 165

Module 7 Lesson 1 Lab 1: Configure Batch Groups .................................................................................. 175

Module 8 Lesson 1 Lab 1: Merge Records Using Merge Manager ........................................................... 181

Module 8 Lesson 1 Lab 2: Unmerge Records using Data Manager .......................................................... 197

Module 9 Lesson 2 Lab 1: Enabling the ORS Database Log File ................................................................ 207

Module 11 Lesson 1 Lab 1: Export an ORS to a Changelist ....................................................................... 211

Module 12 Lab 1: Workshop ..................................................................................................................... 215

Appendices ................................................................................................................................................ 225

Configuring Informatica MDM Multidomain Edition 1

Training Environment Overview

Guidelines

This training course uses the following system scenario for all examples and labs, except for the workshop on the last day where you will be configuring a new MDM Multidomain Edition system.

Please take a few minutes to read through this overview before proceeding with the 1st lab.

Objectives:

Familiarize yourself with the classroom target and source systems

Duration:

15 minutes

Target Data Model

The target consolidated data model used in this course has the entities described below.

Customer Can be Organization or Individual (this sort of model is often known as a Business Party model). Customer class will be ‘O’ for Organizations, ‘P’ for persons or ‘U’ for ‘Unknown/Undefined’. Full Name should be populated for all Customer Classes. The rest of the name fields will only be populated for Individuals. Sub_Category_ROWID is an optional (i.e. nullable) foreign key to the Sub Category table. Not all Customers will have been assigned to sub categories. Customers will be matched on Name and Address attributes.

2 Configuring Informatica MDM Multidomain Edition

Address Each customer has one or more addresses. Duplicate addresses for a customer will be merged to a single record for that customer. Addresses will not be merged across customers

Address Type

A code table that contains a list of the Address Types. Valid Address Types are: Target Address; Billing Address; Shipping Address.

Address Address-

Type

An intersection table between Address and Address Type that allows an Address to be defined as more than one Address Type, and each Address-Type to be associated with many Addresses.

Customer Notes

Sales reps’ notes about the Customer

Category High level categorization of Customers as defined in the CRM system. There are 3 numeric category codes that indicate the Customer’s priority ranking for the sales reps.

Sub-Category

Detailed sub-categorization of Customers as defined in the CRM system. Category_code_FK is a foreign key to the category_code on the C_CATEGORY table, to maintain RI between these 2 tables.

Source Systems

The target consolidated data model used in this course has the entities described below.

There are 2 source systems for this training course:

1. The Sales System: This provides a data file that contains invoice summary information as well as the Customer information for each invoice. The invoice summary provides at least a billing address. It might also provide shipping address if the Customer’s shipping address is different from the billing address.

The Customers in the Sales system can be organizations or individuals – the Cust-Type implies Org vs. Individual. Possible values are:

CUST_TYPE Meaning

RLO Retail - Large Organization

RSO Retail – Small Organization

WO Wholesale Only

WR Wholesale / Retail

IND Individual


The file layout for the Sales system’s invoice file is:

Note: To simplify the “ETL” process for training, the INVOICE_SUMMARY file has already been loaded into a non-Hub table in your training schema. The name of the table is ZZ_INVOICE_SUMMARY.

2. The CRM System:

This provides Customer and Address information as well as Customer Notes and Customer Categorization information.

The Customers in the CRM system are all individuals. The CRM system holds one or more addresses per Customer – each address is considered a ‘Target Address’ for sales rep calls.

CRM Category & CRM Sub Category provides optional classifications of Customers within the CRM system.

The data model for the data in the CRM system is on the next page.

INVOICE_SUMMARY

INVOICE_NO: CHAR(12)

INVOICE_DATE: CHAR(8)CUST_ID: CHAR(10)CUST_NAME: CHAR(50)CUST_TYPE: CHAR(3)BILL_ADDR_LN_1: CHAR(60)BILL_ADDR_CITY: CHAR(30)BILL_ADDR_STATE: CHAR(2)BILL_ADDR_ZIP: CHAR(10)SHIP_ADDR_LN1: CHAR(60)SHIP_ADDR_CITY: CHAR(30)SHIP_ADDR_STATE: CHAR(2)SHIP_ADDR_ZIP: CHAR(10)TOTAL_INCL_TAXES: DECIMAL(10,2)


Data Model for Data in CRM System

Note: To simplify the “ETL” process, the above tables have been added to your training schema as non-Hub tables. The table names in your training schema are the same as shown above, except that all are prefixed with ‘ZZ_’ to make it easier to identify these tables.

Address

ADDR_ID: VARCHAR2(20)

ADDRESS_LINE: VARCHAR2(50)CITY_NAME: VARCHAR2(50)STATE_CODE: VARCHAR2(2)ZIP: VARCHAR2(10)LAST_UPDATE_DATE: DATE

Customer_Category

CATG_NO: VARCHAR2(5)

CATG_NAME: VARCHAR2(10)CATG_DESC: VARCHAR2(30)LAST_UPDATE_DATE: DATE

Customer

CRM_ID: VARCHAR2(20)

FULL_NAME: VARCHAR2(100)FIRST_NAME: VARCHAR2(30)MIDDLE_NAME: VARCHAR2(30)LAST_NAME: VARCHAR2(20)NAME_GENERATION: VARCHAR2(20)LAST_UPDATE_DATE: DATESUB_CATG_NO: VARCHAR2(5)

Customer_Note

CRM_ID: VARCHAR2(20)CREATE_DATE: DATE

CREATED_BY: VARCHAR2(20)NOTE_TEXT: VARCHAR2(2000)

Customer_Sub_Category

SUB_CATG_NO: VARCHAR2(5)

CATG_NO: VARCHAR2(5)SUB_CATG_NAME: VARCHAR2(10)SUB_CATG_DESC: VARCHAR2(30)LAST_UPDATE_DATE: DATE

Customer_Address

CRM_ID: VARCHAR2(20)ADDR_ID: VARCHAR2(20)


Build Process Quick Reference

The following steps describe the overall activities involved in a basic MDM configuration. This is what you will accomplish during the lab exercises in this training course.

1. Define the data model

a. Create data model elements

i. Base objects

ii. Landing tables

iii. Staging tables

b. Define relationships (one-to-many and many-to-many)

c. Define lookup strategies on staging tables

2. Configure the Stage process

a. Create mappings

b. Create re-useable graph functions

c. Set delta detection and raw retention periods

3. Configure the Load process

a. Define trust rules

b. Define validation rules

4. Configure the Match and Merge process

a. Match strategy, population, match path, match columns

b. Defining match rules

5. Configure data access views

a. Create queries

b. Create packages


Data Flow Quick Reference


Module 2 Lesson 1 Lab 1: Create a Customer Data Model

Guidelines

Scenario:

Create and configure the initial tables (landing, staging, and base object tables) that will be used in the Customer data model.

Objectives:

Given the MDM Hub Console Schema tool, the name of the table, and the system name, you will accurately create a Landing table.

Given the MDM Hub Console Schema tool, the name of the table and tablespaces names, you will accurately create Base Object tables.

Given the MDM Hub Console Schema tool, the name of the tables, and the system name, you will accurately create Staging tables.

Duration:

55 minutes

Review

Landing Table – Provides intermediate storage in the flow of data from source systems into Informatica MDM Hub.

Staging Table – Provides temporary, intermediate storage in the flow of data from landing tables into base object tables.

Base Object Table – A table in the Hub Store containing collections of data about individual entities. Each individual entity has a single master record—the best version of the truth—for that entity. An individual entity might have additional records in the base object (contributing records) that contain the “multiple versions of the truth” that need to be consolidated (merged) into the master record.


Startup

Follow the instructions below to start up the JBoss Application Server and to launch the Informatica MDM Hub.

1. Launch the class services:

Start-Stop > MDM > 1. Class Services start

This will start the Oracle services and JBoss on your virtual/hosted machine.

You may start the JBOSS application server manually from the Windows Start menu:

Start > JBoss run.bat

2. Launch the Informatica MDM Multidomain Edition console :

a. Launch Internet Explorer: Start > Internet Explorer

b. Launch the MDM Console from Internet Explorer:

Informatica > Informatica MDM Hub

Note: You may also launch the Informatica MDM Hub by entering http://infa-server:8080/cmx in the address field of the browser.

c. Click the Launch button.


3. Login with user name training and password mdm

4. Select trn_lab as your target database and click Connect.

Walkthrough:

Create a Base Object

In this exercise, create a base object table. The process for creating a base object is much the same as creating a landing table.

1. Right-click the Base Objects node and select Add Item.

2. Enter the Display name as Customer. Leave the physical name as C_CUSTOMER. Enter a description for the base object and keep the settings shown in the screenshot below:

3. Click OK.

4. Click the Customer node in the Schema tree to see the properties and advanced properties for the base object. You can edit these properties in the Properties pane. Advanced Properties will be covered later in this course.

5. On the Basic Properties tab, check the Enable History property. Switching this on causes Informatica MDM Multidomain Edition to keep a record of rows that are inserted, updated, or deleted. You can use a history table for audit purposes.


6. Click the Save button to save the object.

7. Expand the Customer base object node and browse its Columns node.

8. Define columns for the Customer base object using the Add Column button

. Note: For consistency in the classroom, we recommend using the exact Display Names shown below. Physical Names will be populated automatically.

CUSTOMER Base Object

--------------------------------

ROWID_OBJECT

--------------------------------

FULL_NAME

FIRST_NAME

MIDDLE_NAME

LAST_NAME

NAME_GENERATION

CUSTOMER_CLASS

SUB_CATEGORY_ROWID

Display Name

Informatica MDM Data Type

Notes

Full Name VARCHAR(100)

First Name VARCHAR(30)

Middle Name

VARCHAR(30)

Last Name VARCHAR(30)

Name Generation

VARCHAR(5)

Customer Class

CHAR(1) Individual (I) or Organization (O)

Sub Category ROWID

CHAR(14) Will be used as FK to Sub Category base object


Walkthough

Create a Landing Table

In this exercise, create a Landing table for Customer data from the Sales source system.

1. Right-click the Landing Tables node and select Add Item.

2. Enter LDG Sales Customer for the Display Name.

Notes: The physical name is automatically generated for you by Informatica MDM Multidomain Edition, but you can change it if needed.

3. Enter a description for the Description field.

4. Select CMX_DATA as the Data Tablespace and CMX_INDX as the Index Tablespace.

These are the Oracle tablespaces used in the training environment. Other Informatica MDM Multidomain Edition environments can have different tablespace names, depending on how their schema was set up in Oracle.

5. Ignore the Secure Resources flag.

Checking (enabling) this checkbox makes this landing table a secure resource, which allows you to control access to this table. Once a table is designated as a secure resource, you can assign privileges to it in the Secure Resources tool. Secure settings are out of scope for this training course.

9. Click the Save button to save the object.


6. Click OK.

7. Select the Landing Tables > LDG Sales Customer > Columns node for the landing table you created in the previous step.

8. Click the Import Schema button . This allows you to import column definitions from another Oracle table.

9. Enter the connection properties for your LAB schema as shown in the screenshot below:


10. Click Next >.

11. Scroll to the end of the list of tables and select ZZ_INVOICE_SUMMARY.

12. Click Next >.


13. Select the columns checked below (don’t import any columns that are not on this entity diagram, such as invoice_date, invoice_no or total_incl_taxes).

14. Click Finish.

15. The columns you selected are added to the column list. Set them all to Nullable.

16. The columns in ZZ_INVOICE_SUMMARY are all defined as CHAR, and are therefore imported as such. Change the data types to reflect the entity diagram below, and set the column lengths as shown.


CAUTION: When the data type is changed, the field lengths get reset.

NOTE: For a physical data type of VARCHAR2, select VARCHAR not NVARCHAR2 (Informatica MDM Multidomain Edition actually implements VARCHAR as VARCHAR2 in Oracle.)

17. Click the Save button to save the columns.

18. Click OK.

Walkthrough:

Create Two Staging Tables

In this exercise, create a Staging table for Customer data from the Sales source system and another Staging table for the Customer data from the CRM system.

When defining the columns for a staging table, simply choose the set of columns that the staging table’s source system will provide to the base object. To do this you need to first define the staging table in the base object, and its source system.

First, use the Systems and Trust tool to define the source systems.

1. To give the Sales system an identity in Informatica MDM Multidomain Edition, select the Systems and Trust tool in the Workbenches pane.

2. Expand System. Notice that there is an existing system called Admin.


3. Right-click anywhere in the middle pane and select Add System…

4. Enter CRM for the Name and click OK.

5. Likewise, add an entry for the Sales system too.

Next, define the staging tables in the base object.

6. Using the Schema tool, select Staging Tables under the Customer base object: Schema > Base Objects > Customer > Staging Tables


7. Right-click Staging Tables and select Add Staging Table…

8. Enter STG Sales Customer for the Display name. The physical name is automatically created by Informatica MDM Multidomain Edition. You can leave it unchanged.

9. Select Sales as the System.

10. Do not switch on the Preserve Source System Keys option.

11. Ensure CMX_DATA is selected as the Data Tablespace and CMX_INDX as the Index Tablespace.

12. Enter a description for the staging table: something meaningful such as, “This is a Staging table for the Customer data and is derived from the ‘Sales’ system.”

13. The two columns that the Sales system will provide data for the Customer base object are Customer_Class and Full_Name. Select those two columns in the Columns list.


14. Click OK to create the staging table.

15. Likewise, create a staging table for the Customer base object based on data from the CRM system (STG CRM Customer). Select all the Customer columns for this staging table when doing so.


The resulting set of staging tables will be listed in the right-pane.

In this lab exercise, you

Created a base object and defined columns for it (Customer)

Created a landing table and defined columns for it (LDG Sales Customer)

Created two staging tables and defined their columns (STG Sales Customer and STG CRM Customer)

In the next section of this lab, which continues on the next page, use what you’ve learned in the walkthroughs to complete the skills review exercises.


Skills Review:

Create a Base Object with Three Staging Tables

1. Create a base object named Address, and add its columns according to the table definition shown below. Use the same tablespace designations as were used in the Customer base object. Note: Some of the columns can be imported from ZZ_ADDRESS; the rest will have to be created manually.

Note: For consistency in the class, try to use the Display Names and Physical Names exactly as shown below.

Address Base Object

ROWID_OBJECT

-------------------------

ADDRESS_LINE_1

CITY

STATE

ZIP_10

ZIP_5

VALID_IND

CUSTOMER_ROWID

Display Name Informatica MDM Data Type

Address Line 1 VARCHAR(50)

City VARCHAR(50)

State VARCHAR(2)

Zip 10 VARCHAR(10)

Zip 5 VARCHAR(5)

Valid Ind CHAR(1)

Customer ROWID CHAR(14)

2. Switch on the Enable History option for the ADDRESS base object.

3. Create a staging table called STG CRM Address for the Address base object. Its source system is the CRM system. Select all the Address columns for this staging table.

4. Create two more staging tables for the Address base object. Both should have the Sales system as their source system:

Staging table for Ship-To addresses:

a. Set the Display Name to “STG Sales Ship To Addr”

b. Ensure the Physical Name is set to C_STG_SALES_SHIP_TO_ADDR

c. Select all of the base object columns.

Staging table for Bill-to addresses:

a. Set the Display Name to “STG Sales Bill To Addr”

b. Ensure the Physical Name is set to C_STG_SALES_BILL_TO_ADDR

c. Likewise, select all of the base object columns.


8. IMPORTANT: The Address base object should result with three staging tables – one for the CRM system and two for the Sales system. Take a moment to verify the Source systems are set correctly on your staging tables:

9. Review the data model elements using the Schema Viewer.

Note: In the next lab, you will apply a changelist from within the MDM Hub Console The changelist will create a number of base objects, landing and staging tables and a few mappings, all in preparation for the rest of the labs.

Summary

You have reached the end of Module 2 > Lesson 1 > Lab 1. In this lab exercise you created and configure the landing, staging, and base object tables that will be used in the Customer data model.


Module 2 Lesson 2 Lab 1: Define Relationships between Base Objects

Guidelines

Scenario:

Define relationships between the various base objects created earlier for the Customer data model.

Objectives:

Define the foreign-key relationship between the Address and Customer base objects

Create a many-to-many relationship called between the Address and Address_Type base objects

Duration:

15 minutes

Review

MDM Hub supports one-to-many, many-to-many, and hierarchical relationships between records in an object.

One-to-many relationships – Foreign keys are virtual, known to repository only i.e., there is no physical constraint created in database, and you can define a Display Name column for the lookup. Contents will be displayed in drop down list in Add/Edit window in Data Manager/Merge Manager.

Many-to-many relationships – Intersection tables are simply another base object. As the parent records in the parent base objects merge, the foreign keys in the relationship base objects are updated.


Before you Begin:

Apply a Changelist to Create Additional Objects

In order to complete the labs in this training course, you need to have more objects in your schema than you currently have. Rather than have you create all of them manually, they have already been created in a separate schema and exported as a change list, using MDM’s Metadata Manager tool. You will need to use Metadata Manager to promote the changes from that changelist into your LAB schema.

Below are the steps for doing that:

1. Click the Metadata Manager tool in Workbenches pane.

2. You will be prompted to change to the Master Database. Connect to the Master Database.

3. Click the Validate tab in Metadata Manager.

4. Select trn_lab as the repository to validate:

5. Click the Validate button on the right.

6. Click OK when prompted to Select Validation Checks.

Some warnings and information messages will be displayed. These can be ignored. There should be no severe error messages.


7. Click the Promote tab.

8. Click the Change List sub-tab.

9. Select trn_lab as the target repository.

10. Click the Load a changelist from a file button on the right.

11. Browse to C:\MDM_training\MDM330_91_Configuring_MDM_MDE\Setup\lab changelists and select the file called changelist_to_be_applied_prior_to_MOD2_LES2_LAB2.change.xml.

12. Metadata Manager will show you a list of the changes that will be applied to your schema as a result of the change list.


13. Click the Run a simulation of this change list button.

14. Click Yes for the confirmation and Validate Data prompts.

There should be no errors reported.

15. Click OK.

16. Click the Apply Changes button to apply the changes.


17. Select the Full rollback radio button.

18. Click OK.

19. Click Yes, when prompted.

20. Click OK.

21. Connect to Schema tool for the trn_lab schema. Notice all the new objects and relationships that have been added to your schema.


Walkthough

Define a Foreign Key Relationship between two Base Objects

In this walkthrough, define the foreign key relationship between Address and Customer base objects.

When you define a foreign key relationship in Informatica MDM Multidomain Edition you define it from the child (referencing) table to the parent (referenced) table. In this exercise, Address is the child table and Customer is the parent table.

The Customer_ROWID column in the Address table will be used for the foreign key from Address to Customer.ROWID_OBJECT. The column was given a data type of CHAR(14) to make it possible to relate it to Customer.ROWID_OBJECT.

1. Ensure that you have acquired the write-lock on your schema: Write Lock > Acquire Lock

2. Go to the Schema tool and browse to the Relationships node under the Address base object. Schema > Base Objects > Address > Relationships


3. Right click on the Relationships node and choose Add Relationship.

4. Select the Customer_ROWID (in the Address tree) column in the Relate from list.

5. Expand the Customer base object in the Relate To tree

6. Select Customer’s ROWID_OBJECT column.

7. Click OK.

8. Note that the relationship Foreign key from “Address(Customer_ROWID)” to “Customer(ROWID_OBJECT)” (Restrict) has been added under the Table references heading in the Relationship properties.


9. Click on that relationship name. The relationship details are displayed in the bottom pane.

Note that one of the properties for the relationship is Lookup Display Name. This defaults to ROWID_OBJECT, but you can change it to any other column from the referenced table.


The Lookup Display Name value determines which values from the referenced table are displayed in the Edit window (available from the Merge Manager and Data Manager tools) when you edit a record from the referencing table. It is a good idea to get into the habit of always choosing a meaningful, human-readable column for the Lookup Display Name.

10. Change the Lookup Display Name by clicking the Edit button to the right of the column.

11. Select the Full Name column and click Close.

12. Click Save.

Walkthrough:

Define a many-to-many relationship between the base objects

In this exercise, create the Address_AddressType relationship. This is a many-to-many relationship that is between the Address and Address_Type base objects.

This relationship will be used to manage the many-to-many link between Addresses and their Address Types – for example, one address can be both a billing address and a shipping/delivery address.

1. Add a new base object called Address_AddressType.


2. Create the following two columns for the Address_AddressType base object:

Column Name Data Type Description Address_ROWID CHAR(14) This will be used as the

FK to the Address base object

AddressType_ROWID CHAR(14) This will be used as the FK to the Address_Type base object

3. Right-click the Relationships node of the Address_AddressType base object and chose Add Relationship.


4. Choose the Address_ROWID from Address_AddressType and ROWID_OBJECT from Address.

5. Click OK.

6. Again, right click the Relationships node of the Address_AddressType base object and chose Add Relationship.

7. Choose AddressType_ROWID from Address-AddressType and ROWID_OBJECT from Address_Type.


8. Click OK.

9. In the Relationship Properties tab, select “Foreign Key from "Address_AddressType(AddressType_ROWID)" to "Address_Type(ROWID_OBJECT)" (Restrict)”

10. Edit the Lookup Display Name changing it to the Address Type Desc column.

11. Click the Save button


12. In the Relationship Properties tab, select “Foreign Key from "Address_AddressType(AddressType_ROWID)" to "Address (ROWID_OBJECT)" (Restrict)”

13. Edit the Lookup Display Name changing it to the Address Line 1 column.

14. Click the Save button.


In this lab exercise, you

Defined the one-to-many relationship between the Customer and Address base objects

Defined the many-to-many relationship between the Address and Address Type base objects

In the next section of this lab, which continues on the next page, use what you’ve learned in the walkthrough to complete the skills review exercises.


Skills Review:

Create a Relationship

1. Create the relationship from Customer to Sub Category. The referencing column is Sub_Category_ROWID and the referenced column is Rowid_Object.

2. Change the Lookup Display Name for the new relationship: select Sub Catg Desc as the Lookup Display Name.

3. Save your changes and go to the Schema Viewer (Workbenches > Model > Schema Viewer) and review the data model you have defined thus far. It should look like this:

Note: If your schema does not reflect the change, validate trn_lab from Metadata Manager and try again.


Summary You have reached the end of Module 2 > Lesson 2 > Lab 1. In this lab exercise you defined relationships between base objects.


Module 2 Lesson 3 Lab 1: Define Lookups

Guidelines

Scenario:

This lab builds upon the previous labs in this class. In previous labs you defined the target data model with base objects and relationships that used foreign keys. Then, you created staging tables, for the base objects, tied to a particular source system.

Now, for each foreign key column in a staging table, you need to define a lookup. During the Load process, when data is moved into base objects, the lookup will translate the incoming source foreign key value to a corresponding foreign key value in the target data model.

For base objects, whose primary key is ROWID, you need to tell the MDM Hub how to translate the source foreign key value to the corresponding ROWID, by locating the source foreign key value in the base object’s XREF table.

Objectives:

Define the lookup strategy for translating the CRM_ID on the Address record from the CRM system, into a Customer ROWID_OBJECT value for the Customer ROWID foreign key you previously defined for the Address base object.

Duration:

20 minutes

Review:

Lookup in Walkthrough for the Class

CRM Address in the class data model has a foreign key CRM_ID that identifies the customer for that address in the database.

While CRM_ID is uniquely identifying a customer for the address through a relationship, the same identifier is not used in the Address base object of the MDM Hub to identify the customer in its related Customer base object. Rather, the MDM Hub uses the ROWID.

In the MDM Hub, the corresponding staging table (C_STG_CRM_ADDRESS) must be configured to lookup the ROWID of the Customer Base object that corresponds to the CRM_ID in the database table when a load is performed into the Address base object.

To get the ROWID you will define a lookup by identifying which lookup table to use (C_CUSTOMER_XREF), which lookup column to use (pkey_src_object), and which source system to use.


Walkthrough:

Define a Lookup

In Module 2 > Lesson 1 > Lab 1 you created the STG CRM Address staging table for Address data from the CRM system.

Later, in Module 2 > Lesson 2 > Lab 1 you defined a relationship from Address(Customer_ROWID) to Customer(ROWID_OBJECT).

Now you need to tell the system how to translate the CRM system’s customer ID into the Customer base object’s ROWID_OBJECTvalue.

In this lab, define the lookup strategy for Address.Customer_ROWID for the STG CRM Address staging table:


Below are the steps for defining a lookup:

1. Go to the Schema tool.

2. Verify that you have acquired a Write Lock.

3. Browse to the Address base object’s staging tables.

4. Click on the STG CRM Address staging table.

5. Click on the columns tab on the right.

6. Select the Customer_ROWID column. Note that the Edit Lookup Column button to the right of the columns list is enabled when you click on the Customer_ROWID column. This indicates that you can edit the lookup strategy for the selected column.

If the relationship had not already been defined, you would not be able to define the lookup.

7. Click the Edit Lookup Column button.

8. The Define Lookup dialog opens.

9. Select CRM as the Lookup System.

10. Select Pkey Src Object under the Customer Cross-Reference as the Lookup Table and Column.

This tells the system to use a join to C_CUSTOMER_XREF using rowid_system = ‘CRM’ and pkey_src_object in order to find the correct Customer ROWID_OBJECT value for the foreign key column on Address.


11. Click OK.


In this lab, you:

Defined the lookup strategy for translating the CRM_ID on the Address record from the CRM system into a Customer ROWID value.

In the next section of this lab, use what you’ve learned in the walkthrough to complete the skills review exercises.


Skills Review:

Create Additional Staging Tables and Define Lookups for Each

1. Create a staging table for the Address_Address Type base object. Call it “STG CRM Addr-Addr Type”. The source system is CRM. Select all columns.

2. Define the lookup for Address_ROWID using Address XREF’s pkey_src_object and source system = CRM.

3. Define the lookup for AddressType_ROWID using Address_Type XREF’s pkey_src_object and source system = CRM.

Imp: Prior to performing the next step, read the following important note as your labs will be impacted later if the following steps are not performed with this information in mind:

Do not define a lookup for the STG Sales Sub Category staging table’s Category ROWID column, as no such source data (no Sales Sub Category data) exists for the Sales source system. Uncheck the referencing ROWID to remove the lookup if it is checked. Likewise, the STG Sales Customer’s Sub Category ROWID should also be unchecked.

4. Go through each of the staging tables for Sub Category (see Imp note above for exceptions), Customer Note, Customer (see Imp note below), Address, and ensure each foreign key column has a lookup strategy defined. Use pkey_src_object (from the XREF) and choose a source system that is the same as the staging table’s source system.


Summary

You have reached the end of Module 2 > Lesson 3 > Lab 1. In this lab exercise you defined lookups for the various staging tables.


Module 3 Lesson 1 Lab 1: Register a Cleanse Match Server

Guidelines

Scenario:

Register a cleanse match sever that will handle cleanse requests.

Objectives:

Given the Cleanse Match Server tool, and the name and port of the cleanse match server, register a cleanse match server with 100% accuracy.

Duration:

5 minutes

Review

The Cleanse Match Server is a servlet that handles cleanse requests. This servlet is deployed in an application server environment. The servlet contains two server components:

a cleanse server handles data cleansing operations

a match server handles match operations

The Cleanse Match Server is multi-threaded so that each instance can process multiple requests concurrently. It can be deployed on a variety of application servers.


Walkthough

Register a Cleanse Match Server

Each MDM Multidomain Edition schema needs to have metadata telling it how to connect to a cleanse match server in order to test mappings (coming up in the next lab exercise) and run Staging batch jobs.

1. Make sure you have acquired the write-lock on your schema: Write Lock > Acquire Lock

2. Go to the Cleanse Match Server tool under the Utilities workbench

3. Click the Add button. The Add/Edit Cleanse Match Server dialog opens.

4. Enter infa-server as the Server.

5. Enter 8080 for the Port.

6. Ensure that the Cleanse Server and Match Server checkboxes are both checked.

7. Ensure that Cleanse Mode and Match Mode are both set to Online and Batch.

8. Make sure the Offline checkbox is not checked.

9. Click OK.

10. Highlight the cleanse match server you’ve just added, and click the Test button. The test should report success.



Now you will be able to test your mappings (created in the next lab) and run batch jobs that require a cleanse match server.

Summary You have reached the end of Module 3 > Lesson 1 > Lab 1. In this lab exercise you registered a Cleanse Match Server and tested the connection.


Module 3 Lesson 1 Lab 2: Create a Basic Mapping

Guidelines

Scenario:

After the schema has been defined, mappings should be defined prior to executing Stage jobs. Mappings define the transformations performed in Stage jobs.

In this lab

Create a basic mapping

Add a constant to the mapping

Test the basic mapping

Create a new mapping and use a conditional execution component with a function and a constant in the mapping

Test the conditional execution component

Objectives:

Given the MDM Mappings tool, a landing table, a staging table and a list of column associations, create a Basic Mapping with 100% accuracy.

Duration:

55 minutes

Review

A mapping defines movement of data from a landing table to a staging table. The simplest type of mapping only has Copy Column maps with no data standardization and no change in column values.


Walkthrough:

Create a Basic Mapping

1. Go to the Mappings tool and acquire a Write Lock on your schema.

You’ll notice that there are already some predefined mappings in your schema.

2. Right-click in the Mappings pane and choose Add Mapping

The Mapping dialog opens.

3. Follow the instructions below for the Mapping dialog:

a. Enter the mapping name as “Stage Customer Data from CRM system”.

b. Enter a description for the mapping.

c. Select LDG CRM Customer landing table as the landing table.


d. Select STG CRM Customer staging table as the staging table.

e. Click OK.

4. Click on the Diagram tab for the mapping you have just created. The landing table shows on the left of the diagram and the staging table on the right.

You will need to maximize your window and drag pane borders in order to see the entire diagram.

5. Click the Auto Mapping button – this will automatically create a copy column mapping for any staging table columns that have the same name as their landing table counterparts.


6. To manually create a column mapping, click on the output area for the column in the landing table and drag across to the input area for the corresponding column in the staging table.

Do this to map the landing table’s Crm ID to the staging table’s Pkey Src Object column.


7. All the “Non-System” columns in your staging table except Customer Class and Sub_Category_ROWID should now have values mapped to them. You will use a constant in the next walkthrough to provide a value for Customer Class. You will add the mapping for Sub_Category_ROWID later in this lab.

8. Click the Save button to save your mapping.

Walkthough:

Use a Constant in a Mapping

In this walkthrough you will add a constant value of ‘P’ (meaning Professional) as the value for Customer Class for all CRM Customer records.

1. In the same mapping (i.e. ‘Stage Customer Data from CRM System’), click the Add Constant button.

The Add Constant dialog appears.

2. Select String for this data type.

3. Enter P in the Value box. Don’t include any quotes around the value (this occurs automatically when the constant is added to the mapping).

4. Click OK. The constant is added to the mapping diagram near the top left hand corner.


5. Drag the constant to anywhere in the diagram where it doesn’t overlap with or obscure any other diagram components.

6. Hover over the output area (circle) for the constant. The circle will become highlighted.

7. Drag the output area to the input area for Customer Class on the staging table.


When the mapping is executed, every record in the staging table will have the value ‘P’ in the CUSTOMER_CLASS column.


Walkthough:

Test a Basic Mapping

In this walkthrough you will test the basic mapping to ensure that input values produce the expected results.

1. Select the Test tab.


2. Enter test values similar to those shown below:

Note: Use the date selector to choose today’s date for the Last Update Date field.

3. Click the Test button and review the outputs.

4. Confirm that the output values are as expected from your mapping, including the Customer Class, which should display the output value of ‘P’ due to the input being a constant. If not, return to the diagram and correct your Mapping.


5. If the test is successful continue onto the next walkthrough.

Walkthrough:

Use a Function and a Conditional Execution Component in a Mapping

For this exercise, you will create a new mapping from LDG Sales Customer to STG Sales Customer.

In the source data for this exercise, there are some customers that have no name or address information other than the zip code. Those records are for grouping sales that are reported per region (i.e. ZIP-code area) instead of per individual or per organization.

The Cust Type column on the landing table determines what type of customer each record in the landing table represents. If Cust Type is ‘R’, then the customer record is a region.


1. Right-click in the Mappings list and choose Add Mapping.

The Mapping dialog appears.

2. Enter the mapping name as Stage Customer Data from Sales System.

3. Enter a description for the mapping.

4. Select the LDG Sales Customer landing table you created in an earlier exercise as the landing table.

5. Select the STG Sales Customer staging table you created in an earlier exercise as the staging table. The names for these tables could be slightly different from what’s shown here; that’s acceptable as long as you recognize the appropriate tables.

6. Click OK.


7. Click on the Diagram tab for the mapping you have just created.

The logic you will be defining is:

Case: If CaseValue = ‘R’, then concatenate the word ‘REGION ’ (note the space after the word) with the billing address zip code. Map the result to the conditional execution component output. Case: If CaseValue = any other value: move the original Cust Name value to the conditional execution component output.

To achieve this, you will need to define the inputs and outputs for the conditional execution component, as well as the case values.

8. To get started with this, click the Add Conditional Execution Component button.

The Edit Condition dialog opens.


Note: The CaseValue input is standard. When you use the conditional execution component in the mapping, you will map Cust Type from the landing table to the CaseValue input. This is the input that gets evaluated to determine which branch of the conditional logic to execute.

You will also need inputs to which you will map Cust Name and Bill Addr Zip.

9. Double-click on the Inputs component in the Edit Condition window. The Inputs dialog is displayed.


a. Select input1 in the list and click the Edit the Selected Parameter button to edit the input value’s information. The Edit Parameter dialog displays.

b. Change the name to something more descriptive than input1 – use Input Full Name. The data type can be left as String. It is good practice to enter a description for input and output parameters to assist anyone else who needs to understand your mapping.

c. Click OK.

d. In the same Inputs dialog, click the Add a Parameter button to add a new input for Zip. The Add Parameter dialog displays again.

e. Enter Input Zip as the parameter name

f. Leave the data type as String


g. Enter a description for the input parameter.

h. Click OK.

10. Click OK to close the Inputs dialog.

11. Double click on the Outputs component in the Edit Condition window. The Outputs dialog is displayed.


By default, Informatica MDM Multidomain Edition provides a single String output called output. It is good practice to change that name to something more descriptive.

NOTE: If you need to change the data type of the default output to something other than String, then you must delete the default output and add a new output with the data type you require. A conditional execution component can have multiple outputs. However, for purposes of this exercise, we only need the one output. That output value will be a string, but you will change the name of the parameter to something more meaningful.

12. Select output in the list and click the Edit the Selected Parameter button to edit the output value’s information.

a. Change the Name to something more descriptive than output – let’s use Output Full Name.

b. The data type can be left as String.

c. Enter a description for the output parameter.

d. Click OK.


13. Click OK to close that Outputs dialog.

So far you’ve defined in input and output parameters for the conditional execution component. You still need to define the case values, and for each case value, the logic to be executed.

The case values are displayed in a list in the left-hand pane of the Edit Condition dialog. The tool provides a default case value of case 1. The symbol (*) indicates that this is the default case, i.e. this is the case that will be executed if the value mapped to caseValue in the input does not match any other value in the case values list.

Leave this case value as it is for this exercise.

14. Add a new case value for the Cust Type value R. Click the Add a New Case Value button to the right of the case values list. The Add Value dialog displays. Enter R as the value.

Note: Case values are always String values.

15. Click OK.


The case values list now shows R and case 1(*). Now you’re ready to define the logic for each case.

16. Select R in the case values list (it is important to select the right value, here, or else you will be defining the case logic under the incorrect case value).

Reminder: The logic for this case was identified earlier as: If CaseValue = ‘R’, then concatenate the word ‘REGION ’ (note the space after the word) with the billing address zip code. Map the result to the conditional execution component output.

So you will need a constant for the word ‘REGION ’ as well as the Concatenate function to do the concatenation.

a. Make sure you have the R case value selected in the Case Values list.

b. Click the Add Function button.

c. In the Choose function to add dialog, choose the Concatenate function from the String Functions list.


d. Click OK.

The Concatenate function is added to the conditional execution component diagram.

e. Right-click on it and change its display mode to Expanded Mode so that you can see the input and output parameters better.

17. Click the Add Constant button.


a. Select String as the Data Type for this constant.

b. Enter ‘REGION ’ as the value for this constant (without quotes).

Remember to include a space character at the end of the word so that there will be a space between the word and the zip number in the final output.

c. Click OK.

18. Create the execution logic for this case value as follows:

a. Drag the output area for the “REGION” constant to the input area for string1 in the Concatenate function.

b. Map Input Zip to the string2 input in the Concatenate function.

c. Drag the output string from the Concatenate function to the Output Full Name output parameter in the Outputs for the conditional execution component.


19. Select case 1 (*) in the case values list.

Reminder: The logic for this case was identified earlier as:

If CaseValue = any other value: move the original Cust Name value to the conditional execution component output (Output Full Name output parameter).

20. Drag the Input Full Name input parameter to the Output Full Name output parameter.


21. Click OK in the Edit Condition dialog to add the conditional execution component to your mapping.

22. Right-click on the conditional execution component in your mapping and change its’ display mode to Expanded Mode so that you can see the input and output parameters you defined.


23. Map the conditional execution component parameters as follows:

a. Drag Cust Type from the landing table to the caseValue parameter in the conditional execution component

b. Drag Cust Name from the landing table to the Input Full Name parameter in the conditional execution component.

c. Drag Bill Addr Zip from the landing table to the Input Zip parameter in the conditional execution component.

d. Drag the Output Full Name parameter in the conditional execution component to Full Name in the staging table.

24. Perform the following two direct column mappings:

a. Map Cust Id in the landing table to Pkey Src Object in the staging table

b. Map Last Update Date in the landing table to Last Update Date in the staging table


25. Click the Save button in the upper right to save your mapping.

Note: The mapping is not yet complete – we still need to map something to the staging table’s Customer Class column. That will be performed in the next lab, using a Cleanse List.


Skills Review:

Test a Conditional Execution Component in a Mapping

In the previous walkthrough, you created a Conditional Execution Component in a new mapping to address source data where some customers that have no name or address information other than the zip code (used for grouping sales that are reported per region, i.e. ZIP-code area, instead of per individual or per organization).

If Cust Type in the staging table is ‘R’, then the customer record is a region and for these types of customers, the mapping will create a value for customer name; it should be made up of the word ‘REGION ’ concatenated with the zip code.

1. Test the mapping by providing values for the following input fields (taken from the LDG Sales Customer table mapping shown above):

Last Update Date

Cust Name

Cust ID

Cust Type (Test the two cases for this value by entering ‘R’ then any other value)

Bill Addr Zip

2. Check the resulting values in the output fields leading to in the staging table:

Pkey Src Object

Last Update Date

Full Name

The two resulting values should be similar to the screenshots provided over the next two pages:


Case 1: Cust Type = ‘R’


Case 1: Cust Type = Other Value

Continue on to the next page to complete the second Skills Review in this lab.


Skills Review:

Create Additional Mappings

1. Go to the Mappings tool.

2. Edit the mapping for Stage Sub-Category data from CRM system so that the pkey_src_object column contains only the Sub Catg No.

Note: Delete the existing Concatenate function.

3. Save the mapping.

4. Return to the Stage Customer Data from CRM system mapping. Use a Trim function to map Sub Catg No to Sub Category ROWID. Don’t forget to test the results.

5. Create the mapping for staging CRM Address data.


Add a mapping called Stage Address data from CRM system. The landing table is LDG CRM Address and the staging table is STG CRM Address. Create column mappings as described in the table below:

Note: In a real-world implementation, you would typically use an address cleansing tool (such as Informatica’s AddressDoctor) to do the address standardization and validation in your mapping.

Source Column(s)

Transformation Target Column

Last Update Date None: copy-column mapping Last Update Date CRM Id Trim whitespace Customer ROWID CRM Id Addr Id Address Line

Concatenate CRM Id, Addr Id and Address Line, separated with a ‘|’ (i.e. pipe / vertical bar) character. For example: 1234|5678|99 Main St Trim whitespace from the three columns before concatenating.

Pkey Src Object

Address Line Trim whitespace Address Line 1 City Name Trim whitespace City State Code Trim whitespace State Zip Trim whitespace Zip 10 Zip The first 5 characters of the zip code

(hint: use a String function for this) Zip 5

6. Test the mapping using values that you are familiar with, such as mailing and billing addresses, ID’s and so forth.

7. Create the mapping for staging Sales Billing Address data.

a. Add a mapping called Stage Billing Address data from Sales system. The landing table is LDG Sales Customer and the staging table STG Sales Bill To Addr from the Sales system.

This mapping must not create records in the staging table if both BILL_ADDR_LN_1 and BILL_ADDR_ZIP are null. To ensure this:

i. Click the Query Parameters tab

ii. Click Enable Condition

iii. In the Condition text field type: (BILL_ADDR_LN_1 is not null OR BILL_ADDR_ZIP is not null)

Note: Ensure that these columns match those in the landing table.

iv. Click the Validate button to check the syntax of the condition you entered

b. Create column mappings as described in the table below.


Source Column(s)

Transformation Target Column

Last Update Date

Copy Column Last Update Date

Cust Id Trim whitespace Customer ROWID Cust Id Bill Addr Ln1

Concatenate Cust Id and Bill Addr Ln1, separated with a ‘|’ (i.e. pipe / vertical bar) character. For example: 1234|99 Main St Trim whitespace from both columns before concatenating.

Pkey Src Object

Bill Addr Ln1 Trim whitespace Address Line 1 Bill Addr City Trim whitespace City

Bill Addr State Trim whitespace State

Bill Addr Zip Trim whitespace Zip 10 Bill Addr Zip The first 5 characters of the zip

code (hint: use a String function for this)

Zip 5

8. Test the mapping using values that you are familiar with, such as mailing and billing addresses, ID’s and so forth.

9. Create the mapping Stage Shipping Address data from Sales system.

Because the landing table and target base object for this mapping is the same as for the previous mapping you created, you can simply copy that mapping and use it as a starting point for this mapping:

a. In the mapping called Stage Billing Address data from Sales system, click the Copy Mapping button (located underneath the Save button)

b. Enter the mapping name and select the staging table (STG Sales Ship To Addr), then click OK.

c. Click the Query Parameters tab

d. In the Condition text field type, change the text to: (SHIP_ADDR_LN1 is not null)

Note: Ensure that these columns match those in the landing table.

e. Click the Validate button to check the syntax of the condition you entered

f. Edit the column mappings so that they are the same as described in the table below.


Source Column(s) Transformation Target Column Last Update Date None: copy-column mapping Last Update Date Cust Id Trim whitespace Customer_ROWID Cust Id Ship Addr Ln1

Concatenate Cust Id and Ship Addr Ln1, separated with a ‘|’ (i.e. pipe / vertical bar) character. For example: 1234|99 Main St

Pkey Src Object

Ship Addr Ln1 Trim whitespace Address Line 1 Ship Addr City Trim whitespace City Ship Addr State Trim whitespace State Ship Addr Zip Trim whitespace Zip 10 Ship Addr Zip The first 5 characters of the zip code

(hint: use a String function for this) Zip 5

10. Test the mapping using values that you are familiar with.

Summary

You have reached the end of Module 3 > Lesson 1 > Lab 2. In this lab exercise you created and used a Conditional Execution Component in a Mapping, which contained a Constant and a String Function (Concatenate). You also defined the two cases for the condition. At the end you tested the two cases in the condition.

In the Skills Review section you created additional mappings.


Module 3 Lesson 1 Lab 3: Create a Cleanse List and a Graph Function in a Mapping

Guidelines

Scenario:

Cleanse lists and graph functions may be used to validate, cleanse and transform values associated with a mapping. In this lab you will create a simple cleanse function to transform Customer Type values (Cust Type) to appropriate Customer Class values. You will also create a simple graph function that validates existent and non-existent Zip Code values to be used in existing Address mappings.

In this lab

Create a cleanse list

Create a graph function

Use cleanse lists and a graph function in various mappings

Objectives:

Given the logic, a cleanse list and graph function, and the Cleanse Function tool, create a cleanse list and graph function in a Mapping with 100% accuracy.

Duration:

45 minutes

Review

Cleanse List – A cleanse list is a user-defined list of search and replace values. It may be used to identify and/or replace or remove known characters or strings of characters from the input text and for performing common text replacements/translations/abbreviations

Graph Functions - A graph function is a cleanse function that you can visualize and configure graphically using the Cleanse Functions tool in the Hub Console. Graph functions have one or more inputs (input parameters) one or more outputs (output parameters). For each graph function, you must configure all required inputs and outputs.


Walkthrough:

Use a Cleanse List in a Mapping

In this Walkthrough, you will add a pre-existing Cleanse List to a mapping. Use the same mapping from the previous lab (Stage Customer Data from Sales System) for that purpose.

1. Go to the Mappings tool and acquire a Write Lock on your schema.

2. Select the Stage Customer Data from Sales System mapping and click the Diagram tab.

3. Click the Add Function button.

4. Expand the Training group, select CL-Sales Customer Type.


5. Click OK.

6. Right-click on the cleanse list component in the mapping and change its display mode to Expanded Mode so that you can see the input and output parameters.

7. Add constants to the mapping to provide input values for the function as described above. You will need the following constants:

A string constant with the value ENTIRE – map this to searchType in the cleanse list function.

A boolean constant with the value true – map this to replaceAllOccurrences in the cleanse list function.

A String constant with the value U – map this to defaultValue in the cleanse list function. This will indicate ‘Unknown’ if the landing table provides a customer type value that is not already known. Note: The cleanse list provides translation values for the strings IND, R, RLO, WRO, RSO, WO, WR.


8. Map Cust Type from the landing table to input in the cleanse list function. Use the Trim function between the two fields to remove any training spaces.

9. Map matched in the cleanse list function to Customer Class in the staging table.

10. Click the Save button to save your mapping.

11. Select the Test tab and test your mapping.

12. Enter input values to test the following fields:

a. Enter a date for Last Update Date.


b. Enter a Cust Name.

c. Enter any number for a Customer Id.

d. Enter a Bill Addr Zip value.

e. Enter the following values for Cust Type each time and test the resulting Customer Class value:

IND, R, RLO, WRO, RSO, WO, WR, and any other unknown value.

Each of the above values should resolve as follows:

f. When testing the Cust Type of ‘R’, ensure that the Full Name field results with ‘REGION Zipcode’.

Important: Do not proceed to the next lab unless you have sufficiently tested the mapping.

Walkthrough:

Create a Cleanse List

Now, you will create a Cleanse List that will be used to standardize Name Generation values (JUNIOR/JNR/JR, SENIOR/SNR/SR)

1. Select the Cleanse Functions tool from the Workbenches list on the left and make sure that you have acquired the Write Lock on your schema.

2. Right-click on the Cleanse Functions node at the top of the cleanse functions tree and choose Add User Library. This creates a group under which you can create your own cleanse graphs and cleanse lists.

3. Name your user library My User Library.

4. Select the My User Library node in the cleanse functions tree. Right click on this node and choose Add Cleanse List.

5. The Add Cleanse List dialog displays. Enter a name for the cleanse list as well as a description, as follows:


Note: It is good practice to include information in the description on how the cleanse list should be used – i.e. what parameter values work best with this cleanse list.

6. Click OK.

7. Click on the CL-Standardize Name Generation node in the cleanse functions tree. The properties page on the right shows General, Details and Test tabs.

8. Select the Details tab. This is where you define the cleanse list items. You can import them from tables in an Oracle schema or you can enter them manually one at a time. The cleanse list for this exercise is a short one, so you’ll be entering it manually.

9. Click the Add Match and Output String button. Enter the following in the dialog that displays:


10. Click OK.

11. Repeat the previous step for each of the following search and output string pairs:

Search String Output String

SNR SR

SR SR

JUNIOR JR

JNR JR

JR JR

12. Select the Test tab

13. Test your cleanse list with all the valid values for the input field.

14. Test the cleanse list with a non-matching value. Notice the difference between the output and matched parameters, when a non-matching input value (not in the cleanse list) is used.


Non-Matching example:

Matching Example:

Walkthrough:

Use the New Cleanse List in a Mapping

Now, use the cleanse list that you just created in an existing mapping.

1. Go back to the Mappings tool.

2. Open the mapping called Stage Customer Data from CRM System which you created in an earlier lab.

3. Click on the mapping line for the Name Generation column.


4. Delete the mapping line.

5. Click the Add Function button and choose My User Library > CL-Standardize Name Generation.


6. Add a string constant with the value as ‘ENTIRE’. This will be used to specify the searchType parameter for the cleanse list.

7. Map to the cleanse list as shown in the following screen print:


8. Map from the output parameter of the cleanse list to the Name Generation column in the staging table, as shown in the above screen print.

9. Save the mapping and test it.

Walkthrough:

Create a Graph Function

In this exercise you will create a reusable graph function. The purpose of the function is to check whether an input zip code is valid, and to return “Y” if the zip is valid or “N” if the zip is not valid. Validity of the zip is a determined by a simple check – if the zip is NULL or an empty string then it is not a valid zip code.

1. Select the Cleanse Functions tool from the Workbenches list on the left and make sure that you have acquired the Write Lock on your schema.

2. Select the My User Library node in the cleanse functions tree. Right click on this node and choose Add Graph Function.

3. The Add Graph Function dialog displays. Enter a name and description as shown below:

4. Click OK.

The properties page on the right appears and shows General, Details, and Test tabs.

5. Select the Details tab.

Note that it provides a diagram page almost identical to the Diagram page in the mappings tool. The main difference is that the Mappings tool has the landing table as the source of mappings and the staging table as the target of mappings, while in the cleanse graph diagram, the source is one or more input parameters, and the target is one or more output parameters.


6. Double click the Inputs component to edit the input parameters.

7. Select the input parameter.

8. Edit the input parameter by clicking the Edit button .

9. Rename “input” to “Zip Code”.

10. Click OK.

11. Likewise edit the Outputs component and rename “output” to “Validity Indicator”.

12. Add the Trim function to the cleanse graph. Reminder: Trim can be found in the String Functions group. This function trims all whitespace from the input value before checking whether the input is empty or not.


13. Add the Is String Empty function to the cleanse graph (this can be found in the Logic Functions group).

14. Add the Choose String function to the cleanse graph (also found in the Logic Functions group).

15. Click the Add Constant button to create a new string constant – the value should be “Y”. Repeat this step to create a string constant with the value “N”.

16. Map the components as shown below:

This reusable graph function is very basic. It checks whether the Zip Code is NULL, empty, or if a value exists. If empty or NULL, Is String Empty returns “Y”, otherwise it returns “N”. The Choose String function transposes “N” to “Y” and vice versa. Thus, if the Zip Code is not empty or not NULL, “Y” is returned, which is then used as the Validity Indicator, and vice versa.

17. Save the cleanse graph.

18. Select the Test tab.

19. Enter input values and click test to make sure that the output is correct. For example:

Enter 1234 as the Zip Code - the result should be Y

Clear the Zip Code - the result should be N

Enter 5 space characters as the Zip Code – the result should be N


Walkthrough:

Use the Graph Function in a Mapping

Now you will use the cleanse graph you’ve just created.

1. Go back to the Mappings tool

2. Open the mapping called Stage Address Data from CRM System which you created in an earlier lab

3. Click the Add Function button and choose My User Library > Validate Zip Code.

4. Map the landing table column called Zip to the input parameter for the Validate Zip Code function.

5. Map the output parameter from the Validate Zip Code function to the staging table column called Valid Ind.

6. Save the mapping and perform a quick test.

In the next section of this lab, which continues on the next page, use what you’ve learned in the walkthroughs to complete the skills review exercises.


Skills Review:

Use a Graph Function to Validate Fields in Existing Mappings

In this skills review, you will validate the Zip Code using the Validate Zip Code graph function for the Shipping and Billing Addresses of Sales system.

1. Open the mapping called Stage Billing Address data from Sales system.

2. Add the Validate Zip Code graph function to the mapping.

3. Use the landing table’s Bill Addr Zip column as the input parameter and map the output to the staging table’s Valid Ind column.

4. Save and test the mapping.

5. Open the mapping called Stage Shipping Address data from Sales system.

6. Add the Validate Zip Code graph function to the mapping.

7. Use the landing table’s Ship Addr Zip column as the input parameter and map the output to the staging table’s Valid Ind column.

8. Save and test the mapping.

Summary

You have reached the end of Module 3 > Lesson 1 > Lab 3. In this lab, you:

Created a simple cleanse function to transform the Cust Type values (IND, R, RLO, WRO, RSO, WO, and WR) to an appropriate Customer Class values

Created a simple graph function that validates existent and non-existent Zip Code values.

Used the graph function and the cleanse lists in various mappings


Module 3 Lesson 2 Lab 1: Define Delta Detection Options and Raw Data Retention Periods

Guidelines

Scenario:

In this lab you will set options in the staging tables that have mappings to preserve data in the raw table for three (3) months. You will also enable delta detection by comparing all columns in a mapping for Sales data versus using the Last Update Date column only to detect changes for CRM data.

In this lab

Define Delta Detection Options

Define Raw Retention Periods

Objectives:

Given the Schema tool, define delta detection options and raw data retention periods with 100% accuracy.

Duration:

15 minutes

Review

Delta Detection – Delta detection is the process of identifying the new and changed records in the data from a source system by comparing the current data set provided by the source with the previous data set provided by the source.

Audit Trail/Raw Data Retention – This staging table property enables the history of the raw data, as stored in landing table at the start of Stage process (i.e. before actual cleansing). Raw history is stored in a table named staging_table_name_RAW. You can specify the Audit trail retention period.


Walkthough:

Define Delta Detection and Raw Retention Periods for Staging Tables

In this lab you will go back to the Schema tool and observe how to define delta detection options and define raw retention periods for all the staging tables.

Important: If you run into a problem within the lab later in this course, you may need to re-run the LOAD process. RE-Loading the same records require that you turn Delta Detection off. Thus, it is suggested that you perform this lab by only setting Audit Trail for each staging table that has a mapping (up to and including step 3b). You may read through it and after you have completed your last lab you may return here to set Delta Detection, or as needed. For now do not set Delta Detection.

1. Go to the Schema tool in the Workbenches pane. Model > Schema

2. Ensure that you have a Write Lock.

3. For each staging table that has the Settings tab enabled:

a. Click the Settings tab.

b. Check the Preserve an audit trail in the raw table for checkbox to switch on the audit trail option.

i. Specify a raw retention periods of 3 months.

c. Check the Enable delta detection checkbox to switch on delta detection.

d. For the CRM system’s staging tables, delta detection should be done on last update date. Save the table after setting the options.


e. For the Sales system’s staging tables, delta detection should be done on all columns.

Note: If a Staging table does not have a mapping then the Settings tab is grayed out.


Summary You have reached the end of Module 3 > Lesson 2 > Lab 1. In this lab, you:

Set audit trail to preserve data in the raw table for 3 months within every staging table that has a mapping

Enabled delta detection by comparing all columns in a mapping for Sales data

Enabled delta detection by using the Last Update Date column to detect changes for CRM data


Module 3 Lesson 2 Lab 2: Run Staging Jobs

Guidelines

Scenario:

In the previous labs of this module, you configured the Stage process by registering a Cleanse/Match server, creating mappings, and defining audit trail and delta detection. This completes the Stage configuration. In this lab you will run the Staging jobs to transform and move data from the landing tables to the staging tables.

In this lab

Run Stage jobs

Objectives:

Given the Batch Viewer tool and a list of Base Objects, run a Stage job with 100% accuracy.

Duration:

20 minutes

Simulate the ETL Process

The training schema has a SQL script called TRN_create_ETL_simulation_proc.sql that simply deletes all records in the target landing tables and inserts records from the ZZ_* “source” tables into the landing tables.

If you have used the table names and column names when creating their landing tables, then this script should run without any problems. However, if you have used different names for your landing tables, then the procedure will give a run time error and you will need to edit the table name or column in the appropriate place in the procedure (not the database table or column name). Note: This script is independent of the Informatica MDM Hub. It is only provided in order to make it easier to load data into landing tables for this course.

1. Edit the contents of the following file using Notepad++: C:\MDM_training\MDM330_901_Configuring_MDM_MDE\Setup\ TRN_create_ETL_simulation_proc.sql

2. Copy all the contents of the file.

3. Start SQL Developer.


4. Connect to trn_lab.

5. Paste the text from the TRN_create_ETL_simulation_proc.sql into a worksheet.

6. Run the script. The result should be as follows:

0 rows deleted.

0 rows deleted.

0 rows deleted.

0 rows deleted.

0 rows deleted.

0 rows deleted.

45 rows inserted.

11 rows inserted.

84 rows inserted.

46 rows inserted.

12 rows inserted.

3 rows inserted.

commited.

Walkthrough:

Run a Batch Job

1. Check that each of your landing tables has at least a few rows of data (refer back to instructions at the beginning of this lab) Note: C_LDG_CRM_CUST_ADDR doesn’t contain any data. You may ignore that table.

2. Open the Batch Viewer tool. It is part of the Utilities workbench.

3. Set the Group By view type at the bottom of the main Batch Viewer list to Procedure Type


4. Expand the Stage tree node. You will see a stage job for every mapping in your schema.

5. Select the job called Stage Customer Data from Sales System.


6. Click the Execute Batch button to run the stage job that executes the logic defined in your mapping

7. Click Refresh Status to see when the job completes.

Once the job has completed, you will see an entry for the job in the Batch Viewer tree view.

8. Click on the job entry in the tree view to see its full details, and to see errors and warnings as well as the job metrics.

In this lab, you ran a staging batch job. In the next section of this lab, which continues on the next page, use what you’ve learned in the walkthrough to complete the skills review exercises.


Skills Review:

Run Stage Batch Jobs on Remaining Mappings

1. Run the job called “Stage Address data from CRM system”. Check the status of the job after running it to ensure that there are no errors or rejects.

Total Inserted = 45

Run the job called “Stage Billing Address data from Sales system”. Check the status of the job after running it to ensure that there are no errors or rejects. Total Inserted = 84

2. Run the job called “Stage Category data from CRM system”. Check the status of the job after running it to ensure that there are no errors or rejects. Total Inserted = 3

3. Run the job called “Stage Customer Data from CRM system”. Check the status of the job after running it to ensure that there are no errors or rejects. Total Inserted = 46

4. Run the job called “Stage Customer Note data from CRM system”. Check the status of the job after running it to ensure that there are no errors. There should be 2 rejects; use the View Rejects option to determine why those records were deleted. Total Inserted = 9; Rejected = 2

5. Run the job called “Stage Shipping Address data from Sales system”. Check the status of the job after running it to ensure that there are no errors or rejects. Total Inserted = 26

6. Run the job called “Stage Sub-Category data from CRM system”. Check the status of the job after running it to ensure that there are no errors or rejects. Total Inserted = 12

7. Use SQL Developer to review the data that’s been inserted into the staging tables by the jobs you have just run.

Summary You have reached the end of Module 3 > Lesson 2 > Lab 2. In this lab, you ran

Stage batch jobs on all the mappings you had created earlier.


Module 4 Lesson 1 Lab 1: Set Trust, Validation Rules, Cell Update, and Null Update

Guidelines

Scenario:

In the previous module, you configured the Stage process and ran the various Stage jobs for each of the mappings defined. Data is now in the various staging tables. In this module you will begin by configuring the Load process, which includes setting trust and creating validation rules.

In this lab

Switch on Trust and Validation flags for columns in the Customer base object

Define trust settings for the trusted columns in the Customer base object Define a validation rule for the Customer base object Use the Null Update and Cell Update properties of a staging table

Objectives:

Given delineated columns and the Schema tool, set trust with 100% accuracy.

Given the SQL statement and the Schema tool add a Validation Rule with 100% accuracy.

Given delineated columns and the Schema tool, set Cell Update and Null Update with 100% accuracy.

Duration:

20 minutes

Walkthrough:

Switch on Trust and Validation Flags for Columns in a Base Object

1. Open the Schema tool and acquire a Write Lock on your schema.

2. Browse to the Column node of the Customer base object.

3. In the Column properties, switch on the trust indicator for the following columns:

FULL_NAME FIRST_NAME MIDDLE_NAME LAST_NAME NAME_GENERATION


4. Still in the Column properties, switch on the validation indicator for the following columns:

FIRST_NAME MIDDLE_NAME LAST_NAME NAME_GENERATION

Full_Name will have trust switched on for it, but not validation.

Note: You do not have to have validation switched on for every column that has trust switched on. Only use validation rules where there are specific conditions in the data—conditions that would result in a higher trust source system providing invalid data where a lower trusted source system has more correct data and should be allowed to overwrite the value from the higher trust source system.


Note: If you get a message regarding running the synchronization procedure, it is because you have changed the trust settings after having loaded data into the base object.

If you do get the message about running the synchronization procedure, do not delay running it. Go to Utilities > Batch Viewer. Click the Execute Batch button on the right. Expand the job node on the left and check for its successful


run before continuing with anything else in Informatica MDM Multidomain Edition.

Walkthrough:

Define Trust Settings for the Trusted Columns in a Base Object

1. Select the Systems and Trust tool from the Model workbench. Model > Systems and Trust

The source systems and the tables that have trust enabled columns are listed as tree views. The System tree lists all the sources defined and the Trust tree lists the trust enabled tables.

2. Expand the node for Trust and select the Customer base object.

When you select the Customer base object, the Table Identity page on the right shows a list of the Customer columns that are enabled per source.

3. Click on Full Name.

The top pane on the right allows you to edit the values for the column for all sources that provide the column.

4. Enter the following trust values for Full Name for the three systems:


You’ll add the rest of the trust values later in this lab. For now, you have just defines trust values for Full Name.

5. Click the Save button to save the trust settings.

Walkthrough:

Define Validation Rules for a Base Object

In this walkthrough exercise you will define validation rules for the Customer base object.

1. Go back to the Schema tool

2. Expand the Customer base object node in the Schema tree.

3. Click on Validation Rules Setup.


4. Click the Add Validation Rule button.

5. Enter the rule name as “Downgrade First Name where NULL”.

The rule name is simply a descriptive label for the rule.

6. Click on the Rule Type drop down. This provides a template for the rule in the Rule SQL area.

7. Select Existence Check.

8. If the Rule Columns list does not show the First Name column, then click the Edit Rule Column button and select FIRST_NAME as the column that will be downgraded by the rule.

9. Change the Downgrade Percentage to 100%, and click the Reserve Minimum Trust option.

10. Change the Rule SQL to: WHERE S.FIRST_NAME IS NULL

Remember that the validation rule specifies the bad condition, that is, the condition under which the trust must be downgraded.

11. Click OK to save the validation rule. The Validation Rules property page displays the rule you’ve just added. You can edit the rule in the properties page.


Walkthrough: Add Another Validation Rule

1. Click the Add Validation Rule button to add another validation rule

2. Enter the name for the rule as Downgrade First Name where length < 3

3. Select Custom as the Rule Type

4. Select First Name as the column that will be downgraded by the rule

5. Set the downgrade percentage to 30% and click the Reserve Minimum Trust option

6. Type in the Rule SQL as follows: WHERE ( length(s.first_name) < 3 AND s.first_name <> 'ED' )

Note the parentheses around the conditions, because of the AND clause.

Note the use of ‘s.’ as a table alias prefixing each column name. S is an alias, hard-coded in the product.

The above rule will downgrade any first names that are shorter than 3 characters long and that aren’t a valid 2-character first name. This validation rule is intended to illustrate the syntax – it is not a typical real-world validation rule!


7. Click OK to save the validation rule.

Walkthrough: Sequence Validation Rules

Notice that you now have two rules that will downgrade the same column.

The order of validation rules is extremely important. You should try to order the validation rules such that the rule with the greatest downgrade percentage for a column is ordered last. Validation rules are not cumulative for the downgrade percentage.

Of the 2 rules you’ve just created, Downgrade First Name where NULL has the highest downgrade percentage and should be lower in the list than Downgrade First Name where length < 3.


1. Click the Downgrade First Name where NULL rule.

2. Click the Move Down arrow to move the Downgrade First Name where NULL rule down in the list.

Walkthrough: Use Null Update and Cell Update Options for a Staging Table

Cell Update

1. In the Schema tree, go to the Customer base object’s staging tables Schema > Customer > Staging Tables

2. Select the STG CRM Customer staging table

3. Click on the Columns tab and switch on the Cell Update option at the bottom of the page.


4. Click Save, but don’t leave the properties page just yet

Null Update

1. Click the Columns tab on the staging table’s properties page

2. Select the Allow Null Update option for the Name Generation field.

This means that if a source system provides a name generation at first, and then later updates the name generation to null, the Customer Master will allow the null update to take place, that is, this is one of those places where ‘nothing is better than something’ usually applies.


3. Click Save.

In this lab, you:

Switched on Trust and Validation flags for columns in the Customer base object

Defined trust settings for the trusted columns in the Customer base object

Defined a validation rule for the Customer base object

Used the Null Update and Cell Update properties of a staging table

In the next section of this lab, use what you’ve learned in the walkthrough exercises to complete the skills review exercises.


Skills Review:

1. Define the trust and validation rules for Addresses as described below. Assign trust settings relative to other systems. You may choose the trust values yourself, or use the explicit values stated in the description below.

Addresses from the Sales system are more reliable that addresses from the CRM system.

Addresses from the default Admin system are the most reliable, but should not survive for longer than 3 months, because within that time period the Sales system’s support team has to follow up and verify all addresses that are corrected in the Customer Master.

On average, addresses for our fictitious company’s customers change after 7 years.

Address elements should be treated as being part of the same logical trust group. This means that

o Trust and Validation should be set for all address columns with the exception of foreign keys and ROWID values.

o Trust system values (Maximum, Minimum, Units, Decay, and Graph Type) should reflect similar values for all the columns in the three systems.

Note: For this class the following values may be used for each column of the Address table to remain on the same page as all other users in the class, and as the classroom example. However, keep in mind that each system’s value could be chosen by you as long as they are set proportionate to the example described below between systems. Note: Enter values for Unit and Decay in the chart below.

System Maximum Minimum Unit Decay Graph Type

Sales 80 30 SIRL

CRM 70 20 SIRL

Admin 90 0 SIRL

In addition, the Allow Null Update option should be switched on for every address column in every address staging table (do not set it for foreign-key columns)

If an address fails zip code validation (i.e. Valid_Ind = 'N'), the address’ trust should be downgraded by 75%, but minimum trust should be reserved. Remember to treat the address as one logical trust unit (select all columns for the SQL). Note: If in doubt about your chosen settings, you may check it against the completed instructor ORS (instr_lab_complete).


2. Go to the Customer base object’s staging tables and open STG Sales Customer. Switch on Cell Update for this staging table.

Summary You have reached the end of Module 4 > Lesson 1 > Lab 1. In this lab, you configured Trust and Validation for columns in the Customer base object. You also used the Null Update and Cell Update properties of a staging table.


Module 4 Lesson 1 Lab 2: Run Loading Jobs

Guidelines

Scenario:

Because you’ve defined trust and validation rules in the previous lab and the staging tables are populated, you can go ahead and run Load jobs now. Load jobs will load data from the staging tables into their target base objects.

In this lab

Run Load jobs

Objectives:

Given the Batch Viewer tool and a list of base objects, run the Load process with 100% accuracy.

Duration:

40 minutes

Walkthrough:

Review the Contents of a Base Object and its Staging Tables

1. Review the staging tables used in the Category base object.

2. Start SQL Developer.

3. Connect to trn_lab.

4. Expand Tables.

5. Select C_STG_CRM_CATEGORY (STG CRM Category)


6. Click the Data tab and view the contents in the right pane.

There are three (3) records.

7. Select C_STG_SALES_CATEGORY (STG Sales Category).

The staging table does not contain any records.

Walkthrough:

Run the Load Job for each Staging Table of a Base Object

1. Go to the Mappings tool.

2. Observe the mapping associated with the Category base object’s staging tables.

Only one (1) mapping exists for Category data.


Note: The Sub_Category base object (a child of the Category parent base object) also has a mapping associated with its staging table called Stage Sub-Category data from CRM system.

The sequence in which you run Load jobs matters. Don’t try to load a base object before you have loaded its’ parent base objects – if you do, the load of the child base object will fail because the lookups on the parent base object will fail.

3. Use the Batch Viewer to run the Load jobs for the staging table of the Category base object (that has a mapping). Utilities > Batch Viewer

4. Expand the Load node.

5. Load data into the Category base object from the STG CRM Category staging table using the Load from STG CRM Category job.

6. Check the status of the job.

Three (3) records were loaded.

7. Got to SQL Developer and observe the C_CATEGORY base object.


Note the three records that were in the STG CRM Category staging table have been loaded into the base object. The Consolidation_Ind column for each record is set to 4. This means that this is a newly added record.

Skills Review:

Load from Staging Tables in the Correct Order

1. Load data in the respective base objects using the following Load jobs:

Load from STG CRM Sub Category – 12 inserts; Load from STG CRM Customer – 45 inserts; 1 reject Load from STG CRM Customer Note – 9 inserts Load from STG CRM Address – 45 inserts Load from STG Sales Customer – 84 inserts Load from STG Sales Bill To Addr – 84 inserts Load from STG Sales Ship To Addr – 21 inserts; 5 no action

Note: The Address_Address_Type base object is not populated here because the Data Architect decided to populate it at a later time.

2. Check the status of each job after it finishes running.

3. Review the trn_lab schema diagram from the Schema Viewer if needed.

4. If there are rejected records, observe the reasons for rejection.

5. If the reason is as a result of validation rules then they are legitimate. However if they are a result of you not loading in the correct order, correct the action and try again.

6. If you need to re-load data for any reason:

a. Disable Delta Detection (if it is set).

b. Re-run the Stage job for the staging table.

c. Re-run the related Load job with the Force Update option.

d. Re-enable Delta Detection for the staging table (if needed).


Summary You have reached the end of Module 4 > Lesson 1 > Lab 2. In this lab, you ran

the various Load batch jobs.


Module 5 Lesson 1 Lab 1: Setting Match Strategy, Match Columns, and Match Path

Guidelines

Scenario:

Setting Match/Search Strategy and creating Match Columns for Two Different Base Objects.

Objectives:

Set the Match/Search Strategy for a Base Object (Exact for the Sub Category base object)

Create Match Columns to be used later in Match Rules (1 Exact for Sub Category; 1 Fuzzy, 1 Fuzzy Match Key, and 1 Exact match column for the Customer)

Define a Match Path to allow the match engine to use data from the Address base object when matching Customers

Duration:

25 minutes

Review

Match Strategy - Specifies the reliability of the match versus the performance you require: fuzzy or exact. An exact match / search strategy is faster, but an exact match will miss some matches if the data is imperfect.

Match Path - Allows you to traverse the hierarchy between records—whether that hierarchy exists between base objects (inter-table paths) or within a single base object (intra-table paths). Match paths are used for configuring match column rules involving related records in either separate tables or in the same table.

Match Columns - A column that is used in a match rule for comparison purposes. Each match column is based on one or more columns from the base object.


Walkthrough:

Define an Exact Match Column for a Base Object

The Sub Category base object will use an Exact Match/Search Strategy to match sub categories that have the same values in Sub Catg Name.

1. Open the Schema tool, and make sure you have acquired the Write Lock

2. Expand the Sub_Category base object, and click on its Match/Merge Setup node

3. Click the Properties tab.

4. Select Exact as the Match/Search Strategy.

Walkthrough:

Define an Exact Match Column for a Base Object

Exact Match Columns may be used when the Match/Search Strategy for the base object is set to Exact or Fuzzy. In this case, the Sub Category base object uses Exact as the strategy. However, it is not possible to use a Fuzzy Match Column with an Exact Match/Search Strategy.

1. Click the Match Columns tab.

2. Click the Add Exact Match Column button.


The Add Exact Match Column dialog opens.

3. Leave the Match Path Component as Root (Sub_Category). This is because sub-categories will only be matched using data from the Sub_Category table; i.e. we don’t want the match to use data from any related child tables.

4. Enter the value “Sub Category Name” in the Field Name box to provide a label for this field when you use it in match rules.

5. From the list of available columns, select Sub Catg Name and click the Select

Column button to move it to the selected columns list.

6. Click OK.


8. The exact match column has been added to the list of match columns.


Walkthough:

Define a Fuzzy Match Column for a Different Base Object

The Customer base object on the other hand uses Fuzzy as the Match/Search Strategy.

This means that the base object could have both Fuzzy as well as Exact Math Columns. In this walkthrough you will define a Fuzzy Match Column for the Customer base object.


1. In the Match Columns tab for the Customer base object, click the Add Fuzzy

Match Column button.

2. The Add Fuzzy Match Column dialog opens.

3. Leave the Match Path Component as Root (Customer) because the data for this match column will come from the Full Name column of the Customer base object.

4. Select Person_Name from the Field Name list.

5. Move Full Name from the Available Columns list to the Selected Columns list


6. Click OK.

Walkthough:

Define an Exact Match Column for the Same Base Object

Even though Fuzzy has been selected as the overall Match/Search Strategy for the Customer base object, you can still include exact matches on specific columns.

1. In the Match Columns tab for the Customer base object, click the Add Exact

Match Column button.

2. The Add Exact Match Column dialog opens.

3. Make sure the Match Path Component is set to Root (Customer).

4. Enter the value “Customer Class” in the Field Name box.


For exact match columns, there isn’t a predefined list of match columns, so you have to provide a name for the match column yourself.

5. Move Customer Class from the Available Columns list to the Selected Columns list.

6. Click OK. You now have two Match Columns defined, one Fuzzy and the other Exact, for the Customer base object which uses Fuzzy as the Match/Search Strategy.


7. Click the Save button. You will be warned that a Fuzzy Match Key column has not been defined.

8. Click OK to continue.

Walkthrough:

Define the Match Key for the Base Object

A Fuzzy Match Key column is required when you use Fuzzy as a Match/Search Strategy. It is the primary field used during searching and matching to generate match candidates for this base object. Base objects have one and only one Fuzzy Match Key. The names of the Fuzzy Match Key columns are pre-determined by the Population (discussed later).

Population: The primary goal of a population is performance of the fuzzy match process in varied populations. This will be discussed in further detail in Fuzzy Matching lesson of this module. For now, just recognize that a population is required when the Match/Search strategy is set to Fuzzy.

1. Go to the Match Columns tab.

2. In the Fuzzy Match Key section, choose Organization_Name as the Key Type.

Organization_Name is added to the list of match columns – its column type is Fuzzy Match Key.

Note: The data in your Customer base object includes both individuals and organizations. Organization_Name key type is a superset of the Person_Name key type, so by choosing Organization_Name as the key type you are ensuring that the key can handle both organizations and individuals.

3. Leave the Key Width as Standard (discussed later). Key Width: Key Width determines the degree of variance that will be supported in the Fuzzy Match Key column values. This will be discussed in further detail in Fuzzy Matching lesson of this module. For now, just recognize that a Key Width must be set for the Fuzzy Match Key column.

4. Make sure the Path Component is set to Root (CUSTOMER).


This determines which base object columns are available to be used as the Match Key.

You need to tell the match engine which base object columns contain the data to be used as the match key. For this exercise, the Customer’s Full Name column will provide the data for generating the match keys.

5. In the Match Column Contents section at the bottom of the Match Columns tab, select Full Name from the Available Columns list.

6. Click the Select Column button to move Full Name to the Selected Columns list.


7. Click the Save button. You will be warned that no rule sets have been created yet – click OK to continue saving your settings.

Walkthrough:

Define a Match Path

The Customer base object on its own does not really contain enough data to identify realistic matches – if you try to identify matches using only person/organization names, you will overmatch i.e. you will end up treating records for different and distinct customers as all belonging to one customer. To improve the match quality, you need to provide the match engine with as much information about the customer as possible. To do so, in this exercise, we will be including data from the Address base object by defining a match path.

1. Click on the Paths tab.

2. Click on a row in the Path Components section and then click the Add button.

The Add Path Component dialog appears.


a. Enter “Customer Address” as the Display Name. The system will provide a default physical name.

b. Make sure the Check for Missing Children checkbox is checked.

Note: If this option is switched on, then an outer join will be done between Customer and Address, so that any Customers that do not have addresses can still be included in the Match job. Without this option, an inner join occurs, and any Customers without Addresses will be left out of the data sent to the match engine.

c. Select Address as the child table, from the list of tables shown in the Constraints section.

d. Click OK.


Customer-Address now shows as a match path on the Paths tab.

3. Based on the data for this training exercise, there is no need to add any filters for this match path.


Again, you will be warned that no rule sets have been created yet

5. Click OK to continue saving your settings.

In the walkthrough for this lab, you:

Selected Exact as the match/search strategy for the Sub Category base object Kept Fuzzy as the match/search strategy for the Customer base object Defined 1 Exact match column for the Sub Category base object Defined 1 Exact match column for the Customer base object Defined 1 Fuzzy match column for the Customer base object Defined 1 Fuzzy Match Key for the Customer base object Defined a Match Path to allow the match engine to use data from the Address

base object when matching Customers


In the next section of this lab, which continues on the next page, use what you’ve learned in the walkthrough to complete the skills review exercises.

Skills Review:

Define Match Columns for the Customer Base Object

In this exercise you will define more match columns for the Customer base object.

1. Add a fuzzy match column to the Customer base object. Select Address_Part1 as the Field Name. The data for the match column must be provided by the Address Line column of the Address base object. Hint: Remember how you created the Match Path from Customer to Address.

2. Add another fuzzy match column to the Customer base object. Address_Part2 as the Field Name. The data for the match column must be provided by the City, State and Zip_10 columns of the Address base object.

3. Add the following Exact match column to Customer’s match columns list: Match Path Component = Root (Customer) Field Name = Generation Selected Columns = Name Generation

4. Add the following Exact match column to Customer’s match columns list:

Match Path Component = Customer Address Field Name = State Code Selected Columns = State

5. Save your settings.

Once you have completed this exercise, the match columns should look like this:


Summary

You have reached the end of Module 5 > Lesson 1 > Lab 1. In this lab you set the appropriate Match/Search Strategy for base objects, created match columns to be used later in match rules, and set the match path between base objects.


Module 5 Lesson 2 Lab 1: Configure an Exact Match Rules Set

Guidelines

Scenario:

You will be defining a match rule using an exact match column and an exact match base object.

In this lab

Use an Exact match column in a match rule for the Sub_Category base object.

Objectives:

Given the Schema tool, define match rules using exact match columns with 100% accuracy.

Duration:

10 minutes


Walkthrough:

Define a Match Rule for a Base Object with an Exact Match Column

In this exercise you will use the Exact match column you created in the previous lab (Sub_Catgeory_Name) in a match rule for the Sub_Category base object:

In this rule, records will match and be flagged for automerge when they have the same values for Sub Catg Name.

Automerge: The process of merging records automatically. Match rules can result in automatic merging or manual merging. A match rule that instructs Informatica MDM Hub to perform an automerge will combine two or more records of a base object table automatically, without manual intervention.

1. Expand the Sub Category base object.

2. Select Match/Merge Setup.

3. Click the Match Rule Sets tab.

4. Click the Add button to name a new match rule set.

5. In the Add Match Rule Set dialog, enter Main Rule Set as the rule set name.

6. Click OK.

7. Click the Add button to the right of the Match Rules list to add a new match rule to the match rule set.

The Edit Match Rule dialog opens. This is where you will specify which columns to use in the match rule, and can also specify properties for the match rule.


8. Click the Edit button and select the Sub_Category_Name match column in the Add/Remove Match Columns dialog. (This is the match column you defined in the previous section of this walkthrough.)

9. Click OK.

The Sub_Category_Name column has been added to the match columns for the match rule.


For this match rule, you won’t be using any of the optional match properties such as Match NULLs or Non-Equal Matching.

10. Click OK.

The match rule has been added to the list of match rules. By default, it is added as a manual merge rule.


11. Select the match rule and click the Auto button to change the match rule from a manual merge rule to an automerge rule.


The match rule changes color to blue indicating that it is an Automerge match rule.


Used the match column in a match rule for the Sub_Category base object

Summary You have reached the end of Module 5 > Lesson 2 > Lab 1. In this lab, you configured an Exact Match Rule Set with automerge.


Module 5 Lesson 3 Lab 1: Configure a Range Search

Guidelines

Scenario:

Configuring a range search.

In this lab

Select the Match/Search Strategy for a base object

Select the Match Population for a base object

Create a Match Rule Set

Configure a Range Search for the Match Rule Set

Objectives:

Given the Schema tool, configure a range search that identifies candidate set of records based on similar tokens for the match key with 100% accuracy.

Duration:

5 minutes


Walkthrough:

Select the Match/Search Strategy and the Match Population for an Object

1. Open the Schema tool, and verify that you have acquired the Write Lock.

2. Expand the Customer base object, and browse to its’ Match/Merge Setup node.

3. On the Properties tab.

Note that Fuzzy is already set as the Match/Search Strategy.

4. Select US as the Population if not already set.

Walkthough:

Create a Match Rule Set

1. Go to the Match Rule Sets tab for the Customer base object, and click the

Add button to name a new match rule set.

2. The Add Match Rule Set dialog opens.

3. Enter “Main Rule Set” as the rule set name

4. Click OK.


Walkthough:

Configure a Range Search

In this exercise, the Fuzzy Match will be performed on the Customer base object. In configuring a Range Search, your goal is identify a candidate set of records based on similar match keys. For this purpose, you need to configure two things:

A. A Fuzzy Match Key column for each Match Rule – this helps identify a candidate set of records. For the Match Key, you must also configure its properties, which includes

o Key Type o Key Width

In Module 5 Lesson 1 Lab 1, you have already defined a Fuzzy Match Key for the Customer base object and its Key Type, and Key Width. Therefore, there is no need to configure the match key.

This basically means the following:

Key Type = Organization_Name - The available values for the Key Type are determined by the Population. The value chosen here should be the main identifying data in the base object. Reminder: The data in your Customer base object includes both individuals and organizations. Organization_Name Key Type is a superset of the Person_Name key type, so by choosing Organization_Name as the Key Type you are ensuring that the key can handle both organizations and individuals.

Key Width = Standard - The Key Width determines the degree of variance that will be supported in the key values. A Standard Key Width setting aims for balance between Limited and Extended i.e., balance between disk usage/performance and search completeness.


B. The Search Level – this determines how many candidates are returned in the search phase of the match process, and to which candidate records the match column rules will be applied. Its goal is to find an optimal number of matches for your data. You will define the Search level in this walkthrough.

1. From the Match Rules Set tab, select the Main Rule Set if not already selected.

2. Select Typical from the Search Level drop-down menu.


4. Click OK when the warning message appears.


Selected the Match/Search Strategy for the Customer base object

Selected the Match Population as US for the Customer base object

Created a Match Rule Set to contain match rules for the Customer base object Configure a Range Search on the Customer base object to identify match

candidates using a Fuzzy Match Key


Summary

You have reached the end of Module 5 > Lesson 3 > Lab 1. In the next lab you will complete the configuration for match rule in this Match Rule Set and more match rules to the Match Rule Set.


Module 5 Lesson 3 Lab 2: Configure a Fuzzy Match Rule Set

Guidelines

Scenario:

Defining Fuzzy Match Rules.

In this lab

Configure Filtering (Filtering SQL) for a Match Rule Set

Add Columns to a Fuzzy Match Rule in the Match Rule Set

Configure Match Filtering with an Exact Match Column in the Fuzzy Match Rule

Configure the Match Purpose and Match Levels for a Fuzzy Match Rule

Objectives:

Given the Schema tool, define match rules using fuzzy match columns with 100% accuracy

Duration:

40 minutes


Walkthrough:

Configure Filtering (Filtering SQL) for a Match Rule Set

The Customer base object in this exercise contains data for Organizations, Individuals and Regions. The records for Regions do not have complete addresses and have very similar names, which would result in unnecessary overmatching between Region records. We are therefore going to specify an optional filter (Filtering SQL) in the Match Rule Set to remove Region records from the records to be matched. Note: The Filtering SQL option applies criteria to all Match Rules in a Match Rule Set.

1. Go to the Match Rule Sets tab for the Customer base object.

Schema > Customer > Match/Merge Setup > Match Rule Sets

2. Select the Main Rule Set.

3. Switch on the Enable Filtering checkbox

4. In the Filtering SQL box, enter the following:

customer_class <> 'R'

This will limit the batch of records for matching to those where customer_class is not 'R'.


Walkthrough:

Add Columns to a Fuzzy Match Rule in the Match Rule Set

In this walkthrough of the lab, you are creating a fuzzy match rule and adding columns to it. Since this is a fuzzy match rule, make sure that Match/Search Strategy is set to Fuzzy. Remember, in a fuzzy match rule, you can have fuzzy as well as exact match columns. The effect will be as follows:

First uses match keys to obtain candidates for matching

Then applies exact columns to filter out candidates that do not match those conditions

This match rule will apply to Organizations only, and will match them mainly on name and address.

1. Click the Add button to the right of the Match Rules list to add a new match rule to the match rule set.

2. The Edit Match Rule dialog opens.

3. Click the Edit button and select the following match columns in the Add/Remove Match Columns dialog:

Address_Part1 (Fuzzy match column) Address_Part2 (Fuzzy match column) Organization_Name (Fuzzy match column) Customer_Class (Exact match column)


4. Click OK to add those match columns to the match rule.

Walkthrough:

Configure Match Filtering with an Exact Match Column in the Fuzzy Match Rule

Remember, the exact match column added to this match rule is meant to filter out candidates that do not match conditions specified in the Match Properties. Thus, to ensure that this rule only applies to Organization records, you will set the segment match property for Customer_Class in this match rule. The segment match will restrict the match rule to records with Customer_Class = ‘O’ (i.e. Organization) but we will allow Organization records to match to any other type of record regardless of the customer class. The steps for performing this follow:

1. Select Customer_Class in the list of match columns.

2. Check the Segment Matching checkbox under Match Properties.

3. Check the Segment Matches All Data option – this will allow Organization records to be compared with any other type of record.

4. Click the Edit button to the right of the Segment Match Values edit box.

5. In the Edit Segment Values dialog, add the value O

6. Click OK.


Walkthrough:

Configure the Match Purpose and Match Level for the Fuzzy Match Rule

The Match Purpose, as an option, is available for selection depending on which match columns you’ve selected for the rule, which is the reason for that field being grayed out until you’ve selected the appropriate match columns. The Match Purpose determines

How match rules behave?

Which columns are required?

How much attention the MDM Hub pays to each of the match columns used in the match rule?

It contains knowledge about how best to compare two records to achieve the purpose of the match. The Match Level is used along with the Match Purpose. Three Match Levels determine how precise the match is:

Typical – Accepts reasonable matches

Conservative – Accepts close matches

Loose – Accepts matches with a higher degree of variation


1. Choose Organization as the Match Purpose

2. Choose Typical as the Match Level.


3. Click OK in the Edit Match Rule dialog to close it.

4. The new rule is added to the list of Match Rules for the selected Match Rule Set.

This fuzzy match rule is configured for a fuzzy matching using Address_Part1, Address_Part2, and Organization_Name (the fuzzy match key). It uses the fuzzy key column (Organization_Name) as a key to come up with a list of match candidates.

The match candidates are then filtered (organizations only) with the Customer_Class exact match column. The above match rule will result in the Customer match table being populated with records of organizations whose names and addresses have not changed (if name has changed the key changes and there will no comparison, and if address has changed it would not be in the match result).

5. Click the Save button to save the Match Rule Set. In the walkthrough for this lab, you:

Configured Filtering (Filtering SQL) for the Match Rule Set created in the previous lab

Created a Fuzzy Match Rule and added Columns both Fuzzy and Exact columns to the match rule in the Match Rule Set

Configured Match Filtering with an Exact Match Column in the Fuzzy Match Rule


Configure the Match Purpose and Match Levels for a Fuzzy Match Rule In the next section of this lab, use what you’ve learned in the walkthrough, as well as the previous lab, to complete the skills review exercises.

Skills Review:

Add Another Match Rule

1. Add another match rule (Match Rule # 2) to the Customer base object’s Main Rule Set match rule set. This match rule will apply to Persons only (customer_class = “P”), and will match them mainly on name and address:

a. Select the following columns for the match rule:

Address_Part1

Address_Part2

Person_Name

Customer_Class

Generation

b. Select Resident as the Match Purpose and Typical as the Match Level.

c. Switch on Segment Match for Customer_Class and enter P as the segment match value.

d. Select the NULL Matches NULL option for the Generation column.

2. Add another match rule (Match Rule # 3) to the Customer base object’s Main Rule Set match rule set. This match rule will apply to Persons only (customer_class = “P”), and will match them mainly on name and state.

a. Select the following columns for the match rule:

Person_Name

Customer_Class

Name_Generation

State_Code.

b. Select Person_Name as the Match Purpose and Typical as the Match Level. Scroll down the list if necessary.


c. Switch on Segment Match for Customer_Class and enter P as the segment match value.

d. Switch on the NULL matches NULL option for the Generation column.

These new match rules can all be left as manual merge rules.

3. Save the Match Rule Set.

4. Add a match rule to the Address base object to match addresses if their Customer_ROWID values are identical, and their addresses are deemed similar when matched loosely.

Note: Since the data set is limited, this step does not reflect a typical scenario. The point of this skills review is to learn about manually matching (now), and merging later. Hints:

a. Set the Number of rows per match job batch cycle property to 1000 for the Address base object.

b. Select Address_Part1 as the Key Type. The base object column to use for this is Address Line 1. Set Key Width to Extended.

c. Create an exact match column on Customer_ROWID.

d. Add a fuzzy match column called Address_Part2. Use State as the base object column.

e. Add a match rule – the Match Purpose should be Address and the Match Level should be Loose. Select Address_Part1, Address_Part2 and Customer_ROWID as the match columns for the rule. Search Level should be Extreme.


5. Set the match rule to automerge (i.e., Auto = Yes)

6. Go to the Batch Viewer tool and select the Match for Address job under the Match node. Execute the job. We will view the results of this job in a later lab.

Summary You have reached the end of Module 5 > Lesson 3 > Lab 2.


Module 5 Lesson 4 Lab 1: Set Merge Options for Match Rules

Guidelines

Scenario:

Set Merge Options for Match Rules

In this lab

Set merge options for match rules Run the Auto Match and Merge job a base object Run the Automerge job for a base object

Objectives:

Given a match rule, configure the rule for automatic match and merge with 100% accuracy.

Given a configured match rule, run an automatic match and merge job with 100% accuracy.

Given a configured match rule and matched records, run an automatic merge job with 100% accuracy.

Duration:

45 minutes


Walkthrough:

Configure Automerge for Match Rules

In the previous lab, you configured the various match rules. Most match rules were set with the default option i.e., Auto = “No”, which means they are set to merge manually.

In this walkthrough, you will revisit those match rules and set some of them to automerge.

1. Go to the Schema tool.

Model > Schema

2. Acquire a Write Lock.

3. Expand the Customer base object and select Match/Merge Setup.

4. Click the Match Rule Sets tab.

5. Select the Main Rule Set.

6. Select the Fuzzy match rule with the Organization purpose level.

7. Click the Auto button to set the match rule to merge automatically.

8. Save the Match Rule Set.


Walkthrough:

Run the Auto Match and Merge Job

1. Go to the Batch Viewer tool and select the Match and Merge for Customer job under the Auto Match and Merge node.

2. Execute the job.

3. Observe the match table for the Customer base object using SQL Developer (the C_CUSTOMER_MTCH table).


Depending on the number of matched records Queued for manual merge from the Auto Match and Merge job, you should see the same number of rows in the match table.

4. In Batch Viewer, scroll down to the Match for Customer node under the Match node.

There are several jobs listed. These are the jobs that ran automatically on the Customer base object to match records until no more matched records occurred.


5. Select and observe the results of a few of the Match jobs for the Customer base object.

Walkthrough:

Run the Automerge Job

In the previous lab, you ran the Match job on the Address table which, in this case, resulted in a single match.

1. Observe the resulting matches in the Address Match Table (C_ADDRESS_MTCH) using SQL Developer.

Notice the AUTOMERGE_IND value set to 1, which means that the record will be automatically merged when the Automerge job runs.


2. From the Batch Viewer tool and select the Merge data in Address job under the Automerge node.

3. Execute the job.

The record, in this case, has been automerged.

4. Observe the C_ADDRESS_MTCH table using SQL Developer. The record is no longer in the table. That is because records with the AUTOMERGE_IND set to 1 are removed from the table once they are merged.


Configured a match rule in the Customer base object to automerge.

Ran the Customer Auto Match and Merge job

Ran the Address Automerge job



Module 6 Lesson 1 Lab 1: Queries and Packages

Guidelines

Scenario:

Creating Queries and Packages.

In this lab

Create a simple query

Use that query to create a PUT-enabled package to support data edits and merges

Create a more complex query

Objectives:

Given a query and the Packages tool, create a PUT-enabled package to support data edits and merges with 100% accuracy.

Duration:

30 minutes


Walkthrough:

Create a Simple Query

1. Select the Queries tool from the Model workbench, and verify that you still have a Write Lock.

2. Right click in the Queries pane (left hand side of the Queries tool), and click New Query Group.

3. In the Add Query Group dialog, enter Basic Queries as the name for the query group. Optionally, enter a description for the query group.

4. Click OK.

5. Right click on the Basic Queries group and choose New Query.

6. Click the Next button at the New Query wizard.

7. Enter Customer Attributes Only as the query name.

8. Choose Basic Queries as the query group.

9. Select Customer as the primary table.

10. Click Next.

11. Unselect the following columns:

Creator, Create Date, Updated By, Last Update Date, Deleted Ind, Deleted By, Deleted Date, Last Rowid System, Dirty Indicator, Content Metadata dirty Ind, and Interaction Id.

12. Leave all other columns checked.

13. Click Finish.


Walkthrough:

Create a PUT-enabled Package to Support Data Edits and Merges

1. Select the Packages tool from the Model workbench.

2. Right click in the Packages pane (left hand side of the Packages tool), and select New Package.

3. Click Next from the wizard.

4. Enter Customer UPDATE as the display name for the package. The New Package Wizard automatically suggests a name for the physical database view that will be created. Leave that unchanged.

5. Switch on the Enable PUT option to enable inserting or updating of records in the base object table.

Note: PUT-enabled packages cannot include joins to other tables, be based on system tables or other packages, or be based on queries that have constant columns, aggregate functions, or group by settings.


Ignore the Secure Resource flag – security management is out of scope for this course.

6. Click Next.

7. Expand the Basic Query query group that you created previously and select the Customer Attributes Only query as the query for the new package.

Note that you could also create a new query directly from the New Package Wizard.

8. Click Finish.

Walkthrough:

Create a More Complex Query

1. Return to the Queries tool and right click on the Basic Queries group and choose New Query.

2. Click Next.

3. Enter Customer Address as the query name.


4. Choose Basic Queries as the Query Group.

5. Select the Customer UPDATE package as the Primary Table.

6. Click Next.

7. Select all columns from the column list.

8. Click Finish.

9. In the Tables tab, click on the Add Table button (“+” sign) and add the Address table to the query

10. The Address table will now be shown on the Tables tab.

11. Manually join the Address table’s Customer_ROWID column to the Rowid Object column of the Customer UPDATE package.


12. To make sure that the query returns all Customer records, even ones that do not have an Address record, click in the Join Type column for C_ADDRESS and select LEFT OUTER as the join type.

13. Click the Select tab and click the Add Table Column button (+ button) to add more columns to the query.

14. In the Add Table Column dialog, expand Address and select the following columns: Address Line 1, City, State, Zip 10, Valid Ind.

15. Click OK.

16. Edit the Alias values for the Address columns and make them more readable.


17. Go back to the Tables tab, and click the + button to add an additional table.

18. Select the Sub Category table to add to the query.

19. Join the Sub Category ROWID from the Customer UPDATE package to the Rowid Object column on the Sub Category table.

20. Like the Address table, set the Join Type value for the C_SUB_CATEGORY to LEFT OUTER.

21. On the Select tab, click the + button to add columns to the query.

22. From the Sub Category table, select Sub Catg Name and Sub Catg Desc.

23. Edit the Alias values for the Sub_Category columns and make them more readable.


24. Go to the Sort tab. Click the + button to add a sort to the query results.

25. Select Full Name from Customer UPDATE as the table column to sort on.

26. Save the query.

27. Click the View node under Customer Address in the Queries tree view. This allows you to review the result of the query.


Created a simple query

Used that query to create a PUT-enabled package to support data edits and merges

Created a more complex query In the next section of this lab, use what you’ve learned in the walkthrough to complete the skills review exercises.


Skills Review:

1. Create a package called Customer Address READ. This package is based on the Customer Address query you created in the previous walkthrough. This package is not PUT-enabled.

2. Create a query called Customers with Notes. The primary table for the query is Customer UPDATE. Add Customer Note base object to the query and manually create the join between Customer Notes and Customer UPDATE as Customer_ROWID to ROWID_OBJECT.

Leave the join as an INNER join, as we only want to show customers with entries in the Customer Notes table.

Have the query show the Full Name column and Customer Class column from Customer UPDATE as well as the Note Text column from Customer Notes.

Use the View option to review the data returned by the query. If the view does not show you the columns you expect, then click Queries … Refresh form the main menu.

3. Create a package that uses the previous query – name the package Customers with Notes READ.

4. Create a new custom query called View Customer Matches. The SQL for this query is:

SELECT a.rowid_object, a.full_name,

b.rowid_object rowid_object_matched, b.full_name full_name_matched FROM C_CUSTOMER a, C_CUSTOMER b, C_CUSTOMER_MTCH c WHERE a.rowid_object = c.rowid_object AND b.rowid_object = c.rowid_object_matched AND a.rowid_object <> b.rowid_object ORDER BY a.rowid_object, b.rowid_object


5. Use the View option to review the results of the query.

6. Create a package called Customer Matches READ that uses the previous query.

Summary In this lab, you created four packages all based on four queries that you built. One of the packages you created was a PUT-Enabled package. You have reached the end of Module 6 > Lesson 1 > Lab 1.


Module 7 Lesson 1 Lab 1: Configure Batch Groups

Guidelines

Scenario:

Configuring Batch Groups.

In this lab

Create a batch group

Add levels to a batch group

Add jobs to a level

Objectives:

Configure Batch Jobs to execute the stage, load, match and merge processes from within Stored Procedures

Duration:

15 minutes


Walkthrough:

Create a Batch Group and add Levels and Jobs to the Batch Group

1. Select the Batch Groups tool from the Utilities workbench, and verify that you still have a Write Lock.

2. Right click on in the Batch Groups list and click Add Batch Group.

3. Name the new batch group “Stage and Load flow for CRM system”.

4. Right-click on the Start button and choose Add level below.

5. The Choose jobs to add to Batch Group dialog appears.

6. Select the Stage jobs for the CRM system for the following base objects: Address, Category, Customer, Customer Note, Sub Category. Click OK. The selected stage jobs have all been added to the same level in the batch group. This means that they will execute in parallel.


7. Right click on the level you’ve just added. Select Add level below.

8. Select the load job that loads the Category base object from the CRM system.

The load job you’ve just added is shown in its’ own level. That means that it will execute once all the stage jobs from the previous level have completed.



Created a batch group Added levels to a batch group Added jobs to a level In the next section of this lab, use what you’ve learned in the walkthrough to complete the skills review exercises.


Skills Review:

1. Complete the batch group so that it will execute the Load jobs for the Address, Customer, Customer Note and Sub Category base objects. Take into account the dependencies between these objects when choosing the order in which to execute the Load jobs.

Note: You can use the Schema Viewer tool from the Model workbench if you would like to have a look at the data model in your schema.

2. Create a new batch group called Stage and Load flow for Sales system that will execute the Load and Stage jobs for the Sales system. The end batch group should result in the following:

Important: Don’t run the batch groups. You have already staged and loaded the data. Doing so again may lead you to NO DATA being staged nor loaded (if delta detection was set. If needed, you may need to run these batch groups to re-stage and load data).


Summary You have reached the end of Module 7 > Lesson 1 > Lab 1. In this lab, you created two batch groups for executing STAGE and LOAD jobs from the Sales and CRM systems


Module 8 Lesson 1 Lab 1: Merge Records Using Merge Manager

Guidelines

Scenario:

In this lab you will utilize the Merge Manager data management tool in the Informatica Hub to manually search, edit, flag, and merge records queued for manual merging in the base object.

You will complete the following tasks:

Assign records to user assignment list

Flag records as unique

Merge records and apply a trust override

Manually search for matches

Flag records for automerge

Determine which match rule caused a match

Objectives:

Manually edit and merge records using Merge Manager with 100% accuracy.

Duration:

40 minutes


Walkthrough:

Assign Records to User Assignment List

1. Select the Merge Manager tool in the Data Steward workbench.

2. In the Merge Manager setup screen select Customer as the base object.

3. Click Get Count to review the number of records ready to merge.

4. Select Customer UPDATE as the merge package (aka PUT-enable package) that will be used to merge and/or update the records.

Review: PUT-enabled packages can be used to update data when using Merge Manager (or Data Manager) in the base object.

5. Select Customer Address READ as the display package that will be used to display the records.

6. Click on Clear Assigned Records if the number showing for Currently Assigned is not 0.

7. Change the Number of records to add to assignment list value and Page Size to 200.

8. Select <Use Search Wizard> from the Query drop down list.

9. Click Begin Merge….


Note: Using the Search Wizard, you can define the assignment based on any search criteria using the columns available to you in the previously selected display package. You can also leave Query as None and click Begin Merge in which case Merge Manager would simply assign the first 50 queued records to you. Alternately, you can also choose to use a pre-defined query from the list displayed in the Query drop down list, if such queries have been defined in your schema. Be careful to understand what the filter criteria are for that query so you do not specify an additional criterion which may produce a null set, returning no values.

The Search Wizard displays.

10. Click Next.

11. Use the + Add Parameter button to add a new parameter

12. Set up the parameter value to read Customer Class is exactly P.

This will restrict the records added to your assignment list to Persons only i.e. no records for Organizations.

Note: If you add multiple parameters you can use ‘AND’ or ‘OR’ conjunctions in Search Wizard queries, but do not mix them in the same query - stick to all ‘AND’ or all ‘OR” because the Search Wizard does not give you a way to specify precedence of the conditions.


13. Click Finish and the Merge Manager screen displays.

Walkthrough:

Flag Record as Unique

1. In the Unmerged tab at the top of the Merge Manager screen, select the record for ADAM ZAPPLE. Notice that no matches were found for this record. We will therefore mark it as unique to take it out of the merge queue.

2. Click the Accept the unmerged record as unique button. Notice that ADAM ZAPPLE has been removed from the Unmerged list.


Walkthrough:

Merge Records, with a Trust Override

1. In the Unmerged list, find the record for B.DWYER.

Notice that 6 matches were found for this record.

2. Select one of the matches with the name BARB DWYER from the Matched data section.

The bold text in the Cell Data section indicates which values will survive.


3. We want to make sure that the surviving Full Name is BARB DWYER. Click on BARB DWYER in the Matched Cell section. That will cause the bold emphasis to move to BARB DWYER.

To make sure that the newly selected surviving value survives for a long time, we’ll define new cell-level trust for it. Note that the ROWID_OBJECT values in the Unmerged and Matched Cell. In this case they are 10 and 14.

4. Click the button next to the Full Name in the Matched Cell section.

5. The Override Trust Settings dialog opens.


6. Choose High Confidence (if not already selected) and click Finish.

Notice the Trust value for the cell is changes to a higher value.

7. Click the button to merge the 2 records.

8. Click Yes to perform the merge.

9. Click OK. All the values that were bold now are part of the surviving record with ROWID_OBJECT. Also notice that now there are two records with ROWID_OBJECT of 14.


Note: The ROWID_OBJECT values may vary on your system.

10. Merge all the matched records for BARB DWYER in the Unmerged section, each time ensuring that the surviving record (bolded) that has the following values:

Full Name = BARB DWYER

First Name = BARB

Middle Name = <blank>

Last Name = DWYER

At the end of all the merges, the consolidated record should have BARB DWYER in the Full Name column, BARB in the First Name column and DWYER in the Last Name column. How many BARB DWYER records show in the Unmerged list at the top of Merge Manager? Can you explain why?

NOTE: If you end up with the wrong surviving values in any of

the fields, click the Edit button to open the Record Editor.


11. When there are no more matches for BARB DWYER, click the

button to flag the merged record as consolidated.

Walkthrough:

Manually Search for Matches

Occasionally, a data steward may find two (2) records that should merge together, but that the match rules haven’t identified as matches. If there are a large number of records of that nature, then the match rules should be tuned to pick up more matches. But if there are just a few records of that nature, then the data steward can manually match them.

1. In the Unmerged list, find the record for ANGIE O’GRAM (be particular about the spelling because there are a few similar records).

Even though there are four (4) potential matches, only one (1) appears in the Matched data section.


2. Click the Search for potential matches button.

3. Click Next.

4. In the Search Wizard, specify the following search criteria:

Fullname begins with ANG

5. Four (4) Records for are added to the Matched Data section.

Note that the selected Unmerged record (ANGIE O’GRAM) is also shown in the Matched data section (look for the record with the same ROWID_OBJECT value as the record selected in the Unmerged section). You can ignore this matched data record.


6. Merge ANGIE O’GRAM and ANGELA O GRAM, making sure that the values from ANGIE O’GRAM wins.

7. Select ANGIE O’GRAM in the Unmerged section.

Note that it now has a matched record – this is because the consolidated record has inherited the match from the merged ANGELA O GRAM record.

8. Now merge ANGIE O’GRAM and the matched record (ANGIE O GRAM), again first making sure that ANGIE O’GRAM is the winning spelling for the full name.

9. Select ANGIE O’GRAM in the Unmerged section again. Manually search for a match with ANGELA O’GRAMME and merge those 2 records. The full name of the surviving record should be ANGIE O’GRAM.

10. Select ANGIE O’GRAM in the Unmerged section again. Manually search for a match with ANGELA O’GRAMME and merge those 2 records. The surviving Full Name record should be ANGIE O’GRAM.

Do not set the unmerged records as unique (consolidated) just yet.

Walkthrough:

View Cross-references

1. In the Unmerged section, find click on the merged ANGIE O’GRAM record.

2. Click the View Cross-Reference Records button. The Cross-Reference Viewer opens.


3. Review the cross-reference records that have contributed to the consolidated base object as a result of the merges you have just completed.

4. Click Close.

5. Click the button to flag the merged ANGIE O’GRAM record as consolidated.

Walkthrough:

Flag Records for Automerge

It is not necessary for a data steward to wait for records to be merged in real-time. It is possible to flag matched records for automerge, and let the system merge those records the next time the automerge batch job runs.

1. In the Unmerged section, find the record for EILEEN DOVER-ANFELL.

There are 3 matched records: 2 named EILEEN DOVER and 1 named E. DOVER.

2. Select the matched record E. DOVER. Click the Flag for

Automerge button.

3. Find one of the records called EILEEN DOVER in the Unmerged section. In the Matched Data section, select the record for

EILEEN DOVER-ANFELL, and click the button again.


4. Find the E. DOVER record (or any other remaining variations on EILEEN DOVER’s name), and flag it for automerge with the EILEEN DOVER-ANFELL record.

Walkthrough:

Flag all Records without a Match as Unique

1. Click on records in the Unmerged tab at the top of the Merge Manager screen, and notice that a number of records don’t have any matched records – e.g. AARON C. SERCH, ADAM, ZAPPLE, AL BEBACK, BARNABY WILDE, BERTHA VENATION, STAN BACK, RUSSEL SPROUT, TAMARA KNIGHT.

2. Click the Accept all records without a match button. You will be prompted to confirm the action – click OK.

3. Once the process is complete, you will notice that the records without a match are no longer shown in the Unmerged section. This is because their Consolidation_Ind values have been changed to 1.

Walkthrough:

Determine which Match Rule Caused a Match

1. In the Unmerged section, find the record for ANITA CURTIN. It has matched to 2 similar records, but records where the first

names are not ANITA. Use the Show Match Rule button to see which match rules resulted in these matches.



Assigned records to user assignment list Flagged records as unique Merged records and applied a trust override Manually searched for matches Flagged records for automerge Determined which match rule caused a match In the next section of this lab, use what you’ve learned in the walkthrough to complete the skills review exercises.

Answers

How many BARB DWYER records show in the Unmerged list at the top of Merge Manager? Can you explain why?

The consolidated Barb Dwyer parent record has multiple address records. If you merge the duplicate children records as well, you would see 1 record for Barb Dwyer with just 1 address.


Skills Review:

Exercise

1. Merge Hammond Ecks and H. Ex, making sure that Hammond Ecks is the surviving full name.

2. Merge Joseph King and Joe King, making sure that Joe King is the surviving full name.

3. Merge all the matches for Justin Case.

4. Merge all the matches for Tim Burr, making sure the surviving full name is Tim Burr.



Module 8 Lesson 1 Lab 2: Unmerge Records using Data Manager

Guidelines

Scenario:

Unmerge Records using Data Manager

In this lab

Select records to view in Data Manager

View cross-references, history and BVT contributors

Promote a cell value

Create a new Customer record

Change the consolidation flag for a record

Unmerge a consolidated record using standard unmerge

Unmerge a consolidated record using tree unmerge

Objectives:

Perform a standard and tree unmerge using Data Manager with 100% accuracy

Duration:

25 minutes


Walkthrough:

Select Records to View in Data Manager

1. Select the Data Manager tool in the Data Steward workbench.

2. Select the Customer base object as the base object you wish to review.

3. Select Customer UPDATE as the Put Package that you will use for any updates or cell overrides in the Data Manager.

4. Select “Customers with Notes READ” as the display package that you will use to view the data.

5. Click Begin Administration. The following error occurs because the query did not include a primary key (the ROWID_OBJECT).

6. Return to the Queries tool and add the ROWID_OBJECT (from Customer UPDATE) to the query in the Select tab.

7. Return to Data Manager and attempt steps 1-5 again.


8. The Search Wizard opens. If you do not specify any query parameters, then all records selected by the display package you chose will be returned.

For this exercise, we will not be specifying any query parameters, so you can simply click Finish.

Walkthrough:

View Cross-references, History and BVT Contributors

Note: BVT = “Best Version of the Truth” i.e. which cell value survived in the consolidated record

1. Sort the results in the top pane of the Data Manager screen by Full Name. Select one of the records for Barb Dwyer that shows Cross reference instances.

2. Use the various buttons and information on the screen to answer the following questions about this consolidated record:

a. How many source records have been merged into this consolidated record?

b. How many cross-references are from CRM system and how many are from the Sales system?

c. Which cross-reference record contributed the surviving Full Name to the consolidated record?

d. Open the Merge History Tree by clicking the button called Display

the complete Match history . Which 2 records merged together first? Note: Your merge tree won’t look exactly the same as the one shown below – it depends on the order in which you merged these records in the previous lab.


Walkthrough:

Promote a Cell Value

1. Still working with the consolidated record for BARB DWYER, select a cross reference record that has BARBARA in the First Name column.

2. In the Cell Data section at the bottom of the screen, click on the row for First Name.

3. Click the Increase Trust Score button to increase the trust score of the selected cross-reference record for the First Name. This promotes the selected cross-reference for the First Name.


4. The Override Trust Settings dialog opens. Select Custom and click Next.

5. Enter Maximum trust = 100, Minimum = 20, Units = Year, Decay = 3 and Type = Slow Initial, Rapid Later


6. Click Finish. The winning value for the First Name is now Barbara instead of Barb.

Walkthrough:

Create a New Customer Record

1. Click the Add Record button.

2. Enter the Customer data as shown in the following image:

3. Click OK.

4. Click OK.


Walkthrough:

Change the Consolidation Flag for a Record

1. Find the record for BARNABY WILDE.

2. Click the Reset button and choose Set as New.

This will change the consolidation indicator value back to 4.

Walkthrough:

Unmerge a Consolidated Record Using Standard Unmerge

1. Find the record for JUSTIN CASE.

2. View the merge history tree for that record. Three (3) source records have merged together – the tree should look similar to the following (it may differ slightly, depending on the order in which you merged records in the previous lab).


3. Note down which record is in the middle of the merge tree – in the example above CRM:25928668959 (highlighted in red text) is in the middle of the merge tree.

Whichever cross-reference is in the middle of your merge tree is the one you must unmerge now. We’ve chosen that one so that you can clearly see the difference between standard unmerge and tree unmerge.

4. Return to the Cross reference instances dialog and located the noted record.

5. Click the Unmerge button.

Notice that after the unmerge, the record still has 2 cross-references. Only the record that you had selected was unmerged; anything that was below it in the merge tree remains consolidated with the rest of the original (i.e. pre-unmerge) consolidated record.

Walkthrough:

Unmerge a Consolidated Record Using Tree Unmerge

1. Return to the record for Barb Dwyer.

2. View the merge history tree for that record.

3. Note down details of a record in the middle of the merge tree – something that had other records merged into it before it in turn was merged into the final consolidated record. In the example above CRM:35174034284 is in the middle of the merge tree, and had 3 other records merged into it before it in turn was merged with other records.


4. Choose a cross-reference from the middle of your merge tree – this is the one you must unmerge now. Select that cross-reference in the Data Manager

screen and click the Tree Unmerge button.

You will notice that a number of cross-references were removed from the consolidated Barb Dwyer record, instead of just one cross-reference as in the previous section of this lab.

5. Click the Reload button to refresh the display data.

Notice that there are now 2 different consolidated records for Barb Dwyer. Each has a few cross-references as a result of the tree unmerge.



Module 9 Lesson 2 Lab 1: Enabling the ORS Database Log File

Guidelines Objectives:

Enable the database using Enterprise Manager's ORS Database tab with 100% accuracy.

Duration:

10 minutes

Walkthrough:

Create an Oracle Virtual Directory for the ORS Database Log

The MDM Hub attempts to store the value of the Debug File Path (for the ORS) in the C_REPOS_DB_RELEASE table as entered. However, if the value is stored in lower case letters, that is for example, 'c:\infamdm\hub\server\logs', Oracle throws an error as it expects uppercase letters. To address this issue, a virtual directory must be created in Oracle, and the virtual directory name must be stored in the Debug File Path field in the MDM Hub.

1. Connect to Oracle using Sqlplus as the system user with sysdba privileges:

a. Start a Command prompt.

Start > Run …> cmd

b. Connect to Oracle as the system DBA user.

Sqlplus system/admin as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Sat Jul 14 19:07:58 2012 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

2. Create a virtual directory in Oracle for the ORS debug log directory.

SQL> create directory DEBUG_DIRECTORY1 as 'C:\infamdm\hub\server\logs';

3. Grant all privileges to the trn_lab user to write to the newly-created virtual directory.

SQL> grant all on directory DEBUG_DIRECTORY1 to trn_lab;


Walkthrough:

Enable the ORS Database Log

1. Go to the Enterprise Manager tool from the Workbenches pane.

Configuration > Enterprise Manager

2. Click the ORS Databases tab in the right-pane.

3. Select the trn_lab ORS.

4. Click the ORS Log Configuration sub-tab.

5. Acquire a Write Lock.

6. Change the Debug File Path to DEBUG_DIRECTORY1.

7. Change the Debug File Name to trn_lab.log.

8. Check the Debug Enabled checkbox.



For more information on log files and troubleshooting, you may take the Informatica MDM Hub Administration course.

Summary You have reached the end of Module 9 > Lesson 2 > Lab 1. In this lab, enabled the debug directory for the ORS database log.


Module 11 Lesson 1 Lab 1: Export an ORS to a Changelist

Guidelines

Scenario:

You may have used some of the change lists included with this course. Here they were used to catch you up to the current labs. In this lab you will learn how to capture a changelist.

Objectives:

Export an ORS to a changelist using Metadata Manager with 100% accuracy.

Duration:

10 minutes

Review

A changelist is a list of changes to make to a target ORS. A change is an operation in the change list—such as adding a base object or updating properties in a match rule—that is executed against the target repository. Change lists represent the list of differences between Hub repositories.

Walkthrough:

Validate the ORS

1. Go to the Enterprise Manager tool from the Workbenches pane.

Configuration > Metadata Manager

2. Click the Validate tab in the right-pane.

3. Select the trn_lab as the ORS to validate.


4. Click the Validate button.

5. Click OK to continue.

Warnings and Information are recommended to review but you may ignore them for this class.


If there are no errors, you are fine and move on to the next walkthrough.

Walkthrough:

Export a Changelist

1. Click the Export tab.

2. Select trn_lab as the ORS to export.

3. Click the Export button.

4. Specify an appropriate File name and Description for the changelist.

5. Click the Export button.


The changelist has been created for the trn_lab ORS.

Summary You have reached the end of Module 11 > Lesson 1 > Lab 1. In this lab, you exported the trn_lab ORS to a changelist.


Module 12 Lab 1: Workshop

Guidelines

Scenario:

The goal of this exercise is to complete a full implementation of Informatica MDM Multidomain Edition, using the concepts covered in modules 1 – 8 of this training course.

Read through the complete workshop description before starting to configure anything in the console.

Make sure you understand the rules you need to implement.

Query/investigate the “source data” for this workshop before you start configuring the rules to ensure that your rules resolve any quality issues in the data.

You can query the source data using SQL Developer or SQLPlus for Oracle. The “source system” tables are in your workshop schema and their names start with “Z_”. Alternately, you can view the printouts of the data content of those tables at the end of this document.

The schema you must use for this exercise is the one called trn_wkshop.

Duration:

6 hours 20 minutes


Walkthrough:

Source System Overviews

Customer data from 2 source systems – a Billing system and a CRM system – needs to be consolidated in a Customer Master. Billing System: The Billing system provides the following attributes:

Column Data Type Special NotesUPDATE_DT DATE

CUSTOMER_ID VARCHAR2(12)

LAST_NAME VARCHAR2(20)

FIRST_NAME VARCHAR2(20)

MIDDLE_NAME VARCHAR2(20)

SUFFIX VARCHAR2(5) Jr, Sr, etc. The data in this column will require some standardization.

SALUTATION VARCHAR2(5) Mr, Mrs, Dr, etc

LINE_1_ADDRESS VARCHAR2(40) Clean, quite reliable address information; used for billing purposes so business owners of the data have a vested interest in verifying these addresses. Note that the Billing system only keeps 1 address per Customer_ID.

LINE_2_ADDRESS VARCHAR2(40) Is not actually used for Address information. It tends to get used for notes such as ‘By Appointment only’, ‘DO NOT CONTACT’, etc. If this column says ‘DO NOT CONTACT’ or ‘NO CONTACT’, then map ‘9’ to CONTACT_IND column, else map ‘2’ to CONTACT_IND.

CITY VARCHAR2(40)

STATE VARCHAR2(2)

ADDRESS_TYPE VARCHAR2(10) Address Types in this field are Physical (sometimes stored as P, sometimes as 1, sometimes as PHYSICAL) or Mailing (sometimes stored as MAILING, sometimes stored as 2, sometimes as M) or Both (stored as B). These will need to be standardized to P, M or B. Not all addresses have been given address types – if no address type is present, the Address Type should be defaulted to “P”.

COUNTRY VARCHAR2(5)

ZIP VARCHAR2(5) 5-digit zip

ZIP4 VARCHAR2(4) 4-digit zip extension. If this is not null, then it should be concatenated to the ZIP value to form the final zip code in the base object. The format should be xxxxx-zzzz where xxxxx is the 5-digit zip and zzzz is the 4-digit extension.

EMAIL_ADDRESS VARCHAR2(40)

PHONE VARCHAR2(15)

MAIL_TO CHAR(1) A Y/N flag that indicates whether the Customer receives their bills by mail or by email. Y = snail mail; N = email.


Notes:

The Billing system only has 1 address per Customer ID.

If the MAIL_TO flag is “N”, then the billing address is no longer being maintained, but the email address would be well maintained. If the MAIL_TO flag is “Y”, then the billing address is being maintained, and the email address may or may not be maintained.

This means that you will need to downgrade the trust on the address if the MAIL_TO flag is “N”. If the MAIL_TO flag is “Y”, then you’ll need to downgrade the trust on the email address.

CRM System: The CRM system provides the following attributes: Column Data Type Notes LAST_UPDATE_DATE Date

CUSTOMER_ID VARCHAR2(15)

LAST_NAME VARCHAR2(15)


MIDDLE_INITIAL VARCHAR2(3) Initial only, not full middle name.

OPT_IN_IND CHAR(1)

‘A’ = ‘OK to send all mailings, including partners’ ‘B’ = ‘OK to send own mailings, not partners’ ‘C’ = ‘No mailings’ This column must be mapped to the CONTACT_IND column on customer. Transform ‘A’ to ‘2’, ‘B’ to ‘1’ and ‘C’ to ‘9’. Default to ‘2’ if no value is provided.

LINE_1_ADDRESS VARCHAR2(40)

CITY VARCHAR2(40)

STATE VARCHAR2(2)

ADDRESS_TYPE CHAR(1) Address types are P, M or null. A value of ‘P’ can be used instead of null values.

COUNTRY VARCHAR2(3)

ZIP VARCHAR2(10)


PHONE VARCHAR2(15)

Notes:

The CRM system may have one or more addresses per Customer ID.

If you find only one address per Customer ID, a select DISTINCT in the query is not needed, but having it causes no harm, in case such a situation occurs in the future. This means that there will be no matches in data from one source itself but there may be matches after merging data with the second source.


Walkthrough:

Overview of the Target Consolidated Schema

The target schema has 2 base objects: Customer and Address. Customer The Customer table has the following user-defined attributes:

Column Data Type Notes / Special processing LAST_NAME VARCHAR2(20)


MIDDLE_NAME VARCHAR2(20)

SUFFIX VARCHAR2(5) Values should be SR, JR, II, III etc. Add a cleanse list to standardize these, based on the values that are in the source data.

SALUTATION VARCHAR2(5) Mr, Mrs, Dr, etc

CONTACT_IND CHAR(1) ‘1’ = ‘OK to send non-partner marketing material’ ‘2’ = ‘OK to send partner marketing material’ ‘9’ = ‘No unsolicited contact’


EMAIL_DOWNGRADE_IND CHAR(1) If MAIL_TO from the Billing system is ‘Y’, it means that the email address is not used for billing. In that case, EMAIL_DOWNGRADE_IND should be ‘Y’. Otherwise EMAIL_DOWNGRADE_IND can be ‘N’.

PHONE VARCHAR2(15) Phone number should be formatted as follows: (nnn) nnn-nnnn

Address The Address table has the following user-defined attributes:

Note : PKEY_SRC_OBJECT for Address must be a concatenation of source customer key and address line 1 in the following format: Customer_id|Address_Line_1

Column Data Type Notes / Special processing

CUSTOMER_ROWID CHAR(14) Must be a foreign key referencing Customer.ROWID_OBJECT

ADDRESS_LINE VARCHAR2(40)

CITY VARCHAR2(40)

STATE VARCHAR2(2)

ZIP VARCHAR2(10)

ADDRESS_DOWNGRADE_IND CHAR(1)

If MAIL_TO from the Billing system is ‘N’, it means that the mail address is not used for billing. In that case, ADDRESS_DOWNGRADE_IND should be ‘Y’. Otherwise ADDRESS_DOWNGRADE_IND can be ‘N’.

ADDRESS_TYPE CHAR(1)

Address type must be standardized to P (Physical) or M (Mailing) or B (Both Physical and Mailing).


Walkthrough:

Steps

1. Define the data model

Create the base objects

Define the relationship between the base objects

Create the staging tables

Create 1 landing table that will contain the data from both the CRM and the Billing systems and that will be used to populate the Customer and Address base objects. Add a column to the table to differentiate CRM data from Billing data.

TIP 1: Your schema has 2 non-Informatica tables that can be treated as your “Source system”. They are called Z_BILLING and Z_CRM. These tables contain the source data for this exercise, and they can also be used for importing column definitions if you don’t feel like typing all the column definitions. But just remember to check that your data types and lengths are correct before you save column definitions. Also note that not all target columns are actually on the source – some of them are derived through cleanse functions/mappings. TIP 2: Configure as many properties as you can for the Staging tables when you create them, such as Lookup strategies. For the Address staging tables, remember to switch on NULL UPDATE for all address columns.

2. Configure the Stage process

Create cleanse lists and cleanse graphs and mappings to perform any data cleansing required to get from the source to the target. The data cleansing requirements can be derived from the source and target descriptions at the start of this workshop description. NOTE: Make sure that you only send CRM data to the CRM staging tables and Billing data to the Billing staging tables.


3. Configure the Load process

Create trust and validation rules as described below. The Admin system must always have the highest trust.

Customer

Column Comments LAST_NAME Billing is more reliable than CRM for this. Downgrade

trust if the last name is very short (< 3 characters) and not equal to ‘NG’).

FIRST_NAME Billing is more reliable than CRM for this.

MIDDLE_NAME Billing is more reliable than CRM for this. Downgrade trust by 80% if it contains the middle initial only. Downgrade trust by 100% if the middle name is null.

EMAIL_ADDRESS Billing is more reliable than CRM for this. If EMAIL_DOWNGRADE_IND is ‘Y’, then downgrade trust. If the email is null, then downgrade trust.

EMAIL_DOWNGRADE_IND Treat as part of a logical trust group with email_address

PHONE CRM is the trusted system for this. If it’s null, then use Billing phone number

CONTACT_IND Both systems are equally trusted. However, the content of this column determines final winner: ‘9’ (‘No unsolicited contact’) must always win over the others values, regardless of source ‘1’ (‘OK to send non-partner marketing material’) is the next most trusted value ‘2’ (‘OK to send partner marketing material’) is the least trusted value.

Address

Column Comments ADDRESS_LINE Logical trust group – all trust and downgrades should

be the same within each source system. Billing is the preferred source of address, but downgrade address columns by 30% if address_downgrade_ind = ‘Y’. Downgrade address columns by 100% but reserve minimum trust if zip code is null.

CITY

STATE

Zip

ADDRESS_DOWNGRADE_IND

ADDRESS_TYPE ‘B’ (Both) must always win over ‘M’ (Mailing). ‘M’ must always win over ‘P’ (Physical)

4. Configure the match and merge process

Set up all Customer match rules as Manual merge rules so that you can review the results of your rules before any automerging takes place.

For Customer, try different combinations of match and merge rules to come up with the best set of matches.

Use a match path to include Address columns in Customer matching.

Only automerge Address records if their customer_rowid values are identical and the addresses are highly similar. Don’t define any manual merge match rules for Address.


5. Configure data access

Create a single-source query and a PUT-enabled package for each base object

Create one package that joins together Customer and Address and shows all user-defined attributes from each – make sure this query can be used as a display package in Merge Manager.

6. Process data

Set up a batch group to stage and load your source data and also to run the match-merge.

You’ll have to do the “ETL” bit yourself to land the data – use TOAD or SQLPlus or SQLDeveloper to insert data from the Z_CRM and Z_BILLING tables into your landing table.

Once you’ve landed the data in the landing tables, run your batch group to run all the stage, load and automatch-and-merge jobs.

7. Review match results

Use the Merge Manager to review the match results, tune your match rules if necessary and review match results again.

8. Merge records.

Summary You have reached the end of Module 12 > Lab 1 . The rest of the pages in this lab show the content of the source data tables.

Configuring Inform

atica MD

M M

ultidomain Edition

222

So

urce D

ata: Z_C

RM

LAST_U

PDATE

_DATE

CUSTO

MER_ID

LAST_NAM

E FIRST_N

AME

MIDDLE_

INITIAL

LINE_1_AD

DRESS

CITY STATE

ADDRESS_

TYPE ZIP

EMAIL_AD

DRESS

PHONE

OPT_IN

_IND

8/4/2009

35174055793

QASEM

ALBER

T

QUEEN

S HOSPITA

L CEN

TER

JAMAICA

NY

P

11432

bert_q

99@hotm

ail.com

A

2/11/2010

53019129981

KASEM

ALBER

T

80 W

OODWARD ST

ROSLYN

HEIG

HTS

NY

P

11577

A

4/8/2009

35174355154

HER

NANDEZ

ALEJA

NDRO

90 ‐ 2

0 ELM

HURST A

VE

JACKSO

N HEIG

HTS

NY

P

11372

(210)577‐

8291

A

2/11/2010

43127578281

HER

NANDEZ

ALESA

NDRO

37 51 91ST STR

EET JACKSO

N HEIG

HTS

NY

P

11372

al_hern

andez@

msn.co

m

B

2/11/2010

35174005009

LEWIS

ALIC

E

2201 HEM

PSTEA

D TP

KE.

EAST M

EADOW

NY

P

11554

(210)

555/8540

A

2/11/2010

40228991023

LEWIS

ALIC

E

6919 SP

RINGFIELD

BLVD

OAKLAND GARDEN

S NY

P

11364

A

9/2/2009

35174255403

VYSO

TSKAYA

ALLA

327 BEA

CH 19 STR

EET FA

R ROCKAWAY

NY

P

11691

1/18/2010

39574355154

VYSO

TSKAYA

ALLA

8405 BAY P

ARKWAY

BROOKLYN

NY

P

11214

alla2009@gm

ail.com

(403)

555/2121

A

2/11/2010

40128664055

KING

ALLA

8405 BAY P

KWY **&

*! BROOKLYN

NY

P

11214

alla2009@gm

ail.com

(403)555‐

2121

A

2/11/2010

35161064578

JOSH

I ALO

K

491 N

EW BRUNSW

ICK AVE

PER

TH ANBOY

NJ

P

11611

C

2/11/2010

35164306999

JOSH

I ALO

K

1810 PARK AVEN

UE

SOUTH

PLAINFIELD

NJ

B

7086

210‐647‐

9078

A

2/11/2010

35167549420

JOSH

I ALO

K

327 BEA

CH 19TH

ST FA

R ROCKAWAY

NY

P

11691

joshi@

lookout.co

m

A

2/11/2010

35170791852

JOSH

I ALO

K

1810 PARK AVEN

UE

SOUTH

PLAINFIELD

NJ

P

11080

alokj@

complicate.co

m

A

2/11/2010

35173980831

JOSH

I ALO

K

45 SO

UTH

AVE W

CRANFO

RD

NJ

P

17016

210‐647‐

9078

A

2/11/2010

35174034284

JOSH

I ALO

K

1200 RANDOLPH RD

PLAINFIELD

NJ

P

11060

joshi@

lookout.co

m

210‐647‐

9078

B

2/11/2010

35174155728

CURTIN

ANNETT

455 BAYR

IDGE P

KWY

BROOKLYN

NY

P

11209

A

4/1/2009

53128994459

DIM

ARTIN

O

BARB

540 ATLA

NTIC

AVE

BROOKLYN

NY

M

11217

B

10/3/2008

40274329687

O'BRIEN

BETH

1000 YO

UNGE R

D

WILLIA

MSV

ILLE NY

P

14221

1 201 555

3241

B

10/4/2008

35921387280

DE H

AAN

BILL

R

69 JESSE H

ILL JR DR SE

ATLA

NTA

GA

M

14606

deh

aan_w

j@yah

oo.co

m

A

2/11/2010

40212882461

VEN

KATR

AMAN

CHANDAR

130 N KINGSBRIDGE R

D

BRONX

NY

P

10468

B

2/11/2010

35174206298

RAHEJA

CHARU

N

1901 FIR

ST AVEN

UE

NEW

YORK

NY

P

10029

A

1/1/2009

35135253114

KOPEC

K

CHRIS

J 170 OLD

COUNTR

Y ROAD

RIVER

HEA

D

NY

P

11901

647 905

3541

A

2/11/2010

35174329687

KOPEC

K

CHRIS

J 33 M

OUNTA

UK HIGHWAY

QUOGUE

NY

P

11959

647‐905‐

3541

A

2/11/2010

35174149423

MAYFA

IR

DONALD

R

319 BAY STR

EET, ST MARYS

QUEEN

SBURY

NY

P

12804

d.m

[email protected]

m

B

2/11/2010

35174057668

KILLIA

N

DOUGLAS

41 HURLEY A

VEN

UE

KINGSTO

N

NY

P

12401

doug.killian

@thereab

out.c

om

A

2/11/2010

42164057163

KILLIA

N

DOUGLAS

41 HER

LEY AVE

KINGSTO

N

NY

P

12401

A

2/11/2010

35174288474

MCNAIR

EDWARD

J 525 E 6

8TH

ST DIV CARD

NEW

YORK

NY

P

10021

A

2/11/2010

40232572621

INWARD

EILENE

Suite 1

16, 3

METR

OPOLITA

N

AVE

KEW

GARDEN

S NY

B

11415

A

2/11/2010

35174353611

MEN

DEZ

ELIEZER

227 E 1

9TH

ST NEW

YORK

NY

P

10003

A

Con

figur

ing

Info

rmat

ica

MD

M M

ultid

omai

n Ed

ition

22

3

LAST_U

PDAT

E_D

ATE

CUSTOMER

_ID

LAST_N

AME

FIRS

T_NAM

E MIDDLE_

INITIAL

LINE_1_AD

DRE

SS

CITY

STAT

E AD

DRE

SS_

TYPE

ZIP

EMAIL_AD

DRE

SS

PHONE

OPT

_IN

_IND

2/11/2010

35174145210

O'BRIEN

ELIZABETH

1000 YOUNGS RD. SUITE 101

WILLIAMSV

ILLE,

BUFFALO

NY

P

14221

C

2/11/2010

25928668959

MEN

DEZ

ELVEG

ER

227E 19 ST

NEW

YORK

NY

P

10003

A

9/2/2009

1.00129E+11

GALTON

FRANCIS

47 NEW

SCOTLAND AVE

ALBANY

NY

P

12208

A

2/11/2010

35174241556

HARRIM

AN

GEO

RGE

B

1201 N OTT STR

EET

SCHEN

ECTA

DY

NY

B

12307

A

2/11/2010

42174341576

HARRIM

AN

GEO

RGE

B

1201 NOTT ST

SCHEN

ECTA

DY

NY

B

12307

A

2/11/2010

40128719021

SCHMIDT

INGNID

5032 STA

TE HIGHWAY 30

AMSTER

DAM

NY

P

12010

A

12/22/2008

35173967366

SCHMIDT

INGRID

31 SHER

MAN ST

JAMESTO

WN

NY

P

14701

A

5/6/2008

35228461293

SCHMIT

INGRID

A

5032 STA

TE HIGHWAY 30

AMSTER

DAM

NY

P

12010

B

2/11/2010

35173771586

STUART

JAMES

E 37 M

AIN ST

WHITESBORO

NY

P

13492

A

2/11/2010

35174230450

DARWEN

T JAMES

N

101 NICHOLLS RD T12 020

STONY BROOK

NY

M

11794

A

2/11/2010

35173994166

KOHLER

JOSEF

10 PLAZA

ST

BROOKLYN

NY

P

11238

A

12/4/2009

35132590111

O'BRIEN

LIZ

5875 S TRANSIT RD

LOCKPORT

NY

P

14094

[email protected]

m

B

2/11/2010

1.00129E+11

MARTINEZ

RAGUEL

8 STA

NLEY CIRCLE

LATH

AM

NY

P

12110

B

2/11/2010

40232590111

SPROUT

RUSSELL

B

415 NORTH

CEN

TER STR

EET

HICKORY

NY

P

28001

A

2/11/2010

1.00129E+11

LIGHTM

AN

SEYM

OR

870 CEN

TRAL AVE

FAR‐ROCKAWAY

NY

P

11691

A

2/11/2010

35173952822

DE HAAN

WILLIAM

669 BUTLER

ST SE

ATLANTA

GA

M

30303‐

3033

deh

aan_w

[email protected]

A

Configuring Inform

atica MD

M M

ultidomain Edition

224

So

urce D

ata: Z_B

ILL

ING

UP

DA

TE

_D

T

CU

ST

OM

ER

_ID

L

AS

T_

NA

ME

F

IRS

T_N

AM

E

MID

DL

E_

NA

ME

S

UF

FIX

SA

LU

TA

TIO

N

LIN

E_

1_

AD

DR

ES

S

LIN

E_

2_

AD

DR

ES

SC

ITY

S

TA

TE

A

DD

RE

SS

_T

YP

E

ZIP

Z

IP4

EM

AIL

_A

DD

RE

SS

P

HO

NE

M

AIL

_T

O

2/1

2/201

0 E

00

0741

452

O'B

RIA

N

EL

IZA

BE

TH

S

MS

1

000

YO

UN

GE

RD

WILLIA

MS

VIL

LE

NY

B

1

422

1 1

003

eliza

be

th@

ob

rianfam

ily.com

N

2/1

2/201

0 E

16

5311

946

BR

IEN

E

LIZ

AB

ET

H

O

M

RS

1

000

YO

UN

GS

RO

AD

D

O N

OT

CO

NT

AC

TW

ILIAM

SV

ILL

E

NY

P

HY

SIC

AL

1

422

1

eliza

be

th@

ob

rianfam

ily.com

Y

2/1

2/201

0 E

52

5343

464

MC

NA

IR

ED

WA

RD

J

M

R

52

5 E

68TH

ST

DIV

C

AR

D

N

EW

YO

RK

B

10

021

Y

2/1

2/201

0 E

55

3307

170

ME

ND

EZ

E

LV

EG

ER

D

R

22

7E

19T

H S

T

DO

NO

T C

ON

TA

CT

NE

W Y

OR

K

NY

P

1

000

3 4

21

drm

end

ez@

me

dica

lmigh

t.com

N

2/1

2/201

0 E

55

3357

794

ME

ND

EZ

E

LIE

ZE

R

DR

2

27

EA

ST

19T

H

ST

RE

ET

NE

W Y

OR

K

NY

B

1

000

3

Y

2/1

2/201

0 G

62

0333

142

HA

RR

IMA

N

GE

OR

GE

F

RE

DE

RIC

K

SN

R

MR

1

201

NO

TT

ST

RE

ET

SC

HE

NE

CT

AD

Y

NY

P

1

230

7 3

421

Y

2/1

2/201

0 H

30

091

659

7 IN

WA

RD

E

ILE

EN

M

S

11

6-03

ME

TR

OP

OL

ITA

N

AV

E

K

EW

GA

RD

EN

S

NY

1

1

141

5

eile

en

.inw

ard

@tilt.com

N

2/12/2010

I253831818 S

CH

MID

T

ING

RID

A

MR

S

50

32 S

TA

TE

HIG

HW

AY

3

0

AM

ST

ER

DA

M

MA

M

1

201

0

Y

2/1

2/201

0 J3

653

306

99

DA

RW

EN

T

JIMM

Y

3

RD

M

R

1 N

ICH

OL

LS

RD

ST

ON

Y B

RO

OK

N

Y

P

11

794

Y

2/1

2/201

0 J5

233

306

99

DA

RW

EN

T

JAM

ES

N

EV

ILLE

III

MR

1

01

NIC

HO

LL

S R

D T

12

02

0

ST

ON

Y B

RO

OK

N

Y

PH

YS

ICA

L

11

794

Y

2/1

2/201

0 R

55

031

228

5 L

IGH

TM

AN

S

EY

MO

UR

M

R

87

0 C

EN

TR

AL

AV

EN

UE

FA

R R

OC

KA

WA

Y

NY

1

1

169

1

slightm

an@

illum

inatum

.com

N

2/1

2/201

0 2

202

916

824

SP

RO

UT

R

US

SE

L

2

MR

4

15

NO

RT

H C

EN

TE

R

ST

RE

ET

HIC

KO

RY

N

Y

MA

ILING

28001

Y

2/1

2/201

0 4

317

405

579

QA

SE

M

AL

BE

RT

M

R

82

68 16

4TH

ST

RE

ET

, Q

UE

EN

S H

OS

PIT

AL

JA

MA

ICA

N

Y

P

11

432

10

be

rt_q9

9@ho

tma

il.com

Y

2/1

2/201

0 8

387

269

620

DE

HA

AN

W

ILL R

MR

6

9 B

UT

LER

ST

SE

AT

LA

NT

A

GA

P

3

030

3 3

033

Y

2/1

2/201

0 8

387

314

260

CU

RT

IN

AN

NE

TT

E

DR

4

55

BA

YR

IDG

E P

KW

Y

B

RO

OK

LY

N

NY

M

1

120

9 7

90

acu

rtin@

dra

pery.co

m

N

2/1

2/201

0 A

41

6292

274

QA

SE

M

AL

BE

RT

M

R

QU

EE

N H

OS

PIT

AL

C

EN

TE

R, 8

268

16

JAM

AIC

A

NY

P

1

143

2

be

rt_q9

9@ho

tma

il.com

Y

2/1

2/201

0 A

42

0275

782

JOS

HI

AL

OK

M

R

49

1 N

EW

BR

UN

SW

ICK

A

VE

N

O C

ON

TA

CT

P

ER

TH

AM

BO

Y

NJ

2

11

611

a

lokj@

comp

licate

.com

N

2/1

2/201

0 A

42

4281

101

LE

WIS

A

LIC

E

DR

S

TO

NY

BR

OO

K U

HO

SP

O

AK

LAN

D G

AR

DE

NS

N

Y

P

11

364

Y

2/1

2/201

0 A

65

5358

133

HE

RN

AN

DE

Z

AL

EJA

ND

RO

M

R

92

20 E

LM

HU

RS

T A

VE

JAC

KS

ON

HE

IGH

TS

N

Y

MA

ILIN

G

11

372

90

12 a

l_h

erna

nde

z@m

sn.co

m

21

0-57

7-

82

91 N

2/1

2/201

0 A

91

6292

274

KA

SE

M

AL

BE

RT

M

R

80

WO

OD

WA

RD

ST

RO

SL

YN

HE

IGH

TS

N

Y

P

11

577

12

43 b

ert_

q99@

hotm

ail.com

Y

2/1

2/201

0 B

61

6918

072

DI M

AR

TIN

O

BA

RB

AR

A

MR

S

54

0 A

TL

AN

TIC

AV

E

DO

NO

T C

ON

TA

CT

BR

OO

KL

YN

N

Y

1

11

217

75

31

21

0-45

2-

90

56 Y

2/1

2/201

0 D

54

331

287

3 M

AY

FA

IR

DO

NA

LD

R

RE

V

31

9 B

AY

RD

QU

EE

NS

BU

RY

N

Y

P

4

804

d.m

ayfa

ir@m

erry.co

m

19

015

55 23

2

19

2 N


Creating an Empty Training ORS and Applying Changelists

Overview

This course is packaged with changelists that were captured after each lab to help you catch up with the class if you fall behind. You may apply the changelists in one of two ways:

Option 1: After recreating an empty TRN_LAB ORS – Use this option if the data in the underlying Oracle schema (the target Oracle tables) is not important to you.

Option 2: After deleting all objects in the TRN_LAB ORS – Use this option if the data in the underlying Oracle schema (the target Oracle tables) is to be retained.

Consult with the instructor as to which is a better choice for your situation.

Recreating an Empty ORS

This walkthrough is used with Option 1 above. Follow the steps below to recreate an empty trn_lab ORS (or any other for that matter):

1. Shutdown the JBoss application server with Ctrl-C and choosing Y when prompted.

2. Ensure that SQL Developer is not running or connected trn_lab.

3. Start a Command prompt:

Start > Run …> cmd.exe

4. Change directory to the classroom setup for Oracle and dump files:

cd C:\MDM_training\MDM330_91_Configuring_MDM_MDE\Setup\oracle

5. Start SQLPlus as a SYSDBA:

sqlplus system/admin as sysdba

6. Recreate the tns_lab ORS using the setup_ors.sql script:

SQL > @setup_ors.sql

7. Enter the following values when prompted and accept default values for all other prompts: Note: Some prompts may take a while to respond. Give them enough time to respond.


Name of User: trn_lab

Enter password for ORS User [!!CMX!!] : accept default

Accept default for data tablespace, index tablespace, temporary tablespace and temp.

Note: You may wait for over 30 seconds while the user is dropped and recreated

Oracle Server TNS name: infaorcl

Enter name of DBA User [SYSTEM]: accept default

Password for DBA User: admin

File to import: trn_lab.dmp

Import from user name: trn_lab

GCS install path: <Enter>

This will run the script to recreate the ORS. If there are no errors, an empty trn_lab ORS has been created.

8. Exit from SQLPLus.

9. Start the MDM classroom services (to restart JBoss)

10. Stoplight > MDM > Class Services start

When JBoss has completely started, continue to the next step.

11. Launch the MDM Hub Console and connect to the trn_lab ORS.

Note: You don’t need to re-register the ORS since this is already performed in the MDM Hub Console.

You shouldn’t see any objects in the Schema/Schema Viewer tool.


Option 1:

Apply a Changelist after Recreating the ORS

Option 1: After recreating an empty TRN_LAB ORS – Use this option if the data in the underlying Oracle schema (the target Oracle tables) is not important to you.

A changelist is an XML file that contains all the changes that have occurred to an ORS. A change is an operation in the change list—such as adding a base object or updating properties in a match rule—that is executed against the target ORS.

In this course, if you need to catch up with the class, you may apply a changelist of a particular lab. The changelist for each lab is stored in the following folder:

C:\MDM_Training\MDM330_91_Configuring_MDM_MDE\Setup\lab changelists

1. Navigate to Metadata Manager.

2. Validate the ORS:

a. Click the Validate tab.

b. Select the trn_lab repository.

c. Click the Validate icon and click OK.

If there are no errors, proceed to the next step. Otherwise correct the issue and validate again.


4. Select the Source changelist:

a. Click the Visual sub tab.

b. Click the Browse button (…) for the Source.

c. Click the File Repository tab.

d. Select the required changelist from the following folder:



e. Click Open.

f. Click OK.

5. Select the target ORS:

a. Select the Repository node on both the source and target.

6. Click the Promote icon.

7. Select the Replace option.


Note: This will apply all the changes that are in the source to the target.

8. Click OK.

9. Click the Apply Changes button.

10. Select Full Rollback and click OK.

11. Click Yes to validate the data integrity.

12. Click OK.

You will be prompted that the repository needs to be validated. You may ignore that for now.

13. Review the objects that were created in Schema, Schema Viewer, System and Trust, Queries, Packages, Cleanse Functions, and Mappings.

14. Update the Datasource for trn_lab:

a. Go to the Databases tool.

b. Select trn_lab.

c. Click the Edit database connection properties icon.

d. Click OK.

e. Click Yes when prompted to update the datasource.

f. Click OK.


Option 2:

Apply a Changelist without Deleting Objects

Option 2: After deleting all objects in the TRN_LAB ORS – Use this option if the data in the underlying Oracle schema (the target Oracle tables) is to be retained.

A changelist is an XML file that contains all the changes that have occurred to an ORS. A change is an operation in the change list—such as adding a base object or updating properties in a match rule—that is executed against the target ORS.

In this course, if you need to catch up with the class, you may apply a changelist of a particular lab. The changelist for each lab is stored in the following folder:


1. Navigate to Metadata Manager.

2. Validate the ORS:

a. Click the Validate tab.

b. Select the trn_lab repository.

c. Click the Validate icon and click OK.

If there are no errors, proceed to the next step. Otherwise correct the issue and validate again.


4. Select the Source changelist:

a. Click the Visual sub tab.

b. Click the Browse button (…) for the Source.

c. Click the File Repository tab.

d. Select the required changelist from the following folder:



e. Click Open.

f. Click OK.

5. Select the target ORS:

a. Select the Repository node on both the source and target.

6. Click the Promote icon.

7. Select the Use source values as final results for conflicts option.


Note: This will compare both source and target and apply only those changes that do not compare using the source changes as final.

8. Click OK.

9. Click the Apply Changes button.

10. Select Full Rollback and click OK.

11. Click Yes to validate the data integrity.

12. Click OK.

You will be prompted that the repository needs to be validated. You may ignore that for now.

13. Review the objects that should change in Schema, Schema Viewer, System and Trust, Queries, Packages, Cleanse Functions, and Mappings.

Register a Cleanse Match Server (if needed)

The Cleanse Match Server is configured in your labs and not in the change lists. Therefore after you apply a changelist, check to see if a Cleanse Match server is configured. If not, Follow the steps in Module 3 Lesson 1 Lab 1: Register a Cleanse Match Server to register the server.

Re-run the Jobs

If You Chose Option 1:

1. Run the following script from SQLPlus.:

C:\MDM_Training\MDM330_91_Configuring_MDM_MDE\Setup\TRN_create_ETL_simulation_proc.sql

2. Re-run any jobs that you need. Discuss with your instructor as to which jobs to run based on where you are in the labs.

If You Chose Option 2:

1. Re-run any jobs that you need. Discuss with your instructor as to which jobs to run based on where you are in the labs.

configuring informatica mdm multidomain edition lab guidegwinup.com/infa/configuring mdm multidomain...

Documents