5 Implementing the Order to Cash Business Processes

This chapter describes the implementation of Order to Cash business processes and their features through the implementation process of order lifecycle management.

About the Order Lifecycle Management

Order lifecycle management includes the following:

• Process Sales Order Fulfillment: Siebel CRM submits orders to OSM.

  • Enabled using the Order to Cash business process options for OSM and Siebel CRM.

  • Used when submitting orders from Siebel CRM to OSM for order fulfillment processing.

  See About the Process Sales Order Fulfillment Flow.

• Synchronize Fulfillment Order Billing Account: OSM decomposes orders to create customer data in BRM.

  • Enabled using the Order to Cash business process options for OSM, BRM and Siebel CRM.

  • Used when interfacing orders to create customer data in BRM.

  See About the Synchronize Fulfillment Order Billing Account Flow.

• Bill Fulfillment Order: OSM decomposes orders to create transaction data in BRM.

  • Enabled using the Order to Cash business process options for OSM and BRM.

  • Used when interfacing orders to create transaction data in BRM.

  See About the Bill Fulfillment Order Flow.

• Provision Order and Update Fulfillment Order: OSM in the Central Order Management (COM) role decomposes and sends orders to OSM in the Service Order Management (SOM) role for provisioning.

  • Enabled using the Order to Cash business process option for OSM.

  • Used when provisioning orders in OSM SOM, and updating orders and statuses in OSM COM through order updates from OSM SOM.

  See About the Provision Order and Update Fulfillment Order Flows.

• Update Sales Order: OSM sends order updates to Siebel CRM.

  • Enabled using the Order to Cash business processs options for OSM and Siebel CRM.

  • Used when sending order updates from OSM COM to Siebel CRM.

  See About the Update Sales Order Flow.

The following sections describe how the above business flows are implemented.

For more information about configuring order lifecycle management for Order to Cash, see Configuring Order Lifecycle Management.

Implementing the Process Sales Order Fulfillment

This section explains how the Order to Cash business process implements the Process Sales Order Fulfillment flow. It also describes how the Order to Cash business process supports order priorities and multiple price lists.

About the Process Sales Order Fulfillment Flow

The Process Sales Order Fulfillment flow is initiated when a Siebel CRM customer service representative (CSR) submits an order.

Siebel CRM adds the order message to a Java Messaging Service (JMS) queue, where a JMS consumer picks it up and passes it to the Oracle AIA integration. The Order to Cash business process transforms the message and passes it to OSM for processing.

The Order to Cash business process includes a Test Orchestration Process to test the ready-to-use order flow if you are not using OSM for order management. For production systems, you must replace the test orchestration process with your own order management system. See Oracle Application Integration Architecture Installation and Upgrade Guide for Pre-Built Integrations for more information about replacing the TOP.

For more information about creating Sales Orders, see About Sales Orders.

The following business process options enable the Process Sales Order Fulfillment flow:

• Order to Cash for Oracle Communications Order and Service Management (OSM)

• Order to Cash for Siebel CRM

The Process Sales Order Fulfillment flow includes the following:

• Submitting Orders from Siebel CRM to OSM

About Submitting Orders from Siebel CRM to OSM Integration

This flow uses the following services:

• ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer

• ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl

• ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer

Figure 5-1 shows the sequence of integration services for the Submitting Orders from Siebel CRM to OSM integration flow.

Figure 5-1 Submitting Orders from Siebel CRM to OSM

Description of "Figure 5-1 Submitting Orders from Siebel CRM to OSM"

The Order to Cash business process submits orders from Siebel CRM to OSM as follows:

1. A Siebel CRM user submits a new order.

2. Siebel CRM creates an application business message (ABM) called SalesOrderABM with all the sales order details and drops the ABM into the AIA_SALESORDERJMSQUEUE queue.

3. The ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer service picks up the ABM and passes it on to the ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl service.

4. ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl checks the values of the handleLargeOrderEnabled and numOrderLinesInLargeOrder properties in the AIAConfigurationProperties.xml file and does the following:

   • If the value of handleLargeOrderEnabled is true and the number of order lines is less than the value of numOrderLinesInLargeOrder, or if the value of handleLargeOrderEnabled is false, ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl transforms the ABM into an enterprise business message (EBM) called ProcessSalesOrderFulfillmentEBM and sends it to the ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer service.

   • If the value of handleLargeOrderEnabled is true and the number of order lines is greater than or equal to the value of numOrderLinesInLargeOrder, ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl does the following:

     1. Splits the large SalesOrderABM into mini ABMs. Each mini ABM contains no more order lines than the value of the numOrderLinesInMiniABM configuration property, unless those order lines are part of a Siebel CRM promotion.

        Order lines that are part of a promotion always belong to the same mini ABM, even if this ABM has more order lines than the value of numOrderLinesInMiniABM.

     2. Transforms the mini ABMs into mini EBMs.

     3. Merges the mini EBMs into one ProcessSalesOrderFulfillmentEBM and sends it to ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer.

   The Siebel CRM order structure does not support multiple charge types for a single order line, but the order enterprise business object (EBO) structure does. For this reason, the order lines referencing a complex product of billing type Subscription and its component products of billing type Event (multi-event billing products) are transformed into a single EBO order line referencing a product with multiple charge types.

5. ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer wraps the EBM into OSM CreateOrder message format and enqueues the CreateOrder message into the AIA_CRTFO_IN_JMSQ.

   The CreateOrder message is then wrapped in a SOAP envelope. OSM expects the following additional JMS properties to be set with the JMS payload:

   • JMSPriority

   • URI -- /osm/wsapi

   • _wls_mimehdrContent_Type -- text/xml; charset=utf-8

6. The store and forward mechanism forwards the CreateOrder message from the AIA WebLogic server to the OSM WebLogic server.

   OSM receives the CreateOrder message and decomposes the order, creating EBMs to send for fulfillment and provisioning.

See About First-Time Purchase of Products and Services for more information on how OSM processes the order.

Defining Transaction Boundaries and Recovery Details

Table 5-1 describes the transactions, the database operations, and what actions to take in case of an error for this flow.

If order submission from Siebel CRM causes a system or business error, any further order to the account does not get processed until the error is fixed. All order submissions for that account are locked in the sequencer table. If the error is a business error then the message must be removed from the sequencer table and if the error is a system error then the message must be resubmitted.

The following services are involved:

• ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer

• ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl

• ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer

Table 5-1 Transaction Boundaries and Recovery Details for Siebel CRM Flow

Transaction	DB Operations	In Case of Error	Recovery
ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer passes the Siebel CRM message to ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl, which invokes transformation logic to convert that Siebel CRM message into an EBM. The EBM is then routed to ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer.	AIA cross-reference entries.	Roll back cross-reference transactions. Roll back JMS message to AIA_SALESORDERJMSQUEUE_ErrorQ	Resubmit the order from either AIA_SALESORDERJMSQUEUE_ErrorQ or from Siebel CRM.

See the discussion of configuring Oracle AIA processes for error handling and trace logging in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about rollback procedures.

Assumptions and Constraints for the Process Sales Order Fulfillment Flow

The assumptions and constraints for the Process Sales Order Fulfillment flow are as follows:

• Siebel CRM implements service points as assets and you typically upload them into Siebel CRM from external sources. You should manage service points in a common place and share them between Siebel CRM and Network Inventory (Service and Resource Inventory). The integration assumes that at least one following statement is true:

  • The determination of service point in Siebel CRM is irrelevant to Service and Resource Inventory.

  • The determination of service point in Siebel CRM is replicated in Service and Resource Inventory (for example, the same result is achieved).

  • The service point attribute value is unique and common across Siebel and Service and Resource Inventory, such that Service and Resource Inventory can use the value directly.

  • The service point attribute value is a cross-reference that is understood by Service and Resource Inventory; no Oracle AIA cross-reference exists for this attribute.

• When you create a change order, leave it pending in Siebel CRM, and submit it at a later date, Siebel CRM ensures that the change order data is up to date with the actual data from the installed assets. Any customization of Siebel CRM or integration with a different CRM system must also ensure that pending orders are up to date before submitting them.

• If you submit a follow-on order before submitting the base order on which it depends, OSM processes this follow-on order as a base order. Submit base orders first to establish the follow-on order dependency in OSM.

• Mixing future-dated, follow-on, and revision orders requires a well-trained CSR because some scenarios could produce unintended results.

• Siebel CRM can capture revisions to order Due Date in Siebel CRM (Requested Delivery Date in Oracle AIA) and submit them to Oracle OSM.

• Revising the Requested Delivery Date for an order only affects OSM if the base order did not start fulfillment by the time OSM received the revision.

Supporting Order Priority

The integration supports order priority as follows:

1. A Siebel CRM user submits an order with a string value for priority.

2. The Siebel CRM JMS consumer consumes the message and sends it to the Siebel CRM requester ABCS. While transforming the order message into the EBM, the ABCS looks up the value of the OrderPriority field in the Siebel CRM column of the SALESORDER_PRIORITY domain value map (DVM) and populates the ProcessSalesOrderFulfillmentEBM/DataArea/ProcessSalesOrderFulfillment/FulfillmentPriorityCode with the corresponding value from the common column.

3. When creating the OSM create order message, the ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer service looks up the value of the FulfillmentPriorityCode in the common column of the SALESORDER_PRIORITY DVM and populates the priority in the JMSPriority field in the JMS headers with value from the JMS column using the following BPEL assign activity:

   <assign>
     <copy>
       <from expression="orcl:lookup-dvm('oramds:/apps/AIAMetaData/dvm/SALESORDER_PRIORITY.dvm','COMMON',bpws:getVariableData('priority_value'),'JMS',null)"/>
       <to variable="msg_priority"/>
     </copy>
     <copy>
       <from variable="msg_priority"/>
       <to variable="jmsHeaders" part="outboundHeader" query="/ns5:JMSOutboundHeadersAndProperties/ns5:JMSOutboundHeaders/ns5:JMSPriority"/>
     <copy>
   </assign>
   

   where:

   • jmsHeaders is a variable of type JMSOutboundHeadersAndProperties

   • msg_priority is a string variable

4. The store and forward mechanism picks up the messages according to their priority and sends them to OSM.

5. OSM honors the priority through internal mechanisms. Higher priority orders are fulfilled and provisioned first, followed by lower priority orders.

   OSM maintains the priority of the orders and populates the FulfillmentPriorityCode element in all outbound messages.

Other producers need not do a DVM lookup because the priority value is an integer and is directly populated in the EBMs in the FulfillmentPriorityCode. The integration can use this value to populate the JMS priority. OSM and Oracle AIA, unlike Siebel CRM, follow the same values for JMS priorities.

You can extend Siebel CRM to set JMS priority on the order message. See the discussion of modifying the order priority mapping in Siebel Order Management Guide Addendum for Communications, Employee Asset-Based Ordering for more information about priority values in Siebel CRM.

Supporting Price Lists

The integration supports multiple price lists on orders as follows:

1. A Siebel CRM user submits an order with separate price lists for the order lines. Siebel CRM creates an application business message (ABM) containing the order information, including the price lists specified for the order header and order lines. While creating the ABM, Siebel CRM automatically populates empty price list order lines for the components of customizable products with the price list from the customizable product order line.

2. When the ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl service receives the ABM, it looks up the Siebel CRM row ID in the PRICELIST domain value map (DVM) and populates the ProcessSalesOrderFulfillmentEBM message with the corresponding price list information.

3. When OSM receives the CreateOrder message, it transforms it into a ProcessFulfillmentOrderBillingEBM message. During this transformation, OSM populates empty price list order lines with the price list from the order header.

4. OSM passes the ProcessFulfillmentOrderBillingEBM message on for billing. See About the Bill Fulfillment Order Flow for information about how this message is used.

Siebel CRM Interfaces

The Process Sales Order Fulfillment flow uses the following Siebel CRM interface:

• SISOMBillingSubmitOrderWebService

This is the outbound Siebel CRM web service used to submit orders.

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

Industry Oracle AIA Components

The Process Sales Order Fulfillment flow uses these industry components:

• SalesOrderEBO

• ProcessSalesOrderFulfillmentEBM

• OptimizedSalesOrder

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Industry/Communications/EBO/

• OptimizedSalesOrder EBO files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/PIPS/Communications/Schemas

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 the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

Integration Services

The following services are delivered with the Process Sales Order Fulfillment flow:

• ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer

• ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl

• ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer

ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer

The ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer service is implemented as a Mediator process.

This consumer listens to the AIA_SALESORDERJMSQUEUE into which Siebel CRM enqueues the simple object access protocol (SOAP)-wrapped Siebel CRM Order application business message (ABM). This consumer dequeues the messages from this queue, unwraps the message from the SOAP envelope, and routes the Siebel CRM ABM to the ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl.

ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl

ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl is a business process execution language (BPEL) process with a single operation: Initiate.

This service is invoked when an order is submitted in the Siebel CRM application. It converts the Siebel CRM ABM into the sales order EBM.

Before converting the ABM into an EBM, this service checks whether it should use the Process Large Order sub-flow. The service uses the Process Large Order sub-flow if the handleLargeOrderEnabled property is set to true and the number of order lines in the ABM is greater than or equal to the value of the numOrderLinesInLargeOrder property. In the Process Large Order sub-flow, ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl does the following:

1. Splits the ABM into mini ABMs

2. Transforms the mini ABMs into mini EBMs

3. Merges the mini EBMs into one sales order EBM

While transforming the ABM or mini ABMs, the service does the following:

• Looks up the following cross-reference values to find common IDs to appropriately populate the sales order EBM:

  • subscriber account ID

  • billing profile ID

  • pay profile ID

  • organization ID

  • product or discount ID

  • promotion group member ID

  • price list common ID (from the PRICELIST DVM)

  If no cross-reference values exist for promotions and service bundles, the service creates ones.

• Creates the following cross-reference values between Siebel CRM values and generated common values:

  • order ID

  • order line ID

  • installed product ID

  • account ID

  • bill profile ID

  • pay profile ID

  • contact ID

  • address ID

  • balance group ID

  • promotion group member ID

  • asset ID

• Sets the OrderSubject attribute to CUSTOMER.

• Records any payment IDs on the order in the SalesOrderReceivedPayment section of the EBM.

See Table 6-2 for more details about the cross-references created by this service.

ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer

The ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer is a BPEL process that has a JMS Adapter Service, which enqueues the message ProcessSalesOrderFulfillmentEBM into AIA_CRTFO_IN_JMSQ after wrapping it into SOAP envelope (for putting WS-security information for OSM) and OSM's CreateOrder envelope.

This service has one operation: ProcessSalesOrderFulfillment. It takes the ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducerRequestMessage as input.

Implementing the Synchronize Fulfillment Order Billing Account Flow

This section explains how the Order to Cash business process implements the Synchronize Fulfillment Order Billing Account flow.

About the Synchronize Fulfillment Order Billing Account Flow

The Synchronize Fulfillment Order Billing Account flow lets you create subscriber data in Oracle Communications Billing and Revenue Management (BRM) from orders submitted from Siebel CRM and processed by Oracle Communications Order and Service Management (OSM).

This flow creates the subscriber data necessary for order fulfillment without overburdening BRM with all of the subscriber information available in Siebel CRM. It also lets you process payments accepted at order time.

Figure 5-2 shows the sequence of events in this flow.

Figure 5-2 Synchronize Fulfillment Order Billing Account Flow

Description of "Figure 5-2 Synchronize Fulfillment Order Billing Account Flow"

The following business process options enable the Synchronize Fulfillment Order Billing Account flow:

• Order to Cash for Oracle Communications Order and Service Management (OSM)

• Order to Cash for Oracle Communications Billing and Revenue Management (BRM)

• Order to Cash for Siebel CRM

This flow includes Interfacing Orders to Create Subscriber Data.

Note:

In this flow, the CommsProcessBillingAccountListEBF enterprise business flow (EBF) communicates directly with application business connector services (ABCS).

Although direct communication between EBF and ABCS enhances performance for this flow, Oracle recommends that you follow the canonical model when you develop your own integration flows. In the canonical model, an EBF can invoke only an enterprise business service (EBS), which in turn invokes the ABCS. This model allows the EBF to be application agnostic.

For more information about the canonical model and developing integration flows, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.

About the Interfacing Orders to Create Subscriber Data Integration Flow

OSM starts this flow during order orchestration to create subscriber data in BRM using Siebel CRM orders. Integration flows from the integration for subscriber management create accounts and their components (such as billing preferences and payment methods) in BRM.

See About Subscriber Management for more information about Subscriber Management.

The Interfacing Orders to Create Subscriber Data Integration integration flow processes lines with ADD, UPDATE, and MOVE-ADD.

The lines are processed as follows:

• For lines with product type of Promotion, it uses Billing Account.

• All other lines are ignored.

The Interfacing Orders to Create Subscriber Data Integration flow uses the order data to create accounts, /billinfo objects, and /payinfo objects in BRM. It cannot inactivate or delete the objects that it creates.

When you call the integration flow again with different customer data than before, it creates only the accounts, /billinfo objects, and /payinfo objects that do not already exist in BRM.

Defining Transaction Boundaries and Recovery Details

For the Synchronize Fulfillment Order Billing Account flow there are two transaction boundaries. Table 5-2 describes the transactions involved, the database operations, and what actions to take in case of an error.

If any account creation causes a system or business error, any further updates to the account (and thereby processing of other orders for that account) do not occur until the error is fixed. All updates for that account are locked in the sequencer table. If the error is a business error then the message must be removed from the sequencer table and if the error is a system error then the message must be resubmitted.

See Using Error Type to Control Response to Order Fallout for more information on system and business errors.

Table 5-2 Transaction Boundaries and Recovery Details

Transaction	DB Operations	In Case of Error	Recovery
ProcessFulfillmentOrderBillingAccountListSiebelCommsJMSConsumer sends the message to CommsProcessFulfillmentOrderBillingAccountListEBF, which extracts relevant subscriber data. If account hierarchy is required, the EBF sends the message to ProcessAccountHierarchyListSiebelCommsProvABCSImpl, which queries Siebel CRM for the hierarchy. Siebel CRM responds and the ABCS sends the response to CommsProcessFulfillmentOrderBillingAccountListEBF. The EBF then sends the message to CommsProcessBillingAccountListEBF. This EBF sends the message to QueryCustomerPartyListSiebelProvABCSImplV2, which queries account details from Siebel CRM. Siebel CRM responds, and the ABCS sends the response to CommsProcessBillingAccountListEBF. The EBF sends the message to CommunicationsCustomerPartyEBSV2Resequencer.	Oracle AIA cross-reference tables updated. Message goes into the sequencer table.	Message available in Enterprise Manager Fusion Middleware Control in recoverable state.	Retry or abort the message from Enterprise Manager Fusion Middleware Control.
CommunicationsCustomerPartyEBSV2Resequencer sends a message to SyncCustomerPartyListBRMCommsProvABCSImpl, which invokes BRM opcodes to create accounts. BRM responds with a confirmation, which the ABCS sends to CommsProcessBillingAccountListEBF. CommsProcessBillingAccountListEBF sends a message to ProcessCollectionSharingBRMCommsProvABCSImpl, which invokes BRM opcodes to create collections sharing groups. BRM responds with a confirmation, which the ABCS sends to CommsProcessBillingAccountListEBF. The EBF sends the message to CommsProcessFulfillmentOrderBillingAccountListEBF, which sends it to ProcessFulfillmentOrderBillingAccountListResponseOSMCFSCommsJMSProducer. The producer drops the message into AIA_UPDCUST_IN_JMSQ.	Oracle AIA cross reference tables updated. Message goes to AIA_UPDCUST_IN_JMSQ. Accounts and collections sharing groups created in BRM.	Roll back Oracle AIA cross reference updates. Roll back BRM account and collections sharing group creation. Return message to sequencer table.	Resubmit message from sequencer table.

Note:

If any order contains more than one account and a failure occurs after any account is processed successfully but the subsequent account fails, then error recovery may become difficult based on the point of failure. Customers must first examine the point of failure and then determine if it's necessary to recover the BPEL instance from the recovery console.

For more information about rollback procedures, see the Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension, which covers error handling and trace logging in Oracle AIA processes.

Assumptions and Constraints for the Synchronize Fulfillment Order Billing Account

The Synchronize Fulfillment Order Billing Account has the same assumptions and constraints as the Bill Fulfillment Order. See Assumptions and Constraints for the Bill Fulfillment Order Business Flow for information.

If you use an order management system other than OSM, your order management system must meet certain expectations. Table 5-3 summarizes what is expected for the action on order lines. OSM and OSM O2A cartridges conform to these expectations.

Table 5-3 Actions on Order Line Expectations Summary

Original Action on Order Line	Type of Order (Revision or New)	Type of Revision	Action Set by Order Management System on Compensation Order Line	Comments
ADD	New	Not applicable	ADD	None.
ADD	Revision	No changes to service account, billing account, or billing profile.	NONE	No changes for customer sync to process.
ADD	Revision	Changes to service account, billing account, billing profile, or owner account.	UPDATE	The order management system creates customer data in BRM if it does not already exist. If revisions are made to attributes affecting account hierarchy, the order management system makes the change in BRM. If the owner account is changed, the order management system changes the collections sharing group in BRM. The order management system indicates which attributes have changed by populating the prior value fields for the changed attributes.
ADD	Revision	Cancellation. Manifests as a missing line on the revision.	DELETE	This action is ignored. If the original ADD line added a new account, /billinfo object, and /payinfo object, and the revision cancels the request for the new purchase, the account, /billinfo, and /payinfo are not inactivated or deleted. If the original ADD line created a paying hierarchy and the revision cancels the request for the new purchase, then the paying hierarchy stays in place.
UPDATE	New	Not applicable	UPDATE	Expects prior value fields to be populated.
UPDATE	Revision	No changes to service account, billing account, or billing profile.	NONE	No changes.
UPDATE	Revision	Changes to service account, billing account, billing profile, or owner account.	UPDATE	The order management system creates customer data in BRM if it does not already exist. If revisions are made to attributes affecting account hierarchy, the order management system makes the change in BRM. If the owner account is changed, the order management system changes the collections sharing group in BRM. The order management system indicates which attributes have changed by populating the prior value fields for the changed attributes.
UPDATE	Revision	Cancellation. Manifests as a missing line on the revision or the action changing to a "-" (NONE).	UPDATE	If the original update line created a new account and billing profile in BRM, then it cannot be undone. For the attributes that have changed on the original line, the order management system flips the values (old, new) on the compensation line. If a hierarchy has been updated, this reverts that update.
MOVE-ADD	New, but can change billing account and billing profile as part of a move-add.	Not Applicable	MOVE-ADD	Expects prior value fields to be populated for values that are changing from an existing asset.
MOVE-ADD	Revision	No changes to service account, billing account, or billing profile.	NONE	No changes.
MOVE-ADD	Revision	Changes to billing account or billing profile.	MOVE-ADD	The order management system creates customer data in BRM if it does not already exist. If revisions are made to attributes affecting account hierarchy, the order management system makes the change in BRM. The order management system indicates which attributes have changed by populating the prior value fields for the changed attributes.
MOVE-ADD	Revision	Manifests as a missing line on the revision or the action changing to a "-" (The line is canceled).	MOVE-ADD	If the original MOVE-ADD line created a new account and billing profile in BRM, then it cannot be undone. For the attributes that have changed on the original line, the order management system flips the values (old, new) on the compensation line. If a hierarchy has been updated, this reverts that update.

Caution:

The process integration for billing management (delivered in the Cash to Care Business Process business process) assumes that a given billing profile is synchronized to a single billing system. It does not support the ability to query data for the same billing profile from multiple billing system. For that reason, if that process integration is in use, then the same billing profile must not be used on an order for services that are fulfilled in different billing systems.

See the discussion of billing management in Oracle Application Integration Architecture Siebel CRM Integration Pack for Oracle Communications Billing and Revenue Management: Cash to Care Business Process Implementation Guide for more information.

BRM Interfaces

The Synchronize Fulfillment Order Billing Account flow uses the following BRM interfaces:

Table 5-4 BRM Interfaces

Opcode	Purpose
PCM_OP_BILL_GROUP_MOVE_MEMBER	As part of the Create/Sync Account integration flow, modifies a hierarchical account group (moves an account between groups, creates a group if one doesn't exist, deletes a group if it is empty).
PCM_OP_COLLECTIONS_GROUP_CREATE	As part of the Create/Sync Account integration flow, creates a collections sharing group with the subscriber account as the owner and the billing account as a member.
PCM_OP_COLLECTIONS_GROUP_ADD_MEMBER	As part of the Create/Sync Account integration flow, adds the billing account as a member of a collections sharing group owned by the subscriber account.
PCM_OP_COLLECTIONS_GROUP_DELETE_MEMBER	As part of the Create/Sync Account integration flow, removes the billing account as a member of a collections sharing group owned by the subscriber account.
PCM_OP_COLLECTIONS_GROUP_DELETE	As part of the Create/Sync Account integration flow, deletes the collections sharing group owned by the subscriber account.
PCM_OP_CUST_COMMIT_CUSTOMER	As part of the Create/Sync Account integration flow, creates a new account with one or more /billinfo and /payinfo objects.
PCM_OP_CUST_UPDATE_CUSTOMER	As part of the Create/Sync Account integration flow, updates account information (name, address, phone), contact information, and billing information.
PCM_OP_CUSTCARE_MOVE_ACCT	As part of the Create/Sync Account integration flow, moves a child account to a new parent account.
PCM_OP_PYMT_COLLECT	Records a payment for the billing account and billing profile on the order.

See Oracle Communications Billing and Revenue Management Developer's Reference for descriptions of these opcodes.

Siebel CRM Interfaces

The Synchronize Fulfillment Order Billing Account flow uses the following Siebel CRM interface:

• OrderDetailWebService: This web service queries orders and retrieves payment details.

See Siebel CRM Web Services Reference for more information about this web service.

See Siebel CRM Interfaces in "Implementing the Synchronized Subscriber Account Flow" for more information about the web services used by the Create/Sync Account integration flow.

Industry Oracle AIA Components

The Synchronize Fulfillment Order Billing Account flow uses the following communications industry-specific Oracle AIA components:

• FufillmentOrderEBO

• ProcessFulfillmentOrderBillingAccountListEBM

• ProcessBillingAccountListEBM

• ProcessFulfillmentOrderBillingAccountListResponseEBM

• ReceivedPaymentEBM

• ReceivedPaymentEBO

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/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 the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

See Industry Oracle AIA Components for more information about the industry Oracle AIA components used by the Create/Sync Account integration flow.

Integration Services

The following services are delivered with the Synchronize Fulfillment Order Billing Account flow as part of the Interfacing Orders to Create Subscriber Data integration flow:

• ProcessFulfillmentOrderBillingAccountListOSMCFSCommsJMSConsumer

• ProcessFulfillmentOrderBillingAccountListSiebelCommsJMSConsumer

• CommsProcessFulfillmentOrderBillingAccountListEBF

• QueryReceivedPaymentListSiebelCommsProvABCSImpl

• CreateReceivedPaymentListBRMCommsProvABCSImpl

• ProcessFulfillmentOrderBillingAccountListResponseOSMCFSCommsJMSProducer

Additional services are delivered with the Synchronize Fulfillment Order Billing Account flow as part of the Create/Sync Subscriber Account integration flow, which is part of the Synchronize Subscriber Account flow. See Integration Services in "Implementing the Synchronize Subscriber Account Flow" for more information about these services.

ProcessFulfillmentOrderBillingAccountListOSMCFSCommsJMSConsumer

This consumer listens to the AIA_CRTCUST_OUT_JMSQ queue. It picks up ProcessFulfillmentOrderBillingAccountListEBM messages and adds the messages into the AIA_CRTCUST_OUT_Siebel_JMSQ queue.

ProcessFulfillmentOrderBillingAccountListSiebelCommsJMSConsumer

This consumer listens to the AIA_CRTCUST_OUT_Siebel_JMSQ queue. It picks up ProcessFulfillmentOrderBillingAccountListEBM messages and sends them to the CommsProcessFulfillmentOrderBillingAccountListEBF service.

CommsProcessFulfillmentOrderBillingAccountListEBF

This service is an asynchronous delayed response Business Process Execution Language (BPEL) process extracts subscriber data from the order. It loops through every order line and extracts subscriber accounts and billing profiles. It uses these data to call the services that query Siebel CRM for account information.

This service does the following:

1. Receives ProcessFulfillmentOrderBillingAccountListEBM from ProcessFulfillmentOrderBillingAccountListOSMCommsJMSConsumer or ProcessFulfillmentOrderBillingAccountListSiebelCommsJMSConsumer.

2. Transforms ProcessFulfillmentOrderBillingAccountListEBM into ProcessBillingAccountListEBM.

3. If the value for the O2C.CorporateHierarchyAccountType Oracle AIA configuration property matches the account type on the order, the service:

   1. Sends ProcessBillingAccountListEBM to ProcessAccountHierarchyListSiebelCommsProvABCSImpl.

   2. Receives ProcessBillingAccountListResponseEBM from ProcessAccountHierarchyListSiebelCommsProvABCSImpl.

   3. Transforms ProcessBillingAccountListResponseEBM into ProcessBillingAccountListEBM.

4. Sends ProcessBillingAccountListEBM to CommsProcessBillingAccountListEBF.

5. Receives ProcessBillingAccountListResponseEBM from CommsProcessBillingAccountListEBF.

6. If there is a payment-related billing profile ID on the order, the service:

   1. Transforms ProcessFulfillmentOrderBillingAccountListEBM into QueryReceivedPaymentListEBM and sends it to QueryReceivedPaymentListSiebelCommsProvABCSImpl

   2. Receives QueryReceivedPaymentListResponseEBM from QueryReceivedPaymentListSiebelCommsProvABCSImpl

   3. Transforms QueryReceivedPaymentListResponseEBM to CreateReceivedPaymentListEBM and sends it to CreateReceivedPaymentListBRMCommsProvABCSImpl

   4. Receives CreateReceivedPaymentListResponseEBM from CreateReceivedPaymentListBRMCommsProvABCSImpl

7. Transforms ProcessBillingAccountListResponseEBM and CreateReceivedPaymentListResponseEBM into ProcessFulfillmentOrderBillingAccountListResponseEBM and sends it to ProcessFulfillmentOrderBillingAccountListResponseOSMCFSCommsJMSProducer.

OSM does not expect a response for errors. OSM uses Oracle AIA order fallout notification to generate a trouble ticket and change the order and line status to indicate failure.

If you are using an order management system other than OSM, you can send a response message for errors to the order management system based on the responseCode attribute of the DataArea of the ProcessFulfillmentOrderBillingAccountListEBM message from the order management system.

If the responseCode value is REQUIRED_FOR_BUSINESS_AND_SYSTEM_ERRORS, the response message is sent back to the order management system for all errors. If the responseCode value is REQUIRED_FOR_BUSINESS_ERRORS, the response message is only sent back to the order management system for business errors.

QueryReceivedPaymentListSiebelCommsProvABCSImpl

This BEPL process queries Siebel CRM for payment information recorded on sales orders. It processes only payments with the payment status of New.

This service does the following:

1. Receives QueryReceivedPaymentListEBM from CommsProcessFulfillmentOrderBillingAccountListEBF.

2. Transforms QueryReceivedPaymentListEBM into an OrderDetailQueryPage_Input message containing an order ID, and sends the message to OrderDetailWebService.

3. Receives the OrderDetailQueryPage_Output response message from OrderDetailWebService.

4. Transforms OrderDetailQueryPage_Output into QueryReceivedPaymentListResponseEBM and sends it to CommsProcessFulfilmentOrderBillingAccountListEBF.

CreateReceivedPaymentListBRMCommsProvABCSImpl

This BEPL process invokes opcodes to create payments in BRM.

This service does the following:

1. Receives CreateReceivedPaymentListEBM from CommsProcessFulfillmentOrderBillingAccountListEBF.

2. Transforms CreateReceivedPaymentListEBM into the PCM_OP_PYMT_COLLECT input message containing payment information, and invokes the opcode.

3. Receives the response from the opcode.

4. Transforms the opcode response into CreateReceivedPaymentListResponseEBM and sends it to CommsProcessFulfilmentOrderBillingAccountListEBF.

ProcessFulfillmentOrderBillingAccountListResponseOSMCFSCommsJMSProducer

This JMS producer service receives the ProcessFulfillmentOrderBillingAccountListResponseEBM and drops it into the AIA_UPDCUST_IN_JMSQ queue.

Implementing the Bill Fulfillment Order Flow

This section describes the Bill Fulfillment Order flow and explains how the Oracle Communications Order to Cash business process implements it.

About the Bill Fulfillment Order Flow

The Bill Fulfillment Order flow is initiated when OSM drops a transformed order into a Java Messaging Service (JMS) queue, where a JMS consumer picks it up and passes it to the integration. The integration transforms the messages and passes it to BRM for billing.

The following business process options enable the Bill Fulfillment Order flow:

• Oracle Communications Order to Cash for Oracle Communications Billing and Revenue Management (BRM)

• Oracle Communications Order to Cash for Oracle Communications Order and Service Management (OSM)

The Bill Fulfillment Order flow supports the following:

• Interfacing Orders to Create Transaction Data in BRM

About the Interfacing Orders to Create Transaction Data in BRM Integration Flow

The Interfacing Orders to Create Transaction Data in BRM integration flow uses the following services:

• ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer

• ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl

• ProcessFulfillmentOrderBillingOSMCFSCommsJMSProducer

Figure 5-3 shows the sequence of integration services for the Interfacing Orders to Create Transaction Data in BRM integration flow.

Figure 5-3 Bill Fulfillment Order Sequence

Description of "Figure 5-3 Bill Fulfillment Order Sequence"

The integration interfaces orders to create transaction data in BRM as follows:

1. While decomposing and orchestrating an order created by the Process Sales Order Fulfillment flow, OSM creates a ProcessFulfillmentOrderBillingEBM message and drops it into the AIA_CRTBO_OUT_JMSQ JMS queue.

2. The ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer service picks up ProcessFulfillmentOrderBillingEBM and sends it to the ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl service.

3. ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl uses ProcessFulfillmentOrderBillingEBM to invoke opcodes and create billing data in BRM, including billing artifacts, service instances with balance group information, purchased products, purchased discounts, and sharing groups.

4. The opcodes send output response messages, which ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl transforms into the ProcessFulfillmentOrderBillingResponseEBM message and sends back to the ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer service.

5. ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer drops ProcessFulfillmentOrderBillingResponseEBM into the AIA_UPDBO_IN_JMSQ queue where OSM receives updates.

Defining Transaction Boundaries and Recovery Details

For this flow there is one transaction boundary. Table 5-5 describes the transaction involved, the database operations, and what actions to take in case of an error.

See Using Error Type to Control Response to Order Fallout for more information about system errors and business errors.

The following services are involved:

• ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer

• ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl

• ProcessFulfillmentOrderBillingBRMCommsAddSubProcess

• ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess

• ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess

• ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess

• ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess

• ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer

Table 5-5 Transaction Boundaries and Recovery Details

Transaction	DB Operations	In Case of Error	Recovery
The ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer service passes the message to the ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl service, which creates billing artifacts and calls one or more subprocesses. The response message is then routed to the ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer service.	AIA cross-references created. BRM data created. Message goes to the AIA_UPDBO_IN_JMSQ queue.	Rollback AIA cross-references. Rollback data created in BRM. Message goes back to the originating queue (AIA_CRTBO_OUT_JMSQ_ErrorQ).	Resubmit the order from the AIA_CRTBO_OUT_JMSQ_ErrorQ queue.

See the discussion of configuring Oracle AIA processes for error handling and trace logging in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about rollback procedures.

Assumptions and Constraints for the Bill Fulfillment Order Business Flow

The assumptions and constraints for the Bill Fulfillment Order business flow are as follows:

• The integration only supports defining a single brand within a single instance of BRM.

• After an order in Siebel CRM is submitted for processing and successfully interfaced to billing, it cannot be changed and resubmitted. You must enforce this by defining rules in the Siebel CRM state model. The order can be revised and resubmitted for processing if it has not reached a point of no return. The integration assumes that the order line reaches the point of no return after the line has been sent for billing fulfillment.

• The integration does not support copied orders in Siebel CRM because Siebel CRM does not regenerate the asset integration ID that uniquely identifies purchases on the copied order. Instead of copying orders, Oracle recommends that you use the Siebel CRM Favorites feature.

• Regarding quantity support for service bundles and account-level products, the solution assumes that the auto-explode flag on service bundle products is set to Yes and that the customer is using Siebel Asset Based Ordering processes to enforce service item instantiation.

  • The service bundle line always has a quantity of 1 when the order is handed off from Siebel CRM to the integration with the integration creating a single service instance in BRM (per service bundle line on the Siebel order).

    No special handling exists for order quantity > 1 for products whose auto-explode flag in Siebel is set to No.

  • Quantity (and not extended quantity) on service bundle components or account-level products is interfaced to BRM. This creates purchased product or discount instances (one instance per product or discount purchased) with the specified quantity, which is used to determine charge calculation.

  • When an order line is interfaced to Siebel CRM assets it creates a single asset with the specified quantity.

    Additionally, the integration does not look at quantity changes on revisions, or change orders (for existing products) and therefore such changes are not communicated to BRM.

• No special handling exists for shippable goods. No support is available for returns or credit orders.

• If you are also using the Cash to Care Business Process pre-built integration, order lines that must be sent to different billing systems must have different billing profiles.

• Order lines are interfaced to billing only after they have been provisioned.

  Based on this assumption, the service that interfaces the lines with billing creates the service instances, purchased product instances, purchased discount instances, or a combination of these as active. This applies to scenarios of single-phase billing, in which billing interface is called one time in Fulfill Billing mode.

• For self-paying accounts, the service account, billing account, and billing profiles must be the same on all order lines for components in a service bundle.

  • When service-level balance groups are enabled, you must ensure that these fields are the same for service bundles and their components.

  • When service-level balance groups are disabled, any integration logic that works on these fields looks only at the service bundle line. This constraint also applies to one-time charges that are added for MACD actions such as suspending or resuming a service. This means that the integration ignores the service account, billing account, and billing profiles on such lines and applies the charge to the default account-level balance group.

• For nonpaying child accounts, when service-level balance groups are enabled, the billing account can be different for service bundles and simple service bundles nested within a service bundle. For example, if two parents pay for the services of one child, one service bundle component could list one billing account, while a different component in the same service bundle could list a different billing account. An order including multiple billing accounts for the same service account results in a /billinfo hierarchy in BRM.

• The integration does not support changing from nonpaying child account to self-paying account or changing from self-paying account to nonpaying child account. Changing accounts in this way does not produce an error but results in data that breaks the billing management integration flows.

• A nonpaying child account can have multiple paying parents. In Siebel CRM, this relationship is represented in the account hierarchy, and by assigning different billing accounts to the services for one service account. In BRM, this relationship is represented by a /billinfo hierarchy.

• All lines within a service bundle reference products from the same billing system.

  A single Siebel CRM asset can be mapped to a service instance or a purchased product or discount instance in only one billing system.

• The integration assumes that the service bundle and its component products reference the same billing service type. This assumption applies only to component products that represent BRM products of type Subscription or BRM discounts. Violation of this assumption results in a BRM error. Nested service bundles do not have to have the same service type as the root parent service bundle. See Oracle Communication Digital Business Experience Concept to Market Implementation Guide for more information.

BRM Interfaces

The Bill Fulfillment Order flow uses these services:

• PCM_OP_CUST_CREATE_PROFILE

• PCM_OP_CUST_DELETE_PROFILE

• PCM_OP_CUST_MODIFY_CUSTOMER

• PCM_OP_CUST_MODIFY_PROFILE

• PCM_OP_CUST_SET_STATUS

• PCM_OP_CUST_UPDATE_SERVICES

• PCM_OP_READ_FLDS

• PCM_OP_READ_OBJ

• PCM_OP_SEARCH

• PCM_OP_SUBSCRIPTION_CANCEL_DISCOUNT

• PCM_OP_SUBSCRIPTION_CANCEL_PRODUCT

• PCM_OP_SUBSCRIPTION_ORDERED_BALGRP

• PCM_OP_SUBSCRIPTION_PURCHASE_DEAL

• PCM_OP_SUBSCRIPTION_SERVICE_BALGRP_TRANSFER

• PCM_OP_SUBSCRIPTION_SET_PRODINFO

• PCM_OP_SUBSCRIPTION_SHARING_GROUP_CREATE

• PCM_OP_SUBSCRIPTION_SHARING_GROUP_DELETE

• PCM_OP_SUBSCRIPTION_SHARING_GROUP_MODIFY

• PCM_OP_SUBSCRIPTION_SET_BUNDLE

• PCM_OP_SUBSCRIPTION_SET_DISCOUNT_STATUS

• PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS

• PCM_OP_SUBSCRIPTION_TRANSFER_SUBCRIPTION

See Oracle Communications Billing and Revenue Management Developer's Reference for descriptions of these opcodes.

Industry Oracle AIA Components

The Bill Fulfillment Order flow uses these industry components:

• FufillmentOrderEBO

• ProcessFulfillmentOrderBillingEBM

• ProcessFulfillmentOrderBillingResponseEBM

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/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 the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

Integration Services

The following services are delivered with the Bill Fulfillment Order flow:

• ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer

• ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl

  • ProcessFulfillmentOrderBillingBRMCommsAddSubProcess

  • ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess

  • ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess

  • ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess

  • ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess

  • ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess

• ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer

ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer

The ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer service is a Mediator process that has a JMS Adapter Service, which continuously polls the AIA_CRTBO_OUT_JMSQ queue. The ProcessFulfillmentOrderBillingOSMCFSCommsJMSConsumer service dequeues the ProcessFulfillmentOrderBillingEBM message and routes it to the ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl service.

This service has one operation: Consume_Message.

ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl

The ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl service consists of a BPEL process with one operation: ProcessBilling. It receives the Order EBM and then converts the message into a BRM-specific message based on which opcode must be invoked.

This service communicates with BRM using the custom Java EE Connector Architecture (JCA) adapter provided by BRM. It uses the default capability of the custom JCA adapter to define unit transactions for every order. (Do all or none.)

The routing to the right BRM instance is done using dynamic end point binding in the BPEL process using the target application that is decided.

This service accepts the appropriate ProcessFulfillmentOrderBillingEBM message and is responsible for transforming to the relevant BRM ABM and invoking the corresponding opcode.

The ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl service performs the following activities:

• Evaluates the product type of the order line and the action code. If the particular order line is a service bundle, subscription, discount, or item and if this line has never been interfaced to BRM, it calls the subprocesses as described in Table 5-6.

  Table 5-6 Subprocesses Called by Action Code, Billing Mode, and Fulfillment Mode

  Action Code	Billing Mode	Fulfillment Mode	Subprocess
  ADD	INITIATE BILLING	DO	ProcessFulfillmentOrderBillingBRMCommsAddSubProcess and ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess
  ADD	FULFILL BILLING	DO	ProcessFulfillmentOrderBillingBRMCommsAddSubProcess and ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess
  ADD	INITIATE BILLING	REDO	ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess
  ADD	INITIATE BILLING	UNDO	ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess
  DELETE	FULFILL BILLING	DO	ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess and ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess
  SUSPEND or RESUME	FULFILL BILLING	DO	ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess
  UPDATE	FULFILL BILLING	DO	ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess and ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess
  MOVE-ADD	FULFILL BILLING	DO	ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess and ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess

• For Promotion on Invoice, ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl calls the PCM_OP_SUBSCRIPTION_SET_BUNDLE opcode and different values are passed depending on the particular functional operation.

• When the order has promotion group order lines, ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl calls the ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess service. See ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess.

• After all of these activities, the data is cross-referenced to the AIA XREF database.

In case of errors, AIA can send a response message to the order management system, depending on the value of the responseCode attribute of the DataArea on ProcessFulfillmentOrderBillingEBM.

If the value of responseCode is REQUIRED_FOR_BUSINESS_AND_SYSTEM_ERRORS, AIA sends a response message to the order management system for all errors. If the value of responseCode is REQUIRED_FOR_BUSINESS_ERRORS, AIA only sends a response message to the order management system for business errors.

Note:

OSM does not expect a response for errors. Instead, OSM uses the Oracle AIA order fallout notification to both generate a trouble ticket and change the order and line status to indicate failure.

ProcessFulfillmentOrderBillingBRMCommsAddSubProcess

The ProcessFulfillmentOrderBillingBRMCommsAddSubProcess is a synchronous BPEL process that is called by the ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl. This call depends on the action code present on the order line and also the type of product.

The ProcessFulfillmentOrderBillingBRMCommsAddSubProcess is called for a service bundle, account-level product, or account-level discount that is being newly added either as a part of a new order or an update order and that has an action code of Add.

The ProcessFulfillmentOrderBillingBRMCommsAddSubProcess is never called for any one-time penalty charges that also have an action code of Add, but are being added as a part of the MACD operation performed on a service bundle or a promotion.

The ProcessFulfillmentOrderBillingBRMCommsAddSubProcess receives a custom message that has the ProcessFulfillmentOrderBillingEBM, XREFPopulate, and XREFDelete DataStructure.

The structure of the message coming in to the ProcessFulfillmentOrderBillingBRMCommsAddSubProcess comprises:

• ProcessFulfillmentOrderBillingEBM

• XREFPopulate

• XREFDelete

Depending on the type of product for every order Line, the following operations are performed in the ProcessFulfillmentOrderBillingBRMCommsAddSubProcess:

1. The incoming payload is tunneled through two transforms. The first transform groups all the service bundles per service account and the second transform groups all the account-level purchases.

   • When the product type is service bundle, the BPEL process accumulates all of the children inside the service bundle and calls the PCM_OP_CUST_MODIFY_CUSTOMER opcode. During this call, the ProcessFulfillmentOrderBillingBRMCommsAddSubProcess also transforms the ProcessFulfillmentOrderBillingEBM into a BRM-specific message. All the service bundles per service account per billing profile are passed in one single PCM_OP_CUST_MODIFY_CUSTOMER opcode call.

   • When the product type is an account-level subscription, discount, or item, then this BPEL process calls the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL opcode. During this call, the ProcessFulfillmentOrderBillingBRMCommsAddSubProcess also transforms the ProcessFulfillmentOrderBillingEBM into a BRM-specific message.

2. After the BRM opcode calls are successfully carried out, this BPEL process captures the POID (ObjectIdentifier) returned by BRM and populates the XREFPopulateData. See Table 6-2 for more details about the cross-references populated.

3. For ITEM, the POID (ObjectIdentifier) is returned by BRM only during INITIATE BILLING mode.

This service communicates with BRM using the JCA adapter provided by BRM. The service uses the default capability of the JCA adapter to define unit transactions for every order. (Do all or none.)

This service supports two modes of billing:

• Initiate billing

• Fulfill billing

ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess

The ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess is a synchronous BPEL process that is called by the ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl. This call depends on the action code present on the order line and also the type of product. It has one operation: processBillingMove.

The structure of the message coming in ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess comprises:

• ProcessFulfillmentOrderBillingEBM

• XREFPopulate

• XREFDelete

When the action code on the order line is MoveAdd and the product type is a service bundle, a subscription product, an account-level product, or an account-level discount, the ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess is called.

This process supports the following situations:

• Transferring a service from one billing profile, service account, or billing account to another when service-level balance groups are enabled. This includes changing the paying account for services on a child account.

  The ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess service calls the ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess service. See ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess for information about how the Update subprocess implements the service transfer.

• Changing the paying account for services on a child account when service-level balance groups are disabled. Both billing profile and billing account must be changed.

  The ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess service calls the ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess service. See ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess for information about how the Update subprocess implements the changes to billing profile and billing account.

• Changes to ServiceID, Price Override, and Discount Override made as part of a move-add command.

  To process the changes, after ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess is invoked, ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl invokes ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess.

• Simple Move-Add of the service bundles from one location to another.

  There is no BRM interaction for this operation. Only the entries in the cross-reference tables are repointed.

• A Move-Add order accompanied by a one-time penalty charge.

  When a one-time penalty charge is associated, the ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL BRM opcode.

ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess

The structure of the message coming in the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess comprises:

• ProcessFulfillmentOrderBillingEBM

• XREFPopulate

• XREFDelete

The ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess is a synchronous BPEL process that is called by the ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl. This call depends on the action code present on the order line and also the type of product. It has one operation: processBillingSuspendResume.

When the action code is Suspend or Resume and the ProductType is a service bundle or an account-level subscription or account-level discount, then the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess is called.

The following operations are done by this process:

• When the action code is Suspend or Resume and the product type is a service bundle.

  ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_CUST_SET_STATUS BRM opcode.

  When the action code is Suspend, then the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess passes the Flag= 10102.

  When the action code is Resume, then the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess passes the Flag= 10100.

• When the action code is Suspend or Resume and the product type is Account-Level Discount:

  ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_SET_DISCOUNT_STATUS BRM opcode.

  When the action code is Suspend, then the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess passes the Flag= 2.

  When the action code is Resume, then the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess passes the Flag= 1.

• When the action code is Suspend or Resume and the product type is Account-Level Subscription.

  ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS BRM opcode.

  When the action code is Suspend, then the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess passes the Flag= 2.

  When the action code is Resume, then the ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess passes the Flag= 1.

  For Operation 1, a one-time penalty charge may or may not be associated.

• When a one-time penalty charge is associated with the service bundle, then depending on the action code, the one-time charge gets added in the following manner:

  When the action code is Suspend, the one-time charge gets added first.

  ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL BRM opcode.

  After the one-time charge is added, then Operation 1 is run to suspend the service bundle.

  When the action code is Resume, the one-time charge gets added after the service bundle is resumed.

  Operation 1 is run to resume the service bundle.

  Afterwards, the one-time charge gets added:

  ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL BRM opcode.

ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess

The ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess service is a synchronous BPEL process that is called by the ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl service. This call depends on the action code present on the order line and the type of product. It has one operation: processBillingUpdate.

The structure of the message coming in ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess comprises:

• ProcessFulfillmentOrderBillingEBM

• XREFPopulate

• XREFDelete

When the action code is Update and the product type is a service bundle, subscription product, or account-level discount, the ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess is called.

This process supports the following update situations:

• Updating billing profiles, billing accounts, or service accounts for service bundles.

  • When service-level balance groups are enabled, you can transfer a service from one billing profile, billing account, or service account to another. This includes changing the paying account for the services on a child account.

    ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message including new billing profile, service account, billing account, and balance group information. The process then calls the PCM_OP_CUST_MODIFY_CUSTOMER opcode to update the billing profile or billing account, and the PCM_OP_SUBSCRIPTION_SERVICE_BAL_GRP_TRANSFER opcode to transfer the services to the new service account and update the balance group POIDs in the cross-reference table.

  • When service-level balance groups are disabled, you can change the paying account for the services on a subordinate account by updating both the billing profile and the billing account.

    ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message including new billing profile and billing account. The process then calls the PCM_OP_CUST_MODIFY_CUSTOMER opcode to update the billing profile and billing account in BRM.

• Updating the service ID for a particular service bundle.

  During this scenario, you can update the service ID for one or more service bundles as part of regular modify orders or as part of Move-Add.

  ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_CUST_UPDATE_SERVICES BRM opcode.

• Price override

  During this scenario, you can change the PriceOverride on a product line.

  ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_SET_PRODINFO BRM opcode.

• Discount override

  During this scenario, you can change the DiscountOverride on a product line.

  ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_SET_PRODINFO BRM opcode.

• TBO End Date

  During this scenario, you can change the EffectiveEndDate on a product line.

  ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_SET_PRODINFO BRM opcode in case of SUSCRIPTION products and calls PCM_OP_SUBSCRIPTION_SET_DISCOUNTINFO in case of discount products.

ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess

The ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess is a synchronous BPEL process that is called by ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl. This call depends on the action code present on the order line and also the type of product. It has one operation: processBillingDelete.

When the action code is Delete and the product type is a service bundle or an account-level subscription or account-level discount, then the ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess is called.

The following operations are done by this process:

• When the action code is Delete and the product type is Service Bundle, the ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_CUST_SET_STATUS BRM opcode.

• The ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess passes the StatusFlag=4 and Status=10103 in this case.

• When the action code is Delete and the product type is Discount, the ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_CANCEL_DISCOUNT BRM opcode.

• When the action code is Delete and the product type is Account-Level Subscription, the ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_CANCEL_PRODUCT BRM opcode.

• During these operations, the ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess also checks for the existence of any one-time penalty charge. If present, then the ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess converts the ProcessFulfillmentOrderBillingEBM into a BRM-specific message and calls the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL BRM opcode.

ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess

ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess is a BPEL process called by ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl for order lines containing promotion groups, promotion group memberships, and promotion group rewards order lines with the Community Member or Community Offer attributes enabled.

ProcessFulfillmentOrderBillingBRMCommsSharingGroupSubProcess calls the following opcodes:

• PCM_OP_SUBSCRIPTION_SHARING_GROUP_CREATE: called to create a new sharing group. The sharing group POID on the opcode response is added to the Oracle AIA XREF database.

• PCM_OP_SUBSCRIPTION_SHARING_GROUP_MODIFY: called to add or remove a member or reward to or from an existing sharing group.

• PCM_OP_SUBSCRIPTION_SHARING_GROUP_DELETE: called to delete an existing sharing group. The sharing group POID on the opcode response is deleted from the Oracle AIA XREF database.

• PCM_OP_SUBSCRIPTION_ORDERED_BALGRP: called after adding or deleting a member to or from a sharing group to create, update, or delete an ordered balance group for the member that sets the order in which BRM applies discounts, chargeshares, and extended rating attributes.

ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer

The ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer is a BPEL process that has an adapter service, which produces the order response messages to the AIA_UPDBO_IN_JMSQ.

This process has only one operation: Produce_ProcessFOBResponse to produce the message into the AIA_UPDBO_IN_JMSQ AIA queue. This operation is called after the order is interfaced into BRM.

Implementing the Provision Order and Update Fulfillment Order Flows

This section explains how the Order to Cash business process implements the Provision Order and Update Fulfillment Order flows.

About the Provision Order and Update Fulfillment Order Flows

The following sections provide an overview of Provision Order and Update Fulfillment Order flows.

About the Provision Order Flow

In this flow, OSM COM creates provisioning orders by passing a transformed sales order to OSM SOM.

OSM COM drops the ProcessProvisioningOrderEBM message, which includes most of the SalesOrderEBO attributes, into the AIA_CRTFO_OUT_JMSQ store-and-forward queue, where OSM SOM picks it up.

There is no response for this message other than error responses that come through the Oracle AIA common error schema. OSM SOM sends updates in the ProcessFulfillmentOrderUpdateEBM message. For interface errors and request failures, the responses are passed to an Oracle AIA Error Handling service, which passes order failure information from OSM SOM to customer order management for order fallout handling.

See About Order Fallout Management for more information about order fallout.

About the Update Fulfillment Order Flow

In this flow, OSM SOM sends milestone, status, and data updates to OSM COM.

You use OSM COM to manages order status and milestones. You can configure order status management across different fulfillment systems, including OSM SOM. You can also use milestones to track order fulfillment progress. OSM uses fulfillment system responses and status updates to trigger evaluation of rules that progress the order item status and reach new milestones. These statuses and milestones trigger aggregation rules that update the order-level status.

OSM SOM also sends data updates during order provisioning to populate order attributes used by Siebel CRM and other fulfillment systems.

The following business process options enable the Provision Order and Update Fulfillment Order flow:

• Order to Cash for Oracle Communications Order and Service Management (OSM)

The Provision Order and Update Fulfillment Business Order flows include the following integration flow:

• OSM Fulfillment to OSM Provisioning integration flow

About the OSM Fulfillment to OSM Provisioning Integration Flow

This integration flow participates in both the Provision Order flow and the Update Fulfillment Order flow.

For the Provision Order flow, this integration flow passes provision order requests from OSM in the central order management role (OSM COM) to OSM in the service order management role (OSM SOM).

For the Update Fulfillment Order flow, the Interfacing Orders to Create Subscriber Data Integration flow passes milestone, status, and data updates from OSM SOM to OSM COM.

This integration flow uses the following services:

• ProcessProvisioningOrderOSMCFSCommsJMSConsumer

• ProcessProvisioningOrderOSMPROVCommsJMSProducer

• ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer

• ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer

Figure 5-4 shows the sequence of integration services for the OSM Fulfillment to OSM Provisioning integration flow.

Figure 5-4 OSM Fulfillment to OSM Provisioning Sequence

Description of "Figure 5-4 OSM Fulfillment to OSM Provisioning Sequence"

The integration passes provisioning orders to OSM SOM and receives updates in OSM COM as follows:

1. For each new provisioning order, OSM COM creates a ProcessProvisioningOrderEBM message and drops it into the AIA_CRTFO_OUT_JMSQ queue.

2. The ProcessProvisioningOrderOSMCFSCommsJMSConsumer service picks up the ProcessProvisioningOrderEBM and sends it to the ProcessProvisioningOrderOSMPROVJMSProducer service.

3. ProcessProvisioningOrderOSMPROVJMSProducer drops the message into the AIA_FOPROV_IN_JMSQ queue, where OSM SOM picks it up and processes it.

4. While OSM SOM provisions the order, it sends updates by dropping the ProcessFulfillmentOrderUpdateEBM message into the AIA_FOPROV_OUT_JMSQ queue.

5. The ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer service picks up ProcessFulfillmentOrderUpdateEBM and sends it to the ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer service.

6. ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer service drops ProcessFufillmentOrderUpdateEBM into the AIA_FOCFS_IN_JMSQ queue where OSM COM picks it up to update the status of the order.

Defining Transaction Boundaries and Recovery Details

For this flow there are two transaction boundaries. Defining Transaction Boundaries and Recovery Details describes the transactions involved, the database operations, and what actions to take in case of an error.

See Using Error Type to Control Response to Order Fallout for more information about system and business errors.

The following services are involved:

• ProcessProvisioningOrderOSMCFSCommsJMSConsumer

• ProcessProvisioningOrderOSMPROVCommsJMSProducer

• ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer

• ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer

Table 5-7 Transaction Boundaries and Recovery Details

Transaction	DB Operations	In Case of Error	Recovery
ProcessProvisioningOrderOSMCFSCommsJMSConsumer routes the message to ProcessProvisioningOrderOSMPROVCommsJMSProducer, which produces message into AIA_FOPROV_IN_JMSQ. SAF puts message in OSM.	None	Rollback JMS message to originating queue AIA_CRTFO_OUT_JMSQ_ErrorQ.	Resubmit the message from AIA_CRTFO_OUT_JMSQ_ErrorQ.
During provisioning, update messages are dequeued by OSM and eventually moves to AIA_FOPROV_OUT_JMSQ. ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer routes the message to ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer, which produces the message to AIA_FOCFS_IN_JMSQ.	None	Rollback JMS message to the originating queue AIA_FOPROV_OUT_JMSQ_ErrorQ.	Resubmit the order from AIA_FOPROV_OUT_JMSQ_ErrorQ.

See the discussion of configuring Oracle AIA processes for error handling and trace logging in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about rollback procedures.

Industry Oracle AIA Components

The Provision Order and Update Fulfillment Order flows use the following communications industry-specific Oracle AIA components:

• ProvisioningOrderEBO

• ProcessProvisioningOrderEBM

• FulfillmentOrderEBO

• ProcessFulfillmentOrderUpdateEBM

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/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 the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

Integration Services

The following services are delivered with the Provision Order and Update Fulfillment Order flows:

• ProcessProvisioningOrderOSMCFSCommsJMSConsumer

• ProcessProvisioningOrderOSMPROVCommsJMSProducer

• ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer

• ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer

ProcessProvisioningOrderOSMCFSCommsJMSConsumer

For interacting with OSM Provisioning, OSM Fulfillment pushes ProcessProvisioningOrderEBM message into AIA_CRTFO_OUT_JMSQ using store-and-forward.

The ProcessProvisioningOrderOSMCFSCommsJMSConsumer is a Mediator process that has a JMS Adapter Service. This Mediator service continuously polls the AIA_CRTFO_OUT_JMSQ. The ProcessProvisioningOrderOSMCFSCommsJMSConsumer dequeues the ProcessProvisioningOrderEBM and routes it to the ProcessProvisioningOrderOSMPROVCommsJMSProducer.

This service has one operation: Consume_Message.

ProcessProvisioningOrderOSMPROVCommsJMSProducer

The ProcessProvisioningOrderOSMPROVCommsJMSProducer is a BPEL process that has a JMS Adapter Service. This BPEL process is responsible for pushing the ProcessProvisioningOrderEBM message into the AIA_FOPROV_IN_JMSQ using store-and-forward. OSM Provisioning then consumes this message and processes it further.

This service has one operation: Initiate.

ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer

For interacting with OSM COM, OSM SOM pushes ProcessFulfillmentOrderUpdateEBM message into AIA_FOPROV_OUT_JMSQ using store-and-forward.

The ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer is a Mediator process with a JMS Adapter Service. The ProcessFulfillmentOrderUpdateOSMPROVCommsJMSConsumer dequeues the ProcessFulfillmentOrderUpdateEBM from AIA_FOPROV_OUT_JMSQ and routes it to ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer.

This service has one operation: Consume_Message.

ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer

The ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer is a BPEL process that has a JMS Adapter Service. This BPEL process is responsible for pushing the ProcessFulfillmentOrderUpdateEBM Message into the AIA_FOCFS_IN_JMSQ. Using the SAF mechanism, it gets into the appropriate OSM queue.

This service has one operation: Initiate

Implementing the Update Sales Order Flow

This section explains how the Order to Cash business process implements the Update Sales Order flow.

About the Update Sales Order Flow

The following process options enable the Update Sales Order flow:

• Order to Cash for Siebel CRM

• Order to Cash for Oracle Communications Order and Service Management (OSM)

The Update Sales Order flow includes the following integration flow:

• Updating Statuses from OSM to Siebel CRM

About the Updating Statuses from OSM to Siebel CRM Integration Flow

This integration flow uses the following services:

• Integration services for OSM:

  • UpdateSalesOrderOSMCFSCommsJMSConsumer

• Integration services for Siebel CRM:

  • UpdateSalesOrderSiebelCommsJMSConsumer

  • UpdateSalesOrderSiebelCommsProvABCSImpl

Figure 5-5 shows the sequence of integration services for the Updating Status from OSM to Siebel CRM integration flow.

Figure 5-5 Updating Statuses from OSM to Siebel CRM

Description of "Figure 5-5 Updating Statuses from OSM to Siebel CRM"

The integration sends order status updates from OSM in the central order management role (OSM COM) to Siebel CRM as follows:

1. When OSM COM receives status update messages from OSM SOM or BRM, it creates an UpdateSalesOrderEBM message and adds it to the AIA_UPDSO_OUT_JMSQ queue.

2. The UpdateSalesOrderOSMCFSCommsJMSConsumer service subscribed to the queue picks up the EBM.

3. The consumer service adds the EBM to the AIA_UPDSO_OUT_SIEBEL_JMSQ queue.

4. The UpdateSalesOrderSiebelCommsJMSConsumer service subscribed to the queue picks up the EBM and sends it to the UpdateSalesOrderSiebelCommsProvABCSImpl service.

   Note:

   UpdateSalesOrderSiebelCommsJMSConsumer has an error resequencer. If any update to Siebel CRM causes a system or business error, further updates to the account are locked in the sequencer table until the error is fixed. If the error is a business error, the message must be removed from the sequencer table. If the error is a system error, the message must be resubmitted.

   See About Order Priority and Implementing the Synchronize Subscriber Account Flow for more information about using sequencing logic to make updates to Siebel CRM.

5. The provider service transforms the EBM into a Siebel CRM application business message (ABM) and invokes the Siebel CRM web service to update the order.

   During the transformation, UpdateSalesOrderSiebelCommsProvABCSImpl copies fulfillment status from the EBM to the DeliveryStatus attribute of the ABM. The Siebel CRM user interface shows this status in the Fulfillment Status field, which indicates the status of the order in OSM COM while the order is being fulfilled. The Fulfillment Status is a sub-status to the overall order status, which represents the overarching status throughout order capture and order fulfillment. The Siebel CRM user interface shows the overarching status in the Status field.

Defining Transaction Boundaries and Recovery Details

For this flow there are two transaction boundaries. Table 5-8 describes the transactions involved, the database operations, and what actions to take in case of an error.

If any update to Siebel CRM causes a system or business error, further updates to the account are locked in the sequencer table until the error is fixed. If the error is a business error, the message must be removed from the sequencer table. If the error is a system error, the message must be resubmitted.

See Using Error Type to Control Response to Order Fallout for more information on system and business errors.

The following services are involved:

• UpdateSalesOrderOSMCFSCommsJMSConsumer

• UpdateSalesOrderSiebelCommsJMSConsumer

• UpdateSalesOrderSiebelCommsProvABCSImpl

Table 5-8 Transaction Boundaries and Recovery Details for the Siebel CRM Flow

Transaction	DB Operations	In Case of Error	Recovery
UpdateSalesOrderOSMCFSCommsJMSConsumer picks up UpdateSalesOrderEBM from AIA_UPDSO_OUT_JMSQ and adds it to AIA_UPDSO_OUT_SIEBEL_JMSQ.	Message added to queue.	Roll back the message to AIA_UPDSO_OUT_JMSQ_ErrorQ.	Resubmit the order from AIA_UPDSO_OUT_JMSQ_ErrorQ.
UpdateSalesOrderSiebelCommsJMSConsumer picks up UpdateSalesOrderEBM from AIA_UPDSO_OUT_SIEBEL_JMSQ and adds it to the sequencer table defined by the UpdateSalesOrderSiebelCommsJMSConsumer_RS routing service.	Message added to the sequencer table.	Message available in Enterprise Manager Fusion Middleware Control in recoverable state.	Retry or abort the message from Enterprise Manager Fusion Middleware Control.
UpdateSalesOrderSiebelCommsJMSConsumer_RS sends the message to UpdateSalesOrderSiebelCommsProvABCSImpl, which invokes the Siebel web service to update the order.	AIA cross-reference entries.	Roll back the message to the sequencer table.	Resubmit the order from the sequencer table.

See the discussion of configuring Oracle AIA processes for error handling and trace logging in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about rollback procedures.

Siebel CRM Interfaces

The Update Sales Order flow uses the following Siebel CRM interfaces:

• SWIOrderUpsert

• SWIOrderUpsertSubProcess

These are inbound Siebel web services used to update the order information back to Siebel CRM.

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

Industry Oracle AIA Components

The Update Sales Order flow uses the following communications industry-specific Oracle AIA components:

• SalesOrderEBO

• UpdateSalesOrderEBM

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/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 the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

Integration Services

The following services are delivered with the Update Sales Order flow:

• UpdateSalesOrderOSMCFSCommsJMSConsumer

• UpdateSalesOrderSiebelCommsJMSConsumer

• UpdateSalesOrderSiebelCommsProvABCSImpl

UpdateSalesOrderOSMCFSCommsJMSConsumer

UpdateSalesOrderOSMCFSCommsJMSConsumer is a Mediator process with a JMS Adapter Service. It is subscribed to the AIA_UPDSO_OUT_JMSQ queue.

This process does the following:

1. Picks up the UpdateSalesOrderEBM message.

2. Adds UpdateSalesOrderEBM into the AIA_UPDSO_OUT_SIEBEL_JMSQ queue.

UpdateSalesOrderSiebelCommsJMSConsumer

UpdateSalesOrderSiebelCommsJMSConsumer service is a Java Messaging Service (JMS) consumer service. It is subscribed to the AIA_UPDSO_OUT_CPQ_JMSQ into which order update EBMs are added.

This consumer picks up UpdateSalesOrderEBM and sends it to the UpdateSalesOrderSiebelCommsProvABCSImpl service by using a Best Effort resequencer.

UpdateSalesOrderSiebelCommsProvABCSImpl

The UpdateSalesOrderSiebelCommsProvABCSImpl service accepts the UpdateSalesOrderEBM message and uses the information in the input message to update order in Siebel CRM.

The main functions of this service are:

• Updating the order line status: updates the order line status back to Siebel CRM.

• Enriching the order: enriches the information back to Siebel CRM from a central fulfillment system to facilitate subscriber care, service, and asset-based ordering. It is also used to update or enrich the order line items with fulfillment attributes back to Siebel CRM. Among these attributes are service IDs and allocated resources such as port number and IP address.

• Updating the order header: enriches the order header to Siebel CRM.

This process is an asynchronous, one-way service.

This service is enabled to use Session Pool Manager.

See Oracle Application Integration Architecture Pre-Built Integrations Utilities Guide for more information about Session Pool Manager.

Implementing the Synchronize Subscriber Account Flow

This section explains how the Order to Cash business process implements the Synchronize Subscriber Account flow.

About the Synchronize Customer Account Flow

The following business process options enable the Synchronize Subscriber Account flow:

• Order to Cash for Oracle Communications Order and Service Management (OSM)

• Order to Cash for Oracle Communications Billing and Revenue Management (BRM)

• Order to Cash for Siebel CRM

The Synchronize Subscriber Account flow supports the following integration flows:

• Create/Sync Subscriber Account

• Update Subscriber Account

About the Create/Sync Subscriber Account Integration Flow

The Create/Sync Subscriber Account integration flow synchronizes subscriber information from Siebel CRM to BRM.

This integration flow uses the following services:

• CommunicationsCustomerPartyEBSV2Resequencer

• QueryCustomerPartyListSiebelProvABCSImplV2

• ProcessAccountHierarchyListSiebelCommsProvABCSImpl

• SyncCustomerPartyListBRMCommsProvABCSImpl

• ProcessCollectionSharingBRMCommsProvABCSImpl

This flow is called during the Interfacing Orders to Create Subscriber Data integration flow of the Synchronize Fulfillment Order Billing Account business flow.

See About the Synchronize Fulfillment Order Billing Account Flow for information about the sequence of events for this business flow.

About the Update Subscriber Account Integration Flow

This flow synchronizes account updates from Siebel CRM to BRM.

The Update Subscriber Account integration flow uses the following services:

• SyncCustomerSiebelEventAggregator

• SyncAcctSiebelEventAggrConsumer

• ProcessAccountHierarchyListSiebelCommsProvABCSImpl

• SyncAccountSiebelReqABCSImpl

• CustomerPartyEBSV2

• SyncCustomerPartyListBRM_01CommsJMSConsumer

• SyncCustomerPartyListBRMCommsProvABCSImpl

Figure 5-6 illustrates the Update Subscriber Account integration flow.

Figure 5-6 Update Subscriber Account Sequence

Description of "Figure 5-6 Update Subscriber Account Sequence"

The integration updates subscriber accounts in BRM as follows:

1. A Siebel CRM user updates an attribute on a customer's account such as account name, address, contact information, or billing profile.

2. Siebel CRM sends the SiebelUpdateABM message containing the updated attribute to the SyncCustomerSiebelEventAggregator service. SiebelUpdateABM takes one of the following forms, depending on the updated attribute:

   • ListOfSWICustomerIO for name and hierarchy updates

   • ListOfSWIAddressIO for address updates

   • ListOfSWIContactIO for contact updates

   • ListOfSWIBillingProfileIO for billing profile updates

3. SyncCustomerSiebelEventAggregator sends the SiebelUpdateABM to one of the following database adapters, depending on the updated attribute:

   • SyncAccountSiebelAggregatorAdapter for name and hierarchy updates

   • SyncAddressSiebelAggregatorAdapter for address updates

   • SyncContactSiebelAggregatorAdapter for contact updates

   • SyncBPSiebelAggregatorAdapter for billing profile updates

4. The adapter extracts the account, contact, address, or billing profile ID from the ABM, stores it in the AIA_AGGREGATED_ENTITIES database table, and sends an acknowledgment to Siebel CRM.

   The IDs in the database table are stored in the same hierarchy as in Siebel CRM (for example, BillingProfileID is always the child of an account ID).

5. The SyncAcctSiebelEventAggrConsumer service picks up the account ID and all of its child IDs. This service sends updates for the same subscriber in sequence.

6. SyncAcctSiebelEventAggrConsumer sends the account ID and child IDs to the SyncAccountSiebelReqABCSImpl service.

7. SyncAccountSiebelReqABCSImpl sends the account and child IDs as an input application business message (ABM) for the Siebel CRM SWICustomerPartyQueryByExample web service operation.

8. SWICustomerPartyQueryByExample sends an output ABM, which includes the entire account data, back to SyncAccountSiebelReqABCSImpl.

9. SyncAccountSiebelReqABCSImpl transforms the output into the SyncCustomerPartyListEBM and sends it to the CustomerPartyEBSV2 service.

10. CustomerPartyEBSV2 sends SyncCustomerPartyListEBM to SyncCustomerPartyListBRMCommsJMSProducer, which publishes it to the CPARTY_SYNC_TOPIC JMS topic.

11. The consumer subscribed to this topic by default, SyncCustomerPartyListBRM_01CommsJMSConsumer, picks up SyncCustomerPartyListEBM, checks which service it should be sent to, stamps it with the target ID, and sends it to SyncCustomerPartyListBRMCommsProvABCSImpl.

    You can define more consumers for multiple instances of BRM or other billing systems and subscribe them to CPARTY_SYN_TOPIC.

12. SyncCustomerPartyListBRMCommsProvABCSImpl calls one of the following opcodes to update the data in BRM:

    • PCM_OP_CUST_UPDATE_CUSTOMER

    • PCM_OP_CUST_DELETE_PAYINFO

    • PCM_OP_CUST_SET_STATUS

    • PCM_OP_BILL_GROUP_MOVE_MEMBER

13. The opcode sends confirmation to SyncCustomerPartyListBRMCommsProvABCSImpl.

BRM Interfaces

Table 5-9 lists the BRM interfaces used by the Synchronize Subscriber Account flow.

Table 5-9 BRM Interfaces

Opcode	Purpose
PCM_OP_CUST_COMMIT_CUSTOMER	Creates a new account with one or more /billinfo and /payinfo objects.
PCM_OP_CUST_UPDATE_CUSTOMER	Updates account information (name, address, phone), contact information, and billing information.
PCM_OP_CUST_DELETE_PAYINFO	Delete a /payinfo from an account.
PCM_OP_CUSTCARE_MOVE_ACCT	Moves a child account to a new parent account.
PCM_OP_CUST_SET_STATUS	Modifies the account status.
PCM_OP_BILL_GROUP_MOVE_MEMBER	Modifies a hierarchical account group (moves an account between groups, creates a group if one doesn't exist, deletes a group if it is empty).
PCM_OP_COLLECTIONS_GROUP_CREATE	Creates a collections sharing group with the owner account as the owner and the billing account as a member.
PCM_OP_COLLECTIONS_GROUP_ADD_MEMBER	Adds the billing account as a member of the owner account's collections sharing group.
PCM_OP_COLLECTIONS_GROUP_DELETE_MEMBER	Removes the billing account as a member of the owner account's collections sharing group.
PCM_OP_COLLECTIONS_GROUP_GET_BILLINFO	Checks whether an account already owns or is a member of a collections sharing group.
PCM_OP_COLLECTIONS_GROUP_DELETE	Deletes the owner account's collections sharing group.

See Oracle Communications Billing and Revenue Management Developer's Reference for detailed descriptions of individual opcodes.

Siebel CRM Interfaces

Table 5-10 describes the Siebel CRM web service interface.

Table 5-10 Siebel CRM Web Service Interface

Web Service	Description	Used by
Query Account- (SWICustomerParty)	Retrieves account, bill profile, contact, and address data from Siebel CRM.	QueryCustomerPartyListSiebelProvABCSImplV2 as part of creating a new account or adding a new billing profile to an existing account. SyncAccountSiebelReqABCSImpl
Query account hierarchy - (SWI Account Hierarchy)	Retrieves the full linear account hierarchy from Siebel CRM.	ProcessAccountHierarchyListSiebelCommsProvABCSImpl

See Siebel CRM Web Services Reference for more information about this web service.

Table 5-11 describes the Siebel CRM workflow event interfaces.

Table 5-11 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 the discussion of workflows for employee asset-based ordering in Siebel Order Management Guide Addendum for Communications for more information.

Industry Oracle AIA Components

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

• CustomerPartyEBO

• QueryCustomerPartyListEBM

• QueryCustomerPartyListResponseEBM

• SyncCustomerPartyListEBM

• SyncCustomerPartyListResponseEBM

• ProcessBillingAccountListEBM

• ProcessBillingAccountListResponseEBM

• FulfillmentOrderEBO

• ProcessFulfillmentOrderBillingAccountListEBM

• ProcessFulfillmentOrderBillingAccountListResponseEBM

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/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 such as adding new data elements. These extensions are protected and will remain intact even after a patch or an upgrade, so long as the extensibility guidelines are followed.

See the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

Integration Services

The following services are delivered with the Synchronize Subscriber Account flow:

• CommsProcessBillingAccountListEBF

• CommunicationsCustomerPartyEBSV2Resequencer

• SyncCustomerPartyListBRMCommsProvABCSImpl

• SyncCustomerPartyListBRMCommsJMSProducer

• SyncCustomerPartyListBRM_01CommsJMSConsumer

• CustomerPartyEBSV2

• ProcessCollectionSharingBRMCommsProvABCSImpl

• ProcessAccountHierarchyListSiebelCommsProvABCSImpl

• QueryCustomerPartyListSiebelProvABCSImplV2

• SyncCustomerSiebelEventAggregator

• SyncAccountSiebelReqABCSImpl

• SyncContactSiebelAggregatorAdapter

• SyncAddressSiebelAggregatorAdapter

• SyncBPSiebelAggregatorAdapter

• SyncAcctSiebelAggrEventConsumer

• SyncAccountSiebelReqABCSImpl

Additional services are delivered with the Synchronize Subscriber Account flow as part of the Interfacing Orders to Create Customer Data integration flow, which is part of the Synchronize Fulfillment Order Billing Account flow. See Integration Services in Implementing the Synchronize Fulfillment Order Billing Account Flow for more information about these services.

CommsProcessBillingAccountListEBF

This service invokes Siebel CRM services to query account information and BRM services to create accounts.

This service does the following:

1. Receives ProcessBillingAccountListEBM, which contains a list of subscriber account IDs, billing profile IDs, and the target system ID, and transforms it into QueryCustomerPartyListEBM.

2. Sends QueryCustomerPartyListEBM to QueryCustomerPartyListSiebelProvABCSImplV2.

3. Receives QueryCustomerPartyListResponseEBM, which contains detailed account information, and transforms it into SyncCustomerPartyListEBM.

4. Sends SyncCustomerPartyListEBM to CommunicationsCustomerPartyEBSV2Resequencer.

5. Receives SyncCustomerPartyListResponseEBM from SyncCustomerPartyListBRMCommsProvABCSImpl.

6. If the owner account in ProcessBillingAccountListEBM is different than the billing account, this service does the following:

   1. Sends ProcessBillingAccountListEBM to ProcessCollectionsSharingBRMCommsProvABCSImpl.

   2. Receives ProcessBillingAccountListResponseEBM.

7. Combines the response messages into ProcessBillingAccountListResponseEBM and sends the message back to CommsProcessFulfillmentOrderBillingAccountListEBF.

CommunicationsCustomerPartyEBSV2Resequencer

This service groups account messages from CommsProcessBillingAccountListEBF by account ID. This process receives SyncCustomerPartyListEBM and sends it to SyncCustomerPartyListBRMCommsProvABCSImpl.

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

SyncCustomerPartyListBRMCommsProvABCSImpl

This service creates or updates subscriber accounts in BRM. It does following:

1. Receives the SyncCustomerPartyListEBM.

2. For child accounts, checks whether the parent account has been synchronized. The integration can only synchronize a child account after the parent account has been synchronized.

3. For each account in the EBM with the ADD action code, the service creates the account as follows:

   1. Transforms the SyncCustomerPartyListEBM to the BRM-specific account creation ABM.

   2. Calls PCM_OP_CUST_COMMIT_CUSTOMER to create the subscriber account.

   3. For child accounts where the billing account on the order is different from the owner account and the O2C.LegalGroup configuration property is set to TRUE, calls any of the following opcodes:

      • PCM_OP_COLLECTIONS_GROUP_GET_BILLINFO to check if the owner account already owns a collections sharing group.

      • PCM_OP_COLLECTIONS_GROUP_CREATE to create a collections sharing group if the owner account doesn't own one.

      • PCM_OP_COLLECTIONS_GROUP_ADD_MEMBER to add the billing account to the owner account's collections sharing group.

   4. Transforms the response from the opcode calls to SyncCustomerPartyListResponseEBM and populates the following cross-reference tables with the BRM IDs obtained:

      • CUSTOMERPARTY_ACCOUNTID

      • CUSTOMERPARTY_ADDRESSID

      • CUSTOMERPARTY_CONTACTID

      • CUSTOMERPARTY_BILLPROFILEID

      • CUSTOMERPARTY_PAYPROFILEID

4. For each account in the EBM with the UPDATE action code, the service updates the account as follows:

   1. For child accounts where the parent in the EBM is different from the parent obtained in the opcode response, moves the child account to the parent in the EBM by calling the PCM_OP_CUSTCARE_MOVE_ACCT.

   2. Transforms the SyncCustomerPartyListEBM into a BRM-specific account update ABM.

   3. Calls PCM_OP_CUST_UPDATE_CUSTOMER to update the account.

   4. For child accounts where the billing account on the order is different from the subscriber account and the O2C.LegalGroup configuration property is set to TRUE, calls any of the following opcodes:

      • PCM_OP_COLLECTIONS_GROUP_GET_BILLINFO to check if the owner account already owns a collections sharing group or the billing account is already a member of a collections sharing group.

      • PCM_OP_COLLECTIONS_GROUP_CREATE to create a collections sharing group if the owner account doesn't own one.

      • PCM_OP_COLLECTIONS_GROUP_ADD_MEMBER to add the billing account to the owner account's collections sharing group.

      • PCM_OP_COLLECTIONS_GROUP_DELETE_MEMBER to remove the billing account from a collections sharing group if the owner account on the EBM and the owner account in the PCM_OP_COLLECTIONS_GROUP_GET_BILLINFO response are different.

      • PCM_OP_COLLECTIONS_GROUP_DELETE to delete the collections sharing group if the billing account being moved was the only member.

   5. Checks whether the AIA configuration 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.

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

   7. Transforms the SyncCustomerPartyListEBM to SyncCustomerPartyListResponseEBM.

5. Sends SyncCustomerPartyListResponseEBM back to the calling service.

SyncCustomerPartyListBRMCommsJMSProducer

This producer service receives the SyncCustomerPartyListEBM message with account update information from CustomerPartyEBSV2. This service drops the message into the C_PARTY_SYNC_TOPIC queue, where SyncCustomerPartyListBRM_01CommsJMSConsumer picks it up.

SyncCustomerPartyListBRM_01CommsJMSConsumer

This is a mediator process subscribed to the CPARTY_SYNC_TOPIC queue. It does the following:

1. Picks up SyncCustomerPartyListEBM from CPARTY_SYNC_TOPIC.

2. Checks the cross-reference table to identify the BRM ID that corresponds to the common ID.

3. Stamps the EBM with the target BRM ID.

4. Sends the EBM to the SyncCustomerPartyListBRMCommsProvABCSImpl service.

This process is intended for a topology with multiple BRM instances. Deploy a version of this consumer for each BRM instance.

CustomerPartyEBSV2

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

CustomerPartyEBSV2 service uses the following operations:

• SyncCustomerPartyList

• QueryCustomerPartyList

Figure 5-7 illustrates the relationship of CustomerPartyEBSV2 with the other services in the integration flow.

Figure 5-7 CustomerPartyEBSV2

Description of "Figure 5-7 CustomerPartyEBSV2"

The process checks whether the incoming message has a target system identifier. If the target system identifier is not present, then the routing rule assumes multiple BRM systems and routes the incoming requests to SyncCustomerPartyListBRMCommsJMSProducer.

If you have only one BRM instance, you can change the routing rule to route incoming requests to the SyncCustomerPartyListBRMCommsProvABCSImpl directly. You must also apply a transformation before routing to stamp the target system identifier in the EBM. Apply the transformation in the following file:

esb:///ESB_Projects/Customer_CustomerPartyEBSV2/AddTargetID_BRM01.xsl

ProcessCollectionSharingBRMCommsProvABCSImpl

This service invokes opcodes in BRM to create collections sharing groups when the owner account on an order line is different from the billing account. This service does the following:

1. Receives ProcessBillingAccountListEBM.

2. Transforms ProcessBillingAccountListEBM into the correct input and invokes any of the following opcodes:

   • PCM_OP_COLLECTIONS_GROUP_GET_BILLINFO to check if the owner account already owns a collections sharing group or the billing account is already a member of a collections sharing group.

   • PCM_OP_COLLECTIONS_GROUP_CREATE to create a collections sharing group if the owner account doesn't own one.

   • PCM_OP_COLLECTIONS_GROUP_ADD_MEMBER to add the billing account to the owner account's collections sharing group.

   • PCM_OP_COLLECTIONS_GROUP_DELETE_MEMBER to remove the billing account from a collections sharing group if the owner account on the EBM and the owner account in the PCM_OP_COLLECTIONS_GROUP_GET_BILLINFO response are different.

   • PCM_OP_COLLECTIONS_GROUP_DELETE to delete the collections sharing group if the billing account being moved was the only member.

3. Receives the collections sharing group opcode response and transforms it into ProcessBillingAccountListResponseEBM.

4. Sends ProcessBillingAccountListResponseEBM to CommsProcessBillingAccountListEBF.

ProcessAccountHierarchyListSiebelCommsProvABCSImpl

This service calls the Siebel CRM web service to query the account hierarchy for a given account ID.

It does the following:

1. Receives ProcessBillingAccountListEBM from CommsProcessFulfillmentOrderBillingAccountListEBF.

2. Transforms ProcessBillingAccountListEBM into a Siebel CRM ABM.

3. Calls the Siebel CRM web services to query the complete linear account hierarchy for the account IDs listed in the ABM.

4. Receives the response from the Siebel CRM web service.

5. Transforms the response into ProcessBillingAccountListResponseEBM.

6. Sends ProcessBillingAccountListResponseEBM to CommsProcessFulfillmentOrderBillingAccountListEBF.

QueryCustomerPartyListSiebelProvABCSImplV2

This service does the following:

1. Receives QueryCustomerPartyListEBM from CommsProcessBillingAccountListEBF.

2. Transforms QueryCustomerPartyListEBM into a Siebel CRM ABM.

3. Invokes the Siebel CRM SWICustomerParty web service.

4. Receives the response from SWICustomerParty.

5. Transforms the response into QueryCustomerPartyListResponseEBM and sends it to CommsProcessBillingAccountListEBF.

SyncCustomerSiebelEventAggregator

This service receives Siebel CRM update account events and collates them into the AIA_AGGREGATED_ENTITIES database table.

Figure 5-8 illustrates the relationship of the SyncCustomerSiebelEventAggregator with the other services in the integration flow.

Figure 5-8 SyncCustomerSiebelEventAggregator

Description of "Figure 5-8 SyncCustomerSiebelEventAggregator"

This service provides the following operations:

• Aggregateaccountevent:

  1. Receives the Account Updated message from Siebel CRM.

  2. Extracts the account ID, contact IDs, and address IDs from the message.

  3. Invokes the SyncAccountSiebelAggregatorAdapter to store these IDs into the AIA_AGGREGATED_ENTITIES database table.

• Aggregatecontacttevent:

  1. Receives the Contact Update message from Siebel CRM.

  2. Extracts the account IDs, billing profile IDs, and contact IDs from the message.

  3. Invokes the SyncContactSiebelAggregatorAdapter to store these IDs in the AIA_AGGREGATED_ENTITIES database table.

• Aggregateaddresstevent:

  1. Receives the Address Update message from Siebel CRM.

  2. Extracts the account IDs, billing profile IDs, and address IDs from the message.

  3. Invokes the SyncAddressSiebelAggregatorAdapter to store these IDs into the AIA_AGGREGATED_ENTITIES database table.

• Aggregatebpevent:

  1. Receives the BillingProfile Updated message from Siebel CRM.

  2. Extracts the billing profile ID and the associated account ID from the message.

  3. Invokes the SyncBPSiebelAggregatorAdapter to store these IDs in the AIA_AGGREGATED_ENTITIES database table.

SyncAccountSiebelAggregatorAdapter

This service invokes the AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_ACCOUNT PL/SQL procedure, which aggregates the account events generated in Siebel CRM when an account is created or updated.

SyncContactSiebelAggregatorAdapter

This service invokes the AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_CONTACT PL/SQL procedure, which aggregates the account events generated in Siebel CRM when an account is created or updated.

SyncAddressSiebelAggregatorAdapter

This service invokes the AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_ADDRESS PL/SQL procedure, which aggregates the account events generated in Siebel CRM when an account is created or updated.

SyncBPSiebelAggregatorAdapter

This service invokes the AIA_AGGREGATOR_PUB.SIEBEL_AGGREGATE_BP PL/SQL procedure, which aggregates the account events generated in Siebel CRM when an account is created or updated.

SyncAcctSiebelAggrEventConsumer

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

Sequencing is enabled for this service. When this consumer calls the requester service for further processing and the requester service fails, any subsequent update for that subscriber is not processed until action is taken on the messages in the sequencer.

If the failure is due to a business error, you must remove the messages from the queue for the subsequent messages to process. If the failure is system related, you can retry messages in the resequencer, which moves the messages from the resequencer queue and enables 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 transforms the Siebel CRM aggregated message into the SyncCustomerPartyListEBM message and sends it to the CustomerPartyEBSV2 service.

Implementing the Create Trouble Ticket from Oracle AIA Flow

This section describes the Create Trouble Ticket from Oracle AIA flow and explains how the Order to Cash for Siebel CRM and Oracle Communications Billing and Revenue Management (BRM) business process options implements it using Siebel CRM interfaces, communications industry-specific Oracle Application Integration Architecture (Oracle AIA) components, integration services, and fallout-enabled services.

About the Create Trouble Ticket from Oracle AIA Flow Overview

After the Order Fallout Listener (AIACOMOrderFalloutNotificationConsumerProcess) picks up the fault message from the Oracle AIA Error JMS Topic based on an error notification from a downstream system or Oracle AIA service that has ended due to an error, an Oracle AIA Requestor Service provides an interface to invoke a Provider. This interface is used for the creation of trouble tickets in Siebel CRM.

This feature is composed of the following services:

• CreateTroubleTicketAIACommsReqImpl - Oracle AIA Requestor application business connector service (ABCS).

• CreateTroubleTicketSiebelCommsProvABCSImpl - Oracle AIA Provider ABCS invoked to create a trouble ticket in Siebel CRM.

On an error, the order fallout process (detection) within Oracle AIA passes the order fault message that is queued in the Oracle AIA Error JMS Topic to the CreateTroubleTicketAIACommsReqImpl ABCS. The service then routes the Oracle AIA message to the Siebel provider, which in turn calls the Siebel web service to create the trouble ticket in Siebel.

This flow supports the following integration flows:

• Creating a Trouble Ticket in Siebel CRM

Creating a Trouble Ticket in Siebel CRM Integration Flow

This integration flow uses the following interfaces:

• AIAOrderFalloutJMSBridgeService

• AIACOMOrderFalloutNotificationJMSConsumer

• CreateTroubleTicketAIACommsReqImpl

• CreateTroubleTicketSiebelCommsProvABCSImpl

Figure 5-9 illustrates the create trouble ticket integration flow.

Figure 5-9 Create Trouble Ticket Sequence Diagram

Description of "Figure 5-9 Create Trouble Ticket Sequence Diagram"

The integration creates a trouble ticket in Siebel CRM as follows:

1. The AIAOrderFalloutJMSBridgeService listener picks up an enriched fault message with a JMSCorrelationID value of AIA_ORDERFALLOUT_TTS from the AIA_ERROR_TOPIC topic and drops it into the AIA_ORDERFALLOUT_JMSQ queue.

2. The AIACOMOrderFalloutNotificationJMSConsumer picks up the message and sends it to the CreateTroubleTicketAIACommsReqImpl service.

3. CreateTroubleTicketAIACommsReqImpl transforms the fault message into the CreateTroubleTicketEBM message, and sends it to the CreateTroubleTicketSiebelCommsProvABCSImpl service.

4. CreateTroubleTicketSiebelCommsProvABCSImpl calls the Siebel CRM SWITroubleTicketIO web service with the SWITroubleTicketInsert operation.

5. The Siebel CRM web service operation responds with the trouble ticket ID in an application business message (ABM).

6. Depending on the response code in CreateTroubleTicketEBM, CreateTroubleTicketSiebelCommsProvABCSImpl may transform the ABM into CreateTroubleTicketResponseEBM and send it to CreateTroubleTicketAIACommsReqImpl.

Defining Transaction Boundaries and Recovery Details

For this flow there are two transaction boundaries. Table 5-12 describes the transactions involved, the database operations, and what actions to take in case of an error.

See Table 6-2 for more information on system and business errors.

The following services are involved:

• AIAOrderFalloutJMSBridgeService

• AIACOMOrderFalloutNotificationJMSConsumer

• CreateTroubleTicketAIACommsReqImpl

• CreateTroubleTicketSiebelCommsProvABCSImpl

Table 5-12 Transaction Boundaries and Recovery Details

Transaction	DB Operations	In Case of Error	Recovery
The AIAOrderFalloutJMSBridgeService picks up the messages with the JMSCorrelationID and publishes to AIA_ORDERFALLOUT_JMSQ.	Message enqueued in AIA_ORDERFALLOUT_JMSQ.	Rollback JMS message to AIA_ERROR_TOPIC.	Resubmit from AIA_ERROR_TOPIC.
AIACOMOrderFalloutNotificationJMSConsumer picks up messages with the JMS Correlation ID AIA_ORDERFALLOUT_TTS and invokes CreateTroubleTicketAIACommsReqImpl, which parses fault message and routes to CreateTroubleTicketSiebelCommsProvABCSImpl.	AIA cross-reference entries.	Rollback the message to AIA_ORDERFALLOUT_JMSQ.	Resubmit from AIA_ORDERFALLOUT_JMSQ.

See the discussion of configuring Oracle AIA processes for error handling and trace logging in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about rollback procedures.

Exception Handling

These are the exception handling notes for creating trouble tickets in Siebel CRM:

• If validation of the message fails because of missing mandatory data, incorrect formatting, or other problems, then an error message identifying the validation issue is returned to the invoking application.

• In case of any errors in the flow, a standard Oracle AIA Error Handling Framework notification is posted to the Oracle AIA Error Handling Framework.

Siebel CRM Interfaces

The Create Trouble Ticket from Oracle AIA flow uses the following Siebel CRM interface:

• SWI Trouble Ticket Service: This service is invoked by the Siebel ABCS to create or update a trouble ticket in Siebel CRM. If the request is for creating a new trouble ticket, a new trouble ticket is created and the trouble ticket number is returned. If the request is to update a particular trouble ticket, typically to close the trouble ticket, the trouble ticket is updated.

See "Web Services Reference" in Siebel Order Management Guide Addendum for Communications for more information.

Industry Oracle AIA Components

The Create Trouble Ticket from Oracle AIA flow uses the following communications industry-specific Oracle AIA components:

• TroubleTicketEBO

• CreateTroubleTicketEBM

• CreateTroubleTicketResponseEBM

• CommunicationsTroubleTicketEBSV1.wsdl

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/TroubleTicket/V1

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Industry/Communications/EBO/TroubleTicket/V1

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 the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

Integration Services

The following services are delivered with the Create Trouble Ticket from Oracle AIA flow:

• CreateTroubleTicketSiebelCommsProvABCSImpl

• AIAOrderFalloutJMSBridgeService

• AIACOMOrderFalloutNotificationJMSConsumer

• CreateTroubleTicketAIACommsReqImpl

• AIAOrderFalloutErrorHandlerExtension - Java Class

Some of these services have been enabled to use Session Pool Manager.

See Oracle Application Integration Architecture Pre-Built Integrations Utilities Guide for more information about Session Pool Manager.

CreateTroubleTicketSiebelCommsProvABCSImpl

The CreateTroubleTicketSiebelCommsProvABCSImpl service is implemented as an asynchronous business process execution language (BPEL) process. This service takes CreateTroubleTicketEBM as the input. It invokes the Siebel web service to create the trouble ticket and after the trouble ticket is created in Siebel CRM, the trouble ticket ID is passed back to this service.

If the TroubleTicket.GenerateTroubleTicketResponse configuration property is set to True or if the response code attribute is specified on the EBM, this process creates a trouble ticket response message and a cross-reference for the trouble ticket ID with the Siebel ID. Otherwise, this process ignores any response.

This service is enabled to use Session Pool Manager.

See Oracle Application Integration Architecture Pre-Built Integrations 11.1: Utilities Guide for more information about Session Pool Manager.

AIAOrderFalloutJMSBridgeService

The AIAOrderFalloutJMSBridgeService service is a mediator service that picks up the fault message from the AIA Error Topic and publishes the message to the AIA_ORDERFALLOUT_JMSQ.

This service persists the enhanced fault message into a fallout queue so that it can be retried in case of errors in the downstream process. In this flow, the messages in this queue are used by Oracle AIA to create a trouble ticket in Siebel CRM.

AIACOMOrderFalloutNotificationJMSConsumer

The AIAOrderFalloutNotificationJMSConsumer service is implemented as a Mediator service and picks up the fault message from the AIA Error Topic. The fault message is passed to the CreateTroubleTicketAIACommsReqImpl process. This service acts as the consumer, listening to the messages produced in the AIA Error Topic.

CreateTroubleTicketAIACommsReqImpl

The CreateTroubleTicketAIACommsReqImpl service is implemented as a one-way asynchronous BPEL process. This service picks up the fault message from the AIACOMOrderFalloutNotificationJMSConsumer. The fault message is parsed and then the CreateTroubleTicketEBM is constructed.

AIAOrderFalloutErrorHandlerExtension - Java Class

This module is the Java action that is specified for enhancing the fault message. In case of a Java action in the BPEL/ESB fault policy, the control is handed to this application module to enrich the fault message with business-specific content. The enriched fault message is returned to the AIA Error Handling Framework Common Error Handler.

• oracle.apps.aia.industry.comms.eh.AIAOrderFalloutErrorHandlerExtension.java implements oracle.apps.aia.core.eh. IAIAErrorHandlerExtension interface.

• This class implements the IAIAErrorHandlerExtension interface, which has two methods exposed: one for treating a BPEL fault and the other for a Mediator fault.

This class constructs the ApplicationFaultData element of the fault message with the order-related details.

Fallout-Enabled Services

The following Create Trouble Ticket from Oracle AIA flow services are fallout-enabled:

• ProcessFulfillmentOrderBillingBRMCommsAddSubProcess

• ProcessFulfillmentOrderBillingBRMCommsDeleteSubProcess

• ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess

• ProcessFulfillmentOrderBillingBRMCommsProvABCSImpl

• ProcessFulfillmentOrderBillingBRMCommsSuspendResumeSubProcess

• ProcessFulfillmentOrderBillingBRMCommsUpdateSubProcess

• CommsProcessFulfillmentOrderBillingAccountListEBF

• CommsProcessBillingAccountListEBF

• QueryCustomerPartyListSiebelProvABCSImplV2

• SyncCustomerPartyListBRMCommsProvABCSImpl

About Order Fallout Management for System Errors

System errors occur when infrastructure outages cause the participating application, network, or Fusion Middleware engine to be unavailable. Because order fallout due to system errors occurs when there is nothing inherently wrong with the original order message, you can resubmit the same message for processing.

Unlike business errors, system errors do not result in trouble tickets. They are managed using the standard Oracle AIA error handling framework and service fault policies, which automatically resubmit orders and roll back transactions to the error queue.

Some Oracle AIA flows communicate with integrated applications in a synchronous pattern and include consumer services that can be retired when system errors occur. Retiring the consumer service prevents it from picking up subsequent messages and sending them to an ABCS that will attempt to connect to an unavailable application. After the system error is resolved, you reactivate the consumer service and it resumes picking up messages from the queue. See Reactivating Retired Consumer Services for information about how to reactivate consumer services.

If you do not want Oracle AIA to handle system errors in this way, you can disable the Java action which retires the consumers. See Disabling Consumer Service Retirement for more information.

The following consumer services are enabled to handle system errors by default:

• UpdateSalesOrderSiebelCommsJMSConsumer

• SyncItemCompositionListSiebelCommsJMSConsumer

• ProductOptimizedSyncPriceListListSiebelCommsJMSConsumer

• ProcessFulfillmentOrderBillingAccountListSiebelCommsJMSConsumer

Figure 5-10 shows an example of how errors are handled in a part of the flow for updating order status in Siebel CRM. The figure uses UpdateSalesOrderSiebelCommsJMSConsumer as an example, but the same pattern applies to the other consumers enabled to handle system errors.

Figure 5-10 System Error Handling in Order Update Flow

Description of "Figure 5-10 System Error Handling in Order Update Flow"

The figure illustrates the following process:

1. The UpdateSalesOrderSiebelCommsJMSConsumer consumer picks up a message from the AIA_UPDSO_OUT_SIEBEL_JMSQ queue and sends it to the UpdateSalesOrderSiebelCommsProvABCSImpl provider service.

2. The provider service attempts to send the message to Siebel CRM, but Siebel CRM is unavailable.

3. The fault policy for the provider service tries to resend the message a configured number of times.

   Because Siebel CRM remains unavailable, the retries fail.

4. The service's fault policy throws the error to the Oracle AIA common error handler, which performs the basic activities of logging the fault, sending a notification, and dropping it into the Oracle AIA error topic.

5. Because it is a system fault, the service's fault policy initiates a Java action to retire the consumer.

   UpdateSalesOrderSiebelCommsJMSConsumer is retired and no longer picks up messages from AIA_UPDSO_OUT_SIEBEL_JMSQ.

6. The Java action also throws the fault to the error queue, which persists messages that have been rolled back.

Reactivating Retired Consumer Services

After you have resolved the system error and the edge application is available, you must reactivate the retired consumer services.

To reactivate retired consumer services:

1. In a web browser, navigate to the Oracle Enterprise Manager Fusion Middleware Control console for your Oracle AIA domain at the following location:

   http://host.domain:port/em

   where host, domain, and port are the host, domain name, and port number for your Oracle AIA deployment.

2. In the Target Navigation tree, expand the SOA folder, then expand the soa-infra component, and then click the SOA partition component for your Oracle AIA deployment.

   The SOA Partition home page appears.

3. Click the Deployed Composites tab.

4. Locate any of the following consumer services that have Retired in the Mode column:

   • UpdateSalesOrderSiebelCommsJMSConsumer

   • SyncItemCompositionListSiebelCommsJMSConsumer

   • ProductOptimizedSyncPriceListListSiebelCommsJMSConsumer

   • ProcessFulfillmentOrderBillingAccountListSiebelCommsJMSConsumer

5. For each consumer service from the list above with Retired in the Mode column, do the following:

   1. Click the consumer service's name.

      The SOA Composite home page appears.

   2. Click Activate.

      The consumer service is reactivated and resumes picking up messages from the queue to which it is subscribed.

Disabling Consumer Service Retirement

To disable the error handling mechanism that retires consumers:

1. Open the fault policy file for the consumer for which you want to disable the Java action that retires the service.

2. Search for the following line:

   <retryFailureAction ref="aia-custom-java"/>
   

3. Change aia-custom-java to aia-no-action. For example:

   <retryFailureAction ref="aia-no-action"/>
   

4. Save and close the file.

5. Upload the file to the Oracle Metadata Services repository. See "Update Files to MDS" in the Oracle Application Integration Architecture Cloud Native Deployment Guide for more information about uploading changed files to the Oracle Metadata Services repository.

How Oracle AIA Error Handling Framework Captures Faults

The Oracle AIA Error Handling Framework is used to capture faults across order processing.

Figure 5-11 illustrates the interactions taking place when an order failure is detected by an edge application, such as a billing or inventory system.

Figure 5-11 Capturing the Fault Sequence Diagram

Description of "Figure 5-11 Capturing the Fault Sequence Diagram"

The integration captures faults as follows:

1. An edge application, such as BRM, encounters a processing error and sends the error to the Oracle AIA ABCS.

2. The ABCS creates an enhanced fault message from the error message and sends it to the Oracle AIA error handling framework.

3. The error handling framework sends the enhanced fault message to the error JMS topic.

4. If needed, the Oracle AIA error handling listener subscribed to the topic picks up the fault message.

5. The order fallout management listener subscribed to the topic picks up the failed order notification and sends it to the fulfillment system responsible for order fallout management.

6. The fulfillment system sends a status update to the system responsible for status management and proceeds with fallout management tasks such as assigning time of first failure, calculating and assigning recovery priority, mapping the application error code to a central error code, and generating a central error message based on the central error code.

The Oracle AIA error handling framework supports order fallout management by:

• Allowing custom enrichments to the fault message.

• Publishing the enriched fault message to the Oracle AIA Error topic.

• Using the order fallout listener to pick up only the messages that are relevant to the order failure.

Figure 5-12 illustrates how the Oracle AIA Error Handling Framework submits an order failure notification to the Oracle AIA Error Topic.

Figure 5-12 Creation and Submission of a Fault Message to the Oracle AIA Error Topic

Description of "Figure 5-12 Creation and Submission of a Fault Message to the Oracle AIA Error Topic"

The custom listener selectively picks up the messages from the Oracle AIA Error Topic and initiates the appropriate Create Trouble Ticket flow, as shown in Figure 5-13.

Figure 5-13 Initiating Appropriate Create Trouble Ticket Flow

Description of "Figure 5-13 Initiating Appropriate Create Trouble Ticket Flow"

The integration initiates the appropriate trouble ticket integration flow as follows:

1. The Oracle AIA common error handler reads the AIA_ERROR_NOTIFICATIONS table to identify the error type and adds the error type to the JMSHeader JMSCorrelationID attribute.

2. The Oracle AIA common error handler posts all of the enriched fault messages to the AIA_ERROR_TOPIC topic.

3. One of the following services picks up the fault message from AIA_ERROR_TOPIC:

   • The AIAOrderFalloutJMSBridgeService listener picks up messages with a JMSCorrelationID that includes AIA_ORDERFALLOUT and publishes the fault messages to the AIA_ORDERFALLOUT_JMSQ queue for further filtering before creating trouble tickets. This queue ensures that the fault messages are not lost if there are more errors.

   • A business error handler picks up messages with other JMSCorrelationID values. These messages are managed outside of the process integration for Order Fallout Management.

4. One of the following services picks up the fault messages from AIA_ORDERFALLOUT_JMSQ:

   • The AIACOMOrderFalloutNotificationJMSConsumer picks up the fault messages with a JMSCorrelationID value that includes AIA_ORDERFALLOUT_TTS and initiates the Create Trouble Ticket from Oracle AIA flow.

   • The CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer picks up the fault messages with JMSCorrelationID value that includes AIA_ORDERFALLOUT_CFS and initiates the Create and Manage Trouble Ticket from OSM flow.

See Using Error Type to Control Response to Order Fallout for information about how to set up the seed data so that the trouble ticket is created from either Oracle AIA or OSM.

Implementing the Create and Manage Trouble Ticket from OSM Flow

This section explains how the Order to Cash business process implements the Create and Manage Trouble Ticket from OSM flow.

About the Create and Manage Trouble Tickets from OSM Flow

The following business process options enable the Create and Manage Trouble Ticket from OSM flow:

• Order to Cash for Oracle Communications Order and Service Management (OSM)

• Order to Cash for Siebel CRM

The Create and Manage Trouble Ticket from OSM flow includes the following flows:

• Order Failure Notification to OSM integration flow

• Creating a Trouble Ticket in Siebel CRM from OSM integration flow

• Updating a Trouble Ticket in Siebel CRM from OSM integration flow

About the Order Failure Notification to OSM Integration Flow

The Oracle AIA order fallout listener, AIAOrderFalloutJMSBridgeService, listens to all messages published to the Oracle AIA Error JMS Topic, AIA_ERROR_TOPIC. Errors or faults with a correlation ID of AIA_ORDERFALLOUT_CFS are enriched and published to OSM.

This integration flow includes the following services:

• AIAOrderFalloutJMSBridgeService

• CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer

• CreateOrderFalloutNotificationOSMCFSCommsProvImpl

• CreateOrderFalloutNotificationOSMCFSCommsJMSProducer

Figure 5-14 shows the sequence of integration services through which the fallout notification message passes for the Order Failure Notification to OSM integration flow.

Figure 5-14 Order Failure Notification to OSM Sequence

Description of "Figure 5-14 Order Failure Notification to OSM Sequence"

When this process initiates, the following events occur:

1. The AIAOrderFalloutJMSBridgeService listener picks up an enriched fault message with a JMSCorrelationID value of AIA_ORDERFALLOUT_CFS from the AIA_ERROR_TOPIC topic and adds it to the AIA_ORDERFALLOUT_JMSQ queue.

2. The CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer service picks up the message and sends it to the CreateOrderFalloutNotificationOSMCFSCommsProvImpl service.

3. CreateOrderFalloutNotificationOSMCFSCommsProvImpl transforms the message into the OrderFalloutNotificationEBM message and sends it to the CreateOrderFalloutNotificationOSMCFSCommsJMSProducer service.

4. CreateOrderFalloutNotificationOSMCFSCommsJMSProducer adds the message to the AIA_FALLOUT_JMSQ queue, where OSM in the central order management role (OSM COM) picks it up.

5. OSM COM marks the order as failed and initiates the request to create a trouble ticket for Siebel CRM.

About the Creating a Trouble Ticket in Siebel CRM from OSM Integration Flow

This integration flow includes the following services:

• CreateTroubleTicketOSMCFSCommsJMSConsumer

• CreateTroubleTicketSiebelCommsProvABCSImpl

• CreateTroubleTicketOSMCFSCommsJMSProducer

Figure 5-15 shows the sequence of integration services through which the fallout notification message passes for the Creating a Trouble Ticket in Siebel CRM from OSM integration flow.

Figure 5-15 Creating a Trouble Ticket in Siebel CRM from OSM

Description of "Figure 5-15 Creating a Trouble Ticket in Siebel CRM from OSM"

The integration creates trouble tickets in Siebel CRM from OSM as follows:

1. OSM COM adds the CreateTroubleTicketEBM message to the AIA_CRTTTREQ_JMSQ queue.

2. The CreateTroubleTicketOSMCFSCommsJMSConsumer service picks up the message and sends it to the CreateTroubleTicketSiebelCommsProvABCSImpl service.

3. CreateTroubleTicketSiebelCommsProvABCSImpl transforms CreateTroubleTicketEBM into an application business message (ABM) and sends it to the SWITroubleTicket Siebel CRM web service with the SWITroubleTicketInsert operation.

4. SWITroubleTicket sends a response ABM that includes the trouble ticket ID to CreateTroubleTicketSiebelCommsProvABCSImpl.

5. CreateTroubleTicketSiebelCommsProvABCSImpl transforms the ABM into the CreateTroubleTicketResponseEBM message and sends it to the CreateTroubleTicketRespOSMCFSCommsJMSProducer service.

6. CreateTroubleTicketRespOSMCFSCommsJMSProducer adds CreateTroubleTicketResponseEBM to the AIA_CRTTTRESP_JMSQ queue.

7. OSM COM picks up the message and stores the trouble ticket ID for reference.

Defining Transaction Boundaries and Recovery Details

Table 5-13 describes the transactions, the database operations, and what actions to take in case of an error for these flows.

The following services are involved:

• AIAOrderFalloutJMSBridgeService

• CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer

• CreateOrderFalloutNotificationOSMCFSCommsProvImpl

• CreateOrderFalloutNotificationOSMCFSCommsJMSProducer

• CreateTroubleTicketOSMCFSCommsJMSConsumer

• CreateTroubleTicketSiebelCommsProvABCSImpl

• CreateTroubleTicketRespOSMCFSCommsJMSProducer

Table 5-13 Transaction Boundaries and Recovery Details

Transaction	DB Operations	In Case of Error	Recovery
The AIAOrderFalloutJMSBridgeService picks up the messages with the JMSCorrelationID and publishes to AIA_ORDERFALLOUT_JMSQ.	Message added to AIA_ORDERFALLOUT_JMSQ.	Roll back JMS message to AIA_ERROR_TOPIC.	Resubmit from AIA_ERROR_TOPIC.
CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer picks up messages with the JMS Correlation ID AIA_ORDERFALLOUT_CFS and sends it to CreateOrderFalloutNotificationOSMCFSCommsProvImpl, which parses fault message and sends it to CreateOrderFalloutNotificationOSMCFSCommsJMSProducer.	Message is submitted to OSM through AIA_FALLOUT_JMSQ.	Roll back the message to AIA_ORDERFALLOUT_JMSQ.	Resubmit from AIA_ORDERFALLOUT_JMSQ.
CreateTroubleTicketOSMCFSCommsJMSConsumer picks up message and sends the EBM to CreateTroubleTicketSiebelCommsProvABCSImpl. The ABCS invokes a Siebel web service., which sends a response message with the trouble ticket ID to CreateTroubleTicketSiebelCommsProvABCSImpl. The ABCS sends the response to CreateTroubleTicketRespOSMCFSCommsJMSProducer.	AIA cross-references created. Message added to AIA_CRTTTRESP_JMSQ.	Roll back the message to AIA_CRTTTREQ_JMSQ.	Resubmit from AIA_CRTTTREQ_JMSQ.

See the discussion of configuring Oracle AIA processes for error handling and trace logging in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about rollback procedures.

Updating a Trouble Ticket in Siebel CRM from OSM Integration Flow

This integration flow uses the following interfaces:

• UpdateTroubleTicketOSMCFSCommsJMSConsumer

• UpdateTroubleTicketSiebelCommsProvABCSImpl

Figure 5-16 shows the sequence of integration services through which the trouble ticket update message passes for the Updating a Trouble Ticket in Siebel CRM from OSM integration flow.

Figure 5-16 Updating a Trouble Ticket in Siebel CRM from OSM

Description of "Figure 5-16 Updating a Trouble Ticket in Siebel CRM from OSM"

The integration updates trouble tickets in Siebel CRM from OSM as follows:

1. OSM COM adds the UpdateTroubleTicketEBM message to the AIA_UPDTTREQ_JMSQ queue.

2. The UpdateTroubleTicketOSMCFSCommsJMSConsumer services picks up the message and sends it to the UpdateTroubleTicketSiebelCommsProvABCSImpl service.

3. UpdateTroubleTicketSiebelCommsProvABCSImpl service transforms UpdateTroubleTicketEBM into an ABM and sends it to SWITroubleTicket with the SWITroubleTicketInsertorUpdate operation.

4. SWITroubleTicket sends a response ABM to UpdateTroubleTicketSiebelCommsProvABCSImpl.

Defining Transaction Boundaries and Recovery Details

For this flow there is one transaction boundary. Table 5-14 describes the transaction involved, the database operations, and what actions to take in case of an error.

See Table 6-2 for more information about system and business errors.

The following services are involved:

• UpdateTroubleTicketOSMCFSCommsJMSConsumer

• UpdateTroubleTicketSiebelCommsProvABCSIm

Table 5-14 Transaction Boundaries and Recovery Details

Transaction	DB Operations	In Case of Error	Recovery
UpdateTroubleTicketOSMCFSCommsJMSConsumer picks up the message from the queue and invokes UpdateTroubleTicketSiebelCommsProvABCSImpl, which invokes the Siebel web service to update the trouble ticket.	AIA cross-references updated. Trouble Ticket updated in Siebel.	Message goes back to the originating queue AIA_UPDTTREQ_JMSQ.	Resubmit from AIA_UPDTTREQ_JMSQ.

See "Configuring Oracle AIA Processes for Error Handling and Trace Logging", Configuring Fault Policies to Not Issue Rollback Messages in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information about rollback procedures.

Siebel CRM Interfaces

The Create and Manage Trouble Ticket from OSM business flow uses the following Siebel CRM interface:

• SWI Trouble Ticket Service

This inbound web service is invoked by the Siebel ABCS to create or update a trouble ticket in Siebel CRM. If the request is for creating a new trouble ticket, then a new trouble ticket is created and the trouble ticket number is returned. If the request is to update a specific trouble ticket, typically to close the trouble ticket, then the trouble ticket is updated.

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

Industry Oracle AIA Components

The Create and Manage Trouble Ticket from OSM business flow uses the following communications industry-specific Oracle AIA components:

• TroubleTicketEBO

• CreateTroubleTicketEBM

• CreateTroubleTicketResponseEBM

• UpdateTroubleTicketEBM

The following directories contain the industry component files:

• Enterprise business object (EBO) and enterprise business message (EBM) XML schema files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/TroubleTicket/V1

• Enterprise business service (EBS) WSDL files:

  COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Industry/Communications/EBO/TroubleTicket/V1

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 the discussion of Oracle AIA assets extensibility patterns in Oracle Fusion Middleware Developer's Guide for Oracle SOA Core Extension for more information about extending EBOs.

Integration Services

The following services are delivered with the Create and Manage Trouble Ticket from OSM flow:

• AIAOrderFalloutJMSBridgeService

• CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer

• CreateOrderFalloutNotificationOSMCFSCommsProvImpl

• CreateOrderFalloutNotificationOSMCFSCommsJMSProducer

• CreateTroubleTicketOSMCFSCommsJMSConsumer

• CreateTroubleTicketSiebelCommsProvABCSImpl

• CreateTroubleTicketRespOSMCFSCommsJMSProducer

• UpdateTroubleTicketOSMCFSCommsJMSConsumer

• UpdateTroubleTicketSiebelCommsProvABCSImpl

• CreateFaultNotificationLFCommsJMSConsumer

AIAOrderFalloutJMSBridgeService

The AIAOrderFalloutJMSBridgeService service is a mediator service that does the following:

1. Picks up the fault message from the AIA Error Topic.

2. Adds the fault message to the AIA_ORDERFALLOUT_JMSQ.

This service persists the enhanced fault message into a fallout queue so that it can be retried in case of errors in the downstream process. In this flow, the messages in this queue are used to send an order failure notification to OSM.

CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer

The CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer service is a Mediator service that does the following:

1. Picks up the fault message from the AIA_ORDERFALLOUT_JMSQ.

2. Sends the fault message to the CreateOrderFalloutNotificationOSMCFSCommsProvImpl process based on the JMS Correlation ID.

This service acts as a consumer, listening to the messages produced in AIA_ORDERFALLOUT_JMSQ.

CreateOrderFalloutNotificationOSMCFSCommsProvImpl

The CreateOrderFalloutNotificationOSMCFSCommsProvImpl service is a business process execution language (BPEL) process that does the following:

1. Picks up the fault message from CreateOrderFalloutNotificationOSMCFSCommsJMSConsumer.

2. Transforms the fault message into the OrderFalloutNotificationEBM message.

3. Sends OrderFalloutNotificationEBM to the CreateOrderFalloutNotificationOSMCFSCommsJMSProducer service.

CreateOrderFalloutNotificationOSMCFSCommsJMSProducer

The CreateOrderFalloutNotificationOSMCFSCommsJMSProducer is a BPEL process that does the following:

1. Receives OrderFalloutNotificationEBM from CreateOrderFalloutNotificationOSMCFSCommsProvImpl.

2. Adds the EBM to the AIA_FALLOUT_JMSQ queue from which OSM picks up the message to trigger an OSM fallout event.

CreateTroubleTicketRespOSMCFSCommsJMSProducer

The CreateTroubleTicketRespOSMCFSCommsJMSProducer is a BPEL process that does the following:

1. Receives CreateTroubleTicketResponseEBM from CreateTroubleTicketSiebelCommsProvABCSImpl.

2. Adds CreateTroubleTicketResponseEBM to the AIA_CRTTTRESP_JMSQ SAF queue from which OSM picks up the message and updates the order task with the created trouble ticket ID.

CreateTroubleTicketOSMCFSCommsJMSConsumer

The CreateTroubleTicketOSMCFSCommsJMSConsumer is a Mediator service that does the following:

1. Picks up the CreateTroubleTicketEBM message from the AIA_CRTTTREQ_JMSQ queue.

2. Checks the value of the target ID on the EBM and does one of the following:

   • If the target ID is CPQ_01, sends the EBM to CreateTroubleTicketCQCommsJMSProducer.

   • If the target ID is SEBL_01, sends the EBM to CreateTroubleTicketSiebelCommsProvABCSImpl.

This service acts as a consumer, listening to the messages produced in the AIA_CRTTTREQ_JMSQ SAF queue.

CreateTroubleTicketSiebelCommsProvABCSImpl

The CreateTroubleTicketSiebelCommsProvABCSImpl service is an asynchronous BPEL process that does the following:

1. Receives CreateTroubleTicketEBM from CreateTroubleTicketOSMCFSCommsJMSConsumer.

2. Transforms CreateTroubleTicketEBM into the Siebel CRM web service input.

3. Invokes the Siebel web service to create the trouble ticket.

4. Receives a response from the web service with the trouble ticket ID.

5. If the TroubleTicket.GenerateTroubleTicketResponse configuration property is set to True or if the response code attribute is specified on the EBM, transforms the response ABM into the CreateTroubleTicketResponseEBM and sends it to CreateTroubleTicketRespOSMCFSCommsJMSProducer.

This service is enabled to use Session Pool Manager.

See Oracle Application Integration Architecture Pre-Built Integrations 11.1: Utilities Guide for more information about Session Pool Manager.

UpdateTroubleTicketOSMCFSCommsJMSConsumer

The UpdateTroubleTicketOSMCFSCommsJMSConsumer is a Mediator service that does the following:

1. Picks up the UpdateTroubleTicketEBM message from the AIA_UPDTTREQ_JMSQ queue.

2. Sends UpdateTroubleTicketEBM to UpdateTroubleTicketSiebelCommsProvABCSImpl.

This service acts as a consumer, listening to the messages produced in the AIA_UPDTTREQ_JMSQ queue.

UpdateTroubleTicketSiebelCommsProvABCSImpl

The UpdateTroubleTicketSiebelCommsProvABCSImpl is a BPEL process that does the following:

1. Receives UpdateTroubleTicketEBM from UpdateTroubleTicketOSMCFSCommsJMSConsumer.

2. Transforms the EBM into the TroubleTicketInsertorUpdate_Input ABM.

3. Invokes the Siebel CRM web service to update the trouble ticket.

CreateFaultNotificationLFCommsJMSConsumer

The CreateFaultNotificationLFCommsJMSConsumer is a Mediator service that does the following:

1. Picks up the fault message from the AIA_LFERROR_JMSQ queue.

2. Sends the fault message to the AIAAsyncErrorHandlingBPELProcess service, which adds the message to the AIA_ERROR_TOPIC topic.

Provisioning systems that want to notify the central fulfillment system about an error in processing the order create a fault message that includes order details which is added to the AIA_LFERROR_JMSQ. This fault message is processed by the Order Fallout Management framework, and OSM is notified about the errors in the provisioning system for the order.

This service acts as a consumer, listening to the messages produced in the AIA_LFERROR_JMSQ.

Fallout-Enabled Services

The following Create and Manage Trouble Ticket from OSM flow services are fallout-enabled:

• UpdateSalesOrderSiebelCommsProvABCSImpl

• ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl

• ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer

• ProcessFOBillingAccountListRespOSMCFSCommsJMSProducer

• ProcessFulfillmentOrderBillingResponseOSMCFSCommsJMSProducer

• TestOrderOrchestrationEBF

• Siebel.ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer

• Siebel.ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer_RS

  default.ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl.ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl_1_0

• OSM.ABCS.ConsumeCustomerCFO_JMSAdapter

• OSM.ABCS.ConsumeCustomerCFO_JMSAdapter_RS

• OSM.ABCS.ConsumeBillingCFO_JMSAdapter

• OSM.ABCS.ConsumeBillingCFO_JMSAdapter_RS

• OSM.ABCS.ConsumeUpdateFulfillmentOrder_JMSAdapter_RS

• OSM.ABCS.ConsumeUpdateFulfillmentOrder_JMSAdapter

• OSM.ABCS.BillingResponseConsumer

• OSM.ABCS.BillingResponseConsumer_RS

• OSM.ABCS.CustomerResponseConsumer

• OSM.ABCS.CustomerResponseConsumer_RS

• OSM.ABCS.OrderOrchestrationConsumer

• OSM.ABCS.OrderOrchestrationConsumer_RS

• default.TestOrderOrchestrationEBF.TestOrderOrchestrationEBF_1_0

• Siebel.ProcessSalesOrderFulfillmentSiebelCommsSequencer

• ProcessProvisioningOrderOSMPROVCommsJMSProducer

• ProcessFulfillmentOrderUpdateOSMCFSCommsJMSProducer

• OSMPROV

• OSM.ABCS.ConsumeProvUpdate_RS

• OSM.ABCS.ConsumeProvUpdate

• OSM.ABCS.Consume_ProcessProvOrder

• OSM.ABCS.Consume_ProcessProvOrder_RS