21 Understanding the Process Integration for Order Fallout Management

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.

Overview of the Process Integration for Order Fallout Management

Siebel customer relationship management (Siebel CRM) passes submitted orders to downstream systems for fulfillment and provisioning. Because an order passes through multiple systems before completion, it may fail during the process. The process integration for Order Fallout Management handles order exceptions with a detection and notification process that uses trouble ticketing for notification and tracking.

The order fallout process is composed of the following subprocesses:

  • Order fallout detection

  • Order fallout notification

  • Order correction

The process integration for Order Fallout Management handles order fallout due to errors at the AIA service level and the business level.

About Order Fallout Management for AIA Service Errors

If an error occurs at one (Oracle AIA) service calls, such as an application business connector service (ABCS), then the service creates an error by invoking the Oracle AIA Error Handling Framework services to generate a fault message that contains order-specific information and information about the error 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) addresses the trouble ticket 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.

About Order Fallout Management for Business and System Errors

During the execution of the integration processes, an error may be thrown because of either a business failure or a system failure.

Business failures are caused by business reasons unrelated to the infrastructure. For example, a sales order fails while being sent to Oracle Communications Billing and Revenue Management (BRM) because of missing data. Because the error occurs in the original message, you must revise the order in Siebel CRM to correct the error, then resubmit the order. The process integration for Order Fallout Management handles business errors.

System failures can include the participating application, network, or Fusion Middleware engine being unavailable. Because system errors occur when there is nothing inherently wrong with the original message, you can resubmit the same message for processing. Because you can simply resubmit the message, the process integration for Order Fallout Management does not handle system errors.

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.

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-1 illustrates this subprocess. 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-1 Detection Flow for Order Fallout

Description of Figure 21-1 follows
Description of "Figure 21-1 Detection Flow for Order Fallout"

About Order Fallout Notification

Order fallout notification is handled by Siebel CRM. After 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-2 illustrates this subprocess.

Figure 21-2 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.

You can correct errors as follows:

  • 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-3 illustrates the steps a fallout user takes to correct errors in a base order.

    Figure 21-3 Siebel CRM Correction Flow for Order Fallout

    Description of Figure 21-3 follows
    Description of "Figure 21-3 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. 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-4 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 AIA, and an option for updating the order status directly in OSM.

Figure 21-4 Local Correction Flow

This figure is described in the preceding text.

How Oracle AIA Error Handling Framework Captures Faults

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 an edge application, such as a billing or inventory system.

Figure 21-5 Capturing the Fault Sequence Diagram

This figure is described in the surrounding text.

The integration captures faults as follows:

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

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

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

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

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

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

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

  • Allowing custom enrichments to the fault message.

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

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

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

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

Description of Figure 21-6 follows
Description of "Figure 21-6 Creation and Submission of a Fault Message 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.

Figure 21-7 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:

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

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

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

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

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

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

    • The AIACOMOrderFalloutNotificationJMSConsumer picks up the fault messages with a JMSCorrelationID value that includes AIA_ORDERFALLOUT_TTS and initiates the Create Trouble Ticket from Oracle AIA 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.

Order Fallout Management Process Integration Business Flows

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 the following 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 the following business flows:

  • Order Failure Notification to OSM integration flow

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

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

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-8 illustrates the Create Trouble Ticket from Oracle AIA business flow at a high level.

Figure 21-8 Creating Trouble Tickets from Oracle AIA

Surrounding text describes Figure 21-8 .

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.

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 pre-built integration option that includes OSM, the integration automatically uses OSM to manage order fallout.

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

Figure 21-9 Creating Trouble Tickets from OSM

This figure is described in the following text.

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 AIA error handling framework, which sends the message to OSM COM.

When an error occurs in an AIA service, such as an ABCS or EBS, the service sends a fault message to the 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 creates trouble tickets and sends 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 generates 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 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.

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:

  1. Extend the Oracle AIA fault message to capture the additional information in Table 21-1 and Table 21-2.

  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.

  3. 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).

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