Open APIs

 View Only
Expand all | Collapse all

Product Compatibility Rules

  • 1.  Product Compatibility Rules

    Posted Jun 06, 2019 16:15
    Hi,

    This is my first involvement with the Product Catalog API, and we've made a fair stab at modelling significant portions of our ProductSpecification and ProductOffering resources and mapping from our legacy catalog. 

    I would like to know how product compatibility rules are supposed to be modelled into the Product Catalog API, should they be modelled into the ProductOffering specification or should they be modelled into another Entity? How do other operators achieve this for purposes of supporting catalog exchange or Configure-Price-Quote (CPQ) capabilities?

    Regards,
    Edwell

    ------------------------------
    Edwell Dombodzvuku
    Aesopia
    ------------------------------


  • 2.  RE: Product Compatibility Rules

    Posted Jun 13, 2019 11:23
    I second this question.  We have been implementing the rules to execute from Product Order when a product is added, but I am not sure this is the intended way.  We do have product incompatibilities being returned from Product Catalog.  I am not sure the exact details.  But these and other rules are also executed during product order patch calls.

    ------------------------------
    Al Bastien
    IBM Corporation
    ------------------------------



  • 3.  RE: Product Compatibility Rules

    TM Forum Member
    Posted Jun 14, 2019 02:18
    ​Let me share my thought,

    Rules applied on catalog enities are primarily to used for run time activities e.g. browsing the catalog. 
    Rules can used to cater various business scenarios , some of them are listed below
    1) To make PO available based on customer type, market segment , geography etc
    2)  use cases , where product Offerings (product) have dependency (affinity or inaffinity relations) . e.g. International roaming pack only available with base plan , purchase of offer only allowed if similar offer is expired etc. The scenarios , for me will make use of compatibility rules.

    Rules extend the dyamic nature of catalog and to make it more flexible for operational use. 

    For the reasons, my first inclination to attach rules at PO level.

    ------------------------------
    Ashish Doodhwala
    Ericsson Inc.
    ------------------------------



  • 4.  RE: Product Compatibility Rules

    TM Forum Member
    Posted Jun 19, 2019 12:14
    Hi

    Thanks for these posts raising the need to deal with rules in catalogs.

    The Open API team believe that rules should be handled as an external set of entities called Policy. We have the intention to introduce a Policy API to deal with management and execution of Policy rules (based on the SID Policy ABE model). Clients of Policy, such as Product Catalog management, would include references to Policy as part of their model. And as you correctly point out, these policies would be executed in runtime - for instance product catalog policies would be executed as part of the sales and order capture process.

    The specific use case for product offering qualification is covered by an existing API, TMF 679, I advise you to examine that API to see if it meets your needs (the API table is available at https://projects.tmforum.org/wiki/display/API/Open+API+Table).

    Since we do not yet have a concrete plan for this enhancement, we advise you to make an extension in your specific implementation of the catalog API.

    Hope it helps



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 5.  RE: Product Compatibility Rules

    Posted Jun 24, 2019 08:55
    Hi Jonathan Goldberg,
         It is good what you said in your previous post "The Open API team believe that rules should be handled as an external set of entities called Policy. We have the intention to introduce a Policy API to deal with management and execution of Policy rules (based on the SID Policy ABE model)". 
    However, it could be some incongruencies the team should look around in SID. For example, if you look into the "GB922_Product_R18.5.1" document, there is a whole section that talk about Policies rules and how this is applied to calculate the prices of a whole Product Offering Price Rule: "The price of a ProductOffering is governed by a PolicySet.  The PolicySet may be a single PolicyRule or a PolicyGroup which ties together a number of PolicyRules.   The use of both single rules and grouped rules will be explained via examples."

    Having a first OPEN API docs like the one you mention is good, (API, TMF 679,) however without a proper support inside the information model (SID) it is partial solution.

    Cheers.

    ------------------------------
    santiago lorente
    Pegasystems, Inc.
    ------------------------------



  • 6.  RE: Product Compatibility Rules

    TM Forum Member
    Posted Jun 26, 2019 02:25
    We are aware of the SID Policy model, which follows the ECA paradigm (Event, Condition, Action), and we have also seen alternative models.
    A concrete proposal for how the Policy model should appear in the Open API will depend on a more detailed analysis of use cases and flows, that is part of the API design process.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 7.  RE: Product Compatibility Rules

    Posted Jun 26, 2019 09:09
    Thanks Jonathan 
       it will be nice if you can post here a link to the roadmap for adopting these capabilities in a timeline.

    Cheers.


    ------------------------------
    santiago lorente
    Pegasystems, Inc.
    ------------------------------



  • 8.  RE: Product Compatibility Rules

    TM Forum Member
    Posted Jun 26, 2019 10:57
    I don't think it would be appropriate for me to make any promises regarding timelines - I am an (active :)) member of the Open API team but I am not a leader. The API design work is done according to priorities set by the team leadership and availability of the team members (from CSPs and vendors).
    I refer you to the chief Open API architect @Pierre Gauthier ​​who might be able to give his ideas of the vision in this area.
    Hope it helps.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 9.  RE: Product Compatibility Rules

    Posted Jun 27, 2019 11:38
    Product Compatibility is not the only place where policy rules could be used; I have recently been thinking about the need to describe compatibility of hardware components and the need for policy rules to provide a limit or sanity check on the output of AI processes. It is good that the SID places policy in a ABE so that a common policy approach can be used for both Product and Resource problems. However the policy SID ABE has not been revised for some time and I question how widely it has been implemented.


    It may be time to try using the common policy on two or more use cases, and either document how to use the policy structure or raise change requests on it.

    ------------------------------
    Paul Jordan
    BT Group plc
    ------------------------------



  • 10.  RE: Product Compatibility Rules

    TM Forum Member
    Posted Jun 27, 2019 12:11
    Completely agree - the purpose of having a separate Policy API would be so that the concept can be re-used wherever relevant. Product Catalog was intended to be the first API to have used this. But as explained already the whole topic is pending at the moment.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 11.  RE: Product Compatibility Rules

    TM Forum Member
    Posted Jul 01, 2019 16:11
    Folks the topic of Policy  and /or businesss rules comes up from time to time but seems to atop short of a specific set of concrete recommendations
    Prior work on Policy includes 
    In
    TR255B Specification Requirements for Resource Functions R17.5.1  Sec 3.4
    We  needed a way t odescribe service constraints in provisioning Connectivity Services i.e. which features and feature groups are compatible. Note the concept of feature was introduced for Resource Functions but works equally well for CFS and Products. What  was interesting is that we used eBNF to do this which has an advantage that it describes a syntax but without defining a specific Policy Language for which there is quite a bit of diverse industry opinion. Use of eBNF mean in an implementation one could simply describe how you favorite policy language support the rules expressed in eBNF

    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------



  • 12.  RE: Product Compatibility Rules

    Posted Jul 02, 2019 05:03
    Thanks Dave
       The documents you mentioned before are mainly focused on RFS, mostly network related.
    This discussion started focussing more in the catalogue SID information model then we extended to a More general model for supporting the rules but still w need support for these.
    Cest passing possible defior a telco catalogue without those rules: eligibility compatibility etc.
    Then we are kind to hear your view in these area.

    Cheers  






  • 13.  RE: Product Compatibility Rules

    TM Forum Member
    Posted Jul 02, 2019 08:44
    Whilst the examples are RFS based note that the approach based on features and feature compatibility applies at CFS level too and products are composed from CFS. the key thing is about the kind of syntax to express policy.  That's always been the stumbling block. The nouns it applies to will be quite varied and we are seeing catalysts policies that span network levels and use external information such as location and weather to make service and resource policy decision. So one requirement is a common policy approach that can be used across the whole of the SID.

    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------



  • 14.  RE: Product Compatibility Rules

    Posted Jun 28, 2019 11:29
    @Paul Jordan I totally agree with you, except that we have the chance to review the current common policy model for all the use cases​ available at this time (vs a couple of them) to assure the model is robust enough to support current and futures needs.

    Cheers.

    ------------------------------
    SANTIAGO LORENTE
    Pegasystems, Inc.
    ------------------------------