IBM InfoSphere Master Data Management Server

(1)

InfoSphere

Master

Data

Management

Server

Version

8.5.0 Understanding

and

Planning

Guide

LicensedMaterials–PropertyofIBM

(2)

(3)

InfoSphere

Master

Data

Management

Server

Version

8.5.0 Understanding

and

Planning

Guide

LicensedMaterials–PropertyofIBM

(4)

Note

Beforeusingthisinformationandtheproductitsupports,readthegeneralinformationunderAppendixA,“Notices,”on page85.

EditionNotice

Thiseditionappliestoversion8.5.0ofIBMInfoSphereMasterDataManagementServerandtoallsubsequent releasesandmodificationsuntilotherwiseindicatedinneweditions.

ThisdocumentislicensedtoyouunderthetermsoftheInternationalProgramLicenseAgreementorother applicableIBMagreement.Youmustensurethatanyonewhousesthisdocumentcomplieswiththetermsofthe InternationalProgramLicenseAgreementandanyotherapplicableIBMagreement.

Thisdocumentmayonlybeusedforyourinternalbusinesspurposes.Thisdocumentmaynotbedisclosedoutside yourenterpriseforanyreasonunlessyouobtainIBM’spriorwrittenapprovalforsuchdisclosure.

Youmaynotuse,copy,modify,ordistributethisdocumentexceptasprovidedintheInternationalProgramLicense AgreementorotherapplicableIBMagreement.

©CopyrightInternationalBusinessMachinesCorporation1996,2008.

(5)

Chapter

1. Understanding

and

planning

to

use

IBM

InfoSphere

Master

Data

Management

Server

features

.

. 1

PlanningtomodifyIBMInfoSphereMasterData ManagementServerfeatures . . . 1

InfoSphereMDMServerdomains . . . 1

UnderstandingInfoSphereMDMServer consumers . . . 2

UnderstandingtheInfoSphereMDMServer RequestFramework . . . 2

Chapter

2. InfoSphere

MDM

Server

platform

.

. 3

InfoSphereMDMServerplatformtechnicalfeatures 3 Errorhandlingandlogging . . . 3

SmartInquiries . . . 4

Inquirylevels . . . 5

SummaryDataIndicators . . . 6

Pluggableprimarykeys. . . 6

ServiceActivityMonitorfacility . . . 7

Request/ResponseFramework . . . 8

Compositetransactions . . . 9

BatchprocessingusingMDMBatch . . . 11

ConcurrentExecutionInfrastructureforrunning parallelsearches. . . 13

ConfigurationandManagementComponents . . 13

Datavalidation . . . 15

Externalbusinessrules . . . 16

Notifications . . . 17

Securityservice . . . 18

UniqueandpersistentIDgeneration . . . 19

WebServices . . . 20

TrackingIBMInfoSphereMasterData ManagementServerperformance . . . 21

InfoSphereMDMServerplatformbusinessfeatures 22 Pointintimehistory . . . 22

Historyinquirydaterangeimages. . . 23

StoringandretrievingtheTransactionAudit InformationLog. . . 25

Sourcevaluesanddatadecay . . . 27

Attachdocuments . . . 30

Conditionalstorageofduplicateparties . . . . 30

EventManagerandEvergreeningdata . . . . 32

Interactions . . . 35

Languageandlocalecustomization . . . 36

NameandAddressStandardization . . . 37

PartyCDCprocessing . . . 38

PartysearchesinIBMInfoSphereMasterData ManagementServer . . . 39

Partydeletion . . . 44

RulesofVisibilityandDataPersistency Entitlements . . . 45

SuspectDuplicateProcessing . . . 46

TaskManagementServices . . . 52

Chapter

3. The

Party

domain

.

. 55

Aggregatedpartyview . . . 55

Aggregatedpartyviewexampleuse . . . 55

Campaigns . . . 55

Campaignsexampleuse . . . 56

Financialprofile . . . 56

Financialprofileexampleuse . . . 56

Grouping . . . 56

Groupingexampleuse. . . 57

Hierarchy . . . 57

Hierarchyexampleuse . . . 58

KnowYourCustomer . . . 58

KnowYourCustomerexampleuse . . . 58

Lineofbusiness . . . 59

LineofBusinessexampleuse . . . 59

Macroandentityroles. . . 59

MacroandEntityRolesexampleuse . . . 60

Normalization . . . 60

Normalizationexampleuse . . . 60

Partydemographics . . . 61

Partydemographicsexampleuse . . . 61

Partyequivalencies. . . 61

Partyequivalenciesexampleuse . . . 62

Partylifeevents . . . 62

Partylifeeventsexampleuse . . . 62

Partylocation. . . 62

Partylocationexampleuse . . . 62

Partyprivacy. . . 63

Partyprivacyexampleuse . . . 63

Partyroles. . . 63

Partyrolesexampleuse . . . 64

Partyvalues . . . 64

Partyvaluesexampleuse. . . 64

InfoSphereMDMServerintegrationwiththirdparty products . . . 64

IBMInformationServerQualityStageintegration 65 DunandBradstreetintegration. . . 65

EntityAnalyticsSolutionsIntegration. . . 66

Chapter

4. The

Product

domain

.

. 69

Producttypehierarchy . . . 69

Producttypehierarchyexampleuse . . . 69

Productcategoriesandproducthierarchies . . . . 69

Productcategoriesandproducthierarchies exampleuse . . . 70

Productcategoryattributes . . . 70

Productcategoryattributesexampleuse. . . . 70

Productrelationship . . . 71

ProductRelationshipexampleuse. . . 72

Productequivalencies . . . 72

Productequivalenciesexampleuse . . . 72

Productidentifiers . . . 72

Productidentifiersexampleuse . . . 72

Productsearch . . . 72

(6)

Productsearchenhancements . . . 73

Producttermsandconditions . . . 74

Producttermsandconditionsexampleuse . . . 74

Specifications. . . 74

Specificationsexampleuse . . . 74

Chapter

5. The

Account

domain

.

. 77

AgreementBusinessServices . . . 77

AgreementBusinessServicesexampleuse . . . 78

Agreementtermsandconditions . . . 78

AgreementTermsandConditionsexampleuse 78 Termsandconditionsrulessetup . . . 78

Agreementdynamicattributes . . . 79

Agreementdynamicattributesexampleuse . . 79

Agreementdynamicattributesconfiguration behavior . . . 80

Billing . . . 81

Billingexampleuse. . . 81

Claims . . . 81

Claimsexampleuse . . . 82

ContractValues . . . 82

ContractValuesexampleuse . . . 82

Holdings . . . 82

Holdingsexampleuse. . . 83

Relationships. . . 83

Relationshipsexampleuse . . . 83

Valuepackages . . . 83

Valuepackagesexampleuse. . . 83

Appendix

A. Notices

.

. 85

Appendix

B. Trademarks

.

. 89

(7)

Chapter

1. Understanding

and

planning

to

use

IBM

InfoSphere

Master

Data

Management

Server

features

ThisguidecontainsinformationtohelpyouunderstandIBM®InfoSphere™Master Data ManagementServer (InfoSphereMDMServer)features, soyoucandecide whichfeaturesyouaregoingtouse,andthen createaplantoconfigureand implementthose features.

Theinformationforeachfeature includes: v Adescriptionofthefeature

v Anexampleofhow itcanbeused

For somefeatures,thefollowinginformationisalso provided:

v Informationonthebehaviorof thefeature whenitisconfiguredon,whenit is

configuredoff,and whentheconfigurationofthefeatureischangedina productionenvironment

v Whetherthefeaturemust beconfiguredduring installation

v

Linksto moreinformationabouthow tomodifythefeature

Some InfoSphereMDMServer featuresmust beconfiguredon whenInfoSphere MDMServer isbeinginstalledinordertobe availableata laterpoint,while other featurescanbeturnedonwhenyouarereadytousethem.

Other featurescannotbe configuredonoroff,butare alwaysavailable inthe installedInfoSphere MDMServerproduct.

For alistofthefeaturesthatarenewforthis releaseofIBMInfoSphere Master Data ManagementServer,refertotheReleaseNotes.

Planning

to

modify

IBM

InfoSphere

Master

Data

Management

Server

features

ModifyingIBMInfoSphere MasterDataManagementServer featuresallows youto addmorefunctionalitytoexistingfeaturesandtoscaleupfeaturestoprocess largervolumesofdata.Thissection includesinformationonhow toplanfor adding morefunctionalitytofeatures.Foradditional information,seetheModifying IBM InfoSphereMasterDataManagementServersection intheIBM InfoSphereMaster DataManagementServerDevelopersGuide.

InfoSphere

MDM

Server

domains

IBM InfoSphereMasterData ManagementServerenablescompaniestoextract maximum valuefrommasterdatabycentralizingmultipledatadomains and providing acomprehensivesetofprebuiltbusinessservicesthatsupporta full rangeofmasterdatamanagement(MDM)functionality.

InfoSphere MDMServerintegratesdatafromdifferentdomains usingbusiness services thatinteractwithallapplicationsandbusinessprocessesthatconsume masterdata.Thesedomainsare:

(8)

PartyDomain

ThePartydomainmanagestheentiretyofdatarelatedtopartiessuchas customers, vendorsandsuppliers,and itmaintainsa single,consistent versionof thisdata.

Product Domain

TheProductdomainmanagesthedefinitionofproducts.Itscollection of productsmakesupaproductcatalogthatisaccessibletoothersystems acrosstheenterprise.

AccountDomain

TheAccountdomainisanoperational-styledhubthatmanagesaccount data.

The majorityofdomain featuresare alwaysavailableintheinstalledInfoSphere MDMServer product.Youcannotconfigurethemonoroff.Configurationbehavior informationisnotprovidedforsuchfeaturesbecauseit isnotapplicable.

Relatedconcepts

Chapter3, “ThePartydomain,”onpage55

ThePartydomainmanagestheentiretyofdatarelatedtopartiessuchas customers,vendorsand suppliers,andmaintainsasingle,consistentversionof thisdata.

Chapter4, “TheProductdomain,”onpage69

TheProductdomain isanoperational-styledhubthatmanagesthedefinitionof products.

Chapter5, “TheAccountdomain,” onpage77

Understanding

InfoSphere

MDM

Server

consumers

InfoSphere MDMServerconsumersarethemethodsthatinvoke InfoSphereMDM Server services.

For moreinformationaboutInfoSphereMDMServer consumers,seetheIBM InfoSphereMasterDataManagementServerDevelopersGuide.

The followingsectionsprovideunderstandingandplanninginformationfor InfoSphere MDMServerconsumers.

v “BatchprocessingusingMDMBatch” onpage11

v “WebServices” onpage20

Understanding

the

InfoSphere

MDM

Server

Request

Framework

The InfoSphereMDMServerRequestFrameworkprovidesa consistententrypoint toInfoSphere MDMServerand isusedtoreceiverequestsandissuesresponsesin anyformat.

For moreinformationabouttheInfoSphereMDMServerRequestFramework,see theIBMInfoSphereMasterDataManagementServerDevelopersGuide.

Relatedconcepts

“Compositetransactions” onpage9 “Request/ResponseFramework” onpage8

(9)

Chapter

2. InfoSphere

MDM

Server

platform

IBM InfoSphereMasterData ManagementServer(InfoSphere MDMServer)isan enterpriseapplicationthatprovides thesingle versionoftruthforparty,product and accountmasterdata,andan environmentthatprocessesupdatesto andfrom multiple channels,includingdatabases. Italignsthesefront officesystemswith multiple backofficesystemsinrealtime,providinga singlesourceofcustomer truth.InfoSphere MDMServerusesa component-basedExtensibleMarkup Language(XML)and Java™₂_Platform,_Enterprise_Edition_(J2EE)_with_full

EnterpriseJavaBean(EJB)architecturetorapidlyintegratewithothersystemsand deliverflexibilityandscalability.

InfoSphere MDMServercaneitherbe usedinitsstandardconfiguration,or modifiedthroughcustomization. YoucancustomizeInfoSphere MDMServer through anumber ofexternalizedfeatures—accessible tousers—thatcontrolits operation.

InfoSphere

MDM

Server

platform

technical

features

ThefollowingInfoSphere MDMServerplatformfeaturesaremainly aimedata technicalaudience.

Error

handling

and

logging

Throughloggingapplicationandsystem errors,youcan: v defineerrorsand howtheyarelogged

v customizeerrormessagessothattheyaremoremeaningfultoend-usersthan

theerrormessages thatare suppliedwith IBMInfoSphereMasterData ManagementServer

v

changethelevelofanerror, forexample,fromfataltowarning.

Error

handling

and

exception

logging

example

use

Youwanttousetheaddaddresstransactionaspart ofacompositetransaction. Normally, ifyouareenteringa contractrolelocationandenteredanaddress that was alreadyonfile,theaddtransactionwouldreturna fatalerrorandwouldfail, causingthewholecompositetransactiontofail.However, ifyousettheerrorto warning sotheaddtransactionreturnsawarningthattheaddressisalreadyon file,therestofthetransactionwillcontinue.Tosettheerrortowarningusethe varname tag.

Error

handling

and

logging

configuration

behavior

BehaviorWhenConfiguredOn

Errorhandlingandloggingdoesnotneedtobe configured.Errorscanbe definedandlogged, anderrormessagescanbecustomized

BehaviorWhenConfiguredOff

Errorhandlingandloggingdoesnotneedtobe configured.Predefined errorscanbe logged,andtheerrormessagessupplied withIBM InfoSphere MasterDataManagementServer canbeused.

(10)

BehaviorWhenConfigurationisChangedina ProductionEnvironment

Errorscanbe definedand logged,anderrormessagescanbe customized at anytime.

ConfiguredDuringInstallation

Errorhandlingandloggingcanbeconfiguredat anytime.

ModifyingThisFeature

Errorhandlingandloggingcanbemodifiedaccordingtotheproceduresin theConfiguringandusingMDMServererrorhandlingand loggingsection of theIBMInfoSphereMasterDataManagementServerDevelopersGuide.

Smart

Inquiries

The IBMInfoSphereMasterData ManagementServerimplementationonlyuses part ofitsdatamodel,.Thecoreproduct,however,doesnotdistinguishbetween theusedandunused partsofthedatamodel,sosomecompositetransactions—like getPartyand getContract—readdatafromtheunusedmodelpartsifthepassed-in inquiry levelincludesobjectsfromtheunused part.Thisresultsinredundant database I/O,becausethereadsneverreturn anydata.Thesameproblemdoesnot exist foraddandupdateoperationsastheseonlyperformaddorupdateI/Ofor theobjectspassed intherequest.

Using theSmartInquiriesfeature,youcanturnoffunusedpartsofthemodel. Whenthesepartsofthemodelareturnedoff,thecoreproductdoesnotissueany database I/Orequestagainstunusedtables,and doesnotaffectanyfunctionality around theusedpartsofthemodel.TheseSmartInquiriesimproveprocessing efficiency.

AfewoftheInfoSphereMDMServer built-ininquiry compositetransactions,such asgetPartyand getContract,accessnearlyallthefunctional partsof the

application. Whenunused partsofthedatamodelarenotturnedoff,these

transactionsdo notexecuteasefficientlyasthey dointhelimitedfunctionalityuse scenario.

Smart

Inquires

example

use

Youmight decidenottousethepartyfinancialprofileandpartyrelationships subjectareas,butyoustillwanttousetherestofthepartyobjects.Youcanuse Smart Inquiriestoturnofftheunused partsofthedatamodel.

Iftheunused partsofthedatamodelarenotturnedoff,whenyouusethe getPartytransactionatinquirylevel4,IBMInfoSphere MasterDataManagement Server issuesfiveSQLs—four forfinancialprofileand oneforrelationships—that are notrequiredforthetransaction.Ifyoudisablethesepartsofthedatamodel, thesamegetPartytransactiondoesnotreturnthesefiveunnecessarySQLs, reducingthetimeittakestoprocess thetransactionandloadonthesystem.

Smart

Inquires

configuration

behavior

Informationaboutunusedpartsofthedatamodelisnotreturnedin transactions.

(11)

Disablingpartsofthedatamodelcanbe changedatanytimewithout impactotherthanchanging thetransactionresponses.

Thisfeaturedoesnotneedtobeinstalled.

Disablingpartsofthedatamodelcanbe doneaccordingtotheprocedures intheModifyingInfoSphereMDMServertopicintheIBM InfoSphereMaster DataManagementServerDevelopersGuide.

Inquiry

levels

Defining inquirylevelsentails settingtheparametersthatdeterminethelevelof detail forobjectsbeingreturnedina searchorinquirytransaction.Definingthe inquirylevelsallowsnew combinationsofobjectstobe returned.Thecoreproduct businessobjectssupportedforinquiry-levelcustomizationarePerson,Organization and Contract.

IBM InfoSphereMasterData ManagementServeroffers avarietyofinquiry transactionsthatacceptoneormoreinquirylevelsasparameters.IBM InfoSphere MasterData ManagementServer usesthese parameterstoselectthecorrectobjects toreturn asapartofthetransaction.

Inquiry

levels

example

use

Thereare twocaseswhereyoucanconfigureanewchild objectfora parent businessobject:

v NewchildobjectsareaddedtothePerson,Organization,orContract objectsto

accommodateclientrequirementsforanadditionorextensiontotheIBM InfoSphereMasterDataManagement Serverproduct.

v AnexistingchildbusinessobjectofPerson,Organization orContractisnot

currentlybeingreturnedthroughitscoarse-grainedinquirytransaction—thatis, throughgetPerson, OrganizationorContract—foranyoftheproduct-defined inquirylevels,theextensionframeworkmayusedtoretrieveit asan extension. Theparentobjectcanalsobe configuredtoreturnthis childobjectfornew inquirylevels.

Inquiry

levels

configuration

behavior

Inquiries withvariouslevelscanbe run.

Inquirescanonlyhaveonelevel.

Inquirylevelscanbeconfiguredonoroffatanytimewithoutimpactother thanchangingthelevelofinquiry.

Inquiries donotneedtobeinstalled,howeveryoumust configureitin ordertousethelevelsof inquiry.

Inquiries canbe modifiedaccordingto theproceduresintheDefining InquiryLevels sectionoftheIBMInfoSphereMasterDataManagementServer DevelopersGuide.

(12)

Summary

Data

Indicators

SummaryData Indicatorsareusedtodynamicallyavoidreadingthedatabasefor partsofthemodelthatarenotrelevanttothecurrentbaseentitybeingread.By de-normalizing themodelandprovidingsummarydataindicatorsatthebasetable level, thesystem candecidewhetheritneedstoreaddatafromthechildtablesor not.Thissummaryindicatormustbe updatedwhenevera relevantchangeismade tothedatawhosesummaryisbeingtracked.

Summary

Data

example

use

An implementationof IBMInfoSphereMasterData ManagementServercanuse thepartyrelationshipsubjectarea,butrelationshipsmaynotbepresentforall parties.IfyouuseSummaryData Indicatorswhile doinga getPartytransactionfor a partywithnorelationships,thesystemdoesnotissuetheunnecessarySQLto read fromtherelationshiprecord.

Summary

Data

Indicators

configuration

behavior

Whenperformingatransaction,thesystemcanignore partsofthedata modelthatare notrelevant.

Whenperformingatransaction,thesystemreadsallpartsofthedata model.

SummaryData Indicatorscanbe configuredonoroffatanytimewithout impactotherthanchangingtheway thedatamodel isread.

SummaryData Indicatorsdoesnotneedtobe installed.

SummaryData Indicatorscanbe modifiedaccordingtotheproceduresin theCustomizingSummaryDataIndicatorssectionoftheIBMInfoSphere Master DataManagementServerDevelopersGuide.

Pluggable

primary

keys

Pluggable keysprovideasingle pointofentryfordefiningtheprimary keyfora record intoadatabase table.Youcanuseyour ownimplementationtocreatethe primary keyonspecific tablesoronalltables

Eachrecord intheMDMServerdatabaseforoperationaldatasuchascontact, product, andaddress,isidentifiedbyasingleprimarykey.Theprimary keycan be generatedbyoneof threemethods:

v

ByusingthedefaultkeygeneratorthatcomeswithMDMServer

v Byplugging inacustomkeygenerator

v

Bypassingaprimarykeywith theobjectintheservicerequest,knownasa

pluggableprimarykey

Pluggable

primary

keys

example

use

InfoSphere MDMServercanbe usedtomanage partiesthathaverelationshipsto creditcards.Ifthecreditcardsarestored ascontracts,youcanusetheprimary

(13)

pluggable primarykeyobjectonAddContractservicestoset thecontract_id tothe creditcardnumber,asopposedtousingthedefaultkeygeneratortogeneratea contract_id.

Pluggable

primary

keys

configuration

behavior

Thisfeaturedoesnotneedtobeconfigured on.Ifa pluggableprimarykey objectisprovidedinservicerequeststhenitwillbeusedastheprimary key.Ifthereisnopluggable primarykeyobjectisprovidedintherequest, then aprimarykeygeneratorwillbe used,whichwillbeeitherthedefault keygeneratororakeygeneratoryoucanpluginasanalternate.

Thisisnotnormallyafeature thatrequiresconfigurationchangeina productenvironment.Whileitispossibletopluginanew keygenerator implementationorstart usingthepluggableprimarykeyobjectinan existingproductionenvironment,caremustbe takenindoingsoassuming theimplementationalreadyhastakenintoconsideration apartitioningand clusteringstrategyformanagingdata.

Whenpluggableprimarykeysisconfiguredon,customizedidentifiers can be usedtoidentifynew partiesIfacustomized primarykeyisused, InfoSphere MDMServerdoesnotensurethattherearenoduplicatekeys.

Pluggable primarykeyscanbeconfiguredat anytime.

Pluggable primarykeyscanbemodifiedfollowingtheproceduresinthe

Configuringpluggable primarykeyssection oftheIBMInfoSphereMaster Data ManagementServerDevelopersGuide.

Service

Activity

Monitor

facility

TheServiceActivityMonitorfacility providesIBMInfoSphere MasterData Management Serverwith theabilitytoproduceandextractthedatanecessaryto generateManagement InformationSystem(MIS)reports.

InfoSphere MDMServerdoesnotprovidethereports,butthedatacapturedin InfoSphere MDMServerenablesreportstobegenerated.

For alltypesofInfoSphereMDMServer transactions,thereportingenablement feature cancaptureinformationsuchas:

v transactionname

v starttime

v sizeoftherequest

v

sizeoftheresponse

v transactionduration

v transactionoutcome

Youcanusethisinformationtoproducesystemreportsforcapacityplanningand identifying areasofoptimization,aswellasdemonstratinghowInfoSphere MDM Server servicesand transactionsarebeingusedina particularinstallation.

(14)

The impacttoperformanceisminimalandthedatacapturingprocessisableto support reportingonacyclicalbasis(suchasminute-by-minute,hourly,daily,or weekly).TheusercandefinethecycleatwhichInfoSphereMDMServer will capturethedata.

Note: Tolearnmoreaboutimplementingthisfeature,seetheIBMInfoSphere Master DataManagementServerDevelopersGuide.

Service

activity

monitoring

example

use

ABC InsuranceusestheServiceActivityMonitoringfacilitydailytoretrievethe activity feedsfromInfoSphereMDMServer.Thedataflowisasfollows:eachday, eachtransaction, requestand responsespecific dataarecapturedfromInfoSphere MDMServer feedsandsenttotheServiceActivityMonitoringfacility. Thedatais then madeavailableforreporting,soaDailyActivityReportbyUsercanbe generated.

Service

activity

monitoring

configuration

behavior

TheServiceActivityMonitoringfacilitycollectssysteminformation generatedbyInfoSphereMDMServer.

TheServiceActivityMonitoringfacilitydoesnotcollectanydata.

TheServiceActivityMonitoringfacilitycanbeconfiguredat anytime, but willonlycollect datafromthetimethatitisturnedonto thetimethatitis turnedoff.

TheServiceActivityMonitoringfacilitycanbeconfiguredat anytime.

TheServiceActivityMonitoringfeaturecanbemodifiedaccordingtothe proceduresintheIBMInfoSphereMasterDataManagementServerDevelopers Guide.

Request/Response

Framework

The Request/Responseframeworkprovidesa consistententrypointinto InfoSphere MDMServer.Itofferscommoninfrastructureservices-suchas authorizationchecking,transactiondemarcationandothers-for allincoming transactions.Itisextendablebecauseitsvariouscomponentsarepluggable.

Some ofthemaincomponentsthatmake uptheRequest/Responseframeworkare:

DWLServiceController

Astatelesssession EJBthatactsasthefaçadeforallincomingrequeststo theRequest/Responseframework.

RequestHandler

Contains thecontrollerlogicand dispatchestherequesttoother componentsforparsing,processing, andothers.

Parser Responsibleforparsingtheincoming requestand convertingitintoa formatunderstoodbythetargetenterpriseapplication.Forexample,inthe caseofanincoming XMLrequest, thisparserisresponsibleforparsingit intoobjectsasrequiredbythetargetapplication.

(15)

Constructor

Performstheoppositefunctionofparser, andconverts thedataformat returnedfromthetargetapplicationinto aformattobereturnedtothe client.

BusinessProxy

Thecomponentresponsibleforcommunicatingwith thetarget application, calledafter therequesthasgonethrough parsing.

TheRequest/Responseframeworkallowstheparser,constructor andbusiness proxytobe pluggable.Boththeparserand constructorhavecorresponding factory classes, whicharealsopluggable.Agivenimplementationcanhavemultiple instancesofthesecomponentsand useaninstance basedontheincoming transaction.

All IBMInfoSphere MasterData ManagementServer transactionsareaccessible through theRequest/Responseframework.Adefaultparserandconstructor are providedto handletheIBMInfoSphere MasterDataManagementServer XML transactions.Ifcustomrequestorresponseformatsareneeded,newparsers and constructorscanbedevelopedandplugged intotheframework.Adefaultgeneric businessproxy,DWLTxnBP,isalso provided.

Relatedconcepts

“UnderstandingtheInfoSphereMDMServerRequestFramework” onpage2

TheInfoSphereMDMServer RequestFrameworkprovidesaconsistent entry pointtoInfoSphereMDMServer andisusedto receiverequestsandissues responsesinanyformat.

Request/Response

Framework

configuration

behavior

TheRequest/ResponseFrameworkisalways availableintheInfoSphereMDM Server product.Itdoesnotneedtobeseparatelyinstalledorconfiguredinorder foryoutouseit.

TheRequest/Responseframeworkcanbemodifiedaccordingtotheproceduresin theConfiguringtheRequest/Responseframeworksectionof theIBM InfoSphereMaster DataManagementServerDevelopersGuide.

Composite

transactions

Acompositetransactionconsistsofaseriesof singletransactions.Thereare two methodsforcreatingcompositetransactions:

v Usingcustomizedbusinessproxies

v UsingXML Relatedconcepts

“UnderstandingtheInfoSphereMDMServerRequestFramework” onpage2

TheInfoSphereMDMServer RequestFrameworkprovidesaconsistent entry pointtoInfoSphereMDMServer andisusedto receiverequestsandissues responsesinanyformat.

Business

requirements

for

using

Composite

XML

transactions

Youcanconsiderusinga compositeXMLtransactiontogrouprelatedbusiness transactionsthatyouwantexecutedinoneunitofwork.Also, ifyouplanto implementsimple if-then-elseorloopinglogicamongthesetransactions,a CompositeXMLtransactionisalso agoodcandidate.TheCompositeTransaction Frameworkprovides syntaxinXMLformatthatyoucanusetocreatecomposite

(16)

However, sincesingletransactionsina compositeareexecutedinoneunitofwork, youshouldrefrainfromgroupingtoo manysingle transactionsinonecomposite. The moresingletransactionsthereare inthecomposite,thelongerittakesto completetheunitofwork,andthemorelikelyitisthatyouwillhavetransaction timeoutproblems.Therefore,itisrecommendedyouhavenomorethanfour single transactionsinacomposite.

Composite

Transaction

example

use

The followingare examplesofhow tousecompositetransactions.

Exampleuse ofacustomizedbusinessproxy:

Acompanyhasa client’sidentification numberandinformationfora newaddress, and wantstoupdatetheaddressinformationfortheclient.Forexample,the Ministryof Transportationreceivesa notificationofachangeofaddress froma driverwith thedriverlicensenumber xyz.

Toprocess thisrequest,theMinistryofTransportationmayneedtodo several things:

v

Findthedriverusingthedriverlicensenumberprovided

v IfthatdriverisregisteredwiththeMinistry,check toseeif hehasa mailing

addressalreadyentered.Ifhedoesnothavea mailingaddress,addthemailing addressasprovided.Ifhealreadyhasamailingaddress,updatethataddress withtheinformationprovided.

Before thecompanycanprocesstheaddress,firstthecompanyhastoquerythe back-officetofindthedriver,anddeterminewhetheritisnecessarytoaddor updatetheaddress.Thiswholeprocess encompassesa coupleofqueries and decisionmaking.

Onewaytosolve thisrequirement istoimplementa composite

updatePartyAddresstransactionatthebusinessproxylevel.Thisisimplemented byassociatinga customizedbusinessproxytothis transaction.Thisbusinessproxy contains thebusinesslogictosearchforthepartyand performamatchonthe address.Itthen determineswhetherthiscompositetransactionwillinvokean ″addPartyAddress″ oran″updatePartyAddress″transaction.

Exampleuse ofcompositeXMLtransactions:

Normally, whenyouare requiredtoupdatecertainattributesina Contractrecord (suchasContractAlert,Contract Components,Contract PartyRole, orContract PartyRoleLocation),youneedtoprovidetheuniqueContractIDalongandthe LastUpdate Dateoftherecordyouwanttoupdate.However, iftheonly informationyouhaveistheidentifierusedinanexternaladministrativesystem thatintegrates withIBMInfoSphere MasterDataManagementServer andthe administrativesystemtype, thenyoumustusea compositeXMLtransactionto perform theupdate.

The compositetransaction, namedupdateContractByAdminSysKey, mayinclude searchContractorgetContractAdminSysKey,getContract,updateContract, updateContractComponent,updateContractPartyRole,and

updateContractRoleLocation.

Ifnorecord ofthegivenobjectisfoundintheContractrecord,thiscomposite XMLtransactioninvokesanAddtransactioninsteadof anUpdatetransaction.

(17)

Composite

transactions

configuration

behavior

Compositetransactionsare alwaysavailableinInfoSphere MDMServer.Theydo notneedtobe separatelyinstalledorconfiguredinorderforyoutousethem. CompositetransactionscanbemodifiedaccordingtotheproceduresintheIBM InfoSphereMasterDataManagementServerDevelopersGuide.

Batch

processing

using

MDMBatch

MDMBatchisincludedwithin theIBMInfoSphereMasterData Management Server producttoyoutoperformbatchtransactionprocessing.

Using theMDMBatchframework, youcan:

v RunexistingInfoSphere MDMServertransactionsinabatchmodefor

ready-to-useinputandoutputfileanddataformats.

v Buildcustombatchjobstoexecutecustomtransactions,andtosupport custom

inputandoutputfilesanddataformats.

Example

use

of

batch

transactions

YoucanuseMDMBatchtoautomaticallyperformtasks onlargevolumesof transactions.Thefollowingsectionsshowexamples ofhowbatchtransaction processingcanbeused.

Synchronizingdata: AcreditcardcompanyhasimplementedIBM InfoSphere

MasterData ManagementServer.Aspartoftheintegrationstrategywiththe back-endsystems,a batchprocessiscreatedtosynchronizethecreditcardvalues, suchasoutstandingbalanceandotherinformation,withthevaluesthatare

duplicated withinIBMInfoSphere MasterDataManagementServer.Astandardfile formatiscreatedthatalloftheback-endsystemsmust adhereto.Itcontains: v CreditCardNumber

v ContractStatus

v ZeroormoreContractValue Type,ContractValuepairs

v

Forexample,″OutstandingBalance″,1200.30

v Forexample,″MinimumPayment″,50.00

v Forexample,″MinimumPaymentDueDate″,April10,2003

Thebatchprocess readsthefiledefinedabove.Foreachrecord, itfindsthe contract basedonthecreditcardnative key,updatesthestatusifrequired, and then updatescontractcomponentvalues.

v Batchruntype—ContractDataSync

v Filetypes:

– Incomingfile—Back-End ContractData

– Outgoingfile—ContractDataSyncResults

Itispossibletosendfiles fromdifferentback-endsystemsatanytime.Theydo not havetobe consolidatedintoonefileduring atraditionalbatchwindowat night.

UpdatingPartyaddresses: Everymonth,thepostofficeprovides afileofall

residentsthathavemovedinthepreviousmonth,theirnew address,andtheir previous address.Giventhatapproximatelytenpercentofall residentsmoveeach year,thefilecancontainhundredsofthousandsofrecords.Thepostofficedoes notexpectafileorreportinreturn.

(18)

Abatchprocess needstobe createdtoreadthrough thefile,determineifthe parties listedinthefileexist withinIBM InfoSphereMasterData Management Server, andiftheydo,and iftheinformationhasnotalreadybeen updatedby someothermeans,updatetheiraddresswiththenewaddress information. v Batchruntype—PostAddress Update

v Incomingfiletype—AddressUpdates

For eachrecordinthefile,thebatchtransactiontakesthefollowingsteps: v Searchthedatabaseforthepartyfromthelist,usingtheparty’snameand

previousaddress

v Ifapartyisfound,changetheparty’saddresstothenewaddress foreach

addressthatpartyuses

v AddonetoaPartiesUpdated counterforthecontrolreport

Once thefilehasbeenprocessed, thecontrolreportcontainingthenumberof parties inthefileand thenumber ofpartiesupdatedisissued byprintversionor e-mail.

Identifying suspectduplicateparties: Periodically,thedatabasemust besearched

for suspectduplicatepartiesthatmayneedtobe collapsedtogether.Aninquiry batchprocess needstobe createdthatscansa pre-definedrangeofpartiesandfor eachpartyitneedstosearchforsuspectduplicates andreportonthem.

v Batchruntype—SuspectDuplicate PartyInvestigation

v Outgoingfiletypes—IdentifiedSuspects(outgoingfile)

v Parameters—PartyIDStart;Max PartiesToProcess

The batchtransactionreadsthePartyIDStartandMaxParties ToProcess

parametersandexecutesa querytoreadpartyinformation,ordered bylastname startingwith thePartyIDStartparameter.Foreachparty,asuspectduplicate searchisperformedandallfoundsuspects(A1,A2,B)are writtentotheIdentified Suspects outgoingfile.

Once themaximum numberofpartieshasbeenprocessed,based ontheMax Parties toProcessparameter,thePartyIDStartparameterisupdatedin

preparationforthenext timethisbusinessrungetsinitiated.Thetotalnumberof parties processedand thetotalnumberofsuspectsfoundare reportedinthe Controlreport.

Batch

transaction

processing

configuration

behavior

WhenMDMBatchisconfigured,theselectedtransactionscanbeprocessed automaticallyinbatches.

WhenMDMBatchisnotconfigured,transactionsmustbe processed individually.

MDMBatchcanbeconfigured onoroffat anytimewithoutimpactother thanchangingtheabilitytoprocesstransactionsinbatches.

MDMBatchcanbeconfigured atanytime. TheBatchfunctionis customized usingthepropertiesfilesandit isaccessiblethrough a

(19)

commandlineinterface,whichallows systemsmanagement tools, includingschedulers,to startthebatchinanon-interactivemode.

BatchTransactionscanbemodifiedaccordingtotheproceduresinthe

ModifyingInfoSphereMDMServersectionoftheIBMInfoSphereMasterData ManagementServerDevelopersGuide.

Concurrent

Execution

Infrastructure

for

running

parallel

searches

Concurrent ExecutionInfrastructure,orCEI,providestheabilitytodopartyor contract searchesforoperationsthatexecuteat thesametimewithin themanaged environment oftheEJB container.CEIusesmultithreadingtoperform multiple searchessimultaneously,andthen combinestheresults.Searchesinparallelare done whenonetransactionexecutesmultiple readaccessoperationsagainstthe database.TheConcurrent ExecutionInfrastructurecanalsobe usedforother operations thatareindependentandsuitedtobe performedinparallel.

Concurrent

Execution

Infrastructure

example

use

TheCEIcanbe usedforlargeinstallations toincreaseIBMInfoSphere MasterData Management Serverresponsetimes.

Concurrent

execution

infrastructure

configuration

behavior

Multiple searchescanbecarriedoutatthesametime, andtheresultsof thesearchesarepresentedtogether.

Searchesmayonlybeperformedoneata timeand theresultsare presented separately.

Concurrent ExecutionInfrastructureconfigurationcanbechangedat any timewithoutimpactotherthanchangingthesearchcapability.

Concurrent ExecutionInfrastructuredoesnotrequireconfiguration.

Concurrent ExecutionInfrastructurecanbemodifiedaccordingtothe proceduresintheRunningtasksinparallelusingconcurrentexecution infrastructuretopicintheIBMInfoSphereMasterDataManagementServer DevelopersGuide.

Configuration

and

Management

Components

TheConfigurationandManagement componentssupporttheoperational

configurationandmanagement ofapplications.They enableadministrativeusersto deploy, fine-tune,and manageapplicationswithintheirruntimeenvironment. TheConfigurationandManagement componentssupporttheconfigurationand management ofbothstandaloneand enterpriseapplications.

What

are

the

Configuration

and

Management

Components?

TheConfigurationandManagement componentsarea seriesofdistributed componentsthatworktogethertorealizethefunctionsofconfigurationand management. Thesecomponentsare:

(20)

v ConfigurationRepository—Apersistentstorethatholdstheconfigurationfor

oneormanyapplications.Theconfigurationrepositorycandistinguishbetween manyinstallations ofthesameapplication-calleddeployments-andalso between multiplerunninginstancesofthesameapplications,andstoreseparate

configurationforeachof these.

v ApplicationConfigurationClient—Amodulerunningwithin thesame process

asthemanagedapplicationthatprovidestheapplication withread-onlyruntime accesstotheconfigurationstoredintheConfigurationRepository.

v

ManagementConsole—Athinclientapplicationthatprovidesapplication

administratorswitha text-baseduserinterfacethatenablesthemtomanipulate theconfigurationofvariousapplications.The consolesupportsbothinteractive andunattendedoperation.

v ManagementAgent—Aback-endsystemthatactsonbehalfoftheapplicationto

realizetheconfigurationandmanagementfunctionality.Themanagement agent supportsthedisconnectedoperationoftheConfigurationandManagement functionality,andthatofthemanagedapplication.

Who

can

use

the

Configuration

and

Management

Components?

The Configurationand Managementcomponentshavetwotypesofusers: v

Applications—Programmaticusersthatneedtoreadtheconfiguration

informationfromtheConfigurationRepository.Applicationsonlyrequire the presenceof theConfigurationRepositoryand theApplicationConfiguration Client.The ManagementAgentandtheManagementConsolearenotdirectly requiredfortheapplicationtofunction.

v Administrators—Humanusersthatneedtheabilitytoview andchangethe

configurationof theapplicationsthattheymanage.Administratorsusethe ManagementConsoleand theManagementAgenttoaccesstheConfiguration Repository.Themanagedapplicationsare notrequiredtobeoperationalatthe timewhentheirconfigurationismanaged.Iftheapplicationsareoperational, theManagementAgentinformsthemaboutanychangestotheirconfiguration sothattheycandynamicallyload thenew configurationvalues.

Configuration

Torecognizethedifferentsetsofrequirementsthatapplytoapplication

configurationbefore andaftertheapplicationhasbeendeployed intheoperational environment,configurationisdividedupintotwocategories:staticanddynamic. Configurationthatisintendedtobe modifiedonlyatapplicationdevelopment, assembly,ordeploymenttimeisconsideredtobestatic. Thiskindofconfiguration canonlybemodifiedbeforetheapplicationbecomesoperational. Changinganyof thestaticconfigurationparametersfundamentallychangestheapplicationand, therefore, wouldrequireitsredeployment.Newcodeorresourcescanbeaddedas a resultofchanging staticconfiguration. Consequently,theapplication wouldhave tobe rebuilt,retested,and redeployed.

Configurationthatcontrolsthebehavioroftheapplication whileoperationalis consideredtobedynamic.Theapplicationobservesand reactstochangesinits dynamicconfigurationwithouthavingtoberebuilt,retested orredeployed. Changes indynamicconfigurationdo notresult inapplicationresourceshaving to be added,changed,orremoved.

Note: Onlya limitedsetof configurationsettingsare availablethroughthenew ConfigurationRepositoryin bothIBMInfoSphereMasterData ManagementServer and InfoSphereMDMServer EventManager.Priorityhasbeen giventothe

(21)

dynamicconfigurationitemsthatneedtochangewhilethesystemisinoperation withouttheneedtorestarttheApplication. Moreconfigurationitemswillbe migrated infuturereleases.

Configuration DefinitionsandSchemas: Configurationdefinitionsare XML

documents thatcontainalltheconfigurationitemsand theirvaluesasdefined during thedevelopmentprocess.Thesedefinitionsarepackagedintheapplication archive. Theycanbemodifiedduringtheapplicationassemblyphaseand

repackaged withtheapplication.Atdeployment,theconfigurationdefinitions are usedtoestablishtheinitialconfigurationintheconfigurationrepository. Theycan also beusedasthevehicleforreplicatingexistingconfiguration.

Configurationdefinitionscancontainbothstaticanddynamicconfiguration.For an operationalapplication,theManagementConsoleonlyallowsadministratorsto changedynamicconfigurationitems.

Theconfigurationdefinitiondistributedwith theapplicationisconsideredto containthefactorydefaults fortheconfiguration.Anychanges tothis

configurationmaypotentiallybeoverwrittenbyupgradestosubsequent versions of theapplication.Users thatwishtochangetheirconfigurationwhile retaining factory defaultsshoulddosofromtheManagement Consoleafter theapplication (and itsconfiguration)isdeployed.

Configuration

and

Management

Components

configuration

behavior

IBM InfoSphereMasterData ManagementServerhasaccesstothefeaturesofthe ConfigurationRepository,ApplicationConfigurationClient,ManagementConsole, and ManagementAgentcomponents.

Configurationandmanagement componentsareinstalledwithmainIBM InfoSphere MasterDataManagement Serverinstallation.SeetheIBMInfoSphere Master DataManagementServerInstallationGuideformoreinformation.

Configurationandmanagement componentscanbemodifiedaccordingtothe proceduresintheUsing Configurationand ManagementComponentssectionof theIBMInfoSphereMasterDataManagementServerDevelopersGuide.

Data

validation

Data validationiscarriedoutondatasubmitted inIBMInfoSphere MasterData Management Servertransactionstoensurethatthedatasatisfiescertain

requirementsexpressedinvalidationrules. Datacanbevalidated bylevels,for controllerorbusinesscomponents,andbytypes,forinternalorexternaltypes. Data canbevalidated attwolevels:

v

Controllerlevel—Usedtoprocessasmanyvalidationsaspossibleat the

pre-transactionstage.Mostvalidationsareperformedatthecontrollerlevelas opposedtothebusinesscomponent-level,inordertoimproveperformance. v Businesscomponent level—Usedforvalidationsthatcanonlybe doneasthe

transactioniscarriedout.

Thereare alsotwotypesofvalidation:

v Internal—Tomaintain databaseintegrity.Thiscode isgenerallynotaccessibleto

(22)

v External—Validatescontent,andusesinformationaccessibleandmodifiableby

developersandadministrators.

The diagrambelow showshowthevalidationlevelsand typesworktogether.

Data

validation

example

use

The Controllerlevelvalidationsareusedforaccumulatingandreturningasmany errormessages aspossibleat thepre-transactionstageinordertoreducethe number ofvalidationsduringtheirsession,and improvetheperformance forusers. The Businesscomponentvalidationsare performedduring thetransaction. For example,whenan addpartyissuspectedtobe aduplicate,thesystemdoes additional businesscomponentvalidations.

Data

validation

configuration

behavior

Bothinternalandexternal validationcanbeconfiguredofforon.When configured on,dataisvalidated.

Bothinternalandexternal validationcanbeconfiguredofforon.When configured off,dataisnotvalidated.

Data validationcanbeconfigured onoroffat anytimewithoutimpact otherthanchangingthedatavalidation

Data validationcanbeconfigured atanytime.

Data validationcanbemodifiedaccordingtotheproceduresinthe

ValidatingDatasectionoftheIBMInfoSphereMasterDataManagementServer DevelopersGuide.

External

business

rules

External businessrulesarepiecesofbusinesslogicexternaltoIBMInfoSphere MasterData ManagementServer thatare incorporatedintoInfoSphere MDM Server transactionprocessing. Whileeveryconfigurationoption,validation requirement, orpropertyfileentrycouldbeconsideredanexternalrule,this section discussestherulesthatareusedforcomplexprocessingand

decision-making. Controller Level Component Level Validation Adapter Validation Engine External Validation Internal Validation Validator: MaxLen MaxVal ...

add data in database for the validation engine to dynamically invoke the validator, for business rules validation

validateUpdate (BObj)

Maintain data integrity in database validateAdd (BObj)

(23)

TheExternal RuleComponentisusedbyInfoSphereMDMServer whenit

performsa pieceofbusinesslogicaspart ofatransaction.Inperformingthatpiece of businesslogic,InfoSphereMDMServerknows whatdatamustbe providedand whatdatamustbe returned.Basedonthedatareturned,InfoSphere MDMServer canactconditionallyonit.

External

business

rules

example

use

Youcanuseasexternal ruletodefinethecriteriaforidentifyinga suspected duplicate-partymatching.Whenyouaddanew party,a searchisperformedto determineifthereareanysuspectduplicates ofthepartybeingadded.Onestep in thesuspect searchistomatchthenewpartyagainstthesuspectsfoundto

determinehowclosely theyrelate.Becausetherearedifferentmethodsfor matching parties,andthesemethodsmaychange,partymatchingisan externalizedrule.InfoSphereMDMServer knowsthatpartymatching mustbe done,whatdatamustbe providedtotheexternalizedmatching—asourceand target party—andwhatdataisreturned—matchand non-matchscores.The externalizedrulethatyoucreateforpartymatching determineswhatelementsare usedtomatchtheparties.Theseelementsarecalled criticaldata.Thematch relevancyscores relatedtothatcriticaldata—forexample,5points assignedtoa match,and-5 pointsassignedtoa non-match—arealso externalized,butina code table.

External

business

rules

configuration

behavior

External businessrulesarealways availableintheInfoSphereMDMServer

product. Theydonotneedtobe separatelyinstalledorconfiguredinorderforyou tousethem.

External businessrulescanbemodifiedaccordingtotheproceduresinthe

Configuringexternalbusinessrulessection oftheIBM InfoSphereMasterData ManagementServerDevelopersGuide.

Notifications

Notificationsareapplication-to-applicationmessages containingdatarelevantto specific eventsthathaveoccurred inthesendingapplication.InIBMInfoSphere MasterData ManagementServer,theNotificationManager componentisusedto send notificationmessages fromInfoSphereMDMServer todifferentdestinations, forexample,fromInfoSphere MDMServertoothersystemstolettheother systemsknowaboutcriticalpartydatachanges.Currently,theNotification Service usestheJavaMessageService(JMS)topublishmessagesto,forexample,WMQfor queuingtowhatever listenerapplicationssubscribe tothem.

Notifications

example

use

Thefollowingare examplesofhow thenotificationfeaturecanbe used: v Aspartofyourimplementation, itisrequiredthatifa party’slegalnameis

changed,thatchangemust bepropagated toanothersystem,alongwithsome otherpartydetails.Youhavedeterminedthatnoneofthenotificationsamples includedwith IBMInfoSphereMasterData ManagementServerproductcanbe used.Instead,anewnotificationcalled″legalnamechange″iscreated,and the contentforthatnotificationmessageiscustomized toincludethepartydetails required.

v Youhaverecentlyaddedanothermandatoryelementtotherequiredparty

(24)

information,youcancustomizetheerrornotificationtoinclude thiselementand displaythenotificationwhentheelementisnotenteredwiththeparty

information.

Notifications

configuration

behavior

Endusersreceivecustomizednotificationsoferrors.

Endusersreceivethegeneric notificationsincludedwith IBMInfoSphere MasterData ManagementServer.

Enduserswhopreviouslyreceivedthegenericnotificationsnowreceive thecustomized notifications.

Notificationscanbeconfigured atanytime.

Notificationscanbemodifiedaccordingtotheproceduresinthe

Configuringand implementingnotificationstopicintheIBMInfoSphereMaster DataManagementServerDevelopersGuide.

Security

service

InfoSphere MDMServersecurityserviceprovidesa frameworkforimplementing authentication andauthorizationservicesaswellasservices formanagingthe securitydata.Thischapterdiscussesconfiguringand administeringthesecurity service.

The securityservicehastwomaincomponents:

Runtimesecurityservices

Includes runtimeuserauthentication andresource,ortransaction, authorizationchecks.Thesesecurityservicesaresupportedusinga frameworkthatsecurityproviderscanbepluggedinto.Eachsecurity providerisresponsibleforperformingtheauthenticationand authorization checks,usuallyagainsta differentsecuritydatarepositoryorservice. Multiple securityproviderscanbe configured.

Securitydatamanagement

An administrationinterfacetomanagesecuritydataincludinguserand groupprofiles,aswellastheirauthorizationforvariousresources InfoSphere MDMServersecurityservicecomeswith twosecurityproviders:

Default securityprovider

Thisproviderusesthedatastored inarelationaldatabasetoauthorize usersandgroupsforincomingtransactions.

LDAP securityprovider

Thisproviderperformsthetransactional authorizationcheck againstan LDAPrepository.

Theseprovidersonlyimplementtheauthorizationcheck,and donotperform authentication.

Inadditiontothesecurityservice,asecuritymanagerisprovidedtoadminister thesecuritydatainarelationaldatabase.Thisisthesamerepositoryusedbythe

(25)

defaultsecurityprovidertoperformruntimeauthorizationchecks,however,the securityservicedoesnotsupportsecuritydataadministrationforLDAPrepository.

Security

Service

example

use

Default securityprovider

Youusethedefaultsecurityprovidertosetwhichgroupsandusersare authorized toperformspecificchanges tothedatawhenatransactionis run. Forexample,youcanusethissecurityprovidertoset whichusers havetheauthoritytomakechangestospecifieddata,andthen toensure thata userhaspermissiontoperform changestothedatawhena transactionisrun.

LDAP securityprovider

UsetheLDAPsecurityprovidertosetand checkwhichuserscanperform specific transactions.For example,youcanusetheLDAPSecurity Provider toset whichusershavetheauthoritytorunspecifiedtransactions,and then toensurethatauser haspermissiontoperformthosetransactions whenthetransactionisrun.

Security

Service

configuration

behavior

Whenauser attemptstoperformatransaction, asecuritychecksis performedtodetermineifthatuserisauthorizedtoperform that transaction. Iftheuser isauthorized, thetransactioniscompleted;ifthe user isnotauthorizedthetransactioniscancelled.

Nosecuritychecksare performedwhenusersperformtransactions.

SecurityServiceconfigurationcanbechangedatanytimewithoutimpact otherthanchangingthesecuritycheckcapability.

SecurityServicecanbeconfiguredat anytime. Seetheproceduresin the

Settingand administeringthesecurityservicetopicintheIBMInfoSphere Master DataManagementServerDevelopersGuide.

SecurityServicecanbemodifiedaccordingtotheproceduresintheSetting and administeringthesecurityservicetopicintheIBMInfoSphereMasterData ManagementServerDevelopersGuide.

Unique

and

persistent

ID

generation

TheExtended KeyGenerationframeworkprovides theability to:

v Generatedifferenttypesofidentifierssuchasnumeric,alphanumeric,numeric

stringandalphabetic

v Generatedifferenttypesofidentifiersof variablelength

v

Returna setofidentifiers insteadofasingle identifier

v AbilitytoplugcustomIDgenerators

(26)

Unique

and

Persistent

ID

generation

example

use

Afinancialinstitutionmightusethisfeature togeneratean enterprisePartyIDthat cana customercanusewhen loggingintothebankingsystem,insteadofusingthe number foraspecific account.

Unique

and

persistent

ID

generation

configuration

behavior

Unique andpersistentIDgenerationisalwaysavailable intheInfoSphereMDM Server product.Itdoesnotneedtobeseparatelyinstalledorconfiguredinorder for youtouseit.

Unique andpersistentIDgenerationcanbe modifiedaccordingtotheprocedures in theUniqueand persistentIDgenerationframeworktopicintheIBM InfoSphere Master DataManagementServerDevelopersGuide.

Web

Services

SupportforWebServicesinIBM InfoSphereMasterDataManagement Serveris currentlyavailable attwodifferentlevels:

v nativelyintheInfoSphere MDMServer EnterpriseApplication

v

throughtheInfoSphereMDMServer WebServicesAdapter

InfoSphere

MDM

Server

Web

Services

InfoSphere MDMServerWebServicesarean intrinsicpartoftheInfoSphereMDM Server enterpriseapplicationanddo notrequire additionaldeploymentor

configuration. Theoperationsmadeavailable throughtheWebServicesmap one-to-one withInfoSphereMDMServer transactions.

InfoSphere MDMServerWebServicesarecompliantwith theWS-IBasicProfile version 1.0.WSDLfilesthatdescribetheservicesare availablefromtheapplication serverafter theInfoSphereMDMServerenterpriseapplicationisdeployed.

InfoSphere MDMServerWebServicescanbeinvoked intwoways: v bydirectlysubmittingSOAPrequestsoverHTTP(S)

v byusingtheWSDLfilestogenerateclientcodeandthen programmatically

invokingtheoperations

InfoSphere MDMServerWebServicesarealways available,andcannotbe configured off.

Restriction: Asof thisrelease,onlya limitedset ofInfoSphereMDMServer transactionsare exposedthrough InfoSphereMDMServer WebServices.For details, pleaseseetheIBMInfoSphere MasterDataManagementServer release notes.

Web

Services

Adapter

The WebServicesAdapterisanadd-onwebapplication thatisdeployedand configured separatelyfromtheInfoSphere MDMServerenterpriseapplication. The WebServicesAdapterconsistsofoneWebServicewithasingle operationonly. ThisoperationallowsInfoSphereMDMServer XMLrequestsandresponsestobe tunneled throughSOAPmessagesoverHTTP(S). TheInfoSphereMDMServer XMLrequestsandresponsesare passed,as-is,toandfromtheServiceController.

(27)

Web

Services

Adapter

configuration

behavior

TheWebServicesinterface isavailable throughtheAdapter.

TheWebServicesinterface isnotavailablethrough theAdapter.

TheWebServicesAdaptercanbeconfiguredonoroffatanytimewithout impactotherthanchanging theaccesstotheWebServicesinterface.

TheWebServicesAdaptercanbeinstalledandconfiguredmanuallyat any time.

TheWebServicesAdaptercanbemodifiedaccordingtotheproceduresin theUsingthe externalWebServices AdaptertopicintheIBMInfoSphere Master DataManagementServerDevelopersGuide.

Tracking

IBM

InfoSphere

Master

Data

Management

Server

performance

IBM InfoSphereMasterData ManagementServerprovides theabilitytocapture performance statisticsfortheelapsedtimeofa transaction,includingthetimeit takes tocompletedifferentpartsofthetransaction.

Performance trackingisa configurableoption,andcanbe turnedonoroffthrough theAdministrationapplicationinterface.Aswellasenablingordisabling the collection ofperformancedata,youcanalso specifythelevelofdatacollected. See thePerformanceTrackingsectionoftheIBMInfoSphereMasterDataManagement Server SystemManagementGuideformoreinformation.

Tracking

Performance

example

use

Ifperformance loggingat Level2isturnedon,InfoSphereMDMServerlogs the elapsedtimestoperforman operationona businesscomponent, suchas

addParty(). Thebreakdownofthatoperation—validations,database access, extension,and externalserviceselapsedtimes—isalsologged.Thiscatalogingis madepossiblethrough theuseoftransactioncorrelators.

Tracking

performance

configuration

behavior

Whenperformancetrackingisturnedon,thePerformanceMonitor captureselapsedtimesforthefollowingcategoriesofa transaction dependingonthelevelchosen. Whenperformancetrackingisconfigured to:

Level 1

Measures theoveralltransactiontimefromthetimethethread enterstheapplication controller.

Level 2

Measures componentstransactiontime,validation, external

components,suchasTrillium andclientextensions, aswell aslevel 1 measurements.

(28)

Level 3

Measures theamount oftimeforDWLRequestHandler,

XMLRequestParserand XMLResponseConstructorcomponentto parseincoming XMLand toprepareXMLresponse, aswellaslevel 2 measurements.

Notrackingisperformed.

Ifperformance trackingisconfiguredon,performancedataisonly available goingforwardfromthepointthatthefeaturewas turnedon Ifperformance trackingisconfiguredoff,previouslycapturedperformance dataisavailable,butnonew dataiscollected.

Performance trackingcanbe configuredatanytime.

Performance trackingcanbe modifiedaccordingtotheproceduresinthe

TrackingPerformancesectionoftheIBMInfoSphereMasterDataManagement ServerDevelopersGuide.

InfoSphere

MDM

Server

platform

business

features

The followingInfoSphere MDMServerplatformfeaturesaremainly aimedata businessaudience.

Point

in

time

history

IBM InfoSphereMasterData ManagementServerhasanaudit,orhistory,database. The auditdatabase isa duplicateoftheoperationaldatabase (withtheexceptionof thecode/ruletables)with additionalauditattributes.Theaudittablesare

populated atthetimeof executionofanyIBMInfoSphere MasterData Management Servertransaction, viathedefaultsetoftriggersfortheIBM

InfoSphere MasterDataManagement Serverproduct.Thesetablesstoretheactual datathathasbeenaddedorupdatedinthetransaction.Inotherwords,usingthe audittablesmakesit possibletoseeexactlywhata party,forexample,looked like for agivenpointintime.

IBM InfoSphereMasterData ManagementServerallows anyinquirytransaction (get***)toreturn eithercurrentorpoint-in-timedata.Ifa valid<inquireAsOf> elementoccursintherequestcontrol, theget transactiontakesitsdatafromthe audittablesratherthantheoperationalones.

Relatedconcepts

“Historyinquirydaterangeimages”onpage23

Point

in

time

example

use

The pointintimehistoryfeaturecanbe usedtoreviewchanges toaparty’s informationovertime.For example,youcanusepointintimehistorytoreview when addresschangesfora specificpartywereentered,andwhatthosechanges were. PITcanbealsobe usedinconjunctionwith TAIL,tocreateanaudittrail showing whomadewhatchanges andwhen.

(29)

Point

in

time

configuration

behavior

Givesusersaccesstopoint intimehistory,whichprovidesa snapshotof whattheclientfile,ora portionoftheclientfile,lookedlikeasofa definedpoint(eithera singledateorrangeofdates)inthepast.

History inquiriesare notavailable,and theonlypartyinformation available istheinformationthatiscurrentlyinthedatabase.

Ifthehistoryinquirydaterangeimagesfeatureisconfiguredon,PIT historyisavailablefromthetimethefeature isturnedon-historicalqueries willnotshowchanges tothebusinessobjectsfrombeforethefeaturewas turnedon.

IfHistory DateRangeImagesisconfiguredoff,historicalquerieswillshow PIT historyuntil thetimethatthefeaturewasconfiguredoff,butnotafter this time.

Pointintimehistorycanbeconfiguredat anytime.However, inorderto havea completePIThistoryrecord,youmustconfigurethisfeature on during installation.

Pointintimehistorycanbemodifiedaccordingtotheproceduresinthe

Retrievingaudit, orpointintime,history sectionoftheIBMInfoSphereMaster DataManagementServerDevelopersGuide.

History

inquiry

date

range

images

Thehistoryinquirydaterangeimagesfeature retrievesPointInTime(PIT)history foreachchangethathasoccurredtopredefined businessobjects,within a

particulardaterange.Historicalqueries showhow datahaschangedovera set periodoftime. Thesequeries arerequiredfora numberofreasons,suchas: v Toauditdatachanges

v Toverifythatdatahasbeen changed

v Totrackthedatewhendatachanged

v Todeterminewhyaneffectivechange wasnotpropagated

InfoSphere MDMServerprovidestwosetsoftriggerswiththedatabase installation:

v Aset ofcompoundtriggers:CreateTriggers_compound.sql

v Aset ofsimpletriggers:CreateTriggers_simple.sql

Ifthecompoundtriggersare installed,eachoftheoperationaltableswithin the InfoSphere MDMServerproductdatabasehastwoactivetriggers.Ifsimple triggers areinstalled,eachof theoperationaltableswithin theInfoSphereMDM Server productdatabase hasonlyonetriggerforupdateactions. Formoredetailed information,seetheDatabaseconsiderationsforhistoryinquiry topicintheIBM InfoSphereMasterDataManagementServerDevelopersGuide.

Relatedconcepts

(30)

Definitions

The followinglistdefinesterms,acronyms, andabbreviationsrequiredto understandhistoryinquirydaterangeimages:

PIT PointInTimehistorytransactions;asnapshotofwhattheclientfile,ora portion oftheclient file,lookedlike asof adefinedpointintimeinthe past(inquireAsOfDate).

TAIL TransactionAuditInformationLog;thesubsysteminwhichinformationis recordedaboutthetransactionsexecutedwithin InfoSphereMDMServer. The termsimageandviewhavebeenadoptedwithin InfoSphereMDMServer to describethefollowing:

v Animageistheresultofone PIThistoryinquiry transactiontriggeredby

changesinoneormoreselectedobjectdrivers

v Aview isacollection ofimagesgatheredbetweentwoprovideddates—for

example,for thegetImagesByPartytransaction, eachoftheimagesreturnedare theresult ofapoint intimegetPartytransaction

The termhistorychangedrivershasbeenadoptedwithin InfoSphereMDMServerto describea setofpredefined objectsforaparticularview that,whenupdatedor changed,maytriggerthecreationofa newimageorview.

For moreinformation,seetheStoringandretrievingtheTransactionAuditInformation Log topicintheIBMInfoSphereMasterDataManagementServer DevelopersGuide.

History

inquiry

date

range

images

example

use

The historyinquirydaterangeimagesfeature allowsuserstoquerythehistory database:

v UsingapartyIDanddaterangetodeterminehowcontract partyrolesforthe

specifiedpartychanged duringthespecifieddaterange

v Usingacontract IDand daterangetodeterminehowcontractcomponents,

contractalerts,contractrelationships,contract partyroles, contractrolelocations, contractrolesituations, andcontractrole identifiershavechangedforthe specifiedcontractduring theprovideddaterange

History

inquiry

date

range

images

configuration

behavior

Givesusersaccessto:

v Pointintimehistory,whichisasnapshotofwhattheclientfile,ora

portionoftheclientfile,looked likeasofadefinedpoint-eithera single dateorrangeofdates-inthepast

v TransactionAuditInformationLog, whichisthesubsysteminwhich

informationisrecordedaboutthetransactionsexecutedwithin InfoSphereMDMServer.

v

AnimagethatistheresultofonePIT historyinquirytransaction

triggeredbychangesinoneor moreselectedobjectdrivers

v Aview thatisa collectionofimagesgatheredbetweentwoprovided

dates:forexample,forthegetImagesByPartytransaction,eachofthe imagesreturnedaretheresultof apointintimegetPartytransaction

History inquiriesare notavailable, andtheonlypartyinformation available istheinformationthatiscurrentlyinthedatabase.

IBM InfoSphere Master Data Management Server

InfoSphere

Master

Data

Management

Server

Version

8.5.0

Understanding

and

Planning

Guide

InfoSphere

Master

Data

Management

Server

Version

8.5.0

Understanding

and

Planning

Guide

Contents

Chapter

1.

Understanding

and

planning

to

use

IBM

InfoSphere

Master

Data

Management

Server

features

.

.

.

.

.

. 1

Chapter

2.

InfoSphere

MDM

Server

platform

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 3

Chapter

3.

The

Party

domain

.

.

.

.

. 55

Chapter

4.

The

Product

domain