Original Message:
Sent: Mar 28, 2025 11:21
From: Matthieu Hattab
Subject: TMF633 Service Catalog and service configuration specification
Hi Vance,
Always nice to see TMF Projects contributors join the community and share expertise!
I read the link you shared. Thank you, it very timely comment!
I stumbled upon this in TMF783:
I understand the meaning that TMF APIs are basically split in 2 groups:
- Task-based APIs (645 for service qualification, 679 for commercial qualification, TMF723 for Policy, TMF760! ...)
- -> These APIs initiate or manage a process that compute business rules rather than expose persistent, addressable resources
- Other APIs (620 for product catalogue, 622 for order...)
- These APIs manage data resources, no data computation, mostly like CRUD operation.
I have these questions:
- how shall we call this group of API that address resources. is "Entity-Based APIs" a good term?
- Why do we say Task-based APIs cannot expose persistent, addressable resources?
for instance, our product configurator is stateful, we store product configurations in the ODA TMFC027 database and we can query it:
GE T /queryProductConfiguration/{id}?fields=…&{filtering}
My 2nd and most important question 😊:
At time of order capture (<add> or <modify> product use cases), is it OK to use 760 for "service configuration"? (polymorphism could be handy here)
I would like to use 760 to automatically configure for "service configuration" based on product policies. Customer will not be able to change them in UI.
These policies are are governed by local laws, specifically for mobile subscriptions sold to under-13 or under-18 year old users (via their legal guardians) where regulations force us to set some service configuration at time of sale, before order goes to OSS.
Thanks!
------------------------------
Kind regards,
Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
Original Message:
Sent: Mar 26, 2025 01:42
From: Vance Shipley
Subject: TMF633 Service Catalog and service configuration specification
The Configuration and Profiling ABE is realized in the draft Configuration Profile Management API (TMF783), see AP-6713.
Once this is approved it shall be necessary to update TMF633 with a reference to ServiceConfigurationSpecification, which may appear something like this:
{
"@type": "ServiceSpecification",
...
"configurationSpecification": [
{
"id": "42",
"href": "/configurationProfile/configurationSpecification",
"name": "YourConfigurationSpecificaion",
"@referredType": "ServiceConfigurationSpecification"
}
]
}
Similar references will be needed in TMF638 for ServiceConfiguration and other APIs as the Configuration pattern exists in Product, Service and Resource domains.
I would encourage you to get involved in the TMF783 discussions.
------------------------------
Vance Shipley
SigScale
Original Message:
Sent: Mar 25, 2025 11:55
From: Tibor Ujszászi
Subject: TMF633 Service Catalog and service configuration specification
Dear All,
We are implementing a new Service Catalog, and we would like to specify the responsible Network Management System for a particulate RFSS, and its relavant characteristics. Is it possible to define this relationship with Configuration and Profiling ABE? How ServiceSpecification and ConfigurationSpecification could be depicted in TMF633 Service Catalog API?
regards
Tibor
------------------------------
Tibor Ujszászi
Magyar Telekom Plc.
------------------------------