Customize the InfoSphere Master Data Management classic party search capability

A step-by-step guide to leveraging extension attributes in deterministic party search

In this tutorial, use the data extension and pre-written SQL capabilities to create a custom search object and enable the use of the new party attributes as part of a classic party search service. You will use a scenario in which the search criteria to be added, as part of the pluggable SQL, are not available in the out-of-the box party search object. Therefore, additional Java development effort is required.

Share:

Bhavik Shah (bhavik.shah@in.ibm.com), Senior Staff Software Engineer, IBM China

Author photoBhavik Shah leads MDM initiatives for the Banking Frameworks and Solution Assets team and is based in the IBM India Software Lab. Over the past 7 years, he has received a number of internal IBM awards and has extensive experience with leveraging the following technologies in customer implementations: InfoSphere Master Data Management (MDM), InfoSphere MDM Collaboration Edition (PIM), WebSphere Experience Factory, Multi Channel Business Transformation Toolkit, WebSphere Portal, and Mobile Portal Accelerator.



24 January 2013

Before you start

Learn what to expect from this tutorial, and how to get the most out of it.

About this tutorial

Each company has different business requirements for its data, so the default data model underlying an IBM® InfoSphere® Master Data Management Server (InfoSphere MDM Server) implementation often does not capture all of the required party attributes. To manage this, InfoSphere MDM Server enables each customer to create party data extensions. A typical scenario requires that any new extension data can be used in searches for party data. This article provides the steps for creating a custom search leveraging these attributes in InfoSphere MDM Server.

Objectives

In this tutorial, you will use the entity extension and pre-written SQL capabilities of InfoSphere MDM to create a custom search object and enable the use of the new party attributes as part of the classic party search service. Specifically, the tutorial will take you through the process of creating an entity extension to the party search object, make modifications to the underlying pluggable SQL supporting classic search, and then test your solution reusing the existing searchPerson service.

Prerequisites

  1. Intermediate knowledge of InfoSphere Master Data Management Advanced Edition.
  2. Experience with SQL.
  3. InfoSphere Master Data Management (MDM) Version 9.0.x or higher and the accompanying InfoSphere MDM Workbench.
  4. Relational database management system such as DB2.

Assumptions

Readers of this tutorial should be comfortable with the process of creating entity extensions using InfoSphere MDM Workbench.


Understanding the classic Search framework

Understanding classic party search and the pluggable SQL capability

InfoSphere MDM Server provides the following features to enhance classic party search capabilities.

  • Common search exclusion
  • Maximum search result limit
  • Customizable search strategy
  • Internal search operations
  • Pluggable search SQL
  • Search result ranking and sorting
  • Configurable inquiry levels
  • Standardized (nickname) search
  • Phonetic search
  • Minimum wildcard length validation
  • Search result pagination
  • Tables
  • Links

This tutorial makes use of the pluggable Search SQL feature. You will use a scenario where the search criteria to be added as part of the pluggable SQL are not available on the out-of-the box party search object. Therefore, additional Java development effort is required.

You can also use this article for reference when setting up simpler pluggable search SQL scenario, and can skip any of the steps outlined here that are not applicable.

Before beginning the tutorial, it is important to understand the Search framework in InfoSphere MDM Server.

The Search framework is a lightweight framework comprised of interfaces and classes that can be classified into two main categories: SQL definition classes and SQL execution classes. See the Resources section for more information.

Note: This information can also be found in the "Understanding the Search framework" topic of the InfoSphere MDM Information Center. See the Resources section for more information.

Figure 1 shows the class diagram indicating the main classes and their associations that make up the Search framework.

Figure 1. Search framework class diagram
A class diagram that describes all the classes, interfaces, and their associations in the Search framework. Important execution classes and interfaces are ISearch, SearchComponent and IResultSetProcessor.

The following two types of classes are in the Search framework.

  • Execution classes are responsible for carrying out the execution of the search process. Examples of execution classes in the Search framework are ISearch, SearchComponent, IResultSetProcessor, and ISearchResultProcessor.
  • Definition classes provide information about the search criteria and its structure, search query, and the search result and its structure. Examples of definition classes in the Search framework are ISearchInput, SearchInput, Query, SearchSQL, CriterionElement, and SearchField.

Search definition classes

  • SearchSQL represents the SQL to be executed for the search transaction. This SQL can either be selected from a library of pre-written SQL statements or dynamically constructed using the search input class. Note: This tutorial uses the pre-written SQL approach.
  • SearchField represents a search field, which can be either your search criteria or a search result.
  • ComparisonOperator represents a comparison operator which is applied to the search field.
  • CriterionElement represents a search field as a criterion.
  • ISearchInput defines the interface to be implemented by any search input class. The interface provides methods to extract and standardize input parameters.
  • SearchInput is an abstract class which implements the ISearchInput. A search input class wraps the SearchBObj class. Each SeachBObj should have a SearchInput class.

Search execution classes

  • ISearch defines the search component interface to provide different search-related services, including fetching pre-written SQLs, finding a matching pre-written SQL, and executing a search SQL.
  • SearchComponent is an implementation of the ISearch interface.
  • IResultSetProcessor defines the contract that should be implemented by any search result set processor classes. The implementation class retrieves the output of the SQL and constructs a result object.
  • ISearchResultSetProcessor extends the IResultSetProcessor and implements the setSearchFields() to set the output fields.

For a detailed explanation of the these classes, refer to the "Understanding the Search framework" topic in the InfoSphere MDM Information Center. See the Resources section for more information.

SQL store

The Search framework stores all pre-written SQLs in the database. These SQLs are fetched and cached in the application. Figure 2 shows the tables and their relationships, which contain the SQLs.

Figure 2. SQL classes for pre-written SQLs
A data model diagram of the entire search framework related tables.

The following definitions describe the purpose of each of these tables.

  • The searchsql table contains references to the pre-written SQL statement stored in the sqlstatement table, the fully qualified search input class name (such as com.dwl.tcrm.coreParty.search.TCRMPersonSearchInput), and the fully qualified result set processor class name (such as com.dwl.tcrm.coreParty.component.TCRMPersonSearchResultSetProcessor) for each search transaction (such as Search Party By Last Name And Zip Code). Search transaction names are typically stored in the description field of the searchsql table.
  • The sqlstatement table contains the actual SQL statement that will be executed.
  • The searchcriterion table contains an ordered list of criterion fields for the given pre-written SQL.
  • The searchresultfield table contains an ordered list of search result fields for the given pre-written SQL.
  • cdcompoptp is a code table that contains the available comparison operators.
  • cdsrchfld is a code table that represents individual search fields that take part in the search transactions. These can be search input (criterion) or output (result) fields. If a search field is mapped directly to an attribute of a business object search or search result, then it is defined using the foreign key (application, group, and element) to the v_element table. All other search fields are defined using the srch_fld_name column. Each search field has a type as defined by the cdelementtp table.
  • cdelementtp is a code table that defines all available search field types.
  • v_element is a metadata table that defines all attributes of the business objects.

Note: Since you will be using pre-written SQL, this tutorial covers all of the following SQL tables: searchsql, sqlstatement, searchcriterion, cdcompoptp, cdsrchfld, searchresultfield, v_element, and cdelementtp.


Now that you have an understanding of the Search framework, the next step is to understand how to configure InfoSphere MDM Server for party searches.

Figure 3. Party search flow
Flow diagram of the search framework. Important steps are about defining an external rule and writing your own pre-written sql. The important steps to consider are the external rule and the client defined sql.

The following steps are required to create a customized search function that uses a custom search request object.

  1. Create a data extension to the Person entity (TCRMPersonBObj).
  2. Create a transient business object that extends the TCRMPersonSearchBObj business object.
  3. Create an interface that defines the search fields.
  4. Create a new SearchInput object that extends TCRMPersonSearchInput.
  5. Update the appropriate properties and XSD files to support the aforementioned extensions.
  6. Configure the classic search capability to leverage the new search attributes by updating the relevant database tables to hold the new pluggable SQL configuration.
  7. Extend the Search Party rule.
  8. Export and deploy the MDM.ear file.
  9. Test your extended search capability.

Note: You can easily customize the classic search capability leveraging the existing out-of-the-box attributes by starting with the Updating the Search framework configuration tables in the database section.

Extending the Person entity

Goal

Your aim is to create a party search function using client-defined attributes. This step is required to create attributes to use as search criteria.

Procedure

  1. Use the InfoSphere MDM Workbench to create a new InfoSphere MDM Server entity extension for the Person business object.

    Note: For more information about creating an entity extension, see the InfoSphere MDM Workbench User Guide.

  2. For the new entity extension, define two new attributes called BirthTown and Nationality.
  3. Name the new entity extension XPERSON.

Creating a transient search business object

Goal

When you call an inquiry transaction in InfoSphere MDM Server, you need to add an inquiry object to it. In this tutorial, you will create your own custom search business object called CustomPersonSearch class and use it in the transaction. You will later be extending this class with TCRMPersonSearchBObj. The search object holds only those attributes that will be used in the transaction.

Procedure

Create a new transient business object in the same project where you created the XPERSON entity extension for the Person object.

  1. Right click the CustomSearch folder and select New > Transient Data Object as shown in Figure 4.

    Figure 4. Selecting a new transient data object
    Shows how to select a new transient data object.
  2. In the Name field for the Transient Data Object, type CustomPersonSearch, as shown in Figure 5.

    Figure 5. The Name field
    Fill in the relevant details for the transient data object.
  3. Right click the CustomPersonSearch object and select New > Attribute, as shown in Figure 6.

    Figure 6. Selecting New Attribute
    Create a new attribute for the transient data object.
  4. In the Name field for Attribute, type birthTown, as shown in Figure 7.

    Figure 7. Filling in the Name field
    Enter the relevant details for the attribute.
  5. Similarly, create another new attribute (New > Attribute) and give it the name nationality, as shown in Figure 8.

    Figure 8. Adding the nationality attribute
    Add another attribute and fill in the relevant details.
  6. Save the file and click Generate implementation.
  7. Go to the newly generated class and replace TCRMCommon with TCRMPersonSearchBObj. This enables you to also use a combination of existing searchPerson attributes, if needed.

Note: Remember to remove the @generated tag or change it to a @generated NOT tag at the class level. Otherwise, you may accidentally overwrite any changes that you have made to the generated code.

Creating an interface for defining search parameters

Goal

Create a new constant class. A constant class defines the following.

  • The set of attributes that the internal SQL class will use to match against the SQL parameters defined in the request.
  • The set of attributes available in the searchCriterion table.

Procedure

Create a new constant class under the same project and package, as shown in Listing 1.

Listing 1. Sample code for this class
import com.dwl.base.search.SearchField;
public abstract interface CustomPartySearchFields
{
public static final SearchField PERSON_BIRTHTOWN 
	= new SearchField("TCRM", "CustomPersonSearchBObj", "BirthTown", 12);
public static final SearchField PERSON_NATIONALITY 
	= new SearchField("TCRM", "CustomPersonSearchBObj", "Nationality", 12);
}

Note: As per the documentation of a search field, the four fields are as follows.

  • Application type.
  • Group name (from v_group.group_name).
  • Element name (from v_element.element_name).
  • Element type. The element type is one of the java.sql.Types. Select the appropriate element type number based on the attribute and type.

Create a transient search input object

Goal

Create a TCRMCustomPersonSearchInput class. A search input class is responsible for sourcing the attributes for the search operation. Your search input class will hold an instance of the SearchBObj that defines these search attributes.

Procedure

Create a TCRMCustomPersonSearchInput class in the same project and package where the CustomPersonSearchBObj and constant class (CustomPartySearchFields) resides. This class will extend the TCRMPersonSearchInput class and implement with ISearchInput interface. Listing 2 shows the sample code for this class.

Listing 2. Sample code for the TCRMCustomPersonSearchInput class
import java.util.HashMap;

import com.dwl.base.search.interfaces.ISearchInput;
import com.dwl.tcrm.coreParty.search.TCRMPersonSearchInput;

public class TCRMCustomPersonSearchInput extends TCRMPersonSearchInput
		implements ISearchInput {

…
	private CustomPersonSearchBObj customPersonSearchBObj;
	
	public TCRMCustomPersonSearchInput
		(TCRMCustomPersonSearchBObj aCustomPersonSearchBObj)
	{
		super(aCustomPersonSearchBObj);
		setCustomPersonSearchBObj(aCustomPersonSearchBObj);
	}

	public int getMaxReturn() {
		// TODO Auto-generated method stub
		return 0;
	}

	public CustomPersonSearchBObj getCustomPersonSearchBObj() {
		return customPersonSearchBObj;
	}

	public void setCustomPersonSearchBObj(
			CustomPersonSearchBObj customPersonSearchBObj) {
		this.customPersonSearchBObj = customPersonSearchBObj;
	}

	
	 protected void buildSearchParams(HashMap aSearchParams)
	    throws Exception
	  {
		 super.buildSearchParams(aSearchParams);
		 //Add our new params to buildSearchParams List
	    addSearchParam(aSearchParams, CustomPartySearchFields.PERSON_BIRTHTOWN,
			getCustomPersonSearchBObj().getBirthTown());
		 addSearchParam(aSearchParams, CustomPartySearchFields.PERSON_NATIONALITY,
			getCustomPersonSearchBObj().getNationality());
	    }
}

Updating the properties and XSD files

Goal

InfoSphere MDM Server requires modifications to the XSD and properties files to account for new extension artifacts.

The InfoSphere MDM Workbench will update the XSD files automatically. The properties files, however, must be updated for your custom person search.

Procedure

  1. Open the CustomerResources folder and update the required files for the XPERSON extension created for person entity.

    Note: For the full list of files that must be updated, refer the InfoSphere MDM Workbench User Guide.

  2. Open the tcrm_extension.properties file.
  3. Add the lines shown in Listing 3 at the end of the file.
    Listing 3. Add to tcrm_extension.properties file
    ##### Start For Custom Person Search #####
    CustomPersonSearchBObj=com.ibm.mdm.sample.custom.search.component
    TCRMCustomPersonSearchInput=com.ibm.mdm.sample.custom.search.component
    ##### End of Custom Person Search #####

    Remember to include the correct package name, based on the location where you have created your code.

    Note: You do not need to add the element definitions for Nationality and BirthTown. They have already been defined by EXTPERSON. Adding the attributes twice would cause a fatal error at runtime when the request is run.

  4. Open the myTCRM.xsd file and go to the definition of the TCRMObject. Add the line, as shown in bold in Listing 4.
    Listing 4. The final TCRMObject in the myTCRM.xsd file should appear as follows
    <xsd:element ref="CustomPersonSearchBObj" minOccurs="1" maxOccurs="1"/>
    
    <xsd:element name="TCRMObject">
    	<xsd:complexType>
    		<xsd:choice minOccurs="1" maxOccurs="1">
    			.
    			.
    			.
    			.
    			<xsd:element ref="TCRMPersonSearchBObj" 
    				minOccurs="1" maxOccurs="1"/>
    			<xsd:element ref="CustomPersonSearchBObj" 
    				minOccurs="1" maxOccurs="1"/>
    			<xsd:element ref="TCRMOrganizationSearchBObj" 
    				minOccurs="1" maxOccurs="1"/>
    			<xsd:element ref="TCRMPartySearchBObj" 
    				minOccurs="1" maxOccurs="1"/>
    		.
    		.
    		.
    		</xsd:choice>
    	</xsd:complexType>
    </xsd:element>

Update the Search framework configuration tables in the database

Goal

The Search framework uses a set of configuration tables to view the pre-written SQL, its search criteria, its comparison operators, the search result, and the search fields to execute the SQL statement. You must also add the metadata for the objects, such as SearchBObj and Input classes, that you created.

Procedure

  1. Run the SQL statements shown in Listing 5 to add the metadata for the classes created earlier in this tutorial. Important: Before running the SQL, perform the following tasks.
    • Modify each statement with your schema name, the class name (if you have not used the one defined in above steps), and the element name.
    • Ensure that you use unique values for the primary keys and the values that you provide are not already in use.
    Listing 5. SQL to add the metadata for the classes
    INSERT INTO COMPONENTTYPE 
    (COMPONENT_TYPE_ID, DWL_PROD_TP_CD, COMPON_TYPE_VALUE,
     COMPON_LONG_DESC, LAST_UPDATE_DT)
     VALUES (<<component id of customer person search bobj>>, 1, 
     'CustomPersonSearchBObj', null, CURRENT TIMESTAMP);
    
    INSERT INTO V_GROUP 
    (GROUP_NAME, APPLICATION, OBJECT_NAME, LAST_UPDATE_DT, SORTBY) 
    VALUES ('CustomPersonSearchBObj', 'TCRM', 
    'com.ibm.mdm.sample.custom.search.component.CustomPersonSearchBObj',
     CURRENT TIMESTAMP, 'LAST_UPDATE_DT');
    
    INSERT INTO V_ELEMENT 
    (ELEMENT_NAME, GROUP_NAME, APPLICATION, ATTRIBUTE_NAME, 
    LAST_UPDATE_DT, RESPONSE_ORDER, ELEMENTAPPNAME, ELEMENTGROUPNAME, 
    DWLCOLUMN_TP_CD, CARDINALITY_TP_CD) 
    VALUES ('BirthTown', 'CustomPersonSearchBObj', 
    'TCRM', 'BirthTown', CURRENT TIMESTAMP, 10, null,  null,
     null, 1);
    
    INSERT INTO V_ELEMENT
     (ELEMENT_NAME, GROUP_NAME, APPLICATION, ATTRIBUTE_NAME, LAST_UPDATE_DT,
     RESPONSE_ORDER, ELEMENTAPPNAME, ELEMENTGROUPNAME,
     DWLCOLUMN_TP_CD, CARDINALITY_TP_CD)
     VALUES ('Nationality', 'CustomPersonSearchBObj',
     'TCRM', 'Nationality', CURRENT TIMESTAMP, 20, null,  null,
     null, 1);
  2. Run the SQL statements that the Search framework will use, as shown in Listing 6.

    Important: Before running the SQL, perform the following tasks.

    • Modify each SQL statement based on the package name and class name of the Search and Input objects.
    • Modify the element names if they are different.
    • Check the searchresultfield tables for given name1, given name2, given name3, given name4 and last name values defined. Based on those values, modify the searchresultfield statements.

    The alias given should be similar to any aliases used in your result set processor.

    Listing 6. SQL statements that the Search framework will use
    INSERT INTO SQLSTATEMENT VALUES (1001, 'SELECT XP.XPERSONPK_ID as CONT_ID, 
    PN.GIVEN_NAME_ONE AS GIVEN_NAME_ONE2, PN.GIVEN_NAME_TWO AS GIVEN_NAME_TWO2, 
    PN.GIVEN_NAME_THREE AS GIVEN_NAME_THREE2, PN.GIVEN_NAME_FOUR AS GIVEN_NAME_FOUR2,
     PN.LAST_NAME AS LAST_NAME2 FROM PERSONNAME PN, 
    XPERSON XP, CONTACT CT WHERE CT.CONT_ID=XP.XPERSONPK_ID 
    AND PN.CONT_ID=XP.XPERSONPK_ID AND XP.BIRTH_TOWN=? AND XP.NATIONALITY=?',
     CURRENT TIMESTAMP);
    
    INSERT INTO SEARCHSQL VALUES
     (1001, ‘com.ibm.mdm.sample.custom.search.component.TCRMCustomPersonSearchInput',
     1001, 
     'Configured for search using birth town and nationality attributes of the party', 
     'com.dwl.tcrm.coreParty.component.TCRMPersonSearchResultSetProcessor',
     'Y', CURRENT TIMESTAMP, 
     'com.dwl.tcrm.coreParty.component.TCRMPersonSearchRowHandler');
    
    INSERT INTO CDSRCHFLD VALUES
     (1001,'TCRM','CustomPersonSearchBObj',
     'BirthTown', NULL,1,CURRENT TIMESTAMP);
    
    INSERT INTO CDSRCHFLD VALUES 
    (1002,'TCRM','CustomPersonSearchBObj',
    'Nationality', NULL,1,CURRENT TIMESTAMP);
    
    INSERT INTO SEARCHCRITERION VALUES (1001, 1,1001 , 1, 'N', CURRENT TIMESTAMP, NULL);
    
    INSERT INTO SEARCHCRITERION VALUES (1001, 2,1002 , 1, 'N', CURRENT TIMESTAMP, NULL);
    
    INSERT INTO SEARCHRESULTFIELD VALUES (1001,1,50,CURRENT TIMESTAMP);
    
    INSERT INTO SEARCHRESULTFIELD VALUES (1001,2,51,CURRENT TIMESTAMP);
    
    INSERT INTO SEARCHRESULTFIELD VALUES (1001,3,52,CURRENT TIMESTAMP);
    
    INSERT INTO SEARCHRESULTFIELD VALUES (1001,4,53,CURRENT TIMESTAMP);
    
    INSERT INTO SEARCHRESULTFIELD VALUES (1001,5,54,CURRENT TIMESTAMP);
    
    INSERT INTO SEARCHRESULTFIELD VALUES (1001,6,55,CURRENT_TIMESTAMP);

Modify the search party rule

Goal

Since you have defined your own custom search business object and input classes, you must update the search party rule so that it can understand the request object that is being sent and call the appropriate methods. You must also write your own method that will call the Search framework classes to find the correct SQL statements based on the input.

Procedure

  1. Create a new class that extends the com.dwl.tcrm.externalrule.SearchParty.java rule.
  2. Override the execute method and include the code shown in Listing 7 in the execute method.
    Listing 7. Include in the execute method
    public class CustomSearchPartyRule extends SearchParty {
    
    	public Object execute(Object input, Object componentObject) throws Exception
      {
    		Vector searchVec = (Vector)input;
    		Vector searchResult = new Vector();
    		TCRMPartySearchBObj searchObj = 
    			(TCRMPartySearchBObj)searchVec.elementAt(0);
    		if(searchObj instanceof CustomPersonSearchBObj)
    		{
    			  searchResult = 
    				customPersonSearch((CustomPersonSearchBObj)searchObj);
    		}
    		else
    		{
    			searchResult = 
    				(Vector)super.execute(input, componentObject);
    		}
    	return searchResult;
    		
      }
    	
    	
    }
  3. Update the rule configuration tables in the database to point the new rule, as shown in Listing 8.
    Listing 8. Updating rule configuration tables
    update javaimpl set java_classname 
    	= 'com.ibm.mdm.sample.custom.search.component.CustomSearchPartyRule',
    	last_update_dt=current timestamp where ext_rule_impl_id=1008;
  4. Check to ensure you use the correct rule ID for the search party rule.

    Tip: When looking at the code, first locate the instance of CustomPersonSearchBObj. This is helpful because CustomPersonSearchBObj is extending the PersonSearchBObj.

  5. Implement the customPersonSearch method shown in Listing 9.
    Listing 9. customPersonSearch method
    protected Vector customPersonSearch(CustomPersonSearchBObj aSearchObj)
      throws Exception
      {
    		  Vector searchResult = new Vector();
    
    	    TCRMCustomPersonSearchInput searchInput = 
    			new TCRMCustomPersonSearchInput(aSearchObj);
    	searchResult = searchUsingPrewritten(searchInput);
          
    
    	    if ((searchResult != null) && (searchResult.size() != 0)) 
    		{
    	      TCRMPartyMatcherManager matcherManager = 
    			new TCRMPartyMatcherManager();
    	      IPartyMatcher partyMatcher = 
    			matcherManager.getPartyMatcher(aSearchObj.getControl());
    	      searchResult = 
    			partyMatcher.rankSearchResults(aSearchObj, searchResult);
    	    }
    	    return searchResult;  
    	}

Export and deploy MDM.ear

After completing your search customizations, you need to export and deploy the updated EAR file for deployment.

For details on exporting and deploying MDM.ear, see the InfoSphere MDM Workbench User Guide.

Run the search example

Goal

Verify that you can search for a person based on the newly defined custom attributes.

Procedure

  1. The samples could be executed using various methods. A Test Client is shipped with the product installation which can be used to execute the XML Requests, as shown in Listing 10. See the Resources section for a link to the "Verifying the installation" topic in the InfoSphere MDM Information Center.
    Listing 10. Sample request
    <?xml version="1.0" encoding="UTF-8"?>
    <TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="MDMSampleHubRequest.xsd">
        <RequestControl>
            <requestID>10015</requestID>
            <DWLControl>
                <requesterName>cusadmin</requesterName>
                <requesterLanguage>100</requesterLanguage>
            </DWLControl>
        </RequestControl>
        <TCRMTx>
            <TCRMTxType>searchPerson</TCRMTxType>
            <TCRMTxObject>CustomPersonSearchBObj</TCRMTxObject>
            <TCRMObject>
                  <CustomPersonSearchBObj>
                     <BirthTown>Bangalore</BirthTown>
                     <Nationality>Indian</Nationality>
                  </CustomPersonSearchBObj>
            </TCRMObject>
        </TCRMTx>
    </TCRMService>
  2. Ensure that the returned results are as expected. You should either get a returned result if any matching records are found, as shown in Listing 11, or a “no records found” message, as shown in listing 12.

    Listing 11. Sample result when a matching record is found
    <?xml version="1.0" encoding="UTF-8"?>
    <TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="tCRMResponse.xsd">
    	<ResponseControl>
    		<ResultCode>SUCCESS</ResultCode>
    		<ServiceTime>8422</ServiceTime>
    		<DWLControl>
    			<requesterLanguage>100</requesterLanguage>
    			<requesterLocale>en</requesterLocale>
    			<requesterName>cusadmin</requesterName>
    			<requestID>10015</requestID>
    		</DWLControl>
    	</ResponseControl>
    	<TxResponse>
    		<RequestType>searchPerson</RequestType>
    		<TxResult>
    			<ResultCode>SUCCESS</ResultCode>
    		</TxResult>
    		<ResponseObject>
    			<TCRMPersonSearchResultBObj>
    				<ComponentID>1014</ComponentID>
    				<PartyId>911111112</PartyId>
    				<GivenNameOne>RAHUL</GivenNameOne>
    				<LastName>SHAH</LastName>
    				<ResultNumber>1</ResultNumber>
    				<ResultScore>0</ResultScore>
    				<ResultsFound>1</ResultsFound>
    			</TCRMPersonSearchResultBObj>
    		</ResponseObject>
    	</TxResponse>
    </TCRMService>
    Listing 12. Sample result when no record is found
    <?xml version="1.0" encoding="UTF-8"?>
    <TCRMService xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="tCRMResponse.xsd">
    	<ResponseControl>
    		<ResultCode>FATAL</ResultCode>
    		<ServiceTime>1281</ServiceTime>
    		<DWLControl>
    			<requesterLanguage>100</requesterLanguage>
    			<requesterLocale>en</requesterLocale>
    			<requesterName>cusadmin</requesterName>
    			<requestID>10015</requestID>
    		</DWLControl>
    	</ResponseControl>
    	<TxResponse>
    		<RequestType>searchPerson</RequestType>
    		<TxResult>
    			<ResultCode>FATAL</ResultCode>
    			<DWLError>
    				<ComponentType>1</ComponentType>
    				<ErrorMessage>No record is found.</ErrorMessage>
    				<ErrorType>READERR</ErrorType>
    				<LanguageCode>100</LanguageCode>
    				<ReasonCode>794</ReasonCode>
    				<Severity>0</Severity>
    			</DWLError>
    		</TxResult>
    	</TxResponse>
    </TCRMService>

Conclusion

This tutorial outlined one of the basic methods to enable searches for extended attributes using the InfoSphere MDM Server Search framework. This tutorial showed the process of creating customized search fields, search input classes, and search party rules.

As you saw in this tutorial, the underlying data model can be quickly extended to search for a party using custom-defined attributes. The Search framework’s power and flexibility is evident when you realize how easily it can be extended using pre-written SQL, the Search framework data model, and the related classes and associations.

Acknowledgements

The author would like to thank Catherine Griffin and Peter Londry for their very valuable technical guidance. The author would also like to thank Stephanie Hazlewood and Michael Adams for the ongoing review throughout the production of this article and providing significant feedback. Additional thanks are also due to Lena Woolf, Jane Shi, John Thomas, and Wei Zhang for reviewing this article and providing their comments and insight.


Download

DescriptionNameSize
Code sampleCustomerSearchSample.zip---

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=855543
ArticleTitle=Customize the InfoSphere Master Data Management classic party search capability
publish-date=01242013