Open APIs

 View Only

  • 1.  filter on sub-resources

    Posted Oct 19, 2022 07:46
    Hi,

    I read TMF630 but I didn't quite understand how I can add additional parameters to do some "filtering" on sub-resource.

    example: Party "ElectroButtik" (one of our distributors) wants to know applicable prices for a product.

    Our product catalogue has these data (snapshot)


    how can I add extra parameters in my request to tell my Product Catalogue component to only prices data related to:
    Party = ElectroButtik
    Place = North West


    GET .../productCatalogManagement/v4/productOffering/123*****Party.name = ElectroButtik*****Place.name = North West

    What would be the correct syntaxt?


    I expect this response:
    id = 123
    name = Wireless Broadband 100GB
    ...
    "productOfferingPrice": [
    {
    id = POP1
    name = setup charge
    },
    {
    id = POP10
    name = monthly charge
    }
    ]
    ...


    The most important aspect is that we need to keep fully compliance with TMF620 resource models.

    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------


  • 2.  RE: filter on sub-resources

    Posted Oct 20, 2022 01:45

    On Oct 19, 2022 07:45 @Matthieu Hattab wrote:

    |  how can I add extra parameters in my request to tell my Product Catalogue component to only prices data related to:
    |  Party = ElectroButtik
    |  Place = North West

    In your diagram you show a relationship between productOfferingPrice and ProductCatalog.  We'll have to assume this means that you have a collection of catalogs"

    GET /catalog
    [
       {
          "name": "Retail Store",
          "relatedParty": [
             {
                "name": "ElectroButtik",
                 ...
              }
           ].
          "category": [
             {
                "name": "ElectroButtik Retail Store",
                ...
             }
           ],
           ...
       },
       {
          "name": "Web Store".
          ...
       }
    ]             

    You would start your query using the appropriate Catalog which limits it to Product Offerings available in the ElectroButtik retail store.

    GET /productOffering?filter=category[?{@.name=='ElectroButtik Retail Store'}]

    To narrow it down the North West location add another filter:

    GET /productOffering?filter=category[?{@.name=='ElectroButtik Retail Store'}]&filter=place[{@name=='North West'}]

    To return just the productOfferingPrices add fields:

    GET /productOffering?filter=category[?{@.name=='ElectroButtik Retail Store'}]&filter=place[{@name=='North West'}]&fields=productOfferingPrice




    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


  • 3.  RE: filter on sub-resources

    Posted Oct 20, 2022 05:35
    Hi,
    Thanks for your reply and help on the syntax.

    We don't use categories and I see you use categories in your examples. (we will use categories in the future but they will be used to group product offerings by affinity, e.g. hardware, TV etc).

    In your examples, I don't see the product offering Id (123), so I suspect your call may return multiple product offerings.
    The starting point is that the distributor already knows:
    • the product name/id
    • the catalogue name/id
    • the place name/id
    • the Party name/id
     
    Can we just send parameters like:
    GET /productOffering/123?Filter=place[{@name=='North West'}]&Filter=Catalog[{@name=='Retail Store'}]&Filter=Party[{@name=='ElectroButtik'}]
    and let our server-side code do its magic (since our Product catalogue datamodel is different from the API resource model)
    Would that break any "compliance" with the TMF API?

    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------

    Original Message


  • 4.  RE: filter on sub-resources

    Posted Oct 20, 2022 06:12

    On Oct 20, 2022 05:35 @Matthieu Hattab wrote:
    | We don't use categories and I see you use categories in your examples.

    Yes, I provided an example of a /catalog collection to show your two catalogs (Retail Store, Web Store) and their related Categories which I invented for the example because this is needed to connect Product Offering to Catalog. The structure is Catalog -> Category -> Product Offering.

    In your draft you have a filter=catalog[{@name=='Retail Store'}] query parameter however there is no catalog, or party, attribute in the ProductOffering object. There is however a category attribute.

    You said
    | The most important aspect is that we need to keep fully compliance with TMF620 resource models

    ... so I tried to demonstrate how that could work.

    | and let our server-side code do its magic (since our Product catalogue datamodel is different from the API resource model)
    | Would that break any "compliance" with the TMF API?

    Of course your internal model will be different than the API data model, it would have to be!  The question is about whether you need to expose any of those implementation specific details on your TMF620 service interface. You can always use polymorphism to add attributes to objects, so you do do what you propose if you create a new @type MyProductOffering, with @baseType ProductOffering, and just add catalog and party attributes.  Is it compliant?  I guess so, as long as it doesn't force the use of these extensions for basic operations.

    It goes without saying that these are just my views, I don't speak for TM Forum.

    ​

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


Related Content