Open APIs

 View Only
Back to discussions
Expand all | Collapse all

TMF633 T-Shirt size

  • 1.  TMF633 T-Shirt size

    Posted Oct 29, 2021 12:12
    Edited by Florian Kammermann Oct 29, 2021 12:17

    Hi Dear tmforum

    We try to model T-Shirt Size with TMF633

    What is T-Shirt Size:
    For example, we have a Service Specification which is "compute and memory".
    This Service has the T-Shirt Sizes: 
    - S: 1 cpu / 128MB
    - M 2 cpu / 256MB
    - L 4 cpu / 512MB
    - XL 8 cpu / 1024MB

    We struggle to apply this to the TMF633 open API spec.

    The following opportunities:
    - use featureSpecification as T-Shirt Size and then express cpu/memory as featureSpecCharacteristic
    - use specCharacteristic for expressing T-Shirt Size, then use also specCharacteristic to express cpu / memory. Express the relation between T-Shirt Size and cpu / memory with charSpecRelationship.

    How would you model T-Shirt Size with TMF633?



    ------------------------------
    Florian Kammermann
    Swisscom AG
    ------------------------------


  • 2.  RE: TMF633 T-Shirt size

    Posted Oct 31, 2021 06:23
    Hi Florian
    One approach might be to have the t-shirt size at the Product level, i.e. commercial. So your product specification would have characteristic spec size (say), with list of spec values S, M, L, XL.
    And you could then build commercial offerings to match these size values, each one with different price.
    In the decomposition to Service, you would map the product size into the specific service compute characteristics.
    Of course this assumes you want to hide the compute characteristics in the commercial layer.

    ------------------------------
    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.
    ------------------------------



  • 3.  RE: TMF633 T-Shirt size

    Posted Oct 31, 2021 07:25
    Edited by Florian Kammermann Oct 31, 2021 07:31

    > One approach might be to have the t-shirt size at the Product level, i.e. commercial.
    This doesn't work, because a lot of these services are just used internally and are not directly used by a commercial offering.
    At the end they can be part of a commercial offering, but they are 2 to n services down the graph.

    If these are all Services, then "a" would be the one connected to the Commercial Offering. But I we also need to model T-Shirt Size on "b","c","d","e".

    Another possibility would be to introduce a custom Attribute and data structure, but I'm not sure if tmf open api allows this.

    ------------------------------
    Florian Kammermann
    Swisscom AG
    ------------------------------

    Original Message


  • 4.  RE: TMF633 T-Shirt size

    Posted Oct 31, 2021 07:39
    In that case, perhaps intent-based would be the best way to go? At the higher levels (CFS?) you just have size, and at the lower levels this gets translated to the actual implementation (the compute parameters). But I'm not sure that we have sufficiently detailed semantics for characteristic value mapping in the API model. Even in the SID, where there is value mapping between ProductSpec and ServiceSpec, I'm not sure that they have Service characteristic value mapping between Service and Service.

    ------------------------------
    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.
    ------------------------------

    Original Message


  • 5.  RE: TMF633 T-Shirt size

    Posted Nov 01, 2021 05:58
    Hi Florian,

    The secret lies in some of the SID  that did not get properly implemented in the API yet.
    The serviceSpecification describes what a Compute&Memory is. The characteristicSpecifications describe what information is expected for each instance.

    e.g.

    • ServiceSpecification: Compute&Memory
      • serviceCharacteristicSpecifications
        • name: CPU, valueType: integer
        • name: Memory, valueType: integer, unitOfMeasure: MB

    The ServiceCandidate is now defining the offered versions of this Compute&Memory. The API for ServiceCandidate is however missing the required array of characteristics:

    e.g.

    • ServiceCandidate: Compute&Memory S
      • characteristic
        • name: CPU, value: 1
        • name: memory, value: 128
    • ServiceCandidate: Compute&Memory M
      • characteristic
        • name: CPU, value: 2
        • name: memory, value: 256
    • ServiceCandidate: Compute&Memory L
      • characteristic
        • name: CPU, value: 4
        • name: memory, value: 512
    • ServiceCandidate: Compute&Memory XL
      • characteristic
        • name: CPU, value: 8
        • name: memory, value: 1024

    The ServiceCandidates can be added to a ServiceCatalog for internal use.
    The ServiceCandidates can also be used to create producOfferings (with a link to serviceCandidate) for offering them to customers.

    I have found again and again that this is the simplest way to model the T-shirt size packages that are so common for service providers. Unfortunately the serviceCandidate concept is often not well understood by vendors, forcing service providers to either do much more complex modeling using conditional relationships between characteristics or roll their own service catalogs.

    Regards

    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------

    Original Message


  • 6.  RE: TMF633 T-Shirt size

    Posted Nov 01, 2021 12:37

    Thank you for your answer @Koen Peeters this points into the right direction.

    To fulfill our requirements we would extend, the ServiceCandidate with the Characteristics.
    For the usability of the API I would also suggest to add the ServiceCandidates as an array to the ServiceSpecification. Since the browsing flow is mostly: I search for a Service Specification and then want to know the Candidates (T-Shirt size).

    @Jonathan Goldberg what is your opinion on this?​​



    ------------------------------
    Florian Kammermann
    Swisscom AG
    ------------------------------

    Original Message


  • 7.  RE: TMF633 T-Shirt size

    Posted Nov 02, 2021 02:38
    Hi all!
    I'm wondering whether mysterious ProductConfigSpec could be used for this case?
    The name matches perfectly, but I can't see relation to ProductSpecCharValue.
    And it has minimal description in GB922.

    ------------------------------
    Damian Golda
    Comarch S.A.
    ------------------------------

    Original Message


  • 8.  RE: TMF633 T-Shirt size

    Posted Nov 02, 2021 02:50
    Edited by Florian Kammermann Nov 02, 2021 02:52
    I can not find ProductConfigSpec in the tmforum API's https://github.com/tmforum-apis, nor I can find it in https://github.com/tmforum-apis/Open_Api_And_Data_Model/. Can you provide the direct link?

    ------------------------------
    Florian Kammermann
    Swisscom AG
    ------------------------------

    Original Message


  • 9.  RE: TMF633 T-Shirt size

    Posted Nov 02, 2021 03:15
    ProductConfigSpec is from SID not OpenApi:
    https://www.tmforum.org/resources/standard/gb922-product-v21-0-0/

    I found that ProductConfigSpec extends ConfigurationSpecification from Common so it is defined by ConfigSpecCharUse.

    ------------------------------
    Damian Golda
    Comarch S.A.
    ------------------------------

    Original Message


  • 10.  RE: TMF633 T-Shirt size

    Posted Nov 03, 2021 01:23
    The ODA teams have recognized requirements for Configuration Management (CM) in Product, Service and Resource domains. As you say, the Configuration and Profile ABE is in Common.  Jira issue AP-2997 contributes JSON Schemas reflecting what is in SID.

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


  • 11.  RE: TMF633 T-Shirt size

    Posted Nov 03, 2021 02:32
    Hi
    I'm afraid that I have not seen the value or relevance of ServiceCandidate (or ResourceCandidate), and I had even suggested their removal from the SID and API models.
    Having said that, it is possible that, as suggested by @Koen Peeters, these entities could be "revived" and given value. The suggested extension needs more study, but teh material in this thread is a good starting point.​

    ------------------------------
    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.
    ------------------------------

    Original Message


  • 12.  RE: TMF633 T-Shirt size

    Posted Dec 06, 2022 10:22

    Hi.
    I agree with your observation Jonathan. I do not see the relevance of ServiceCandidate either. It seems to me that purpose is better fulfilled using appropriate status attributes. Is there perhaps a discussion dedicated solely to this topic ?

    As for the original topic and the suggestion using serviceCandidate, it works out for this particular example. But imagine a product with a complete scalable parameter from 1-1000. We do not want to create 1000 Candidates. So the answer would obviously be product and service configuration, with the needed translation in between.(?)



    ------------------------------
    tobias adelgren
    Telia Company
    ------------------------------

    Original Message


Related Content