Open APIs

Hi,

we are examining the use of TMF679 to determine which products to offer to a customer based on a) their geography and b) their existing services.  We can see that the geography can be represented in the 'place' collection of the product offering qualification but we can't see how we can pass the details of existing services in the POST request.  As an example, we want to know whether a customer has a copper phone service so that we know whether to offer our own copper based products but we may not be the existing provider so we can't pass a reference to a service inventory for example - we only have the customer's phone number that we can use to look up line availability etc.  Where in the model for requesting a product offering qualification can we pass technical details such as these?

In general is there any guidance on the dependency between product offering qualification and service qualification?  E.g. we can only offer customers certain products based on the connectivity services available at their premises or in their immediate locality.  So should the client call product offering qualification which in turn calls service qualification or should the client call service qualification and pass the result to product offering qualification?

regards,

Graeme.

------------------------------
Graeme Wilson
Zen Internet Ltd
------------------------------

Hi Graeme

The expectation is that an implementation of TMF679 (POQ) can invoke an implementation of TMF645 (SQ). This implies that the BSS layer (commerce) is capable of "understanding" the concept of service, either to construct a SQ request (product=>service), or to resolve a list of services returned by an SQ query (service=>product).
The high-level mapping between product and service is represented in the Product Catalog (TMF620), where ProductSpecification has a list of possible implementing ServiceSpecification.

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.
------------------------------

That's great Jonathan, thank you, POQ invoking SQ was the approach that we had taken so it's good to get some validation of that!

On my first question - passing technical details in the POQ request - do you think that we should just extend the model to accommodate these details?

regards,

------------------------------
Graeme Wilson
Zen Internet Ltd
------------------------------

Original Message:
Sent: Jul 14, 2021 10:01
From: Jonathan Goldberg
Subject: TMF679 Product Offering Qualification and Service detail

Hi Graeme

The expectation is that an implementation of TMF679 (POQ) can invoke an implementation of TMF645 (SQ). This implies that the BSS layer (commerce) is capable of "understanding" the concept of service, either to construct a SQ request (product=>service), or to resolve a list of services returned by an SQ query (service=>product).
The high-level mapping between product and service is represented in the Product Catalog (TMF620), where ProductSpecification has a list of possible implementing ServiceSpecification.

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.
------------------------------