| Oracle® Application Integration Architecture Siebel CRM Integration Pack for Oracle Order Management: Order to Cash Implementation Guide Release 3.1.1 Part Number E20515-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Application Integration Architecture Siebel CRM Integration Pack for Oracle Order Management: Order to Cash Implementation Guide Release 3.1.1 Part Number E20515-04 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview and discusses the process integration for Order Management.
This chapter includes the following sections:
Section 11.6, "Siebel Customer Relationship Management (Siebel CRM) Interfaces"
Section 11.7, "Oracle E-Business Suite (Oracle EBS) Interfaces"
Section 11.8, "Core Oracle Application Integration Architecture (Oracle AIA) Components"
The process integration for Order Management between Siebel Customer Relationship Management (Siebel CRM) and Oracle E-Business Suite (Oracle EBS) supports the following integration flows:
Create sales orders: This flow enables the processing of new orders submitted from Siebel CRM to Oracle EBS.
Revise sales order (Siebel CRM-initiated): This flow enables the processing of order revisions or changes from Siebel CRM to Oracle EBS.
Cancel sales orders: This flow enables the processing of order cancellations from Siebel CRM to Oracle EBS.
Update sales orders (Oracle EBS-initiated): This flow enables the synchronization of order updates from Oracle EBS to Siebel CRM. Shipping details from Oracle EBS are also synchronized.
Additionally, freight charges and estimated taxes are synchronized from Oracle EBS to Siebel CRM.
The process integration for Order Management uses the following service calls:
Available to Promise (ATP): This check service is initiated from Siebel CRM and provides information about when a product can be fulfilled from Oracle EBS.
Credit Check: This service is initiated from Siebel CRM and obtains credit status information for purchase orders from Oracle EBS.
Payment Authorization: This service is initiated in Siebel CRM and obtains the authorization status for credit cards from iPayment in Oracle EBS.
Shipping Charges: This service is initiated in Siebel CRM and obtains the estimated shipping cost from Oracle Transportation Management (OTM).
Find prerequisites in Chapter 13, "Reviewing Prerequisites and Data Requirements."
The process integration for Order Management has the following assumptions and constraints:
Orders must be submitted with a status of Booked. Orders have a status of Booked before they are submitted. Before invoking any integration services, Siebel CRM validates this status using a workflow process.
Siebel CRM allows revisions to an order if the order status is Booked.
Business-to-Customer (B2C) scenarios are not supported.
Order updates in Oracle EBS are system-driven. When any of the following attributes change, they are synchronized to Siebel CRM:
Order Header/Line Status
Order Header Hold/Hold Release
System-generated line splits due to partial shipping
Line schedule arrival date changes
Taxes and freight charges
Shipping charges
The following Order (or Order line) statuses from Oracle E-Business Suite are supported:
Booked
Awaiting Shipping
Shipped
Fulfilled
Closed
Cancelled
Supply Eligible
Additional status values can configured by exposing them in Oracle E-Business Suite, and adding List of Values in Siebel, and domain value maps (DVMs) in Oracle AIA.
Customer Account ID, Product ID, and Price List ID (optional) must be available before an order is submitted. If they are not synchronized, the processes end in error.
When an order with a configured product is submitted to Oracle EBS, the order gets updated with certain included items, products, or both associated with the configured product.
This order update is synchronized back to Siebel CRM also. However, these included items in Siebel CRM are displayed as separate line items, instead of being a part of configured product hierarchy. These included items do not have a pricing impact.
When an order is put on hold due to credit status, orders can be resubmitted only after the credit hold is released.
In Oracle EBS multiple holds can exist at the order header and line items. In this solution, only a single header hold is supported out-of-the-box.
Order data validation is accomplished using Siebel Data Validation Manager workflow processes. Order data is validated for new order, order revision, and order cancellation flows in Siebel.
It is assumed that order data validation processes have been successfully run before submission of the order.
Order validation is not done within the integration process services.
This integration does not support manual updates to orders in Oracle EBS.
Only Siebel orders of the type Sales Orders are supported in this integration.
The order can be revised if the status of the order is Booked and the status of at least one order lines is Booked or Awaiting Shipping.
If the status of the line is Shipped, Fulfilled, Closed, Cancelled, Cancel Pending, or Supply Eligible, the order line is not revisable and cannot be canceled.
Deletion of an existing Order line in an order revision is not supported.
Return Material Authorization (RMA) is not supported for assemble-to-order (ATO) and pick-to-order (PTO) items.
Figure 11-1 illustrates the overall flow for the process integration:
When this process is initiated, the following events take place:
Sales and RMA Orders are created in Siebel CRM.
Upon submission of the order in Siebel CRM, the Oracle AIA services send it to Oracle EBS for fulfillment.
Accounts created in Siebel CRM do not get immediately synchronized to Oracle EBS by default. Instead, accounts are synchronized to Oracle EBS only after an order has been submitted in Siebel CRM.
When an order is submitted in Siebel CRM, it raises an event that invokes the ProcessSalesOrderSiebelReqABCSImplV2 service, which calls the SalesOrderOrchestrationEBSV2 service. SalesOrderOrchestrationEBSV2 can be configured to call an order orchestration process.
The sales order orchestration has two steps: first, SyncCustomer initiates the customer flows; second, OrderFulfill, which proceeds with order processing in Oracle EBS.
Automated order update events occur in Oracle EBS.
When a Sales or RMA order update event occurs in Oracle EBS, Oracle AIA services sends the order update to Siebel CRM.
Figure 11-2 illustrates the overall Order Management integration flow:
The Create Sales Order flow enables the submission of new orders from Siebel CRM to Oracle EBS. Orders are captured in Siebel CRM. After orders go through the ATP check and credit check, they are submitted to Oracle EBS. After sales orders are submitted, they are frozen in Siebel CRM. When the order has been successfully submitted to Oracle EBS, the order status is updated in Siebel CRM.
The order submission initiates the synchronization of accounts from Siebel CRM to Oracle EBS.
These integration flows can be invoked before the Create Order flow is called:
ATP
Shipping Charges
Credit Check
Payment Auth
When a sales order is processed in Oracle EBS, the freight charges and estimated taxes are returned. The update sales order flow updates these on the Sales Order in Siebel CRM.
Additionally, when the order is fulfilled in Oracle EBS, the shipping details are synchronized to Siebel CRM.
Figure 11-3 illustrates the Create Sales Order integration flow:
This integration flow uses the following interfaces:
ProcessSalesOrderSiebelJMSProducerV2
ProcessSalesOrderSiebelJMSConsumerV2
ProcessSalesOrderSiebelReqABCSImplV2
SalesOrderOrchestrationEBSV2
SalesOrderOrchestrationResponseEBSV2
InterfaceSalesOrderToFulfillmentEBF
InterfaceSalesOrderToCustomerEBF
InterfaceCustomerToFulfillmentEBF
SalesOrderEBSV2
CreateSalesOrderEbizProvABCSImpl
SyncSalesOrderEbizProvABCSImpl
ProcessSalesOrderEbizAdapter
SalesOrderResponseEBSV2
UpdateSalesOrderSiebelProvABCSImpl
Order components that are synchronized and passed to Oracle EBS:
Accounts
Addresses
Contacts
Products
Price
Order Management-related
Figure 11-4 illustrates the Create Sales Order integration flow:
When the Create Sales Order process is initiated, the following events occur:
When an Order is created and submitted in Siebel CRM (version 8.0.0.x), workflow invokes the ProcessSalesOrderSiebelJMSProducerV2 service. If Siebel CRM 8.1.1.x is being used, then Siebel directly enqueues the message onto the AIA queue.
The invoked JMSProducer service enqueues the Siebel application business message (ABM) to a Java Message Service (JMS) queue and replies the success or failure of the enqueue to the Siebel application.
The ProcessSalesOrderSiebelJMSConsumerV2 service dequeues the Siebel ABM from the JMS queue and invokes the ProcessSalesOrderSiebelReqABCSImplV2 service. In case of Siebel 8.1.1.x, the dequeue is done by ProcessSalesOrderSoapMsgSiebelJMSConsumer.
The invoked ProcessSalesOrderSiebelReqABCSImplV2 service transforms the Siebel ABM into the ProcessSalesOrderEBM.
In doing so, the Order, Order Line, Account, Contact, and Address cross-reference tables are populated with the Siebel Row IDs and newly generated Common IDs. In this process of transformation, EBMHeader/VerbCode is identified as follows: If CurrentOrderRowId (SWIOrder/ID) equals PreviousOrderId (SWIOrder/PreviousOrderId), the VerbCode is populated as Process; otherwise, the VerbCode holds Sync.
The ProcessSalesOrderSiebelReqABCSImplV2 then invokes the ProcessSalesOrder operation of the SalesOrderOrchestrationEBSV2, which is routed to the InterfaceSalesOrderToFulfillmentEBF enterprise business flow.
The InterfaceSalesOrderToFulfillmentEBF process in turn invokes the InterfaceSalesOrderToCustomerEBF process only for the sales orders.
A configuration parameter is available to prevent the customer sync service from being invoked if a customer chooses. However, if it is decided based on a flag sent by Siebel whether the Address or Contact has changed, then the Customer sync should be invoked.
The InterfaceSalesOrderToCustomerEBF process transforms the SalesOrderEBM into the ProcessCustomerPartyListEBM containing a reduplicated list of Account, Contact, and Address IDs that were referenced on the order.
The InterfaceSalesOrderToCustomerEBF then invokes the InterfaceCustomerToFulfillmentEBF, which performs the necessary steps for synchronizing the customer accounts, contacts, and addresses to the fulfillment system.
Upon receiving the response from the InterfaceCustomerToFulfillmentEBF service, the InterfaceSalesOrderToCustomerEBF sends a response enterprise business message (EBM) back to the InterfaceSalesOrderToFulfillmentEBF.
When the response is received from the InterfaceSalesOrderToCustomerEBF service, backward compatibility to support CreateSalesOrderEbizProvABCSImpl for new order creation can be controlled by a configuration parameter isLegacyEbizProvSupported and EBMHeader/VerbCode value Process (refer to step 4).
The InterfaceSalesOrderToFulfillmentEBF performs a transformation to generate the CreateSalesOrderEBM, which is used to invoke the CreateSalesOrder operation of the SalesOrderEBSV2. Otherwise, the InterfaceSalesOrderToFulfillmentEBF performs a transformation to generate the SyncSalesOrderListEBM, which is used to invoke the SyncSalesOrderList operation of the SalesOrderEBSV2.
The SalesOrderEBSV2 routes the CreateSalesOrder invocation to the CreateSalesOrderEbizProvABCSImpl service or routes the SyncSalesOrderList invocation to the SyncSalesOrderEbizProvABCSImpl.
The CreateSalesOrderEbizProvABCSImpl/SyncSalesOrderEbizProvABCSImpl service transforms the CreateSalesOrderEBM/SyncSalesOrderListEBM into the Oracle ProcessOrderABM.
The CreateSalesOrderEbizProvABCSImpl/SyncSalesOrderEbizProvABCSImpl service then invokes the ProcessOrder operation of the ProcessSalesOrderEbizAdapter service.
This service invokes the appropriate Oracle ProcessOrder PL/SQL application programming interface (API), which results in the creation of the order in the Oracle EBS system.
Upon completion and response from the ProcessSalesOrderEbizAdapter, the CreateSalesOrderEbizProvABCSImpl/SyncSalesOrderEbizProvABCSImpl generates the response EBM, during which the Oracle IDs are added to the cross-reference, and replies to the SalesOrderResponseEBSV2, which in turn is routed back to the InterfaceSalesOrderToFulfillmentEBF.
The InterfaceSalesOrderToFulfillmentEBF then performs another transformation to generate the UpdateSalesOrderEBM, which is used to invoke the UpdateSalesOrder operation of the SalesOrderEBSV2.
The SalesOrderEBSV2 routes the UpdateSalesOrder invocation to the UpdateSalesOrderSiebelProvABCSImpl service.
The UpdateSalesOrderSiebelProvABCSImpl transforms the UpdateSalesOrderEBM to the UpsertOrder Siebel ABM using the appropriate cross-reference tables to determine the Siebel IDs from the Common IDs.
The UpdateSalesOrderSiebelProvABCSImpl then invokes the Siebel UpsertOrder web service to update the status of the order header.
An appropriate provider application business connector service (ABCS) should be identified and routed to the following two points in the Create Order integration flow:
The creation of the order in the back office fulfillment system. The SalesOrderEBSV2 CreateSalesOrder operation must invoke the appropriate provider ABCS. When delivered, the target fulfillment system is not identified until the original CreateSalesOrderEBS routing rules are run and the system determines that the Oracle EBS provider ABCS should be the target. Customers can replace the original routing rules to do more complex target system decision-making and routing.
After the creation of the order in the back office fulfillment when the SalesOrderEBSV2 UpdateSalesOrder operation must invoke the provider ABCS for the original CRM system from which the order was submitted. This routing uses the Source System ID that is available in the original ProcessSalesOrderEBM to identify the provider ABCS.
The Update Sales Order integration flow enables the synchronization of order updates from Oracle EBS to Siebel CRM. This is a one-way synchronization from Oracle EBS to Siebel CRM. When orders are updated, a business event is triggered to enable the synchronization of the latest order status from Oracle EBS to Siebel CRM. Only the following order and order-line statuses are brought back to Siebel CRM:
Booked
Awaiting Shipping
Shipped
Fulfilled
Closed
Cancelled
Supply Eligible
The Update Sales Order integration flow uses the same Sales Order enterprise business object (EBO) as the create process.
Certain Order updates in Oracle EBS are system-driven. When any of the following attributes changes, these are synchronized to Siebel CRM:
Order Header/Line Status
Order Header Hold/Hold Release
System-generated line splits due to partial shipping
Line schedule arrival date
Line schedule ship date
Order Header and Order Line Taxes
Order Header and Order Line Freight charges
When an order line is shipped, the following order line shipping details are also synchronized to Siebel CRM:
Tracking number
Actual shipped date
Ship from location
Carrier code
Shipped quantity
Figure 11-5 illustrates the Update Sales Order integration flow:
This integration flow uses the following interfaces:
UpdateSalesOrderEbizEventConsumer
UpdateSalesOrderEbizReqABCSImpl
GetSalesOrderEbizAdpater
SalesOrderEBSV2
SalesOrderResponseEBSV2
UpdateSalesOrderSiebelProvABCSImpl
GetSalesOrderLineShippingDetailsEbizAdapter
Figure 11-6 illustrates the Update Sales Order flow sequence diagram.
When you initiate the Update Sales Order process in Oracle EBS, the following events take place:
When an order header or line update event is launched, the event is enqueued to Oracle Advanced Queuing (AQ).
UpdateSalesOrderEbizEventConsumer consumes the message from the AQ.
The UpdateSalesOrderEbizEventConsumer service has resequencer properties defined to provide guaranteed first-in first-out processing of the events. For each event, the UpdateSalesOrderEbizReqABCSImpl service is invoked. If the resequencer is enabled, then events of the same order are processed sequentially but the events of a different order are processed in parallel.
The UpdateSalesOrderEbizReqABCSImpl service transforms the EventABM into the Oracle ABM for requesting the Order payload, and then invokes the GetSalesOrderEbizAdpater service for retrieving the full Order update details.
For each Order line with status Shipped, the Order payload is transformed into the RequestOrderLineShippingDetailsABM and the GetSalesOrderLineShippingDetailsEbizAdapter is invoked for retrieving shipping details for that shipped Order line.
The UpdateSalesOrderEbizReqABCSImpl then transforms the full Order update payload along with the fetched and aggregated OrderLineShippingDetailsABMs into the UpdateSalesOrderEBM to invoke the UpdateSalesOrder operation of the SalesOrderEBSV2.
The SalesOrderEBSV2 routes the UpdateSalesOrder operation to the UpdateSalesOrderSiebelProvABCSImpl service.
The UpdateSalesOrderSiebelProvABCSImpl service transforms the UpdateSalesOrderEBM into the Upsert Order Siebel ABM and invokes the Siebel Upsert Order web service.
Upon response from the Siebel web service, the response is transformed into the UpdateSalesOrderResponseEBM during which any newly inserted line IDs are added to the cross-reference.
In Oracle EBS, when the order is updated, a business event is triggered from Oracle EBS that enables the synchronization of the latest order status to Siebel CRM. These business events in Oracle EBS result in messages generated and sent to AIA for processing. Sequencing of events has been configured in the Update Order flow to provide the following functionality:
Events belonging to different orders run in parallel.
Events belonging to the same order run sequentially.
The Update Order flow determines what target system provider ABC service to invoke. As delivered, the UpdateSalesOrderEBS routing rules run and determine that the Siebel provider ABC service should be the target. Customers can replace the original routing rules to do more complex target system decision-making and routing.
The following steps must be performed using the Oracle Enterprise Manager Fusion Middleware Control Console to enable the resequencer functionality in Oracle Mediator and for better performance. The Fusion Middleware sequencing feature ensures better scalability and performance. Not defining these properties does not affect anything in the code, but the synchronize Update Order flow works as a single threaded flow.
To update order events resequencing on FMW:
Launch Oracle Enterprise Manager.
Open the SOA Infrastructure Home page.
From the SOA Infrastructure menu, select SOA Administration and then Mediator Properties.
Configure the following properties for better performance of the sequencing feature:
Resequencer Worker Threads = 5
Resequencer Locker Thread Sleep (sec) = 1000
Resequencer Maximum Groups Locked = 100
Note:
The value of these properties can vary based on the environment configuration and the same can be set appropriately.
Save the changes.
For more information about using the Oracle Mediator Resequencer as a part of an Oracle AIA implementation, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite, "Resequencing in Oracle Mediator."
All customer-requested revisions or changes to the order are done in Siebel CRM. If the order is booked and submitted to Oracle EBS, these changes must be validated by Oracle EBS Order Management processing constraints. The changes that are not allowed by the fulfillment system (Oracle EBS) are restricted in Siebel CRM, and the corresponding error message is sent
The process integration for Order Management has the following assumptions and constraints:
An order in Siebel can be revised only when the status of the order is Booked.
An order line in Siebel can be revised or canceled if its status is Booked or Awaiting Shipping. Siebel CRM does not allow order line revision if the status of the order line is Shipped, Fulfilled, Closed, Cancelled, Cancel Pending, or Supply Eligible. In this case, if the CSR clicks the Revise button, the message box appears with the message "Order not revise-able as it is beyond that state."
Siebel CRM controls the Order or Order line revision using rules in its Data Validation Manager component.
When a sales order is revised in Oracle EBS, the freight charges and estimated taxes are returned for those lines. The revise sales order flow updates these on the sales order in Siebel CRM.
Deletion of an existing line in an order in a revision is not supported.
This integration flow uses the following interfaces:
ProcessSalesOrderSiebelJMSProducerV2
ProcessSalesOrderSiebelReqABCSImplV2
SalesOrderOrchestrationEBSV2
InterfaceSalesOrderToFulfillmentEBF
InterfaceSalesOrderToCustomerEBF
InterfaceCustomerToFulfillmentEBF
SalesOrderEBSV2
SyncSalesOrderEbizProvABCSImpl
ProcessSalesOrderEbizAdapter
UpdateSalesOrderSiebelProvABCSImpl
Figure 11-7 illustrates the Revise Sales Order (Siebel CRM-initiated) integration flow:
When you initiate the revise sales order process in Siebel CRM, the following events take place:
When an order is revised and submitted in Siebel CRM (version 8.0.0.x), workflow invokes the ProcessSalesOrderSiebelJMSProducerV2 service. If Siebel CRM 8.1.1.x is being used, then Siebel directly enqueues the message onto the AIA queue.
The invoked JMSProducer service enqueues the Siebel ABM to a Java Message Service (JMS) queue and replies the success or failure of the enqueue to the Siebel application.
The ProcessSalesOrderSiebelJMSConsumerV2 service dequeues the Siebel ABM from the JMS queue and invokes the ProcessSalesOrderSiebelReqABCSImplV2 service. For Siebel 8.1.1.x, the dequeue is done by ProcessSalesOrderSoapMsgSiebelJMSConsumer.
The invoked ProcessSalesOrderSiebelReqABCSImplV2 service transforms the Siebel ABM into the ProcessSalesOrderEBM.
In doing so, the Account, Contact, and Address cross-reference tables are looked up or populated with the respective common IDs; the Order and OrderLine are populated for the new order and for the revised order but not for the canceled order.
The ProcessSalesOrderSiebelReqABCSImplV2 then invokes the ProcessSalesOrder operation of the SalesOrderOrchestrationEBSV2 that is routed to the InterfaceSalesOrderToFulfillmentEBF enterprise business flow.
The InterfaceSalesOrderToFulfillmentEBF process in turn invokes the InterfaceSalesOrderToCustomerEBF process only for sales orders.
A configuration parameter is available to prevent the customer sync service from invoking if a customer chooses. However, if it is decided based on a flag sent by Siebel whether the Address/Contact has changed, only then should the customer sync be invoked.
If customer sync is invoked, the InterfaceSalesOrderToCustomerEBF process transforms the SalesOrderEBM into the ProcessCustomerPartyListEBM containing a reduplicated list of the Account, Contact, and Address IDs that were referenced on the order.
The InterfaceSalesOrderToCustomerEBF then invokes the InterfaceCustomerToFulfillmentEBF that performs the necessary steps for synchronizing the customer accounts, contacts, and addresses to the fulfillment system (if the customer sync is invoked).
Upon receiving the response from the InterfaceCustomerToFulfillmentEBF service, the InterfaceSalesOrderToCustomerEBF sends a response EBM back to the InterfaceSalesOrderToFulfillmentEBF (if customer sync is invoked).
Upon receiving the response from the InterfaceSalesOrderToCustomerEBF service, the InterfaceSalesOrderToFulfillmentEBF performs a transformation to generate the SyncSalesOrderListEBM that is used to invoke the SyncSalesOrderList operation of the SalesOrderEBSV2.
The SalesOrderEBSV2 routes the SyncSalesOrderList invocation to the SyncSalesOrderEbizProvABCSImpl service.
The SyncSalesOrderEbizProvABCSImpl service transforms the SyncSalesOrderListEBM into the Oracle ProcessOrderABM.
The SyncSalesOrderEbizProvABCSImpl service then invokes the ProcessOrder operation of the ProcessSalesOrderEbizAdapter service.
This service invokes the appropriate Oracle ProcessOrder PL/SQL application programming interface (API) that results in the update of the order in the Oracle EBS system.
Upon completion and response from the ProcessSalesOrderEbizAdapter, the SyncSalesOrderEbizProvABCSImpl generates the response EBM and replies to the SalesOrderResponseEBSV2 that in turn is routed back to the InterfaceSalesOrderToFulfillmentEBF.
The InterfaceSalesOrderToFulfillmentEBF then performs another transformation to generate the UpdateSalesOrderEBM that is used to invoke the UpdateSalesOrder operation of the SalesOrderEBSV2.
The SalesOrderEBSV2 routes the UpdateSalesOrder invocation to the UpdateSalesOrderSiebelProvABCSImpl service.
The UpdateSalesOrderSiebelProvABCSImpl transforms the UpdateSalesOrderEBM to the UpsertOrder Siebel ABM using the appropriate cross-reference tables to determine the Siebel IDs from Common IDs.
The UpdateSalesOrderSiebelProvABCSImpl then invokes the Siebel UpsertOrder web service to update the status of the order header.
If any order is canceled in Order capture system (Siebel CRM), it must be canceled in the Fulfillment system (Oracle EBS) as well. The order cancellation flow requests to cancel the entire order, canceling all open lines in an order. In this scenario, the order level cancellation is initiated in Siebel CRM through an order revision, to be processed in Oracle EBS. If the fulfillment system (Oracle EBS) rejects the order cancellation for any reason, the order revision in Siebel CRM must be rolled back to prior version.
Additionally, a cancel reason for the order cancellation has also to be provided.
The process integration for Order Management has the following assumptions:
If the order status is Booked, only then can the order be canceled.
Entire order cancellation is not possible if any of the order line status is Shipped, Fulfilled, Closed, Cancelled, Cancel Pending, or Supply Eligible.
This integration flow uses the following interfaces:
ProcessSalesOrderSiebelJMSProducerV2
ProcessSalesOrderSiebelReqABCSImplV2
SalesOrderOrchestrationEBSV2
InterfaceSalesOrderToFulfillmentEBF
SalesOrderEBSV2
SyncSalesOrderEbizProvABCSImpl
ProcessSalesOrderEbizAdapter
SalesOrderResponseEBSV2
UpdateSalesOrderSiebelProvABCSImpl
Figure 11-8 illustrates the Cancel Sales Order integration flow:
When you initiate the Cancel Sales Order process, the following events take place:
When an order is submitted for cancellation in Siebel CRM (version 8.0.0.x), workflow invokes the ProcessSalesOrderSiebelJMSProducerV2 service. If Siebel CRM 8.1.1.x is being used, then Siebel directly enqueues the message onto the AIA queue.
The invoked JMSProducer service enqueues the Siebel ABM (holding only header parameters) to a JMS queue and communicates the success or failure of the enqueue to the Siebel application.
The ProcessSalesOrderSoapMsgSiebelJMSConsumer service dequeues the Siebel ABM from the JMS queue and invokes the ProcessSalesOrderSiebelReqABCSImplV2 service. For Siebel 8.0.0.x, the dequeue is done by the ProcessSalesOrderSiebelJMSConsumerV2.
The invoked ProcessSalesOrderSiebelReqABCSImplV2 service transforms the Siebel ABM into the ProcessSalesOrderEBM.
In doing so, the Order cross-reference table is looked up for the Siebel Row IDs and newly generated Common IDs.
The ProcessSalesOrderSiebelReqABCSImplV2 then invokes the ProcessSalesOrder operation of the SalesOrderOrchestrationEBSV2 that is routed to the InterfaceSalesOrderToFulfillmentEBF enterprise business flow.
InterfaceSalesOrderToFulfillmentEBF performs a transformation to generate the SyncSalesOrderListEBM that is used to invoke the SyncSalesOrderList operation of the SalesOrderEBSV2.
The SalesOrderEBSV2 routes the SyncSalesOrderList invocation to the SyncSalesOrderEbizProvABCSImpl.
The SyncSalesOrderEbizProvABCSImpl service transforms the SyncSalesOrderListEBM into the Oracle ProcessOrderABM.
The SyncSalesOrderEbizProvABCSImpl service then invokes the ProcessOrder operation of the ProcessSalesOrderEbizAdapter service.
This service invokes the appropriate Oracle ProcessOrder PL/SQL API that results in the cancellation of the order in the Oracle EBS system.
Upon completion and response from the ProcessSalesOrderEbizAdapter, the SyncSalesOrderEbizProvABCSImpl generates the response EBM, during which the Oracle IDs are looked up in the cross-reference, and replies to the SalesOrderResponseEBSV2, which in turn is routed back to the InterfaceSalesOrderToFulfillmentEBF.
The InterfaceSalesOrderToFulfillmentEBF then performs another transformation to generate the UpdateSalesOrderEBM, which is used to invoke the UpdateSalesOrder operation of the SalesOrderEBSV2.
The SalesOrderEBSV2 routes the UpdateSalesOrder invocation to the UpdateSalesOrderSiebelProvABCSImpl service.
The UpdateSalesOrderSiebelProvABCSImpl transforms the UpdateSalesOrderEBM to the UpsertOrder Siebel ABM using the appropriate cross-reference tables to determine the Siebel IDs from Common IDs.
The UpdateSalesOrderSiebelProvABCSImpl then invokes the Siebel UpsertOrder web service to update the status of the order header.
These are the Siebel CRM web services for the Order Management integration flow:
Inbound Siebel CRM Web Services
Service Name: SWIOrderUpsert
Operation Name: SBLOrderUpsert
Request Schema: SWIOrderIO.xsd
Response Schema: SWIOrderIO.xsd
Service Name: OrderUpsertService
The UpdateSalesOrderSiebelProvABCSImpl invokes this service during:
The CreateOrder integration flow after the order has been synced to back office. The order header's integration status is updated to Created In Back Office or Error In Back Office.
The Update Order integration flow after the order line update is done in the back office. UpdateSalesOrderSiebelProvABCSImpl also invokes OrderUpsertService to update shipping details of the order line.
Service Name: QuoteUpsertService
The UpdateSalesOrderSiebelProvABCSImpl invokes this service during the CreateQuote integration flow after syncing the quote to the back office. The quote header's integration status is updated to Created In Back Office or Error In Back Office.
Outbound Siebel CRM Web Services
Sales Order Submitted - Siebel CRM invokes ProcessSalesOrderSiebelJMSProducerV2 with the ListOfSWIOrderIO ABM
Quote Submitted - Siebel CRM invokes the ProcessQuoteSiebelJMSProducer with the ListOfSWIQuoteIO ABM
New Sales Order, Revised Order, or Cancel Order Submitted - Siebel CRM invokes the ProcessSalesOrderSiebelJMSProducerV2 service.
For more information about Siebel web services, see CRM Web Services Reference.
These are the Oracle EBS web services for the Order Management integration flow:
Inbound to Oracle EBS Web Services
OE_INBOUND_INT.PROCESS_ORDER_25 (Process Sales Order Service)
OE_OUTBOUND_INT.SYNC_ORDER (Get Sales Order Service)
GetSalesOrderLineShippingDetailsService
The UpdateSalesOrderEbizReqABCSImpl service invokes this service during the Update Order integration flow to retrieve the order line shipping details before sending the updates to Siebel.
GetSalesOrderService
The UpdateSalesOrderEbizReqABCSImpl service invokes this service during the Update Order integration flow to retrieve the order header or line update details before sending the updates to Siebel.
Outbound from Oracle EBS Event Interfaces
oracle.apps.ont.genesis.outbound.update
For more information about Oracle E-Business Suite web services and documentation prior to Release 12.1.3, see the library on Oracle Technology Network: http://www.oracle.com/technetwork/documentation/applications-167706.html?. For Oracle E-Business Suite documentation for R12.1.3 and beyond, see this library: http://download.oracle.com/docs/cd/E18727_01/index.htm?
The Order Management process integration uses the following delivered EBOs and enterprise business messages (EBMs):
SalesOrderEBO
ProcessSalesOrderEBM
ProcessSalesOrderResponseEBM
CreateSalesOrderEBM
CreateSalesOrderResponseEBM
UpdateSalesOrderEBM
UpdateSalesOrderResponseEBM
ProcessCustomerPartyListEBM
ProcessCustomerPartyListResponseEBM
For detailed documentation of individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in Oracle Enterprise Repository.
For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
EBOs can be extended, for instance, to add new data elements. These extensions are protected, and they remain intact after a patch or an upgrade.
For more information, see Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Extensibility."
The integration provides these services:
SalesOrderEBSV2
SalesOrderResponseEBSV2
SalesOrderOrchestrationEBSV2
SalesOrderOrchestrationResponseEBSV2
CustomerPartyOrchestrationEBSV2
CustomerPartyOrchestrationResponseEBSV2
InterfaceSalesOrderToFulfillmentEBF
InterfaceSalesOrderToCustomerEBFV2
ProcessSalesOrderSiebelJMSProducerV2
ProcessQuoteSiebelJMSProducer
ProcessSalesOrderSiebelJMSConsumerV2
ProcessSalesOrderSoapMsgSiebelJMSConsumer
ProcessQuoteSiebelJMSConsumer
ProcessQuoteSoapMsgSiebelJMSConsumer
ProcessSalesOrderSiebelReqABCSImplV2
ProcessQuoteSiebelReqABCSImpl
CreateSalesOrderEbizProvABCSImpl
SyncSalesOrderEbizProvABCSImpl
UpdateSalesOrderEbizEventConsumer
UpdateSalesOrderEbizReqABCSImpl
UpdateSalesOrderSiebelProvABCSImpl
ProcessSalesOrderEbizAdapter
GetSalesOrderEbizAdapter
GetSalesOrderLineShippingDetailsEbizAdapter
The SalesOrderEBSV2 is an EBS that provides basic request and response operations that can be performed against the SalesOrderEBO. This service is invoked as part of the create order, update order, and cancel order integration flows.
CreateSalesOrder
UpdateSalesOrder
SyncSalesOrderList
The SalesOrderEBSV2 is implemented as a Mediator routing service.
For more information about this EBS, see the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."
The SalesOrderResponseEBSV2 service is an EBS that provides the basic response operations that can be performed against the SalesOrderEBO. This service is invoked as part of the create order, update order, and cancel order integration flows.
SalesOrderResponseEBSV2 Operations
CreateSalesOrderResponse
UpdateSalesOrderResponse
SyncSalesOrderListResponse
The SalesOrderResponseEBSV2 service is implemented as a Mediator routing service.
For more information about this EBS, see the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."
The SalesOrderOrchestrationEBSV2 and SalesOrderOrchestrationResponseEBSV2 are enterprise business services providing request and response operation routing to process a sales order through a business process flow. These services are invoked as part of the create order, change order, and cancel order integration flows
Note:
Invoking InterfaceSalesOrderToCustomer for cancel order is not required, because the order is not revised.
Figure 11-9 illustrates the request and response operation routing to process a sales order.
The SalesOrderOrchestrationResponseEBSV2 service exposes the asynchronous response operations for each of the request operations.
The SalesOrderOrchestrationEBSV2 service has four asynchronous one-way operations. The SalesOrderOrchestrationResponseEBSV2 has four asynchronous response operations.
SalesOrderOrchestrationEBSV2 Operations
ProcessSalesOrder
This operation is routed to the InterfaceSalesOrderToFulfillment operation of the same EBS.
If customers want to insert a custom orchestration process into the flow, they must define a routing rule that routes this operation to the custom orchestration process rather than the InterfaceSalesOrderToFulfillment.
InterfaceSalesOrderToFulfillment
This operation is routed to the InterfaceSalesOrderToFulfillmentEBF.
InterfaceSalesOrderToCustomer
This operation is routed to the InterfaceSalesOrderToCustomerEBFV2.
SalesOrderOrchestrationResponseEBSV2 Operations
ProcessSalesOrderResponse
This operation is intended to be routed to the caller of the ProcessSalesOrder operation as indicated in the EBM header. However, no routing targets are provided because the ProcessSalesOrderSiebelReqABCSImpl does not expect to receive a response.
InterfaceSalesOrderToFulfillmentResponse
This operation is routed to the ProcessSalesOrderResponse operation as indicated in the EBM header.
InterfaceSalesOrderToCustomerResponse
This operation is routed to the caller of the InterfaceSalesOrderToCustomer operation (InterfaceSalesOrderToFulfillmentEBF) as indicated in the EBM header.
For more information about this EBS, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."
The CustomerPartyOrchestrationEBSV2 service is an EBS that provides a request operation that can be performed against the order to sync the customer information by invoking InterfaceCustomerToFulfillmentEBF. This service is invoked as part of the Create Order.
CustomerPartyOrchestrationEBSV2 Operations
InterfaceCustomerToFulfillment
For more information about this EBS, see the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."
The CustomerPartyOrchestrationResponseEBSV2 service is an EBS that provides a response operation that is used to return an InterfaceCustomerToFulfillmentEBF response to InterfaceSalesOrderToFulfillmentEBF. This service is invoked as part of the Create Order.
CustomerPartyOrchestrationResponseEBSV2 Operations
InterfaceCustomerToFulfillmentResponse
For more information about this EBS, see the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."
The InterfaceSalesOrderToFulfillmentEBF service is an enterprise business flow that interfaces a sales order to a back-office fulfillment system. This service is invoked as part of the create order, change order, and cancel order integration flows.
This process performs three high-level actions:
Interfaces customer accounts from the order to the fulfillment system.
The InterfaceSalesOrderToCustomerEBFV2 is invoked for this. This step can be configured so that it can be suppressed.
Creates, changes, or cancels the order in the fulfillment system using the SalesOrderEBSV2 Create or SyncSalesOrderList operations.
Updates the order status in the source order capture system.
This step can be configured so that it can be suppressed.
The InterfaceSalesOrderToFulfillmentEBF is an asynchronous Business Process Execution Language (BPEL) process. Upon completion, it invokes the InterfaceSalesOrderToFulfillmentResponse operation of the SalesOrderOrchestrationResponseEBSV2.
This enterprise business flow (EBF) has five inbound operations. The first initiates the process, and the remaining operations receive the asynchronous callbacks from the other service operations that this process invokes. These are the inbound operations:
InterfaceSalesOrderToFulfillment
InterfaceSalesOrderToCustomerResponse
CreateSalesOrderResponse
UpdateSalesOrderResponse
SyncSalesOrderListResponse
Figure 11-10 illustrates the InterfaceSalesOrderToFulfillmentEBF activity flow:
InterfaceSalesOrderToFulfillmentEBF activity flow diagram
These are the transformations:
ProcessSalesOrderEBM to CreateSalesOrderEBM
ProcessSalesOrderEBM + CreateSalesOrderResponseEBM to UpdateSalesOrderEBM
ProcessSalesOrderEBM to SyncSalesOrderListEBM
ProcessSalesOrderEBM + SyncSalesOrderListResponseEBM to UpdateSalesOrderEBM
The InterfaceSalesOrderToCustomerEBFV2 service is an enterprise business flow that extracts the list of distinct customer accounts, addresses, and contacts from the order and invokes the InterfaceCustomerToFulfillmentEBF service. This service is invoked as part of the Create Order or Sync Revised Order integration flow.
The InterfaceSalesOrderToCustomerEBFV2 enterprise business flow is implemented as an asynchronous request+callback BPEL process.
Figure 11-11 illustrates the InterfaceSalesOrderToCustomerEBFV2 activity flow:
These are the transformations:
ProcessSalesOrderEBM to ProcessCustomerPartyListEBM: this transformation must pass a list of accounts referenced in the order (for example, the order header-level and line-level accounts) and the bill-to and ship-to addresses referenced for each account.
This list must not contain duplicates.
ProcessSalesOrderEBM + ProcessCustomerPartyListResponseEBM to ProcessSalesOrderResponseEBM: this transformation passes through success or error messages.
The ProcessSalesOrderSiebelJMSProducerV2 service guarantees delivery of the ProcessSalesOrder Siebel ABM to the JMS queue. This service is invoked synchronously from the Siebel application workflow. The response indicates whether the message was successfully enqueued. This service is invoked as part of the Create Order integration flow when the version of the Siebel CRM application is 8.0.0.x.
The assumption is that the Siebel order was validated from within the Siebel workflow.
The ProcessSalesOrderSiebelJMSProducerV2 service has a single synchronous request+reply operation: ProcessSalesOrder.
The ProcessSalesOrderSiebelJMSConsumerV2 service dequeues the ProcessSalesOrder Siebel ABM from the JMS queue and asynchronously invokes the ProcessSalesOrderSiebelReqABCSImpl service. This service is invoked as part of the Create Order integration flow when the version of the Siebel CRM application is 8.0.0.x.
The ProcessSalesOrderSiebelJMSConsumerV2 service has an inbound JMS adapter front end, which subscribes to the JMS queue.
The ProcessSalesOrderSiebelJMSConsumerV2 service is implemented as an inbound JMS adapter service in Mediator.
The ProcessSalesOrderSoapMsgSiebelJMSConsumer service dequeues the ProcessSalesOrder Siebel ABM from the JMS queue and asynchronously invokes the ProcessSalesOrderSiebelReqABCSImpl service. This service is invoked as part of the Create Order integration flow when the version of the Siebel CRM application is 8.1.1.x.
The ProcessSalesOrderSoapMsgSiebelJMSConsumer service has an inbound JMS adapter front-end, which subscribes to the JMS queue.
The ProcessSalesOrderSoapMsgSiebelJMSConsumer service is implemented as an inbound JMS adapter service in Mediator.
The ProcessSalesOrderSiebelReqABCSImplV2 service transforms the ProcessSalesOrder Siebel ABM into the canonical ProcessSalesOrderEBM and asynchronously invokes the ProcessSalesOrder operation of the SalesOrderOrchestrationEBSV2 to initiate the InterfaceSalesOrderToFulfillmentEBFV2. This service is invoked as part of the create order, change order, and cancel order integration flows.
In the create order integration flow: As part of the transformation to the ProcessSalesOrderEBM, common IDs for the order, order lines, referenced accounts, referenced ship to and bill to addresses, and contacts are generated and loaded into the cross-reference.
In the revise or change order integration flow: As part of the transformation to the ProcessSalesOrderEBM, common IDs for the order and order lines are regenerated and loaded into the cross-reference to point to new Siebel Row IDs, and referenced accounts, ship to, bill to addresses, and contacts are entered or looked up from the cross-reference.
In the cancel order integration flow: As part of the transformation to the ProcessSalesOrderEBM, common IDs for an order are looked up from the cross-reference.
The ProcessSalesOrderSiebelReqABCSImplV2 service has a single asynchronous request-only operation: ProcessSalesOrder. It accepts the Siebel Order ABM.
The one transformation is ProcessSalesOrderABM to ProcessSalesOrderEBM.
The ProcessSalesOrderSiebelReqABCSImplV2 application business connector service is implemented as an asynchronous request-only BPEL process.
The CreateSalesOrderEbizProvABCSImpl service provides the Oracle EBS implementation for the CreateSalesOrder operation of the SalesOrderEBSV2. This service is invoked as part of the create order integration flow by the CreateSalesOrder operation of the SalesOrderEBSV2.
This service invokes the Process Sales Order PL/SQL API in Oracle EBS using the ProcessSalesOrderEbizAdapter service registered in Mediator.
The CreateSalesOrderEbizProvABCSImpl service is the Oracle EBS provider for the CreateSalesOrder operation of the SalesOrderEBSV2. When complete, this service invokes the CreateSalesOrderResponse operation of the SalesOrderResponseEBSV2.
These are the transformations:
CreateSalesOrderEBM to ProcessSalesOrder ABM.
ProcessSalesOrderResponse ABM to CreateSalesOrderResponseEBM.
The CreateSalesOrderEbizProvABCSImpl application business connector service is implemented as an asynchronous BPEL process.
The SyncSalesOrderEbizProvABCSImpl service provides the Oracle EBS implementation for the SyncSalesOrderList operation of the SalesOrderEBSV2. This service is invoked as part of the create order, change order, and cancel order integration flows through the SyncSalesOrderList operation of the SalesOrderEBSV2.
This service in turn invokes the Process Sales Order PL/SQL API in Oracle through the ProcessSalesOrderEbizAdapter service registered in Mediator.
These are the transformations:
SyncSalesOrderListEBM to ProcessSalesOrder ABM
ProcessSalesOrderResponse ABM to SyncSalesOrderListResponseEBM
The SyncSalesOrderEbizProvABCSImpl application business connector service (ABCS) is implemented as an asynchronous BPEL process.
The UpdateSalesOrderEbizEventConsumer service subscribes to the oracle.apps.ont.genesis.outbound.update business event in Oracle EBS. After the event is picked up from Oracle AQ, it is passed to the UpdateSalesOrderEbizReqABCSImpl service.
This set of fields uniquely identifies the event:
HEADER_ID
LINE_ID
HDR_REQ_ID
LIN_REQ_ID
CHANGE_TYPE
HOLD_SOURCE_ID
ORDER_HOLD_ID
This service is an inbound AQ adapter service and does not have a public interface. The service is initiated by Mediator when the subscription event occurs.
This service is implemented as an inbound-to-SOA Oracle Apps Event adapter service in Mediator.
The UpdateSalesOrderEbizReqABCSImpl service fetches the Oracle Order ABM from GetSalesOrderEbizAdpater based on event payload. For any Order Line whose status is Shipped, the OrderLineShippingDetailsABM is fetched from the GetSalesOrderLineShippingDetailsEbizAdapter. The combined Oracle order ABMs are transformed into UpdateSalesOrderEBM and then the UpdateSalesOrderEbizReqABCSImpl invokes the UpdateSalesOrder operation of the SalesOrderEBSV2.
This service has one asynchronous request operation that accepts the Oracle event ABM.
These are the transformations:
WF_EVENT_T_msg à args_in_msg (GetSalesOrderEbizAdpater)
Args_out_msg (GetSalesOrderEbizAdpater) à args_in_msg (GetSalesOrderLineShippingDetailsEbizAdapter)
Args_out_msg (GetSalesOrderEbizAdpater) + args_out_msg (GetSalesOrderLineShippingDetailsEbizAdapter) à UpdateSalesOrderEBM
The UpdateSalesOrderEbizReqABCSImpl service is implemented as an asynchronous fire-and-forget BPEL process.
The UpdateSalesOrderSiebelProvABCSImpl service is the Siebel provider ABCS for the UpdateSalesOrder operation of the SalesOrderEBS. This service invokes the Siebel Upsert Order web service or the Upsert Quote web service, depending on the nature of the update and type of order (for example, sales order or RMA or quote).
This service implements the UpdateSalesOrder operation defined in the SalesOrderEBSV2 service. This operation is an asynchronous request operation that accepts the UpdateSalesOrderEBM. After completion, this service invokes the UpdateSalesOrderResponse operation of the SalesOrderResponseEBSV2.
These are the transformations:
UpdateSalesOrderEBM to UpsertOrderABM
UpdateSalesOrderEBM to UpsertQuoteABM
UpsertOrder Response ABM to UpdateSalesOrderResponseEBM
UpsertQuote Response ABM to UpdateSalesOrderResponseEBM
The ProcessSalesOrderEbizAdapter service is an Oracle EBS Adapter service registered in Mediator. This adapter service exposes the Oe_Inbound_Int.Process_Order_25 PL/SQL. This service is the interface through which an order is created in Oracle EBS and is invoked by the CreateSalesOrderEbizProvABCSImpl / SyncSalesOrderEbizProvABCSImpl as part of the create order, change order, and cancel order integration flows.
The ProcessSalesOrderEbizAdapter service exposes the Process Order operation of the PL/SQL API. This operation is a synchronous request+reply operation. By registering this adapter service in Mediator, Mediator exposes a Simple Object Access Protocol (SOAP) binding that is used in this integration to invoke the service from the CreateSalesOrderEbizProvABCSImpl and SyncSalesOrderEbizProvABCSImpl.
The service is implemented as an EBS adapter service in Mediator.
The GetSalesOrderEbizAdpater service is an Oracle EBS Adapter service registered in Mediator. This adapter service exposes the Oe_Outbound_Int.Sync_Order25 PL/SQL API delivered as part of EBS12.1.1. This service is invoked as part of the Update Order flow initiated when an order update event is launched in Oracle EBS.
This set of fields uniquely identifies the event:
HEADER_ID
LINE_ID
HDR_REQ_ID
LIN_REQ_ID
CHANGE_TYPE
HOLD_SOURCE_ID
ORDER_HOLD_ID
The GetSalesOrderLineShippingDetailsEbizAdapter service is an Oracle EBS Adapter service registered in Mediator. This adapter service exposes the WSH_INTEGRATION.Get_Delivery_Detail_attributes PL/SQL API delivered as part of EBS 11.5.10 and 12.1.
This service is invoked as part of the update order flow initiated when an order line status becomes shipped. This operation is a synchronous request and reply operation. Because this adapter service is registered in Mediator, Mediator exposes a SOAP binding that is used in this integration to invoke the service from the UpdateSalesOrderEbizReqABCSImpl.
|
 Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
