Open APIs

Expand all | Collapse all

AllowedProductAction

  • 1.  AllowedProductAction

    TM Forum Member
    Posted Sep 25, 2019 00:54
    Hi All,
    The product SID document defines an AllowedProductAction which can be associated with a ProductOffering.
    Unfortunately, the product catalog apis doesn't have a placeholder for this. The product ordering apis on the other hand has an "action" for an orderItem. So we can say a product offering needs to be bought (add), changed (modify), terminated (delete). I assume these two are related.

    We're trying for a use case of suspending a product with a price implication. There are a couple of design thoughts in our head

    1. Introduce allowedProductAction in ProductOffering with a product action type as "suspend". Pass this on to orderItem.action. Needs to have a linking to a price for suspension.

    2. Introduce allowedProductAction + subAction in ProductOffering. action would be "modify" and subAction would be "suspend". Pass action and subAction to orderItem (add subAction field in orderItem). The question here compared to point 1 is whether we can introduce new actions apart from the usual ones (add, modify, delete, noChange) defined in many of the TMF documents?. If not, we might have to resort to a subAction. Needs to have a linking to a price for suspension.

    3. Introduce allowedProductAction in ProductOffering with action type as "modify", but when we send to order management, use action="modify" with orderItem.product.state="suspended". This looks cleaner. Compared to the above two, it is not very clear how we can link a price to a state change of a product.

    Is there any other way to do this and if not what would be a better approach from the above list?

    ------------------------------
    Shibin CK
    Tecnotree
    ------------------------------


  • 2.  RE: AllowedProductAction

    TM Forum Member
    Posted Sep 25, 2019 09:43
    Hi Shibin
    It appears that you have some good ideas here
    • Adding allowed action types as an array to the product catalog (spec or offering). We should consider this as a CR on TMF620 catalog api.
    • Similarly relating a price to a specific action is missing (I think) from the catalog, again could be considered as a CR

    Regarding suspend (or resume, the reverse of suspend) is tricky, because there are many types of suspend (customer request, collection/dunning, fraud), and these might have different pricing implications. Needs more detailed study.

    In general, you are free to extend the Open API model, provided that you follow the guidelines for extension.

    Adding @Ludovic Robert for his thoughts, since he "owns" product order and product inventory.​

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



  • 3.  RE: AllowedProductAction

    TM Forum Member
    Posted Sep 27, 2019 18:55
    Re: "Similarly relating a price to a specific action is missing (I think) from the catalog, again could be considered as a CR"  ...  Could the model already support this? I mean could we instead of modifying SID getting this done by triggering an event due to a specific action like order change (suspend type)?

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



  • 4.  RE: AllowedProductAction

    Posted Sep 30, 2019 02:00

    Hi Shibin,

    Please see my comment below.... Oscar>>>

    Hi All,
    The product SID document defines an AllowedProductAction which can be associated with a ProductOffering.
    Unfortunately, the product catalog apis doesn't have a placeholder for this. The product ordering apis on the other hand has an "action" for an orderItem. So we can say a product offering needs to be bought (add), changed (modify), terminated (delete). I assume these two are related.

    We're trying for a use case of suspending a product with a price implication. There are a couple of design thoughts in our head

    1. Introduce allowedProductAction in ProductOffering with a product action type as "suspend". Pass this on to orderItem.action. Needs to have a linking to a price for suspension.

    Oscar>>>TMF622 Product Ordering Management has paymentRef linked to an OrderItem, AllowedProductAction value can always be emunirated/addend in an temp array because i don't believe that generally  'Order action types' are part of the  a Product Catalog schema, However i do agree that the generic "Common language value"  are a limitation for other use case.

    2. Introduce allowedProductAction + subAction in ProductOffering. action would be "modify" and subAction would be "suspend". Pass action and subAction to orderItem (add subAction field in orderItem). The question here compared to point 1 is whether we can introduce new actions apart from the usual ones (add, modify, delete, noChange) defined in many of the TMF documents?. If not, we might have to resort to a subAction. Needs to have a linking to a price for suspension.

    Oscar>>> You are referring a lot to ProductOffering but i believe you are referring to ProductOrdering resource because the is no TMF Schema where a productoffering is linked to an orderItem and even if it was a case of ProductOrdering.action, you wouldn't want  add an "action" as part of an Overall order because it is misleading and contradicts the "State" of the order.   TMF622 Product Ordering Management has paymentRtoef linked to an OrderItem

    3. Introduce allowedProductAction in ProductOffering with action type as "modify", but when we send to order management, use action="modify" with orderItem.product.state="suspended". This looks cleaner. Compared to the above two, it is not very clear how we can link a price to a state change of a product.

    Oscar>>> I have different view on above adding in Product Offering!?

    Oscar>>>Suggestion, to fulfill your Use Case  what you need to do is to add your product offer(As understood by your organisation) as an orderItem as guided in TMF622 .

    ProductOrder
     --> OrderItem.id ="001"
     --->OrderItem.@type ="ProductOffer/ProductOrder" | This OrderItem can be included in every request as an overall orderactiontype depending on the type of change
     -->OrderItem.action ="modify"

    --> OrderItem.id ="002"
     --->OrderItem.@type ="Product"
     -->OrderItem.action ="suspended" / orderItem.product.state="suspended" however adding "state" as name value pair

    Oscar>>>Above ensure the Openness of the API, implementation may be easier for other organisation and challenging for other however, we still retain the Openness of the resources

    Is there any other way to do this and if not what would be a better approach from the above list?

    ------------------------------
    Shibin CK
    Tecnotree
    ------------------------------



    ------------------------------
    Oscar Morei
    Telkom SA
    ------------------------------



  • 5.  RE: AllowedProductAction

    TM Forum Member
    Posted Sep 26, 2019 03:42
    hello Jonathan,

    I have a question to your view on adding Allowed action types as an array to the product catalog (spec or offering) as below.

    Apart from an extension to the API will this be also considered as an addition on Information Model (SID) for Product offering or Spec, as we intend to include this on our Enterprise Product Catalog ?

    Kind regards,

    ------------------------------
    Shreyas Madwanna
    Tech Mahindra Limited
    TMForum Career Certified Professional
    ------------------------------



  • 6.  RE: AllowedProductAction

    TM Forum Member
    Posted Sep 26, 2019 03:54
    In general, the Open API model is derived from the SID with adjustments and simplifications reflecting the different purposes of the models (the Open API model needs to reflect input and outputs from business APIs).
    If we make significant enhancements to the Open API model that are not already present in the SID, we try to get them approved by the SID team so that the SID can be adjusted as well.

    In this particular case, the SID already has a relationship from PO or PS to AllowedProductAction, which in turn has a ProductActionType with the name of the action. The SID does not however have a closed list of action types. The Open API has collapsed these two entities into a single entity ProductActionType and given a closed list of action types.

    Hope it helps

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



  • 7.  RE: AllowedProductAction

    TM Forum Member
    Posted 7 days ago
    @Jonathan Goldberg Hi , I was going through you posts . We have a requirement to model ,Allowed Product Action  for Product Offerings  , As per SID model , the Product Action Type is treated as a separate Entity , rather than ,  as an attribute of  Allowed Product Action Object  .  so is there any specific reason why we are considering Product Action Type as an separate Entity  , and not modelling is a an attribute with  list of  Action Types , to be modelled on Allowed Product Action .​

    ------------------------------
    alok pradhan
    Netcracker Technology
    ------------------------------



  • 8.  RE: AllowedProductAction

    TM Forum Member
    Posted 6 days ago
    Edited by Jonathan Goldberg 6 days ago
    Hi Alok
    I don't know how to explain the SID model. I can tell you that in the path between SID and Open API we often make simplifications so that the API model will be easier to use. If and when we make this enhancement to TMF620, we'll have to consider whether to make the action a separate entity or simply a closed (or open) list of strings.
    Watch this space :)
    Hot off the press, a CR has been raised for this, if you are a member of the Open API project you can see it here: https://projects.tmforum.org/jira/browse/AP-2519

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