The catalog data model provides a framework that allows service providers to define the products and services. It includes different entities that separate the customer-facing information from the technical information.

• Product: market information; customer facing
• Service: can be both customer and non-customer facing
• Resource: technical information; non-customer facing

Below are the Product catalog data model entities and should be setup in the similar approach defined here.

1. Product Offering Catalog.
2. Specification Category.
3. Characteristic
4. Characteristic-Options.
5. Resource Specification including characteristics mapping, Specification Relationships and then publish it.
6. Service Specification including characteristics mapping and then publish it.
7. Product Specification including characteristics mapping, Specification Relationships and then publish it.
8. Product Offering with required Product specification.

For more details on these entities, please refer the documentation here.

Most Important pints to be noted during the catalog data model setup: -

• The relationship type between PS-PS should be used as per business requirements.
• PS should be marked as ‘composite = true’, which will have child PS related to it.
• While defining the characteristics of type choice, yes_no, and checkbox, should be marked as ‘Mandatory’ true.
• Cross validating if all the characteristics from PS level have been pulled at PO level or not.

To more understand the above four points, let us consider below data model as an example.

Let us try to understand the four points with help of model in above image.

1. The PS-PS relationship type should be defined carefully,
   
   1. For example, if we define it as ‘Bundles’ in case of PS_001 to PS_002 it will generate both Product Order and Service Order for Order line item of PS_002 specification.
      
   2. If we define it as ‘Composed of’ in case of PS_001 to PS_002 it will generate only Service Order for Order line item of PS_002 specification.
2. PS_001 should be marked as ‘Composite’ True because it is related to PS_002 and both PS_001, PS_002 have characteristics defined on them and all of them will be auto pulled on product offering once you link PS_001 on PO_001.
3. Choice, yes_no, and checkbox type characteristics should be marked as mandatory because in the backend flow it validates the characteristics defined at PS level with the characteristics at PO_001 level (They should match so that you can pass the values for them in payload/request-body of Open API and system will allow the generated ORD to be approved).
4. Cross validation of the characteristics counts on PO_001 should be done so that all of them from PS_001, PS_002 are pulled (ORD generated will not allow to be approved if the count does not match as it is considered as mandatory in the back-end flow for Rome version).

Note: - The behavior mentioned in the Article is specific to the Rome Version and might be different for upcoming versions.

Hope this helps.

If you think this has helped you or can be helpful for other, please mark it as Helpful, Bookmark it, and Share it.

Thank You!Regards,

Kailash