Disclaimer:

• Provided solution-accelerator is an illustration of how to integrate a Person entity with Contact Object in Salesforce.
• The utility will give the customer a jumpstart to integrate MDM-multidomain/C360 solution with Salesforce.
• For MDM+IICS customers, the solution shall be used to accelerate integration and can be extended as a business.
• Any bugs reported need to be taken care of by the customer itself.

Accelerator Reference:

• MDM-Person-Consumer.zip

Products Used:

• MDM multidomain 10.4 + IICS - CAI

Outbound integrations enable the business process to interact in real-time with downstream applications, such as CRM, reporting apps, or an external database, etc. Depending on the system that you are integrating with, you can implement the integration via specific connectors as applicable in Informatica Intelligent Cloud Services.

This utility will give customers a jumpstart to integrate MDM-multidomain/C360 solution with Salesforce.

• Ready to deploy*prebuilt IICS-CAI mappings, workflow, Oauth2 based authentication, BES API used, etc. will come along.
• To simulate outbound integration, few MDM attributes covering demographic details had been used for integrating the master record and create a Salesforce contact entity in real-time. Can be extended as per business.
• Track Master integration status using the MDM dashboard.
• Customer environment details need to be updated ie. CAI properties & BES orsids.

End to End Data Flow

Products used: MDM multidomain 10.4 + IICS -CAI

Figure 1. MDM, API’s and Salesforce Automation

×

Figure 1. MDM, API’s and Salesforce Automation

Figure 2. End to End Data Flow

×

Figure 2. End to End Data Flow

As a business grows, the need to onboard more data for a domain or add more domains to manage, govern, integrate, and analyze increases. Continuous trigger-based or on-demand integration is becoming a need of the hour. To make MDM operational 24/7 we leveraged Informatica BES+CAI service for real-time or on-demand integration with Salesforce (downstream)

Figure 3. Operationalize MDM

×

Figure 3. Operationalize MDM

You can access business entity services through an Enterprise JavaBeans (EJB) endpoint, a Representational State Transfer (REST) endpoint, or a Simple Object Access Protocol (SOAP) endpoint.

REST endpoints are built upon an EJB standpoint. The REST business entity service configuration defines how the REST URLs are mapped to the EJB business entity service calls.  

BES is a set of operations that run MDM Hub code to create, update, delete, and search for base object records in a business entity.

Sample Call:

http://host:port/cmx/cs/PDB01-MS_D02775145A/Person?action=query&filter=Processedflag=N

Figure 4. Business Entity Services

×

Figure 4. Business Entity Services

Note: Add Bes parameter for Batch Volume as per business

Parameter: recordsToReturn

Description: Specifies the number of rows to return. The default is 10.

Figure 5. REST, EJB, and SOAP-based interfaces

×

Figure 5. REST, EJB, and SOAP-based interfaces

The below figure depicts MDM records created via Entity 360 synchronized with Salesforce. We leveraged IICS (Informatica Intelligent Cloud Services) CAI services and handshake through Salesforce Connector by consuming MDM Bes API and sending an acknowledgment back to MDM and it can be seen in the MDM dashboard in real-time.

Figure 6. API – Business Entity Services

×

Figure 6. API – Business Entity Services

Dashboard Utilization - Track master integration in real-time

Figure 7. Track Master Integration

×

Figure 7. Track Master Integration

Create a Process to extract Person records that need to be processed to downstream systems, such as Salesforce, you can then transform, enrich the data in the process. Once the records have been committed to downstream systems, we update the processed flag, using Person Id, in the MDM system.

Import the zip file into your IICS Org; if need be, modify the locations from the dropdown.

Figure 8. Import Assets

×

Figure 8. Import Assets

Connects to 3rd party REST or SOAP API’s – in our case, we connect to MDM via Rest Call for retrieving the records and for posting an update post record creation in Salesforce.

Definition:

Figure 9. Definition

×

Figure 9. Definition

Actions – Get Person records:

Figure 10. Get Person Records

×

Figure 10. Get Person Records

Actions – Input:

URL is flagged as a parameter; defining the input.

Figure 11. getPerson - Input

×

Figure 11. getPerson - Input

Actions - Binding:

URL is built from the parameters passed to the process as part of the request body and is passed into the service connector along with the binding information.

Figure 12. getPerson - Binding

×

Figure 12. getPerson - Binding

Actions- Output:

We are defining how the output or the response is going to be.

Figure 13. getPerson - Output

×

Figure 13. getPerson - Output

Actions- Test Results:

Choose the appropriate runtime environment and click Test; post successful test, click on Generate Process Objects.

Figure 14. getPerson – Test Results

×

Figure 14. getPerson – Test Results

Figure 15. Update to MDM System after record creation in Salesforce

×

Figure 15. Update to MDM System after record creation in Salesforce

Actions - Input:

URL is flagged as a parameter; defining the input.

Figure 16. postProcessedflag – Define Input

×

Figure 16. postProcessedflag – Define Input

Actions - Binding:

URL is built from the parameters passed to the process as part of the request body and is passed into the service connector along with the binding information.

Figure 17. postProcessedflag – Binding Information

×

Figure 17. postProcessedflag – Binding Information

Figure 18. postProcessedflag – Binding Information shared

×

Figure 18. postProcessedflag – Binding Information shared

Actions - Output:

We are defining how the output or the response is going to be.

Figure 19. postProcessedflag - Define output

×

 Figure 19. postProcessedflag - Define output

Actions - Test Results:

Choose the appropriate runtime environment and click Test; post successful test, click on Generate Process Objects.

Figure 20. postProcessedflag - Test Results

×

Figure 20. postProcessedflag - Test Results

Save, Validate & Publish the Service Connector.

Defines actions to perform using a pre-defined connector or a service connector – in our case, we have two actions to perform which we have defined in the service connector above.

Figure 21. App Connection

×

Figure 21. App Connection

Figure 22. The action defined in Service Connector

×

Figure 22. The action defined in Service Connector

Save, Test, Validate & Publish the App Connection.

App Connection for Salesforce:

Defines actions to perform using a pre-defined connector or a service connector – in our case, we create Contact records in Salesforce.

Figure 23. Create records in Salesforce

×

Figure 23. Create records in Salesforce

Save, Test, Validate & Publish the App Connection.

Below is the logic that’s performed within the CAI Process:

1. Extract MDM Person records, which satisfy Processed flag=N, that need to be processed.
2. Loop through the response to Create Contact records in Salesforce.
3. The last step is to update the flag to Y to indicate the records have been consumed to Salesforce – this will also ensure the same records aren’t consumed again in the next instance.

This is how the Process will look like once the import is complete:

Figure 24 . Logic performed within CAI Process

×

Figure 24 . Logic performed within CAI Process

We have 4 input variables that need to be passed as part of the request body:

• Base URL – this is the MDM rest endpoint URL; in our sample, we have it to Person.
• Query – to indicate we are going to be retrieving the records.
• Filter – to filter based on Processedflag.
• Postparam – used to separate the different logins for retrieval and post-process update to MDM.

Figure 25. Four input variables

×

Figure 25. Four input variables

Figure 26. Output Fields

×

Figure 26. Output Fields

Figure 27. Temp Fields

×

Figure 27. Temp Fields

Figure 28. Build getPersonURL Properties

×

Figure 28. Build getPersonURL Properties

fn:concat($temp.tmp_baseURL, '?', $temp.tmp_query, '&', $temp.tmp_filter)

Figure 29. getPerson - Service

×

Figure 29. getPerson - Service

Figure 30. getPerson – Input Fields

×

Figure 30. getPerson – Input Fields

Figure 31. Assign getPerson Response to temp variables

×

Figure 31. Assign getPerson Response to temp variables

Figure 32. Check Number of Records - Decision

×

Figure 32. Check Number of Records - Decision

Figure 33. Extract first record from Person node

×

Figure 33. Extract first record from Person node

Figure 34. Add Contact Record - Create

×

Figure 34. Add Contact Record - Create

Figure 35. Add Contact Record – Input Fields

×

Figure 35. Add Contact Record – Input Fields

$temp.tmp_person/Person/lastName

$temp.tmp_person/Person/firstName

Figure 36. Initialize variables for Post Call

×

Figure 36. Initialize variables for Post Call

fn:concat($temp.tmp_baseURL, '/', $temp.tmp_personId, '?', $input.in_postparam)

fn:concat('{rowidObject:', $temp.tmp_personId, ', Processedflag: "Y", $original: { Processedflag: "N" }}')

Figure 37. Update Processflag - Service

×

Figure 37. Update Processflag - Service

Figure 38. Update Processedflag – Input Fields

×

Figure 38. Update Processedflag – Input Fields

$temp.tmp_UpdProcFlagReqBody

Figure 39. Remove Processed Record

×

Figure 39. Remove Processed Record

Next is to check if we have reached the end of the response.

Figure 40. Check if all Person Records are Processed - Decision

×

Figure 40. Check if all Person Records are Processed - Decision

Figure 41. Assign Success Message

×

Figure 41. Assign Success Message

Records are processed until all the records from the response file have been processed.

Figure 42. Data Processed

×

Figure 42. Data Processed

Next is a jump back to “Extract first record from Person node”.

Figure 43. Extract first record from Person node

×

Figure 43. Extract first record from Person node

Next is when the response from MDM is empty.

Figure 44. Assign Empty Response

×

Figure 44. Assign Empty Response

We end the process if we receive an empty response.

Figure 45. Empty Response

×

Figure 45. Empty Response

In conclusion, deliver connected experiences to customers by operationalizing MDM Implementation with Salesforce.

Accelerator Reference: 

MDM-Person-Consumer.zip