When configured to work with getSimilarObjects SOAP web service, special considerations should be made for the Find Similar solution's match codes and matching algorithm.
Important: A getSimilarObjects request (SOAP) can only return ninety-nine results at a time.
Match Codes
Attribute value binds in the match code definition should be created specifically for getSimilarObjects SOAP cases. For example:
if ( node == null ) {
//generate matchcodes for getSimilarObject
}
else {
//generate matchcodes for existing objects
} Note: When used for getSimilarObjects, it is safe to establish large match code groups without impacting performance.
For more information, refer to the Match Codes topic here.
Matching Algorithm
Matching algorithm global binds should be configured to map the attributes used in the SOAP request. 'Mcevaluate' / 'evaluate' should be used in the match criterion’s STEP function / JavaScript function to retrieve these values when the current object returns null.
Note: It is recommended practice to use the decision table match criteria for this purpose.
When decision tables are used as the match criteria, any configured party data normalizers require that all configured attributes also exist as global binds. This applies to both explicitly configured attributes and for those configured via component models.
So, for example, if the Address Normalizer is used for getSimilarObjects, the country, region, city, postcode, and street attributes must have corresponding global binds.
Important: For customer data normalizers, the name of the global bind must match the ID of the corresponding attribute.
Customer data normalizers are compatible with getSimilarObjects so long as global binds are set on the matching algorithm. For more information on global binds and match criteria, refer to the Configuring Matching Algorithms topic here.