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.

MDM Notification Framework and Types of Notification

Notification types and contents

Notification messages are constructed based on the notification type. A number of notification types are provided with InfoSphere® MDM out-of-the-box.

The existing notification business objects are defined as OSGi services using the CommonServiceFactory service pattern. The following are the default notification types.

NotificationType.nt1=com.dwl.tcrm.coreParty.notification.A1PartySelectedNotification
NotificationType.nt2=com.dwl.tcrm.coreParty.notification.SuspectIdentificationNotification
NotificationType.nt3=com.dwl.tcrm.coreParty.notification.AutoSuspectReIdentificationNotification
NotificationType.nt4=com.dwl.tcrm.coreParty.notification.ManualSuspectEntryAdjustmentNotification
NotificationType.nt5=com.dwl.tcrm.coreParty.notification.ElementChangeNotification
NotificationType.nt6=com.dwl.tcrm.coreParty.notification.DeletePartyHistoryNotification
NotificationType.nt7=com.dwl.tcrm.coreParty.notification.PendingCDCRequestNotification
NotificationType.nt9=com.ibm.mdm.suspect.notification.EntitySuspectNotification
NotificationType.nt10=com.ibm.mdm.suspect.notification.EntitySuspectNotification
NotificationType.nt11=com.ibm.mdm.suspect.notification.EntitySuspectNotification

Here is a sample blueprint service definition of a notification type:

<service id="A1PartySelectedNotification" interface="com.ibm.mdm.common.servicefactory.api.CommonServiceFactory">
  <service-properties>
   <entry key="common.service" value="NotificationType.nt1"/>
  </service-properties>
  <bean class="com.ibm.mdm.common.servicefactory.CommonServiceFactoryImpl">
   <argument type="java.lang.Class" value="com.dwl.base.notification.CommonNotification"/>
   <argument type="java.lang.Class" value="com.dwl.tcrm.coreParty.notification.A1PartySelectedNotification" />   
   <argument ref="blueprintBundle"/>   
  </bean>
 </service>

The following table shows the information included within each type of notification object:

Table 1. Information included with each notification object

Notification Type	Notification Value	Information Included
nt1	A1 Party Selected	Details of original source party passed to Add Party transaction Details of A1 matched party selected List of other A1 matched parties found (exceptional case)
nt2	Suspect Identification	Source party Suspects marked to source party
nt3	Auto Suspect Re-identification	Reason for Re-Identification (critical data change | critical data add | collapse parties | split party) Before/After image if critical data change Image if critical data add Source party New suspects to source party created Existing suspects to source party updated Deleted suspects
nt4	Manual Suspect Entry Adjustment	Source/Target Parties Before Status After Status
nt5	Element Change	Element Name Element Identifier Before and After Images of Element's Value.
nt6	Delete Party History	Note of ‘Party history has been deleted for this party'. PartyId Additional Information
nt7	Pending Critical Data Change Request	Element name Before update After update
nt9	Update Product Suspects	Source product List of suspects before update List of suspects after update
nt10	Delete Product Suspects	Source product List of deleted suspects
nt11	Add Product Suspects	Source product List of added suspects
ntem	Event Manager to the Topic	Notification message for the happened Event