xDM

Semarchy REST Client + Excel Matching Solution

Using Semarchy's REST client, potential matches can be validated from an Excel spreadsheet by using queryPotentialMatches. 

Business Use Case: External business users (no direct access to Xdm hub) want to validate if provided member data matches existing data in the hub. This is a "validation-only" procedure, so no data will be saved/committed during processing. External users will provide Semarchy Xdm DataStewards a spreadsheet containing data to be validated. Once validated, the enhanced data is sent back to the originating requestor. 

Solution details: 

Our solution is based upon the Customer B2C model. Customers wishing to implement this solution should complete the Customer B2C tutorial as a prerequisite. Datasets provided in the Customer B2C tutorial are needed in order for this solution to work, and should be imported into the application once the new model (attached) is deployed. The provided solution extends the basic functionality of the Customer B2C model by incorporating a REST client, the main object used. Additionally, several custom model objects were created in order to support use case requirements. Our documentation includes a brief explanation of the individual components used, as well as the modified Customer B2C model and Rest Client .json file. Import the model and REST Client file (both attached to the Question section) in order to implement this solution. The intended purpose of the solution is to provides guidance on implementing the Semarchy REST Client to support Matching operations.

Solution Main Components

   1. REST Client

• REST Client calls our API based on a load. Load Id is passed and is needed in order to execute the Detect Matches query.
• REST Client is used in an enricher that is called during the stepper on import
• For load id, we use the v_loadid variable in order to specify the current load id. Needed since the operation is triggered in a Stepper.
• Sourceid must be provided (any value will work) since MasterRecordID is not automatically generated.
• Based on our requirements, persistMode is set to "Never" to ensure data is never persisted.
• Source Email is an input, and is also used in the body.
• As an output, we will enrich the HighestMatchScore attribute. HighestMatchScore is an Integer, it must be compatible with the Enricher, which uses Number for its output.
• Line 7 calls CleanseEmail Enricher
• Line 8 calls queryPotentialMatches api and "true" flag enables query to run against all entity Matchers

2. DetectMatches REST Client Enricher. Enricher is configured to call the "detect matches" REST Client. Inputs are load_id and source_email. Outputs is HighestMatchScore. No job is run with this enricher, it runs on the fly during Stepper. Highest Match Score attribute is populated using REST Client. A value of "0" indicates no match, while a non-zero value represents the match score of the best match.

3. ExternalMatch Stepper contains a step trigger (HighestMatchScore) which calls our DetectMatches REST Client enricher. Stepper contains Job "INTEGRATE NONE", which has no associated tasks. The purpose for this job is to act as a failsafe against anything being processed after data is imported for validation. If a used clicks the "Finish" button after import, this empty job will ensure the validated data is not saved into the hub and instead will simply be discarded.

Solution In Action

1. Using the Detect Matches menu item, we import a spreadsheet containing a single column (SourceEmail). One of the source emails will match an existing member, while the second will not.

      2.  Highest Match Score attribute is added to the view by the REST Client, and values are populated based on the highest match score for each Source Email. Match was found for the first member, but not the second (tutu@tata.com). Clicking on the Finish button will not result in data being committed to the hub. The view can now be exported to a new Excel spreadsheet and sent back to the original requestor, thus completing user requirements.