Open APIs

 View Only
Back to discussions
Expand all | Collapse all

Creation of service in initial state (TMF638)

  • 1.  Creation of service in initial state (TMF638)

    TM Forum Member
    Posted May 30, 2022 12:58
    I am wondering what the best practice is for initial creation of a service in a service inventory with TMF638.

    The use case is of a service-handling application, that needs to create a new service instance in the service inventory, and then gradually enrich it in multiple steps (with PATCH operations) before it can be put into one of the specified states of the service lifecycle, e.g. 'designed' or 'active'. What should the state of the service be when it is first created (with POST operation)?

    According to the user guide the 'state' is mandatory for POST operation, so it cannot be left empty/unspecified. However, according to the lifecycle state machine:


    > 'inactive' is not suitable, because there is no transition from it to e.g. 'designed' (that would be necessary when the service is fully enriched).
    > 'initial' may be suitable, but does not seem to be a valid state of the lifecycle.

    What is the best practice state to use in this case?

    Thank you,
    Opher

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------


  • 2.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted May 31, 2022 05:16
    Hi Opher

    A very interesting question. I suggest you take a look at the ODA use cases UC003 and UC004, which deal with the equivalent flow in the area of Product, and see where in the flow they decide to place the product in the inventory.

    The point is that you would likely have your service embedded (initially) in a service order, not in the inventory. Changes to the service would be done via the order. At some point in the provisioning process, you would decide that the service is "mature" enough to have an independent existence in the inventory, in which case statuses such as Designed or FeasibilityChecked would seem to make sense as initial statuses.

    Hope it helps

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------

    Original Message


  • 3.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted May 31, 2022 13:12
    Hi Jonathan.

    Thank you for the answer.

    The mechanism you propose is one option, however UC003 also proposes another option, which is more in line with my approach. In Section 1.4. "API call flows", right at the beginning ("Step 0") there is a bullet point stating as follows: "(opt) Product inventory could be initialized with the elements already selected." It also appears at the bottom of the respective diagram:

    According to this alternative approach the product is created (initialized) in the inventory very early in the process, but it is not specified with which state. It is clearly not even "designed" yet, as it is "initialized with the elements already selected" - which I understand as only partially designed. Please note that per the TMF specifications, even "feasibilityChecked" is not really acceptable as state for entities (resources) in inventories. For example, in the diagram I copied to my original post above, you cannot reach this state with the operation "create(state=feasibilityChecked)", and the text of the guide (TMF638 in this case) explicitly specifies that a Service (RFS/CFS) is not supposed to be created at 'check feasibility' phase.

    Do I get this completely wrong?

    Opher

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------

    Original Message


  • 4.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 01, 2022 10:54
    It would be best to discuss this point with @Ludovic Robert, as the author of the use case, and also as a focal point for Service inventory and the state transition diagram.
    If you think t​hat something is flawed, a defect or CR could be raised.
    My personal belief is that the standard should be enabling and not prescriptive, so that organizations can implement entity lifecycles in a way that matches their business.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------

    Original Message


  • 5.  RE: Creation of service in initial state (TMF638)

    Posted Jun 02, 2022 03:15
    Hi Opher,

    In the same TMF asset that Jonathan refers to (IG1228), UC008 addresses your point, or at least our way of dealing with it. Service Order Management creates the service with status "feasibilityChecked" (see figure 6.3.1). Your feedback is welcome.

    Best regards,

    ------------------------------
    Roland Leners
    alvatross by SATEC
    ------------------------------

    Original Message


  • 6.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 02, 2022 04:18
    Hi Roland,

    Thank you for your reply.

    In the version of IG1228 UC008 that I am looking at there is no Figure 6.3.1, but I guess the diagram you refer to is Figure 10 - here is the relevant area of the diagram:



    My problem is that it is in contradiction with the state diagram from TMF638 that I copied in my original post. According to that diagram, the call:
    POST /service (state="feasibilityChecked")
    is not supported...

    What do I miss?

    Best regards,
    Opher

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------

    Original Message


  • 7.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 02, 2022 06:39
    Hi Jonathan, Roland, Ludovic,

    Another example of my question appears very clearly in IG1224, specifically in Figure 12: Order Management sequence flow:



    Here there is first a call to TMF638 to create a service instance, then, after activation/configuration is complete, there is another call to TMF638 to update this service instance. The way I understand it, the first call only initializes a service instance in the inventory, therefore the "state" should be something like "new" or "initial". However such state is not specified in TMF638 (or any of the resources, for that matter).

    Best regards,
    Opher

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------

    Original Message


  • 8.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 03, 2022 07:49
    I found the answer to my question. In case anyone is interested, here it is.

    According to TMF630 REST API Design Guidelines Part 2, Paragraph 2.3 State extension pattern (quote):
    • The enumeration of states are considered "normative" but not comprehensive. They must not be removed from the specification, or semantically redefined by the implementation, but they can be added to - both in breadth (additional states) and depth (additional sub-states).
    • The transitions between states are "illustrative". While the state-transition diagram provides a helpful graph, a compliant implementation is free to transition between states as it wishes - though obviously it would be helpful to document any variation for potential consumers.
    So we can simply add the initial state we need...

    Best regards,
    Opher

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------

    Original Message


  • 9.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 06, 2022 05:19

    Hi Opher,

    Could you tell me where is mentioned that a service cannot be created with the feasibilityCheck status in the TMF638 User Guide? I really can't find it.

     In UC008 we are following the next rule: SOM instantiates the service only when it knows it is feasible. This is mostly to avoid having services in the inventory that will never get activated. But indeed, you can follow different rules if they fit better in your solution.

    Best regards.

    ------------------------------
    Abel Ruiz Huerta
    alvatross by SATEC
    ------------------------------

    Original Message


  • 10.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 07, 2022 02:08
    Hi Abel,

    Thank you for your message.

    To your question - it is not mentioned explicitly that a service cannot be created with the feasibilityChecked status. However, if you look at the state diagram, you see that from the entry point of the diagram ('Initial') you can reach any targetState except feasibilityChecked with "create(state=targetState)". The arrow towards feasibilityChecked is the only one that is annotated differently, with "checkFeasibility" rather than "create(state=feasibilityChecked)". From this difference I deduced that the services are not supposed to be created with this state.

    Best regards,
    Opher

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------

    Original Message


  • 11.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 06, 2022 18:12
    Edited by Stuart Batten Jun 06, 2022 18:15
    Hi Opher,

    Another way to think about the State of a service is to consider the state the intended state not the achieved state.

    e.g. A client might request that a non existent service be put into "designed" state. A service record (not the service itself) is created. A listener detects the request and responds by undertaking a design for the service.
    Once happy with the design the client might proceed to another stage requesting the resources be reserved for the design - and hence the client request a change to the record into a "reserved" state.  Another listener responds and initiates the reservation of the resources.

    Think of change of status request as an update to a database record and a listener operating on that database triggering the set of tasks

    The next part to the problem is being able to detect when design or reserve or activate is actually achieved. This can be achieved by applying updates to service characteristics and checking for "MonitorAttributeValueChangeEvent" a pretty handy way to track progress of an action (e.g. 40%complete, dueDate=yyyymmdd)

    The intended state is also handy if the service actually moves out of that state unexpectedly (intentional/unintentional error scenario). The mismatch between intended versus actual state could (depending on business rules) trigger an action on the service to return it to the intended state.



    ------------------------------
    Stuart Batten
    Telstra Corporation
    ------------------------------

    Original Message


  • 12.  RE: Creation of service in initial state (TMF638)

    TM Forum Member
    Posted Jun 07, 2022 02:14
    Hi Stuart,

    Thank you for your message, it is an interesting idea.

    Best regards,
    Opher

    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------

    Original Message