Oracle® Application Integration Architecture Oracle Customer Master Data Management Integration Implementation Guide Release 11.1 Part Number E27422-03 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of data enrichment and covers:
Data enrichment represents a spoke service to the CustomerPartyEBO to make a request for clean or enriched information from third-party data provider services. This third-party provider cleanses, recognizes, enriches, and protects Oracle Customer Hub contact records.
Clean: build a foundation of accurate customer contact information.
Recognize: enables customers to consistently recognize consumers and remove duplications, even with name changes, unreported moves, or incorrectly keyed information.
Enrich: enrich, enhance the data by adding other contact, demographic, socio-economic, or lifestyle enhancements.
Protect: compliance and regulatory expertise combined with suppression, risk, and compliance products.
Data enrichment enables the Oracle Customer Hub to enrich its Contact (B2C) information by sending a request message to pre-built third-party AIA connector. Depending on configuration (manual or automatic) a process is invoked to send basic name and address information to the third-party system for cleansing.
Two types of processing can occur for the request message: realtime or batch; however, the scope of this integration is realtime only, where the Oracle Customer Hub is configured to synchronize updated, enriched data automatically to participating applications as and when an EBM is received from the third-party enrichment application. There is no support for batch flows in this integration.
The prerequisites for implementing customer data enrichment are:
Oracle Customer Hub is set up as provided in Siebel UCM Data Enrichment Web Services chapter at My Oracle Support note 763962.1.
Oracle AIA configuration as mentioned in Section 8.6, "Handling Errors"
Oracle AIA is set up for the third-party provider, which depends on the provider chosen by the customer.
Note:
Set up of the third-party ABCS is not part of the Customer MDM integration. The third-party provides the ABCS code and instructions.
Figure 8-1 illustrates a high-level enrichment process.
The high-level process is defined here:
A set of parameters are sent using Oracle Customer Hub to the third-party enrichment application in the form of an EBM. Depending on the third-party services to which an organization has subscribed, the third-party consumes the message parameters and returns EBM of additional attributes.
The Oracle Customer Hub consumes the inbound message and performs the required updates received as enriched data from the third-party enrichment application.
Oracle Customer Hub can optionally synchronize these updated contact records to Siebel CRM or Oracle E-Business Suite if these are set up as participating applications.
Note:
A connector to AIA must be established by the third-party enrichment service to enable the applications to use the services provided.
Figure 8-2 illustrates the process for data enrichment from Oracle Customer Hub to third-party and back.
Figure 8-3shows the integration sequence flow:
When you initiate this process, these events occur:
Oracle Customer Hub invokes the ABCS service for data enrichment by passing person records. A person record is sent from either Siebel or Oracle E-Business Suite, which invokes the Oracle Customer Hub web service to synchronize the record.
Before synchronizing the record, Oracle Customer Hub invokes the ProcessPersonUCMreqABCSImpl to get the enriched data from the third-party provider.
ProcessPersonUCMReqABCSImpl: The Oracle Customer Hub requester ABC implementation, ProcessPersonUCMReqABCSImpl, transforms the Oracle Customer Hub ABM to the ProcessCustomerPartyListEBM and invokes the ProcessCustomerPartyListRequestResponse operation of the ProcessCustomerPartyEBS.
This message contains one or more addresses to be enriched.
ProcessCustomerPartyEBS: Invoking ProcessCustomerPartyEBS with the ProcessCustomerPartyListRequestResponse operation routes the ProcessCustomerPartyListEBM to the third-party provider ABC implementation service.
ProcessPersonUCMReqABCSImpl: ProcessCustomerPartyListResponseEBM with enriched data from third-party provider is then transformed back to Oracle Customer Hub ABM and sent back as a synchronous response.
The services that support the third-party integration are:
Table 8-1 Data Enrichment Integration Services
Service | Type | Owner | Description |
---|---|---|---|
ProcessPersonUCMReqABCSImpl |
BPEL |
AIA |
Oracle Customer Hub ABCS Connector service initiated from Oracle Customer Hub for data enrichment. This synchronous service maps the Oracle Customer Hub ABM to ProcessCustomerPartyListEBM and invokes the ProcessCustomerPartyEBS. After getting a response, maps the enriched response EBM back to Oracle Customer Hub ABM. |
ProcessCustomerPartyEBS |
Mediator |
AIA |
Mediator service, which routes the ProcessCustomerPartyListEBM to the third-party provider and passes the response EBM back to the Oracle Customer Hub requester. |
Third-party provider service |
BPEL |
Third-party |
Third-party provider ABCS connector service. This service is not packaged with the AIA release, but delivered by third-party provider. This service maps the ProcessCustomerPartyListEBM to third-party provider input ABM, invokes the third-party provider service to get enriched data and maps the enriched data back as ProcessCustomerPartyListResponseListEBM |
No cross-reference populate or lookups done in the data enrichment flow. Third-party IDs are directly passed into Oracle Customer Hub columns.
For a list of cross-references applicable for the Customer MDM integration, see Chapter 7, "Working with Cross-References"
The DVMs here pertain to the data enrichment flow only. For a complete list of DVMs for the Oracle Customer MDM integration, see Chapter 7, "Working with Domain Value Maps".
The DVMs used for the data enrichment flow are:
Table 8-2 DVMs Used for the Data Enrichment Flow
Name | DVM Column Name | Description | New/Existing |
---|---|---|---|
CONTACT_GENDERCODE |
SEBL_01, COMMON, EBIZ_01, UCM_01 |
To map gender codes like Male, Female, M, and so on. |
Existing |
MARITAL_STATUS |
UCM_01, COMMON, EBIZ_01 |
To map marital status codes like Married, Single, and so on. |
Existing |
ADDRESS_COUNTRYSUBDIVID |
SEBL_01, COMMON, EBIZ_01, UCM_01 |
To map country sub division codes. |
Existing |
ADDRESS_COUNTRYID |
SEBL_01, COMMON, EBIZ_01, UCM_01 |
To map country codes like USA, US, and so on. |
Existing |
STATE |
SEBL_01, COMMON, EBIZ_01, UCM_01 |
To map state codes like CA, FL, TX, and so forth |
Existing |
ADDRESS_DELIVERYTYPE |
UCM_01, COMMON, SEBL_01 |
To map delivery types like Residential Curb, Business, and so on. |
New |
ADDRESS_SEASONALINDICATORTYPE |
SEBL_01, COMMON, UCM_01 |
To map seasonal address indicator types like Educational Facility, Seasonal Address, and so on. |
New |
ADDRESS_MOVETYPE |
SEBL_01, COMMON, UCM_01 |
To indicate the type of move like Individual, Business or Firm, and so on. |
New |
ADDRESS_POSTALPROCESSINGCODE |
SEBL_01, COMMON, UCM_01 |
To map postal processing codes like AA match at ZIP Code level, LOT default match, and so on. |
New |
Standard AIA error handling is implemented with catch blocks for remote, binding, and AIA faults. Fault policy is provided. Any error from third-party provider is propagated to Oracle Customer Hub using the fault schema as in any synchronous service.
For more information about error handling, see Chapter 7, "Handling Errors"
The standard AIA configuration properties defined for data enrichment flow are provided here. For a complete list of properties in the AIAConfigurationProperties.xml file, seeChapter 7, "Setting Configuration Properties"
System ID: The default system ID is set.
Endpoint URLs: Properties are provided for the application service endpoint URLs.
CAVS: Properties for enabling CAVS.
ABCS Extension: Properties to govern ABCS Extension points.
Table 8-3 Configuration Properties for Customer Data Enrichment
Property Name | Value/Default Value | Description |
---|---|---|
Default.SystemID |
UCM_01 |
OCH system code (like UCM_01, defined in Oracle Enterprise Repository (OER)) from which requests originate for this process |
ABCSExtension.PreProcessABM |
True/False Default = False |
Property that governs whether ABCS Extension is enabled to pre-process ABM at the pre-defined plug-in point. If set to true, then the Extension process is invoked. |
ABCSExtension.PreProcessEBM |
True/False Default = False |
Property that governs whether ABCS Extension is enabled to pre-process EBM at the pre-defined plug-in point. If set to true, then the Extension process is invoked. |
ABCSExtension.PostProcessEBM |
True/False Default = False |
Property that governs whether ABCS Extension is enabled to post-process EBM at the pre-defined plug-in point. If set to true, then the Extension process is invoked. |
ABCSExtension.PostProcessABM |
True/False Default = False |
Property that governs whether ABCS Extension is enabled to post-process ABM at the pre-defined plug-in point. If set to true, then the Extension process is invoked. |
Routing.ProcessCustomerPartyEBS.ProcessCustomerPartyListRequestResponse.MessageProcessingInstruction.EnvironmentCode |
CAVS/PRODUCTION Default = PRODUCTION |
Property to govern whether the message is routed to CAVS or to the specified target service. Default value is PRODUCTION, which routes to the target service. |
Routing.ProcessCustomerPartyEBS.ProcessCustomerPartyListRequestResponse.RouteToCAVS |
True/False Default = False |
Property that governs whether the service should route the message to the CAVS endpoint or not. Default value is false, which does not route to CAVS. If set to true, it routes to CAVS using the endpoint specified in the CAVS.EndpointURI property. |
Routing.ProcessCustomerPartyEBS.ProcessCustomerPartyListRequestResponse.CAVS.EndpointURI |
http://<SOA_HOST>:<SOA_PORT>/AIAValidationSystemServlet/syncresponsesimulator |
CAVS Endpoint URI, when CAVS is enabled. |