O2A Order Fallout Scenario Clarification (Doc ID 2018784.1)

Last updated on JUNE 12, 2015

Applies to:

Oracle Communications Order and Service Management - Version 7.2.2 and later
Information in this document applies to any platform.

Goal

The following is a Clarification of the behavior of O2A PIP during order fallout.

Basic understanding:

1) A business fallout happened in a downstream system
2) OSM-COM detected the fault via AIA.
3) OSM-COM creates Trouble Ticket in CRM and receives TT-id in acknowledgement.
4) Order status in OSM will remain in-progress but in CRM order status should be changed to FAILED.
5) CRM can submit a revision order on the FAILED order for recovery of the fallout scenario.


In OSM, During a business fallout, O2A receives the OrderFalloutNotification from AIA and the recognition rule recognizes it.
“exists(../falloutxmlns:OrderFalloutNotification)"

As per the document -a typical flow path of SIFalloutProcess :

1)Get fulfillment order (search sales order correlated to this message)
2) Trigger transition of fulfillment order process into fallout recovery state (wait)
3) Send FAILED Status Update to Siebel.
4) Send trouble ticket to Siebel
5) Abort the sales order if a second fallout is detected during a revision

When tested in an integrated environment (CRM - AIA - OSM - BRM), and if we simulate a business fallout from BRM, we observe, TT is created in CRM , but order status not getting changed to FAILED in siebel.

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms