A while back, there was a discussion on introducing an ODA component for Service Orchestration and also Resource Orchestration/Provisioning. I just looked at the latest IG1242 ODA Component Inventory document and there is nothing planned for those specific components as of yet.
Any idea whether these components are still in the pipeline, or have they been replaced by some other ODA-C producers of the TMF640/TMF702 OpenAPIs?
I can see that TAC-280 for introducing these new components is 'In progress' as of Nov/21.
This would be a great place for @Gaetano Biancardi and @Sylvie Demarest to step in and give their vision for ODA components in this area.
Hi Dan, we have already specified 2 components involved in delivery orchestration:
TMFC003 - Product Order Delivery Orchestration and Mgt (in charge of the orchestration of the delivery of Product Orders)
TMFC007 - Service Order Management (in charge of the orchestration of the delivery of CFS or Services)
And we are currently working on TMFC011 - Resource Order Management.
Hope you can find there what you are looking for.
Thanks for your reply.
TMFC007 appears to address the SOM which exposes the TMF641 Service Ordering Management Open API. I was wondering which ODA-C will expose the TMF640 Service Activation and Configuration API? Various documentation suggests that TMF641 may be used for complex, asynchronous, orchestration; whereas TMF640 may be used for near real-time activations and re-configurations within the network.
TAC-280 indicates the following Open API interactions between SOM/ROM/etc.
There is also these two alternative interaction diagram proposal
Production: Components & Interactions - Components and Canvas - TM Forum Confluence
I suspect this is an open issue with ODA C teams
Yes it is, and we plan to discuss it and publish Resource Order Mgt specification for sprint 5 (end mid october).
IMHO it would be unfortunate if service/resource orchestration/activation/configuration was conflated with order management.
I am having trouble following the link in your reply. Any chance you could point me in the right direction?
IMHO, the component(s) that expose TMF640/TMF702 are not service order/resource order management. On the contrary SOM and ROM components would be expected to consume these APIs. An activation/configuration component would be something that talks directly to the software/hardware/firmware of the "network" (switches, NVFs, etc.), exposing 640/702 and mapping these (where necessary) into propriety NEP interfaces.
As a rule, I don't refer to Amdocs offerings in my replies on this forum, but in this particular case, I think it's worth mentioning that we have an offering - Amdocs Service Activation - that does exactly this. I'm sure other vendors in the OSS space have similar offerings, and so from ODA perspective I think it's worth considering this capability as being abstracted as a specific ODA component.
Think this is in the members only area at the moment