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
------------------------------
Original Message:
Sent: Jul 24, 2020 06:50
From: Dave Milham
Subject: TMF701 Process Flow API and Component model
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
Original Message:
Sent: Jul 20, 2020 08:43
From: Lester Thomas
Subject: TMF701 Process Flow API and Component model
@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
------------------------------