Open APIs

 View Only

  • 1.  TMF640 AVCNotification and Failed state

    Posted Aug 26, 2019 21:13
    Hi

    I have a question on TMF640 specification.
    While I understand - the entity states and transitions in TMF Open API specifications are considered as ILLUSTRATIVE rather than NORMATIVE. 


    Any service attribute modification of a service in Active state; will lead into AVCNotification (defined as per TMF640) and service will stay in Active state if the modification was a success.
    1. How will we
    - capture failure of modification
    - what will be the service state that it will transition to?
    - will we still have AVCNotification published with a failure message
    - If you could share a sample AVC Notification for this scenario

    2. The failure of service can happen at any state. Ex the design time service failed as there is not enough capacity on the ports defined by the requestor. How should this be published to OMS?

    3. TMF Service lifecycle state assumes best case scenario and has NO FAILED state of the service defined - but closest we get is state=INACTIVE.
    But that assumes that the existing service can be transitioned to Active state.

    I feel there is a strong need to add a FAILED state in TMF service state. Please advice

    Thanks
    Vikas

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


  • 2.  RE: TMF640 AVCNotification and Failed state

    Posted Aug 27, 2019 21:42
    Hello Vikas
    My general comment - it would be quite sad - for interoperability - if market players implement their own states or transitions. There could be strong semantic disconnect if new states are introduced, that are misunderstood (conceptually) by other players as they are not in TMF standard. State transitions are transactional, in a PATCH call you can designate desired (target) state, and if the call fails, service should remain in its previous state. Successful PATCH brings service into state corresponding to API payload provided (incl. one of TMF-recommended states that are understood by the rest of vendors and provider systems).

    My specific comment - the service states in TMF640 meant to trace it state in terms of Fulfillment lifecycle - not its Assurance status.
    E.g. service can be Active (e.g.= Provisioned), but have Incidents  indicating that it is not performing adequately (TMF621, 623).
    Inactive state can happen for example, on prepaid mobile services that have run out of credit.
    There are other TMF APIs if you want to bring the Assurance side in (TMF653, 657, 656).
    I am quoting them all because we do not know what talks to what in your case.

    Take a look at a wider API story, and you will see the place of 640 in the bigger picture of things.
    The states there are for Activation and Provisioning side of story, not Operational states.

    ------------------------------
    Sergey Zak
    Australia
    ------------------------------



  • 3.  RE: TMF640 AVCNotification and Failed state

    Posted Aug 29, 2019 11:00
    Regarding the general comment about states and transitions, the current approach of the Open API team is that the list of states should be supplied as an explicit list as NORMATIVE part of API specification, so any conforming implementation would be expected to honor the states in the list. However the transitions are likely to depend on specific business situations and so the state transition diagram should be considered as ILLUSTRATIVE.
    Suggest you reach out to the Open API chief architect @Pierre Gauthier for more clarity on this.​
    Regarding the specifics of the states in service and related entities, a discussion with the domain expert @Ludovic Robert might be helpful here - as Sergey writes you need to distinguish between the state of a service in the inventory as against the state of the process (order or activation) that is creating or changing the service.
    Hope it helps.
    ​

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

    Original Message


Related Content