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.
The following is a Clarification of the behavior of O2A PIP during order fallout.
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.
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.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms