Open APIs

 View Only
Back to discussions
Expand all | Collapse all

TMF640 - Understanding the use of 'supportingService'

  • 1.  TMF640 - Understanding the use of 'supportingService'

    Posted Aug 28, 2018 03:37
    TMF640 API Document (Release 15.5.1) describes the usage of supportingService as

    "supportingService":[  

         {  

                 "id": "59",

                 "href":" http://server:port/inventoryApi/service/59"

    ….     May contain the fully embedded service or only an hyperlink

         }],


    Our interpretation of the documentation of supportingService is as given below, 
    • I can provide the hyperlink of another service instance which act as a supporting service.
    • I can embed the full details of another service instance (retrieved using GET operation) which act as a supporting service.
    • Since there is no relationship type attribute in the supportingService block, the supportingService only represents the parent child relationship (vertical relationship).  
    Question:   Can we use the supportingService block in the TMF640 API to create a supporting service along with the primary service in the same TMF640 request? i.e Can I embed the service create request of the supporting serivce by providing the request details under the supportingservice block. 

    Example:

    {
    "name": "Mobile",
    "state": "active",
    "serviceSpecification": {
    "href": ".../serviceSpecification/Mobile/11"
    },
    "supportingService": [
    {
    "name": "Data",
    "state": "active",
    "serviceSpecification": {
    "href": ".../serviceSpecification/Data/12"
    },
    "serviceCharacteristic": [
    {
    "name": "Limit",
    "value": "1 GB"
    }
    ]
    }
    ],
    "serviceCharacteristic": [
    {
    "name": "MSISDN",
    "value": "0123456789"
    }
    ]
    }

    ------------------------------
    Abdul Majid Hussain
    Telstra Corporation
    ------------------------------


  • 2.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Aug 29, 2018 03:05
    Hello Abdul,

    My feedback: I share the same interpretation than you for the use of  supportingService so related to you question I will assume you can do this way. It means than it allows through one service creation request in fact to create a service hierarchy  with a compositeService and an array of atomicService.

    Best regards

    Ludovic

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



  • 3.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Aug 29, 2018 03:32
    Thanks Ludovic.

    How do we document these understanding around 'supportingService' so that whoever implements TMF640, does that in consistent manner rather than leaving it for open interpretation?

    Can we update the API document with different examples?

    ------------------------------
    Abdul Majid Hussain
    Telstra Corporation
    ------------------------------

    Original Message


  • 4.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Aug 29, 2018 09:03
    Yes, I think the better is to add an example.

    But in order to do this, my recommendation is to log a CR in Jira for this API (suggesting to add an example based on 'embedded service description). It will allow to get feedback from the API team, and will be in the backlog for this API next release.

    Ludovic

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

    Original Message


  • 5.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Mar 29, 2020 19:50
    Hello Ludovic,

    Do you have any feedback on your CR for adding this example? I've had a look on the new version of the TMF640 Spec (18.5.1) but I couldn't find it.

    I have two additional questions on this point:
    1) Would it make sense to follow this same approach for the supportingResource? I mean, could it be possible to create resources behind the service directly on the same request? 
    2) Could we apply it (creating supportingService/supportingResource) also for TMF641?

    Regards

    ------------------------------
    Carlos Portela
    Solution Architect
    Proximus SA
    ------------------------------

    Original Message


  • 6.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Apr 02, 2020 11:28
    Hello Carlos,

    This is still on the to-do list for the examples. This is always the trickest part to deliver good examples ;)
    Regarding your questions
    1) Yes. Supporting resource will be present...but ....only as a reference and not by value. So you can indicate resource id (from inventory) to used for supporting the service but no request resource creation.
    2) Yes.  It should be in TMF641 v4.0 release.

    Hope it helps

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------

    Original Message


  • 7.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Apr 28, 2020 18:58
    Hello Ludovic,

    Thanks for your reply.

    From your feedback, it seems to be valid that we can create a supportingService together with the head service from TMF640.

    Looking in the resource model from the TMF640 spec document (v18), I see only "ServiceRef" on the supportingService relationship.
    Wouldn't it make sense to define it there with a different name (ref or service itself)?

    Just a suggestion so that we can have a better understanding on the valid use-cases.

    Another question, when performing a GET with TMF640, would it be possible to expose the supportingResource characteristics or, also in this case, only the reference ID?

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------

    Original Message


  • 8.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Apr 29, 2020 02:17
    Hello Carlos

    This has been changed in the soon-to-be-release v4.0 of this API. The attribut is still supportingService but the entity is serviceRefOrValue and not ServiceRef only...so you'll have all capabilities to describe a new service. For GET you can use Depth & Expand directive to expand with current version already-- please see TMF630 API Design Guideline part 2.

    Hope it helps

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------

    Original Message


  • 9.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Apr 29, 2020 09:29
    Thanks Ludovic.

    I had a look on the API Guidelines doc you've suggested. It is indeed answering my question.

    Regards

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------

    Original Message


  • 10.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted May 14, 2020 05:58
    Hi Ludovic, 

    Based on the Abdul interpretation. 

    Our interpretation of the documentation of supportingService is as given below,
    • I can provide the hyperlink of another service instance which act as a supporting service.
    • I can embed the full details of another service instance (retrieved using GET operation) which act as a supporting service.
    • Since there is no relationship type attribute in the supportingService block, the supportingService only represents the parent child relationship (vertical relationship).  
    if i don't have the hyperlink to link to the service instance, am i still able to use that element without hyperlink? 

    {
	"supportingService": [
		{
			"name": "Data",
			"serviceCharacteristic": [
				{
					"name": "Limit",
					"value": "1 GB"
				}
			]
		},
                {
			"name": "Voice",
			"serviceCharacteristic": [
				{
					"name": "Limit",
					"value": "60 minutes"
				}
			]
		},
                {
			"name": "SMS",
			"serviceCharacteristic": [
				{
					"name": "MT",
					"value": "enable"
				},
                                {
					"name": "MO",
					"value": "disable"
				}
			]
		}
	]
}​​


    ------------------------------
    Chio Chuan Ooi
    SingTel Optus
    ------------------------------

    Original Message


  • 11.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted May 14, 2020 07:34
    Hello

    I'm assuming here you want to describe the supporting service by value - so in this case you have to provide all required information to create as well this service. From my perspective I tend to think that at least 2 attributes are missing from your sample: supporting service state and specification.id. Need to check if other attributes are mandatory but I do not think so.

    Hope it helps,
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------

    Original Message


  • 12.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted May 24, 2020 16:52
    Edited by Carlos Portela May 24, 2020 16:53
    Hi Ludovic,

    Could this API Design Guideline chapter you suggest be applicable on TMF641? I mean, could we perform a GET on TMF641 and retrieve the enriched version of the services (1 per orderItem) and not only the northbound orderItem service data that has been previously ordered?

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------

    Original Message


  • 13.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted May 25, 2020 03:48
    Hi Carlos

    This is a very good question!
    From my perspective the guideline did not rules against: The "depth" is used to expand the level of referenced (related) entities 

    But still I will be a bit unconfortable that service order will then be used as an inventory query.... preferably use TMF638. For me,  once an order has been completed, this is history (keep it for log/track) but better use inventory (where link to order are).

    Hope it helps,
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------

    Original Message


  • 14.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted May 25, 2020 03:59
    Edited by Carlos Portela May 25, 2020 04:00
    Ludovic,

    I also feel a bit "step-back" on that approach via TMF641 but I was checking if it was even a possibility.

    Well, instead of TMF638, I had in mind to make it via TMF640. Basically, we would need to do still the call on TMF641 to get the service ID's from an order and then, via TMF640, get the full picture of the service.

    Or... I see that TMF640 also has the ServiceOrderRef in the Resource Model so, we could do this in a single call with no need to use TMF641 at all. 
    What do you think?

    (I was thinking to keep TMF638 away from the northbound and apply it only via the orchestrator..)

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------

    Original Message


  • 15.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Jun 17, 2020 14:15
    Edited by Carlos Portela Jun 17, 2020 14:16

    Ludovic,

    I was re-thinking about TMF641 GET and there's something that is not clear to me. When we perform a GET on a specific service order, shouldn't we get the exact same order data and corresponding items service data that we asked for at that time?

    Imagine that Order #1 asks a new (action ADD) Mobile CFS with 10G Data Usage Volume Limit. Then, Order #2 does an update (action MODIFY) on the same Mobile CFS increasing the Data Volume from 10G to 15G.

    Now, performing a get on Order #1, wouldn't it make sense to still get the orderItem Mobile CFS with 10G and orderAction as ADD?

    Shouldn't an order picture be kept intact as it was requested by that time (like a snapshot)? In this case, the GET with "depth" concept doesn't make sense in my opinion. We should not be able to retrieve a more detailed service as it was not ordered like that in the start... Do you see my point?

    Thanks for the input

    ​​​

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------

    Original Message


  • 16.  RE: TMF640 - Understanding the use of 'supportingService'

    Posted Jun 18, 2020 04:10
    Hello Carlos

    When we perform a GET on a specific service order, shouldn't we get the exact same order data and corresponding items service data that we asked for at that time?

    For me, the order is a request at a given time for a given situation. It is  an intent-based request where you describe a target situation. There is an inventory before (could be empty) and an updated inventory after (if the order is a success). The order during fullfiment could be completed, some id or charactersitic valued but data directly linked to this order.... but globally if you retrieve an order completed some time ago you should retrieve data at this time.

    Depth is useful when you want retieve more information for complex attribute defined as class ref.... Retrieve an order with detail on party & account for example (and not only their id).


    Hope it helps
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------

    Original Message


Related Content