Open APIs

Hi all,

I'm working with TMFC003 Product Order Delivery Orchestration and I've run into a challenge I guess many of us have seen.

When decomposing a Product Order into a Service Order, the characteristics on the ProductSpecification side don't always line up neatly with the ServiceSpecification side. For example:

• ProductSpecification has separate characteristics like:

  • downloadSpeed = 1000 Mbps

  • uploadSpeed = 300 Mbps

  • serviceLocation = ID123

• ServiceSpecification expects something different:

  • bandwidthProfile = {1000/300}

  • endpointLocation = ID123

So we need mapping logic to transform product-level attributes into the service-level attributes the network actually understands.

I know TMF620 lets us link ProductSpec directly to ServiceSpec, but the APIs themselves don't define how to do the transformation.

👉 Has anyone here already solved this in practice?

• Do you keep somehow the mapping rules in the catalog (TMF620/TMF633)?

• Or is it something you implement directly inside TMFC003 orchestration?

• Or do you offload it into a different component?

How do you handle this? Could anybody share experiences about what worked well (or didn't).

Thanks!

Hi,

Hi all,

I'm working with TMFC003 Product Order Delivery Orchestration and I've run into a challenge I guess many of us have seen.

When decomposing a Product Order into a Service Order, the characteristics on the ProductSpecification side don't always line up neatly with the ServiceSpecification side. For example:

• ProductSpecification has separate characteristics like:

  • downloadSpeed = 1000 Mbps

  • uploadSpeed = 300 Mbps

  • serviceLocation = ID123

• ServiceSpecification expects something different:

  • bandwidthProfile = {1000/300}

  • endpointLocation = ID123

So we need mapping logic to transform product-level attributes into the service-level attributes the network actually understands.

I know TMF620 lets us link ProductSpec directly to ServiceSpec, but the APIs themselves don't define how to do the transformation.

👉 Has anyone here already solved this in practice?

• Do you keep somehow the mapping rules in the catalog (TMF620/TMF633)?

• Or is it something you implement directly inside TMFC003 orchestration?

• Or do you offload it into a different component?

How do you handle this? Could anybody share experiences about what worked well (or didn't).

Thanks!

Hi Koen,

Thanks for sharing your implementation approach - very clear and pragmatic. I've reviewed your post and would like to reflect back my understanding, along with a few open questions that arise.

✅ Summary of Key Takeaways

• ProductOffering with fixed characteristics: Each offering represents a predefined profile (e.g., 1000/300 Mbps), with characteristics fixed and inherited from the corresponding ServiceCandidate. This simplifies ordering and orchestration.

• ServiceCandidate as technical anchor: I understand you're using ServiceCandidate to represent valid combinations of service characteristics, effectively acting as the technical equivalent of ProductOffering.

• Characteristic alignment: Both ProductSpecification and ServiceSpecification define similar characteristics (e.g., downloadSpeed, uploadSpeed), and the mapping is straightforward when profiles are fixed.

• Use of @type: NetworkProductSpec: This helps distinguish network-related products and supports orchestration logic in TMFC003.

❓ Open Questions and Observations

• Service decomposition into RFS and resources: In practice, ServiceSpecifications often decompose into multiple ResourceFacingServices (RFS) and ResourceSpecifications. Your post doesn't mention this layer - is it something you handle separately, or do you abstract it behind the ServiceCandidate?

• Transformation logic location:

  Even with fixed profiles, mapping logic is sometimes needed. For example, in my hypothetical case:

  • ProductSpec has downloadSpeed = 1000, uploadSpeed = 300, serviceLocation = ID123

  • ServiceSpec expects bandwidthProfile = {1000/300}, endpointLocation = ID123

  So we need a transformation layer to convert product-level attributes into service-level ones. Do you handle this in TMFC003, or somewhere else?

• Scalability of fixed profiles: For large catalogs with many variants (e.g., speed tiers, contract durations, optional features), the number of ProductOfferings and ServiceCandidates can grow quickly. Have you encountered limits or strategies to manage this complexity?

Thanks again for the detailed breakdown. I'd be keen to hear how you approach the deeper service/resource decomposition and whether you've found a clean way to keep it manageable across TMF APIs.

Hi,

Hi all,

I'm working with TMFC003 Product Order Delivery Orchestration and I've run into a challenge I guess many of us have seen.

When decomposing a Product Order into a Service Order, the characteristics on the ProductSpecification side don't always line up neatly with the ServiceSpecification side. For example:

• ProductSpecification has separate characteristics like:

  • downloadSpeed = 1000 Mbps

  • uploadSpeed = 300 Mbps

  • serviceLocation = ID123

• ServiceSpecification expects something different:

  • bandwidthProfile = {1000/300}

  • endpointLocation = ID123

So we need mapping logic to transform product-level attributes into the service-level attributes the network actually understands.

I know TMF620 lets us link ProductSpec directly to ServiceSpec, but the APIs themselves don't define how to do the transformation.

👉 Has anyone here already solved this in practice?

• Do you keep somehow the mapping rules in the catalog (TMF620/TMF633)?

• Or is it something you implement directly inside TMFC003 orchestration?

• Or do you offload it into a different component?

How do you handle this? Could anybody share experiences about what worked well (or didn't).

Thanks!

Hi all,

I'm working with TMFC003 Product Order Delivery Orchestration and I've run into a challenge I guess many of us have seen.

When decomposing a Product Order into a Service Order, the characteristics on the ProductSpecification side don't always line up neatly with the ServiceSpecification side. For example:

• ProductSpecification has separate characteristics like:

  • downloadSpeed = 1000 Mbps

  • uploadSpeed = 300 Mbps

  • serviceLocation = ID123

• ServiceSpecification expects something different:

  • bandwidthProfile = {1000/300}

  • endpointLocation = ID123

So we need mapping logic to transform product-level attributes into the service-level attributes the network actually understands.

I know TMF620 lets us link ProductSpec directly to ServiceSpec, but the APIs themselves don't define how to do the transformation.

👉 Has anyone here already solved this in practice?

• Do you keep somehow the mapping rules in the catalog (TMF620/TMF633)?

• Or is it something you implement directly inside TMFC003 orchestration?

• Or do you offload it into a different component?

How do you handle this? Could anybody share experiences about what worked well (or didn't).

Thanks!