| Oracle® Application Integration Architecture Oracle Customer Master Data Management Integration Implementation Guide Release 11.1 Part Number E27422-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Application Integration Architecture Oracle Customer Master Data Management Integration Implementation Guide Release 11.1 Part Number E27422-02 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the Oracle Customer Hub (OCH) and discusses OCH process flows, integration services, interfaces, and assumptions and constraints.
This chapter includes the following sections:
Oracle Customer Hub (also called Siebel UCM) enables organizations to centralize information from heterogeneous systems, creating a single view of customer information that can be leveraged across all functional departments and analytical systems.
Oracle Customer Hub provides a single, consolidated system of record for the definition of customer-related entities such as contacts, addresses, and accounts as well as the relationships within these entities. Oracle Customer Hub can also serve as the system of entry for a Data Steward to update customer records directly in Oracle Customer Hub and publish this customer definition to all subscribing applications.
For more information about Oracle Customer Hub, see the Siebel UCM product documentation.
These are the process flows from Oracle Customer Hub (OCH):
Match and Fetch Organizations and Persons between OCH and participating applications, as applicable.
Synchronization of Organizations and Persons from OCH to the participating applications, as applicable.
Merge flow from Oracle Customer Hub to the participating applications, as applicable.
Publishing organization updates from Oracle Customer Hub to Oracle Billing and Revenue Management.
The match and fetch flow between Oracle Customer Hub and a participating application have been covered in the chapter specific to the participation application involved in the flow.
See Section 3.2, "Match and Fetch between Siebel CRM and Oracle Customer Hub"for match and fetch between Oracle Customer Hub and Siebel CRM.
See Section 4.2, "Match and Fetch between Oracle E-Business Suite and Oracle Customer Hub" for match and fetch between Oracle Customer Hub and Oracle E-Business Suite.
This integration flow synchronizes organization and person parties and customer accounts from Oracle Customer Hub to Oracle E-Business Suite. The single synchronize service that is invoked publishes a message using AIA to the subscribing Oracle E-Business Suite application(s).
This integration flow can be triggered manually or as part of an automated process, and is leveraged as part of the match/fetch process.
Figure 2-1 illustrates the synchronization of organizations and persons from Oracle Customer Hub to Oracle E-Business Suite:
This integration flow synchronizes new accounts or updates from Oracle Customer Hub to Oracle E-Business Suite. This integration flow uses these interfaces:
SyncOrganizationUCMJMSProducer
SyncOrganizationUCMJMSConsumer
SyncOrganizationUCMReqABCSImpl
CustomerPartyEBSV2
SyncCustomerPartyListEbizProvABCSImpl
CustomerPartyResponseEBSV2
SyncCustomerPartyListResponseUCMProvABCSImpl
Figure 2-2 illustrates the integration flow:
When you initiate this process, these events occur:
Oracle Customer Hub publishes messages that initiate the SyncOrganizationUCMJMSProducer, with the UCMAccountABM message.
The SyncAccountUCMJMSProducer queues the Oracle Customer Hub Account ABM message onto a JMS queue.
The message in the queue is picked up by the SyncAccountUCMJMSConsumer service, which then routes the message to the SyncAccountUCMReqABCSImpl.
The Oracle Customer Hub Requester ABC implementation, SyncAccountUCMReqABCSImpl, transforms the Oracle Customer Hub ABM to the SyncCustomerPartyListEBM and invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2.
When there are multiple accounts in the message, the message has to be transformed into several EBM messages with accounts with the same target or one EBM per account with all its targets. In either case, there are multiple calls to the EBS from the SyncAccountUCMReqABCSImpl.
Invoking the CustomerPartyEBSV2 with the SyncCustomerPartyList operation routes the SyncCustomerPartyListEBM to the Oracle E-Business Suite provider ABC implementation service, SyncCustomerPartyListEbizProvABCSImpl.
The Oracle E-Business Suite provider ABC implementation service, SyncCustomerPartyListEbizProvABCSImpl, transforms the SyncCustomerPartyListEBM into the appropriate Oracle E-Business Suite organization account ABM and invokes the Oracle E-Business Suite API.
The response from the Oracle E-Business Suite API is then transformed into the SyncCustomerPartyListResponseEBM in the process of which, the cross references tables are populated with the Oracle E-Business Suite identifier values if not already present.
The response is also sent to the CustomerPartyResponseEBSV2, which routes the message to the SyncCustomerPartyListResponseUCMProvABCSImpl to set the Oracle E-Business Suite ID within Oracle Customer Hub.
The SyncCustomerPartyListResponseUCMProvABCSImpl transforms the SyncCustomerPartyListResponseEBM into the Oracle Customer Hub organization ABM and synchronizes the external ID into Oracle Customer Hub.
This integration flow is used to synchronize new persons or updates from Oracle Customer Hub to Oracle E-Business Suite. This integration flow uses these interfaces:
SyncPersonUCMJMSProducer
SyncPersonUCMJMSConsumer
SyncPersonUCMReqABCSImpl
CustomerPartyEBSV2
SyncCustomerPartyListEbizProvABCSImpl
CustomerPartyResponseEBSV2
SyncCustomerPartyListRsponseUCMProvABCSImpl
Figure 2-3illustrates the integration flow:
When you initiate this process, these events occur:
Oracle Customer Hub publishes messages that initiate the SyncPersonUCMJMSProducer, with the UCMPersonABM message.
The SyncPersonUCMJMSProducer queues the Oracle Customer Hub person ABM message onto a JMS queue.
The message in the queue is picked up by the SyncPersonUCMJMSConsumer service, which then routes the message to the SyncPersonUCMReqABCSImpl.
The Oracle Customer Hub requester ABC implementation, SyncPersonUCMReqABCSImpl, transforms the Oracle Customer Hub ABM into the SyncCustomerPartyListEBM and invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2.
When there are multiple persons in the message, the message has to be transformed into several EBM messages with persons with the same target or one EBM per person with all its targets. In either case, there are multiple calls to the EBS from the SyncPersonUCMReqABCSImpl.
Invoking the CustomerPartyEBSV2 with the SyncCustomerPartyList operation routes the SyncCustomerPartyListEBM to the Oracle E-Business Suite provider ABC implementation service, SyncCustomerPartyListEbizProvABCSImpl.
The Oracle E-Business Suite provider ABC implementation service, SyncCustomerPartyListEbizProvABCSImpl, transforms the SyncCustomerPartyListEBM to the appropriate Oracle E-Business Suite person account ABM and invokes the Oracle E-Business Suite API.
The response from the Oracle E-Business Suite API is then transformed into the SyncCustomerPartyListResponseEBM in the process of which the cross references tables are populated with the Oracle E-Business Suite identifier values if they are not already present.
The response is also sent to the CustomerPartyResponseEBSV2, which routes the message to the SyncCustomerPartyListResponseUCMProvABCSImpl to set the Oracle E-Business Suite ID within Oracle Customer Hub.
The SyncCustomerPartyListResponseUCMProvABCSImpl transforms the SyncCustomerPartyListResponseEBM into the Oracle Customer Hub person ABM synchronizes the external ID into Oracle Customer Hub.
This integration flow enables the synchronization of accounts and contacts from Oracle Customer Hub to Siebel CRM. This integration flow can be triggered manually or as part of an automated process.
Siebel CRM is expected to subscribe to all synchronization messages that Oracle Customer Hub produces.
Figure 2-4 illustrates the synchronization of organizations and persons from Oracle Customer Hub to Siebel CRM:
This integration flow is used to synchronize new account or updates from Oracle Customer Hub to Siebel. This integration flow uses these interfaces:
SyncOrganizationUCMJMSProducer
SyncOrganizationUCMJMSConsumer
SyncOrganizationUCMReqABCSImpl
CustomerPartyEBSV2
AIASessionPoolManager
SyncCustomerPartyListSiebelProvABCSImpl
CustomerPartyResponseEBSV2
SyncCustomerPartyListResponseUCMProvABCSImpl
Figure 2-5 illustrates the integration flow:
When you initiate this process, these events occur:
Oracle Customer Hub publishes messages that initiate the SyncOrganizationUCMJMSProducer, with the UCMAccountABM message.
The SyncAccountUCMJMSProducer queues the Oracle Customer Hub account ABM message onto a JMS queue.
The message in the queue is picked up by the SyncAccountUCMJMSConsumer service, which then routes the message to the SyncAccountUCMReqABCSImpl.
The Oracle Customer Hub requester ABC implementation, SyncAccountUCMReqABCSImpl, transforms the Oracle Customer Hub ABM into the SyncCustomerPartyListEBM and invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2.
Invoking the CustomerPartyEBSV2 with the SyncCustomerPartyList operation routes the SyncCustomerPartyListEBM to the Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl.
When there are multiple accounts in the message, the message has to be transformed into several EBM messages for accounts with the same target or one EBM per account with all its targets. In either case, there are multiple calls to the EBS from the SyncAccountUCMReqABCSImpl.
The Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl, transforms the SyncCustomerPartyListEBM into the appropriate Siebel account ABM and invokes the Siebel web service.
The response from the Siebel web service is then transformed into the SyncCustomerPartyListResponseEBM in the process of which, the cross references tables are populated with the Siebel identifier values if not already present.
The response is also sent to the CustomerPartyResponseEBSV2, which routes the message to the SyncCustomerPartyListResponseUCMProvABCSImpl to set the Siebel ID within Oracle Customer Hub.
The SyncCustomerPartyListResponseUCMProvABCSImpl transforms the SyncCustomerPartyListResponseEBM into the Oracle Customer Hub organization ABM synchronizes the Siebel ID into Oracle Customer Hub.
This integration flow is used to synchronize new persons or updates from Oracle Customer Hub to Siebel CRM. This integration flow uses these interfaces:
SyncPersonUCMJMSProducer
SyncPersonUCMJMSConsumer
SyncPersonUCMReqABCSImpl
CustomerPartyEBSV2
AIASessionPoolManager
SyncCustomerPartyListSiebelProvABCSImpl
CustomerPartyResponseEBSV2
SyncCustomerPartyListRsponseUCMProvABCSImpl
Figure 2-6 illustrates the integration flow:
When you initiate this process, these events occur:
Oracle Customer Hub publishes messages that initiate the SyncPersonUCMJMSProducer, with the UCMPersonABM message.
The SyncPersonUCMJMSProducer queues the Oracle Customer Hub person ABM message onto a JMS queue.
The message in the queue is picked up by the SyncPersonUCMJMSConsumer service, which then routes the message to the SyncPersonUCMReqABCSImpl.
The Oracle Customer Hub requester ABC implementation, SyncPersonUCMReqABCSImpl, transforms the Oracle Customer Hub ABM into the SyncCustomerPartyListEBM and invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2.
When there are multiple persons in the message, the message has to be transformed into several EBM messages with persons with the same target or one EBM per person with all its targets. In either case, there are multiple calls to the EBS from the SyncPersonUCMReqABCSImpl.
Invoking the CustomerPartyEBSV2 with the SyncCustomerPartyList operation routes the SyncCustomerPartyListEBM to the Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl.
The Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl, transforms the SyncCustomerPartyListEBM into the appropriate Siebel contact ABM and invokes the Siebel web service.
The response from the Siebel web service is then transformed into the SyncCustomerPartyListResponseEBM in the process of which, the cross references tables are populated with the Siebel identifier values if not already present.
The response is also sent to the CustomerPartyResponseEBSV2, which routes the message to the SyncCustomerPartyListResponseUCMProvABCSImpl to set the Siebel ID within Oracle Customer Hub.
The SyncCustomerPartyListResponseUCMProvABCSImpl transforms the SyncCustomerPartyListResponseEBM into the Oracle Customer Hub person ABM and synchronizes the Siebel ID into Oracle Customer Hub.
The synchronization of organizations (accounts) and persons (contacts) from OCH to Oracle BRM enforces that the customer data in Oracle BRM is consistent with the version of the data from the OCH. Billing systems contain considerable amount of customer data, which is used to bill customers and prepare billing invoices for customers. The inconsistency in data can translate to loss of revenues and result in higher maintenance costs and poor customer satisfaction.
Oracle Customer Hub publishes account updates to Billing and Revenue Management (Oracle BRM) under these circumstances:
New customer data is created in Siebel CRM as part of order submission flow. OCH receives the data from Siebel CRM, cleanses it, and publishes it to the subscribing applications.
In this case, Oracle BRM receives the data from Siebel CRM through order and an update from OCH.
Customer data is updated in OCH because of an update in Siebel CRM. OCH receives the data from Siebel CRM, cleanses it, and publishes it to Oracle BRM.
Customer data is updated in OCH because of an update in an application other than Siebel CRM.
OCH receives the data, cleanses it, and publishes it to the subscribing applications including Oracle BRM.
Customer data is updated in OCH due to a merge either because of link and update or because of data steward's action.
The synchronization flow between Oracle Customer Hub and Oracle BRM is unidirectional where the customer data updates are published from Oracle Customer Hub to Oracle BRM.
Note:
For OCH to Oracle BRM synchronization flow, publishing is always done in batch.
Figure 2-7 the process flow for customer data updates published from Oracle Customer Hub to Oracle BRM.
The flow from OCH to Oracle BRM enforces that the creation of new customer data can take place only as part of an order submission flow, because it is not recommended to have prospects created in a billing system.
For more information about the order submission flow, see the Oracle Communications Order to Cash Integration Pack for Siebel CRM, Oracle OSM, and Oracle BRM Implementation Guide.
The synchronization process in OCH updates organization (party or customer) account information and their related entities, such as addresses and related contacts/accounts in Oracle BRM. It also updates person (party or customer) account information and their related entities, such as addresses, and related accounts in Oracle BRM. Oracle BRM can optionally subscribe to this synchronization operation depending on the configuration.
The synchronize customer request by OCH:
Ensures that Oracle BRM has most current customer records consistent with the golden version of the customer data owned by Oracle Customer Hub (OCH)
Enables invocation of single operation to update organization and person parties and customer accounts with the changes applied by Oracle Customer Hub (OCH) in one or more Oracle BRM applications.
The preset routing ensures that create messages are not propagated to Oracle BRM to avoid creating prospects in Oracle BRM as creation of customer data in Oracle BRM should take place only as part of the order submission flow.
OCH invokes a single synchronization service that publishes a message using AIA to the subscribing applications.
There may occur a race condition between an account create or update coming from Siebel CRM to Oracle BRM and the updates coming from OCH to Oracle BRM.
If customer data is created in Siebel CRM and published to Oracle BRM, the updates to OCH are applied after the customer data has been created.
If customer data is updated in Siebel CRM and published to OCH and Oracle BRM, OCH also publishes to Oracle BRM after performing cleansing and de-duping. In this case, changes to Oracle BRM are applied by OCH only after the Siebel CRM updates have been applied to OCH.
This race condition is a rare event as it takes place only when the update from OCH reaches Oracle BRM before it reaches Siebel CRM, and before the AIACOM query from Siebel CRM. The dependency between the two updates (the update from OCH should be applied only after the create/update action from Siebel CRM has been performed) is not enforced.
However, if a race condition does take place, the cleansed data from OCH may be overwritten by the original data in Siebel CRM; therefore, to fix this rare situation, a periodic synchronization is performed by the OCH administrator where the data that was not properly synchronized due to race condition is re-synchronized. See Section 2.2.8.3, "Periodic Cron-Job for Re-Syncing Customer Data from OCH to Oracle BRM".
Oracle Customer Hub updates can be published to Oracle BRM during customer data creation or customer data updates.
The flow associated with the organization and person updates from OCH to Oracle BRM is composed of two parts for synchronization request:
Note:
The synchronization message from OCH is always at the account level.
OCH publishes customer data updates to AIA: This spoke is common to the standard customer data synchronization and reused from the horizontal integration.
The AIA CustomerPartyEBS routes the updates to the subscribing Oracle BRM instances. This AIA EBS needs to be configured to route a request for customer data update to Oracle BRM when customer-data synchronization message is received.
AIA applies Customer Data updates to Oracle BRM: This spoke is a modification of the existing Oracle BRM customer data update.
In Oracle BRM SyncCustomerPartyListBRMCommsProvABCS, the AIA checks that a cross-reference for the entity exists. If the cross-reference exists, the changes are applied. Else, they are discarded as the customer data was not created in the Oracle BRM instance.
Figure 2-8 illustrates the functional steps when customer data is created in Siebel CRM (as part of agent-assisted billing care flow) and OCH:
Figure 2-9 illustrates the customer-account flow process from Siebel CRM to Oracle BRM.
This is the process flow:
In Siebel CRM, a user creates an account with Address(es), Contact(s) & Billing Profile(s) in the Accounts screen. Then the user navigates to the Sales Order screen and creates a new order for this account and submits it using the 'Submit' button. This triggers the Order flow, which in turn, calls the Orchestration engine.
The Orchestration engine initiates the Sync Customer flow by dropping the message into a JMS Queue named ' AIA_CRTCUST_OUT_JMSQ', which is picked up by the ProcessFufillmentOrderBillingAccountListOSMCFSCommsJMSConsumer and routed to the CommunicationsBillingEBSV1. This EBS routes the message to the CommsProcessFulfillmentOrderBillingAccountListEBF.
The CommsProcessFulfillmentOrderBillingAccountListEBF extracts the relevant customer data (ProcessBillingAccountListEBM) and routes it to the CommsProcessBillingAccountListEBF through the EBS CommunicationsBillingEBSV1.
The CommsProcessBillingAccountListEBF prepares the message (QueryCustomerPartyListEBM) required for querying the entire account data from the Siebel system before creating the account in BRM.
Invoking the CommunicationsCustomerPartyEBSV2 EBS with the operation 'QueryCustomerPartyList' will route the message to the CustomerPartyEBSV2 EBS using the Comms2CoreCustomerPartyBridge service. The core EBS CustomerPartyEBSV2 will further route the message to the QueryCustomerPartyListSiebelProvABCSImplV2.
The QueryCustomerPartyListSiebelProvABCSImplV2 prepares the ABM required to invoke Siebel's SWI_Customer_Party_Service. The query service invokes the Siebel database and fetches the account details and replies to the QueryCustomerPartyListSiebelProvABCSImplV2 with the response ABM.
This response ABM is then transformed into the response EBM (QueryCustomerPartyListResponseEBM) and is sent back to the CommsProcessBillingAccountListEBF using the CustomerPartyEBSV2 - Comms2CoreCustomerPartyBridge - CommunicationsCustomerPartyEBSV2.
The CommsProcessBillingAccountListEBF service invokes the CommunicationsCustomerPartyEBSV2 on operation the 'SyncCustomerPartyList' which instantiates the SyncCustomerPartyListBRMCommsProvABCSImpl. This service invokes the BRM system on opcode PCM_OP_CUST_COMMIT_CUSTOMER, if it is a new account to be created. For an existing account, the opcode PCM_OP_CUST_UPDATE_CUSTOMER or PCM_OP_CUSTCARE_MOVE_ACCT is called, as applicable.
If an account is successfully created or updated, an appropriate response (SyncCustomerPartyListResponseEBM) is sent back to the CommsProcessBillingAccountListEBF in async delayed response fashion, which then sends a response message (ProcessBillingAccountListResponseEBM) to the CommsProcessFulfillmentOrderBillingAccountListEBF in async delayed response fashion.
The CommsProcessFulfillmentOrderBillingAccountListEBF drops a response message into the SAF Queue named 'AIA_UPDCUST_IN_JMSQ', where the orchestration engine is notified of the SyncCustomer status.
OCH publishing updates to Oracle BRM for the changes made to existing data can be differentiated as updates made to an account (organization) and updates made to a contact (person).
For the updates made to an account, the process flow is the same as described in OCH Publishes Updates to BRM for New Customer Data, where OCH publishes an account synchronization message that is routed as an account update to Oracle BRM.
Figure 2-10 illustrates the interactions among the systems when customer data is updated in Siebel CRM (as part of agent-assisted billing care flow) and OCH at account level.
For the updates affecting only the person data, OCH publishes a contact update message. If the contact update is an update to the primary contact for an existing account in Oracle BRM, the Oracle BRM data is updated as well.
The synchronization message from OCH to BRM is always at the account level as the BRM provider expects an account message. Even when a new contact is created, it is done in the context of an account creation. If the contact is changed in Siebel, Siebel sends the contact message along with a list of impacted accounts, that is, even though a contact is changed it is really an account message that is passed to BRM provider.
In the event the contact data is changed in OCH, OCH publishes a person message (and not account message) which needs to be converted into an account message before sending to Oracle BRM. For this to happen, a transformation takes place in the routing rule that converts the person message into account message and routes it to InterfaceContactToAccountEBF, which checks whether both the account and the contact exist in the cross-reference. If both of them exist in the cross-reference, this EBF sends the account message for processing to Oracle BRM.
Figure 2-11 illustrates the interaction between the systems when customer data is updated at the contact level:
Figure 2-12 illustrates the customer update process initiated in Siebel CRM when an account is updated, and the change propagated to the Oracle BRM.
This is the process flow:
In Siebel CRM, the user navigates to the Accounts screen, queries an account and updates an account attribute like Address, Contact, or Billing Profile. This causes the Siebel workflow to invoke the SyncCustomerSiebelEventAggregator, with the SiebelUpdateABM message containing the details of the account that has been updated. Corresponding to the kind of update, there can be four kinds of Siebel messages, for example: ListOfSWICustomerIO, ListOfSWIBillingProfileIO, ListOfSWIContactIO and ListOfSWIAddressIO.
The SyncCustomerSiebelEventAggregator then calls one of the four database adapters (Account, Address, Contact, BP) that executes a pl/sql script which extracts and stores the relevant ids (like account, contact, billprofile) in the database table AIA_AGGREGATED_ENTITIES and sends an acknowledgement to Siebel as a reply
The IDs in the database table are stored in such a way that the hierarchy of the IDs is maintained. For example, the BillingProfileID will always be the child of some account ID. The account ID, along with its entire child IDs is picked up from the database table by the SyncAcctSiebelEventAggrConsumer process.
The Consumer process then calls the SyncAccountSiebelReqABCSImpl process. This process takes all the IDs, constructs a Siebel Query Input ABM, and calls the Siebel Query web service to get the entire account data from Siebel. After getting the data, it is transformed into the SyncCustomerPartyListEBM, and the CustomerPartyEBSV2 is invoked on the operation SyncCustomerPartyList.
The CustomerPartyEBSV2 routes the message (SyncCustomerPartyListEBM) to the CommunicationsCustomerPartyEBSV2 using the Core2CommsCustomerPartyBridge service.
The CommunicationsCustomerPartyEBSV2 sends the message (SyncCustomerPartyListEBM) to the SyncCustomerPartyListBRMCommsJMSProducer which publishes the message to a JMS Topic named CPARTY_SYNC_TOPIC.
Depending on the instances of BRM or any other Billing System, consumers can be defined that subscribe to the above topic. One such consumer for the default implementation is available, named SyncCustomerPartyListBRM_01CommsJMSConsumer, which listens to the topic for messages, picks up the arriving message, and passes it on to the process SyncCustomerPartyListBRMCommsProvABCSImpl, after duly checking if the message should go to the ensuing providerABCS or not, and correspondingly stamping the target ID.
The SyncCustomerPartyListBRMCommsProvABCSImpl process then calls the PCM_OP_CUST_UPDATE_CUSTOMER or the PCM_OP_CUST_DELETE_PAYINFO or the PCM_OP_CUST_SET_STATUS opcode as required, to synchronize the updated data to Oracle BRM.
Periodic cron-job ensures that all cleansed data that may not have been synced from OCH to Oracle BRM because of race conditions is periodically synced. It also ensures that Oracle BRM customer data is updated with the cleansed and trusted version from the OCH even in the rare event that the batch update could not be applied.
The data steward configures OCH to publish periodic synchronization to target applications. During this periodic synchronization, all customer data (account and contact) that are created and updated during the last (periodic) synchronization are published to the subscribing applications.
Figure 2-13 illustrates the merge from Oracle Customer Hub to Siebel CRM integration flow:
By default, the Customer MDM integration merges the customer data in Siebel when a merge is published by the Oracle Customer Hub; however, you can turn off this default behavior should you have a business need when interoperating with applications that do not support a merge process.
To turn off merge publishing by Oracle Customer Hub, set the process property EnablePubSub to False for the UCM Process Merge Request workflow.
For more information about the workflow, see the Siebel Book Shelf: Siebel Business Process Framework: Workflow Guide.
This integration flow uses these interfaces:
SyncOrganizationUCMJMSProducer
SyncOrganizationUCMJMSConsumer
SyncOrganizationUCMReqABCSImpl
CustomerPartyEBSV2
AIASessionPoolManager
SyncCustomerPartyListSiebelProvABCSImpl
Note that these services are the same services used by the synchronization flows. These same Siebel ABC services deal with different transformations and ABMs to correspond to two different web services in Siebel.
Figure 2-14 illustrates the integration flow:
When you initiate this process, these events occur:
Oracle Customer Hub publishes merge account messages in real time when two accounts are merged in the Existing Duplicates screen in Oracle Customer Hub.
This initiates the SyncOrganizationUCMJMSProducer, with the UCMAccountABM message that contains both the survivor and the victim object.
The SyncOrganizationUCMJMSProducer queues the Oracle Customer Hub Account ABM message onto a JMS queue.
The message in the queue is picked up by the SyncOrganizationUCMJMSConsumer service, which then routes the message to the SyncOrganizationUCMReqABCSImpl.
The Oracle Customer Hub requester ABC implementation, SyncOrganizationUCMReqABCSImpl, transforms the Oracle Customer Hub ABM with both the survivor and the victim object to the SyncCustomerPartyListEBM with the verb code 'Merge' and invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2.
When there are multiple target systems in the message, the message has to be transformed into several EBM messages, one for each target, and there are multiple calls to the EBS from the SyncOrganizationUCMReqABCSImpl.
Invoking the CustomerPartyEBSV2 with the SyncCustomerPartyList operation routes the SyncCustomerPartyListEBM to the Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl.
The Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl identifies the verb code 'Merge' and transforms the SyncCustomerPartyListEBM to the appropriate Siebel merge ABM and invokes the Siebel web service for merging accounts.
The Siebel Merge web service performs a merge of the victim account to the survivor account and re-parents all the transactions to the survivor record within Siebel. The response from Siebel is then transformed to mark the corresponding cross-reference entries for deletion.
This integration flow uses these interfaces:
SyncPersonUCMJMSProducer
SyncPersonUCMJMSConsumer
SyncPersonUCMReqABCSImpl
CustomerPartyEBSV2
AIASessionPoolManager
SyncCustomerPartyListSiebelProvABCSImpl
Note that these services are the same services used by the synchronization flows. These same Siebel ABC services deal with different transformations and ABMs to correspond to two different web services in Siebel.
Figure 2-15 illustrates the integration flow:
When you initiate this process, these events occur:
Oracle Customer Hub publishes a person message with the survivor and the victim object in real time when two contacts are merged in the Existing Duplicates screen in Oracle Customer Hub.
This initiates the SyncPersonUCMJMSProducer, with the UCMPersonABM message.
The SyncPersonUCMJMSProducer queues the Oracle Customer Hub Person ABM message onto a JMS queue.
The message in the queue is picked up by the SyncPersonUCMJMSConsumer service, which then routes the message to the SyncPersonUCMReqABCSImpl.
The Oracle Customer Hub requester ABC implementation, SyncPersonUCMReqABCSImpl, transforms the Oracle Customer Hub ABM with the survivor and victim object into the SyncCustomerPartyListEBM with the verb code Merge and invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2.
When there are multiple targets in the message, the message has to be transformed into several EBM messages, one for each target and there are multiple calls to the EBS from the SyncPersonUCMReqABCSImpl.
Invoking the CustomerPartyEBSV2 with the SyncCustomerPartyList operation routes the SyncCustomerPartyListEBM to the Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl.
The Siebel provider ABC implementation service, SyncCustomerPartyListSiebelProvABCSImpl, identifies the verb code Merge, and transforms the SyncCustomerPartyListEBM to the appropriate Siebel merge ABM. It then invokes the Siebel merge web service.
The Siebel Merge web service performs a merge of the victim contact to the survivor contact and re-parents all the transactions to the survivor record within Siebel. The response is then transformed to mark the corresponding entries in the cross reference for deletion.
The Oracle E-Business Suite ABCS consumes the merge message, but updates only the survivor record with the latest details while ignoring the request to delete the victim records. This includes the creation of new child entries like addresses and contacts that is similar to the synchronization flow from Oracle Customer Hub to Oracle E-Business Suite. Out-of-the-box invocation of merge within Oracle E-Business Suite is not supported as part of this flow.
A merge in Oracle E-Business Suite involves running concurrent jobs, which is not supported.
The merge customer request by OCH enables Oracle BRM to update customer data with the changes published by OCH. Oracle BRM ABCS updates the survivor record with the latest details while ignoring the request to delete the victim records.
Figure 2-16 illustrates the merge flow from OCH to Oracle BRM.
The flow associated with the organization and person updates from OCH to Oracle BRM is composed of two spokes for merge request:
OCH publishes customer data updates to AIA: This spoke is common to the standard customer data merge and reused from the horizontal integration.
The AIA SyncCustomerPartyEBS routes the updates to the subscribing Oracle BRM instances. This AIA EBS needs to be configured to route a request for customer data update to Oracle BRM when a customer data merge message is received.
AIA applies customer data updates to Oracle BRM: This spoke is a modification of the existing Oracle BRM customer data update.
In Oracle BRM SyncCustomerPartyListBRMCommsProvABCS, the AIA checks that a cross-reference for the entity exists. If the cross-reference exists, the changes are applied. Else, they are discarded as the customer data was not created in the Oracle BRM instance.
Some of the subscribing applications such as Siebel CRM may be able to merge records and re-parent the associated entities to reflect the merge performed by OCH, but Oracle BRM does not offer a service to support this feature. Therefore, merging account or contacts in Siebel CRM without merging the corresponding accounts or contacts in Oracle BRM is not a feasible option. The reason being, it would not be possible to retrieve invoice details for victim accounts or submit change orders related to assets parented to victim accounts.
A merge operation in OCH only triggers an update of the survivor account in both Siebel CRM and Oracle BRM. However, customers may customize their procedures and tools so that an administrator can merge customer data in Siebel CRM and in Oracle BRM to be consistent with the merge data in OCH. This is a suggested custom solution and is not part of the flows covered in the Customer MDM integration.
These are the integration services:
SyncOrganizationUCMJMSConsumer
SyncOrganizationUCMJMSProducer
SyncPersonUCMJMSProducer
SyncPersonUCMJMSConsumer
QueryCustomerPartyListUCMProvABCSImpl
QueryCustomerPartyUCMProvABCSImpl
SyncOrganizationUCMReqABCSImpl
SyncCustomerPartyListResponseUCMProvABCSImpl
SyncPersonUCMReqABCSImpl
ProcessPersonUCMReqABCSImpl
SyncCustomerPartyListUCMProvABCSImpl
The SyncOrganizationUCMJMSProducer is implemented as a BPEL process because it involves JMS Header manipulations that cannot be done in Mediator. This service is responsible for queueing the Oracle Customer Hub Organization payload into the JMS queue. When queueing, a unique JMSCorrelationID is populated in the JMS Header of each message. This ID is used when dequeueing the message in the SyncOrganizationUCMJMSConsumer. This operation is defined in this service: SyncOrganization.
The SyncOrganizationUCMJMSConsumer service is implemented as a process with a JMS adapter and routing services. This service is responsible for dequeueing the Oracle Customer Hub Organization message from the JMS queue and invoking the requestor ABCS, SyncOrganizationUCMReqABCSImpl. The dequeue operation is done depending on the JMSCorrelationID that is populated when the message is enqueued.
The SyncPersonUCMJMSProducer service is implemented as a BPEL process since it involves JMS Header manipulations that cannot be done in Mediator. This service is responsible for enqueueing the Oracle Customer Hub Person payload into the JMS queue. When queueing, a unique JMSCorrelationID is populated in the JMS Header of each message. This ID is used when dequeueing the message in the SyncPersonUCMJMSConsumer. This operation is defined in SyncPerson service.
The SyncPersonUCMJMSConsumer is implemented as a process with a JMS adapter and routing services. This service is responsible for dequeueing the Oracle Customer Hub Person message from the JMS queue and invoking the requestor ABCS, SyncPersonUCMReqABCSImpl. The dequeue operation is done depending on the JMSCorrelationID that is populated when the message is enqueued.
The QueryCustomerPartyListUCMProvABCSImpl provider ABC service is used by the match flow to query both organization and person information from Oracle Customer Hub. It returns a list of organization or person candidates that matches the sent criteria. This service has one synchronous request/reply operation: QueryCustomerPartyList.
The QueryCustomerPartyUCMProvABCSImpl provider service is used as part of the fetch flow for both organization and person requests. It accepts an organization or person common ID as the request criteria and returns the full organization or person data record from Oracle Customer Hub. This service has one synchronous request/reply operation: QueryCustomerParty.
The SyncOrganizationUCMReqABCSImpl service is responsible for transforming the Oracle Customer Hub message into the SyncCustomerPartyList EBM format and invoking the SyncCustomerPartyList operation of the CustomerPartyEBSV2. This operation is defined in the service: SyncOrganization.
The SyncCustomerPartyListResponseUCMProvABCSImpl is implemented in BPEL and is invoked by the SyncCustomerPartyListResponse operation of the CustomerPartyResponseEBSV2, passing in the SyncCustomerPartyListResponseEBM payload. This service transforms the EBM into an Oracle Customer Hub ABM and invokes the Oracle Customer Hub web service interface to synchronize the external system IDs.
The SyncPersonUCMReqABCSImpl service is responsible for transforming the Oracle Customer Hub message into the SyncCustomerPartyList EBM format and invoking the SyncCustomerPartyList operation of the CustomerPartyEBSV2. This operation is defined in the service: SyncPerson.
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.
The SyncCustomerPartyListUCMProvABCSImpl service is implemented in BPEL and is invoked by the SyncCustomerPartyList operation of the CustomerPartyEBSV2, passing in the synchronize CustomerPartyListEBM payload. This service transforms the EBM into a OCH ABM and invokes the OCH web service interface. It also captures the response from the OCH Application, transforms the OCH Response ABM to the SyncCustomerPArtyListResponseEBM payload, and invokes the SyncCustomerPartyListResponse operation of the CustomerPartyResponseEBSV2.
Inbound/Outbound services, as applicable, are provided here.
Service: OrganizationMatchService
Operation: OrganizationMatch
Service: PersonMatchWebService
Operation: PersonMatch
OrganizationQueryService
Operation: getOrganization
PersonQueryService
Operation: getPerson
For more information about Oracle Customer Hub (Siebel UCM) web services, see Siebel CRM Web Services Reference Addendum for Siebel UCM on My Oracle Support 3.
Table 2-1 Inbound Web Services: Organization and Person Synchronization
| Name | Schema |
|---|---|
|
Service:OrganizationService Operation: createOrganization |
ListOfSwiOrganizationIO.xsd |
|
Service: PersonService Operation: createPerson |
ListOfSwiPersonIO.xsd |
|
OrganizationCrossReferenceService |
ListOfSwiOrganizationPublishIO.xsd |
|
PersonCrossReferenceService |
ListOfSwiPersonPublishIO.xsd |
These are the assumptions and constraints:
The Oracle Customer Hub integration supports these application and middleware components:
Oracle Fusion Middleware
Oracle AIA Foundation Pack
Oracle Customer Hub (Siebel UCM)
Siebel CRM
Oracle E-Business Suite
Oracle BRM
For more information about installing and selecting the participating applications (integration options) see Oracle Application Integration Architecture Installation and Upgrade Guide for Pre-Built Integrations Release 11.1 available on Oracle Technology Network. This guide is continually updated.
Note:
Any use of Customer MDM integration as part of a vertical/industry-specific initiative may require that the Customer MDM integration be certified on different combinations of applications, middleware, and AIA foundation pack objects.
Synchronization of delete actions on accounts, addresses, or contacts is not supported in this integration.
Synchronization of assets to OCH is not in scope for this integration.
Synchronization of account hierarchies to OCH is not in scope for this integration.
Synchronization of billing profile data to OCH is not in scope for this integration.
Synchronization of OCH households is not in scope for this integration.
Synchronization of financial accounts to OCH is not in scope for this integration.
Synchronization of households to OCH is not in scope for this integration.
Synchronization of billing profiles to OCH is not in scope for this integration.
OCH must be configured to auto-trigger web services for bi-directional create/update of customers with a participating application.
The significant differences between the Oracle Customer Hub, Siebel CRM, and EBO data models with respect to modeling Customer entities necessitate that the solution include built-in mapping and configuration settings.
These settings ensure that the out-of-the-box functionality and feature set of the solution are maximized and that the solution can be deployed independently or in conjunction with other integration solutions. For more information about configuration settings, see Chapter 7, "Configuring the Customer MDM Pre-Built Integration".
Oracle Customer Hub must be deployed as a separate instance from Siebel CRM.
Siebel CRM, Oracle BRM, and Oracle E-Business Suite must be set up as Registered Systems in Oracle Customer Hub/UCM to enable local cross-referencing, survivorship rules, and the ability to manage CRUD privileges on each participating application.
This set up is part of the standard Oracle Customer Hub/UCM configuration setup.
All organization and person messages published from Oracle Customer Hub are consumed by Oracle E-Business Suite out-of-the-box. The functional impact is that a customer account is established in Oracle E-Business Suite in advance of a known financial relationship with the party, which may be desired from a business perspective; however, this functionality may undermine the inherent definition of a customer account under the Oracle E-Business Suite Trading Community Architecture (TCA) model. If this functionality is not required and that the records should be consumed by Oracle E-Business Suite only in the case of a financial transaction, either the routing rules need to be modified so that messages are not published to Oracle E-Business Suite or the source system registrations within Oracle Customer Hub need to be updated so that Oracle E-Business Suite is not included for published messages.
The match and fetch integration flow from Oracle E-Business Suite to Oracle Customer Hub uses a Composite Application Framework user interface.
During a synchronization, if Oracle Customer Hub publishes an existing record for an incoming new record which is identified as a duplicate, the existing record is synchronized to the target applications whereas the incoming duplicate record is left as-is due to pending transactions.
In this case, the duplicate records have to be analyzed by an administrator and manually merged.
Oracle Customer Hub cross-references are created by Oracle Customer Hub when Customer entities (accounts and contacts) are published from applications to Oracle Customer Hub and identified by Oracle Customer Hub as referring to the same party.
Oracle Customer Hub cross-references can link records across applications (for example, ACME Account in CRM and ACME Account in Oracle BRM) as well as within one single application (for example, ACME Account and ACME Inc. Account in CRM).
Oracle Customer Hub cross-references may also be created for applications that are not integrated through AIA.
Although some participating applications have the ability to request a merge operation, only customer merges executed within Oracle Customer Hub are supported for this release.
While Oracle Customer Hub supports the internal unmerge of previously merged entities, no publishing takes place from Oracle Customer Hub as a result of an unmerge.
This implies that if unmerge is used within Oracle Customer Hub, the corresponding records are not automatically updated in Siebel CRM/Oracle E-Business Suite. This can lead to inconsistencies in customer data between Oracle Customer Hub and Siebel CRM/Oracle E-Business Suite unless a manual process is adopted for updating survivors and re-creating victims in Siebel CRM/Oracle E-Business Suite or the integration solution is extended during deployment to support unmerge publishing so that in Siebel CRM/Oracle E-Business Suite survivors are updated and victims re-created automatically.
Siebel CRM accounts should not be merged when Oracle BRM is present in the deployment. Merging Siebel CRM accounts creates issues if the corresponding accounts are not merged in Oracle BRM.
If the merger of survivor and victims does not take place in Oracle BRM, but it is performed in CRM, it is not possible to retrieve billing information for the victims. There can also be issues with assets that have been re-parented in Siebel CRM but not in Oracle BRM. A change order for a merged account may not be able to find the assets in the Oracle BRM, as they are still associated to the victim accounts.
The match process involves the passing of search criteria to the Oracle Customer Hub application to generate a list of possible candidates, and it is likely that these candidates have multiple addresses and phone numbers as part of their profile.
In the Siebel-enabled user interface, only the primary address and phone number fields are presented as part of each candidate profile. This compressed view of displayed values enhances the user experience without sacrificing the ability for the user to make an informed decision about the candidate to be fetched. The Composite Application Framework user interface displays all of the addresses that are associated to the candidates.
When an organization or contact is synchronized with Oracle Customer Hub, the related organization is not fetched from the AIA cross-reference and passed into Oracle Customer Hub.
In Oracle Customer Hub, accounts are supposed to be across business units, we call the Oracle Customer Hub web service without any organization IDs. However, within Oracle Customer Hub, the business unit is defaulted, as it is a required column. Therefore, we are supporting only one business unit for organization/contact synchronization into Oracle Customer Hub. However, if Oracle Customer Hub publishes records with multiple business units, those related organizations, if set up in the cross-reference and target applications are associated and supported as part of the integration flow.
OCH does not maintain cross-references for Oracle BRM customer data, because:
Oracle BRM does not publish customer data update/create to OCH. This is not in scope of the Customer MDM integration.
Customer data gets created in BRM only as part of the Order process. Only updates to Customer records will be sent to BRM through the Customer MDM integration.
AIA maintains cross-references for the accounts and contact information created in Oracle BRM.
Contact/Person update in OCH (Siebel UCM) does not propagate the changes to Oracle BRM.
Publishing of OCH unmerge service is not supported by this integration.
For Oracle BRM, Siebel CRM is the accounts master where accounts are created and updated.
Account merge is not supported for Oracle BRM.
Siebel CRM account hierarchy is not synchronized to the billing system.
Instead, the billing account /service account relationship on a Siebel CRM order line is sent to the billing system as parent account and child account, respectively.
Creation of customer data in Oracle BRM takes place only as part of the order-submission flow part of the Oracle Communications Order to Cash Integration Pack for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management integration.
This enforces that prospects accounts are not created in Oracle BRM.
Initial Load from Oracle BRM/Siebel CRM/Oracle E-Business Suite into OCH is not in scope.
Initial loads are typically specific to particular deployment and require a customized solution.
OCH has capabilities to master non-customers (partners, prospects, suppliers, and so on), generally as an input to campaign management processes, partner loyalty/relationship programs, or other processes.
Although this particular integration assumes that OCH acts as a hub for mastering customers defined as entities with which a selling relationship has been established, the integration flows modeled as part of this solution do not require that the entities being mastered are necessarily customers.
Customer data enrichment is done one-person-record at a time and only for the primary address.
|
 Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
