Open APIs

 View Only
Expand all | Collapse all

Service ordering API - Define attributes/characteristics of ServiceRelationships

  • 1.  Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 08, 2018 16:28
    Hi,

    While evaluating the Open API for service ordering for a project I am working on I found the principle of modelling a service relationship for one of the services I am instantiating in a Service Order. In this relationship (as I see it) I can define a dependency of the service I am creating. For instance, for service A I need an instance of service B.

    Now I actually want to link a specific characteristic of Service B to Service A. Example would be a allocation of some kind of resource on a service (vlan). There is, in my opinion, no way of modelling this properly. But I wanted to check if I miss something here. 

    Thanks in advance!

    Regards,


    ------------------------------
    Jeroen Van der Laan
    Eurofiber Group
    ------------------------------


  • 2.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 11, 2018 10:07
    Jeroen

    You could build this type of behavior into the service itself, i.e., make the dependency to a service of Type B an attribute of a service of Type A. In terms of directives that are explicit in the order itself, I think you are correct that this is not support. 
    Also, see Section 2.5 Directives of IG1164 (you can access a draft of this document if you are a TM Forum member). 

    Steve

    ------------------------------
    Stephen Fratini
    TM Forum
    ------------------------------



  • 3.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 13, 2018 09:39
    Thanks Stephen for the response! I will try to figure out if your suggestion will work in our case.  Since it could be possible that in our case one service is dependent of multiple other services I am still unsure if this would work in the way you suggest. But the proof is in the pudding, so I will update this thread once I found a way to work this out. 😊

    Thanks again!

    ------------------------------
    Jeroen Van der Laan
    Eurofiber Nederland BV
    ------------------------------



  • 4.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 14, 2018 14:07
    Jeroen

    The service that you define can essentially be a script that requires various inputs. 
    The script could indicate the order in which subordinate services are created and even specify what happens in the event of failure (e.g., roll-back). 
    The downside of this approach is that each script writer will do the scripting in a different way. 
    So, a better solution would be to add a capability for directives in the API itself. This would need to be initiated by a Change Request from a TM Forum member company. 

    Steve


    ------------------------------
    Stephen Fratini
    TM Forum
    ------------------------------



  • 5.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 18, 2018 17:55
    Hi Jeroen 

    A similar question arose in a discussion today. 
    It turns out that you can state dependencies among order items. See the following text from the service order API (TMF641):

    OrderItemRelationship

    Linked order item to the one containing this attribute.

    Field

    Description

    type

    A string. The type of relation to another order item, as example it can be:

    o   "dependency" if the order item needs to be "not started" until another order item is complete

    o   "reliesOn" if the service needs another service to rely on

    o   ...

    id

    A service order item id - It could be any order item from this order.



    Steve

    ------------------------------
    Stephen Fratini
    TM Forum
    ------------------------------



  • 6.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 19, 2018 02:47
    Hi Stephen,

    Thank you for this update.

    This would work when I would have multiple OrderItems in one batch (both the depending and the dependent service). This would not work in my opinion when I would order a service (via an OrderItem) that relies on something on an already existing service. So either I would have to make this existing service be in the service order as an order item (which I think isn't the right approach) or try the ServiceRelationship approach instead. But then it becomes hard to model the attributes/characteristics of the existing service.

    Regards,
    Jeroen



    ------------------------------
    Jeroen Van der Laan
    Eurofiber Group
    ------------------------------



  • 7.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    TM Forum Member
    Posted Jun 19, 2018 04:37
    The SID includes a relationship between ServiceSpecCharacteristics, which could be what you are looking for. See for example figure SO.22 in the Service Overview guidebook from the SID.
    But as pointed out by previous posters, this appears to be missing from the Open API, you could submit an improvement request on the Open API JIRA https://projects.tmforum.org/jira/projects/AP/i.
    But even this might not be sufficient, you may need to have a relationship at the level of characteristic value (e.g. a specific bandwidth value in one service could be dependent on a technology attribute in another service). We discovered a similar lack in the area of product-to-service decomposition, here also the relationship appears to be missing.

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



  • 8.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 20, 2018 04:17
    Hi Jonathan,

    Indeed the ServiceSpecCharRelationship would work when I want to model dependencies between characteristics of one service specification (e.g. one service). This will not solve our situation which is more as you described the bandwidth/technology relationship). As I would probably model it is the fact that a service (within a service order) can have a serviceRelationship (relies_on) to another service which can hold something like a list of serviceRelationshipCharacteristics (that are valid serviceSpecCharacteristics of the service I depend on). In fact in my opinion the serviceRelationship entity needs a little more depth to define the specifics of the related service that are impacted by this service relationship. 

    Regards,

    ------------------------------
    Jeroen Van der Laan
    Eurofiber Group
    ------------------------------



  • 9.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 27, 2018 03:31
    Hi Jeroen,

    From a pure SID perspective, RootEntityRelationship may help you:
    "A RootEntitiyRelationship describes a relationship between two instances of RootEntities. The type of relationship might be very different such as requires, incompatibility, equivalent"
    Have a look at the SID GB922_Root section 1.2.2. There are several examples illustrating this concept.

    However, at the API level this kind of relationship is not expressed.

    Michel

    ------------------------------
    Michel Besson , PhD
    Lead Architect
    TM Forum
    ------------------------------



  • 10.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 29, 2018 10:15
    Hi Michel,

    Thanks for this helpful information. I wasn't aware of this modelling on the most low level (RootEntity). Will definitely have a look at this approach. I now modelled it in this API via a way that might just match this part of SID, and otherwise I might have to move it to an actual instance of RootEntity.

    Regards,

    ------------------------------
    Jeroen Van der Laan
    Eurofiber Group
    ------------------------------



  • 11.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jul 02, 2018 07:24
    ​Hi,
    indeed a possible modelling option is usign the "serviceSpecCharRelationship" i.e. starting from the "serviceSpecification", add one or more "serviceSpecCharRelationship" referencing the "serviceSpecification" the ordered service depends on.
    The referenced service specification can include 0 or more "serviceSpecCharacteristic" in turn including 0 or more "serviceSpecCharacteristicValue" at the detail needed.

    Just I want to add that the dependencies model between services is normally maintained in the service catalog and is supported by the Catalog Management API (TMF 633).

    Example in JSON:
     {
        "id": "7655",
        "href": "https://host:port/catalogManagement/serviceSpecification/7655",
        "name": "Firewall Service",
        "description": "This  service specification ...",
        "@type": "ResourceFacingServiceSpec",
        ....
        "serviceSpecCharacteristic": [
                {
                "name": "Supported throughput",
                .....
                "serviceSpecCharRelationship": [
                    {
                        "type": "dependency",
                        "name": "connectivity",
                        "id": "4690",
                        "href": "https://host:port/catalogManagement/serviceSpecification/4690",
                        }
                    }
                ],
       ....
    }

    {
        "id": "4690",
        "href": "https://host:port/catalogManagement/serviceSpecification/4690",
        "name": "P2P EVC",
        "description": "Connectivity service",
        "@type": "ResourceFacingServiceSpec",
        ....
        "serviceSpecCharacteristic": [
                    {
                "name": "Bandwidth profile",
                "description": "This service bandwidth",
                "valueType": "Committed Information Rate",
                .....
                "serviceSpecCharacteristicValue": [
                    {
                        "isDefault": true,
                        "value": "10Mbps",
                        .....
                        }                   
                    }
                ]
      ]
    }

    Hope it helps.
    Best regards,

    ------------------------------
    Dino Pellegrini
    Ericsson Inc.
    ------------------------------



  • 12.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jul 03, 2018 03:13
    Thanks for your input!

    In your example you model the a relation between a ServiceSpecCharacteristic and another ServiceSpecification which can be perfectly done using the OpenAPI in ServiceOrdering. The thing I am trying to achieve is to create a relationship between the Service I am ordering and a characteristic of another Service. To do this I create the relation on Service level and within that relation define the related characteristic as well. 

    Possibly it is better to move this to a slightly higher level (Service) and not relate it to the active Service but directly to the ServiceCharacteristic of the active service. I still find this to be a bit implicit which makes the API more complex. So I am still not completely sure what I will do here.  

    Regards,

    ------------------------------
    Jeroen Van der Laan
    Eurofiber Group
    ------------------------------



  • 13.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 20, 2018 11:13
    Jeroen

    I see your issue. However, order items do not typically point to a specific instance. 
    You could design your composite service such that one of the attributes is an optional reference to an existing component service or resource. 

    In the configuration API (TMF664), there is an option to reference existing components - another option if you are willing to use a configuration API. Probably worth having a look at TMF664 in any event. 

    Steve


    ------------------------------
    Stephen Fratini
    TM Forum
    ------------------------------



  • 14.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    TM Forum Member
    Posted Jun 26, 2018 04:52
    ​Hi Jeroen, I suggest looking at the catalyst that addressed similar issues: Automating Network as a Service - TM Forum
    TM Forum remove preview
    Automating Network as a Service - TM Forum
    Automating Network as a Service Using Operational Domain Management (ODM), TM Forum Open APIs and MEF LSO In this Catalyst, now in its 3rd phase, TM Forum
    View this on TM Forum >


    ------------------------------
    Lester Thomas
    Vodafone Group
    ------------------------------



  • 15.  RE: Service ordering API - Define attributes/characteristics of ServiceRelationships

    Posted Jun 29, 2018 10:24
    Hi Lester,

    Thanks for noting. I will have a look at this catalyst for sure! Good to see this catalyst also includes the MEF LSO architecture which I find to be a very interesting development as well. 

    Regards,

    ------------------------------
    Jeroen Van der Laan
    Eurofiber Group
    ------------------------------