Open APIs

Dear Team,

We have implemented TMF 641 for related customer order CFS which will further to go to SOM/network layer for necesary provisioning and all for respective RFS against it.

Now we are generating service order for given CFS specs using TMF 641 and sending it to downstream system then related service instance and all created at BSS and OSS end for it.

Now later due to some business requirement we need to add new service characteristics or parameters for respective CFS TMF 641 spec. then CFS service spec. ID is getting changed as class is getting re-created. So when CFS spec id is getting change again either upstream or downstream system to register/define new TMF 641 to adopt and generate/consume it accordingly. I believe in TMF 641 we do have parameter call "version" which we can update it to 1.0 or 1.1 . so instead changing original TMF 641 service spec id can we rely on version parameter to recreate class upon change or addition or deletion of any parameters /attributes. OR as TMF design guideline we need to upgrade TMF 641 spec with its specification ID as well along with version.

Kindly guide how we can avoid impact keeping same CFS spec. ID if any change in respective CFS TMF 641 spec. We are got stuck there due to continuous business requirements/improvement CFS spec getting changed and every time all application has to recreate class to consume new CFS spec id even if no change in structure and ony addition of new parameter/attribute un service characteristics.

------------------------------
Mahesh Choudhari
BT Group plc
------------------------------

Hi Mahesh

The catalog entities in the TMF Open API, including Service Specification, do indeed have a version property. So if you change a CFS spec, e.g. by adding a new characteristic, you would keep the same entity ID but update the version from (say) 1.0 to 1.1 (if the change is backward compatible) or from 1.0 to 2.0 (if the change breaks compatibility).

ServiceSpecRef includes version, so all your existing services in the inventory that use this spec would have 1.0 in SSRef.version, while new services instantiated from now on would have 1.1 (or 2.0) in SSRef.version.

All this has no bearing on the TMF641 signature, which will not change as a result of changes you make to catalog definitions.

Of course, if you decide to go with the strongly-typed subclass approach, and create (e.g.) a VirtualStorageServiceSpecification with properties instead of characteristics, you will have a signature change when you add a new property.

Just out of interest, how often do CFS specifications change in your business? I was under the impression that changes in the network area (CFS, RFS, Resource) are quite rare as compared to changes in product catalog domain.

This has nothing to do with the Open API signatures

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------