dc55slides.ppt

Master Data Management Server 8.5
© 2009 IBM Corporation
IBM® InfoSphere™ Master Data Management
Architecture

2
AGENDA
InfoSphere MDM Server Domains
1. MDM Server and SOA
2. MDM Server Architecture
3. How Services are Implemented
4. How Services are Invoked
5. How Services are Extended
6. Event Management
7. Common Components
8. UI Architecture
9. Deployment Topologies

3
Hi, my name is ….

4
AGENDA
InfoSphere MDM Server Architecture
6. Event Management
8. UI Architecture
a. How MDM Server works in
context of SOA
b. MDM Data Model from SOA
point of view
c. MDM Services from SOA point
of view

5
Learning Objectives
At the end of this unit you will be able to:
• Describe how SOA and MDM relate
• How MDM Server works in the context of SOA

6
Master Data and Master Data Management
 Master Data is the high value information that a
company uses across their business.
– customers, suppliers, partners, products, materials, bill of
materials, chart of accounts, location and employees
 Master Data Management (MDM) is defined as the
set of disciplines, technologies and solutions to create
and maintain consistent, complete, contextual and
accurate business data for all stakeholders across
and beyond the enterprise.

7
Services and SOA
 Services are self-contained, reusable software
modules each of which performs a specific business
task. They have well-defined interfaces and are
independent of the applications and the computing
platforms on which they run.
 A service-oriented architecture (SOA) can be
described as a loose coupling of services which
communicate with each other. The process of
communication involves either simple data passing or
it could involve two or more services coordinating
some activity. Some means of connecting services to
each other is needed.

8
SOA Concerns
 SOA is often business process and business
component focused
– Data and Data Quality are often but an afterthought
 Consequences:
– Can lead to incomplete, inconsistent, inaccurate and
misinterpreted data
– Can lead to inconsistent rules around accessing the data
– Especially problematic for unmanaged Master Data
– Exposing bad data to more people (through services) just
makes things worse

9
MDM Server and SOA
 MDM Server can play many critical roles in a modern
service oriented architecture. It provides:
– A common authoritative source of accurate, consistent and
comprehensive master information for business services to access
critical business information.
– Common business services supporting consistent information-
centric procedures across all applications within the enterprise and
extended enterprise.
– Business process support to integrate with, or drive business
processes across, heterogeneous applications by making data
actionable.
– The ability to de-duplicate, validate, standardize and cleanse your
data.

10
SOA Reference Architecture and MDM Server

11
SOA Reference Architecture

12

13

14

15

16

17

18

19

20

21
Information as a Service
 InfoSphere MDM Server is a critical component in the
Information as a Service architecture.
 It provides access to Master Data through a large set
of well defined SOA services
 This provides:
– Consistency in the view and packaging of the data
– Consistency in the rules applied to the data
– A single point of maintenance

22
AGENDA
6. Event Management
8. UI Architecture
context of SOA
point of view
of view

23
Learning Objectives
• Describe the types of master data domains managed
in MDM Server.

24
Master Data
 MDM Server manages the following types of master data and the
relationships among them:
– Party
– Product
– Account

25
Master Data Types
Account-to-Party
Role
PARTY
Agent
Customer
Employee
Prospect
Supplier
ACCOUNT
Contract
Agreement
Reward Program
Financial Account
Transaction
PRODUCT
Product
Product Bundle
Ts & Cs Item/SKU
Service
LOCATION
Address
relationships
Service
Hierarchy
Ts & Cs Cross-reference
Keys
Category
Good
Interaction
Privacy
Events and Insight
Identification
Data
Stewardship
Financial Profile
Roles
Relationships
Demographics
Cross-reference
Keys
Account
Alerts
Account
Components
Agreement
Ts & Cs
Account
Relationships

26
InfoSphere MDM Server Data Model
 MDM Data Model
– MDM_CORE_Product.pdf
– MDM_CORE_Account.pdf
– MDM_CORE_Customer.pdf
– MDM_COMMON_(ADMIN AREA).pdf
 MDM Data Dictionary
– MDMCommonDataDictionary.pdf
– MDMDataDictionary.pdf

27
Qualities of Master Data
 Some qualities of Master Data include:
– Domain centric (e.g., Party centric)
– Application agnostic
– Process neutral
– Consistent in vocabulary and structures
– Enforced Quality – Proactively
 MDM Server provides additional qualities:
– Industry agnostic
– Technology agnostic
– Configurable and Extendible
– Alignment with Industry Models and Assets

28
Configurable and Extendible
 The MDM Server Data Model can be configured
through mechanisms such as code tables.
 MDM Server is extendible for existing tables and
allows for adding new tables or extending with xml
schemas.

29
AGENDA
6. Event Management
8. UI Architecture
context of SOA
point of view
of view

30
Learning Objectives
• Describe the types of services exposed by MDM
Server

31
Coarse
Grained/Fine
Grained
Services
Component
Methods
Business
Object
Model
Database
Service
Controller
Business
Processes
MDM Server ™ Core Application
MDM™ Request
Framework
Component
methods
Services
Data Repository & Information
Services

32
cdprodtp
inactivecontlink
nativekey
contactmethodgroup
identifier
incomesource
contractrole
contract
contact
org person
bankaccount
chargecard
personname
contactrel
address
contactmethod
orgname
inactivatedcont
contequiv
rolelocation
addressgroup
contractcomponent
locationgroup
suspect
personsearch
contractrolerel
rolelocpurpose
roleidentifier
rolesituation
contractcompval
prodtprel
contractrel
holding
vehicle
property
claim
claimcontract
claimrole
payrolldeduction
paymentsource
billingsummary
contsummary
contmacrorole
macroroleassoc
The MDM Server Party Logical Data Model

33
The Person Component
p p
cdprodtp
inactivecontlink
nativekey
contactmethodgroup
identifier
incomesource
contractrole
contract
contact
org person
bankaccount
chargecard
personname
contactrel
address
contactmethod
orgname
inactivatedcont
contequiv
rolelocation
addressgroup
contractcomponent
locationgroup
suspect
personsearch
contractrolerel
rolelocpurpose
roleidentifier
rolesituation
contractcompval
rodt rel
contractrel
holding
vehicle
property
claim
claimcontract
claimrole
payrolldeduction
paymentsource
billingsummary
contsummary
contmacrorole
macroroleassoc

34
p p
cdprodtp
inactivecontlink
nativekey
contactmethodgroup
identifier
incomesource
contractrole
contract
contact
org person
bankaccount
chargecard
personname
contactrel
address
contactmethod
orgname
inactivatedcont
contequiv
rolelocation
addressgroup
contractcomponent
locationgroup
suspect
personsearch
contractrolerel
rolelocpurpose
roleidentifier
rolesituation
contractcompval
rodt rel
contractrel
holding
vehicle
property
claim
claimcontract
claimrole
payrolldeduction
paymentsource
billingsummary
contsummary
contmacrorole
macroroleassoc
addPerson
updatePerson
getPerson
Services for the Person Component

35
p p
cdprodtp
inactivecontlink
nativekey
contactmethodgroup
identifier
incomesource
contractrole
contract
contact
org person
bankaccount
chargecard
personname
contactrel
address
contactmethod
orgname
inactivatedcont
contequiv
rolelocation
addressgroup
contractcomponent
locationgroup
suspect
personsearch
contractrolerel
rolelocpurpose
roleidentifier
rolesituation
contractcompval
rodt rel
contractrel
holding
vehicle
property
claim
claimcontract
claimrole
payrolldeduction
paymentsource
billingsummary
contsummary
contmacrorole
macroroleassoc
Large Grained Transactions
addPersonName
updatePersonName
getPersonName
addPerson
updatePerson
getPerson

36
InfoSphere Master Data Management Server
(RMI, Web Services, JMS, Batch)

37
Qualities of Master Data Services
 MDM Server Common Services
– Standardization
– Duplicate Suspect Processing
– Security
• ROV
• Data Entitlements
• Transaction Security
– Audit Information
– Data Validation
– Event Detection
– Notifications

38
Coarse
Grained/Fine
Grained
Services
Component
Methods
Business
Object
Model
Database
Service
Controller
Business
Processes
MDM Server ™ Core Application
MDM™ Request
Framework
Component
methods
Services
Data Repository & Information
Services

39

40
AGENDA
6. Event Management
8. UI Architecture
a. Big Picture
b. How does MDM Server work

41
Learning Objectives
• Describe the high level components in the MDM
architecture

42
MDM Server architecture modules and frameworks

43
Consumers
 Provides user interfaces,
adapters and frameworks
to invoke services by using
the Request Framework
 MDM Server User
Interfaces
– Administration UI
– Data Stewardship UI
 Client Interfaces
– ESB, MQ Broker or EAI
Broker, etc.

44
Request/Response Framework
 Entry point into the
Core MDM Server
 Manages service
requests
 Parses service
requests
 Authorizes service
requests
 Constructs response

45
MDM Server Core
 Kernel of MDM
Server
 Party Services
 Product Services
 Account Services
 Admin Services
 Common Services

46
Extension Framework
 Mechanisms for extending:
– Service Behavior
– Data Model
 Pluggable Rules Engine

47
External Components
 Components delivered as
part of MDM Server
 Consumers of MDM
Server’s Services.

48
Integration
 Other Information
Management and AIM
products
 3rd party products

49
Common Components
 Well defined services to
the Core Application and
Request Framework

50
MDM Server architecture modules and frameworks

51
AGENDA
6. Event Management
8. UI Architecture
a. Big Picture
b. How does MDM Server work

52
Learning Objectives
• Describe the different modes of operations
• Describe the different styles of operations

53
Modes of Operations
Examples modes of operations:
1. Real time
– Client applications, UI, etc.
sending real time
transactions
2. Batch
– Batch processor sending
one of more transactions
in batch
3. Scheduled
– The Evergreen processor
in Event Manager sending
transactions based on next
process date
1
2 3

54
Styles of Operations
Consolidation Style Registry style Coexistence style Transaction style
Matches and physically
stores a consolidated
view of master data
Updated after the event
and not guaranteed up to
date
Authoring remains
distributed
No publish and
Subscribe
Not used for transactions
but could be used for
reference.
For reporting and
analysis & central
reference
Matches and links to
create a skeleton
system of record
Physically stores the
global ID, links to data
in source systems and
transformations
Virtual, consolidated
view is assembled
dynamically and is often
read-only
Mainly for real-time
central reference
Matches and physically
stores consolidated
view of master data
Updated after the event
and not guaranteed up
to date.
Authoring remains
distributed.
Publishes
the consolidated view.
Not usually used for
transactions but could
be used for reference.
For harmonization
across databases and
for central reference
Matches and
physically stores the
up-to-date
consolidated
view of master data
Supports
transactional
applications directly
— both new and
legacy — typically
through service oriented
architecture
Interfaces
Central authoring of
master data
Acts as System
of Record
to Support
Transactional
Activity
Analytical Focus Operational Focus

55
Consolidation Style
 Consolidate master data to
share with a target system, or
as a preparation for transaction
hub deployment
 Share consolidated master data
with analytics and data
warehouse environment
 Often include consolidation of
3rd party data Index Reference
Data
System of
Record Data
Data
Stewardship
Search &
Inquiry
SOR Add
& Update
Event
Processing
Collaborative Operational Analytical
Publish Insight
/ Reporting
Application
DW
DB
Existing
ODS
Legacy
CRM/ Front
Office
ERP

56
Registry Style
 MDM solution serves as an
index – cross reference to data
held in other systems
 May contain some limited data
required for data matching
 Also a common phase 1 of an
MDM project
Index Reference
Data
System of
Record Data
Data
Stewardship
Search &
Inquiry
SOR Add
& Update
Event
Processing
Publish Insight
/ Reporting
Existing
ODS
Legacy
ERP
Index Search &
Inquiry
A system that
requires
master index view
and search /
inquiry function

57
Co-existence Style
 Co-existence can be a logical
starting point for many projects
and very often phase 2 of an
MDM solution strategy
 Stores data that is created in
other systems
 Provides that data to other
applications via SOA
Index Reference
Data
System of
Record Data
Data
Stewardship
Search &
Inquiry
SOR Add
& Update
Event
Processing
Publish Insight
/ Reporting
DW
Existing
ODS
Legacy
CRM/ Front
Office
ERP
Index Search &
Inquiry
A system that
requires
master index view
and search /
inquiry function

58
Transaction Style
 Some projects deploy
transaction style initially
 Requires up-front strategic
planning
 Usually chosen because a long-
term enterprise-wide MDM
strategy is in place
Index Reference
Data
System of
Record Data
Data
Stewardship
Search &
Inquiry
SOR Add
& Update
Event
Processing
Publish Insight
/ Reporting
DW
Legacy
CRM/ Front
Office
ERP
New Application

59
Summary
You are now proficient in the following topics:
 MDM Server architecture
• consumers, core, request framework, extension framework,
external components, common components, integration
components
 MDM Server modes of operations
• real time, batch, scheduled
 MDM Server styles of operations
• consolidation, registry, co-existence, transaction

60
AGENDA
6. Event Management
8. UI Architecture
a. Service Overview
b. Pre/Post Processing Framework
c. Persistence
d. How Variability is addressed
e. Error/Exception Handling

61
Learning Objectives
• Describe the different types of services
• Describe the application framework
• Understand how a service is executed in the
application framework

62
Service Organization
 Core of MDM Server organized into modules
– Party, Product, Account, Common, Admin
 Each module provides a rich set of services
 The services all built according to an Application
Framework
 The services are invoked through the

63
Services
 Approximately 800 services (as of MDM Server 8.0)
 Inquiry
– getxxx, getAllxxx
 Search
– searchxxx
 Persistent
– addxxx, updatexxx, deletexxx
– collapsexxx,splitxxx, …

64
Granularity of Services
 Coarse-grained service vs. fine-grained service
– e.g. addPerson = addPerson + … +
addPartyAddress + … +
addPartyIdentification + …
vs
– e.g. addPartyIdentification
 Service invokes reusable business logic components

65
Granularity of Services – A Demonstration
Service
Consumers MDM Runtime
Fine Grained
Coarse Grained
Financial
Profile
Address
Name
Relationship
Identification
Bank Account
Income Source
Privacy & Preference
Line Of Business
Contract Party Role
Native Key
Contract Relationship
Role Location
Role Identifier
Party
Interaction Interaction Summary
MDM out of the box
Client composites & additions
Interaction Relationships
Contract

66
Application Framework
 Three parts to the Application Framework:
1. Vocabulary of a service
2. Behavior of a service
3. Pre/Post Processing of a service
Core MDM Server
TxnController
FinderController
Business
Component
BObj
BObj
EObj
ODS
BObj
B
O
b
j
Pre
Pre Post
Post
Pre Post
Request
Response
Framework

67
Vocabulary of a service
 Each service accepts data as part of the request and
returns data in the response
 Each service request consists of a control structure
and data payload
– Control structure known as “DWLControl”
– Data payload represented as:
• Business object graph for persistent and search services
• Set of parameters for most inquiry services

68
Role of DWLControl object
 Provide context and processing information about the transaction
 The DWLControl is shared by the business object and any of the
child objects under it
 A subset of elements from DWLControl stored in transaction audit
log and can drive the conditions of when to execute behavior
extensions
 Name/value pairs
 You can add your own name/value pair

69
Core MDM Server
TxnController
FinderController
Business
Component
BObj
BObj
EObj
ODS
BObj
B
O
b
j
Pre
Pre Post
Post
Pre Post
Request
Response
Framework
Business object
 The vocabulary of a service (i.e., the data provided to and received
from a service)
 By convention, xxxBObj
 Usually an abstraction of the corresponding database entity
 Attributes of the business object only accept String values
 Most xxxBObj classes are backed up by the corresponding entity
object
 Maps directly to XML schemas for RMI and Web Services interfaces

70
Core MDM Server
TxnController
FinderController
Business
Component
BObj
BObj
EObj
ODS
BObj
B
O
b
j
Pre
Pre Post
Post
Pre Post
Request
Response
Framework
Entity object
 By convention, EObjxxx
 Strongly typed attributes
 Maps to the physical data model
 Most entity classes are annotated to map to the physical
database table

71
Behavior of a service
 Services are implemented using a component based
approach
 A method on Controller components equates to a
service
 Controller components aggregate Business Logic
components to carry out the service
 Business objects used as parameters in the
component’s methods

72
Core MDM Server
TxnController
FinderController
Business
Component
BObj
BObj
EObj
ODS
BObj
B
O
b
j
Pre
Pre Post
Post
Pre Post
Request
Response
Framework
Controller Component
 Interface for the service and aggregates underlying business
components
 Means for the business components to collaborate together to
carry out a service
 All controller classes extend from DWLCommonComponent class
 Service gets executed at the controller component by reflection
– Persistent service is implemented by a session bean;
pattern xxxBean
– service-to-controller class lookup is defined in the
TCRMCommon.properties or
DWLCommon.properties

73
Core MDM Server
TxnController
FinderController
Business
Component
BObj
BObj
EObj
ODS
BObj
B
O
b
j
Pre
Pre Post
Post
Pre Post
Request
Response
Framework
Business Logic Component
 The heart of MDM Server
 Example is “Party Component” that provides behavior for
inquiring, searching and maintaining the single version of truth for
person and organization data
 Process business rules that are either encapsulated within the
boundaries of the component or are externalized elsewhere
 Manage interactions with the database
 All component classes extend from DWLCommonComponent

74
Application Framework
Core MDM Server
TxnController
FinderController
Business
Component
BObj
BObj
EObj
ODS
BObj
B
O
b
j
Pre
Pre Post
Post
Pre Post
Request
Response
Framework

75
AGENDA
6. Event Management
8. UI Architecture
a. Service Overview
c. Persistence

76
Learning Objectives
• Understand the role of Pre/Post processing framework
in the transaction lifecycle
• Describe the difference between Pre and Post
execution logic
• Describe the extension points exposed by Pre/Post
framework

77
What is Pre-Post Transaction Framework?
Core MDM Server
TxnController
FinderController
Business
Component
BObj
EObj
ODS
Pre
Pre Post
Post
Pre Post
Request
Response
Framework
• Part of the Application Framework
• Allows business transactions to inherit common behaviors
• “Pre” logic automatically executed at the beginning of transaction/action
and “Post” logic executed at the end.

78
78
Core MDM Server
TxnController
FinderController
Business
Component
BObj
EObj
ODS
At the beginning of each transaction the framework will:
1. Populate Before Image for Update Controller level transactions
2. Invoke internal and external validation
3. Invoke behavior extensions
4. Invoke Rules of Visibility for persistent (Add/Update) transactions
Pre
Pre Post
Post
Behavior
Extension
External
Validation
Rule
Pre Post
PreExecute() Transaction Logic

79 79
TxnController
FinderController
Business
Component
BObj
EObj
ODS
At the beginning of each Business Component (Action) the framework will:
1. Invoke internal validation
2. Check for redundant updates for Update transactions
3. Invoke deleteRecord() on Business Objects for Delete transactions
Pre
Pre Post
Post
Pre Post
Behavior
Extension
PreExecute() Business Component Logic

80
80
At the end of each Business Component (Action) the framework will:
1. Collect TAIL (Transaction Audit Information Log) data
3. Invoke the following methods on extended objects
• getRecord(), addRecord(), updateRecord
PostExecute() Component Logic
TxnController
FinderController
Business
Component
BObj
EObj
ODS
Pre
Pre Post
Post
Pre Post
Behavior
Extension

81
81
Core MDM Server
TxnController
FinderController
Business
Component
BObj
EObj
ODS
At the end of each transaction the framework will:
2. Create TAIL records on Controller level transaction
3. Invoke Rules of Visibility for inquiry transactions
Pre
Pre Post
Post
Behavior
Extension
Pre Post
PostExecute() Transaction Logic

82
Internal Validation
• Types of validations include code table validations,
start/end date validations and foreign key constraints.
• Controller Level
– preExecute() after External Validation
• Component Level
– preExecute()
• Maintains integrity of the data
• Cannot be customized
• Business Object Methods
– validateAdd, validateUpdate
BObj
validateAdd(int level)
validateUpdate(int level)

83
External Validation
 Controller Level
– preExecute()
 Customizable
– Rules Written for External Validation Engine and can plug in new
“validators”
– Configured via Administrator UI and is managed as metadata
– Example: “MinLength” of “PersonName.lastName” >= “2”
Controller
BObj
EObj
Pre Post
External
Validation
Rule

84
3 Categories of External Validation
 Fixed type data validation
– Targets Java class type data (PersonBObj)
– Supports Cross Field Validation and Element Validation
 Variable type data validation
– Targets XML typed Data (Product Specs)
 Context only validation
– Targets transaction type Data (addPerson)

85
External Validation Flow
• Data and Context pass through validations
• When data and context match, validation function is
executed

86
Recursive Validation
 Used to traverse through a tree structure object graph
 A Pre-defined function “Recursive” that applies only to
fixed type data.
 Set recursive validation in
V_ELEMENT_VAL table
to loop through elements
of child object

87
Transaction Audit Information Log (TAIL)
 Services to store and retrieve transaction log
information
 Log any transaction and configured in metadata
– persistent, search and inquiry (including failed transactions)
– Can also log internal transactions, or “actions”
 Logged synchronously or asynchronously
 getTransactionLog service
– Returns TAIL from the audit log tables
– Can also return transaction history details from the history tables
• Stores Audit information:
• UserName or UserRole, Transaction Name, PartyId or
ContractId, and elements from DWLControl.

88
Behavior Extensions
• Custom Business Logic for a transaction or set of
transactions
– Custom Java Class
– Extends ClientJavaExtensionSet class
• Invoked in pre/post framework
– preExecute() or postExecute()
– Controller level or Component Level
• skipExecution() flag
– Set to “true” will skip core transaction logic and will go directly to
postExecute() step.
– Used to replace core business transaction logic

89
AGENDA
6. Event Management
8. UI Architecture
a. Service Overview
c. Persistence

90
Learning Objectives
• Describe operational versus history databases
• Describe pureQuery
• Describe and understand the Pluggable Persistence
Layer
• Describe the business object query framework
• Understand how these frameworks are used

91
Operational versus History Databases
 Operational Database
– Contains the operational data for the master data
domains
– Data retrieved and persisted using persistence
framework
 History Database
– Used for data audit
– Is a replica of the operational database’s schema with
additional control fields for tracking history
– Access for “Point in Time” (PIT) or date-range inquiries
– Populated using simple or compound data base triggers

92
IBM® Data Studio pureQuery
(MDM Server’s Default Persistence Layer)

93
IBM® Data Studio pureQuery
 Heart of the persistence framework
 High-performance Java data access framework
 Used for all of its database access
 MDM Workbench generates all the persistence code
with the help of pureQuery
TxnController
FinderController
Business
Component
BObj
EObj
ODS
Request
Response
Framework
PureQuery
Business
Object
Query
Framework

94
EObjxxxData
ODS
pureQuery
EObjxxxDataImpl
EObj
Implementation Class
generated by pureQuery
Interface Class
contains SQL
definitions
Entity Object
contains database
mapping and
attributes
PureQuery

95
PureQuery Entity Object:
 Each entity object (EObj) is
mapped to the database using
annotations:
@Table
@Id
@Column
@DataType
@Table (name=“REMINDER”)
public class EObjReminder extends EObjCommon {
private static final String tableName = "REMINDER";
private static final String ReminderIdColumn = "REMINDER_ID";
private static final String ReminderIdJdbcType = "BIGINT";
private static final int ReminderIdPrecision = 19;
@Id
@Column (name=“REMINDER_ID”)
@DataType (jdbcType=“BIGINT”, precision=19)
public Long ReminderId;
EObjxxxData
ODS
pureQuery
EObjxxxDataImpl
EObj
Implementation
Class generated by
pureQuery
Interface Class
contains SQL
definitions
Entity Object
contains
database
mapping and
attributes

96
PureQuery InquiryData Interface:
 An InquiryData interface contains
several annotated inquiry methods
 An inquiry annotation has 2 parts:
SQL and pattern
static final String tableAliasString = "tableAlias (H_CONTACT =>
com.dwl.tcrm.coreParty.entityObject.EObjContact, H_PERSON =>
com.dwl.tcrm.coreParty.entityObject.EObjPerson)";
@Select(sql ="SELECT DISTINCT C.CONT_ID , … , P.CONT_ID , … FROM H_CONTACT C LEFT
JOIN H_PERSON P ON P.CONT_ID = C.CONT_ID”, pattern= tableAliasString)
Iterator<ResultQueue2<EObjContact, EObjPerson>> getPersonLightImages(Object[] parameters);
EObjxxxData
ODS
pureQuery
EObjxxxDataImpl
EObj
Implementation
Class generated by
pureQuery
Interface Class
contains SQL
definitions
Entity Object
contains
database
mapping and
attributes

97
Pluggable Persistence Layer
TxnController
FinderController
Business
Component
BObj
EObj
ODS
Request
Response
Framework
Custom
Persistence
Layer
Business
Object
Query
Framework
 To create a new Persistence Strategy
– Extend the BObjQuery (AbstractBObjQuery)
– Override the persistent methods you wish to
extent (eg. persistAdd())
– Register the extended query factory in
property file

98
The MDM Server PureQuery Sequence
CorePartyComponent
PersonBObjQuer
y
handleAddPerson
create
.createPersonBObjQuery
PersonBObjQuery
PersonBObjPersi
stenceQueryFact
ory
Uses the
TCRM.properties to
acquire the classpath
BObjPersistenceQueryFactory
create
persistAdd()
DataAccessFactory EObjPersonDataImpl
getQuery(DataAccess Interface
Class, QueryConnection)
DataAccess Implementation
Instance
createPerson (PersonEObj)
Create Person in
Database
PersonEObj
New as of MDM 8.5, to
help decouple
persistence layer from
Component

99
The MDM Server PureQuery Sequence
CorePartyComponent
PersonBObjQuer
y
EObjPetInquiryImpl DataAccessFactory
handleGetPerson
create
.createPersonBObjQuery
(query method)
PersonBObjQuery
provideQueryInterfaceClass()
PersonBObj
QueryFactory
Uses the
TCRM.properties to
acquire the classpath
BObjQueryFactory
create
PersonBObjQuery
getSingleResult
getQueryConnection – Uses the DataManager
Method exist in the
Parent class
GenericBObjQuery
Method exists in
PersonBObjQuey
getQuery(DataAccess Interface Class, QueryConnection)
DataAccess Implementation Instance
PetResultSetProcessor
provideResultSetProcessor
Method exists in
PersonBObjQuey
queryResults – operated
agains the QueryConnection
getObjectFromResultSet (Iterator)
createObject
Method implemented by
GenericResultSetProces
sor
Vector <PetBObj>
PersonBObj – the first element on the Vector

100
Other Data/Persistence Related Features
 Pluggable ID Generators
– For defined tables or application as a whole
– Default primary key generation algorithm contains “Realm” component to enable
multi-site adds
– Can also provide primary key in service layer (primary key business object)
 Customizable Inquiry Levels
– Can configure what day should be returned for a given level
– Defined in meta data
 SMART Inquiries
– Can “disable” parts of the data model not in use
 Summary Indicators
– Can manage what data a party has to enable more efficient inquires
– For example: only retrieve addresses for a given party when we know the party
does in fact have one or more addresses
 Paging
– On Search and GetAll transactions

101
AGENDA
6. Event Management
8. UI Architecture
a. Service Overview
c. Persistence

102
Learning Objectives
• Describe how the behavior of MDM can be controlled
by changing various configuration points
• Understand the role of External Rules framework
• Describe the usage of Configuration and Management
component

103
Controlling variability within services
 Three primary methods for customizing or controlling
the behavior of existing services:
1. External Rule Framework
2. Configuration options
3. Plug in points

104
External Business Rules Component
 When implementing a service there is some business logic that will
be variable. Example: Matching two parties
 Pluggable pieces of business logic
 Used in numerous features
– Suspect Duplicate Processing
– Search
– Notification
– Event Manager
– And many more
 Implemented as Java classes or as Third party Rules Engines rules.
• Default rule engine - iLog’s JRules

105
How External Rules Component works
ExternalRuleComponent aExternalRuleComponent =
TCRMExtRuleHelper.getExternalRuleComponent();
ExternalRuleFact aExternalRuleFact = new ExternalRuleFact();
Vector input = new Vector();
input.addElement(theTCRMPartySearchBObj);
aExternalRuleFact.setInput(input);
aExternalRuleFact.setRuleId("9"); // searchParty
aExternalRuleFact.setComponentObject(this);
aExternalRuleComponent.executeRule(aExternalRuleFact);
// get the output from external rule engine
vecResult = (Vector) aExternalRuleFact.getOutput();
addPerson Component

106
Configuration and Management (CM) component
 Manages configurable options
 Both standalone and enterprise applications
 Configuration options could be dynamic or static
– Static
• Restarting application server required
– Dynamic
• Changes take effect immediately

107
Configuration and Management architecture
• Configuration Repository
• Configuration Client
• Management Console
manages configurations
through the Management
Agent.
• Management Agent uses
JMX MBean on the
Application Server

108
Configuration definitions and schemas
 Configuration definitions
– XML documents
– Contains all the configuration items and their values
– Hierarchical, consists of:
• Nodes. Document nodes correspond to XML entities
• Items represent the actual configurable values. Document
items correspond to entity attributes
 In CONFIGELEMENT table, XML converted to canonical
name structure
– Name = /IBM/DWLCommonServices/TAIL/enabled
– Value = false

109
Adding Configuration options
 New configuration nodes and items
– Added during development process
– Configuration definition (dwl-config.xml) and
configuration definition schema (dwl-config.xsd)
– Configuration changes through management console
validates against XSD schema
 Extensions can create new configuration nodes and
items to manage Extension feature

110
Standardized Interfaces
 Allows customizations of some components by exposing
standardized interfaces and providing a factory mechanism for
instantiating custom implementation
 This type of customization mechanism is available in the following
components and more:
– Security
– Parser and Constructor
– Business Proxy
– Data persistency framework
– Standardization, Normalization, Phonetic key Generator
– Batch Processor Writers and Reader

111
AGENDA
6. Event Management
8. UI Architecture
a. Service Overview
c. Persistence

112
Learning Objectives
At the end of this unit you will be able to understand:
• Reference Error Messaging Component
• Logging

113
Error handling
 Application and System Errors
– Captures error condition
• ComponentID (Eg TCRMPersonBObj)
• Error Type Code (Eg READERR)
• Error Code
– Reports back to caller with a meaningful error message
– Error message texts are externalized
– Error severity level can be assigned
 Utilities classes help to handle exceptions
– com.dwl.tcrm.utilities.TCRMExceptionUtils
– com.dwl.base.util.DWLExceptionUtils

114
Logging
 Two available logging APIs:
– JDK Logging
– Log4J Logging
 Location of log messages configurable
 Log messages can be filtered based on class, sub-package or
package level.
 Allows severity level to be configured for runtime to control the
level of detail in the log destination
 Common logging API can be used in additions, extensions and
external rules.
– private static IDWLLogger
logger=DWLLoggerManager.getLogger(TheClass.class);
– logger.fine(“logging messages in TheClass.theMethod()");

115
AGENDA
6. Event Management
8. UI Architecture
a. MDM Server Consumers
b. How Services are invoked
c. How Services are Handled
d. Transaction Statistics

116
Learning Objectives
• Understand MDM service consumers types
• Describe what can make service invocations

117
What can be MDM service consumer?
 Any application that can call into MDM Server and
invoke its services
 MDM Product Consumer:
– Business Administration web application
– Data Stewardship web application
– MDM’s Java Component

118
Common MDM service consumer
 Some practical MDM Consumer examples:
– ESB, MQ broker or EAI broker
– Dashboard or portal user interfaces
– Client applications

119
AGENDA
6. Event Management
8. UI Architecture

120
Learning Objectives
 Describe the different protocols for invoking MDM
Server services
 Describe the single entry point into MDM Server
(ServiceController)
 Describe the other interfaces such as WebService,
Batch, Messaging

121
Service Invocation Protocols
 MDM Services can be invoked via various
communication protocols:
– RMI-IIOP
– JMS
– SOAP
– JMX (used by Configuration and Management
component)
 Services can also be invoked in batch using the Batch
Processor
– Default readers/writers use files

122
MDM Services are transactional
 Invoking any MDM Service is a transactional operation
 MDM Services may participate in a distributed
transaction
 The services over RMI-IIOP, JMS and WebServices
protocols are all stateless services
 JMX is the only stateful communication protocol,
specifically designed for MDM’s configuration and
management services

123
The Request Response Framework
DWLServiceController Core MDM
Server
ProcessRequest
(Request, Hashmap)
DWLRequestHandler
Business Proxy
TransactionObj

124
124
Receiving the request: DWLServiceController
Core MDM
Server
ProcessRequest
(Request, Hashmap)
TransactionObj
DWLCommon
1. RMI - Invoked using processRequest(Hashmap context, Serializable
request)
2. Stateless session bean, container transaction type “required”
3. Invokes the RequestHandle (DWLRequestHandler by default)
DWLServiceController
DWLRequestHandler
Business Proxy

125
processRequest
public Serializable processRequest (HashMap context, Serializable request)
throws DWLResponseException, java.rmi.RemoteException;
 Context
– TargetApplication
– RequestType
– Parser
– ResponseType
– Constructor
– OperationType
– CompositeParser
– CompositeConstructor
– CompositeTxn

126
Web Service Requests
 Supported Standards
– WS-I Basic Profile 1.0 compliant
– SOAP over HTTP(S)
 Web Services Adapter
– Web Services interface to the MDM Server Service Controller
• WsDWLServiceControllerAdpater.wsdl
 Strongly typed Java Interface
– Each function area has a web service, like BillingService,
ClaimService, etc
– Web Services are described by a series of WSDL and XSD
files
• Service descriptions in WSDL files
• Data type definitions in XSD files

127
Messaging Requests
 Messaging Adapter
– uses a message-driven bean, or MDB
– uses container-managed transactions. Default transaction
attribute defined as NotSupported.
– Provide transaction context values as application-specific
JMS header properties.
 Request / Response Queues
– Each Messaging Adapter MDB is associated with a request
queue and a response queue
– Both Response and Exception data configurable whether to
put on response queue

128
Batch Requests
 Batch Processor
– handles each record in its unit of work.
– Multi-threaded execution
– Can dynamically adjust threads
 Pluggable Readers/Writers
– Reader responsible for reading the batch input and returning one record at a
time
– Writers is responsible for writing the batch output
– Writers can be Chained, like Chained FileWriter, SuccessWriter.
 WAS XD Batch Processor
– driven by an XJCL batch job
 Common usage includes initial loads, delta loads, extracts
Writer
Reader
Batch Processor
Input
Output
Properties

129
AGENDA
6. Event Management
8. UI Architecture

130
Learning Objectives
 Describe how services are parsed
 Describe how services are secured
 Describe how services are fulfilled by calling the MDM
Core
 Describe how service responses are constructed

131
What happens when a service is being handled?
 A requested service is processed by various components
inside MDM Server. Some of these components are:
– Service Controller
– Request Parsers
– Authentication and Authorization
– Business Proxy
– Controller Components
– Response Constructors

132
DWLServiceController Core MDM
Server
ProcessRequest
(Request, Hashmap)
DWLRequestHandler
Business Proxy
TransactionObj

133
133
DWLRequestHandler (Part 1)
ProcessRequest
(Request, Hashmap)
TransactionObj
DWLCommon
1. Invoked by the DWLServiceController and passed the Request
2. ParserFactory determines the Parser from the DWLCommon.properties
Parser.<ApplicationName>.<Parser>
3. DWLRequestHandler invokes the parseRequest on the Parser
Parser
DWLRequestHandler
Business Proxy

134
134
Parser
Transaction Object
1. Constructs a Transaction based on the type of request (eg. addPerson).
a) A Transaction Object can be an InquiryTransaction, PersistentTransaction, or SearchTransaction
b) Each request type defines which transaction object to create in the CDBusinessTxnTP table
2. For Search and Persistent transaction, constructs the Business Object (BObj) passed in the request
3. The BObj constructs an Entity Object (EObj) that will hold the simple attributes of the BObj
4. The Transaction Object is passed back to the DWLRequestHandler
Parser
Config
TransactionObj
BObj
EObj
DWLRequestHandler
Business Proxy

135
135
DWLRequestHandler (Part 2)
ProcessRequest
(Request, Hashmap)
TransactionObj
1. Receives the Transaction Object back from the Parser
2. Determines the Business Proxy from the DWLCommon.properties
BusinessProxy.<ApplicationName>.<RequestName> (RequestName, eg. addPerson)
3. Invokes the business proxy
4. Business proxy invokes a Controller Component
Core MDM
Server
EObj
Transaction Object
BObj
DWLCommon
DWLRequestHandler
Business Proxy

136
Securing the request: Authentication
 MDM Server Authentication
– Handled by Application Server
– Users Authenticated are given ServiceConsumers role
– MDM Server entry points grant access to the
ServiceConsumer role. They use the ServiceProvider
role as RunAs security role.
– Other Beans are not meant to be accessed directly by
other applications, and have their methods configured
to grant access to the ServiceProvider role
– A user identity passed in DWLControl in the requests

137
Securing the request: Authorization
 Authorization
– Handled by MDM Server
 Default Transaction Authorization Provider
– MDM Server Database stores information about security
policy
– A Security Manager administers the authorization data
– The authorization data associates users and groups to
the transactions that they are authorized for.

138
Securing the request: Custom Authorization
 LDAP Transaction Authorization Provider
– Transaction authorization check against an LDAP repository
– Independent of the LDAP server and the directory structure used to store the
authorization data
– uses JNDI to connect to the LDAP server
– uses the LDAP search functionality to query the directory for a relationship
between the transaction and the group or user
 Plug in point
– A custom transaction authorization provider
– A custom user management provider
– A custom authentication assertion parser to parse out user/group information

139
Row Level Authorization
 Rules of Visibility
– For inquiry and search services (get, getAll, search)
– Checked at Controller level post-execute
– Only visible data is returned in the response
 Persistency Entitlement
– For persistent services (add, update, delete)
– Checked at Controller level pre-execute
– Service fails if no entitlement
 Access Token
– Can stamp Party and Contract records with a token
– Consumer must have proper token to access record

140
140
Constructor
Transaction Object
1. Construct the response to be returned to the caller.
2. Define in properties file in the format of
a) Constructor.<TargetApplication property value>.<Constructor property value>
3. Default Constructors
a) MDM Server XML Constructor
b) Composite XML Constructor (Used in composite request framework)
Constructor
TransactionObj
BObj
EObj
DWLRequestHandler
Business Proxy
TCRM

141
AGENDA
6. Event Management
8. UI Architecture

142
Learning Objectives
• Describe the usage of Transaction Statistics
• Describe the Service Activity Monitoring facility
• Understand how it is used

143
Usage of Transaction Statistics
 MDM Server has the ability to provide information about
every transaction processed.
– This information is made available through the Service
Activity Monitor facility.
 These transaction statistics can be used to provide
system reports (MIS) for:
– Gaining an understanding of how the MDM Server
transactions are used in a given implementation.
– Capacity planning
– Performance optimization

144
Service Activity Monitoring facility
 Service Activity Monitoring provides information about
every transaction processed.
– This includes information such as:
• Transaction name
• Start/end times
• Request/response size
• Transaction outcome
• DWLControl elements

145
How is Service Activity Monitoring used
 Information capture by Service Activity Monitoring is
available through either JMX or log files.
MDM Server
Service
Activity
Monitoring
Facility
MBean
JMX Listener
Log File
Notification

146
AGENDA
6. Event Management
8. UI Architecture
a. Types of Extensions
b. Data Extensions
c. Data Additions
d. Specs
e. Behaviour Extensions
f. Composite Services

147
Learning Objectives
• Describe the types of extensions that can be made to
MDM Server
• Explain when to use each type of extension
• Describe the MDM Workbench tooling
• Explain when the MDM Workbench can assist in
extension development

148
MDM Server Extension Framework
 Two Main Extension Types
– Data: Changes to the data model
– Behaviour: Changes to service execution

149
 Data Addition
– Changes to the data model involve adding new entities, or subject area to the
data model
– Also involves adding new supporting services to the product framework
 Data Extension
– Changes to the data model involves adding new elements to an existing
entity in the data model
– Extension framework allows for these new elements to be persisted and
retrieved by all existing services consuming the modified entity
 Specs
– Defines new attributes for Products, Parties, Contracts using an XSD
– Attributes values are stored in the database as an XML
Data Extensions
Parse Request with Extension  Validate Extension BObj  Persist/Retrieve  Construct Service Response with Extension

150
Behavior Extensions
 Service behavior
– Adding new behavior to existing services
– Pre/Post Framework
 Query behavior
– Change the query implementation for an existing service
 Composite service behavior
– Pull existing services together to execute as one unit of work
• Customize business proxy
• XML
TxnController
FinderController
Business
Component
BObj
EObj
ODS
Pre
Pre Post
Post
Pre Post
Request
Response
Framework

151
“wizards”
Location
Variant
Category
Party
Model (module.mdmxmi)
(operational model)
MDM runtime
MDM Server Workbench
Developers
Code artifacts Tailored code
Tailor Deploy
Generates
Manipulate
 Integrated set of Eclipse-based tools
 Development environment set-up
 Code generation for:
– Data Extensions
– Behavior Extensions
– Specs
MDM Workbench

152
• Model-driven
 MDM Server
Workbench generates
artifacts from models
 Supports incremental
development
 Preserves manual
changes to code on
regeneration
DDL database definitions
•DDL to seed database tables
•DDL to populate Metadata DB tables
Request-response XSDs
•Sample XML requests
Java code
•Controllers
•Business objects
•Interfaces
•Transaction skeletons
•Behaviour extension skeletons
•Query extension skeletons
•Code tables
Web Service definitions
•WSDL files
•Implementation
generates
Pet
Vehicle
Driving
License
Insurance
Extensions Model
EJB Bean Descriptors

153
 @generated tag indicates that the code can be over-
written the next time the model-to-code transform is
used
/**
* Performs the business logic for transaction handleRenewPolicy.
*
* @generated
*/
public DWLResponse handleRenewPolicy(TCRMContractComponentBObj theBObj)
throws Exception {
DWLStatus status = new DWLStatus();
DWLResponse response = createDWLResponse();
// MDM_TODO Add required business logic to complete the transaction
return response;
}
Example of generated code…

154
 Add “NOT” or remove the @generated tag to preserve the
customization the next time the model-to-code generator
is used
/**
* Performs the business logic for transaction handleRenewPolicy.
*
* @generated NOT
*/
public DWLResponse handleRenewPolicy(TCRMContractComponentBObj theBObj)
throws Exception {
DWLStatus status = new DWLStatus();
DWLResponse response = createDWLResponse();
// required business logic to complete the transaction
long policyId = clonePolicy( theBObj , status );
if( status.getStatus() == DWLStatus.SUCCESS ) {
setPolicyDatesForThisYear( policyId , status );
}
response.setStatus( status );
return response ;
Example of tailored code

155
AGENDA
6. Event Management
8. UI Architecture
b. Data Extensions
c. Data Additions
d. Specs

156
Learning Objectives
• Understand at a high-level how data extensions can
be made to the product
• List the key areas of the product that may be modified
to support a data extension
• Explain how the extended data flows through a basic
MDM service

157
Extending Existing MDM Entities
 Data Extension
– New data attributes for existing entities
.
• Credit Risk
TCRMPersonBObj
• Birth Date
• Client Importance Type
• Highest Education
• Gender Type Code
• Children Count
• Marital Status
…
New Attribute

158
 Persist Attributes to Existing Table
 Persist Attributes to a New Table
Two Approaches to Data Extension Persistency

159
Consideration New Table Alter Existing Table
Compatibility Issues
None Changing core tables could lead
to compatibility issues with future
releases of the product.
DB I/O Performance
Inquiry transactions require two DB
calls: one for the core table, and
another one for the extension table
When using the Inquiry framework
only one DB call is required for
Inquiry transactions.
Mapping Extension
Attributes
Extension entity object is mapped to
the extension table using pureQuery
Java annotations.
The extension entity object is
mapped to the same table as the
original entity object was mapped
to, using pureQuery Java
annotations.
Ability to Tune Low High
Data History
History for the extension columns is
kept in its own history table
Two history records are created in
the core history table for
insert/update transactions.
Persistency Guideline

160
How to Extend Existing MDM Entities
DWLRequestHandler
Business Proxy
TransactionObj
TxnController
FinderController
Business
Component
BObj
EObj
BObj
EObj
TCRM
Database
Audit
Extended
Database
XML Schema
Extend Schema
Update extension
properties file
Extend business
object
New Entity Object Create New Table OR
Alter Existing Table
Add Metadata

161
<TCRMPersonBObj>
…
<TCRMExtension>
<ExtendedObject>XPersonBObjExt</ExtendedObject>
<PersonBObjExt>
<CreditRating>100</CreditRating>
</PersonBObjExt>
</TCRMExtension>
</TCRMPersonBObj>
Sample XML Request/Response Fragments
 MDM Server Workbench generates a
sample XML snippet of the extended
business object.

162
Extended Business Object
 New Extended BObj extends existing BObj
 Contains new EObj containing new
Attributes
 addRecord, updateRecord, deleteRecord,
getRecord
BObj
BObjExt

163
Creating Validation for Extended Business Object
Two options:
1. Using external validation component
• Database configurations for disallowed
values, minimum field length etc.
• MDM Server Workbench does not create
External Validation
2. On the extended business object
• Modify validateAdd(), validateUpdate(),
validateGet(), validateDelete()
• MDM Workbench provides “TODO”
notifications to provide customizations to
validations

164
New Entity Object
 New Entity Object (EObj) contains new
Attributes
 Maps to the Database Table using
Annotations
 Exists inside BObj
EObjExt Extended
Database

165
The AddPerson Sequence
Request/Response CorePartyTxn PersonComponent PersonBObj XPersonBObj PersonEObj XPersonEObj
XML
XML
Create
Create
EObj
BObj
addPerson(BObj)
addPerson(BObj)
getEObj()
Save EObj
(PureQuery
createEObj)
EObj
BObj
BObj
Create
EObj
addRecord()
Save XEObj
(PureQuery
createEObj)

166
The GetPerson Sequence
Request/Response CorePartyTxn PersonComponent BObjQuery XPersonBObj PersonEObj XPersonEObj
XML
XML
getPerson(PKj)
getPerson(PK)
getSingleResults()
BObj
BObj
getRecord()
Create
Create
EObj
BObj
BObjQuery knows to
create the Extended
PersonBObj because
of the
TCRM.properties file
Create
XEObj
Post-
Component
Level

167
AGENDA
6. Event Management
8. UI Architecture
b. Data Extensions
c. Data Additions
d. Specs

168
Learning Objectives
• Understand at a high-level how data additions can be
made to the product
• List the key areas of the product that may be modified
to support a data addition

169
Adding a New MDM Entity
 Data Addition
– Allows for the creation of new services over a new subject area
– Customization that provides additional functionality by incorporating new
entities and their accompanying services.
– Follows the MDM Server Application Framework. Data flows through a
service in exactly the manner as any existing MDM Service.
addPet
updatePet
getPet
PetBObj
• Animal Type
• Size
• Name
…

170
Business
Component
How to Create a New MDM Entity
DWLRequestHandler
Business Proxy
TransactionObj
TxnController
FinderController
Business
Component
BObj
EObj
BObj
EObj
TCRM
Database
Extended
Database
XML Schema
Extend Schema
Update extension
properties file New Business Object
New Entity Object
New Table
Add Metadata
DWLCommon
TxnController
FinderController
New Controllers
New Component

171
Extending Schema
 MDM Server Workbench generates
schema snippets
 Snippets are merged with Extended
DTD/Schema
 TCRMExtension used as Extension Point
<!ELEMENT TCRMExtension (ExtendedObject?, OrganizationBObjExt?, PetBObj?>

172
Sample XML Request/Response Framework
<TCRMObject>
<TCRMExtension>
<PetBObj>
<AnimalType>Dog</AnimalType>
<Name>Buddy</Name>
<Size>Small</Size>
</ PetBObj>
</TCRMExtension>
<TCRMObject>
 MDM Server Workbench generates a
sample XML snippet of the extended
business object.

173
Sample WebService Request/Response Framework
<xsd:complexType name="XPersonBObjExt">
<xsd:complexContent>
<xsd:extension base="party:Person">
<xsd:sequence>
<xsd:element name="XPersonContId" type="xsd:long" minOccurs="0"/>
<xsd:element name="EyeColour" type="xsd:string" minOccurs="0"/>
<xsd:element name="XPersonLastUpdateTxId" type="xsd:long" minOccurs="0"/>
<xsd:element name="XPersonLastUpdateDate" type="xsd:date" minOccurs="0"/>
<xsd:element name="XPersonLastUpdateUser" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

174
Controllers
 Finder Controller (inquiry services)
– POJO
 Transaction Controller (add/update)
– Session bean
 New configurations are required in the
extension properties file:
addPet=com.ibm.training.controller.PetTxnBean
updatePet=com.ibm.training.controller.PetTxnBean
getPet=com.ibm.training.controller. PetFinderImpl
tcrm_extension.properties

175
Business Component
 Holds all business logic for all the
services for the new entity
 Uses pureQuery to persist and retrieve
the new entity from the database
 Property file is used by Controller to
find classpath of Component
pet_component=com.ibm.training.component.PetComponent

176
Business Object
PetBObj=com.ibm.training.component
 Holds Entity Object (EObj)
 validateAdd, validateUpdate,
validateDelete, getValidationStatus
 Extends DWLCommon

177
<Java Interface>
PetFinder
<Java Class, Controller>
PetFinderImpl
<Java Interface>
Pet
<Java Class, Component>
PetComponent
<Java Interface>
PetTxn
<Java Class, Controller>
PetTxnBean
<Java Class>
PetBObj
<Java Class, Table>
EObjPet
<<Use>>
<<Use>>
<<Use>>
<<Use>>
<<Use>>
Add New Supporting MDM Components

178
The AddPet Sequence
DWLServiceContoller DWLRequestHandler DWLTxnBP PetTxnController PetComponent PetBObj PetEObj
XML
XML
XML
Create
Create
EObj
BObj
Execute(TxObj)
addPet(BObj
addPet(BObj)
Save EObj
(PureQuery
createEObj)
BObj
BObj
XML
PetBObjQuery
create
Uses the
BObjPersistent
Factory
persistAdd
BObj
BObj

179
The GetPet Sequence
DWLServiceContoller DWLRequestHandler Business Proxy PetFinder PetComponent PetBObj PetEObj
XML
XML
XML
EObj
Execute(TxObj)
getPet(PK)
getPet(PK)
getSingleResult
Create
BObj
BObj
BObj
XML
PetBObjQuery
Get
BObj
BObj

180
AGENDA
6. Event Management
8. UI Architecture
b. Data Extensions
c. Data Additions
d. Specs

181
Learning Objectives
• Understand what Specs are
• Understand why we use Specs
• Understand where Specs are stored and what Entities
in the MDM Server Data Model can use Specs

182
What are Specs?
 A Type of Metadata used to define a data extension
 Uses XSD to define structure
 Does not change the Database Schema
 Values of Specs are stored as an XML Document
(Dynamic Attributes)
Student
Loan Spec
(XSD)
Interest
Amount
GPA
Qualifications
Interest=3%
Amount=200
Product:Loan
(XML)
Interest=2%
Amount=600
Product:Loan
(XML)
Interest=2%
Amount=600
Product:Loan
(XML)
Interest=2%
Amount=600
GPA=3.8
(XML)
Star
Student
Loan
Good Luck
Student
Loan
Student
Flex Loan
Student
Freedom
Loan

183
Product Specs – Logical Model

184
Why Specs?
 Flexible – create data extension without redeploying the
server
– Faster go to market time
– Some attributes have short life-cycle
– Some attributes will evolve over time
 Structured
– Unlike Miscellaneous Value (also an entity in MDM
Server), data attributes are well defined

185
When do I want to use Specs?
 Short Lifecycle
– Seasonal Product or Attributes that may change over time
– Many Product Attributes have this feature
 Domain
– Attributes only apply to specific entities
 Time to market
– Specs can be created faster than hard attributes create through
Extensions and Additions to the data model

186
Where can I add Specs?
 Product Domain
– Products Type (Applied to Products of a specified Product Type)
– Product Category (Applied to a Product if in Category)
 Account Domain
– Agreement Type (Applied to all Contracts of a specified
agreement type)
 Party (Demographics)
– Applied directly to the Party (available to all Parties)

187
Where are Specs Stored?
(Party Domain)
Version
Values
for
Single
Party

188
(Product Domain)
 Similar to PartyDemographics
except uses the EntitySpecUse
Table
 EntitySpecUse
– Used to Connect to various
Entity in the Product
Domain using the
entity_name
(PRODUCTYYPE or
CATEGORY) and
instance_pk
 Products that are of the
ProductType or linked to the
Hierarchy Category can use the
Spec

189
(Account Domain)
 Similar to Product Domain (uses
the EntitySpecUse Table
 Contact are associated with a spec
if they are a specific Agreement
Type

190
How do I work with Specs?
 Through Services (add/update/get values)
– Add/Update/Get Specs for all Domains
– Used in Coarse Grain transaction (e.g. getContract returns ContractSpecValues)
 Fine Grain Spec Service
– Update and Add since Element Values of the Specs

191
How do I create Specs?
 Workbench
– Workbench assists in the creation of Specs and deployment
 Admin Services
– Various Admin Services allows you to add, update and get Specs

192
AGENDA
6. Event Management
8. UI Architecture
b. Data Extensions
c. Data Additions
d. Specs

193
Learning Objectives
• Understand how behavior extensions can be made to the product
• List the areas of the product where behavior may be added or
extended
• Understand and use behavior extension terminology
• Identify the two types of rules supported by this framework
• Understand the information that is available to you for use in a
rule set implementation

194
The Extension Framework
• Extending behavior at predefined points
 An extension set can be:
– Rule set (such as ILOG JRules ilr file)
– Java class
 Extensions can be as broad or as narrow in scope
– All Update Transaction
– addPerson Transaction
 Behavior Extensions supported by MDM Workbench

195
195
Core MDM Server
Business Proxy
FinderController
Business
Component
BObj
EObj
ODS
Pre
Pre
Pre Post
ExtensionSet
Table
Cached Memory
TCRM
Java Class or
Rule Set (.ilr) file
Behavior
Extension
TxnController
Post
Pre Post
Post
Four Predefined Extension Points
1
1
2 3
4
4
Pre-Transaction
Behavior
Extensions
Pre-Action
Behavior
Extensions
Post-Transaction
Behavior
Extensions
Post-Action
Behavior
Extensions

196
What Do I Have to Work With?
 Extension Parameters
– Contains information for Behavior Extension
• DWLControl
• DWLStatus
• Controller-level representation of Object Tree
• Component-level representation of Object Tree
• Metadata
– transactionCategoryType
– actionCategoryType
– transactionType
– ActionType
– triggerCategoryType
Extension examples
• Sends notification (Address
Change)
• Executes services on another
system (Standardization)

197
AGENDA
6. Event Management
8. UI Architecture
b. Data Extensions
c. Data Additions
d. Specs

198
Learning Objectives
• Understand the types of Composite Services you can create
• Understand the behavior of a XML Composite
• Understand the behavior of a Business Proxy Composite
• Understand when to use XML composite vs Business Proxy
Composite"

199
Composite Services
• Executing more than one business service in one unit of
work
• XML Composite Service
• Supported by the XML interface
• No programmatic effort
• Java Composite Service
• Supported by customized business proxy
• Programmatic effort involved

200
200
Composite XML Transaction
• Each Transaction is described in the XML
• A transaction can refer to a previous transactions response
• A Composite Parser is used to send multiple requests to MDM
Server
Core MDM
Server
ProcessRequest
(Request, Hashmap)
TransactionObj
DWLRequestHandler
Business Proxy
TransactionObj
TransactionObj

201
Composite Transaction Syntax
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE DWLCompositeServiceRequest SYSTEM "CompositeTransactionRequest.dtd">
<DWLCompositeServiceRequest>
<TCRMService>
… (getPartyMacroRole)
</TCRMService>
<TCRMService>
… (updatePartyMacroRole)
</TCRMService>
</DWLCompositeServiceRequest>

202
Composite Transaction Syntax Part 2
<DWLControl>
<requesterName>{GlobalFields.requesterName}</requesterName>
<requesterLanguage>{GlobalFields.requesterLanguage}</requesterLanguage>
<transactionCorrelatorId>111</transactionCorrelatorId>
</DWLControl>
Correlating the Services and GlobalFields
{id.111.BusinessObject.BusinessObject.Child Element}
Backward Referencing
{id.11.TCRMPersonBObj.TCRMPersonNameBObj[0]. LastName}
OR
{id.11.TCRMPersonBObj.TCRMPersonNameBObj[WHERE NameUsageType=‘2’]. LastName}
Multiple Objects

203
<message errorId=”xxxx” lang=”yyy”> default_description </message>
Error Messaging
<choose>
<when test=” id.91341.response.TCRMPersonBObj. PendingCDCIndicator = ‘Y’">
(Service goes Here)
</when>
<otherwise>
(Service goes Here)
</otherwise>
</choose>
Conditional Referencing

204
<for-each select=”object-set-expression” var=”varName”>
<TCRMService>
…
<xmlTag> {$ varName.Id}</xmlTag>
…
<TCRMService>
</for-each>
Iteration Logic

205
XML Composite Service
 Conditional: <choose>, <when>, <otherwise>
 looping: <for-each select="object-set-expression" var="varName">
 Comparison Operator: = != < > <= >=
 Logical Operator: () and or
 Function: count() date()
 Object reference (as an example):
– id.444.response.TCRMPersonBObj.TCRMPersonNameBObj
[where NameUsageType = 1].LastName = ’Smith’
Tests if the LastName equals ″Smith″. The LastName is
from the TCRMPersonNameBObj object where the
NameUsageType equals 1. The TCRMPersonBObj object
comes from the response that has a correlator ID 444.

206
206
Composite Business Proxy
Core MDM
Server
ProcessRequest
(Request, Hashmap)
TransactionObj
DWLRequestHandler
• The new Business Proxy extends the existing Business Proxy
• The new Business Proxy is passed the Transaction Object as input
and can invoke multiple service requests on MDM Server
NewBP
Business Proxy

207
Business Proxy
Step 1: Determining the Request Structure
Step 2: Registering the Transaction in the Database
Step 3: Adding the Transaction Name to the Properties File
Step 4: Implementing the Business Proxy
Step 5: Deploying the Business Proxy with the MDM Server

208
Recommendations Composite approach
Requirement Approach
XML Composite Business Proxy
The “new transaction” is coming into MDM Server through the Object
Interface
Performance is a very important consideration for the “new
transaction”
No Java coding is desired or no Java skills are available.
Requirements for the “new transactions” change often.

209
Requirement Approach
XML
Composite
Business Proxy
The “new transaction” requires data from multiple sources and
messaging middleware is not in place or planned
The “new transaction” only requires interaction within MDM Server
“New” Transaction must be available no matter which interface is
used e.g. batch, messaging, web services
Minimum or no business logic is required between the execution of
the individual transactions
Complex business logic required between execution of the
individual transactions
Recommendations Composite approach

210
AGENDA
6. Event Management
8. UI Architecture
a. Event Manager Overview
b. Event Manager Architecture

211
Learning Objectives
• The usage of Event Manager
• The architecture of Event Manager
• How and when events are detected
• How events are scheduled

212
Event Manager Overview
 A set of database tables, processes, and business rules
within MDM Server that can track and react to system-
defined or user-defined events.
Core MDM Server
Request
Response
Framework
Event Manager
Client
Application
ODS
Busines
s Rules
EM
Tables

213
Business Use
 The Event Manager can be used to satisfy business
requirements:
– A customer cancels credit card.
– A customer turning 65 years old
– A customer withdrawals funds from a tax-sheltered account.

214
Technical Use
 Technical use:
• The application sends suspects to another engine for matching
asynchronously after a transaction.
– Evergreen processing
– Acxiom
– Business data corruption
– Compliance

215
When Are Events Detected
 Transaction based:
– A customer cancels a credit card.
• at the postExecute() of an updateContract transaction
 Time based:
– A customer turning 65 years old.
• Event Manager invokes the scheduler to query the party to see
if the party is over 65 years old
 Ad-hoc:
– A customer calls the CSR to request withdrawal.
• The CSR creates an explicit event.
Note: Detected events are persisted, and notification is sent out if it is enabled.

216
AGENDA
6. Event Management
8. UI Architecture
a. Event Manager Overview
b. Event Manager Architecture

217
Learning Objectives
• The architecture of Event Manager

218
Event Manager
Process Controller
Module
Event Detection Module
EventTask
EventDetectorMDB
Process Controller
EventDetector
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
Client Components
Configurable Components
Process Controller Internal
EM DB
Pub/Sub

219
Event Manager – types of events
EM
Events we are
informed about by
Clients (ad-hoc)
Timed passed by
Events resulting
from transaction
Event Occurrence:
what, when, for whom
Other Business
System
Perform
Transaction
MDM
Update
Data
ERP System
Send email

220
Event Manager – Ad-hoc
Process Controller
Module
EventTask
EventDetectorMDB
Process Controller
EventDetector
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
Client Components
Process Controller
Internal
EM DB
Pub/Sub
MDM Server
1
2
3
4
6
7
5

221
Event Manager – Time Based
Process Controller
Module
EventTask
EventDetectorMDB
Process Controller
EventDetector
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
Client Components
Process Controller
Internal
EM DB
Pub/Sub
1
2 3
4
6
7
5

222
Event Manager – Transaction Based
Process Controller
Module
EventTask
EventDetectorMDB
Process Controller
EventDetector
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
Client Components
Process Controller
Internal
EM DB
Pub/Sub
MDM Server 1
2
3
4
6
7
8
9
10
11
5

223
Process Controller
Process Controller
Module
EventTask
Process Controller
EM DB
 Two ways to invoke
–Send Explicit Event
–Send Business Object for
Event Detection
 Retrieves Event Categories
(ENTITYEVENTCAT Table)
 Creates EventTask for each
Event Category
 Place EventTask on queue

224
Process Controller
Module
EventTask
Process Controller
EM DB
 Invoked by a
EventDetectionScheduleCo
ntroller to detect events from
the ProcessAction table
 Retrieves Process Actions
that are passed Next
Process Date
(PROCESSACTION Table)
 Creates Event Task for each
Process Action
 Place EventTask on queue

225
Time Based Scheduler
1. EventDetectionScheduleC
ontroller makes a remote
call to the Process
Controller Module
2. Detects event for specific
event categories (defined
in the CDEVENTCAT
table)
– e.g. LifeEvents,
ValuePackage,
CreateSuspects,
CollapseParties
Process Controller
Module
Process Controller
EM DB
Event
Detection
Schedule
Controller

226
Event Detector Message Driven Bean
 Receives the EventTask
from the Process Controller
 Invokes the
process(EventTask) on the
EventDetectorHelper
EventTask
EventDetectorMDB EventDetector
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
EM DB
Pub/Sub

227
Event Detector Helper Session Bean
 Core of the Event Manager
 Receives EventTask from
EventDetectorMDB
 Invokes retrieveDataObject
on the EventTask
EventTask
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
EM DB
Pub/Sub
(Part 1)

228
EventTask
 Holds EventTask Details
(Business Object, Event
Category, etc)
 Uses Adapter
(ADAPTERDEF) to retrieve
Business Object from MDM
Server
 Retrieves previous events
and calculates event horizon
EventTask
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
EM DB
Pub/Sub

229
Event Detector
 Invoked by the
EventDetectorHelper
 Event Detection Rules are
executes
 Events found are passed
back to EventDetector
Helper
EventTask
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
EM DB
Pub/Sub

230
How Event Manager Detects Events
 Uses the External Rules component to configure
business rules
 Rules can be implemented in Java, or other pluggable
rules engine.
 The business object fetched by the adapter is used as
input to the business rule

231
Term and Condition Rule Framework
 Term and Condition
Rule Framework
introduced in MDM
version 8.5
 Offers a template
class as the super
type
 Allow Automatic and
Manual evaluation
mechanisms

232
At the end of event detection
 If an event is detected
– Business rule creates a pending EventBObj and returns the rule facts
– Event Persistence Module creates an EVENT record in the database.
– Sends notification to a destination.
 If an event is NOT detected
– Resets the PROCESSACTION.NEXT_PROCESS_DT by adding the number
days specified in the CDEVENTCAT.EVENT_HORIZON

233
Adding New Event Detection
 To add new event detection
– Define event category (CDEVENTDEFTP) and definition (CDEVENTDEFTP)
– Write adapter to fetch business object
– Write business rule to execute against the business object for that type of
event
 “Black box” processing
– Next process date reset
– Selecting entities for time based event detection
– Event persistence
– Notification sending

234
Retrieve Data for Event Detection
 PROCESSCONTROL
– stores the entity and its primary key
 Based on the primary key, Event Manager will fetch the
entire business object.
 MDM Server Adapter
– Defined in the ADAPTERDEF table
– Used to fetch business object based on the primary key

235
Event Detector Helper Session Bean
 Receives EventTask back
from EventDetector
 Persists each Event
detected
 Sets next processing date
based on horizon date of
Event Category
 Send Notification is defined
for event category
EventTask
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
EM DB
Pub/Sub
(Part 2)

236
Event Notifications
 Sends notifications to the a
destination queue
EventTask
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
EM DB
Pub/Sub

237
Event Manager
Process Controller
Module
EventTask
EventDetectorMDB
Process Controller
EventDetector
NotificationSender
External
Rules
EventDetectorHelper
Entity
Adapters
Client Components
EM DB
Pub/Sub

238
AGENDA
6. Event Management
8. UI Architecture

239
Learning Objectives
 Describe the various common components

240
Common Components
MDM Server uses a set of common components that
are not product or domain specific.
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Standardization Task Manager Search
Transaction Audit
Information Log

241
External Rules
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

242
External Rules
 Allows business rules to be implemented outside of a closed-source
product to allow a client to plug in own customized version of the rule
 External Rules implemented in java or a rules engine
 Example:
Survivorship
Searching
Compare
Address
Rank
Results
–data survivorship rules when collapsing
parties together
–how to rank and sort search results
Core WCC

243
External Validation
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

244
 Provides for table-driven validations of business objects and their
attributes
 Comes pre-packaged with a set of “validators” and supports new java
validators to be plugged in
 Example:
– MAXLENGTH Person.lastName = 30
External Validation
Range
Max/Min
Mandatory
Default
Core WCC

245
Event Manager
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

246
Event Manager
 Invokes client-defined business rules at pre-defined times to
determine if an event has occurred based on a given business object
 Detected events are recorded and can be notified on.
 Used in a variety of features such as the Data Corruption sample,
Abilitec integration, Value Package Management and Quality Stage
integration
 Example:
– Evergreen Processor, which is a process that monitors the party repository and
detects and notifies on suspect duplicate parties.

247
Notification
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

248
Notification
 Notifications are:
– Outbound Messages
– Publication Mechanism
– JMS Java Standard Messages
– Non-Persistent
 Ability to construct your own types of notifications
 Out of the box:
– Element Change, Suspect Processing and Data Stewardship, Event Manager,
Configuration (on/off, topics)
WCC
Pub/Sub
Notification
Framework
Client App
Client App

249
Rules of Visibility
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

250
Rules of Visibility
 Data-level entitlements (row and column-level security)
 Visibility Rules
– Which elements or instances of elements a user can see based on given
constraints
 Persistency Entitlement Rules
– Which elements or instances of elements a user can add or update based on
given constraints
 Example:
– Which users can see, add and update which MDM Server and client-extended
data elements

251
Meta Data
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

252
Meta Data
 Defines the MDM Server schema which consists of transactions,
actions, business objects and the relationships between them
 Example:
– MDM Server transactions
– Actions within transactions
– Business objects and attributes and relationships among them all

253
Caching
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

254
Caching
 Caching is generic component used to temporarily store data in
memory in order to speed up the operations of the system
 Example:
– Caching code table data
– Caching error messages

255
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log
Logging and Serviceability

256
Service Activity Monitoring Facility
 Service Activity Monitoring facility (Broadcaster)
– Captures System Information generated by MDM Server
– Broadcasts information through JMX Notification
– /IBM/DWLCommonServices/Report/Broadcaster/enabled
 Transaction Logger (Listener)
– Listens for Notifications from the MBean Server
– Print messages to Log File (default transaction.log)
– Configuration found in Log4J and JDK property file
– /IBM/DWLCommonServices/Report/Listener/enabled
MDM Server Report
Broadcaster
Report Listener
Transaction
Log

257
Transaction Audit Information Log
 Captures transaction audit details in a structured way. Provides
inquiry services to retrieve audit details given different inquiry levels
and with point-in-time
 It can be configured which transactions, actions within transactions
and data elements are to be captured
 Example:
– Logs all MDM Server and client-defined transactions and actions

258
Performance Tracker
 ARM compliant component that receives and records out distributed
transaction, MDM Server transaction and sub-transaction response
times
 Example:
– Performance tracking and the level of tracking is a configuration option. Examples
of levels include “transaction response time only”, “database activities response
time”, “client extensions response time”, etc.

259
Performance Logging (Logging Levels)
 Logging Levels
– /IBM/DWLCommonServices/PerformanceTracking/enabled
– /IBM/DWLCommonServices/PerformanceTracking/level
– Level 0
• Off
– Level 1
• Overall Transaction Time
– Level 2
• Validation, external components
– Level 3
• all Performance Points
– Level -1
• Customer Logging Level
– /IBM/DWLCommonServices/PerformanceTracking/RequestHandler/enabled
– /IBM/DWLCommonServices/PerformanceTracking/RequestParser/enabled
– /IBM/DWLCommonServices/PerformanceTracking/{Component}/enabled
– Etc.

260
Error Messaging
 Provides for table-driven error messages. Services exist to retrieve
and format messages according to a given locale

261
Logging
 Writes out messages to log files
 Implemented using Log4J or Java Logging API
 Example:
– Write out information, warning and error messages to separate logs

262
The DWL Logger
MDM Server
DWLLogger
Log4J JDKLogger
Log4J Loggers
– OFF
– FATAL
– ERROR
– ERROR
– WARN
– WARN
– INFO
– INFO, CONFIG
– DEBUG
– FINE, FINER
– ALL
JDKLogger
Loggers
– OFF
– SEVERE
– ERROR
– WARNING
– WARN
– INFO
– INFO
– CONFIG
– CONFIG
– FINE
– FINE
– FINER
– FINER
– FINEST
– ALL

263
The MDM Server Logs
MDM log files
 Customer.log
 EventManager.log
 ManagementAgent.log
 ManagementConsole.log
 PerformanceMonitor.log
 MDM Server Install logs
MDM Property files
 JDKLog.properties
 Log4j.properties
 Bootstrap.properties
 DWLLog.properies

264
A command line tool
without ISA dependency
to collect MDM Server logs and properties files
MDM Server Serviceability Tools
 ISA MDM Problem Determination Collector
 Standalone MDM Problem Determination Collector
 Log and Trace Analyzer for MDM Server
An ISA GUI tool to collect MDM Server logs
and properties files
An eclipse based ISA tool to
sort, filter and analyze MDM log files

265
Tools and its Users
Collect MDM Server data via ISA GUI Tool
Collect MDM Server data via Command line
Sort, filter and analyze huge log files in CBE formats
ISA PD collector
Standalone PD collector
LTA parser plugin
Customer
Customer
Customer / IBM Support
On Linux and Windows
On Linux, Solaris and AIX
On Linux and Windows

266
CBE adapter
 You can only import log files into the Log and Trace Analyzer
(LTA) that use the Common Base Event (CBE) format.
 The CBE adapter is a plugin that you install into the LTA.
 By default, your log files are formatted in the PatternLayout format,
when you install the CBE adapter, every time you import your log
files into the LTA, they are automatically reformatted into the CBE
format.
 You must install the LTA prior to installing the CBE adapter plugin.

267
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log
Configuration Manager

268
Configuration Manager
 Defines configurable features, possible configuration options and the
client’s chosen configuration option
 Configures global and feature-specific settings of a product
 Selected features can be configured dynamically across a clustered
environment
 Example:
– /IBM/DWLCommonServices/DateValidation/dateFormat –
The date format in which to represent a date field.

269
Configuration and Management Architecture
Management
Console
Management
Agent
RMI
MEJB
Configuration
Repository
Application Server
RMI
MDM
Server
MDM
Server
Application Server
(Managed Node)
Application Server
(Managed Node)
JDBC
JDBC
JMXMP

270
Configuration Definition and Schema
Master configuration definition (MDMMergedConfiguration)
/IBM
/CoreUtilities …. /DWLCommServices …. /ThirdPartyAdapters
 Configuration Definition – dwl-config.xml
 Configuration Schema – dwl-config.xsd

271
Configuration Elements
 Two types of Configuration Elements
– Static
• Required server restart
• Can be changed without the Configuration and Management system
– Dynamic
• Can change value dynamically without server restart
• Must use the Configuration and Management system
 Element Names
– XML Path
• eg. /IBM/DWLCommonServices/Reports
<IBM>
<DWL CommonServices>
<Reports>true</Reports>
</DWL Common Services>
</IBM>

272
Deploying and Undeploying Configuration Data
 Deploying the application configuration
 Undeploying the application configuration
 Partial deploying the application configuration
 Partial undeploying the application configuration

273
Partial Deploying the Application Configuration
 Use this option if you want to add to the master configuration
definition.
 You must restart the server to make this option take effect.
/IBM
/CoreUtilities …. /DWLCommServices …. /ThirdPartyAdapters /MyExtension

274
Partial Undeploying the Application Configuration
 Use this option if you want to remove portion of the master
configuration definition.
 You must restart the server to make this option take effect.
/IBM
/CoreUtilities …. /DWLCommServices …. /ThirdPartyAdapters /MyExtension

275
Standardization
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

276
Standardization
 Provides adapters to standardize data elements including names and
addresses
 Example:
– Using MDM default standardizer
– Using QualityStage standardizer

277
Task Management
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

278
Task Management
 Manages the definition of tasks by role
 Manages the lifecycle of a task instance assigned to a user
 Example:
– Used within Data Stewardship to organize work by assigning
tasks to data stewards for suspect duplicate party investigation
and collapsing

279
Party Search
External Rules
External
Validation
Event
Manager
Notification
Rules of
Visibility
MetaData Caching
Service Activity
Monitoring Facility
Performance
Tracker
Error
Messaging
Logging
Configuration
Manager
Transaction Audit
Information Log

280
Searching for Parties
• SearchParty
• SearchPerson
• SearchOrganization
• SearchFSParty
• SearchFederatedParty – (Unit 9)

281
281
Acceptable Search Parameters
Last Name
Organization Name
Address
Identification Type/Value
Contact Method Reference Number
Established Date
Date of Birth
Party Equivalency

282
Wildcards and Look-a-likes
%  Wildcard
?  Look-a-like
AdminPartyId
OrganizationName
LastName
GivenNameOne
GivenNameTwo
GivenNameThree
AddrLineOne
AddrLineTwo
AddrLineThree
CityName
ProvStateType
ZipPostalCode
CountryType
IdentificationNum
ContactMethodReferenceNumber
EstablishedDate
DateOfBirth
Examples
• ???10 (ZipPostalCode)
• %-5555 (Contact Method)
• S?ith (LastName
• John% (FirstName)

283
Common Name Exclusion
Prohibit vague searches from being returned successful
• LastName
• LastName and GivenNameOne
• Lastname and CityName
SEARCHEXCLRULE

284
Phonetic Searches
Returns ‘sounds-like’ matches generated by the
NYSIIS or Soundex algorithms for:
• Organization Name
• Last Name
• Given Name
• City
Wendy Torrence  ANT TRNS
Given_Name_One Last_Name
P_Given_Name_One P_Last_Name

285
Search for a Party Continues
Search Configuration
• Phonetic Search (On/Off)
• Max Results
Other Search Features
• Pagination
• Inquiry Levels
• Filters (ACTIVE, INACTIVE, ALL)
• Customizable Search Strategy
• Search Result Ranking and Sorting

286
AGENDA
6. Event Management
8. UI Architecture
a. MDM Server User Interfaces
b. User Interface Architecture
c. User Interface Security
d. Custom UIs

287
Learning Objectives
• Describe different UIs for MDM Server

288
MDM Server User Interfaces
 There are two user interfaces in the MDM Server
product.
– Business Administration UI

289
Business Administration UI
 The Business Administration UI is a “black box” web
application shipped with the product and used to
configure MDM Server.
 It consists of the following 5 modules:
–Rule Module
–Meta Data Module
–Code Table Module
–Security Module
–System Module

290
Rule Module
 The Rule Module allows you to:
– Manage Rules of Visibility
– Associate Rules of Visibility with user groups
– Manage group validations
– Manage element validations

291
Meta Data Module
 The Meta Data Module provides the capability to
manage data associations.
– Create data associations
– View data association details
– Edit data associations

292
Code Table Module
– Code table details
– Error messages
– Association of error messages
with application components
 The Code Table Module provides for the management
of:

293
Security Module
 The Security Module provides the capability to:
– Create user groups
– Associate transactions with user groups

294
System Module
 The System Module provides capability to:
– Manage the extension framework
– Manage the Transaction Audit Information Log (TAIL)

295
 The Data Stewardship UI is a “white box” web
application shipped with the product and used to
maintain data quality within MDM Server.
 It consists of the following 4 modules:
– Party Maintenance
– Managing Hierarchies
– Managing Party Grouping
Data Stewardship UI

296
 The Party Maintenance Module provides the capability
to:
Party Maintenance Module
– Add or delete a person or organization to
your system.
– Correct errors and update the information
for a person or organization, including any
of their related information.
– Perform a search, based on specific
criteria, to return the party you want to view
or update.
– Display an aggregated result view for a
party

297
 Provides a method for maintaining the quality of your
party data:
Suspect Duplicate Processing Module
– Search for suspect duplicates
– Collapse multiple suspect duplicate
party records
– Manage the tasks for party record
consolidation
– Mark and unmark prospective duplicate
suspects
– Create two new parties from one party
record

298
 The Hierarchy module provides a way for you to:
– Create, maintain and view hierarchical structure.
– Create, maintain and view hierarchy nodes.
– Create, maintain and view hierarchy relationships and roles.
Managing Hierarchies Module

299
 The Party Grouping feature allows you to:
Managing Party Grouping Module
– Search for parties and view a list of
groupings associated with a party
– Create, maintain and view the grouping
– Create, maintain and view grouping
associations
– Create, maintain and view grouping values
– Create, maintain and view grouping
association roles

300
AGENDA
6. Event Management
8. UI Architecture
d. Custom UIs

301
Learning Objectives
• Understand the UI Architecture for MDM Server

302
 There are two user interfaces in the MDM Server
product.
– Business Administration UI
 Both interfaces utilize a “thin” web browser based
client to communicate to UI web applications.
 The focus in this module will be on the Data
Stewardship UI.

303
Thin Web Browser Client
HTML
MDM UI
Web
applications
MDM
Server
MDM
DB
Http
J2EE Application Server
UI Client

304
Customer Service Admin Service
MDM Server
Maintain
parties
Process
suspects
Maintain
hierarchies
Maintain
groupings
Java Server Faces Pages
Suspect Search
Suspect Search
Party
models
Suspect Search
Suspect Search
Suspect
models
Suspect Search
Suspect Search
Hierarchy
models
Suspect Search
Suspect Search
Grouping
models
Java Beans
Web Container
EJB Container
SDO Objects Generated From Schema
Service Controller
JSF Runtime
Pagecode Classes
XML over RMI
View
Controller
Model
Data Stewardship UI Application

305
JSF Pages and Pagecode classes

306
JSF Runtime

307
Model Classes and SDO Objects

308
RMI Invoked Service Controller

309
JSF Web Application
MDM Server
Maintain
parties
Process
suspects
Maintain
hierarchies
Maintain
groupings
Suspect Search
Suspect Search
Party
models
Suspect Search
Suspect Search
Suspect
models
Suspect Search
Suspect Search
Hierarchy
models
Suspect Search
Suspect Search
Grouping
models
Java Beans
Web Container
EJB Container
Service Controller
JSF Runtime
Pagecode Classes
XML over RMI
View
Controller
Model

310
MDM Services

311
Complete UI Architecture
MDM Server
Maintain
parties
Process
suspects
Maintain
hierarchies
Maintain
groupings
Suspect Search
Suspect Search
Party
models
Suspect Search
Suspect Search
Suspect
models
Suspect Search
Suspect Search
Hierarchy
models
Suspect Search
Suspect Search
Grouping
models
Java Beans
Web Container
EJB Container
Service Controller
JSF Runtime
Pagecode Classes
XML over RMI
View
Controller
Model

312
AGENDA
6. Event Management
8. UI Architecture
d. Custom UIs

313
Learning Objectives
• Understand the UI Security for MDM Server

314
UI Security
 A form based login is used for UI authentication
– The MDM UI application takes advantage of a J2EE application server and
relies on a web container to do form based login authentication.
– The UI’s assume that an LDAP server is used to store user and group
security information.
– The username and password information passed to the application server will
be verified against the LDAP user registry defined on the application server.

315
UI Security Role
 Only one role is defined for the whole web application,
that role is mapped to all authenticated users.
• After a user is authenticated, the user has full access to the
whole web application functionality.

316
UI Transaction Authority
 The user name of the login user and the groups the
login user belong to (as defined in the user registry)
will be propagated to MDM Server for further
authorization on transaction authority, rules of visibility,
data persistency entitlement.

317
AGENDA
6. Event Management
8. UI Architecture
d. Custom UIs

318
Learning Objectives
• Understand the Workbench UI Generator

319
Custom UI
 A RSA plugin available to generate MDM Server UIs
 Generation of user interfaces from UML User Models
 Supports a range of rich widgets that require no coding
 Supports customization
– Custom text, fonts, buttons, text, background color
– Field size, screen layout (1, 2, or 3 columns)
 Full I18N/L10N support
 J2EE Ear File generated for Deployment on a WAS or Weblogic
Server

320
Custom UI Generation Steps
1. Create UML Models and
Look and Feel
2. Transform Model into
Code
3. Customize Code
(Translations, Command
Beans, Custom JSP)
4. Deploy to Server
1
2
3
4

321
1. Create UML Models
– <
Role Goal
Task Task Task
Object
Object
Object
Creates
Creates
Updates
Creates
Class Diagram for Basic
User Requirements
Filter
Deletes
To user
To Service
Activity Diagram for Task
Implementation
(Generated)
Domain

322
2. Transform Model into Code
 Wizard walks user through generating
the User Interface from the User Model.
 Available from the ‘Modelling’ menu in
RSA

323
Customize Code
Develop
Command
Beans
Customize
JSP
Configure
User
Directory
Choose
Style and
Layout
Label location Buttons
userDirectory.properties
Command Bean

324
Deploy to Server
Role defined
from User
Model
Domains and
Goals defined
in the User
Model
Workflow
defined by the
Activity
Diagram (Work
with Customer
Record)

325
Benefits
 Provides the starting framework to create a
User Interface to MDM Server
 Beta program success:
– 60 – 70% savings by using the User Interface
Generator

326
AGENDA
6. Event Management
8. UI Architecture

327
Learning Objectives
• Understand various MDM Server Deployment
Topologies
• Understand Federated Services

328
Sample Deployment Topologies

329
Separate MDM UIs and Server
 MDM UIs and MDM Server are to be deployed on
separate application server instance or even separate
machines.
MDM UI
Instance
MDM Server
Instance
MDM
DB
MDM UI
Client
Html over http XML over RMI
MDM Web
Service
Client
MDM RMI
Service
Client

330
MDM Server Clustering
 Physical Clustering
Having each MDM Server instance running on a separate physical machine
 Logical Clustering
Having multiple MDM Server instance running on same physical machine
Physical Clustering Group
Logical Clustering Group
MDM Server
Instance
MDM Server
Instance
MDM Server
Instance
MDM Server
Instance
MDM Server
Instance
MDM Server
Instance
MDM Server
Instance
MDM Server
Instance

331
Scaling
Two Types of Scaling
 Vertical Scaling
– Adding Capacity (memory, CPUs, etc)
– Increases capacity, manageability
– Decreases reliability, availability
 Horizontal Scaling
– Adding servers
– Increases reliability, availability, capacity, flexibility
– Decreases manageability

332
Deployment Sample 1: Single MDM Server
 MDM Server Deployed on single
server
 Machine A contains the
Deployment Manager node
 MQ Series deployed to separate
server
 MDM UIs are deployed to
separate server
 MDM DB and Config are
deployed to the same DB2 Server
 Can scale by increase capacity of
server hosting MDM Server
MDM
Config A
MDM UIs
MDM
DB
B
MQ Series

333
Deployment Sample 2: MDM Server Cluster
 MDM Server Deployed in a
Application Server Cluster
 Machine A contains the
Deployment Manager node
 MQ Series Deployed to separate
server
 MDM UIs are deployed to
separate server
 MDM DB and Config are
deployed to the same DB2 Server
 Can scale by adding servers and
increase capacity of each node
Cluster
MDM
Config A
B
C
MDM UIs
MDM
DB
D
MQ Series

334
Federated Services
(Connecting multiple geographically-distributed MDM Server instances)

335
Federated Services Example

336
Federated Services DataModel
336
Defines the Group of
Federated Instances (e.g.
Europe)
Defines the communication
protocol and adapter to use.
(e.g. RMI)
The Local Group that has
access to this federated
instance
The Local User that has
access to this federated
instance
Connection attributes
associated with the
Instance (e.g. host, port)
The MDM Server
instance in the profile
(e.g. Switzerland)
Connect the instance to
the profile
NOTE: The local instance
does not need connection
attributes

337
prefix = corbaloc://iiop
Port = 2809
Host = uk.ibm.com
prefix = corbaloc://iiop
Port = 2809
Federated Services Metadata
337
Name: UK
Name: France
Name: Switzerland
Local
RMI
FederatedInstance
CDProtoColTP
Host = fr.ibm.com
InstanceAttribute
FederadedProfInst
Name: Europe
FederatedProfile
GroupId: eufedusergrp
1
2
3
4
5
6
GroupFedInstance

338
How Federation Works
UK
France
Switzerland
 Custom Business Proxy
 Uses Work Queue to invoke
instances concurrently
 Combines all instance responses
into the service response

339
AGENDA
6. Event Management
8. UI Architecture
Thank You
For Attending

dc55slides.ppt

More Related Content

Similar to dc55slides.ppt (20)

Recently uploaded (20)

dc55slides.ppt

Editor's Notes