Open APIs

Hi there, <o:p></o:p>

I'm still working my way around the various TMF Open API's their intended focus. But one of the things I am struggling with is how organisation might implement one or more of the TMF Open API's.<o:p></o:p>

Does one only look to use the components that might be needed for their business scenario and extend/tailor where required?<o:p></o:p>

My feeling is that the API's are really a framework, where some of the structure might be adopted and where others business needs are developed for, within the framework of a particular API to create our own compliant versions of say 622, 629 and 620 etc..<o:p></o:p>

I ask this question as I have had comments from developers saying it would be hard to implement all of what is contained in the API's. <o:p></o:p>

So now I am thinking about how I go back to the devs and say this is how we go about leveraging the API for our organisation.<o:p></o:p>

Many thanks in advance.<o:p></o:p>

Bryn  <o:p></o:p>

Hi Bryn

It's completely up to you and your organization about how far you want to go in implementing TMF Open APIs. It depends on which business areas your organization covers, and what the expectations are of potential consumers of the APIs.

For example, if you were creating a digital commerce solution, you would presumably be interested in APIs such as product catalog, product configuration, product offering qualification, shopping cart, product ordering, product inventory, and more. On the other hand, if you are closer to the network, you would be more interested in service catalog, service order, service inventory, resource catalog, resource order, resource inventory, etc.

Hope it helps

Hi there, <o:p></o:p>

I'm still working my way around the various TMF Open API's their intended focus. But one of the things I am struggling with is how organisation might implement one or more of the TMF Open API's.<o:p></o:p>

Does one only look to use the components that might be needed for their business scenario and extend/tailor where required?<o:p></o:p>

My feeling is that the API's are really a framework, where some of the structure might be adopted and where others business needs are developed for, within the framework of a particular API to create our own compliant versions of say 622, 629 and 620 etc..<o:p></o:p>

I ask this question as I have had comments from developers saying it would be hard to implement all of what is contained in the API's. <o:p></o:p>

So now I am thinking about how I go back to the devs and say this is how we go about leveraging the API for our organisation.<o:p></o:p>

Many thanks in advance.<o:p></o:p>

Bryn  <o:p></o:p>

Hi Jonathan, <o:p></o:p>

Thanks for your reply and my apologies if I wasn't quite clear with my question. I guess what I am trying to understand is how much you would utilize/implement from each API. <o:p></o:p>

My assumption is that there are mandatory components within, let's say in TMF620 that must be used and some that may not be used and that you would extend where needed. On further investigation, it is also my assumption that IG1228 is a place to start to identify what to use, and that the use cases listed in IG1228 help to determine your approach.<o:p></o:p>

Regards Bryn

Hi Bryn

It's completely up to you and your organization about how far you want to go in implementing TMF Open APIs. It depends on which business areas your organization covers, and what the expectations are of potential consumers of the APIs.

For example, if you were creating a digital commerce solution, you would presumably be interested in APIs such as product catalog, product configuration, product offering qualification, shopping cart, product ordering, product inventory, and more. On the other hand, if you are closer to the network, you would be more interested in service catalog, service order, service inventory, resource catalog, resource order, resource inventory, etc.

Hope it helps

Hi there, <o:p></o:p>

I'm still working my way around the various TMF Open API's their intended focus. But one of the things I am struggling with is how organisation might implement one or more of the TMF Open API's.<o:p></o:p>

Does one only look to use the components that might be needed for their business scenario and extend/tailor where required?<o:p></o:p>

My feeling is that the API's are really a framework, where some of the structure might be adopted and where others business needs are developed for, within the framework of a particular API to create our own compliant versions of say 622, 629 and 620 etc..<o:p></o:p>

I ask this question as I have had comments from developers saying it would be hard to implement all of what is contained in the API's. <o:p></o:p>

So now I am thinking about how I go back to the devs and say this is how we go about leveraging the API for our organisation.<o:p></o:p>

Many thanks in advance.<o:p></o:p>

Bryn  <o:p></o:p>

Hi Bryn

The TMF Open APIs are just that, APIs. The published assets describe the contract between the provider/exposer of the API and the consumer.

There are no "components" in the APIs, and no real implementation.

Perhaps you are referring to gaining formal certification of conformance to the standard? One of the published assets is a conformance profile, that defines the minimum expectation from an implementation for the API. For example, in TMF620 Product Catalog, we believe that the API implementation must support the entities Product Specification, Product Offering, Product Offering Price. However the other managed entities Catalog, Category, ImportJob, ExportJob are not crucial, and an implementation can gain conformance without implementing these entities.

Hi Jonathan, <o:p></o:p>

Thanks for your reply and my apologies if I wasn't quite clear with my question. I guess what I am trying to understand is how much you would utilize/implement from each API. <o:p></o:p>

My assumption is that there are mandatory components within, let's say in TMF620 that must be used and some that may not be used and that you would extend where needed. On further investigation, it is also my assumption that IG1228 is a place to start to identify what to use, and that the use cases listed in IG1228 help to determine your approach.<o:p></o:p>

Regards Bryn

Hi Bryn

It's completely up to you and your organization about how far you want to go in implementing TMF Open APIs. It depends on which business areas your organization covers, and what the expectations are of potential consumers of the APIs.

For example, if you were creating a digital commerce solution, you would presumably be interested in APIs such as product catalog, product configuration, product offering qualification, shopping cart, product ordering, product inventory, and more. On the other hand, if you are closer to the network, you would be more interested in service catalog, service order, service inventory, resource catalog, resource order, resource inventory, etc.

Hope it helps

Hi there, <o:p></o:p>

I'm still working my way around the various TMF Open API's their intended focus. But one of the things I am struggling with is how organisation might implement one or more of the TMF Open API's.<o:p></o:p>

Does one only look to use the components that might be needed for their business scenario and extend/tailor where required?<o:p></o:p>

My feeling is that the API's are really a framework, where some of the structure might be adopted and where others business needs are developed for, within the framework of a particular API to create our own compliant versions of say 622, 629 and 620 etc..<o:p></o:p>

I ask this question as I have had comments from developers saying it would be hard to implement all of what is contained in the API's. <o:p></o:p>

So now I am thinking about how I go back to the devs and say this is how we go about leveraging the API for our organisation.<o:p></o:p>

Many thanks in advance.<o:p></o:p>

Bryn  <o:p></o:p>