Open APIs

 View Only

  • 1.  ProductSpecCharacteristics

    TM Forum Member
    Posted Sep 16, 2019 02:01

    Hi All,

    I have a couple of questions regarding product characteristics.

    Assume there's an MSISDN Product Spec. This will have an "msisdn" number productSpecCharacteristic.

    In the CRM system, we have an option of choosing msisdn number via 3 methods.

    1. Automatic. In this case, the msisdn number has to be fetched automatically from resource inventory.
    2. Manual. In this case, User may be able to specify his chosen suffix.
    3. Token. In this case, User might give a token with which he has reserved an msisdn number.

     

    1. My question is, does it make sense to model this as a "SelectionType" characteristic with values such as "Automatic, Manual, Token" along with productSpecCharRelationship? or should it not be part of product characteristic as it is only used to fetch the characteristic during product purchase?. In the latter case, is it related to ProductConfiguration from SID. (I admit that I've not explored the configuration part).
    2. How will the CRM know that msisdn has to be fetched from a resource inventory if we are going by a catalog driven model where CRM doesn't want to hard code msisdn product logic?. Should it traverse from ProductSpecification to ResourceSpecification and figure that out?
    3. How is characteristic linking between Specifications at different layers defined in OpenAPI?. E.g.

    In the SID Product document, there's a MailBox product with "MailBoxSize" as a product characteristic with values as "Basic" and "High Volume". In CFSSpec, these values translate to "10MB" and "20MB". But how is the char/charValue in product domain and service/resource domain linked in the api data model?

     

     

    -shibin



  • 2.  RE: ProductSpecCharacteristics

    TM Forum Member
    Posted Sep 18, 2019 04:15
    Hi Shibin
    1. The selection type can influence the price, one can imagine that a manually-specified logical resource might cost more than an automatic resource. For this reason it can make sense to retain as a product characteristic. However I would agree with you that there is a case for allowing characteristics at Order level that don't need to be persisted in the inventory. This would require enhancements in the Open API model and also in the underlying SID information framework.
    2. If you indeed choose to model selection type as a Product characteristic, then the CRM system will have the information in the catalog model, as a product spec characteristic. You would still need code in the CRM system to understand the semantic meaning of these valid values (auto, manual, token).
    3. I am not sure that we have a good solution in the API model for characteristic mapping - we have the mapping at the level of specification (product spec is implemented by service specs and resource specs) but not for characteristics. The SID has explicit mapping between product characteristics and service (or resource) characteristics, and even between values. Probably this needs to be enhanced into the Open API model, and I have opened a JIRA issue to document this.
    Hope it helps

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

    Original Message


  • 3.  RE: ProductSpecCharacteristics

    TM Forum Member
    Posted 26 days ago

    Hi Shibin,

    Let me provide my personal opinion on your questions.

    1. It looks like as of today you have 3 different strategies to select the MSISDN and probably in the future you may have additional strategies as well. To me this requirement can be solved with the "Strategy Pattern" where you can select the software code that needs to run during the runtime. Your CRM should be able to use such a pattern so that whatever strategy you want to execute based on the SelectionType characteristic value is selected by the end user. I wouldn't recommend you to define hard coded solutions to this need because we all know that these requirements will evolve and you will have more strategies.

      2. Part of your second question is answered (I believe) with my above answer: use the Strategy Pattern in your software and plug in new strategies as you add new ways. Coming to the second part of this question where you're asking how to propagate the the selected MSISDN value (or the selection of MSISDN business logic) to the Service or Resource Order level. My personal opinion is that there should be a way to map Characteristics and their Values to lower and upper levels. In the mapping you may need to specify the direction of the mapping (because in some cases you will want the characteristic value be selected by the Resource Order fulfillment logic, or in some cases you will have the end user select the value and pass this selection down to the Resource level). A solution to this is to use charSpecRelationship properties of the CharacteristicSpecifications. You are able to map the characteristics across Product, Service, and Resource Specification levels and use these mappings to pass values between Product Order, Service Order, and Resource Orders during their fulfillment. Your order managers can detect these kind of relations between characteristics and values and can create the lower level orders with these informations populated (if you're passing from Product down to Resource level) or you can read the assigned characteristics values from the completed orders by the upper level order (e.g. if an MSISDN is automatically assigned by a Resource Order then the selected MSISDN can be read by a Service Order that initiated a Resource Order and waiting that the Resource Order is completed with an assigned MSISDN characteristic value).

      3. The Characteristic Linking between Specifications (to me) is the charSpecRelationship property on the characteristic specification. However, the unfortunate part of this is that on the Open APIs the Characteristic Specifications are not defined as sub-resources, nor they have their own unique IDs that you can refer to. In our solution we have extended the Open APIs to assign some unique IDs to these characteristics specifications so that we can refer to them during our mapping between characteristics and their values. 

    I hope I could answer some of your questions.

    Roy



    ------------------------------
    Dr. Roy Kucukates
    LotusFlare
    ------------------------------

    Original Message