Short Answer:
The examples provided by TMF are just starting points to help you understand the basic interactions between ODA components.
You have full flexibility in deciding how and when to use these components and their APIs.
Long Answer:
Understanding ODA Components:
It seems like you're trying to understand two key aspects:
- Orchestrating ODA components effectively (this is the secret sauce for a great composable architecture, IMHO)
- Interdependencies between ODA components – Understanding how each component consumes and interacts with others is essential for "internal" orchestration (done by the ODA component itself, typically those dependent APIs that are listed in each ODA specification).
Since your post contains multiple detailed/short questions, I'll just address some key ones:
Question:
"My main question is, which ODA component is responsible for ensuring that Product Offering Qualification (POQ) and Service Qualification (SQ) match? Is it POCV?"
Answer:
- TMFC027/POQ and TMFC009/SQ compute qualification rules and return a qualification status.
- TMFC003 is responsible for orchestrating these service APIs
To use a metaphor:
- TMFC027/POQ and TMFC009/SQ are like the violinist and pianist playing their parts.
- TMFC003 (or any orchestration engine) is the conductor, ensuring they perform in harmony.
Question:
"Is this check missing in this example below?"
Answer:
No, it's not missing. TMFS003 documentation and sequence diagrams indicate that it "follows TMFS001 and TMFS002." This suggests that the author may have assumed TMFC027/POQ was handled in TMFS002.
However, if needed, you can configure TMFC003 to also orchestrate TMFC027/POQ. It depends on your specific architecture and requirements.
Question:
"Our purpose is to display only commercially and technically valid offerings. I assume it is ultimately POCV's responsibility to revalidate that in these outputs CFS->PS->PO matches?"
Answer:
TMFC003 should not be involved.
A useful reference for this is TMFS002, which provides guidance to show only valid offerings.
but I understand BSS can be very "composed" (not composable) and requires the product offering to be in the cart/order before further computations (qualification, configuration, pricing, recommendation....), in which case, you do have to use TMFC003.
💡 In TMFS002, the orchestration is handled by a BFF (Backend for Frontend) rather than TMFC003. This is just one possible approach. You could also use a data orchestration engine, Digital Experience Orchestration engine, or other modern alternatives.
Question:
"What happens when the PC receives a task to create a product configuration, but POQ has not been performed beforehand? Does it generate an error back, or does it perform the POQ itself if it hasn't been done yet?"
Answer:
This behavior depends entirely on your TMFC027 implementation.
In our case:
- Our TMFC027/Pcfg does not trigger TMFC027/POQ or TMFC009/SQ for the root product (the one selected by the customer from the offer list).
- This is because the root product was already qualified during the previous user experience phase: "show offer list" (I call this "prepick eligibility").
However:
- If the computedProductConfiguration includes CFSS or bundle components, then TMFC027/Pcfg may need to orchestrate TMFC027/POQ or TMFC009/SQ as part of the product configuration process when customers interact with the PcfgUI.
- For instance, our Altibox Extra bundle includes an optional Viasat Total channel package. TMFC027/Pcfg may need to orchestrate TMFC027/POQ to check if customer is eligible to buy Viasat Total. This can be done in prepick (before customer select Viasat Total, what you call "beforehand") or postpick mode (= after customer selected Viasat Total). We do prepick because we believe it offers a vastly superior user experience.
My 2 cents,
------------------------------
Kind regards,
Matthieu Hattab
Lyse Tele AS
------------------------------
Original Message:
Sent: Feb 18, 2025 04:24
From: Reet Meier
Subject: ODA Components responsibilities and functional boundaries
Hi ODA component experts,
I am seeking some clarification regarding the boundaries between the ODA components of Product Configurator (PC) TMFC027 and Product Order Capture and Validation (POCV) TMFC002 microservices.
I am trying to understand the responsibilities outlined in the following:
POCV Functional Framework 727 Product Offer to Customer Verification 2
Product Offer to Customer Verification enables and verifies the configuration of the commercial offer chosen by the customer.
The configuration consist of technical, functional, and commercial prerequisites and preferences.
1 TMFC027 Product Configurator covers the part related to Product Catalog rules checking. Stock control part is done by TMFC002 Product Order Capture & Validation
2 TMFC027 Product Configurator covers the part related to Product Catalog rules checking at commercial and functional eligibility levels. Technical eligibility controls are triggered by TMFC002 Product Order Capture & Validation
My main question is, which ODA component is responsible for ensuring that Product Offering Qualification (POQ) and Service Qualification (SQ) match? Is it POCV? According to TMFS003, POCV checks if an offer is valid from the catalog TMF620 perspective and compares the service specifications.
However, it does not ensure that the POQ is done for the same catalog tree and offeringId?
Is this check missing in this example below or is it done within the PC if someone starts product configuration without performing POQ first or still POCV needs to trigger POQ also if it is not done?
Our purpose is to display already only commercially and technically valid offerings (e.g.internet availability at a given location and goods in stock) on our website, so we should perform SQ and POQ by Engagement first. However, I assume it is ultimately POCV's responsibility to revalidate that in these outputs CFS->PS->PO matches?
What happens when the PC receives a task to create a product configuration, but POQ has not been performed beforehand? Does it generate an error back, or does it perform the POQ itself if it hasn't been done yet?
Your insights on these points would be greatly appreciated.
------------------------------
Reet Meier
Telia Eesti AS
------------------------------