Open APIs

 View Only

  • 1.  Resource Model of Service Inventory and Service Order Management(TMF 641)

    Posted Mar 30, 2017 10:27
    Hi;

    I am evaluating both TMF641 and Service Inventory API.

    Looking at the resource models seeing same entities has different fields or different relations between.

    For example: TMF641 has ServiceSpecificationRef entity belongs to ServiceOrderItem whereas ServiceInventory API resource model has ServiceSpecificationRef entity belongs to Service Entity.

    Another example: attributes of Service entity in TMF641 is different than the attributes of the Service entity in Service Inventory API resource model.

    if I would like to use both of these APIs, what should be the approach I take to avoid confusion in resource models?

    Thanks,
    Regards.

    ------------------------------
    Osman Sebati CAM
    Huawei Technologies Co. Ltd
    ------------------------------


  • 2.  RE: Resource Model of Service Inventory and Service Order Management(TMF 641)

    Posted Mar 31, 2017 02:25
    Hi Osman,
    as I understood it, ServiceSpecificationRef is an entity that points to a more or less complex Service entity.
    Instead of using the Service Entity at any place where it is needed, the ServiceSpecificationRef seems to be a more handy way to reference services from different locations which are perhaps not aware of how to instantiate a service or don't have the necessary information about the service. So by having a light-weight reference, it becomses possible to reference services from order items, inventories or elsewhere.
    As I'm quite a newbie to this topic, my interpretation might be wrong. Please feel free to correct me.
    Kind regards
    Daniel

    ------------------------------
    Daniel Schaefer
    Vodafone GmbH
    ------------------------------



  • 3.  RE: Resource Model of Service Inventory and Service Order Management(TMF 641)

    Posted Mar 31, 2017 04:23
    Hi Daniel;

    Thank you for your answer.
    Yes. My understanding of ServiceSpecificationRef is same.

    However my question is "resource model's of APIs are different although they have the same entities, what approach we should take if we are considering to use more than one API"

    To further illustrate this question, look at these examples;
    Some entities has different number of attributes. For example; compare Service Entities in both specs.
    Also relations are different, For example have a look at ServiceSpecificationRef relations in the resource model of the both specs.

    Thanks,
    Regards.

    ------------------------------
    Osman Sebati CAM
    Huawei Technologies Co. Ltd
    ------------------------------

    Original Message


  • 4.  RE: Resource Model of Service Inventory and Service Order Management(TMF 641)

    Posted Apr 03, 2017 03:05

    Hi,

    I have a different understanding of ServiceSpecificationRef. Since it is a "specification" reference I understand that it refers to the Service Catalog, where the ServiceSpecification is defined. Then both ServiceOrderItem and Service can refer to the same specification in the logical data model. Where "ServiceOrderItem" is an existing or future instance of a ServiceSpecification and "Service" is an instance of the ServiceSpecification.

    I also think that since the TMForum SID model is a reference model and as such conceptual and is also defined by multiple authors, different lists of attributes and even attribute names can exist in Open API documentation. I suppose the attribute names are supposed to be unified within SID and the Open APIs, but as an example here "state" or "serviceState" isn't defined by SID so the difference between the attributes can easily be explained.

    As to what approach one should take in creating a resource model I can offer this: It is more important to think about the meaning and usage of relations and attributes than their technical implementation and naming. We already have an example of different understanding of entity relationships of ServiceSpecificationRef and if implemented with those differences the integration use of such APIs could run into problems. Also as an example of the Service's "state" attribute. Do you see such attribute to be meaningful to you as state affecting other services or as a state of service instance's lifecycle? Those two are defined by SID as "isStateful" and "cfsStatus"/"rfsStatus".

    Hope this helps.

    Best Regards,
    Niko



    ------------------------------
    Niko Kolari
    Telia Company
    ------------------------------

    Original Message


  • 5.  RE: Resource Model of Service Inventory and Service Order Management(TMF 641)

    Posted Apr 03, 2017 06:39
    Hi Niko;

    Thank you for your detailed answer and highlighting that specification is reference for catalogue and service isforinstance.

    On the main point where youcommentwith your last paragraph, I agree on your statement below.
    It is more important to think about the meaning and usage of relations and attributes than their technical implementation and naming.
    Niko Kolari,  04-03-2017 03:05

    However when I look at a sample CTK, I see a template created by the resource model of the related API.How right level of conformance can be possible if the number of attributes in the entities are different or attributes has different naming?

    Thanks,
    Regards.

    ------------------------------
    Osman Sebati CAM
    Huawei Technologies Co. Ltd
    ------------------------------

    Original Message


  • 6.  RE: Resource Model of Service Inventory and Service Order Management(TMF 641)

    Posted Apr 03, 2017 08:18

    Hi Osman,

    I think that the right level of conformance will unavoidably differ between implementations. It depends on both the TMForum specification in question and the underlying system(s) which in the end will offer the service/functionality through the API in question.  Assuming the system is built to support the SID data model we can expect the level of conformance to be high, but sometimes we are not that lucky.

    But as I said the SID model is a reference model and built by multiple authors. Add to that that it keeps developing and we have to concede that one can only strive towards conformance when basing actual API specifications on it.

    On a positive note I can say that despite not having everyone implement exactly the same API, just by having the common logical data model and key attributes and common understanding of the processes and the platforms is of HUGE benefit.

    Best Regards,
    Niko



    ------------------------------
    Niko Kolari
    Telia Company
    ------------------------------

    Original Message


Related Content