| Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management Release 11.3 Part Number E37675-02 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the process integration for Order Fallout Management and discusses capturing faults, order fallout management process integration business flows, and how to extend fault messages to capture order fallout information.
Orders that have been submitted in Siebel customer relationship management (Siebel CRM) to reflect a customer's intent to use or purchase services provided by a communications service provider (CSP) are passed to downstream systems for fulfillment and provisioning. Because an order is likely to traverse multiple stages before completion, it may fail during the process. The process integration for order fallout management provides a comprehensive, delivered solution that handles such exceptions by implementing a detection and notification process, making the Oracle Communications Order to Cash Integration Pack more robust. Order fallout uses trouble ticketing for notification and tracking of order failures.
The order fallout process is broadly categorized into these three subprocesses:
Order Fallout Detection
Order Fallout Notification
Order Correction
If an error occurs at one Oracle Application Integration Architecture (Oracle AIA) service calls (enterprise business service (EBS), application business connector service (ABCS), and so on), then the service creates an error by invoking the services provided by the Oracle AIA Error Handling Framework to generate a fault message that contains information about the error and also order-specific information that can then be used to create a trouble ticket. The Oracle AIA order fallout management services are then called to create a trouble ticket in Siebel CRM using a Siebel CRM web service. After the trouble ticket is available within Siebel CRM, an order fallout specialist or customer service representative (CSR) opens the trouble ticket and addresses it either by resubmitting the order after correcting it, or by canceling the order.
See Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack for more information about the Oracle AIA Error Handling Framework.
During the execution of the integration processes, an error may be thrown because of either a system failure or a business failure.
System failures include, but are not limited to, the participating application being down, the network going down, or the Fusion Middleware (FMW) engine going down. Business failures are caused by business reasons and have nothing do with the infrastructure. For example, missing required data is a business error.
The main difference between a system error and a business error is that, for a system error, there is nothing inherently wrong with the original message and can therefore be resubmitted as is for processing. However, for a business error, the original message is flawed (data missing, bad data, and so on) and cannot be resubmitted and reprocessed as is. For business errors, the message must be corrected in the source system and then resubmitted for processing. (For example, a sales order message fails while being interfaced to Oracle Communications Billing and Revenue Management (BRM) because it has bad data. In this case the sales order must be revised and resubmitted from Siebel CRM to Oracle Communications Order and Service Management (OSM) for fulfillment, and then from OSM to BRM for billing fulfillment.
As part of order fallout management, it only deals with business errors. For system errors, since the message can be retried as is, it is outside the scope of order fallout management.
See "Configuring the Process Integration for Order Fallout Management" for more information about how to configure the process integration for order fallout management.
The order can fail in any of the application tiers shown in Figure 21-1. However, this chapter discusses order failure only within Oracle AIA. Other applications and systems are outside the scope of this solution.
Figure 21-1 illustrates the detection subprocess within the order fallout process.
When an error occurs within any of the order services, the ABCS (in this case) creates an error in Oracle AIA that is detected by the Oracle AIA Error Handling framework. The framework then creates an enhanced fault message that contains information about the fault and the failed order and publishes it to the AIA Error Java Message Service (JMS) topic. The Oracle AIA Order Fallout Management Error Handling Listener detects the AIA Error Handling Enhanced Fault Message, picks up the message from the queue, and submits it to the order fallout function within Oracle AIA for further processing (creation of trouble ticket).
The AIA Enhanced Fault Message has some following key error and order failure information:
Faulting Service
Error Code
Error Severity
Error Text
Time Of Failure
Order ID
Order Number
Order Originating System Code
Account ID
Account Name
See "Extending Fault Messages to Capture Order Fallout Information" for more information about extending fault messages.
Figure 21-2 illustrates the notification subprocess within the order fallout process.
After the trouble ticket is created in Siebel CRM, the request is assigned to a fallout specialist by an assignment rule set in Siebel CRM. The fallout specialist can then log in to the system, pick up the trouble ticket from the queue, and resolve the ticket. After the specialist identifies the failure aspects of the order, they can create a new order to correct the failed order and then submit it for processing.
Order fallout can be caused by one of the following two categories of errors:
Errors that can only be resolved by changing the order.
To resolve this type of error, the order fallout specialist must submit a revision order to recover the order from fallout. The OSM Cartridge for Oracle AIA closes any trouble tickets created to report the order fallout and proceed with fulfilling the revision order.
Errors related to data setup in local fulfillment systems, such as bad inventory data.
To resolve this type of error, the order fallout specialist must correct the cause of the error in the local fulfillment system and resume the order from OSM in the central order management role (OSM COM).
Submitting a revision order for this type of error does not recover the order from fallout because the revision order will be identical to the base order and therefore ignored by OSM.
Note:
Siebel CRM and BRM act as local fulfillment systems when participating in the fulfillment of an order. For example, if there is a bad billing profile causing an order to fail, the error must be corrected by fixing the billing profile in Siebel CRM, which triggers synchronization of the corrected billing profile to BRM. The order then resumes in OSM.Figure 21-3 illustrates the Siebel CRM correction flow subprocess within the order fallout management process.
Figure 21-4 illustrates the local correction flow subprocess within the order fallout management process that must take place to undo, compensate, or otherwise fix changes that were committed locally within a fulfillment system for a failed order.
The Oracle AIA Error Handling Framework is used to capture faults across order processing.
Figure 21-5 illustrates the interactions taking place when an order failure is detected by a fulfillment system, such as provisioning and BRM.
The Oracle AIA Error Handling Framework:
Allows custom enrichments to the fault message.
Publishes the enriched fault message to the AIA Error topic.
Provides a mechanism by which the Order Fallout Listener process picks only the messages that are relevant to the order failure.
Figure 21-6 illustrates how the Oracle AIA Error Handling Framework is leveraged to submit an order failure notification to the AIA Error Topic.
The custom listener selectively picks up the messages from the AIA Error Topic and initiates the appropriate Create Trouble Ticket Business flow, as shown in Figure 21-7.
The flow proceeds as follows:
All of the enriched fault messages with the order failure details are posted to the AIA Error Topic (AIA_ERROR_TOPIC).
Messages that are specific to order failure are stamped with a JMS Correlation ID like AIA_ORDERFALLOUT.
The AIAOrderFalloutJMSBridgeService consumes the messages from the AIA_ERROR_TOPIC with JMSCorrelationID like AIA_ORDERFALLOUT and publishes them to the AIA_ORDERFALLOUT_JMSQ queue. (This queue is introduced to persist the order failure messages and ensure the messages are not lost if there are errors.)
Messages that are specific to order failure have a JMS Correlation ID of either AIA_ORDERFALLOUT_TTS or AIA_ORDERFALLOUT_CFS, depending on whether the trouble ticket is created directly from Oracle AIA or the order failure notification is sent to OSM CFS.
See "Using Error Type to Control Response to Order Fallout" for more information on how to set up the seed data so that the trouble ticket is created from either Oracle AIA or OSM.
The AIACOMOrderFalloutNotificationJMSConsumer picks up the fault messages and initiates the appropriate Create Trouble Ticket business flow. For the Create Trouble Ticket business flow:
If the JMSCorrelationID = AIA_ORDERFALLOUT_TTS, the trouble ticket is directly created from Oracle AIA. (This is the default configuration.)
If the JMSCorrelationID = AIA_ORDERFALLOUT_CFS, the order failure notification is sent to OSM and OSM initiates the Create Trouble Ticket request.
The process integration for order fallout management provides the following integration flows, which enable the Create Trouble Ticket from Oracle AIA and the Create and Manage Trouble Ticket from OSM business flows.
Create Trouble Ticket from Oracle AIA
This business flow is enabled by either the Oracle Communications Order to Cash for Siebel CRM and BRM Pre-Built Integration option or the Oracle Communications Order to Cash Siebel CRM, OSM, and BRM Pre-Built Integration option.
For this business flow, the JMS Correlation ID = AIA_ORDERFALLOUT_TTS and the request to create a trouble ticket is initiated from Oracle AIA.
The following integration flow enables this business flow:
Creating a trouble ticket in Siebel CRM integration flow
Create and Manage Trouble Ticket from OSM
This business flow is enabled by either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash Siebel CRM, OSM, and BRM Pre-Built Integration option.
For this business flow, the JMS Correlation ID = AIA_ORDERFALLOUT_CFS and the request to create a trouble ticket is initiated from OSM.
The following integration flows enable this business flow:
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
The Create Trouble Ticket from Oracle AIA business flow provides an alternative solution for order fallout management in which OSM is not the central fulfillment system and is not used for order fulfillment and fallout management. The approach adopted for this alternate solution assumes that as delivered, the integration handles a subset of order fallout management functionalities by providing delivered services and artifacts that handle order fallout detection and notification.
Also discussed is the functional design required to implement trouble ticket creation in Siebel CRM by the integration when an order fails and an error is detected by the Oracle AIA Error Handler.
Figure 21-8 illustrates the high-level flow of order fulfillment and order fallout management within the capacity of the integration. As illustrated in the diagram, orders can fail at various stages while in process.
Note:
Figure 21-8 shows only the interactions for order fallout. Additional interactions are part of the order fulfillment.This is a high-level description of the flow:
The fault message containing the failed order information is created and submitted within an Oracle AIA service (EBS or application business service (ABS)). If the order fails within a fulfillment application, this returns an error to its ABCS, which produces the fault message.
The fault message is then submitted to the AIA Common Error Handler, which recognizes that the fault message is related to an order failure and posts it to the AIA Error JMS Topic (AIA_ERROR_TOPIC) with JMSCorrelation set to AIA_ORDERFALLOUT_TTS (as indicated in the ERROR_TYPE column in the AIA_ERROR_NOTIFICATION page).
The Oracle AIA order fallout listener (AIAOrderFalloutJMSBridgeService) picks up the fault message from the AIA Error Topic and pushes it to the Fallout Queue (AIA_ORDERFALLOUT_JMSQ)
The AIACOMOrderFalloutNotificationConsumer process picks up the fault message from the Fallout Queue and invokes Oracle AIA order fallout services to create the order failure notification within Oracle AIA.
See "Configuring Oracle AIA Processes for Error Handling and Trace Logging," Extending Error Handling and Extending Fault Messages in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information about extending error handling.
These are the assumptions and constraints for the Create Trouble Ticket from Oracle AIA business flow:
The order fallout management functionality manages orders that fail after being submitted by Siebel CRM.
One trouble ticket is created in Siebel CRM for every fault message notification. The process flow must ensure that no multiple notifications are generated for the same order failure.
Oracle AIA or OSM can initiate the creation of trouble tickets. This is configurable. Installing either the Oracle Communications Order to Cash for Siebel CRM and OSM Pre-Built Integration option or the Oracle Communications Order to Cash for Siebel CRM, OSM, and BRM Pre-Built Integration option automatically configures order fallout to occur in OSM.
With the combination of Siebel CRM and OSM:
Trouble tickets are created in Siebel CRM from OSM on a per-order or per-system basis. The failure of different orders in the same system generates different trouble tickets, and the failure of the same order in a different system generates a different trouble ticket, but multiple order line item failures for the same order in the same system generates only one trouble ticket. The additional order line item failure information is appended.
If the cancellation of a failed order is required as part of the recovery flow, the fallout specialist should cancel the order from OSM.
Any custom process flow that invokes the creation of an order failure notification must ensure that no multiple notifications are generated for the same order failure.
Figure 21-9 illustrates the high-level process flow involved in using OSM for order fallout management. It identifies the possible sources of failed orders, capturing these faults using the Oracle AIA Error Handling Framework and the creation of the trouble ticket from OSM in Siebel CRM for the failed order:
The assumptions and constraints for the Create and Manage Trouble Ticket from OSM business flow are as follows:
Order fallout management functionality handles orders that fail after being submitted by Siebel CRM.
When an order revision fails upon arrival in OSM, a new trouble ticket for the revision is created, and any existing trouble ticket for the base order is preserved. In this case, the trouble ticket acts as an important notification of the failed on arrival condition. The side effect is that the fallout specialist must manually close the trouble ticket for the revision that failed upon arrival.
The order fallout management solution leverages the existing Oracle AIA Error Handling Framework to capture order failure notifications when an ABCS or an Oracle AIA service ends due to error.
A fault message is created when an order fails in an AIA service, an ABCS, or in the fulfillment system. The fault message is enhanced with additional information to capture pertinent data about the order failure.
The messages used by the Oracle AIA Error Handling Framework to capture the errors must be extended to capture order failure information. The following two tables describe additional fields that must be added to the Oracle AIA error handling messages to capture order fallout information.
If a fault happens within Oracle AIA, the fault message has all the required details of the failed order and does not require additional enrichment by the Oracle AIA Error Handling Framework. In this case, the common error handler stamps the correlation ID to the fault message and publishes it to the Error Topic (JMS Correlation ID is set to the value indicated in the AIA Error Notification table) so that it can be uniquely identified as an order fallout fault message.
See the discussion of extending fault messages in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information about extending error handling.
Table 21-1 lists the order header-level data that is passed from a fulfillment system or Oracle AIA service to the Order Fallout Management functionality over the Oracle AIA Error Handling Framework (order header-level fields).
Table 21-1 Order Header-Level Data
| Field Name | Type | Description | Source | Optional |
|---|---|---|---|---|
|
Order Originating System Code |
ID |
The system code of the Siebel CRM system from which the order was placed. It is required to cross-reference the IDs back to the appropriate Siebel CRM IDs. |
Oracle AIA service |
No |
|
Sales Order Number |
Alphanumeric |
Alphanumeric identifier for the sales order number (Siebel CRM value). |
Siebel CRM |
Yes |
|
Sales Order Revision Number |
Numeric |
Numeric field storing the sales order number (Siebel CRM value). |
Siebel CRM |
Yes |
|
SalesOrderID |
ID |
Siebel CRM Sales Order ID. Required to create trouble tickets for the orders that fail even before hitting the central fulfillment system. |
Siebel CRM |
Yes |
|
Account Name |
AlphaNumeric |
AlphaNumeric value identifying the Siebel CRM account name. |
Siebel CRM |
Yes |
|
Account ID |
ID |
Siebel CRM Account ID. Required to create trouble tickets for the orders that fail even before hitting the central fulfillment system. |
Siebel CRM |
Yes |
|
SalesOrderID (Common) |
ID |
Common Order ID. (Required when Oracle AIA creates the trouble tickets). |
Oracle AIA service |
No |
|
AccountID (Common) |
ID |
Common Account ID. |
Oracle AIA service |
Yes |
|
Order ID |
ID |
Alphanumeric identifier for the order. Assigned by fulfillment system to the order. The fulfillment system uses it to correlate the order back to the common order ID received for the original order. The common order ID is then mapped to the Siebel order ID by the Siebel ABCS. |
Fulfillment System |
No |
|
Order Number |
AlphaNumeric |
User-friendly identifier for the order in the fulfillment system. |
Fulfillment System |
Yes |
|
ProductID |
AlphaNumeric |
Alphanumeric identifier for the product used for the failed line or the product for the first order line in case of multiple line failures. |
Siebel CRM or Oracle AIA service |
Yes |
|
Fulfillment System of Failure for Order |
LOV |
Part of the enterprise business object (EBO) header. Set to the fulfillment system in which the order failed. The Oracle AIA identifier for the fulfillment system is used. |
Fulfillment system of Failure or Oracle AIA service |
No |
|
Service of Failure / FailureSubSystem |
LOV |
Identifies the Oracle AIA service, web service, application programming interface (API), or SubSystemCode (if available) where the order failed. |
Fulfillment System of failure or Oracle AIA service |
Yes |
|
Message |
Alphanumeric |
Used for the message (error, warning, or other). It can also be used to return notification to customers or other systems. Not to be confused with the original input order message. |
Fulfillment System of failure or Oracle AIA Service |
Yes |
|
Error Code |
Alphanumeric |
Used to return the error code from the downstream fulfillment system (if any). |
Fulfillment System of failure or Oracle AIA service |
No |
|
Error Severity |
LOV |
Used to return the error severity from the downstream fulfillment system (if any). |
Fulfillment System of failure or Oracle AIA service |
Yes |
|
Processing Number |
ID |
Identifier of the job ID assigned in case of batch or bulk orders. |
Siebel CRM |
Yes |
|
Processing Type Code |
Code |
Code to identify the job type. |
Siebel CRM |
Yes |
|
Processing Quantity |
Quantity |
Job cardinality - Total number of orders within the job. |
Siebel CRM |
Yes |
See "Guidelines for Ensuring that Oracle AIA Processes are Fallout-Compliant" for more information about how to pass this information.
This table shows the order fallout information passed from a fulfillment system or Oracle AIA service to the order fallout management functionality over the Oracle AIA Error Handling Framework (order-line item-level fields). This is supplied only if the Oracle AIA service or the fulfillment system identifies a particular order line item as responsible for the order failure. For system faults caused by network issues or system unavailability, the order lines may not actually add value to the trouble ticket and in those cases you need not populate these fields.
Table 21-2 Order-Line Item-Level Data
| Field Name | Type | Description | Source | Optional |
|---|---|---|---|---|
|
Order Line Item ID |
ID |
Unique identifier for the order item. |
Siebel CRM |
No |
|
Message |
Alphanumeric |
Used for error message. It can also be used to return notification to customers or other systems. |
Fulfillment system of failure or Oracle AIA service. |
Yes |
|
Error Code |
Alphanumeric |
Used to return the error code from the downstream fulfillment system (if any). |
Fulfillment system of failure or Oracle AIA service. |
No |
|
Error Severity |
Alphanumeric |
Used to return the error severity from the downstream fulfillment system (if any). |
Fulfillment system of failure or Oracle AIA service. |
Yes |
|
StatusContext |
LOV |
Used to capture status-related display information or status-related information that is product-dependent. It can also be used to capture the current milestone within the provisioning system for the service associated with the order item. |
Fulfillment system of failure or Oracle AIA service. |
Yes |
|
FailureSubSystemCode |
LOV |
Subsystem code or API where the order line has failed. Applicable for participating applications. If the fault is within Oracle AIA, the service which faulted is assumed as the subsystem of failure. |
Fulfillment system of failure or Oracle AIA service. |
Yes |
The overall solution includes:
Extending the Oracle AIA fault message to be able to capture the additional information identified in the tables described previously.
Extending the common error handler to be able to:
Identify when a fault message is related to order failures.
Stamp the error type in the fault message as a correlation ID and invoke the appropriate fault extension handlers (in case of a partner link fault).
Publish to the AIA Error JMS Topic.
Creating the Oracle AIA order fallout listener (AIAOrderFalloutJMSBridgeService), which:
Listens to all messages published to the AIA Error JMS Topic.
Picks up the messages that are specific to order fallout by looking at the correlation ID that contains the error type stamped by the Oracle AIA Common Error Handler.
Persists the fault message into a fallout queue (AIA_ORDERFALLOUTJMSQ).
Creating a listener to the Order Fallout Queue, AIACOMOrderFalloutNotificationConsumer that routes the fault message appropriately to the process integration for order fallout management to create the trouble ticket.
See "Configuring Oracle AIA Processes for Error Handling and Trace Logging," Extending Error Handling in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information about extending error handling.
The types of operation conducted by the AIA Order Fallout Listeners are quite straightforward; therefore, the exception handling is also straightforward: If an error occurs while the listeners are preparing the message for the invocation of the Oracle AIA service, then a standard Oracle AIA Error Handling Framework notification is posted to the Oracle AIA Error Handling Framework.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
