1 Reply Latest reply: Feb 26, 2014 8:12 AM by Mike-Matthews-Oracle RSS

    How to delay the real time integration between EDQ and Siebel




      We are using EDQ for data deduplication and data cleansing in real time. One of the requirement is, for a contact there can be multiple email addresses.

      We have exposed a MVF from "XXX Custom BC" business component to capture the email address and set the primary email address. And once the records are saved in "XXX Custom BC", a workflow policy is triggered to update the primary email address from "XXX Custom BC" BC to EMAIL_ADDR column of "Contact" BC.


      And uniqness of contact is defined as Last Name + First Name + Primary Emaill address.


      When we save record in Siebel, EDQ is getting Last Name + First Name + Primary Emaill address values, but Primary Email address is having NULL value, as it is being populated by WF policy.


      Is there any setting in Siebel or EDQ or Siebel EDQ connector, which will delay in invoking the real time integration till the EMAIL_ADDRESS is populated by WF policy on contact record?

        • 1. Re: How to delay the real time integration between EDQ and Siebel



          The clustering service will always be called, but you can make it so that the matching service is not called until email is populated by customizing clustering so that you only generate keys if all your required fields (first name, last name and email) are populated. This is because the matching service in EDQ will only be called if the driving record has at least one candidate record that it may match against, where the candidate records are selected using the logic that any record that shares any key value with the driving record is a candidate.


          Note that with 'typical' (level 2) clustering of individuals, this will actually be the effect, unless you are using other secondary identifiers such as phone numbers, addresses etc. (in which case, are you sure you don't want to use them in matching?) If you do not want to use these a simple way of disabling them would be not to map them from Siebel in the DQ field mappings. EDQ-CDS will only return a cluster key value if all the attributes that form part of the key value are populated, and with level 2 clustering there are no keys based on just the name fields.


          If you mean email actually gets a string value of 'NULL' that is being passed to EDQ, I believe this will have no effect since I think the services will only generate keys based on email, and use the email in matching, if the email is syntactically correct (by regex), but you may want to check this behaviour using the Web Service Tester.