Open APIs

Expand all | Collapse all

TMF701 Process Flow API and Component model

  • 1.  TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 20, 2020 08:44
    @Ludovic Robert - In the work on the ODA Component model, we believe many ODA-Components will expose a TMF701 Process Flow API. Has any thought been put into how a component might expose the full set of process-flows that it can manage? I understand that at run-time a consumer (eg a channel) may query the process-flows that are available. I understand that a channel is meant to understand the full set of possible process-flows (as it may be required to build the relavant UIs). Could we introduce something in the component model to expose the full set of possible Process-Flows at design-time? ​

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


  • 2.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 20, 2020 09:29
    Hello Lester,
    Do you mean something like a ProcessFlow catalog to get existing Process flow 'template'? To be aligned with our 'API/SID grammar' I will say ProcessFlowSpecification (describing a set of TaskFlowSpecification). We will then be able to query ProcessFlowSpecification or retrieve available for a given context (by copying our pattern we can also introduce a ProcessFlowQualification).
    From an API standpoint it is something we can contribute  (I got same request internally).
    From an architecture perspective it is a bit blurry for me if one single end-point will provide this proccessFlowSpecification catalog or if we expect each ODA Component to provide the subset of their managed ProcessFlowSpecification.

    Best regards,
    Ludovic


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



  • 3.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 21, 2020 04:36
    Hello @Ludovic Robert,
        When do you expect to start the review/revison of the next version of this API specficiation? If possible, I'd like to get involved in that.

    Many thanks



    ------------------------------
    Stephen Connor
    Cortex
    ------------------------------



  • 4.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 21, 2020 05:15
    Hello Stephen
    Probably starting in September. The first step is to provide an API contribution to the TMF API project team to get their approval for a new API.
    If you have joined the TMF API Project you can of course get involved into this work. You're welcome :)

    Thanks

    Ludovic

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



  • 5.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 21, 2020 05:24
    Many thanks Ludovic

    ------------------------------
    Stephen Connor
    Cortex
    ------------------------------



  • 6.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 23, 2020 08:32
    Hi Ludovic,

    yes - I mean  ProcessFlow catalog. I would expect each Component (that implements 701) to expose a catalog of the full set of ProcessFlows.

    Regards,

    Lester

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



  • 7.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 24, 2020 03:09
    It seems to me that this is analogous to VNF Flow Graphs (VNFFG) which would be represented as Resource Functions (RF).  An RF may exist to embody a path, for example a route from A -> Z through a number of network elements which is represented as a directed graph in the connectivity attribute of an RF.

    ODA Components should be represented as SoftwareSpecification/InstalledSoftware (TMF634/TMF639) which contain ApiSpecification/API and ResourceFunctionSpecifications/ResourceFunctions (see AP-2274 and ODA-430).

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 8.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Jul 24, 2020 06:51
    Good discusino . Some similar discusion are coming up in the ODA Tech Architecture
    There is metadata that needs to be associated with components - some of this is  needed at Design time and some  at run time
    I would expect whilst a component would have a URL when this metadata can be queried at run time that  it might proxy this to a general ODA System/ Canvas Serivce ( itself an ODA component who core funnction is a catalog of processes.) just to avoid burdening all componets directly with this code overhead. This type of patern is appering for other things like component run time regitratin and discover ,  security .
    Vance's comment caputurs the current thinking on how this metdata could be modelled and is neat because it aligns with SID and current APIs
    BTW in an earlier project called Software Enabled Service (SES) / Software delivery Framaframework (SDF)   precursor to ODA compoents this fucntinoality was called a metadata coordinator  see TMF 519 v1.6 section 5.2. Use cases

    ------------------------------
    Dave Milham
    TM Forum CHIEF ArchItect
    ------------------------------



  • 9.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Aug 17, 2020 08:53
    Hi,

    looking at TMF701 Process Flow Mgmt I am wondering how it interacts with Ordering APIs such as e.g. TMF622 ProductOrdering API.

    Assume the execution of a Product Order involves automatic and possibly also manual tasks. A consumer could retrieve the order state by using GET /productOrder/{id}. This provides the current state of the order, ok.

    But, in addition, during the order fulfillment there arise typically a whole bunch of "business events"  (like service created, parcel shipped etc.). Moreover, a consumer (like customer or service agent) would like to know which tasks of the order fulfillment are already accomplished and which tasks are still open / to be done.

    My question is which API should the be called to get a view on these "business events" and on the "order execution task flow", TMF622 or TMF701? Is there a rule of thumb which API is responsible for which sort of information?

    BR Thomas

    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------



  • 10.  RE: TMF701 Process Flow API and Component model

    TM Forum Member
    Posted Aug 17, 2020 09:42
    We are drafting some ideas in the the ODA technical architecture  under
    ODA Pattern: Back end for Front end Service and Integration Pattern (BFF)
    For how this might work as a ODA integration / transaction paterns . The concept of Pace architecture is introduced and it leverages some work from a colleague of yours.

    ------------------------------
    Dave Milham
    TM Forum CHIEF ArchItect
    ------------------------------