| Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Order and Service Management, and Oracle Billing and Revenue Management Release 11.2 Part Number E26501-02 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the Process Sales Order Fulfillment business flow and discusses the implementation of Siebel Customer Relationship Management (Siebel CRM) interfaces, industry Oracle Application Integration Architecture (Oracle AIA) components, and integration services.
This chapter includes the following sections:
Section 9.1, "Process Sales Order Fulfillment Business Flow Overview"
Section 9.2, "Submitting Orders from Siebel CRM to Oracle OSM Integration Flow"
This business flow is enabled using the Oracle Communications Order to Cash Siebel CRM and Oracle Order and Service Management (Oracle OSM) pre-built integration options.
Note:
If you have deployed Oracle Communications Order to Cash Siebel CRM and Oracle BRM options, but not the Oracle OSM option, a Test Orchestration Process (TOP) is shipped to sanity test the out-of-the-box (OOTB) order flow. This must be replaced by your own order management system.
For more information, see Oracle Application Integration Architecture Installation and Upgrade Guide for Pre-Built Integrations, "Configuring and Deploying the Comms Order to Cash: SBL CRM and BRM Pre-Built Integration," Replacing Test Order Orchestration with your Order Management System.
The following integration flow involves submitting orders to Oracle OSM:
Submitting orders from Siebel CRM to Oracle OSM
This integration uses the following interfaces:
ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer
ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl
ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer
Figure 9-1 illustrates an order submitted from Siebel CRM to Oracle OSM Central Fulfillment System (CFS) using Oracle AIA.
When a new order process is initiated, the following events occur:
In Siebel CRM, a user navigates to the Sales Order screen and clicks Submit to submit a new order. This action triggers Siebel to create a Siebel application business message (ABM) with all the captured details. Siebel then enqueues this ABM in the AIA_SALESORDERJMSQUEUE JMS Queue.
After the Siebel ABM is enqueued in the AIA_SALESORDERJMSQUEUE, the ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer dequeues the message and passes it on to the ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl. The ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer has a JMS adapter service that polls for any messages in the AIA_SALESORDERJMSQUEUE.
The ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl invokes the transformation logic to transform Siebel ABM to the ProcessSalesOrderFulfillmentEBM, and routes the message to the ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer.
The Siebel order structure does not support multiple charge types for a single order line, while the order EBO structure does. For this reason, the order lines referencing a Complex Product (CP) of billing type Subscription and its component products of billing type Event, representing a multi-event billing product, are transformed into a single EBO order line referencing a product with multiple charge types.
The ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer interface wraps ProcessSalesOrderFulfillmentEBM into CreateOrder message format and enqueues the message into the AIA_CRTFO_IN_JMSQ.
The CreateOrder message is then wrapped in a SOAP envelope. Oracle OSM expects the following additional JMS properties to be set when the JMS payload:
JMSPriority
URI -- /osm/wsapi
_wls_mimehdrContent_Type -- text/xml; charset=utf-8
Once the message is dropped to the Queue, the store and forward (SAF) mechanism forwards the message from Oracle AIA WebLogic to Oracle OSM WebLogic.
Oracle OSM picks up the CreateOrder message and then further decomposes the order for fulfillment and provisioning.
For more information about how Oracle OSM processes the order, see Chapter 7, "Understanding the Process Integration for Order Lifecycle Management."
For this flow, there is one transaction boundary. Table 9-1 describes the transactions involved, the database operations, and what actions to take in case of an error.
If order submission from Siebel 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.
For more information about system errors and business errors, see Section 27.5.2, "Using Error Type to Control Response to Order Fallout."
The following services are involved:
ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer
ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl
ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer
Table 9-1 Transaction Boundaries and Recovery Details
| Transaction | DB Operations | In Case of Error | Recovery |
|---|---|---|---|
|
ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer passes the Siebel message to ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl, which invokes transformation logic to convert that Siebel message into an EBM. The EBM is then routed to ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer. |
AIA cross-reference entries. |
Rollback cross-reference transactions. Rollback JMS message to AIA_SALESORDERJMSQUEUE_ErrorQ |
Resubmit the order from either AIA_SALESORDERJMSQUEUE_ErrorQ or from Siebel. |
For more information about rollback procedures, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack "Configuring Oracle AIA Processes for Error Handling and Trace Logging", Configuring Fault Policies to Not Issue Rollback Messages.
Customers can add other order priority values in Siebel CRM. Additionally, customers can use the SWI_ORDER_JMS_PRIORITY mapping, which maps these string values to integers.
You are required to set up some JMS compatibility properties on the Siebel queue and to make manual changes to seeded priority values.
For more information about priority values, see the Siebel Order Management Guide Addendum for Communications, Employee Asset-Based Ordering, "Modifying the Order Priority Mapping."
The integration supports 10 priority values, 0-9, as dictated by JMS queuing technology. Implementers can extend Siebel to support priority values other than the four that are supported when delivered.
For more information, see the Siebel product documentation for Lists of Values.
These steps describe how the integration handles order priorities:
When the order is submitted, Siebel sets the JMS Priority message in the JMS headers and also populates the following field: ListOfSWIOrderIO/SWIOrder/OrderPriority.
Based on the priority, the ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer consumes the message and routes it to the ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl. This process does a lookup on the SALESORDER_PRIORITY domain value map (DVM) and populates the ProcessSalesOrderFulfillmentEBM/DataArea/ProcessSalesOrderFulfillment/FulfillmentPriorityCode.
The ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer looks for the FulfillmentPriorityCode and does a lookup on SALESORDER_PRIORITY DVM for the JMS column and populates the priority in the JMS Headers in JMSPriority field.
The store and forward (SAF) mechanism honors the JMS priority and picks up the message with high priority first and passes it to Oracle OSM CFS.
Oracle OSM CFS and Oracle OSM Provisioning honor the priority through internal mechanisms. Higher priority orders are fulfilled and provisioned first, followed by lower priority orders.
Oracle OSM is expected to maintain the priority of the orders and must populate the FulfillmentPriorityCode element in all outbound messages.
The population of JMS priority from the FulfillmentPriorityCode is done using the BPEL assign activity as follows:
Look up the DVM column for priority value and copy it to the JMSPriority field in JMS headers:
<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>
jmsHeaders is a variable which is of type JMSOutboundHeadersAndProperties.
msg_priority is a string variable.
The ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer follows this logic to populate the JMSPriority.
Other producers need not do a DVM lookup since 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. Oracle OSM and Oracle AIA, unlike Siebel, follow the same values for JMS priorities.
This integration flow uses the following Siebel interface:
SISOMBillingSubmitOrderWebService
This is the outbound Siebel web service used to submit orders.
For more information about web services, see the Siebel Order Management Guide Addendum for Communications, "Web Services Reference."
These integration flows use these industry components:
SalesOrderEBO
ProcessSalesOrderFulfillmentEBM
The industry enterprise business object (EBO) and EBM XSD files are located here: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/
The industry EBS WSDL files are located here: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Industry/Communications/EBO/
For detailed documentation of individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in the Oracle Enterprise Repository (OER).
For more information about using the OER and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle SOA Repository."
EBOs can be extended, for instance, to add new data elements. These extensions are protected and remain intact after a patch or an upgrade, so long as the extensibility guidelines are followed.
For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Working with AIA Design Patterns," AIA Assets Extensibility Patterns, Extending Existing Schemas in AIA.
The following services are delivered with these integration flows:
ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer
ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl
ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducer
The ProcessSalesOrderFulfillmentSiebelCommsJMSConsumer is implemented as a Mediator process.
This consumer listens over the AIA_SALESORDERJMSQUEUE into which Siebel enqueues the simple object access protocol (SOAP)-wrapped Siebel Order application business message (ABM). This consumer dequeues the messages from this queue, unwraps the message from the SOAP envelope, and routes the Siebel ABM to the ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl.
The ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl is implemented as a business process execution language (BPEL) process with a single operation: Initiate.
This service is invoked when an order is submitted in the Siebel application. This service is the Siebel ABCS implementation, which converts the Siebel ABM into the Sales Order EBM. The service looks up the cross-reference values for the customer account ID, billing profile ID, pay profile ID, and product ID to find common IDs to appropriately populate the Sales Order EBM. In the case of promotions and service bundles, if the cross-reference values are not present, new cross-reference values are created.
This service also creates the requisite cross-reference values for the order ID, order line ID, installed product ID, account ID, bill profile ID, pay profile ID, contact ID, and address ID between Siebel values and generated common values.
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 Oracle OSM) and Oracle OSM's CreateOrder envelope.
This service has one operation: ProcessSalesOrderFulfillment. It takes the
ProcessSalesOrderFulfillmentOSMCFSCommsJMSProducerRequestMessage as input.
|
 Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|