Hi Calin,
As far as I know, there is currently nothing this specific covered in the standard. Some time ago, we developed a use case precisely to highlight the need to specify this kind of functionality within the context of the ODA architecture.
https://www.tmforum.org/resources/technical-specification/tmfs011-use-case-order-fallout-management-v5-0-2/
The use case identifies the need for a new ODA component, new APIs, and changes to existing ones, as well as updates to SID entities to support this capability. The new component is proposed but not yet approved as part of the standard (it's on me to submit the formal proposal).
In the use case, once the issue is manually resolved, the Fallout Management component performs a PATCH operation against the order manager (in this case, a resource order manager, although the same approach would apply at the product level) to indicate that execution can resume. We did it this way because the current API does not offer a more suitable mechanism. That said, I believe the more correct solution would be to implement this via a dedicated task in the order management APIs (TMF622, TMF641, and TMF652).
Hope it helps.
Best regards,
------------------------------
Abel Ruiz Huerta
alvatross
------------------------------
Original Message:
Sent: Jun 10, 2025 06:54
From: Calin MARIAN
Subject: Handling Order Recovery
Hello,
I am searching for best practices for order recovery scenario:
1. A ProductOrder is in Held status due to a communication failure with an external API (e.g., provisioning partner).
2. The external issue has been resolved manually or via other processes.
3. Now we need to resume order processing in our order delivery system (orchestration engine).
What is the recommended way to indicate that the order should continue processing, PATCH on productOrder, custom taskResource for this, some event?
Thank you!
------------------------------
Calin MARIAN
Orange S.A.
------------------------------