Open APIs

I noticed TMF640 is no longer in the list OpenAPI Directory OpenAPI Directory.

1. Does this mean it has been replaced by Service Ordering, Inventory, and Catalog? 
2. Is there a document where we can read about changes to the current APIs?
3. Service Activation and Inventory both use "Service" as the base model. Does that mean the id field should be the same in /serviceOrder/service/{id} and /serviceActivation/service/{id} 

Hi Patriya

This may have been a transient publication glitch, or a problem at your end. I see TMF640 in the directory: https://www.tmforum.org/oda/open-apis/directory/service-activation-management-api-TMF640/v4.0.0 - from this link you can see the various published and preview versions of the API.

I'm afraid that we have not been very good in the Open API project in giving concrete documentation of changes (release notes). Sorry, we need to improve in this area.

Regarding the ID matching between the inventory and activation APIs, this is tricky. There obviously needs to be some correlation between the service actually provisioned in the network (TMF640) and the service instantiated in the inventory (TMF638). ID is not the ideal mechanism for this, since we don't generally allow ID as input in POST. Ideally it would be done by using an external identifier, which would be populated in the inventory by some sort of ID that was returned from TMF640 . We do have a change request open for this: https://projects.tmforum.org/jira/browse/AP-4239 (accessible only by Open API project members), but I don't have visibility about when this will be dealt with.

Hope it helps

I noticed TMF640 is no longer in the list OpenAPI Directory OpenAPI Directory.

1. Does this mean it has been replaced by Service Ordering, Inventory, and Catalog? 
2. Is there a document where we can read about changes to the current APIs?
3. Service Activation and Inventory both use "Service" as the base model. Does that mean the id field should be the same in /serviceOrder/service/{id} and /serviceActivation/service/{id} 

I think also within ODA component working group there are discussions regarding the need of such Activation and Configuration API vs Order API.

I don't understand this API. The content is the same as the Service Inventory API. I would be happy to hear a feedback of this API use.

Hi Patriya

This may have been a transient publication glitch, or a problem at your end. I see TMF640 in the directory: https://www.tmforum.org/oda/open-apis/directory/service-activation-management-api-TMF640/v4.0.0 - from this link you can see the various published and preview versions of the API.

I'm afraid that we have not been very good in the Open API project in giving concrete documentation of changes (release notes). Sorry, we need to improve in this area.

Regarding the ID matching between the inventory and activation APIs, this is tricky. There obviously needs to be some correlation between the service actually provisioned in the network (TMF640) and the service instantiated in the inventory (TMF638). ID is not the ideal mechanism for this, since we don't generally allow ID as input in POST. Ideally it would be done by using an external identifier, which would be populated in the inventory by some sort of ID that was returned from TMF640 . We do have a change request open for this: https://projects.tmforum.org/jira/browse/AP-4239 (accessible only by Open API project members), but I don't have visibility about when this will be dealt with.

Hope it helps

I noticed TMF640 is no longer in the list OpenAPI Directory OpenAPI Directory.

1. Does this mean it has been replaced by Service Ordering, Inventory, and Catalog? 
2. Is there a document where we can read about changes to the current APIs?
3. Service Activation and Inventory both use "Service" as the base model. Does that mean the id field should be the same in /serviceOrder/service/{id} and /serviceActivation/service/{id} 

With regards to the original thread, TMF640 is back in the Open API table (https://www.tmforum.org/oda/open-apis/directory) and was missing earlier due to technical glitch. Earlier thread around this issue.

There are 2 topics additionally raised in this thread

1. TMF638 vs TMF640: IG1224 NaaS Transformation v13 section 3.2.1 provides guidance on implementation of TMF638 & TMF640, even though the APIs represent the same underlying Service object. Please refer to the table in the document.
2. TMF640 vs TMF641: TMF640 and TMF641 APIs offers us choice for handling different service provisioning patterns. IG1224 NaaS Transformation talks about these patterns in detail, but below is a summary

• • Type 1: Physical Infrastructure Deployment

    • Requires complex orchestration and has a long lead time.
    • Involves manual tasks and third-party integrations.
    • Best suited API: TMF641.

  • Type 2: Existing Infrastructure Usage

    • Type 2a: Rapid Activation
      • Zero-touch orchestration with short lead times.
      • Includes seamless third-party integration.
      • Best suited API: TMF640.
    • Type 2b: Complex Activation
      • Involves complex orchestration and long lead times.
      • Spans multiple domains with manual tasks and third-party integrations.
      • Best suited API: TMF641.

        Important considerations are:

• • Complex attribute changes may require TMF641 for lifecycle management.
  • Simple attribute changes can use TMF640 for rapid provisioning.

 TMF640 or TMF641 is an implementation choice, and both the APIs have their own merits.

Hope the above helps.

I think also within ODA component working group there are discussions regarding the need of such Activation and Configuration API vs Order API.

I don't understand this API. The content is the same as the Service Inventory API. I would be happy to hear a feedback of this API use.

Hi Patriya

This may have been a transient publication glitch, or a problem at your end. I see TMF640 in the directory: https://www.tmforum.org/oda/open-apis/directory/service-activation-management-api-TMF640/v4.0.0 - from this link you can see the various published and preview versions of the API.

I'm afraid that we have not been very good in the Open API project in giving concrete documentation of changes (release notes). Sorry, we need to improve in this area.

Regarding the ID matching between the inventory and activation APIs, this is tricky. There obviously needs to be some correlation between the service actually provisioned in the network (TMF640) and the service instantiated in the inventory (TMF638). ID is not the ideal mechanism for this, since we don't generally allow ID as input in POST. Ideally it would be done by using an external identifier, which would be populated in the inventory by some sort of ID that was returned from TMF640 . We do have a change request open for this: https://projects.tmforum.org/jira/browse/AP-4239 (accessible only by Open API project members), but I don't have visibility about when this will be dealt with.

Hope it helps

I noticed TMF640 is no longer in the list OpenAPI Directory OpenAPI Directory.

1. Does this mean it has been replaced by Service Ordering, Inventory, and Catalog? 
2. Is there a document where we can read about changes to the current APIs?
3. Service Activation and Inventory both use "Service" as the base model. Does that mean the id field should be the same in /serviceOrder/service/{id} and /serviceActivation/service/{id} 

Excellent contribution here by Abdul, it says it all, I think.

There've been some previous threads here on the distinction between TMF638 and TMF640, here's a summary of my view:

• TMF638 is (if you like) an IT system API - it's all about maintaining a unified picture of the network inventory, distinct from the network itself. Nevertheless, a specific implementation might decide that for some lines of business, e.g. commodity mobile, there is no need for a separate service inventory; assuming that the HLR/HSS/UDS is sufficiently low-latent to directly reflect the contents of the mobile network.
• TMF640 is a network API - it "talks" directly to the network (perhaps via custom equipment adapters on the way).

Regarding the use of TMF640 as against TMF641 service order management - it may be a specific implementation decision, but I'm not sure that in general it would be wise to assume that core commerce (ODA BSS component) would directly invoke TMF640. This would imply that core commerce has some knowledge of the network implementation, and "knows" that for certain lines of business, or for certain operations on services, there is no need for a service order.

Would be interesting to hear from in-the-field implementations about how these three APIs are used in concert.

With regards to the original thread, TMF640 is back in the Open API table (https://www.tmforum.org/oda/open-apis/directory) and was missing earlier due to technical glitch. Earlier thread around this issue.

There are 2 topics additionally raised in this thread

1. TMF638 vs TMF640: IG1224 NaaS Transformation v13 section 3.2.1 provides guidance on implementation of TMF638 & TMF640, even though the APIs represent the same underlying Service object. Please refer to the table in the document.
2. TMF640 vs TMF641: TMF640 and TMF641 APIs offers us choice for handling different service provisioning patterns. IG1224 NaaS Transformation talks about these patterns in detail, but below is a summary

• • Type 1: Physical Infrastructure Deployment

    • Requires complex orchestration and has a long lead time.
    • Involves manual tasks and third-party integrations.
    • Best suited API: TMF641.

  • Type 2: Existing Infrastructure Usage

    • Type 2a: Rapid Activation
      • Zero-touch orchestration with short lead times.
      • Includes seamless third-party integration.
      • Best suited API: TMF640.
    • Type 2b: Complex Activation
      • Involves complex orchestration and long lead times.
      • Spans multiple domains with manual tasks and third-party integrations.
      • Best suited API: TMF641.

        Important considerations are:

• • Complex attribute changes may require TMF641 for lifecycle management.
  • Simple attribute changes can use TMF640 for rapid provisioning.

 TMF640 or TMF641 is an implementation choice, and both the APIs have their own merits.

Hope the above helps.

I think also within ODA component working group there are discussions regarding the need of such Activation and Configuration API vs Order API.

I don't understand this API. The content is the same as the Service Inventory API. I would be happy to hear a feedback of this API use.

Hi Patriya

This may have been a transient publication glitch, or a problem at your end. I see TMF640 in the directory: https://www.tmforum.org/oda/open-apis/directory/service-activation-management-api-TMF640/v4.0.0 - from this link you can see the various published and preview versions of the API.

I'm afraid that we have not been very good in the Open API project in giving concrete documentation of changes (release notes). Sorry, we need to improve in this area.

Regarding the ID matching between the inventory and activation APIs, this is tricky. There obviously needs to be some correlation between the service actually provisioned in the network (TMF640) and the service instantiated in the inventory (TMF638). ID is not the ideal mechanism for this, since we don't generally allow ID as input in POST. Ideally it would be done by using an external identifier, which would be populated in the inventory by some sort of ID that was returned from TMF640 . We do have a change request open for this: https://projects.tmforum.org/jira/browse/AP-4239 (accessible only by Open API project members), but I don't have visibility about when this will be dealt with.

Hope it helps

I noticed TMF640 is no longer in the list OpenAPI Directory OpenAPI Directory.

1. Does this mean it has been replaced by Service Ordering, Inventory, and Catalog? 
2. Is there a document where we can read about changes to the current APIs?
3. Service Activation and Inventory both use "Service" as the base model. Does that mean the id field should be the same in /serviceOrder/service/{id} and /serviceActivation/service/{id}