Member search

To get a 360-degree view of John Bach, the surgeons approached the IT department at Get Well Hospital, who first made a preliminary search for John Bach's profile using a member search interaction by specifying some basic criteria.

This search resulted in a list of members that matched the criteria.

You can use the member search interaction object IxnMemSearch to return a list of member rows that fit a list of search criteria. For instance, the member search Java example shows a legal name search for another member whose name is Norman.

Note: A minimum score (minscore) setting of 0 previously meant that all scores were considered during a member search interaction. Thus, all potential candidates were returned in the search regardless of score. This behavior lead to unnecessary I/O, which had a negative impact on performance. The operational server logic was modified such that a minscore of 0 now returns only members that score at or above 0. If a user needs to return all candidates, a large negative score such as -999 can be used.

When composite views are implemented, the member search results return the originating row identifier for each view attribute so that the lineage of each attribute value can be traced. For example, your MDM database has the following member information.

Table 1. Member information stored in the MDM database
Member record number Entity ID Source Attribute Modified date
1 10 A Name 2014-03-05
1 10 A Phone 2013-12-15
2 10 B Name 2013-10-10
2 10 B Phone 2014-01-15
In most cases, you expect to see a single row returned in a member search. However, with composite views, search results for this example returns multiple rows.
  • Row 1: Member 1, Name (from Source A, because it is the most current attribute)
  • Row 2: Member 2, Phone (from Source B, because it is the most current attribute)