3 Process Integration for Customer Management

This chapter provides an overview of the process integration for customer management and discusses how to synchronize accounts from Siebel Customer Relationship Management (Siebel CRM) to Oracle E-Business Suite (Oracle EBS). Also discussed are Siebel CRM and Oracle EBS interfaces, core Oracle Application Integration Architecture (Oracle AIA) components, and integration services.

This chapter includes the following sections:

3.1 Process Integration for Customer Management

The process integration for Customer Management between Siebel CRM and Oracle EBS supports the following integration flows:

  • Synchronize new customer accounts from Siebel CRM to Oracle EBS: This flow enables the synchronization of new customer accounts from Siebel CRM to Oracle EBS as part of booking an order in the process integration for Oracle Order Management.

  • Update and synchronize customer accounts from Siebel CRM to Oracle EBS: This flow enables the synchronization of customer updates from Siebel CRM to Oracle EBS if the record exists in both Siebel CRM and Oracle EBS. If you update a customer record that does not exist in Oracle EBS, the customer record is not synchronized to Oracle EBS.

  • Synchronize customer accounts from Oracle EBS to Siebel CRM: In this flow, whenever you create or update a customer account in Oracle EBS, a real-time synchronization flow is initiated to synchronize the related party and customer account to a Siebel customer account.

  • Merge accounts from Oracle EBS to Siebel CRM: This flow maintains the transactional integrity that is essential to convert orders captured in Siebel CRM into booked orders. Because customer merge events may occur within Oracle EBS, this flow is initiated in Oracle EBS. This flow is initiated when a customer account is merged into another customer account. The merge operation is then performed in Siebel CRM.

  • Merge parties from Oracle EBS to Siebel CRM: This flow is initiated in Oracle EBS when an organization party is merged into another party. All of the child records that belong to the surviving party in the fulfillment system are synchronized to Siebel CRM after the merge.

  • Bulk load of customer data: Bulk load enables the extract, transformation, and load of initial customer data from Oracle EBS to Siebel CRM.

    This feature uses Oracle Data Integrator (ODI) to extract relevant customer data from Oracle EBS to load it to the appropriate Siebel CRM Enterprise Integration Manager (EIM) tables and insert it into base tables. This process also enables cross-referencing between Oracle EBS and Siebel CRM.

    For more information about initial data loads, see Chapter 2, "Loading Initial Data."

    For more information about using ODI for bulk processing, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack "Using Oracle Data Integrator for Bulk Processing".

3.1.2 Solution Assumptions and Constraints

The integration design assumes that:

  1. The default functionality of the Order to Cash: Siebel CRM - EBS pre-built integration is to only synchronize new customer accounts from Siebel CRM to Oracle EBS when an order is submitted. However, deployments can choose to directly synchronize new accounts from Siebel CRM to Oracle EBS by changing the AIAConfig property Account.ProcessUpdateEventsOnly from True to False.

  2. To initiate the Customer synchronization, users must run a concurrent job after any creates or updates to accounts or parties in Oracle EBS. A concurrent job is a batch job that raises events for creates or updates.

  3. As part of this integration, the customer number and the site number are auto-generated. In Oracle EBS, the system parameters Auto Generate Customer Number and Auto Generate Site Number are set at the operating unit level. The value for these parameters is set to Y so that customer number and site number are autogenerated in Oracle EBS.

  4. Account hierarchy synchronization is not in the scope of this release.

Figure 3-1 illustrates the overall flow for the customer process integration.

Figure 3-1 Customer Process Integration Flow

Customer Process Integration Flow

Customer information related to orders is maintained in both Siebel CRM and Oracle EBS, and is synchronized bidirectionally. New accounts can be created and maintained in Siebel CRM. An account is synchronized with Oracle EBS only when an order is booked for it in Siebel CRM.

Whenever a new customer account is created or updated in Oracle EBS, run a concurrent job (TCA Business Object Events - Raise Events) from the Trading Community Architecture (TCA) Manager responsibility. The synchronize flow is initiated after this request finishes successfully. The corresponding primary and bill to or ship to addresses are captured with the account and synchronized. Similarly, the contacts associated with the account are also synchronized.

Any updates to the account (or related addresses or contacts) in Oracle EBS are also synchronized with Siebel CRM. The updates to accounts in Siebel CRM are synchronized to Oracle EBS only if it has been synchronized before.

Whenever party accounts are merged in Oracle EBS, the corresponding accounts in Siebel CRM must be merged or their customers' Ids must be updated accordingly. When an account is inactivated in Oracle EBS, it is inactivated in Siebel CRM.

3.2 Synchronizing New Customer Accounts from Siebel CRM to Oracle EBS

The customer synchronization flow from Siebel CRM to Oracle EBS is orchestrated as part of the Order Process Management flow. This process flow synchronizes new accounts, contacts, and new or existing addressees associated with a Siebel order into Oracle EBS.

When working with the business process for synchronizing new customer accounts from Siebel CRM to Oracle EBS, consider the following guidelines:

  • Orders placed on behalf of Siebel accounts result in the creation of an Oracle organization party and a customer account with a corresponding bill-to/ship-to address.

    • Oracle Order application programming interface (API) requires a site Id and customer Id to associate the order to existing records in Oracle EBS; otherwise, a new (or duplicate) customer may be created in Oracle EBS.

    • Account contacts and site contacts may be created in Oracle EBS using the Oracle Order Management interface.

  • This account synchronization process creates location, party site, account site, site uses, and contact points in Oracle EBS.

Figure 3-2 illustrates the Synchronize New Customer Account integration flow.

Figure 3-2 Synchronize New Customer Account Integration Flow

Sync New Customer Acct. Integration Flow

3.2.1 Synchronize New Customer Account Integration Flow

This integration flow uses the following interfaces:

  • InterfaceCustomerToFulfillmentEBF

  • CustomerPartyEBSV2

  • CustomerPartyResponseEBSV2

  • QueryCustomerPartyListSiebelProvABCSImplV2

  • SyncCustomerPartyListEbizProvABCSImpl

  • SyncCustomerPartyListEbizAdapter

Figure 3-3 illustrates the Synchronize Customer Account integration scenario.

Figure 3-3 Synchronize New Customer Account Flow Sequence Diagram

Sync New Customer Acct. Flow Sequence Diag.

When you initiate the Synchronize New Customer Account process, the following events occur:

  1. In Siebel CRM, a user navigates to the Sales Order screen, creates a sales order for the account, changes its status to Booked, and then submits the order.

    These actions trigger the Order Submit process integration, which in turn instantiates the InterfaceCustomerToFulfillmentEBF service.

  2. The InterfaceCustomerToFulfillmentEBF invokes the CustomerPartyEBSV2 with the operation QueryCustomerPartyList and the message QueryCustomerPartyListEBM.

    This service fetches account data from Siebel CRM before creating the account in Oracle EBS.

  3. Invoking CustomerParyEBSV2 with the operation QueryCustomerPartyList routes the QueryCustomerPartyListEBM to the QueryCustomerPartyListSiebelProvABCSImplV2.

    This service transforms the QueryCustomerPartyListEBM into the Siebel-specific SiebelQueryAccountRequestABM and invokes the Siebel query account web service.

  4. The SiebelQueryAccount web service queries the Siebel database and fetches the account data that is sent back as a response using the message SiebelQueryAccountResponseABM.

  5. QueryCustomerPartyListSiebelProvABCSImplV2 transforms the response message SiebelQueryAccountResponseABM into the QueryCustomerPartyListResponseEBM.

    This response is sent back to the InterfaceCustomerToFulfillmentEBF through the CustomerPartyEBSV2.

  6. The InterfaceCustomerToFulfillmentEBF then invokes the SyncCustomerPartyListEbizProvABCSImpl and sends the account details in the message SyncCustomerPartyListEBM.

    The provider ABC implementation service then transforms the enterprise business message (EBM) into the Oracle EBS-specific message and invokes the Oracle EBS inbound adapter SyncCustomerPartyListEbizAdapter.

  7. The Oracle EBS Customer Creation API creates the account in Oracle EBS and returns the account details back in the OracleSyncAccountResponseABM response message.

  8. The response from the Oracle EBS API is transformed into the SyncCustomerPartyListResponseEBM, and the cross-reference tables are populated with the new or updated Oracle EBS identifiers.

    The responseEBM is then sent back to the InterfaceCustomerToFulfillmentEBF through the CustomerPartyResponseEBSV2.

  9. The response message SyncCustomerPartyListResponseEBM is then transformed into the ProcessCustomerPartyListResponseEBM and sent back to the InterfaceSalesOrderToCustomerEBFV2 using the SalesOrderOrchestrationResponseEBSV2.

    This action signifies the end of the account creation process in the Order Submit integration flow.

3.3 Updating and Synchronizing Customer Accounts from Siebel CRM to Oracle EBS

The Update and Synchronize Customer Account integration flow is initiated in Siebel CRM when a customer account is updated.

If a customer account that exists in both systems is updated in Siebel CRM, then that updated customer account must be synchronized to Oracle EBS. If a customer account that does not exist in Oracle EBS is updated, then the customer account is not synchronized to Oracle EBS.

Customer accounts can be updated by making changes to information, such as existing Siebel accounts, and changes to ship-to addresses, bill-to addresses, contact points, account/contact profiles, and so on.

Figure 3-4 illustrates the Update and Synchronize Customer Account integration flow.

Figure 3-4 Update and Synchronize Customer Account Integration Flow

Update Sync Customer Acct. Integration Flow

3.3.1 Update and Synchronize Customer Account Integration Flow

This integration flow uses the following interfaces:

  • SyncAcctSiebelAggrEventConsumer

  • SyncCustomerSiebelEventAggregator

  • SyncAccountSiebelReqABCSImpl

  • CustomerPartyEBSV2

  • SyncCustomerPartyListEbizProvABCSImpl

  • SyncCustomerPartyListEbizAdapter

Figure 3-5 illustrates the Update and Synchronize integration scenario.

Figure 3-5 Update and Synchronize Customer Account Flow Sequence Diagram

Update Sync Customer Acct. Flow Sequence Diag.

When you initiate the Update and Synchronize Account process, the following events occur:

  1. In Siebel CRM, a user navigates to the Accounts screen, queries an account, and updates an account attribute such as Address or Contact.

    As a result, Siebel CRM invokes the SyncCustomerSiebelEventAggregator with the SiebelAccountUpdatedABM message containing details of the account that was updated.

  2. The SyncCustomerSiebelEventAggregator invokes an aggregator adapter (SyncAccountSiebelAggregatorAdapter, SyncAddressSiebelAggregatorAdapter, or SyncContactSiebelAggregatorAdapter) based on the entity updated.

  3. The aggregator adapters internally perform the aggregation and enqueue the aggregated entity identifier in the AIA Aggregator table.

  4. The message in the table is picked up by the SyncAcctSiebelAggrEventConsumer service and invokes the sync operation of the Siebel requester ABC implementation service.

  5. The Siebel Requester ABC implementation, SyncAccountSiebelReqABCSImpl, queries the Siebel application in return with the entity identifier to fetch the entire entity ABM.

    It then transforms the Siebel ABM into the SyncCustomerPartyListEBM and invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2.

  6. Invoking the CustomerPartyEBSV2 with the SyncCustomerPartyList operation routes the SyncCustomerPartyListEBM to the Oracle EBS provider ABC implementation service, SyncCustomerPartyListEbizProvABCSImpl.

  7. The Oracle EBS provider ABC implementation service, SyncCustomerPartyListEbizProvABCSImpl, transforms the SyncCustomerPartyListEBM into the appropriate Oracle EBS-specific ABM and invokes the Oracle EBS API using the Oracle EBS adapter SyncCustomerPartyListEbizAdapter.

  8. The responses from the Oracle EBS adapter service are transformed into the SyncCustomerPartyListResponseEBM, during which the cross-reference tables are populated with the Oracle EBS identifier values.

    The Update and Synchronize Account integration flow ends here.

3.3.1.1 Event Aggregation

Synchronization of accounts updated in Siebel CRM to Oracle EBS is implemented using the Event Aggregation Programming Model.

When an account or its contacts and addresses are updated in Siebel CRM, a fine-grained event is triggered, which invokes the Oracle AIA Aggregator service, SyncCustomerSiebelEventAggregator, for every event. This service is a BPEL-based process, which invokes one of three database adapters that reside on the Oracle AIA database. These database adapters expose the Aggregator APIs, which are built using PL/SQL.

In Siebel CRM, an update or create action can lead to multiple events being raised based on the number of entities that were updated or the number of times they were updated. In these cases, The Aggregator is used to aggregate these events and process them in batches instead of processing each event individually.

In this flow, the Event Producer is Siebel CRM, which produces the events that must be aggregated. These messages are routed to the AIA layer by the service SyncCustomerSiebelEventAggregator. Based on the message type (Account, Contact or Address entity) the appropriate database adapter is then invoked. The actual aggregation happens in the database, with the data present in the self-referencing table AIA_AGGREGATED_ENTITIES. The PL/SQL APIs contain logic to maintain the relationships between the various entities and to also perform the aggregation based on the parent entity of the event. For this update flow from Siebel CRM to Oracle EBS, the parent entity is usually the Account, which can have one or more contacts and addresses. As part of the aggregation, there is one row per account (parent entity) in the aggregator table. Even if there are multiple events for the same account, there is only one corresponding entry in the aggregator table for the account.

At the end of the PL/SQL processing, the aggregated entities are present in the AIA_AGGREGATED_ENTITIES table. The Aggregator consumer service, SyncAcctSiebelAggrEventConsumer, continually polls on this table to initiate the synchronization. The polling interval determines how often messages are polled from the table and can be configured by the user based on the business need. The batch size for the consumer determines how many aggregated entities are picked up for synchronizing in a given transaction and can be changed from the default value. In other words, for a batch size of 1 at a time, only one account is consumed from the aggregator table and synchronized to Oracle EBS. For a batch size of 10, the first 10 accounts in the aggregator table are consolidated into one business message by the consumer service. The consumer service routes the polled entities to the Requester BPEL process, SyncAccountSiebelReqABCSImpl. On the Oracle Enterprise Manager Fusion Middleware Control, for every instance of the consumer SyncAcctSiebelAggrEventConsumer, there is an instance of the requester service. In scenarios where the batch size is 1, the requester service processes only one account. When the batch size is greater than one, there can be times where multiple accounts are processed in one instance of the SyncAccountSiebelReqABCSImpl service.

The message from the consumer routed to the SyncAccountSiebelReqABCSImpl service, at this point, contains only the Ids of the entities, like AccountId, AddressId, or ContactId. The complete information of the entity is queried back from Siebel CRM by the Requester service and the EBM is then built based on the retrieved information. The Enterprise Business Service, CustomerPartyEBSV2, then routes this EBM (SyncCustomerPartyListEBM) to the appropriate Provider service.

The provider service, SyncCustomerPartyListEbizProvABCSImpl, transforms the incoming EBM into the required Oracle EBS specific ABM and invokes the adapter service, SyncCustomerPartyListEbizAdapter. The SyncCustomerPartyListEbizAdapter exposes the Customer API, which creates or updates the account in Oracle EBS. The response from Oracle EBS is used to cross-reference the Ids and complete the transaction.

For more information about the Event Aggregation Programming Model, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Describing the Event Aggregation Programming Model".

3.3.1.2 Updating Polling Interval on FMW for the Aggregator Consumer Services

The PollingInterval for the Account and Contact Aggregator consumer services are, by default, set to 90s and 60s respectively. To change these values for your use cases:

  1. Go to the Oracle Enterprise Manager Fusion Middleware Control.

  2. Look for the SyncAcctSiebelAggrEventConsumer service located under Farm_soa_domain, SOA, soa-infra, default.

  3. Select this service and go to the Services and References section.

  4. Click service of type JCA Adapter.

    Go to the Properties tab and set the property Polling Interval to the desired value.

  5. Click Apply to save the changes.

  6. Restart the service-oriented architecture (SOA) server for the changes to take effect.

If needed, perform the same steps as for the contact consumer service, SyncContSiebelAggrEventConsumer.

3.4 Synchronizing Customer Accounts from Oracle EBS to Siebel CRM

The Synchronize Customer Account integration flow is initiated in Oracle EBS when a new customer account is created or an existing account is updated. Details relating to the account (account number, addresses, contacts, phone number, fax number, email address, and web address) are reflected in the target system, Siebel CRM.

When an account is created or updated in Oracle EBS, a record appears on a tracking table. Raising a TCA business event causes all of the account records in the tracking table to be stamped with an event identifier and enqueue event message to Oracle Advanced Queuing (AQ). The synchronize account process dequeues from AQ, reads the event identifier, and invokes the TCA API to extract all of the created or updated account information.

A create or update event is tracked in the following situations:

  • When a new party and account is created, the create account business event is raised.

  • When a party or account is updated, the update account business event is raised.

  • When an account is created on an existing party, the update account business event is raised.

When the SyncCustomerPartyList operation accepts the list of accounts, the requester ABC implementation service passes the entire list of accounts to the CustomerPartyEBSV2 and invokes the corresponding provider ABC implementation service.

Figure 3-6 illustrates the Synchronize Customer Account integration flow.

Figure 3-6 Synchronize Customer Account Integration Flow

Synchronize Customer Acct. Integration Flow

3.4.1 Synchronize Customer Account Integration Flow

This integration flow uses the following interfaces:

  • SyncCustomerPartyListEbizEventUpdateConsumer

  • SyncCustomerPartyListEbizEventCreateConsumer

  • QueryCustomerPartyListEbizCreateAdapter

  • QueryCustomerPartyListEbizUpdateAdapter

  • SyncCustomerPartyListEbizReqABCSImpl

  • CustomerPartyEBSV2

  • SyncCustomerPartyListSiebelProvABCSImpl

Figure 3-7 illustrates the Synchronize Customer Account integration scenario.

Figure 3-7 Synchronize Customer Account Flow Sequence Diagram

Sync account seq diagram

When you initiate the Synchronize Account process, the following events occur:

  1. In Oracle Applications, a user navigates to the Customer Standard form and creates an account with address and contact details.

    Then the user runs the TCA Raise Business Events concurrent program to raise the business events for the account creation. The events are captured in a database table to which the SyncCustomerPartyListEbizEventUpdateConsumer/SyncCustomerPartyListEbizEventCreateConsumer is listening. Different events are raised for a create scenario and an update scenario.

  2. The SyncCustomerPartyListEbizEventUpdateConsumer/ SyncCustomerPartyListEbizEventCreateConsumer dequeues the event payload from the queue and routes the request to the SyncCustomerPartyListEbizReqABCSImpl service.

    This service has two operations, create and update, for actions of the same name. The routing occurs based on the payload received from the event.

  3. The event payload received by the SyncCustomerPartyListEbizReqABCSImpl contains only the event identifier, not the entire account detail.

    Therefore, account details must be fetched from Oracle EBS based on the Event ID. Using the Query Apps adapters, QueryCustomerPartyListEbizCreateAdapter and QueryCustomerPartyListEbizUpdateAdapter, the account details are fetched based on the kind of action, update, or create.

  4. The Query adapters (QueryCustomerPartyListEbizCreateAdapter and QueryCustomerPartyListEbizUpdateAdapter) query the Oracle EBS database with the EbizQueryCustomerPartyRequestABM and fetch the account payload corresponding to the Event ID, which is the EbizQueryCustomerPartyResponseABM.

  5. In the SyncCustomerPartyListEbizReqABCSImpl, the QueryResponseABM is transformed into the SyncCustomerPartyListEBM, and the SyncCustomerPartyList operation of the CustomerPartyEBSV2 is invoked with this EBM.

  6. The CustomerPartyEBSV2 service routes the SyncCustomerPartyListEBM to the SyncCustomerPartyListSiebelProvABCSImpl.

    In this service, the SyncCustomerPartyListEBM is transformed into the SiebelAccountUpsertRequestABM, and the Siebel web service for account creation or update is invoked.

  7. The Siebel Customer Update web service does the actual creation or update of the account, address, and contact in Siebel and returns the appropriate response, SiebelAccountUpsertResponseABM.

    This response is received by the SyncCustomerPartyListSiebelProvABCSImpl service.

  8. 8. In the SyncCustomerPartyListSiebelProvABCSImpl service, the SiebelAccountUpsertResponseABM is transformed into the SyncCustomerPartyListResponseEBM, during which the cross-reference data is updated with the Siebel identifiers.

    The Account Update flow ends at this point; no response is returned to Oracle EBS.

3.5 Merging Accounts from Oracle EBS to Siebel CRM

The Merge Account integration flow is initiated in Oracle EBS when an account is merged into another account in Oracle EBS. A corresponding account merge operation is performed in the target Siebel CRM system.

When accounts are merged in Oracle EBS, a business event is raised in Oracle EBS. The event message contains a customer merge header identifier. The message is enqueued to AQ. The MergeAccountEbizEventAdapter dequeues the message and passes it to the MergeAccountEbizReqABCSImpl. The process reads the identifier and invokes the TCA API to extract account merge information.

Figure 3-8 illustrates the Merge Account integration flow.

Figure 3-8 Merge Account Integration Flow

Merge Account Integration Flow

3.5.1 Merge Account Integration Flow

This integration flow uses the following interfaces:

  • MergeAccountEbizEventConsumer

  • MergeAccountEbizReqABCSImpl

  • CustomerPartyEBSV2

  • CustomerPartyResponseEBSV2

  • SyncCustomerPartySiebelProvABCSImpl

  • QueryMergeAccountEbizAdapter

  • QueryCustomerPartyEbizAdapter

Figure 3-9 illustrates the Merge Account integration scenario.

Figure 3-9 Merge Account Flow Sequence Diagram

Merge Account Flow Sequence Diagram

When you initiate the create account process, the following events occur:

  1. In Oracle Applications, a user performs an account merge using the Account Merge form.

    The merge involves two entities, the Winning Account (To account) and the Losing Account (From account). The Account Merge operation generates a concurrent request that does the actual merge in Oracle EBS; then it raises the business events to the queue, where a consumer Oracle Apps adapter (MergeAccountEbizEventConsumer) is listening.

  2. The MergeAccountEbizEventConsumer dequeues the event payload from the queue and routes the request to the SyncCustomerParty operation of the MergeAccountEbizReqABCSImpl service.

  3. The event payload received by the MergeAccountEbizReqABCSImpl contains only the event identifier, not details of the entire account.

    Therefore, the account details must be fetched from Oracle EBS based on the Event ID. You use the Query Apps adapters, QueryMergeAccountEbizAdapter and QueryCustomerPartyEbizAdapter, to fetch the account details.

  4. The QueryMergeAccountEbizAdapter fetches the Winning and Losing Account identifiers from Oracle EBS based on the Event ID in the request payload.

    This response is then used to build the QueryCustomerPartyABM message, which is then used to fetch the individual account details.

  5. The QueryCustomerPartyEbizAdapter service fetches the account details (addresses, contact points, contacts, and so on) from Oracle EBS and sends the response back as QueryAppsCustomerPartyListResponseABM.

  6. The response from the QueryCustomerPartyEbizAdapter is transformed into the SyncCustomerPartyListEBM by the MergeAccountEbizReqABCSImpl service.

    Then the SyncCustomerPartyList operation of the CustomerPartyEBSV2 service is invoked.

  7. The CustomerPartyEBSV2 service routes the SyncCustomerPartyListEBM to the SyncCustomerPartySiebelProvABCSImpl, which then transforms the EBM to the Siebel SyncAccountRequestABM and invokes the Sync Siebel web service.

    The response sent by the Sync Siebel web service is then transformed into the SyncCustomerPartyListResponseEBM, during which the cross-reference data is updated. The response is sent back to the MergeAccountEbizReqABCSImpl using the CustomerPartyResponseEBSV2 service.

  8. The Account Merge into Siebel occurs in two stages

    First, the Losing account data is synchronized to the Winning account (based on an option that, when selected during the Merge, creates the same address using the Sync Siebel web service (until step 7). Second, the Merge Siebel web service is used to perform the actual merge in Siebel.

  9. As the second part of the merge, the MergeAccountEbizReqABCSImpl invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2 service, which in turn routes the EBM to the SyncCustomerPartyListSiebelProvABCSImpl.

  10. Based on a flag in the EBM, the SyncCustomerPartyListSiebelProvABCSImpl transforms the SyncCustomerPartyListEBM to the SiebelMergeAccountReqABM and invokes the Merge Siebel web service to perform the actual merge in the Siebel application.

    The response received from the web service is then used to update the cross-reference data while it is being transformed to the SyncCustomerPartyListResponseEBM.

  11. The Merge Account flow ends with no further responses returned to Oracle EBS.

3.6 Merging Parties from Oracle EBS to Siebel CRM

The Merge Party integration flow is initiated in Oracle EBS when an organization party is merged into another party in Oracle EBS. Because the Party Id is part of the Oracle Id in the Id cross-reference, the Merge Party flow updates the corresponding Oracle Id value in the Id cross-reference. In addition, all accounts of the surviving party in Oracle EBS are synchronized to Siebel CRM after the merge.

When parties are merged in Oracle EBS, a business event is raised in Oracle EBS. The event message contains the batch and winning party identifier. The message is enqueued to AQ. The MergePartyEbizEventAdapter dequeues the message from AQ and passes it to the MergePartyEbizReqABCSImpl. The process reads the identifiers and invokes the TCA API to extract merge party information.

Figure 3-10 illustrates the Merge Party integration flow.

Figure 3-10 Merge Party Integration Flow

Merge Party Integration Flow

3.6.1 Merge Party Integration Flow

This integration flow uses the following interfaces:

  • MergePartyEbizEventConsumer

  • MergePartyEbizReqABCSImpl

  • CustomerPartyEBSV2

  • SyncCustomerPartySiebelProvABCSImpl

  • QueryRelatedOrgCustEbizAdapter

  • QueryMergeOrgCustEbizAdapter

  • QueryPartyMergeEbizAdapter

Figure 3-11 illustrates the Merge Party integration scenario.

Figure 3-11 Merge Party Flow Sequence Diagram

Merge Party Flow Sequence Diagram

When you initiate the Merge Party process, the following events occur:

  1. In Oracle Applications, a user performs a party merge using the Party Merge form. The merge involves two entities, the Winning Party (To account) and the Losing Party (From account).

    The Party Merge operation generates a concurrent request that does the actual merge in Oracle EBS and then raises the business events to the queue, where a consumer Oracle EBS adapter (MergePartyEbizEventConsumer) is listening.

  2. The MergePartyEbizEventConsumer dequeues the event payload from the queue and routes the request to the SyncCustomerParty operation of the MergePartyEbizReqABCSImpl service.

  3. The event payload received by the MergePartyEbizReqABCSImpl contains only the event identifier, not details of the entire account.

    Therefore, account details must be fetched from Oracle EBS based on the Event ID. Use the Query Apps adapters, QueryPartyMergeEbizAdapter, QueryMergeOrgCustEbizAdapter, and QueryRelatedOrgCustEbizAdapter, to fetch the account details. When the parties being merged are of type Organization, use QueryMergeOrgCustEbizAdapter. When the parties being merged are not of type Organization, use QueryRelatedOrgCustEbizAdapter.

  4. The QueryPartyMergeEbizAdapter fetches the Winning and Losing Account identifiers from Oracle EBS based on the event ID in the request payload.

    This response is then used to build the QueryCustomerPartyABM message, which is then used to fetch the individual account details.

  5. The QueryMergeOrgCustEbizAdapter service fetches account details for the Organization type parties (addresses, contact points, contacts, and so on) from Oracle EBS and sends the response back as QueryAppsCustomerPartyListResponseABM.

    The QueryRelatedOrgCustEbizAdapter service fetches account details for parties being merged that are not of type Organization.

  6. The response from the QueryMergeOrgCustEbizAdapter (or QueryRelatedOrgCustEbizAdapter) is transformed into the SyncCustomerPartyListEBM by the MergePartyEbizReqABCSImpl service, which then invokes the SyncCustomerPartyList operation of the CustomerPartyEBSV2 service.

  7. The CustomerPartyEBSV2 service routes the SyncCustomerPartyListEBM to the SyncCustomerPartySiebelProvABCSImpl, which then transforms the EBM into the Siebel SyncAccountRequestABM and invokes the Sync Siebel web service.

    Because no parties are available in Siebel, the Merge service is not used in this flow. Instead, the Sync service is used to synchronize the accounts of the parties being merged in Oracle EBS.

  8. The response sent by the Sync Siebel web service is then transformed into the SyncCutomerPartyListResponseEBM, during which the cross-reference data is updated.

    The Merge Party flow ends at this point, and no further responses are returned to Oracle EBS.

3.7 Siebel CRM Interfaces

These Siebel CRM web services are available for the Customer Management integration flow:

Inbound Siebel CRM Web Services

  • Service Name: SWICustomerParty

    • Operation Name: SWICustomerPartyInsertOrUpdate

    • Request Schema: SWICustomerPartyInsertOrUpdate_Input

    • Response Schema: SWICustomerPartyInsertOrUpdate_Output

  • Service Name: SWICustomerParty

    • Operation Name: SWICustomerPartyQueryByExample

    • Request Schema: SWICustomerPartyQueryByExample_Input

    • Response Schema: SWICustomerPartyQueryByExample_Output

  • Service Name: SWICustomerParty

    • Operation Name: SWICustomerPartySynchronize

    • Request Schema: SWICustomerPartySynchronize_Input

    • Response Schema: SWICustomerPartySynchronize_Output

  • Service Name: SWICustomerParty

    • Operation Name: SWIMergeServices

    • Request: SchemaSWIMergeServicesMerge_Input

    • Response Schema: SWIMergeServicesMerge_Output

Outbound Siebel CRM Web Services

These events are raised in Siebel and are consumed by this integration:

  • Account Updated

    • Siebel calls the SyncCustomerSiebelEventAggregator service with an AccountUpdatedABM.

  • Contact Updated

    • Siebel calls the SyncCustomerSiebelEventAggregator service with a ContactUpdatedABM.

  • Address Updated

    • Siebel calls the SyncCustomerSiebelEventAggregator service with an AddressUpdatedABM.

These are the Siebel outbound services:

  • CalculateShippingChargeSalesOrderSiebelReqABCSImpl

  • CheckATPSalesOrderSiebelReqABCSImpl

  • ConfiguratorUserLangSiebelAdapter

  • CreditCheckSalesOrderSiebelReqABCSImpl

  • FetchAccountSiebelReqABCSImpl

  • FetchContactSiebelReqABCSImpl

  • MatchAccountSiebelReqABCSImpl

  • MatchContactSiebelReqABCSImpl

  • PaymentAuthorizationSalesOrderSiebelReqABCSImpl

  • ProcessQuoteSiebelJMSProducer

  • ProcessSalesOrderSiebelJMSProducerV2

  • RequestProductStructureSiebelJMSProducer

  • SyncCustomerSiebelEventAggregator

  • ESB_ConfiguratorCopyConfigEbizAdapter_Service

For more information about Siebel web services, see CRM Web Services Reference.

3.8 Oracle EBS Interfaces

These Oracle EBS web services are available for the Customer Management flow integration:

Inbound to Oracle EBS Web Services

This integration uses these Oracle artifacts:

  • Service Name: HZ_ORG_CUST_BO_PUB.GET_ORG_CUSTS_CREATED

  • Service Name: HZ_ORG_CUST_BO_PUB.GET_ORG_CUSTS_UPDATED

  • Service Name: HZ_AIA_CUSTOM_PKG. SYNC_ACCT_ORDER

  • Service Name: HZ_AIA_CUSTOM_PKG.get_acct_merge_obj

  • Service Name: HZ_AIA_CUSTOM_PKG.get_party_merge_objs

  • Service Name: HZ_AIA_CUSTOM_PKG.get_merge_org_custs

  • Service Name: HZ_AIA_CUSTOM_PKG.get_related_org_cust_objs

Outbound from Oracle EBS Event Interfaces

These events are raised in Oracle and are consumed by this integration:

  • oracle.apps.ar.hz.OrgCustBO.create

  • oracle.apps.ar.hz.OrgCustBO.update

  • oracle.apps.ar.hz.CustAccount.merge

  • oracle.apps.ar.hz.Party.merge

For more information about Oracle EBS web services and documentation prior to Release 12.1.3, see the library on Oracle Technology Network: http://www.oracle.com/technetwork/documentation/applications-167706.html?. For Oracle EBS documentation for R12.1.3 and beyond, see this library: https://download.oracle.com/docs/cd/E18727_01/index.htm?

3.9 Core Oracle AIA Components

The Customer Management integration uses the following horizontal components:

  • CustomerPartyEBO

  • InterfaceCustomerToFulfillmentEBF

  • QueryCustomerPartyListEBM

  • QueryCustomerPartyListResponseEBM

  • SyncCustomerPartyListEBM

  • SyncCustomerPartyListResponseEBM

  • CustomerPartyEBS

The industry enterprise business object (EBO) and enterprise business message XML schema (EBM XSD) files are located here: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Core/EBO/

The industry enterprise business service (EBS) WSDL files are located here: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/

For detailed documentation of individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in Oracle Enterprise Repository.

For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."

EBOs can be extended, for instance, to add new data elements. These extensions are protected, and they remain intact after a patch or an upgrade.

For more information, see Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Extensibility."

3.10 Integration Services

These services are delivered with this integration:

  • CustomerPartyEBSV2

  • CustomerPartyResponseEBSV2

  • InterfaceCustomerToFulfillmentEBF

  • SyncAccountSiebelReqABCSImpl

  • QueryCustomerPartyListSiebelProvABCSImplV2

  • SyncCustomerPartyListSiebelProvABCSImpl

  • SyncCustomerPartyListEbizReqABCSImpl

  • SyncCustomerPartyListEbizProvABCSImpl

  • MergeAccountEbizReqABCSImpl

  • MergePartyEbizReqABCSImpl

  • SyncCustomerSiebelEventAggregator

  • SyncAccountSiebelAggregatorAdapter

  • SyncContactSiebelAggregatorAdapter

  • SyncAddressSiebelAggregatorAdapter

  • SyncAcctSiebelAggrEventConsumer

  • SyncContSiebelAggrEventConsumer

  • SyncCustomerPartyListEbizEventUpdateConsumer

  • SyncCustomerPartyListEbizEventCreateConsumer

  • MergeAccountEbizEventConsumer

  • MergePartyEbizEventConsumer

  • SyncCustomerPartyListEbizAdapter

For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."

3.10.1 CustomerPartyEBSV2

The CustomerPartyEBSV2 Enterprise Business Service is routing service that exposes all of the enterprise operations that can be performed with a CustomerParty enterprise object. All of the Customer Management integration flows make use of the operations provided by this enterprise business service.

The CustomerPartyEBSV2 service uses these operations:

  • QueryCustomerPartyList

  • SyncCustomerPartyList

For more information about this EBS, see the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."

3.10.2 CustomerPartyResponseEBSV2

The CustomerPartyResponseEBSV2 Enterprise Business Service is a routing service that exposes all of the enterprise response operations that can be performed with a CustomerParty enterprise object. All of the Customer Management integration flows make use of the response operations provided by this.

The CustomerPartyResponseEBSV2 EBS uses this operation SyncCustomerPartyListResponse.

For more information about this EBS, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."

3.10.3 InterfaceCustomerToFulfillmentEBF

The InterfaceCustomerToFulfillmentEBF enterprise business flow is implemented as an asynchronous business process execution language (BPEL) process, using the asynchronous message exchange pattern (with delayed response) framework of Oracle AIA.

This enterprise business flow creates or synchronizes all the customer accounts and related components (such as address and contacts) in sequence to the appropriate fulfillment system. This service is invoked from the Order integration flow with a list of Customer Account IDs, Address IDs and contact IDs, and the Target System ID. When the process is complete, a response is returned to the Order flow confirming that all accounts, addresses, and contacts have been set up in the target fulfillment system and that Order processing can continue. In case of an error, an error code is returned, signaling that Order processing cannot continue.

Assumption/Constraint: A single target back-office system is identified within the Order flow, and this information is passed to this service through the EBM header. The source CRM system must also pass through the EBM header.

This service involves a single operation, and the input is an instance of the ProcessCustomerPartyListEBM message containing the target fulfillment system identifier in the EBM header. The Data Area of the message contains one or more customer account IDs and, for each account, one or more address and contact IDs that must be synchronized to the target fulfillment system. Also, enough identifying information must be available to support querying back to the proper CRM source system for the detailed account, customer, and contact data.

The service looks up the cross-reference values for Organization ID. If any of the IDs are not present in the source CRM system, the processes ends in error.

The service also establishes the cross-reference for Account ID, Contact ID, and Address ID between Common Values and corresponding Oracle Apps IDs.

The return message contains the same list of account IDs that were passed in the request, with additional flags to indicate success or failure and appropriate error messages, for each account.

The service also assumes that before calling the Order process, invoking this service would have established the cross-reference for the Siebel to Common ID for all new accounts, addresses, and contacts that are part of the Siebel sales order or quote.

For more information about this flow, see Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding the Oracle AIA Reference Architecture," AIA Service Artifacts.

3.10.4 SyncAccountSiebelReqABCSImpl

The SyncAccountSiebelReqABCSImpl service is responsible for transforming the Siebel messages into the appropriate Sync Customer Account EBM format and invoking the SyncCustomerPartyList operation of the CustomerPartyEBSV2.

3.10.5 QueryCustomerPartyListSiebelProvABCSImplV2

The QueryCustomerPartyListSiebelProvABCSImplV2 service is invoked by the CustomerPartyEBSV2 when the routing rules determine that Siebel is to be the service provider for the CustomerPartyEBS-QUERY operation. This determination occurs during the integration flow that is initiated by the account sync portion of the order flow.

This service has one synchronous request/reply operation: QueryCustomerPartyList.

The input and output messages are instances of the QueryCustomerPartyListRequestEBM and QueryCustomerPartyListResponseEBM, respectively.

3.10.6 SyncCustomerPartyListSiebelProvABCSImpl

CustomerPartyEBSV2 invokes the SyncCustomerPartyListSiebelProvABCSImpl service when the routing rules determine that Siebel is to be the service provider for the SyncCustomerPartyList EBS operation. This occurs in the following scenarios:

When you create or update a customer account in Oracle Apps. This service is initiated to synchronize customer accounts from Oracle to Siebel. An update web service call to Siebel is invoked.

Before you merge an account, this service is initiated to synchronize surviving account information from Oracle to Siebel. In the sync operation, if an address with row ID 100 is in Siebel but not in the request message, then the address is removed. A synchronize web service call to Siebel is invoked.

This service has one synchronous request/reply operation: SyncCustomerParty.

The input and output messages are instances of the SyncCustomerPartyListEBM and SyncCustomerPartyListResponseEBM, respectively.

3.10.7 SyncCustomerPartyListEbizReqABCSImpl

The SyncCustomerPartyListEbizReqABCSImpl service is responsible for transforming the Oracle EBS account, contact, or address create or update event message into the appropriate SyncCustomerPartyListEBM format and invoking the SyncCustomerPartyList operation of the CustomerPartyEBSV2.

This service has two asynchronous operations: create and update.

3.10.8 SyncCustomerPartyListEbizProvABCSImpl

The CustomerPartyEBSV2 invokes the SyncCustomerPartyListEbizProvABCSImpl service when the routing rules determine that Oracle Apps is to be the service provider of the SyncCustomerPartyList EBS operation. This determination occurs during the integration flow that is initiated by the account create processing portion of the Sales Order flow.

This service has one synchronous request/reply operation: SyncCustomerPartyList.

3.10.9 MergeAccountEbizReqABCSImpl

The MergeAccountEbizReqABCSImpl service is responsible for transforming the Oracle Apps account, contact, or address merge event message into the appropriate SyncCustomerPartyListEBM format and invoking the CustomerPartyEBSV2.

This service has one asynchronous request operation: SyncCustomerParty.

Figure 3-12 illustrates the MergeAccountEbizReqABCSImpl process activity:

Figure 3-12 MergeAccountEbizReqABCSImpl Activity Diagram

MergeAccountEbizReqABCSImpl

3.10.10 MergePartyEbizReqABCSImpl

The MergePartyEbizReqABCSImpl service is responsible for transforming the Oracle Apps account, contact, or address merge event message into the appropriate SyncCustomerPartyEBM format.

This service has one asynchronous request/reply operation: SyncCustomerParty.

Figure 3-13 illustrates the MergePartyEbizReqABCSImpl process activity:

Figure 3-13 MergePartyEbizReqABCSImpl Activity Diagram

MergePartyEbizReqABCSImpl

3.10.11 SyncCustomerSiebelEventAggregator

The SyncCustomerSiebelEventAggregator is implemented as a BPEL process because it involves Java Message Service (JMS) header manipulations. This service has three operations, one for each kind of event raised by the Siebel application when an account, contact, or address is created or updated. Each operation invokes the corresponding aggregator adapter service, which does the aggregation of the event in the AIA Aggregator table. The following operations are defined in this service:

  • aggregateaccountevent

  • aggregatecontactevent

  • aggregateaddressevent

For more information about the event aggregation design pattern, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Describing the Event Aggregation Programming Model."

3.10.12 SyncAccountSiebelAggregatorAdapter

The SyncAccountSiebelAggregatorAdapter is implemented as a process with a database adapter and routing services. This service aggregates the account events generated in the Siebel application when an account is created or updated. This service invokes a PL/SQL procedure, AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_ACCOUNT, which does the actual aggregation in the AIA aggregator table.

For more information about the event aggregation design pattern, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Describing the Event Aggregation Programming Model."

3.10.13 SyncContactSiebelAggregatorAdapter

The SyncContactSiebelAggregatorAdapter is implemented as a process with a database adapter and routing services. This service aggregates the account events generated in the Siebel application when an account is created or updated. This service invokes a PL/SQL procedure, AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_CONTACT, which does the actual aggregation in the AIA aggregator table.

For more information about the event aggregation design patter Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Describing the Event Aggregation Programming Model."

3.10.14 SyncAddressSiebelAggregatorAdapter

The SyncAddressSiebelAggregatorAdapter is implemented as a process with a database adapter and routing services. This service aggregates the account events generated in the Siebel application when an account is created or updated. This service invokes a PL/SQL procedure, AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_ADDRESS, which does the actual aggregation in the AIA aggregator table.

For more information about the event aggregation design pattern, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Describing the Event Aggregation Programming Model."

3.10.15 SyncAcctSiebelAggrEventConsumer

The SyncAcctSiebelAggrEventConsumer service is responsible for dequeueing the aggregated Siebel Account identifiers from the AIA Aggregator table and invoking the appropriate operation of the Requestor application business connector service (ABCS), SyncAccountSiebelReqABCSImpl.

3.10.16 SyncContSiebelAggrEventConsumer

The SyncContSiebelAggrEventConsumer service is responsible for dequeueing the aggregated Siebel Contact identifiers from the AIA Aggregator table and invoking the appropriate operation of the Requestor ABCS, SyncContactSiebelReqABCSImpl.

3.10.17 SyncCustomerPartyListEbizEventCreateConsumer

The SyncCustomerPartyListEbizEventCreateConsumer service is responsible for dequeueing the Oracle create account business event payloads from AQ and invoking the appropriate operation of the Requestor ABCS, SyncCustomerPartyEbizReqABCSImpl. The dequeue operation is done depending on the CorrelationID in AQ. For customer create, the correlation ID is oracle.apps.ar.hz.OrgCustBO.create.

Two business events, each with one operation, are available for reading each of the three types of Oracle Apps messages from the AQ:

  • oracle.apps.ar.hz.OrgCustBO.create.

  • oracle.apps.ar.hz.OrgCustBO.update

3.10.18 SyncCustomerPartyListEbizEventUpdateConsumer

The SyncCustomerPartyListEbizEventUpdateConsumer service is responsible for dequeueing the Oracle create or update account business event payloads from AQ and invoking the appropriate operation of the Requestor ABCS, SyncCustomerPartyEbizReqABCSImpl. The dequeue operation is done depending on the CorrelationID in AQ. For customer create, the correlation ID is oracle.apps.ar.hz.OrgCustBO.create. For customer update, the correlation ID is oracle.apps.ar.hz.OrgCustBO.update.

Two business events, each with one operation, are available for reading each of the three types of Oracle Apps messages from the AQ:

  • oracle.apps.ar.hz.OrgCustBO.create

  • oracle.apps.ar.hz.OrgCustBO.update

3.10.19 MergeAccountEbizEventConsumer

The MergeAccountEbizEventConsumer service is responsible for dequeueing the Oracle account merge business event payloads from AQ and invoking the appropriate operation of the Requestor ABCS. For the account merge, the correlation ID is oracle.apps.ar.hz.CustAccount.merge and the event adapter is MergeAccountEbizEventAdapter. The dequeue operation is done depending on the CorrelationID in AQ.

One business event with one operation is available for reading each of the three types of Oracle Apps messages from the AQ oracle.apps.ar.hz.CustAccount.merge.

3.10.20 MergePartyEbizEventConsumer

The MergePartyEbizEventConsumer service is responsible for dequeueing the Oracle party merge business event payloads from AQ and invoking the appropriate operation of the Requestor ABCS. For the party merge, the correlation ID is oracle.apps.ar.hz.Party.merge and the event adapter is MergePartyEbizEventAdapter. The dequeue operation is done depending on the CorrelationID in AQ.

One business event with one operation is available for reading each of the three types of Oracle Apps messages from the AQ oracle.apps.ar.hz.Party.merge.

3.10.21 SyncCustomerPartyListEbizAdapter

The SyncCustomerPartyListEbizAdapter service is an Oracle EBS Adapter service registered in Mediator. This adapter service exposes the HZ_AIA_CUSTOM_PUB.sync_acct_order PL/SQL API. This wrapper API is delivered as part of EBS HZ.N.

This service is the interface through which an order is created in Oracle EBS. SyncCustomerPartyListEbizProvABCSImpl invokes this service as part of the Update Customer and Create Order integration flow.

The SyncCustomerPartyListEbizAdapter service exposes the Sync customer party operation of the PL/SQL wrapper API. This operation is a synchronous request + reply operation. If you register this adapter service in Mediator, it exposes a SOAP binding, which is used in this integration to invoke the service from the SyncCustomerPartyListEbizProvABCSImpl.