Skip Headers
Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management
Release 11.3

Part Number E37675-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

19 Implementing the Synchronize Customer Account Business Flow

This chapter describes the Synchronize Customer Account business flow and explains how the Oracle Communications Order to Cash Integration Pack for Siebel customer relationship management (Siebel CRM), Oracle Communications Order and Service Management (OSM), and Oracle Communications Billing and Revenue Management (BRM) (the integration) implements the business flow using Siebel CRM and BRM interfaces, communications industry-specific Oracle Application Integration Architecture (Oracle AIA) components, and integration services.

Overview of the Synchronize Customer Account Business Flow

The following Pre-Built Integration options enable the Synchronize Customer Account business flow:

  • Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option

  • Oracle Communications Order to Cash for Siebel CRM and BRM Pre-Built Integration option

The Synchronize Customer Account business flow supports the following integration flows:

  • Create/Sync Customer Account

  • Update Customer Account

Create/Sync Customer Account Integration Flow

The Create/Sync Customer Account integration flow enables the synchronization of customer information from Siebel CRM to BRM. This flow is called during the Interfacing Orders to Create Customer Data in BRM integration flow of the Synchronize Fulfillment Order Billing Account business flow.

See "Interfacing Orders to Create Customer Data in BRM Integration Flow" for information about the sequence of events for these integration flows.

Update Customer Account Integration Flow

This flow is initiated to propagate updates to accounts in Siebel CRM to BRM.

This Update Customer Account integration flow uses the following services:

  • SyncCustomerSiebelEventAggregator

  • SyncAcctSiebelEventAggrConsumer

  • SyncAccountSiebelReqABCSImpl

  • CustomerPartyEBSV2

  • SyncCustomerPartyListBRM_01CommsJMSConsumer

  • SyncCustomerPartyListBRMCommsProvABCSImpl

Figure 19-1 illustrates the update customer accounts flow.

Figure 19-1 Update Customer Account Flow Sequence Diagram

This image is described in surrounding text.

When this process is initiated, the following events occur:

  1. In Siebel CRM, a user navigates to the Accounts screen, queries an account, and updates an account attribute (for example, address, contact, or the billing profile).

    This causes Siebel CRM to invoke the SyncCustomerSiebelEventAggregator, with the SiebelUpdateABM message containing the details of the account that has been updated. Depending on the type of update, one of four kinds of Siebel messages can be generated: ListOfSWICustomerIO, ListOfSWIBillingProfileIO, ListOfSWIContactIO, or ListOfSWIAddressIO.

  2. The SyncCustomerSiebelEventAggregator then calls a database adapter (account, address, contact, or billing profile) that executes a pl/sql script that extracts and stores the relevant IDs (for example, account, contact, or billing profile) in a database table AIA_AGGREGATED_ENTITIES and sends an acknowledgment to Siebel CRM as a reply.

  3. The IDs in the database table are stored in the same manner as the hierarchy of IDs is maintained (for example, BillingProfileID is always the child of some account ID).

    The account ID, along with its entire child IDs, is picked up from the database table by the SyncAcctSiebelEventAggrConsumer process. This consumer is sequencing-enabled to ensure that the updates for the same customer are sent in the appropriate sequence.

  4. The Consumer process then calls the SyncAccountSiebelReqABCSImpl process.

    This process takes all the IDs, constructs a Siebel Query Input ABM, and calls the Siebel Query web service to get the entire account data from Siebel CRM. After getting the data, the Siebel Query Input ABM is transformed into the SyncCustomerPartyListEBM and routed to SyncCustomerPartyListBRMCommsJMSProducer through CustomerPartyEBSV2, which publishes the message to the JMS topic named CPARTY_SYNC_TOPIC.

  5. Depending on the instances of BRM or any other billing system, consumers can be defined that have subscribed to the CPARTY_SYNC_TOPIC topic.

    One such consumer for the default implementation is available, named SyncCustomerPartyListBRM_01CommsJMSConsumer, which listens to the topic for messages, picks up the arriving message, and passes it on to the process SyncCustomerPartyListBRMCommsProvABCSImpl after duly checking whether the message should go to the ensuing provider ABCS, and accordingly stamping the target ID.

  6. The SyncCustomerPartyListBRMCommsProvABCSImpl process then calls the PCM_OP_CUST_UPDATE_CUSTOMER, PCM_OP_CUST_DELETE_PAYINFO, or PCM_OP_CUST_SET_STATUS opcode as required to synchronize the updated data to BRM.

BRM Interfaces

Table 19-1 lists the BRM interfaces used by the Synchronize Customer Account business flow.

Table 19-1 RM Interfaces

API / Opcode Description Used by

PCM_OP_CUST_COMMIT_CUSTOMER

Create a new account with one or more bill-infos and pay-infos in BRM.

BRM Sync Customer Provider application business connector service (ABCS) as part of the Create/Update Customer Account flow.

PCM_OP_CUST_UPDATE_CUSTOMER

Update account information (name, address, phone), contact information, and billing and pay information.

BRM Sync Customer Provider ABCS as part of the Update Customer Account flow.

PCM_OP_CUST_DELETE_PAYINFO

Delete a payinfo object from an account.

BRM Sync Customer Provider ABCS, as part of the Update Customer Account flow.

PCM_OP_CUSTCARE_MOVE_ACCT

Move an account to a new parent account.

BRM Sync Customer Provider ABCS, as part of Order flow to manage paying parent changes (account hierarchy change).

PCM_OP_CUST_SET_STATUS

Used to modify the account status in BRM.

BRM Sync Customer Provider ABCS as part of the Update Customer Account flow.


See the BRM documentation for more information.

Siebel CRM Interfaces

Table 19-2 describes the Siebel CRM web service interface.

Table 19-2 Siebel CRM Web Service Interface

Web Service Description Used by

Query Account-

(SWICustomerParty)

Retrieves account, bill profile, contact, and address data from Siebel CRM.

Used by the Siebel Query Account Provider ABCS as part of creating and adding a new billing profile to an existing customer.

Also used by the Siebel Sync Account Requester ABCS to retrieve the most current account data from Siebel.


See Siebel Order Management Guide Addendum for Communications for more information about web services.

Table 19-3 describes the Siebel CRM workflow event interfaces.

Table 19-3 Siebel CRM Workflow Event Interfaces

Event Description Consumed by

SWI Account Updated

This workflow event is started when an account is updated in Siebel CRM.

This event message is consumed by the SyncCustomerSiebelEventAggregator.aggregateaccountevent service, which extracts all the relevant IDs from the input payload and stores them in a database table (AIA_AGGREGATED_ENTITIES).

SWI Bill Profile Updated

This workflow event is started when a bill profile is updated in Siebel CRM.

The event message is consumed by the SyncCustomerSiebelEventAggregator.aggregatebpevent service, which extracts all the relevant IDs from the input payload and stores them in a database table (AIA_AGGREGATED_ENTITIES).

SWI Contact Updated

This workflow event is started when a contact is updated in Siebel CRM.

The event message is consumed by the SyncCustomerSiebelEventAggregator.aggregatecontactevent service, which extracts all the relevant IDs from the input payload and stores them in a database table (AIA_AGGREGATED_ENTITIES).

SWI Address Updated

This workflow event is started when an address is updated in Siebel CRM.

The event message is consumed by the SyncCustomerSiebelEventAggregator.aggregateaddressevent service, which extracts all the relevant IDs from the input payload and stores them in a database table (AIA_AGGREGATED_ENTITIES).


See "Workflows for Employee Asset-Based Ordering" in Siebel Order Management Guide Addendum for Communications for more information.

Industry Oracle AIA Components

The Synchronize Customer Account business flow uses the following enterprise business objects (EBOs) and enterprise business messages (EBMs):

  • CustomerPartyEBO

  • QueryCustomerPartyListEBM

  • QueryCustomerPartyListResponseEBM

  • SyncCustomerPartyListEBM

  • SyncCustomerPartyListResponseEBM

  • ProcessBillingAccountListEBM

  • ProcessBillingAccountListResponseEBM

  • FulfillmentOrderEBO

  • ProcessFulfillmentOrderBillingAccountListEBM

  • ProcessFulfillmentOrderBillingAccountListResponseEBM

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

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

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

EBOs can be extended, for instance, to add new data elements. These extensions are protected and remain intact after a patch or an upgrade, so long as the extensibility guidelines are followed.

See Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information about:

  • Configuring and using OER as the Oracle SOA Repository to provide the AIA Reference doc link

  • Extending existing schemas and EBOs

Integration Services

The following services are delivered with the Synchronize Customer Account business flow:

  • ProcessFulfillmentOrderBillingAccountListOSMCFSCommsJMSConsumer

  • CommunicationsCustomerPartyEBSV2Resequencer

  • CommsProcessFulfillmentOrderBillingAccountListEBF

  • CommsProcessBillingAccountListEBF

  • SyncCustomerSiebelEventAggregator

  • SyncAccountSiebelAggregatorAdapter

  • SyncContactSiebelAggregatorAdapter

  • SyncAddressSiebelAggregatorAdapter

  • SyncBPSiebelAggregatorAdapter

  • SyncAcctSiebelAggrEventConsumer

  • SyncAccountSiebelReqABCSImpl

  • CustomerPartyEBSV2

  • QueryCustomerPartyListSiebelProvABCSImplV2

  • SyncCustomerPartyListBRMCommsProvABCSImpl

  • SyncCustomerPartyListBRM_01CommsJMSConsumer

ProcessFulfillmentOrderBillingAccountListOSMCFSCommsJMSConsumer

This process listens to the AIA_CRTCUST_OUT_JMSQ JMS queue and as soon as a message is picked up, forwards it to the CommsProcessFulfillmentOrderBillingAccountListEBF enterprise business flow, which extracts the relevant customer data. The ProcessBillingAccountListEBM is then routed to the CommsProcessBillingAccountListEBF.

CommunicationsCustomerPartyEBSV2Resequencer

The CommunicationsCustomerPartyEBSV2Resequencer enterprise business service sequences the account message from CommsProcessBillingAccountListEBF. The messages are grouped by account ID. This process receives the customer EBM and passes it to SyncCustomerPartyListBRMCommsProvABCSImpl for routing to BRM.

See "Designing and Constructing Enterprise Business Services" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack and "Understanding Enterprise Business Services," Enterprise Business Flow Processes in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack for more information about this EBS.

See "Using the Oracle Mediator Resequencer Feature" for more information about the Oracle Mediator Resequencer.

CommsProcessFulfillmentOrderBillingAccountListEBF

This enterprise business flow (EBF) extracts the Customer Data from OrderEBM. The process loops through every order line and extracts any customer account or billing profile that it encounters.

This service has two operations. One accepts the ProcessFulfillmentOrderBillingAccountListEBM and is used by the process to order data. The other is used by the process to send the response back to the calling process (using the ProcessFulfillmentOrderBillingAccountListEBM).

The transformations include:

  • ProcessFulfillmentOrderBillingAccountList to ResponseEBM.xsl

  • ProcessFulfillmentOrderBillingAccountListEBM to ProcessBillingAccountListEBM.xsl

The CommsProcessFulfillmentOrderBillingAccountListEBF enterprise business flow is implemented as an asynchronous delayed response Business Process Execution Language (BPEL) process.

See "Designing and Constructing Enterprise Business Flows" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack and "Understanding Enterprise Business Services," Enterprise Business Flow Processes in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack for more information about EBFs.

CommsProcessBillingAccountListEBF

This EBF service creates or synchronizes all the customer accounts and billing profiles in an appropriate billing system. The Order Processing integration flow invokes this service with a list of customer account IDs, billing profile IDs, and the target system ID. When the process is complete, a response is sent back to the order flow confirming that all accounts have been set up in the target billing system, and the order processing can continue.

This service provides two operations. One accepts the ProcessBillingAccountListEBM and is used by the process to accept the customer data to be synchronized. The other one is used by the process to send the response back to the calling process (using the SyncCustomerPartyListResponseEBM). The data area of the message contains one or more customer account IDs. For each account, one or more bill profile IDs must be synchronized to the target billing system. The customer data indicates both the hierarchical and the paying relationships between the accounts.

This service creates or synchronizes one or more customers (identified by ID only) and their billing profiles to a particular target billing system (identified in the EBM header).

Therefore, the responsibilities of this service include:

  • Determining whether the customer exists and is up to date in the target billing system.

    If so, optimize and do not try to create or synchronize.

  • Retrieving the customer data from the appropriate Siebel CRM system using the provided IDs, if necessary.

  • Optimizing, if possible, the number and size of queries back into Siebel CRM for the customer data.

  • Creating or updating the customers and billing profiles in the target billing system, reflecting the customer hierarchy and paying relationships among the customers.

See "Designing and Constructing Enterprise Business Flows" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack and "Understanding Enterprise Business Services, "Enterprise Business Flow Processes in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack for more information about EBFs.

SyncCustomerSiebelEventAggregator

This service is responsible for receiving Siebel CRM update account events and collating them into an Oracle AIA database table.

Figure 19-2 illustrates the relationship of the SyncCustomerSiebelEventAggregator with the other services in the integration flow.

Figure 19-2 SyncCustomerSiebelEventAggregator

This image is described in surrounding text.

This service provides four operations, one for each of the object types that are updated:

  • Aggregateaccountevent:

    Receives the Account Updated Siebel message. Extracts the account ID, contact IDs, and address IDs from the message. Invokes the SyncAccountSiebelAggregatorAdapter to store these IDs into the AIA_AGGREGATED_ENTITIES database table.

  • Aggregatecontacttevent:

    Receives the Contact Update Siebel message. Extracts the account IDs, bill profile IDs, and contact IDs from the message. Invokes the SyncContactSiebelAggregatorAdapter to store these IDs in the AIA_AGGREGATED_ENTITIES database table.

  • Aggregateaddresstevent:

    Receives the Address Update Siebel message. Extracts the account IDs, bill profile IDs, and address IDs from the message. Invokes the SyncAddressSiebelAggregatorAdapter to store these IDs into the AIA_AGGREGATED_ENTITIES database table.

  • Aggregatebpevent:

    Receives the BillingProfile Updated Siebel message. Extracts the BillingProfile ID and the associated account ID from the message. Invokes the SyncBPSiebelAggregatorAdapter to store these IDs in the AIA_AGGREGATED_ENTITIES database table.

See "Describing the Event Aggregation Programming Model" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information about the Event Aggregation programming model.

SyncAccountSiebelAggregatorAdapter

This service aggregates the account events generated in Siebel CRM 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.

SyncContactSiebelAggregatorAdapter

This service aggregates the account events generated in Siebel CRM 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.

SyncAddressSiebelAggregatorAdapter

This service aggregates the account events generated in Siebel CRM 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.

SyncBPSiebelAggregatorAdapter

This service aggregates the account events generated in Siebel CRM when an account is created or updated. This service invokes a PL/SQL procedure, AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_BP, which does the actual aggregation in the AIA aggregator table.

SyncAcctSiebelAggrEventConsumer

This service extracts the account IDs stored in the AIA_AGGREGATED_ENTITIES database table and sends them forward to the SyncAccountSiebelReqABCSImpl service.

Sequencing is enabled for this service. When this consumer calls the requestor for further processing and the requestor fails, any subsequent update for that customer is not processed until proper action is taken on the messages in the sequencer. If the failure is due to a business error then messages must be removed from the queue for the subsequent messages to process. If the failure is system related then messages in the resequencer can be retried to move the message from the resequencer queue and thereby enabling subsequent messages to be processed. Any updates for other errors are processed as usual.

See "Using the Oracle Mediator Resequencer Feature" for more information about the resequencer.

SyncAccountSiebelReqABCSImpl

This service is responsible for transforming the Siebel message into the SyncCustomerPartyList EBM format and invoking the SyncCustomerPartyList operation of the CustomerPartyEBSV2.

The process checks whether the incoming message has a target system identifier. If the target system identifier is not present, then the delivered rule assumes multiple BRM systems and routes the incoming requests to a Java message service (JMS) producer service SyncCustomerPartyListBRMCommsJMSProducer::Produce_Message.

If the implementing customer does not have multiple BRM systems and operates only on a single BRM system, then they can change the routing rule to route incoming requests to the SyncCustomerPartyListBRMCommsProvABCSImpl_1_0::SyncCustomerPartyList directly. Additionally, customers must apply a transformation before routing to stamp the target system identifier in the EBM. The transformation file name is esb:///ESB_Projects/Customer_CustomerPartyEBSV2/AddTargetID_BRM01.xsl.

CustomerPartyEBSV2

CustomerPartyEBSV2 exposes all of the enterprise operations that can be performed with a CustomerParty enterprise object.

CustomerPartyEBSV2 service uses the following operations:

  • SyncCustomerPartyList

  • QueryCustomerPartyList

Figure 19-3 illustrates the relationship of QueryCustomerPartyListSiebelProvABCSImplV2 with the other services in the integration flow.

Figure 19-3 CustomerPartyEBSV2

This image is described in surrounding text.

The CustomerPartyEBSV2 is implemented as a lightweight EBS routing service.

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

QueryCustomerPartyListSiebelProvABCSImplV2

CustomerPartyEBSV2 invokes the QueryCustomerPartyListSiebelProvABCSImplV2 service when the routing rules determine that Siebel CRM is to be the service provider for the QueryCustomerPartyList EBS operation.

This service has one synchronous request and reply operation, QueryCustomerPartyList.

SyncCustomerPartyListBRMCommsProvABCSImpl

The CommsProcessBillingAccountListEBF or SyncAccountSiebelReqABCSImpl service invokes SyncCustomerPartyListBRMCommsProvABCSImpl. It performs the following actions:

  1. Receives the SyncCustomerPartyListEBM.

  2. Loops through each data area:

    If the current account is a child account, it checks whether the parent account has been synchronized. The child account should be synchronized only when the parent has been synchronized.

    Based on the action code associated with each account, it goes to the Create block (used when a new account must be synchronized) or the Update block (used when an existing account is to be updated).

  3. Creates the block:

    Transforms the SyncCustomerPartyListEBM to the BRM-specific ABM (PCM_OP_CUST_COMMIT_CUSTOMER_Inmsg).

    Calls the PCM_OP_CUST_COMMIT_CUSTOMER opcode with the BRM ABM.

    Transforms the response from the PCM_OP_CUST_COMMIT_CUSTOMER opcode call to SyncCustomerPartyListResponseEBM.

    While transforming, the service populates the following cross-reference tables with the BRM IDs obtained:

    • CUSTOMERPARTY_ACCOUNTID

    • CUSTOMERPARTY_ADDRESSID

    • CUSTOMERPARTY_CONTACTID

    • CUSTOMERPARTY_BILLPROFILEID

    • CUSTOMERPARTY_PAYPROFILEID

  4. Updates the block:

    If the account is a child account:

    • If the parent obtained from the EBM is different from the parent obtained from the opcode call, then it moves the child account to the new parent (as directed by the EBM) by calling the PCM_OP_CUSTCARE_MOVE_ACCT.

    Creates the PCM_OP_CUST_UPDATE_CUSTOMER input message by a transformation from the SyncCustomerPartyListEBM.

    Checks whether the AIAConfiguration property EnableAccountStatusSync is set to True. If set to True, then it creates the PCM_OP_CUST_SET_STATUS input message from the SyncCustomerPartyListEBM. Calls the opcode PCM_OP_CUST_SET_STATUS to synchronize the status mentioned in the EBM to BRM.

    If the result of an account update, in which the PayProfile of the account is changed, is SyncCustomerPartyListEBM, then after calling the PCM_OP_CUST_COMMIT_CUSTOMER, it calls the PCM_OP_CUST_DELETE_PAYINFO to delete the earlier PAYINFO object from BRM.

    Transforms the SyncCustomerPartyListEBM to SyncCustomerPartyListResponseEBM.

SyncCustomerPartyListBRM_01CommsJMSConsumer

This process listens to the topic CPARTY_SYNC_TOPIC and as soon as a message is picked up, forwards it to the SyncCustomerPartyListBRMCommsProvABCSImpl.

This service performs the following actions:

  • Receives the SyncCustomerPartyListEBM.

  • Does an cross-reference lookup to determine whether for the given common ID, the corresponding BRM ID (for BRM_01 or BRM_02, based on the consumer name) exists.

    If it exists, then the service stamps the message with the particular target system ID and passes it forward to the SyncCustomerPartyListBRMCommsProvABCSImpl.

This process is implemented as a Mediator process. This consumer process is intended for a multiple BRM system type installation. If multiple BRM systems exist, then for each system one such consumer must be deployed.

See "Configuring Multiple BRM Instances for Communications Integrations" for more information about multiple BRM systems.