3 Process Integration for Customer Management

This chapter provides an overview of customer management process integration, and describes customer data synchronization, how to synchronize accounts from CRM on Demand to Oracle E-Business Suite (Oracle EBS) and from Oracle EBS to Oracle CRM on Demand, Oracle EBS and Oracle CRM on Demand interfaces, core Oracle Application Integration Architecture (Oracle AIA) interfaces, and integration services.

This chapter includes the following sections:

Section 3.1, "Overview"
Section 3.2, "Customer Data Synchronization"
Section 3.3, "Synchronizing Accounts from CRM On Demand to Oracle EBS"
Section 3.4, "Synchronizing Accounts from Oracle EBS to CRM On Demand"
Section 3.5, "Oracle CRM On Demand Interfaces"
Section 3.6, "Oracle EBS Interfaces"
Section 3.7, "Core Oracle AIA Components"
Section 3.8, "Integration Services"

3.1 Overview

The process integration for customer account management between Oracle EBS and CRM On Demand supports these integration flows:

Batch load account data

This flow enables the extract, transformation, and initial load of account data from Oracle EBS to CRM On Demand. This process also establishes the cross-reference of account data between Oracle EBS and CRM On Demand.
Synchronize accounts from Oracle EBS to CRM On Demand

This flow enables the synchronization of accounts from Oracle EBS to CRM On Demand. When an account is created or updated in Oracle EBS, the account details, such as addresses, contacts, and phone and fax information, are synchronized to CRM On Demand.
Synchronize accounts from CRM On Demand to Oracle EBS

This flow enables the synchronization of customer accounts from CRM On Demand to Oracle EBS. When a new account is created in CRM On Demand that is marked for synchronization, that is, the Integration Status field is set to Sync ON, a real-time synchronization flow is initiated to synchronize the CRM On Demand account to the related party and account in Oracle EBS.
Update and synchronize accounts from CRM On Demand to Oracle EBS

This flow enables the synchronization of account updates from CRM On Demand to Oracle EBS for account records that have been flagged for synchronization within CRM On Demand, that is, for records in which the Integration Status field is set to Sync ON.
Merge accounts

This flow is initiated in Oracle EBS when an account is merged into another account. The corresponding merge operation is then performed in CRM On Demand on the related accounts. Upon merge completion, the child records of the losing account record point to the winning account record.
Merge parties

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 are synchronized to CRM On Demand after the merge.

For more information about initial batch loading of data, see Chapter 2, "Initial Loading and Synchronization of Data".

3.1.1 Solution Assumptions and Constraints

These are the integration solution assumptions and constraints:

The synchronization of account hierarchies across systems, that is, account-to-account relationships, is not in the scope of this release.
To initiate the account synchronization, you must run a concurrent job in Oracle EBS after any creates or updates to accounts or parties.

A concurrent job is a batch job that raises events for creates or updates since the last concurrent job.
Bill-To and Ship-To usage on the same account address record in Oracle EBS is not supported. If the same address (Account-Site) is to be designated as Bill-To and Ship-To address in Oracle EBS, create two addresses with the different Site Usage Types associate to each. If you do not create addresses with the different Site Usage Types, unpredictable results occur while syncing from CRM On Demand to Oracle EBS.
As part of this integration, the customer number and the site number are autogenerated.

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.
The account integration in version 3.1 of the pre-built integration does not include a mapping of the CRM On Demand Account Description or Furigana name because the CustomerParty Enterprise Business Object (EBO) does not support these attributes.
Within Oracle EBS, you can create multiple phone numbers for an account or account-contact with an associated type (main, fax, and so on), but can specify only one primary phone number across types.

Within CRM On Demand, separate fields capture the main phone number, fax number, and so on, and only one of each. From CRM On Demand to Oracle EBS, the mapping is straightforward, that is, the main phone number in CRM On Demand is mapped to the telephone number in Oracle EBS. From Oracle EBS to CRM On Demand, the first active phone number that appears in the CustomerParty Enterprise Business message (EBM) message is synchronized with CRM On Demand.

When synching account-contact telephone numbers from Oracle EBS to CRM On Demand, the Communication Type and Purpose fields must be set as follows if the telephone number entered in Oracle EBS is to successfully synchronize to CRM On Demand:

Table 3-1 Communication Type and Purpose for CRM On Demand Telephone Mapping

Oracle EBS Communication Type	Oracle EBS Communication Purpose	CRM On Demand Telephone Mapping
Telephone	Personal	HomePhone
Telephone	Business	WorkPhone
Mobile	not applicable	Cellular

Within Oracle EBS, Party_Site (address) assignments across multiple accounts are not supported, that is, a Party_Site associated with an Organization party can be assigned only to one account.

If a single Party_Site is assigned to multiple accounts, updates to the address information within CRM On Demand may not propagate across the accounts for which the address is shared.

Figure 3-1 illustrates the overall flow for the account process integration:

Figure 3-1 Customer Account Process Integration Flow

This image is described in surrounding text.

When 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 Manager responsibility. The synchronize flow is initiated after this request finishes successfully. The corresponding primary, bill to, and 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 CRM On Demand. The updates to accounts in CRM On Demand are synchronized with Oracle EBS only if they have been synchronized before and if the account records are flagged for synchronization in CRM On Demand.

When an account is inactivated in Oracle EBS, it is inactivated in CRM On Demand; that is, if Account Status is set to Inactive in Oracle EBS, the corresponding account in CRM On Demand is also set to Inactive. The cross-references between the two inactivated accounts remain unchanged, and subsequent updates to the accounts continue to be synchronized.

Note:

An account that is set to Inactive in Oracle EBS is set to Inactive at the account level, not at the organization or party level.

3.2 Customer Data Synchronization

After the initial load of customer account data from Oracle EBS to CRM On Demand is complete, mapped attributes of account and account-contact records that exist in both applications are synchronized bidirectionally when accounts and account-contacts are created or updated so that data integrity is maintained.

Account data is synchronized when a new account is created, or whenever an existing account record that exists in both applications and that is flagged for synchronization in CRM On Demand is changed in either application.

The Oracle Lead to Order Integration Pack for Oracle CRM On Demand and Oracle EBS pre-built integration enables you to designate the specific account and account-contact records that are to be enabled for synchronization from CRM On Demand to Oracle EBS. All newly created or updated accounts are synchronized from Oracle EBS to CRM On Demand.

These synchronization rules apply:

New customer accounts and account-contacts created in CRM On Demand that are flagged for synchronization propagate to Oracle EBS.
In Oracle EBS, you cannot flag a specific account for synchronization to CRM On Demand. All customer accounts (that is, all Organization parties with an associated account number) created or updated in Oracle EBS initiate synchronization to CRM On Demand.
- Data associated with accounts that are updated in CRM On Demand and that are flagged for synchronization propagate to Oracle EBS.
- Account data updated in Oracle EBS propagates to CRM On Demand.
- If the account in Oracle EBS has not previously been synchronized and an update is made in Oracle EBS, the account is created in CRM On Demand.
Accounts and account-contacts created in CRM On Demand that have not been flagged for synchronization are synchronized to Oracle EBS when the associated CRM On Demand opportunity is converted to an Oracle EBS quote or order.

3.2.1 Enabling Account Synchronization in CRM On Demand

In CRM On Demand, the Integration Status field on the Account detail, Contact detail, or Product detail page indicates whether:

A record is enabled for synchronization (Sync On)
A record is not enabled for synchronization (Sync Off)
A record has failed to synchronize (Sync Failed)

If a record fails to synchronize, an error message is logged to the Integration Message field on the record.

You can set the value of the Integration Status field using the following procedure.

To enable a record for synchronization to Oracle EBS:

Navigate to the Account Detail or Contact Detail page as appropriate.
Set the value of the Integration Status field to Sync On.

The Integration Status field of an account that is synchronized from Oracle EBS to CRM On Demand is automatically set to Sync On.
Save the record.

Depending on your business environment, you can:

Optionally allow users to set the value of the Integration Status field on the Account detail and Contact detail pages manually.
Define business rules that determine when the value of the Integration Status field is Sync On by default. You can define business rules using the Expression Builder functionality for the Integration Status field.

For more information about Expression Builder, see CRM On Demand Online Help.
Assign responsibility for flagging records for synchronization from CRM On Demand to Oracle EBS to a designated administration user role within your organization.

Table 3-2 describes the expected behavior when the integration status of a record changes.

Table 3-2 Expected Behavior for Integration Status Changes

Integration Status	Resultant Behavior	Details
From Sync Off to Sync On or from Blank to Sync On	Results in an insert of the corresponding record from CRM On Demand to Oracle EBS.	Insert, update, and delete association and disassociation transactions are captured by workflow or integration events on the CRM On Demand side and placed in the Integration Event Queue for processing. At this point, the corresponding record is enabled for sync to the target application, that is, Oracle EBS.
From Sync On to Sync Off	Results in no new updates going from CRM On Demand to Oracle EBS. New updates in CRM On Demand are not tracked. Updates to CRM On Demand from Oracle EBS still occur.	Insert, update, and delete association and disassociation transactions are no longer captured by workflow or integration events on the CRM On Demand side and are not placed in the Integration Event Queue for processing. At this point, the corresponding record is disabled for synchronization with Oracle EBS.
From Sync On to Sync Failed	Results in no new updates going from CRM On Demand to Oracle EBS. Updates from Oracle EBS to CRM On Demand continue to be processed (if possible).	The toggle to this state should happen automatically only if a sync failure that is either related to a business rule failing or a system error. If the integration status is Sync Failed, any insert, update, and delete association and disassociation transactions are no longer captured by workflow or integration events on the CRM On Demand side and are not placed in the Integration Event queue for processing. At this point, the corresponding record is disabled for sync to Oracle EBS.
From Sync Failed to Sync On	Results in a resync of the record from CRM On Demand to Oracle EBS	After the reason for the sync failure has been corrected, an admin user can set the integration status back to Sync On, which results in a resync from CRM On Demand to Oracle EBS. Once again, insert, update, and delete association and disassociation transactions are captured by workflow or integration events on the CRM On Demand side and placed in the Integration Event queue for processing. At this point, the corresponding record is enabled for sync to the target application, that is, Oracle EBS.

Note:

When the Sync flag for an account is set to Off, changes to the account-addresses continue to be synchronized. Synchronization status is maintained only for parent-level objects, such as the Account object.

Because synchronization status is not maintained for child-level objects, such as for account-addresses, the address continues to be synchronized even if the status of the parent object is set to Sync Off. If the Account Sync flag is set to off and any associated contact is set to Sync On, the contact changes propagate. If you do not want these changes to be synchronized, set the Sync flag to Off for both the account and the contact.

3.3 Synchronizing Accounts from CRM On Demand to Oracle EBS

Synchronizing accounts from CRM On Demand to Oracle EBS includes the following process integrations:

Synchronizing new accounts from CRM On Demand to Oracle EBS
Synchronize new account integration flow
Updating and synchronizing accounts from CRM On Demand to Oracle EBS
Update and synchronize account integration flow
Deleting accounts in CRM On Demand
Synchronizing new account-contacts
Synchronize new account-contacts integration flow
Updating and synchronizing account-contacts
Update and synchronize account-contact integration flow
Deleting account-contacts in CRM On Demand

3.3.1 Synchronizing New Accounts from CRM On Demand to Oracle EBS

The Create Customer Account integration flow is initiated in CRM On Demand when a new account is created that has been flagged for synchronization. Within CRM On Demand, a workflow that has been defined triggers an integration event that captures the details associated with the creation of the account and places a message in the CRM On Demand integration event queue. The CRMOnDemandIntegrationEventProcessor process in the middle tier polls the CRM On Demand integration event queue at configurable intervals, picks up the account creation message, and makes the appropriate call to Oracle EBS to create the corresponding account and cross-reference entry in the SOA XREF DB. From this point forward, the account is considered synchronized and subsequent updates to the account in either system are propagated between the two.

During the Opportunity to Quote or Opportunity to Sales Order conversion process, if the account associated with the opportunity has not been synchronized previously to Oracle EBS, it is synchronized during the conversion process.

3.3.2 Synchronizing New Account Integration Flow

This integration uses the following interfaces:

CreateCustomerCRMODReqABCSImpl
CreateCustomerPartyEbizProvABCSImpl

3.3.3 Updating and Synchronizing Accounts from CRM On Demand to Oracle EBS

When an existing account record that has been flagged for synchronization is updated in CRM On Demand, the corresponding account record in Oracle EBS is updated with the changes that were made in CRM On Demand for the mapped attributes.

Account-contact records created or updated in CRM On Demand that are flagged for synchronization and that are also associated with an account that has been synchronized to Oracle EBS are also synchronized.

3.3.4 Updating and Synchronizing Account Integration Flow

This integration flow uses the following interfaces:

CreateCustomerAddressCRMODReqABCSImpl
UpdateCustomerAddressCRMODReqABCSImpl
UpdateCustomerCRMODReqABCSImpl
ProcessContactCRMODReqABCSImpl
UpdateCustomerPartyEbizProvABCSImpl

3.3.5 Deleting Accounts in CRM On Demand

The delete account integration flow is initiated in CRM On Demand when an existing integrated account record is deleted from the database.

The deletion of the integrated account record from CRM On Demand initiates a process that deletes cross-reference records to the corresponding data in Oracle EBS in the SOA XREF database but does not delete the account data in Oracle EBS.

When an account is deleted in CRM On Demand, the cross-reference records related to the account are deleted, that is, the account ID, phone, and fax records. The cross-reference records for the address-related information, such as the shipping address, the billing address, and the alternate address, are not deleted.

3.3.6 Synchronizing New Account-Contacts from CRM On Demand to Oracle EBS

The Create Account-Contact integration flow is initiated in CRM On Demand when a new account-contact is created that has been flagged for synchronization. An account-contact that is flagged for synchronization is synchronized only if the primary account with which it is associated has been successfully synchronized to Oracle EBS. Contacts that are not associated with an account are not synchronized to Oracle EBS. Synchronizing a contact, which is associated with several accounts, is not supported.

New account-contacts created in CRM On Demand create a corresponding account-contact in Oracle EBS. Cross-reference entries for the synchronized account-contacts are made in the SOA XREF database.

3.3.7 Synchronizing New Account-Contact Integration Flow

This integration uses the following interfaces:

ProcessContactCRMODReqABCSImpl
UpdateCustomerPartyEbizProvABCSImpl

3.3.8 Updating and Synchronizing Account-Contacts from CRM On Demand to Oracle EBS

When an existing account-contact record that has been flagged for synchronization is updated in CRM On Demand, the corresponding account-contact record in Oracle EBS is updated with the changes that were made in CRM On Demand. The synchronization of account-contact record updates is bidirectional across CRM On Demand and Oracle EBS.

When the account-contact work phone number, cellular phone number, work fax number, or email address is deleted in CRM On Demand, the corresponding entries in Oracle EBS are set to Inactive.

When the primary active account-contact telephone number, mobile number, fax number, and email address are set to inactive in Oracle EBS, the corresponding entries in CRM On Demand are deleted.

For account-contact records, only the primary email address in Oracle EBS is synchronized to the Email field in CRM On Demand.

For accounts, the primary web site is synchronized to the CRM On Demand web field.

The first phone, fax, or mobile number that appears in the CustomerParty EBM that is active is synchronized to CRM On Demand.

3.3.9 Update and Synchronize Account-Contact Integration Flow

This integration flow uses the following interfaces:

ProcessContactCRMODReqABCSImpl
UpdateCustomerPartyEbizProvABCSImpl

3.3.10 Deleting Account-Contacts in CRM On Demand

CRM On Demand users who have the appropriate privileges can delete an account-contact. Within Oracle EBS, users cannot delete an account-contact, but they can inactivate it.

When an integrated account-contact is deleted in CRM On Demand, the corresponding cross-reference in the SOA XREF DB is removed, but the status of the account-contact in Oracle EBS does not change; it is not deleted or inactivated.

When the status of an integrated account-contact is set to Inactive in Oracle EBS, the corresponding account-contact in CRM On Demand remains unchanged. The cross-reference between the two entities is also unchanged, and subsequent updates to the entities continue to synchronize even though the status of the account-contact in Oracle EBS is Inactive.

The integration does not support the restoration of deleted accounts or accounts-contacts; that is, if you delete and then restore a synchronized account-contact, the results are unpredictable; for example, duplicate data may be generated in Oracle EBS.

When an integrated account-contact is disassociated from its parent account in CRM On Demand, the corresponding account-contact in Oracle EBS is set to Inactive status. If the status of the account-contact is subsequently set to Active in Oracle EBS, the association between the records is again established in CRM On Demand, and the account-contact is synchronized from Oracle EBS to CRM On Demand. If the account-contact is again associated with the account in CRM On Demand, the account-contact in Oracle EBS is reset to Active status and the record is synchronized from CRM On Demand to Oracle EBS without a duplicate record being created in Oracle EBS.

3.4 Synchronizing Accounts from Oracle EBS to CRM On Demand

Synchronizing accounts from Oracle EBS to CRM On Demand includes the following process integrations:

Batch Loading Accounts from Oracle EBS to CRM On Demand
Synchronizing New Accounts from Oracle EBS to CRM On Demand
Synchronize Customer Account Integration Flow
Merging Accounts from Oracle EBS to CRM On Demand
Merge Account Integration Flow
Merging Parties from Oracle EBS to CRM On Demand
Merge Party Integration Flow

3.4.1 Batch Loading Accounts from Oracle EBS to CRM On Demand

You initiate the Batchload Customer Account integration flow in Oracle EBS when performing the initial data load from Oracle EBS to CRM On Demand. Details related to the account (account number, addresses, contacts, phone number, fax number, email address, web address, and so on) are synchronized to CRM On Demand; this includes associated account-contacts and account-addresses.

For information about the initial batch loading of customer account data, see Chapter 2, "Initial Loading and Synchronization of Data".

3.4.2 Synchronizing New Accounts from Oracle EBS to CRM On Demand

You initiate the Synchronize Customer Account integration flow in Oracle EBS when you create a new account or update an existing account. Details related to the account (account number, addresses, contacts, phone number, fax number, email address, web address, and so on) are synchronized to CRM On Demand.

When an account is created or updated in Oracle EBS, a record is written to a tracking table. Raising a Trading Community Architecture (TCA) business event causes all of the account records in the tracking table to be stamped with an event identifier and queue event message to be sent to the Oracle Advanced Queue (AQ). The synchronize account process retrieves the message from the AQ, reads the event identifier, and invokes the TCA Application Programming Interface (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 Application Business Connector (ABC) integration service passes the entire list of accounts to the CustomerPartyEBSV2Enterprise Business Service (EBS) and invokes the corresponding provider ABC implementation service.

Figure 3-2 provides an overview of the Synchronize Customer Account integration flow:

Figure 3-2 Synchronize Customer Account Integration Flow

3.4.3 Synchronize Customer Account Integration Flow

This integration flow uses the following interfaces:

SyncCustomerPartyListEbizEventCreateConsumer
SyncCustomerPartyListEbizEventUpdateConsumer
QueryCustomerPartyListEbizCreateAdapter
QueryCustomerPartyListEbizUpdateAdapter
SyncCustomerPartyListEbizReqABCSImpl
CustomerPartyEBSV2
SyncCustomerCRMODProvABCSImpl

Figure 3-3 illustrates the Synchronize Account integration flow:

Figure 3-3 Synchronize Account Flow Sequence Diagram

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

In Oracle Applications, a user navigates to the Customer Standard form (or any other form that allows the creation of customer accounts) and creates an account with address and contact details.

An administrator either manually runs or schedules periodic execution of 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 SyncCustomerPartyListEbizEventConsumer is listening. Different events are raised for a create scenario and an update scenario.

Note:

The TCA Raise Business Events concurrent program can be scheduled to run periodically at defined intervals, for example, every three minutes.
The SyncCustomerPartyListEbizEventConsumer retrieves the event payload from the queue and routes the request to the SyncCustomerPartyListEbizReqABCSImpl service.

The create event is retrieved from the queue by the SyncCustomerPartyListEbizEventCreateConsumer and the update event is retrieved from the queue by the SyncCustomerPartyListEbizEventUpdateConsumer.

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.
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.

When you use the Query Apps adapters QueryCustomerPartyListEbizCreateAdapter and QueryCustomerPartyListEbizUpdateAdapter, the account details are fetched based on the kind of action, update, or create.
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.
In the SyncCustomerPartyListEbizReqABCSImpl, the QueryResponseABM is transformed into the SyncCustomerPartyListEBM, and the SyncCustomerPartyList operation of the CustomerPartyEBSV2 is invoked with this EBM.
The CustomerPartyEBSV2 service routes the SyncCustomerPartyListEBM to the SyncCustomerCRMODProvABCSImpl.

In this service, the SyncCustomerPartyListEBM is transformed into the CRM On Demand Account/Contact Request Application Business Message (ABM), and the CRM On Demand web service for account creation or update is invoked.
The CRMODCustomer Upsert web service actually creates or updates the account, address, and contact in CRM On Demand and returns the appropriate response, CRM On Demand Account/Contact Response ABM.

This response is received by the SyncCustomerCRMODProvABCSImpl service.
In the SyncCustomerCRMODProvABCSImplservice, the CRM On Demand Account/Contact Response ABM is transformed into the SyncCustomerPartyListResponseEBM, during which the cross-reference data is updated with the CRM On Demand identifiers.

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

3.4.4 Merging Accounts from Oracle EBS to CRM On Demand

You initiate the Merge Account integration flow in Oracle EBS when you merge an account into another account in Oracle EBS. A corresponding account merge operation is performed in the target CRM On Demand system.

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

Table 3-3 outlines the synchronization outcome of several scenarios when the account merge process is initiated in Oracle EBS.

Table 3-3 Synchronization Outcome for Account Merge Process

Scenario	Outcome
Two accounts that belong to the same party are merged In Oracle EBS. Neither account was previously synchronized to CRM On Demand.	The winning account in Oracle EBS is synchronized to CRM On Demand.
Two accounts that belong to the same party are merged in Oracle EBS. Both accounts were previously synchronized to CRM On Demand.	Attributes of the losing account, such as address and contacts, are incorporated into the winning account. The status of the losing account is set to Inactive in CRM On Demand.
Two accounts that belong to different parties are merged in Oracle EBS.	This is not a supported scenario. However, in Oracle EBS, the customer can merge the two parties for the Accounts in question and then run the Account merge. After the merge of two parties, the winning party has the loosing party's account. The loosing party's account also has the attribute of the winning party. The same is reflected in CRM On Demand.

Figure 3-4 illustrates the Merge Account integration flow:

Figure 3-4 Merge Account Integration Flow

3.4.5 Merge Account Integration Flow

This integration flow uses the following interfaces:

MergeAccountEbizEventConsumer
MergeAccountEbizReqABCSImpl
CustomerPartyEBSV2
CustomerPartyResponseEBSV2
SyncCustomerCRMODProvABCSImpl
QueryMergeAccountEbizAdapter
QueryCustomerPartyEbizAdapter

Figure 3-5 illustrates the Merge Account integration flow:

Figure 3-5 Merge Account Flow Sequence Diagram

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

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.
The MergeAccountEbizEventConsumer retrieves the event payload from the queue and routes the request to the SyncCustomerParty operation of the MergeAccountEbizReqABCSImpl service.
The event payload received by the MergeAccountEbizReqABCSImpl service contains only the event identifier, not details of the entire account.

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.
The QueryMergeAccountEbizAdapter fetches the Winning Account 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.
The QueryCustomerPartyEbizAdapter service fetches the account details (addresses, contact points, contacts, and so on) from Oracle EBS and sends the response back as QueryAppsCustomerPartyListResponseABM.
The response from the QueryCustomerPartyEbizAdapter is transformed into the SyncCustomerPartyListEBM by the MergeAccountEbizReqABCSImpl service.

Then the SyncCustomerPartyList operation of the CustomerPartyEBSV2 service is invoked.
The CustomerPartyEBSV2 service routes the SyncCustomerPartyListEBM to the SyncCustomerCRMODProvABCSImpl, which then transforms the EBM to the CRMODSyncAccountRequestABM and invokes the Upsert CRM On Demand web service.

The response sent by the Upsert CRM On Demand 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.
The account merge into CRM On Demand occurs in two stages.
1. The losing account data is synchronized to the winning account (based on an option selected during the merge that specifies whether to create the same address) using the Upsert CRM On Demand web service.
2. The Update CRM On Demand web service is used to update the losing account status to Inactive in CRM On Demand.
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 SyncCustomerCRMODProvABCSImpl.
Based on a flag in the EBM, the SyncCustomerCRMODProvABCSImpl transforms the SyncCustomerPartyListEBM to the CRMODUpdateAccountReqABM and invokes the Update CRM On Demand Account web service to update the losing account status to Inactive in CRM On Demand.
The response received from the web service is then used to update the cross-reference data while being transformed to the SyncCustomerPartyListResponseEBM.
The Merge Account flow ends with no further responses sent back to Oracle EBS.

3.4.6 Merging Parties from Oracle EBS to CRM On Demand

You initiate the Merge Party integration flow in Oracle EBS when you merge an organization party into another party in Oracle EBS. Because the party ID is part of the Oracle ID in the cross-reference ID, the Merge Party flow updates the corresponding Oracle ID value in the cross-reference ID. In addition, all accounts of the surviving party in Oracle EBS are synchronized to CRM On Demand 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 added to the AQ. The MergePartyEbizEventAdapter retrieves the message from the AQ and passes it to the MergePartyEbizReqABCSImpl. The process reads the identifiers and invokes the TCA API to extract merge party information.

Table 3-4 outlines the synchronization outcome of several scenarios when the party merge process is initiated in Oracle EBS.

Table 3-4 Synchronization Outline for Party Merge Process

Scenario	Outcome
Two parties are merged in Oracle EBS and the accounts associated with the winning party were not previously synchronized to CRM On Demand.	The accounts associated with the winning party are synchronized to CRM On Demand and the attributes of the winning party are synchronized to the accounts of the losing party.
Two parties are merged in Oracle EBS and the accounts associated with the losing party were not previously synchronized to CRM On Demand.	After the merge, the winning party contains the losing party accounts and all the winning party accounts (including the accounts of the losing party) are synchronized to CRM On Demand.
Two parties are merged in Oracle EBS and the accounts associated with both parties were not previously synchronized to CRM On Demand.	After the merge, the winning party contains the losing party accounts and all the winning party accounts (including the accounts of the losing party) are synchronized to CRM On Demand.
Two parties are merged in Oracle EBS and the accounts associated with both were previously synchronized to CRM On Demand.	After the merge, the attributes of the winning party are incorporated into the accounts of the losing party.

Figure 3-6 illustrates the Merge Party integration flow:

Figure 3-6 Merge Party Integration Flow

3.4.7 Merge Party Integration Flow

This integration flow uses the following interfaces:

MergePartyEbizEventConsumer
MergePartyEbizReqABCSImpl
CustomerPartyEBSV2
SyncCustomerCRMODProvABCSImpl
QueryRelatedOrgCustEbizAdapter
QueryMergeOrgCustEbizAdapter
QueryPartyMergeEbizAdapter

Figure 3-7 illustrates the Merge Party integration flow:

Figure 3-7 Merge Party Flow Sequence Diagram

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

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.
The MergePartyEbizEventConsumer retrieves the event payload from the queue and routes the request to the SyncCustomerParty operation of the MergePartyEbizReqABCSImpl service.
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.
The QueryPartyMergeEbizAdapter fetches the Winning Account 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.
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.
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.
The CustomerPartyEBSV2 service routes the SyncCustomerPartyListEBM to the SyncCustomerCRMODProvABCSImpl, which then transforms the EBM into the CRMODSyncAccountRequestABM and invokes the Upsert CRM On Demand web service.

Because no parties are available in CRM On Demand, 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.
The response sent by the Upsert CRM On Demand 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 sent back to Oracle EBS.

3.5 Oracle CRM On Demand Interfaces

The CRM On Demand web service provided for the Customer Management flow integration is document/urn:crmondemand/ws/account/10/2004:AccountInsertOrUpdate.

3.6 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
oracle.apps.ar.hz.ebi.custLoad
HZ_EBI_CUST_LOAD.GENERATE_EVENTS
HZ_EBI_CUST_LOAD.Get_Org_Custs_BO
HZ_EBI_CUST_LOAD.PURGE_EVENTLOG
HZ_EBI_CUST_LOAD.REGENERATE_FAILED_EVENT

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.7 Core Oracle AIA Components

The Customer Management integration uses the following horizontal components:

CustomerPartyEBO
InterfaceCustomerToFulfillmentEBF
QueryCustomerPartyListEBM
QueryCustomerPartyListResponseEBM
SyncCustomerPartyListEBM
SyncCustomerPartyListResponseEBM
CustomerPartyEBSV2
CreateCustomerPartyEBM
CreateCustomerPartyResponseEBM
UpdateCustomerPartyEBM
UpdateCustomerPartyResponseEBM
CustomerPartyResponseEBS

The core EBO and EBM XML Schema Definition (XSD) files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Core/EBO/.

The core Oracle EBS Web Service Definition Language (WSDL) files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/.

For detailed information about 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 11g Release 1, "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 remain intact after a patch or an upgrade if AIA guidelines are adhered to.

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

3.8 Integration Services

These services are delivered with this integration:

CustomerPartyEBSV2
CustomerPartyResponseEBSV2
InterfaceCustomerToFulfillmentEBF
SyncCustomerCRMODProvABCSImpl
SyncCustomerPartyListEbizReqABCSImpl
SyncCustomerPartyListEbizReqABCSImpl
SyncCustomerPartyListEbizReqABCSImpl
MergeAccountEbizReqABCSImpl
MergePartyEbizReqABCSImpl
SyncCustomerPartyListEbizEventConsumer
MergeAccountEbizEventConsumer
MergePartyEbizEventConsumer
SyncCustomerPartyListEbizAdapter
CreateCustomerCRMODReqABCSImpl
UpdateCustomerCRMODReqABCSImpl
DeleteCustomerCRMODReqABCSImpl
CreateCustomerAddressCRMODReqABCSImpl
UpdateCustomerAddressCRMODReqABCSImpl
DeleteCustomerAddressCRMODReqABCSImpl
QueryCustomerPartyListCRMODProvABCSImpl
ProcessContactCRMODReqABCSImpl
CreateCustomerPartyEbizProvABCSImpl
UpdateCustomerPartyEbizProvABCSImpl
TransformAppContextEbizService
QueryResponsibilityEbizAdapter
AIACompositeScheduler
CRMOnDemandIntegrationEventProcessor

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

3.8.1 CustomerPartyEBSV2

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

The CustomerPartyEBSV2 service uses these operations:

QueryCustomerPartyList
SyncCustomerPartyList
CreateCustomerParty
UpdateCustomerParty

For more information about this enterprise business flow, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1, "Understanding Enterprise Business Services."

3.8.2 CustomerPartyResponseEBSV2

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

The CustomerPartyResponseEBSV2 enterprise business service uses these operations:

SyncCustomerPartyListResponse
CreateCustomerPartyResponse
UpdateCustomerPartyResponse

3.8.3 InterfaceCustomerToFulfillmentEBF

The InterfaceCustomerToFulfillmentEBF enterprise business flow is implemented as an asynchronous Business Process Execution Language (BPEL) process by using the asynchronous message exchange pattern (with delayed response) framework of AIA.

This enterprise business flow creates or synchronizes all the customer accounts and related components (such as address and contacts) to the appropriate fulfillment system. This service is invoked from the Order integration flow with a list of customer account IDs, address IDs, contact IDs, and the target system ID. When the process is complete, a response is sent back 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.

For Assumption and 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 be passed 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 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 end due to 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 the Order process is called, invoking this service would have established the cross-reference for the CRM On Demand to common ID for all new accounts, addresses, and contacts that are part of the CRM On Demand sales order or quote.

3.8.4 SyncCustomerCRMODProvABCSImpl

The SyncCustomerCRMODProvABCSImpl service transforms the SyncCustomerPartyListEBM messages into the appropriate CRM On Demand AccountABM format and invokes the CRM On Demand Account Upsert web service operation. If the input SyncCustomerPartyListEBM contains contact-related details, then it transforms to CRM On Demand Contact ABM format and invokes the CRM On Demand Contact Upsert web service operation. It also includes compensation handlers.

These preprocesses are included in the SyncCustomerCRMODProvABCSImpl to ensure that ABC services are extensible:

PreprocessABM
PreprocessEBM

3.8.5 SyncCustomerPartyListEbizReqABCSImpl

The SyncCustomerPartyListEbizReqABCSImpl service is responsible for transforming the Oracle EBS account, contact, or address created or updated 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.8.6 SyncCustomerPartyListEbizProvABCSImpl

The CustomerPartyEBSV2 invokes the SyncCustomerPartyListEbizProvABCSImpl service when the routing rules determine that Oracle Apps is to be the service provider of the SyncCustomerPartyList Oracle 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 and reply operation SyncCustomerPartyList.

3.8.7 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.

3.8.8 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 and reply operation SyncCustomerParty.

3.8.9 SyncCustomerPartyListEbizEventConsumer

The SyncCustomerPartyListEbizEventConsumer service is responsible for retrieving the Oracle create or update account business event payloads from the AQ and invoking the appropriate operation of the requester Application Business Connector Service (ABCS) SyncCustomerPartyEbizReqABCSImpl.

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

oracle.apps.ar.hz.OrgCustBO.create
oracle.apps.ar.hz.OrgCustBO.update

The retrieval of the event from the queue is performed according to the correlation ID of the event in the AQ. For customer account create events, the correlation ID is oracle.apps.ar.hz.OrgCustBO.create. For customer account update events, the correlation ID is oracle.apps.ar.hz.OrgCustBO.update.

3.8.10 MergeAccountEbizEventConsumer

The MergeAccountEbizEventConsumer service is responsible for retrieving the Oracle account merge business event payloads from the AQ and invoking the appropriate operation of the requester ABCS. For the account merge, the correlation ID is oracle.apps.ar.hz.CustAccount.merge and the event adapter is MergeAccountEbizEventAdapter. The process of retrieving the event from the queue depends on the correlation ID of the event in the 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.8.11 MergePartyEbizEventConsumer

The MergePartyEbizEventConsumer service is responsible for retrieving the Oracle party merge business event payloads from the AQ and invoking the appropriate operation of the Requester ABCS. For the party merge, the correlation ID is oracle.apps.ar.hz.Party.merge and the event adapter is MergePartyEbizEventAdapter. The event retrieval operation is performed according to the event correlation ID 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.8.12 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 Oracle EBS HZ.N.

This service is the interface through which an order is created in Oracle EBS, and it is invoked by the SyncCustomerPartyListEbizProvABCSImpl 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 and reply operation. By registering this adapter service in Mediator Component, Mediator Component exposes a Simple Object Access Protocol (SOAP) binding that is used in this integration to invoke the service from the SyncCustomerPartyListEbizProvABCSImpl service.

3.8.13 CreateCustomerCRMODReqABCSImpl

The CreateCustomerCRMODReqABCSImpl service receives the account insert integration event from CRM On Demand. It then queries CRM On Demand to determine whether multiple addresses exist for the customer, whether any contacts are associated with the account, and whether its status is set to Sync On. If multiple addresses exist, the service combines the information into one single message event before transforming the message from CRM On Demand format into the CreateCustomerPartyEBM format. After transforming the message, this service invokes the CustomerPartyEBSV2. After it receives a response from the CreateCustomerPartyEbizProvABCSImpl service, it updates the On Demand Account external system ID with the Oracle EBS account ID.

3.8.14 UpdateCustomerCRMODReqABCSImpl

The UpdateCustomerCRMODReqABCSImpl receives an account update integration event from CRM On Demand. The service converts the event message from CRM On Demand format to UpdateCustomerPartyEBM format and invokes the UpdateCustomerPartyEBS.

In cases in which the account has not been synchronized to Oracle EBS, the service queries CRM On Demand to fetch full information about the account, including account addresses and contacts that are associated with it and flagged for synchronization. The service then converts the message to UpdateCustomerPartyEBM format and invokes the CreateCustomerPartyEBS to enable the Oracle EBS application to create an account, including addresses and contacts if necessary.

After UpdateCustomerCRMODReqABCSImpl gets a response from CreateCustomerPartyEbizProvABCSImpl or UpdateCustomerPartyEbizProvABCSImpl, it updates the On Demand Account external system ID with the Oracle EBS account ID.

3.8.15 DeleteCustomerCRMODReqABCSImpl

The DeleteCustomerCRMODReqABCSImpl service receives an account delete integration event from CRM On Demand. The service converts the message from CRM On Demand format to UpdateCustomerPartyEBM format and deletes account-related cross-reference details, and the process ends.

For this service to function properly, these criteria must be met:

The account ID must exist in the CRM On Demand message.
The host ID must exist in the CRM On Demand message.
The CRM On Demand input message can contain only one account.
The CRM On Demand input message contains only delete account information.

Account addresses are not included in the message. If address information exists in the message, it is ignored and not transformed.

One asynchronous one-way operation is provided: DeleteCustomerCRMODReqABCSImpl interface.

3.8.16 CreateCustomerAddressCRMODReqABCSImpl

The CreateCustomerAddressCRMODReqABCSImpl service receives an address insert integration event from CRM On Demand. The service checks whether the address has a cross-reference ID. If so, the address has been processed during account creation and no further processing is required. If the cross-reference ID does not exist, the service transforms the event message from CRM On Demand format to UpdateCustomerPartyEBM format and invokes the UpdateCustomerPartyEBS.

One asynchronous one-way operation is provided by the CreateCustomerAddressCRMODReqABCSImpl interface service.

3.8.17 UpdateCustomerAddressCRMODReqABCSImpl

The UpdateCustomerAddressCRMODReqABCSImpl service receives an address update integration event from CRM On Demand. The service converts the event message from CRM On Demand format to UpdateCustomerPartyEBM format and invokes the UpdateCustomerPartyEBS.

For this service to function properly, these criteria must be met:

The account ID must exist in the CRM On Demand message.
The host ID must exist in the CRM On Demand message.
The CRM On Demand input message can contain only one address.
The CRM On Demand input message must contain some information about the address account.

Only the account ID is used during transforming to supply account identification. All other information about the account is discarded because the purpose of this service is to update an address, not an account.

One asynchronous one-way operation is provided by the UpdateCustomerAddressCRMODReqABCSImpl interface service.

3.8.18 DeleteCustomerAddressCRMODReqABCSImpl

The DeleteCustomerAddressCRMODReqABCSImpl service receives an address delete integration event from CRM On Demand. The service converts the message from CRM On Demand format to UpdateCustomerPartyEBM format, deletes On Demand address-related cross-reference details, and invokes UpdateCustomerPartyEBS.

The Address Delete integration event occurs only when a CRM On Demand user deletes an individual address. The Address Delete integration event is not generated automatically when a CRM On Demand user deletes an account that is associated with addresses.

For this service to function properly, these criteria must be met:

The account ID must exist in the CRM On Demand message.
The host ID must exist in the CRM On Demand message.
The CRM On Demand input message can contain only one address.
The CRM On Demand input message contains the deleted address information and some information about the address account.

One asynchronous one-way operation is provided by the DeleteCustomerAddressCRMODReqABCSImpl interface service.

3.8.19 QueryCustomerPartyListCRMODProvABCSImpl

The QueryCustomerPartyListCRMODProvABCSImpl service receives the QueryCustomerPartyListEBM as the input message and transforms it to a CRM On Demand Account Query request message.

The CRM On Demand Account Query request message queries all the account-related details, including the address and contacts associated with the account, then filters the details that are not required according to the query criteria specified in the input EBM message. The data is then transformed into a QueryCustomerPartyListResponseEBM message.

The QueryCustomerPartyListCRMODProvABCSImpl service is invoked during the Opportunity-to-Order or the /Quotes conversion process Opportunity-to-Quote conversion process when the account and contact associated with an opportunity have not synchronized to Oracle EBS.

3.8.20 ProcessContactCRMODReqABCSImpl

ProcessContactCRMODReqABCSImpl receives contact create, update, association, and disassociation values with the account and delete integration event from CRM On Demand. Then the service converts the message from CRM On Demand format to the UpdateCustomerPartyEBM format and invokes UpdateCustomerPartyEBS.

For this service to function properly, these criteria must be met:

The contact ID must exist in the CRM On Demand message.
The host ID must exist in the CRM On Demand message

3.8.21 CreateCustomerPartyEbizProvABCSImpl

The CustomerPartyEBSV2 service invokes the CreateCustomerPartyEbizProvABCSImpl service when the routing rules determine that Oracle EBS is to be the service provider of the CreateCustomerParty Oracle EBS operation. This determination occurs during the integration flow that is initiated by the create account processing in CRM On Demand.

3.8.22 UpdateCustomerPartyEbizProvABCSImpl

The CustomerPartyEBSV2 service invokes the UpdateCustomerPartyEbizProvABCSImpl service when the routing rules determine that Oracle EBS is to be the service provider of the UpdateCustomerParty Oracle EBS operation. This flow is initiated when an address or contact associated with an account is created or updated, or when an account is updated in CRM On Demand.

3.8.23 TransformAppContextEbizService

TransformAppContextEbizService is invoked by the Oracle EBS providers to obtain the application context information that is required to invoke the Oracle EBS APIs through the Oracle EBS adapter service. The TransformAppContextEbizService service obtains details such as the Oracle EBS responsibility ID and the organization ID from the configuration properties.

For more information about the service properties for the TransformAppContextEbizService service, see Configuring the Oracle Lead to Order Integration Pack for Oracle CRM On Demand and.

3.8.24 QueryResponsibilityEbizAdapter

The QueryResponsibilityEbizAdapter service makes sure that the Oracle EBS responsibility exists in the Oracle EBS database by running a query. The query is invoked from the TransformAppContextEbizService service.

3.8.25 AIACompositeScheduler

AIACompositeScheduler invokes the CRMOnDemandActivationAgent service. AIACompositeScheduler is a utility component that is used by pre-built integrations to schedule a Service-Oriented Architecture (SOA) composite to be invoked at the specified time interval. For example, it can schedule a SOA composite to be invoked every 30 seconds. It supports scheduling composites in cluster environment as well.

Properties of AIACompositeScheduler are specified in web.xml. Administrators can change these properties dynamically through a deployment plan.

For more information about how to modify and how to deploy AIACompositeScheduler, see Oracle Application Integration Architecture Process Integration Pack Utilities Guide, "AIACompositeScheduler," Modifying AIACompositeScheduler Properties.

3.8.26 CRMOnDemandIntegrationEventProcessor

The CRMOnDemandIntegrationEventProcessor service is invoked by the CRMOnDemandActivationAgent; the CRM On Demand host ID is provided as input to the process. The CRMOnDemandIntegrationEventProcessor service queries up to a maximum of 100 integration events in the default queue using CRM On Demand integration event web services. The messages are then sent to the appropriate resequencers (CustomerCRMODRoutingService and ContactCRMODRoutingService), which act as middle-tier queues. Resequencers then route events one by one to the appropriate CRM OnDemand requesters.

Also, import the CRM On Demand certificate to Web Logic. If you do not import the certificate, you might encounter the following error: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.