Open APIs

 View Only

  • 1.  TMF633 - Queries on Detailed Specs

    Posted Jul 23, 2019 04:00
    Hi,
    Looking closely in TMF633 version 18.5, yields a few more questions.

    1. How the "version" of a Service Catalog entity is maintained? When we create does it have to default to "1.0"? "version" being a patch-able attribute, should we ONLY modify the field if it is explicitly present in input? Or shall we increment (say- +0.1) on every PATCH, if it's not present in input?
    2. Under the "Query all versioned catalog resources" section, sample example shows Service Candidate entity of multiple versions for SAME id to co-exist? Acc. to the spec, we can see "version" is a Patch-able attribute, similar to Service Catalog. A New Version of an entity with SAME "name" can be created with a POST which can create another entity with different version, but how to maintain diff version for same "id"?
    3. Acc to some example(s), where "id" is numeric, I am assuming "id" in spec translates into "id" in DB as well, even though it's String acc. to Spec. Or can it be case - specific, where "id" in spec and "identifier" in DB may differ? Which cases would be these?
    4. Retrieve Service Catalog - Which UC might need both the {id} and {&filtering}? I understand {&filtering} is optional, but is it necessary when a specific entity is being fetched?
    It'll be really helpful, if the above can be clarified.

    Thanks & Regards,

    ------------------------------
    D Basu``
    Architect
    India
    ------------------------------


  • 2.  RE: TMF633 - Queries on Detailed Specs

    TM Forum Member
    Posted Jul 24, 2019 12:35
    Hi D

    Firstly you need to examine the use cases for which Catalog element versioning is relevant (this applies to all the Open API catalog APIs, not just Service Catalog). One obvious use case is when you have instantiated inventory items from a catalog element, and then you make a change to the catalog element. You will probably want the existing inventory items to refer to the version from which they were instantiated, while referring new instantiations to the more recent version.

    1. It is the responsibility of the consumer to decide when a new version is relevant. This will relate to your business procedures for product and service life-cycle management.
    2. Indeed multiple versions of an element with the same id can co-exist. I would expect that an implementation would use the combination of version and id as the primary key for storage in (e.g.) a relational database.
    3. id in all the Open APIs is a string, there is no reason to limit it to numeric, neither in API exposure nor in persistence layer. It's up to the implementation how to generate id (GUID, database sequence, whatever).
    4. &filtering represents limiting the records returned and also which fields are returned. So in GET by ID you have already restricted the records, but you would still perhaps want to restrict which fields are returned.

    Hope it helps​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------

    Original Message