Open APIs

Hi All,

Consider an use-case where we are a offering OTT as part of our telco bundled plans. After a customer orders a telco plan with OTT, we need to invoke the partner API to activate the user's benefits.

Should this API activation be handled directly by the Product Order Manager, or should it be orchestrated through the Service Order Manager according to TM Forum best practices? 

What are the reasons for choosing one approach over the other?

Thanks

Hi Ajay,

OTT account creation/update/delete/query should be orchestrated via the Service Order Manager, utilizing the TMF641 Service Order API.

Thanks & Regards

Manish Vishnoi

Hi,

Even though it's an external integration in question here, I believe OTT access (let's say streaming or entertainment content in general) should still be modeled as a service with a service specification, alongside the corresponding productSpecification and productOffering for pricing. This allows use of the Service Ordering API in a generic way and aligns with broader service handling patterns, enabling better state management, provisioning flow control, and separation of concerns. For example, provisioning may require sequential steps like creating a TV account before enabling access. So then service would not be created or be active, but customer billing might need to be started sooner or be decoupled from the provisioning state.

How I think of productOrdering is that it works agnostic of the product types, but adaptation to flow are more for production domain (e.g. if we need to integrate to different APIs per service type and so on)

An argument for "skipping" the service/production domain for this interaction could be for simplicity(as likely that service and product catalog specs be really close in what they represent), but unless provisioning state is generaly mapped on product order and product inventory, this will require adaptation to the solution flow and order state management, just to be able to integrate externally behind the product order.