Ludovic,
Thanks for going back to this. I think we are on the same page:
I.e.
The client should not have to specify action on QueryXXXXQualification as query is, by definition, a search for possible solutions.
QueryXXXXQualification asks "What can I have?" without necessarily knowing what is in the current estate.
To be clear - I think there are cases where the client might wish to specify action, it should be optional, not removed.
From the ServiceQualification docs CheckXXXXQualification is not a search operation but the validation of a specific change against an extant configuration.
CheckXXXXQualification asks "Can I do this?"
Which implies the client
has knowledge of the current state of Products or Services and plans a specific update.
So we are dealing with specific updates and action is needed otherwise we cannot be precise about the change - so yes, I agree action is needed here.
To answer your question - the scenarios I am dealing with really fit the the Query mode. I would see them playing out like this (assuming a singleton PO).
Client performs Query[PO1, foo=bar]
and could get back QueryResponse[qualificationResult=Qualified, PO1, foo=bar, action=add] if they don't have the PO1 already
or they might get back QueryResponse[qualificationResult=Qualified, PO1, foo=bar, action=update, product/id=1234] if they have PO1 already and should update it
(obviously this is specific to the rules of a given product)
I.e. the Query response would fill in the action and maybe some other data so the client knows what to do.
If the rule was that you order the same product many times (not updating) they might always get back
QueryResponse[qualificationResult=Qualified, PO1, foo=bar, action=add]
every time.
If the rule was that they could either add to update I assume they could get back
Item[qualificationResult=Qualified, PO1, foo=bar, action=add] to add a new PO
Item[qualificationResult=Qualified, PO1, foo=bar, action=update, product/id=1234] to update the existing
(in reality we would probably include more data to nail down exactly what to do).
But all of these are really
Query use cases, for
Check it makes sense that action is mandatory.
Another thing that I noticed was ProductQualificationItems do not have children (i.e. embedded/nested ProductQualificationItems) whereas TMF622 ProductOrderItems can be nested. I think this is an oversight? I.e. if we have a BundledProductOffering or CompositeProduct with related POs, or want to qualify based on a CompositeProduct don't we need the nested structure?
Regards, Alasdair
------------------------------
Alasdair MacLeod
BT Group plc
------------------------------
Original Message:
Sent: May 17, 2021 10:50
From: Ludovic Robert
Subject: Query on semantics of TMF679 Product Offering Qualification Management
Hello Alasdair,
As previously stated we have the objective to align future Product Offering Qualification version with Service Qualification. Doing that we'll have 2 separate resources.
I'm aligned with your view with QueryProductOfferingQualification - It should not require action as the objective is to get a list of product offering available (and aligned with criteria passed in the request).
I'm a bit more concerned for CheckProductOfferingQualification because here we would like to manage more advanced UC where we want to check if we can add a product in relationship with existing, change an existing product (changing relationship, characteristic value) or event terminate a product. The action field is required for this, or, at least explicit the requester-intend. (If a product.id is present, is it a product to change or to terminate or only pass as reference ? The action will provide the answer).
In your example - if I already own PO1 with foo=xxx - and request CheckPOQ for PO1 with foo=bar how do you understand if I want to change existing or a new instance of PO1? You need to explicitly pass the action and pass the product.id for change (or the server has to understand this is a change because there is a product.id ....which is not trivial) - and in both case need to look on your inventory.
For me, action is missing in CheckServiceQualification and should be re-introduced, but this is a good topic to be discussed in API team.
Thanks,
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: May 13, 2021 12:13
From: Alasdair MacLeod
Subject: Query on semantics of TMF679 Product Offering Qualification Management
Picking up this thread again. I think my point was obscured by too much wordy explanation. I will try and be more precise...
The a client of Product Qualification cannot simple ask "can my customer have YXZ (with some constraints)", the client is forced to say "can my customer add XYZ" or "can my customer update XYZ", in effect the client must inspect the customer's estate and work up the order actions for a product. The schema forces this because action is mandatory and there is no don't care term value - the client must decide if the scenario is an add|update|noChange|delete. There are cases where this is overly prescrptive.
I notice the Service Qualification API does not include an action on Service Qualification Item and so can avoid this problem. As Product Qualification will be aligned with Service Qualification can I assume that future versions of the Product Qualification API will remove the action field or at least make it optional?
------------------------------
Alasdair MacLeod
BT Group plc
Original Message:
Sent: Feb 25, 2021 02:16
From: Ludovic Robert
Subject: Query on semantics of TMF679 Product Offering Qualification Management
Hello Alasdair,
First we have the plan to align ProductOfferingQualification with ServiceQualification API Pattern in order to clarify. We'll have 2 resources: CheckProductOfferingQualification which globally w'll have same structure than today ProductOfferingQualification and must be use for precise request and get a response for the eligibility (with alternate). We'll introduce a QueryProductOfferingQualification resource - this one fetaure search criteria abd the response will list all available/eligible PO matching your criteria.
Now to your questions : For me right now it is impossible in this API to go further than providing alternate. You can query for a new product offering (or a set of them) and get result & alternate, you can also pass existing product(s) and check configuration change, you can mix both (I want this offer in this commercial bundling thant I own).
I'm wondering if your requirement will no be close to some kind of 'Configuration API' that manage a whole configuration and assess all rules (even pro actively) to indicate all possibilities. It could be done from scratch (new API) or an evolution of today POQ (as you suggested) but we did not put some thought onthis within the API group already.
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Feb 24, 2021 12:15
From: Alasdair MacLeod
Subject: Query on semantics of TMF679 Product Offering Qualification Management
Hello,
I would be grateful if someone could pass their eye over this and (hopefully) concur.
A ProductOfferingQualificationItem is a request to do something with a ProductOffering.
The productOffering, product or category field identifies the PO either exactly or in the latter two cases by defining constraints/grouping.
The action (of type ProductActionType) defines the action we wish to take.
"add" would mean we want to add/create on of these Product Offerings.
"modify" would mean we wish to make some change to an existing product
"delete" to delete/cease/end service.
If we sent a ProductOfferingQualificationItem[PO1, add] and the system does not allow the PO to be added then the qualificationItemResult would be unqualified.
If, in the above scenario, the system wanted to suggest the client use an existing product (e.g. in some modify scenario) how would the API express that?
I assume additional characteristics or relations imply something common between the add request and the existing product.
Would it be a ProductOfferingQualificationItem like this?
{"productOffering" : "PO1"
"action" : "add"
"qualificationItemResult" : "unqualified" <-- which means "you can't have this"
"eligibilityUnavailableReason " : "some meaningful code for this scenario"
"alternateProductOfferingProposal" : [{"alternateProduct" : {details of the existing product go here}}] <-- which means "have a look at this"
I.e. we say "no you can't add, but look at this existing product that can meets your needs in some way.
I assume the exact interpretation would rely on eligibilityUnavailableReason codes specific to the application.
If, in our scenario, we wish to say "you can add the PO but you must delete this existing product" Might we do this?
This might be straying beyond what the authors envisaged - but is it at least consistent with the definitions?
{"productOffering" : "PO1"
"action" : "add"
"qualificationItemResult" : "qualified"
"qualificationItemRelationship" : [{some relation to the item below}]}
{"productOffering" : "PO2" <-- this item was not in the request but the system has included it in the response to indicate the thing that must be deleted.
"product" : {"id" : "some identifier for existing product"}
"action" : "delete"
"qualificationItemResult" : "qualified" }
Many thanks for anyone who got this far! Alasdair
------------------------------
Alasdair MacLeod
BT Group plc
------------------------------