Open APIs

Hi,

According IG1228 v14.0.0's UC004, Service order management (SOM) can be domain oriented. In the use case, Access service domain has its own SOM and Resource order management (ROM).  

I thought firstly we will have only one service order management that is shared across all domain. Product order management (POM) sends request to shared SOM. So, in POM application's configuration, we will set SOM's api url. It is catalog driven POM. In multiple SOM use cases, how does POM know to send which SOM will be receiver? In product spec, should we add any tag/attribute that can express which SOM is. In the case, our POM have additional configuration, based on the tag/attribute, it will decide which SOM will receive SOM order request. What alternative solutions can be?

Also, for ROM, the question is similar. How does SOM know to call which ROM will be receiver?

Hi Myagaa,

Although you are not the only one that encounters this problem, I don't believe there is an official TM Forum response to this question.

I will give you the secret sauce I use to solve this problem.

GB922 Product Figure Pr.03a - Product Specification - Examples gives you a way to classify ProductSpecifications. I use these to create subclasses of "ProductSpecification": e.g. "@type": "GoodsProductSpecfication", "@baseType": "ProductSpecification".

Using this logic you can define subclasses for your domains:

• AccessProductSpecification: for products realised as service by the Access Domain
• CoreNetworkProductSpecification: for products realised as service by the Core Network Domain
• NaaSProductSpecification: for products realised as a service by the NaaS domain
• GoodsProductSpecification: for products realised as a resource by the logistics domain

Your POM can then use the @type to determine to which SOM or ROM to send the order.

P.S. Let's keep this a secret ;-)

------------------------------
Koen Peeters
OryxGateway FZ LLC

Original Message:
Sent: Oct 09, 2023 10:12
From: Myagaa Nm
Subject: Multiple Service order management (SOM)

Hi,

According IG1228 v14.0.0's UC004, Service order management (SOM) can be domain oriented. In the use case, Access service domain has its own SOM and Resource order management (ROM).  

I thought firstly we will have only one service order management that is shared across all domain. Product order management (POM) sends request to shared SOM. So, in POM application's configuration, we will set SOM's api url. It is catalog driven POM. In multiple SOM use cases, how does POM know to send which SOM will be receiver? In product spec, should we add any tag/attribute that can express which SOM is. In the case, our POM have additional configuration, based on the tag/attribute, it will decide which SOM will receive SOM order request. What alternative solutions can be?

Also, for ROM, the question is similar. How does SOM know to call which ROM will be receiver?

------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
------------------------------

Should we drive this routing logic based on ProductSpec or ServiceSpec. SOM has process to fulfill ServiceSpec and not ProductSpec. Different SOM will be potentially deployed for various ServiceSpec Category.

Should @type we used or ServiceCategory?

------------------------------
Srinivasa Vellanki
Jio Platforms Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of my employer or TM Forum.

Original Message:
Sent: Oct 16, 2023 01:59
From: Koen Peeters
Subject: Multiple Service order management (SOM)

Hi Myagaa,

Although you are not the only one that encounters this problem, I don't believe there is an official TM Forum response to this question.

I will give you the secret sauce I use to solve this problem.

GB922 Product Figure Pr.03a - Product Specification - Examples gives you a way to classify ProductSpecifications. I use these to create subclasses of "ProductSpecification": e.g. "@type": "GoodsProductSpecfication", "@baseType": "ProductSpecification".

Using this logic you can define subclasses for your domains:

• AccessProductSpecification: for products realised as service by the Access Domain
• CoreNetworkProductSpecification: for products realised as service by the Core Network Domain
• NaaSProductSpecification: for products realised as a service by the NaaS domain
• GoodsProductSpecification: for products realised as a resource by the logistics domain

Your POM can then use the @type to determine to which SOM or ROM to send the order.

P.S. Let's keep this a secret ;-)

------------------------------
Koen Peeters
OryxGateway FZ LLC

Original Message:
Sent: Oct 09, 2023 10:12
From: Myagaa Nm
Subject: Multiple Service order management (SOM)

Hi,

According IG1228 v14.0.0's UC004, Service order management (SOM) can be domain oriented. In the use case, Access service domain has its own SOM and Resource order management (ROM).  

I thought firstly we will have only one service order management that is shared across all domain. Product order management (POM) sends request to shared SOM. So, in POM application's configuration, we will set SOM's api url. It is catalog driven POM. In multiple SOM use cases, how does POM know to send which SOM will be receiver? In product spec, should we add any tag/attribute that can express which SOM is. In the case, our POM have additional configuration, based on the tag/attribute, it will decide which SOM will receive SOM order request. What alternative solutions can be?

Also, for ROM, the question is similar. How does SOM know to call which ROM will be receiver?

------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
------------------------------

Service category can be one of solutions. However, @type is more suitable for the multiple SOMs. Thank you for you helpful reply.

Should we drive this routing logic based on ProductSpec or ServiceSpec. SOM has process to fulfill ServiceSpec and not ProductSpec. Different SOM will be potentially deployed for various ServiceSpec Category.

Should @type we used or ServiceCategory?

------------------------------
Srinivasa Vellanki
Jio Platforms Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of my employer or TM Forum.

Original Message:
Sent: Oct 16, 2023 01:59
From: Koen Peeters
Subject: Multiple Service order management (SOM)

Hi Myagaa,

Although you are not the only one that encounters this problem, I don't believe there is an official TM Forum response to this question.

I will give you the secret sauce I use to solve this problem.

GB922 Product Figure Pr.03a - Product Specification - Examples gives you a way to classify ProductSpecifications. I use these to create subclasses of "ProductSpecification": e.g. "@type": "GoodsProductSpecfication", "@baseType": "ProductSpecification".

Using this logic you can define subclasses for your domains:

• AccessProductSpecification: for products realised as service by the Access Domain
• CoreNetworkProductSpecification: for products realised as service by the Core Network Domain
• NaaSProductSpecification: for products realised as a service by the NaaS domain
• GoodsProductSpecification: for products realised as a resource by the logistics domain

Your POM can then use the @type to determine to which SOM or ROM to send the order.

P.S. Let's keep this a secret ;-)

------------------------------
Koen Peeters
OryxGateway FZ LLC

Original Message:
Sent: Oct 09, 2023 10:12
From: Myagaa Nm
Subject: Multiple Service order management (SOM)

Hi,

According IG1228 v14.0.0's UC004, Service order management (SOM) can be domain oriented. In the use case, Access service domain has its own SOM and Resource order management (ROM).  

I thought firstly we will have only one service order management that is shared across all domain. Product order management (POM) sends request to shared SOM. So, in POM application's configuration, we will set SOM's api url. It is catalog driven POM. In multiple SOM use cases, how does POM know to send which SOM will be receiver? In product spec, should we add any tag/attribute that can express which SOM is. In the case, our POM have additional configuration, based on the tag/attribute, it will decide which SOM will receive SOM order request. What alternative solutions can be?

Also, for ROM, the question is similar. How does SOM know to call which ROM will be receiver?

------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
------------------------------

Hi Myagaa,

Although you are not the only one that encounters this problem, I don't believe there is an official TM Forum response to this question.

I will give you the secret sauce I use to solve this problem.

GB922 Product Figure Pr.03a - Product Specification - Examples gives you a way to classify ProductSpecifications. I use these to create subclasses of "ProductSpecification": e.g. "@type": "GoodsProductSpecfication", "@baseType": "ProductSpecification".

Using this logic you can define subclasses for your domains:

• AccessProductSpecification: for products realised as service by the Access Domain
• CoreNetworkProductSpecification: for products realised as service by the Core Network Domain
• NaaSProductSpecification: for products realised as a service by the NaaS domain
• GoodsProductSpecification: for products realised as a resource by the logistics domain

Your POM can then use the @type to determine to which SOM or ROM to send the order.

P.S. Let's keep this a secret ;-)

Hi,

According IG1228 v14.0.0's UC004, Service order management (SOM) can be domain oriented. In the use case, Access service domain has its own SOM and Resource order management (ROM).  

I thought firstly we will have only one service order management that is shared across all domain. Product order management (POM) sends request to shared SOM. So, in POM application's configuration, we will set SOM's api url. It is catalog driven POM. In multiple SOM use cases, how does POM know to send which SOM will be receiver? In product spec, should we add any tag/attribute that can express which SOM is. In the case, our POM have additional configuration, based on the tag/attribute, it will decide which SOM will receive SOM order request. What alternative solutions can be?

Also, for ROM, the question is similar. How does SOM know to call which ROM will be receiver?