Open APIs

 View Only
  • 1.  Why serviceState in TMF640/641 does not have a Failed state

    Posted Aug 21, 2018 03:40

    Hi

    Both TMF 640 & 641 have service states defined 

    blank
    Inactive
    Designed
    Reserved
    Inactive
    Terminated

    But there is no FAILED service state - why is that? Did it got missed or am i missing something?

    Also in TMF641 Spec - there is serviceOrder state = FAILED - when ALL serviceOrderItem(service) state = FAILED.
    Not sure how this correlation will work without having the service state = failed.

    Thanks
    Vikas

    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------


  • 2.  RE: Why serviceState in TMF640/641 does not have a Failed state

    TM Forum Member
    Posted Aug 22, 2018 02:10
    Hi Vikas
    As a general rule, the entity states and transitions in TMF Open API specifications are considered as ILLUSTRATIVE rather than NORMATIVE. While best efforts are made to account for good business practice, a specific implementation of the API should be able to introduce different states according to the business requirements and existing functionality of underlying software models. All the more so for entities defined in a catalog (such as Product, Service, etc.), where the list of states and transitions might be different for different Services or Products.
    With that, I suggest that you discuss the issue of the FAILED state with the team lead for service order - @Ludovic Robert.
    Hope it helps.​

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



  • 3.  RE: Why serviceState in TMF640/641 does not have a Failed state

    TM Forum Member
    Posted Aug 22, 2018 03:02
    Hello Vikas, Jonathan

    The point mentioned by Jonathan about ILLUSTRATIVE value is an important one so feel free in your implementation to extend or use other value.

    About the Failed by itself, we considered in this example that it could not be a service state. A service could be inactive, active, etc but not failed. But this not prevent to use failed for service order item state. You could imagine to post a service order for an existing service modification. The provider for any reason is unable to deliver. We could imagine the service state is ...active but the service order item state is ...failed.
    But I repeat this is just for specification illustration.

    Hope it helps

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



  • 4.  RE: Why serviceState in TMF640/641 does not have a Failed state

    Posted Aug 22, 2018 05:13
    ​I presume the servicestate is meant to capture the Administrative State and not the Operational state(run-time)..Can anyone help to confirm this ?

    Thanks
    Vanitha R


  • 5.  RE: Why serviceState in TMF640/641 does not have a Failed state

    TM Forum Member
    Posted Aug 23, 2018 02:52
    Hi Vanitha 

    If you mean the serviceState in the serviceOrder.serviceOrderItem.service.serviceState this is the requested service state wished by the service order requester. This service state is a service inventory state (for illustration in the specification we have FeasabilityCheck, Designed, Reserved, Inactive, Active, Terminated).

    So imagine you have an existing service  in your inventory in reserved Status. You want to active it. it will be describe as this: A service order with an item referring this service id with action modify and serviceState active.

    Hope it helps.


    Ludovic

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



  • 6.  RE: Why serviceState in TMF640/641 does not have a Failed state

    Posted Sep 02, 2018 19:23
    Edited by Pete Bains Sep 02, 2018 19:23
    Hi Vikas,

    That's a good question!

    You are partialy correct in your assesment.

    In 641 it has two state models, 1) Service Order/Order Item state model & 2) Service Instance state model. In 640 it only has a service state model.

    With the Service Order/Item state model, you can indicate that the service has failed in a number of different ways (Pending, Held, Cancelled & Partial) some of these states are not clearly defined but that's what it means to be Illustrative.

    If you are looking for a failed scenario then you could consider using the error response codes (i.e. 400 codes) combined with an error response code, reason and message ... these are not so elegant when sent in an asynchronous manner.

    Hope this helps

    Pete

    ------------------------------
    Pete Bains
    ------------------------------



  • 7.  RE: Why serviceState in TMF640/641 does not have a Failed state

    Posted Sep 03, 2018 22:18
    Edited by Vikas Kumar Sep 03, 2018 22:25
    Hi @Ludovic Robert & @Pete Bains

    thanks for your response. Below is the snapshot from TMF641 spec r16.5.1
    In this the serviceOrder state = FAILED if All serviceOrderItems state = FAILED
    I think there is a consistency issue between Order state and Orderitem State

    thumbnail image
    ServiceOrder state and serviceOrderItem State table





    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------



  • 8.  RE: Why serviceState in TMF640/641 does not have a Failed state

    TM Forum Member
    Posted Sep 04, 2018 03:21
    Hello Vikas, Pete
    Yes there is consistency between orderState and orderItemState. I will go a step further: the orderState is 'deducted' from the orderItemState.

    service.state is not correlated to these two and this state is in the request: this is the requested service state requested. Of course the serviecorder item will be failed if the fullfilement process is unable to shift service state as requested.

    Hope it helps.

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



  • 9.  RE: Why serviceState in TMF640/641 does not have a Failed state

    Posted Sep 04, 2018 20:39
    Edited by Vikas Kumar Sep 04, 2018 21:42
    Thanks Ludovic

    As you commented: "the orderState is 'deducted' from the orderItemState."

    But as per Pg9 of the spec - 

    The order item states are the same as the order ones except ‘Partial’ status which is not available for service order item.

    Note that the order and order item states are tightly linked and need to be consistent (see table below)




    Also You commented - "Of course the serviecorder item will be failed if the fullfilement process is unable to shift service state as requested"

    The confusion is around not having another current/actual state of the service & how the inability of fullfilment process trickles to the serviceOrder.

    One way of doing it is via Notification. As Pete said "these are not so elegant when sent in an asynchronous manner."

    I think there is a lack of actual-state attribute in the service model definition.
    Having this attribute in the spec will have give a complete view of the service & can be mapped to serviceOrder too

    Thanks
    Vikas


    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------



  • 10.  RE: Why serviceState in TMF640/641 does not have a Failed state

    TM Forum Member
    Posted Sep 06, 2018 03:18
    Hi Vikas

    To clarify...When in the spec we wrote that "The order item states are the same as the order ones except 'Partial' status which is not available for service order item" we mean that except the partial value, the enum list is the same.
    It did not mean that at a given time all orderItem status and order status are the same.

    If you have one order item in Acknowledged, another inProgress, another Cancelled, another completed and one failed the order itself will be in In progress state. This rule to define order state depending on the order item states is illustrated(I hope) in the table. All this is illustrative and of course you are free in your implem to define another state engine.

    I'm not sure to understand what you mean with actual-state because for me you have it in the service inventory. The serviceState in the order is the targeted one, the service in the inventory the current one. If order item fails, the service state in the inventory would not change, the target state in the order item either bit the order item state will be failed so you have (I hope)  all the information.

    Thanks,

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