Open APIs

 View Only
  • 1.  TMF641 - serviceRelationship vs supportingService

    Posted Aug 22, 2019 05:55
    Hi,
    A couple of questions on TMF641.

    1. What is the need of having a separate "supportingService" relationship in ServiceRestriction? Can we not think it as a different relationshipType under "serviceRelationship"? I have gone through Product Ordering (TMF 622) as well, but it seems not to have modeled a separate "supportingProduct" kind of relationship? 
    2. ServiceRestriction and it's sub-resources seems to be very similar to Service adn it's sub-resources in TMF638. Can't it be replaced by ServiceRef instead? 
    3. I too had the same questions about having set of Valid Values for relationshipType, which is already addressed in a previous post here. Just to add, can this be extended to cover the relationshipType across ServiceOrderRelationship, ServiceOrderItemRelationship as well?

    Thanks & Regards

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


  • 2.  RE: TMF641 - serviceRelationship vs supportingService

    TM Forum Member
    Posted Aug 22, 2019 10:51
    Hi
    ServiceRestriction is a strict subset of Service - it wast introduced in recognition of the fact that a Service not yet instantiated has less attributes. We don't have a true business-context model that would tailor attributes to the specific needs of the API, so we introduced this pattern to reduce the size of the Service payload in relevant APIs (such as Service Order, Service Qualification).
    ServiceRestriction, like Service, is a value object, and as such is completely different from ServiceRef, which is a reference containing only a very few critical attributes to support the reference.

    The same has been done in Release 19 for Product, although we have changed the naming convention so it is now Base (thus BaseProduct), this will be visible when R19 assets are published (currently under member review).

    Regarding supportingService relationship, perhaps @Ludovic Robert could address this point.

    Hope it helps

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



  • 3.  RE: TMF641 - serviceRelationship vs supportingService

    TM Forum Member
    Posted Aug 23, 2019 03:12
    Hello

    One small correction: We took the decision the remove BaseEntity & EntityRestriction schemas instead use the plain Entity schema. This restricted schemas triggered negative side effect if the entity has to be extended.
    In the 19.0 we corrected this for product. In following release we will correct this for service API.

    Hope it helps

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------



  • 4.  RE: TMF641 - serviceRelationship vs supportingService

    Posted Aug 24, 2019 11:23
    Hi @Ludovic Robert,
    It would be really kind if you please clarify the queries around (1) and (3) please, as well?​

    Regards,


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



  • 5.  RE: TMF641 - serviceRelationship vs supportingService

    TM Forum Member
    Posted Aug 26, 2019 03:01
    Hi D Basu``

    1/ From my understanding - and the way we used it - the specific 'suporting' relationship should be used to manage the relationship between Customer-facing service (CFS) and Resource-facing service (RFS). RFS are supporting CFS. ServiceRelationship are used horizontally between same service type.

    3/Not sure to get the question but yes for me you can extend the relationship type value if you need to define specific one for your implementation. The specifications provided examples from common UC but of course real life UC could require additionnal value(s).

    Hope it helps

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------



  • 6.  RE: TMF641 - serviceRelationship vs supportingService

    Posted Aug 26, 2019 06:09
    Edited by D Basu`` Aug 26, 2019 06:13
    Thanks @Jonathan Goldberg,

    We are in the process of implementing R18.5 version for the time being and it would be extremely helpful if you please clarify the following:
    1. How does an actual Service instance is created?  Acc. to the Sample UC of TMF638, "The Service Inventory API can be called by the Service Order Management to create a new service instance/ update an existing service instance in the Service Inventory."
      1. Using Notification Model, if ServiceOrdering API need to generate ServiceCreateNotification(Service Inventory Space) then both get strongly coupled?
      2. Otherwise, if ServiceOrdering invokes REST API(s) to create Service Instances, the performance suffers?
    2. Also, According to the "GB992_Open_API_Map_R17.0.1 > Section 4. API Dependency Relation", As we see below,Service Inventory API and Service Ordering API is dependent on each other. How these should be ideally connected?
    3. Service as an "API Resource" features in both "Activation and configuration API" and "Service Inventory API". Do we view the same Service instance from either perspective? If yes, would it be possible to clarify with a possible sample representation? Or else, how is it?
    4. Can we please elaborate with sample representation, how a actual Service instance in "Service Inventory API" is actually different from Service Candidatein Service Catalog API?
    Thanks & Regards,



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



  • 7.  RE: TMF641 - serviceRelationship vs supportingService

    TM Forum Member
    Posted Aug 29, 2019 11:19
    Hi

    1. The Open API does not dictate implementation and deployment strategy. So the choice is up to you whether to invoke synchronously or to leave a message and expect service inventory to listen to the message.

    2. I am not sure if the GB922 API Map should be treated as a normative part of the specification, or rather as a guideline. But certainly one would expect that an implementation of Service Order would (among other things) cause Service Inventory to be invoked (either directly or indirectly as in 1.), see the following paragraph (3.).

    3. The Service entity is the same in Service Activation and Service Inventory - the difference between the APIs is that Service Inventory represents persistence of a Service in storage (such as a relational database) while Activation represents the service in the underlying network. The process implemented within a Service Order manager would be expected to activate the service in the network, and, if successful, to cause creation the service in the inventory, if an inventory was needed for this type of service. I guess it would be an implementation decision whether to create a separate inventory storage, people who know more about OSS than I do might be able to give guidance on this.

    4. Service Candidate is a catalog-level entity that wraps a Service Specification and represents its use in a Service Catalog (the same spec can feature in multiple catalogs). No direct relationship is relevant to the Service instance, in the model we of course track the Service Specification from which the Service was instantiated, but not from which Catalog this was taken.

    Hope it helps

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