Open APIs

Hi all,

We are trying to come up with TMF model for POTSOLVE product and export it in TMF 622 Open API compliant format. Sample product model for the same is depicted below (For the sake of simplicity, prices are ignored from the diagram, though they are present on the child product offerings like Analog Hardware, Onsite Install etc. BundledProductOfferingOption is depicted as cardinalities on top of the bundledProductOfferings for the sake of simplicity E.g. 0..20 meaning numberRelOfferLowerLimit = 0 and numberRelOfferUpperLimit = 20):

We have few characteristics which are common to all these child product offerings (List of characteristics below) and expected to be provided as input as part of the product order. These also need to be passed on to downstream activation and provisioning systems as they have provisioning impact, hence I believe should be present on CustomerFacingServiceSpecs as well?

• Building Address
• Demarc Point
• Contact Name
• Contact Email
• Contact Phone

How should we model such characteristics as per TMF best practices? Options -

Option 1: Create these characteristic specifications on each of the component Product Offerings and their ProductSpecifications in above model using ProdSpecCharValueUse and prodSpecCharacteristic respectively and further model them on CustomerFacingServiceSpec as well

Will result in proliferation of characteristics and with some magic rules needed in Ordering to request input for only one of those product offerings and copy values to others

Option 2: Create these characteristic specifications on each of the child Product offerings in above model using ProductOfferingCharValue and further model them on CustomerFacingServiceSpec as well (Don't model on ProductSpecification)

Will result in proliferation of characteristics and with some magic rules needed in Ordering to request input for only one of those product offerings and copy values to others

Option 3: Model a Product Specification for POTSOLVE SingleDemarcService product offering and its CustomerFacingServiceSpec as well and follow Option 1 or Option 2 for modelling characteristic specifications at ProductOffering, ProductSpecification and CustomerFacingServiceSpecification or at ProductOffering and CustomerFacingServiceSpecification only.

We could observe that Open API doesnt restrict us from creating a Product Specification for Product Offering (IsBundle = true), but SID doesn't incline to this thought.

Option 4: Create another mandatory child Product offering under "POTSOLVE SingleDemarcService" which will house all these characteristics as per option 1 or option 2

What could be best possible way forward here? Or are there any better alternatives?

On a side note, we have a fulfillment characteristic (Tracking ID) too which will be modelled at Product offering since its visible to the customer but the value will not be received until it is not filled in by provisioning systems. 

One more question, the can the cardinalities mentioned in BundleProductOfferingOption (e.g. 0..20) translate into single ProductOrderItem with quantity mentioned in ordering, meaning lets say, customer buys 10 instances of Analog Hardware, what could it translate to ?

• One ProductOrderItem (with quantity = 10) and Product instance in ProductOrder and ProductInventory APIs respectively, or,
• 10 ProductOrderItems having their own respective Product instances in Product Order and ProductInventory APIs respectively?

What is suitable/advised/possible/recommended as per TMF under which scenario?

------------------------------
Varun Pandhi
Infosys
------------------------------

TL;DR,

I wouldn't expect a building address for a virtual line...

assuming that the end-to-end process is done with orders, (product order, service order, ressource order). generic info about customer must be on the order header (we do that for customer data, which we never "store" at characteristic level).
your core commerce and Production domain should use the data available at order header level.

in IG1228 and GB922 Product , there are examples of product models that could inspire you.

you will see in these documents that there relationships between productspec can define dependencies: PS B requires PS A, which can help you normalise your characteristics.

Thanks Matthieu, this helps. But, there can be other cases as well where customer address might not point to exact location where service is to be installed and/or the contact details being passed on here be the contact details of end user and not some contact related to customer.

And, also would be great if someone can throw some light around interpreting cardinalities defined between product offerings in TMF 620 and interpreting in TMF 622 -

Can the cardinalities mentioned in BundleProductOfferingOption (e.g. 0..20) translate into single ProductOrderItem with quantity mentioned in ordering, meaning lets say, customer buys 10 instances of Analog Hardware, what could it translate to ?

• One ProductOrderItem (with quantity = 10) and Product instance in ProductOrder and ProductInventory APIs respectively, or,
• 10 ProductOrderItems having their own respective Product instances in Product Order and ProductInventory APIs respectively?

What is suitable/advised/possible/recommended as per TMF under which scenario?

Hello Varun,

Regarding your last question about the hardware representation, I would say that this generally depends upon the nature of the hardware sold. More specifically, your needs and requirements concerning the management of the inventory and and service and support processes. For example, if you are selling quantities of low value memory sticks you are likely to care only about quantity. At the other end of the scale, if you are selling routers, you will likely want to have individual lines throughout, so that you can track serial numbers, provide in-life support, sell warranties etc.

Hello Varun,

You might want to have a look at the TMF760 Product Configuration API. The configuration API has a "quantity" attribute to support configuration items. You may then map each configurationItem into a single/multiple productOrderItems.

------------------------------
Akshay Sahni
Orange
------------------------------

Hello Varun

when you want to pass the subscriber's contact in product order, be it postal address or phone number, it is a contact medium of a partyrole having a role as subscriber, you can use relatedParty->partyOrPartyRole->PartyRole->contactMedium . For these resources , please refer to TMF669 - Party Role Management API.

Regarding product order item quantity - it depends on the scenario:

1. if 10 analog devices to be managed as individual subscription each, and they will be managed and terminated as individual subscription, then there will be 10 order items , so that 10 product inventories get created.
2. if 10 analog devices will be managed and terminated together, then there can be one product order item 

Hi Varun

Below we generally do not put as product characteristics. instead, we put in product order.

• Building Address : ProductOrder->ProductOrderItem->Product.Place(newly proposed resource is site) 
• Contact Name : In order it can come in ProductOrder->RelatedParty with role as technical Contact , @type as PartyRole 
• Contact Email : ProductOrder->RelatedParty -> PartyRole ->ContactMedium
• Contact Phone : ProductOrder->RelatedParty -> PartyRole ->ContactMedium

Ref : https://projects.tmforum.org/wiki/x/FhdlAg , https://projects.tmforum.org/wiki/x/mSVlBQ