Hi Myagaa
You raise a valid question, and I don't have a good answer. To make it concrete, how is a UI/engagement management/validation component supposed to "know" that for a wireline product an installation address is mandatory while for a wireless product it is irrelevant. I would go further, how is the component supposed to know that a given RelatedPlace is actually an installation address?
I clearly cannot explain to you how we do this in Amdocs, that would be "leaking" our intellectual property. All I will say is that, like CSPs and other vendors, we extend the Open APIs where needed to match our business aims. And in many cases we have suggested our improvements as enhancements back into the standard. In this particular area we have not done this, and I don't know if we will.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Dec 10, 2023 08:47
From: Myagaa Nm
Subject: Product catalog driven validation in POCV component and engagement management
Hi Jonathan,
My idea is that if product catalog provides an offer and its mandatory fields (characteristics, related parties, place so on), an engagement app can draw what fields are mandatory. According to product offer in product catalog, I only can provide characteristics as mandatory fields using cardinalities. But for other fields like relaties parties (with roles) and place so on, I can't provide mandatory marks in the offer in product catalog. How can I provide the marks for mandatory fields in the offer? I mean that should I extend the product offer to store marks for mandatory fields in the product offer? If I provide the marks, one of SOR components like pocv or product configurator (you suggested) can validate request from the engagement app using the product offer in the product catalog and its the mandatory marks. How far is my idea from solutions of implementers of tmforum like amdocs? :)
------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
Original Message:
Sent: Dec 10, 2023 07:16
From: Jonathan Goldberg
Subject: Product catalog driven validation in POCV component and engagement management
Hi Myagaa
The ProductConfiguration API TMF670 (https://www.tmforum.org/oda/open-apis/table) might be just what you are looking for. It saves the consumer the work of doing the validation against the catalog model. Of course you need to implement it, so there are no short cuts, but it does put the logic in the right place, in a backend pocv ODA component, rather than in the front-end or engagement layer.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Dec 07, 2023 06:51
From: Myagaa Nm
Subject: Product catalog driven validation in POCV component and engagement management
Hello,
If product offer provides what engagement management fills mandatorily, the engagement management can draw UI and check validation itself. Also, when pocv validates order request, it can use the product offer to validate what should be mandatory in the order request. However, I think product offer only can provide min, max cardinality for characteristics. How can I validate offer's related parties, places, agreement in order request to validate in pocv? How should I provide same validation for engagement and pocv?
------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
------------------------------