21 Understanding the Process Integration for Order Fallout Management

This chapter describes the process integration for order fallout management and related order fallout concepts.

About the Process Integration for Order Fallout Management

The process integration for Order Fallout Management helps you detect order fallout and notify the appropriate person so that you can correct failed orders. Oracle Application Integration Architecture (Oracle AIA) handles order exceptions with a detection and notification process that uses trouble ticketing for notification and tracking.

You can use Oracle AIA or Oracle Communications Order and Service Management (OSM) to initiate the creation of trouble tickets in Siebel CRM.

About the Order Fallout Management Business Flows

The process integration for Order Fallout Management includes the following business flows:

Create Trouble Ticket from Oracle AIA:
- Used when the request to create a trouble ticket is initiated by Oracle AIA for messages with the JMS Correlation ID of AIA_ORDERFALLOUT_TTS.
- Enabled by the Order to Cash for Siebel CRM pre-built integration options.
See "About the Create Trouble Ticket from Oracle AIA Business Flow" for more information.
Create and Manage Trouble Ticket from OSM.
- Used when the request to create a trouble ticket is initiated by OSM for messages with the JMS Correlation ID of AIA_ORDERFALLOUT_CFS.
- Enabled by the Order to Cash for Siebel CRM and Order to Cash for OSM pre-built integration options.
See "About the Create and Manage Trouble Ticket from OSM Business Flow".

About the Create Trouble Ticket from Oracle AIA Business Flow

The Create Trouble Ticket from Oracle AIA business flow provides trouble ticketing when OSM is not the central fulfillment system and is not used for order fulfillment and fallout management. In this business flow, the integration provides services and artifacts to handle order fallout detection and notification.

The integration can also create trouble tickets in Siebel CRM when an order fails and an error is detected by the Oracle AIA error handler. Because the integration creates a trouble ticket for every fault message notification, you must model your processes to generate only one notification for each order failure.

Figure 21-1 illustrates the Create Trouble Ticket from Oracle AIA business flow at a high level.

Figure 21-1 Creating Trouble Tickets from Oracle AIA

Surrounding text describes Figure 21-1 .

When an error occurs in an edge application, such as in BRM while synchronizing customers or initiating billing, the edge application sends an error notification back to the ABCS that provided the order data. The ABCS sends a fault message to the Oracle AIA error handling framework.

When an error occurs in an Oracle AIA service, such as an ABCS or EBS, the service sends a fault message to the Oracle AIA error handling framework.

The Oracle AIA error handling framework initiates the Oracle AIA services that create trouble tickets in Siebel CRM.

About the Create and Manage Trouble Ticket from OSM Business Flow

The Create and Manage Trouble Ticket from OSM business flow provides trouble ticketing when OSM is the central fulfillment system. When you install the Order to Cash for OSM pre-built integration option, the integration automatically uses OSM to manage order fallout.

Figure 21-2 illustrates the high-level process flow involved in using OSM for order fallout management.

Figure 21-2 Creating Trouble Tickets from OSM

This figure is described in the following text.

When an error occurs in an Oracle AIA service, such as an ABCS or EBS, the service sends a fault message to the Oracle AIA error handling framework, which sends the message to OSM COM.

When OSM COM receives errors from Oracle AIA or processing errors from within OSM, OSM COM manages the fallout with OSM-internal fallout management mechanisms, including compensation and orchestration of fallout orders. As part of fallout management, OSM can create trouble tickets and send them to Siebel CRM through Oracle AIA.

The integration creates trouble tickets on a per-order or per-application basis for failed orders that have been submitted from Siebel CRM as follows:

The failure of different orders in the same application generates different trouble tickets.
The failure of the same order in a different application generates a different trouble ticket. For example, if an order fails while initiating billing in BRM, and the same order fails while provisioning a service in OSM, the integration creates two trouble tickets for that order: one for the failure in BRM and one for the failure in OSM.
Multiple order line item failures for the same order in the same application generate only one trouble ticket with the additional order line item failure information appended. For example, if three line items on an order fail during the service design phase of provisioning in OSM, the integration creates only one trouble ticket containing all three order line failures.

This business flow operates under the following constraints:

To cancel a failed order as part of error correction, you must cancel the order from OSM rather than Siebel CRM.
You must ensure that any custom process flow that creates an order failure notification creates only one notification for each order failure.
When an order revision from Siebel CRM 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. You must manually close the trouble ticket for the revision that failed upon arrival.

About Order Fallout Management for Different Error Types

Oracle AIA manages order fallout for the following error types:

System errors: Errors caused by infrastructure outages. See "About Order Fallout Management for System Errors".
Business errors: Errors caused by missing data. See "About Order Fallout Management for Business Errors".
Service: Errors caused by failed Oracle AIA services. See "About Order Fallout Management for Service Errors".

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 21-3 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 21-3 System Error Handling in Order Update Flow

The figure is described in the following text.

The figure illustrates the following process:

The UpdateSalesOrderSiebelCommsJMSConsumer consumer picks up a message from the AIA_UPDSO_OUT_SIEBEL_JMSQ queue and sends it to the UpdateSalesOrderSiebelCommsProvABCSImpl provider service.
The provider service attempts to send the message to Siebel CRM, but Siebel CRM is unavailable.
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.
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.
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.
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:

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.
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.
Click the Deployed Composites tab.
Locate any of the following consumer services that have Retired in the Mode column:
- UpdateSalesOrderSiebelCommsJMSConsumer
- SyncItemCompositionListSiebelCommsJMSConsumer
- ProductOptimizedSyncPriceListListSiebelCommsJMSConsumer
- ProcessFulfillmentOrderBillingAccountListSiebelCommsJMSConsumer
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:

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

Search for the following line:

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

Change aia-custom-java to aia-no-action. For example:
```
<retryFailureAction ref="aia-no-action"/>
```
Save and close the file.
Upload the file to the Oracle Metadata Services repository. See Oracle AIA Installation Guide for more information about uploading changed files to the Oracle Metadata Services repository.

About Order Fallout Management for Business Errors

Business failures are caused by business reasons unrelated to the Oracle AIA infrastructure. For example, a sales order that is missing critical data fails while being sent to Oracle Communications Billing and Revenue Management (BRM). Because the error occurs in the original message, you must revise the order in Siebel CRM to correct the error, then resubmit the order.

About Order Fallout Management for Service Errors

If an error occurs during an Oracle AIA service call, such as when an application business connector service (ABCS) calls an integrated application, the following occurs:

Detecting order fallout: An error occurs within an ABCS, it creates an error message, and the Oracle AIA error handling framework uses the message to create an enhanced fault message. See "About Order Fallout Detection" for more details.
Notifying someone of the fallout: For orders submitted from Siebel CRM, Oracle AIA creates a trouble ticket in Siebel CRM and Siebel CRM assigns the trouble ticket to a user and notifies the user. See "About Order Fallout Notification" for more details.
Correcting orders: The notified user resolves the issue and either resubmits the order or cancels it. See "About Order Correction" for more details.

About Order Fallout Detection

When an error occurs within any of the Oracle AIA order services, the ABCS creates an error message. The Oracle AIA Error Handling framework detects the error message and uses it to create an enhanced fault message that contains the following 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. 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.

The framework publishes the enhanced fault message to the AIA Error JMS topic, where the error handling listener picks it up. The listener submits the fault message to the order fallout services to create a trouble ticket in Siebel CRM.

Figure 21-4 illustrates order fallout detection when Oracle AIA initiates trouble ticket creation. When OSM initiates trouble ticket creation, the Oracle AIA error handling framework sends a notification to OSM, and OSM begins the process of notifying Siebel CRM.

Although the order can fail in any of the application tiers shown in the figure, this chapter discusses order failure only within Oracle AIA. Other applications and systems are outside the scope of the process integration for order fallout management.

Figure 21-4 Detection Flow from Oracle AIA for Order Fallout

Description of ''Figure 21-4 Detection Flow from Oracle AIA for Order Fallout''

About Order Fallout Notification

Siebel CRM handles order fallout notification. After Oracle AIA sends an enhanced fault message to Siebel CRM and creates a trouble ticket using a web service operation, Siebel CRM processes the trouble ticket and assigns it to a fallout user according to the Siebel CRM assignment rules. Siebel CRM can create and send notification to the fallout user, who can then investigate the trouble ticket to correct the issue.

Figure 21-5 illustrates the process for order fallout notification.

Figure 21-5 Order Fallout Notification Flow

This figure is described in the preceding text.

About Order Correction

After the trouble ticket is created in Siebel CRM and assigned to a fallout user, the fallout user can investigate the failure and correct the error to resolve the trouble ticket.

To correct errors in the base order, submit a revision order with updated data. The OSM Order to Activate cartridge closes any trouble tickets created to report the order fallout and fulfills the revision order.

Figure 21-6 illustrates the steps a fallout user takes to correct errors in a base order.

Figure 21-6 Siebel CRM Correction Flow for Order Fallout

Description of ''Figure 21-6 Siebel CRM Correction Flow for Order Fallout''

To correct errors in the data from participating edge applications (such as BRM, Siebel CRM, or an inventory or activation system), update the data in the edge application and resume the order OSM in the central order management role (OSM COM).

For example, if an order fails because of bad billing profile information, correct the billing profile information in Siebel CRM. Oracle AIA synchronizes the changed information to BRM, and you can resume the order in OSM.

For errors that occur and are corrected in local fulfillment systems, submitting a revision order from Siebel CRM does not correct the error or close the trouble tickets. Because the revision order is identical to the base order, OSM ignores the revision. You must resume the order from OSM.

Figure 21-7 illustrates process of correcting order data errors in edge applications. The figure shows an option for updating the order status from the edge application, which sends the order update through Oracle AIA, and an option for updating the order status directly in OSM.

Figure 21-7 Local Correction Flow

How Oracle AIA Error Handling Framework Captures Faults

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

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

Figure 21-8 Capturing the Fault Sequence Diagram

This figure is described in the surrounding text.

The integration captures faults as follows:

An edge application, such as BRM, encounters a processing error and sends the error to the Oracle AIA ABCS.
The ABCS creates an enhanced fault message from the error message and sends it to the Oracle AIA error handling framework.
The error handling framework sends the enhanced fault message to the error JMS topic.
If needed, the Oracle AIA error handling listener subscribed to the topic picks up the fault message.
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.
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 21-9 illustrates how the Oracle AIA Error Handling Framework submits an order failure notification to the Oracle AIA Error Topic.

Figure 21-9 Creation and Submission of a Fault Message to the Oracle AIA Error Topic

Description of ''Figure 21-9 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 Business flow, as shown in Figure 21-10.

Figure 21-10 Initiating Appropriate Create Trouble Ticket Flow

This image is described in the following text.

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

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.
The Oracle AIA common error handler posts all of the enriched fault messages to the AIA_ERROR_TOPIC topic.
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.
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 business 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 business 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.

Extending Fault Messages to Capture Order Fallout Information

The process integration for Order Fallout Management uses the Oracle AIA error handling framework to capture order failure notifications when an ABCS or an Oracle AIA service fails.

For faults that occur within Oracle AIA, the fault messages contain all the required details of the failed order and do not require enrichment by the Oracle AIA error handling framework.

For faults that occur in edge applications, you must extend the messages to capture additional order failure information. See the discussion of extending fault messages in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for information about extending error handling.

Table 21-1 and Table 21-2 list the additional fields that you must add to the fault messages to capture order failure information.

Table 21-1 lists the order header-level fields to include in the fault messages.

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 from the edge application or Oracle AIA service to the process integration for Order Fallout Management.

Table 21-2 lists order line item level fields to include in the fault messages. when the Oracle AIA service or the edge application 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 are not required.

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

To extend error handling, at a high level:

Extend the Oracle AIA fault message to capture the additional information in Table 21-1 and Table 21-2.
Extend the common error handler to:
- Identify when a fault message is related to order failures.
- Stamp the error type in the fault message as a JMSCorrelationID and invoke the appropriate fault extension handlers (in case of a partner link fault).
- Publish to the AIA Error JMS Topic.
Create 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).
Create the AIACOMOrderFalloutNotificationConsumer listener for the Order fallout queue 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.

Exception Handling

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.