Configuring Quality Stage

To configure quality stage

update configelement set value='true' where name = '/IBM/DWLCommonServices/Standardization/enabled';

update db2admin.configelement set value = 'http://100.100.100.100:1000'  where  name = '/IBM/ThirdPartyAdapters/IIS/providerURL';

update db2admin.configelement set value = 'com.ibm.mdm.thirdparty.integration.iis8.adapter.InfoServerStandardizerAdapter'  where  name = '/IBM/Party/Standardizer/Address/className';

Configuring the Maximum Search Result Limit

You can configure the maximum number of results that are returned by a search.

Before you begin

That maximum number of results returned in a SearchParty, SearchPerson and SearchOrganization transaction is configurable at a global level. The configuration can be overridden at a transaction level as long as the transaction maximum search result limit is less than the global setting.

About this task

The default global setting is 100 returns.

To change the default number, change the /IBM/Party/Search/maxResults configuration element in the Configuration Manager.

Understanding the InfoSphere MDM Probabilistic Matching Engine data model

The InfoSphere® MDM Probabilistic Matching Engine uses Person and Organization functions to compare party records and determine their degree of similarity. However, the parties that are being compared must also be defined formally in the InfoSphere MDM Probabilistic Matching Engine data model.

The InfoSphere MDM Probabilistic Matching Engine data model is defined using three constructs:

• Records – An entity being compared; such as a person or an organization. A record is divided into attributes.
• Attributes – A major identifying component of a record. For example, an address or a name represents an attribute of a record. An attribute is further subdivided into fields.
• Attribute fields – A data component of an attribute. For example, an address can consist of a street name and number, a city, a province or state, a country, and a postal code.

The figure above represents the default InfoSphere MDM Probabilistic Matching Engine data model definitions for the Person and Organization entities and their constituent attributes that are assigned to matching functions. These correspond to the Person and Organization party entities in InfoSphere MDM Server. Also illustrated is a subset of attributes that comprise each record type.

The full data models for both Person and Organization consist of many more fields that are not assigned to matching functions. For a complete listing of the attributes comprising the InfoSphere MDM Probabilistic Matching Engine data model, see the section Mapping InfoSphere MDM Server business objects to the InfoSphere MDM Probabilistic Matching Engine data model.

Configuring SDP

Enabling or disabling Suspect Duplicate Processing

A property in the InfoSphere® MDM Server Configuration and Management component controls whether Suspect Duplicate Processing runs when processing an addParty or updateParty transaction. You can use this property to configure whether Suspect Duplicate Processing runs during the addParty and updateParty transactions for Person parties, Organization parties, neither, or both.

In the InfoSphere MDM Server Configuration and Management component, modify the value of the /IBM/Party/SuspectProcessing/enabled configuration element to one of the following values:

• false – Disables SDP for both Person and Organization parties.
• true – Enables SDP for both Person and Organization parties.
• TCRMPersonBObj – Enables SDP for Person parties only.
• TCRMOrganizationBObj – Enables SDP for Organization parties only.

Extension condition parameters

When you define and describe an extension in the extension framework, you can also specify condition parameters that must be true for the extension to be executed.

The following lists some of the possible condition types along with their description.

Condition types and their condition categories can be customized by modifying the CDCONDITIONTP code table. For information on adding or editing code table values, see Code tables and error messages.

• Action Category: Reserved for a future release.
• Action Type: Reserved for a future release.
• Company: Limits the extension execution to only those transactions whose <company> field in the XML header (Control) matches the value you specify here.
• Geographical Region: Limits the extension execution to only those transactions whose <geographicalRegion> field in the XML header (Control) matches the value you specify here.
• Line Of Business: Limits the extension execution to only those transactions whose <lineOfBusiness> field in the XML header (Control) matches the value you specify here.
• Transaction Category: Applies the extension to a whole category of transactions. Choose from the following values: inquiry, persistence, or all. If you select a transaction category, the Transaction Type condition must be left blank.
• Transaction Type: Applies the extension to only to a specific transaction. If you specify a transaction name, the Transaction Category condition must be left blank. Transaction names are the names ofIBM® InfoSphere Master Data Management controller methods that perform the transaction processing. They are contained in <TCRMTxType> or <InquiryType> tags in the transaction XML messages. For more information see the reference topics about external lists of transactions and in the various Controller Methods sections of the TCRM.properties file.
• Trigger Type: Specifies at what point during the transaction processing the extension is to be executed. You can choose from the following options:
  • Post Action: Executes after all of the Component level transaction processing has been completed.
  • Post Transaction: Executes after all of the Controller level transaction processing has been completed.
  • Pre Action: Executes before all of the Component level transaction processing has been completed.
  • Pre Transaction: Executes before any of the Controller level transaction processing has begun.

MDM Architecture

MDM Controller Transaction Skeleton implementation

Example skeleton implementation for a component

Creating a new component transaction in the hub module editor results in the MDM Workbench generating new methods in the relevant component class to implement the transaction.

For example:

• A new component transaction SampleTxn is created in the model: /SampleModule/SampleFolder/SampleTxn
• This results in extra methods being generated in the component .java file: /SampleModule/ejbModule/com.example.samplemodule.component/SampleFolderComponent.java
• If SampleTxn is a txn transaction, the new methods added to the SampleFolderComponent class are SampleTxn and handleSampleTxn.
• If SampleTxn is an inquiry transaction, then the additional method beforePreExecuteSampleTxn is also generated.

When the MDM Workbench generates code, it puts an @generated tag in the javadoc for each method to indicate that the method was generated by the MDM Workbench. When the workbench generates new code, it overwrites any methods which have the @generated tag. If you customize the generated methods, you must remove the @generated tag or change it to @generated NOT so that the MDM Workbench will not overwrite the changes you have made.

The MDM Workbench generates a stub for the beforePreExecuteSampleTxn, to which argument validation logic should be added.

The sampleTxn method includes some logging and input data preparation. Usually modifications to this method are not required.

The handleSampleTxn method implements the actual logic of the transaction. This method must be customized to add the desired business logic.

For an inquiry transaction, handleSampleTxn accepts the parameters to the transaction and a DWLControl object as arguments. For a txn transaction, handleSampleTxn accepts the input business object as its sole argument.

The transaction handleSampleTxn returns an output business object that will then be returned to the user in the transaction response.

The MDM Workbench will generate MDM_TODO comments throughout the generated code to indicate where changes or additions to the code should be made.