Hi Jiri,
Regarding TMF645:
The flat structure in TMF645 is by design and there is no other way.
Nesting implies a containment hierarchy but in the SID:
It's impossible to construct a hierarchy of Sspecs based on the bundle product offering hierarchy.
Because TMF645 qualifies ServiceSpecifications, and no SSpec hierarchy exists, nested SQIs would have no semantic foundation in SID/TMF645.
qualificationItemRelationship is therefore the only valid way to relate items if you need to define dependencies. I hope the TMF645 design team will confirm this.
and about TMF641:
In TMF641, the ServiceOrderItem concept supports nested service order items, which is very convenient for composite (bundle) services made of multiple components.
Are you suggesting that 641 nesting reflects product catalogue-driven hierarchy (bundle product offerings in the product catalogue?).
I don't believe that's possible.
I believe 641's serviceOrderItem is a hierarchy created dynamically by the service decomposition/orchestration layer (e.g., CFS → RFS expansion) to group technical services for lifecycle and orchestration. (this is maybe a case where you can use SSpec collection defined in the Service Catalogue).
Thus, TMF641 nesting and TMF645 flatness are by design and serve different purposes.
The OSS experts will probably give you a better answer!
------------------------------
Kind regards,
Matthieu Hattab
Digital Sales, Core Commerce Domain Architect
Ex-Lyse Tele, Open to Work
------------------------------
Original Message:
Sent: Dec 08, 2025 05:19
From: Jiri Smekal
Subject: TMF645 v5 (Preview) – nested ServiceQualificationItems?
Hi all,
we are working on an implementation of the TMFC009 Service Qualification Management component using the TMF645 API. At the moment we are focusing on the CheckServiceQualification operation.
From the point of view of the client systems – TMFC002 Service Order Capture and Validation (POCV) and TMFC003 Product Order Delivery Orchestration and Management – calling TMF645 looks very similar to calling TMF641 Service Order.
decompose products into CFS services, and then
call TMF645 for feasibility/qualification, and afterwards
call TMF641 to actually place the service order.
In TMF641, the ServiceOrderItem concept supports nested service order items, which is very convenient for composite (bundle) services made of multiple components. On top of that, there is also ServiceOrderItemRelationship for more detailed relationships between items.
In TMF645 v5, there is no option to nest ServiceQualificationItem. The relationships between items in the request can still be expressed using QualificationItemRelationship, which is conceptually equivalent to ServiceOrderItemRelationship in TMF641, but the structure is strictly flat.
My questions are:
Is the absence of nested ServiceQualificationItem in TMF645 intentional by design?
Or would it make sense to consider adding support for nested items in a future/final version, to better align with TMF641 for composite/bundled services?
Custom API extension is of course always possible, but this one would change the payload and processing quite a lot, in my opinion.
- Or is rather the recommended pattern to model composite services in TMF645/TMF641 purely as a flat list of items + xxxItemRelationship?
Thanks in advance for any guidance or clarification.
------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------