My Oracle Support Banner

O2A Order Fallout Scenario Clarification (Doc ID 2018784.1)

Last updated on DECEMBER 09, 2017

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

To view full details, sign in with your My Oracle Support account.

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


In this Document
Goal
Solution


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.