Hi Kalpana!
Sure you can do this. I think you have to decide between beeing more generic and 'data driven' or beeing more specific and perhaps more 'consumer friendly'. It strongly depends on the context you are working in and your customers/consumers. In my opinion nether is wrong, it just depends.
I mean the api allows you to specify the Impact-/Target Entity as you need. You could use it to refer to a resource, service or even a product.
My perspective about this API is that it is mainly desigend for a Resource Change in the Network. So a typical use case I would see is like:
1. A change for an network element is created and referred as TargetEntityRef
2. During change planning all impacted products or services are identified and referred as ImpactEntityRef
3. Based on this information the change will be classified (for example can it be executed or must I inform customer about an outtage of the network with a list of the products which are impacted)
4. The information can then be used from Customer Care to communicate to the customers
My feeling is when you talk about make it specific, it's more about the format of the notification. So that (a) a party see only what is necessary and (b) is not overwhelmed by the information.
In this case you could think about adding specific notifications for these stakeholders or bring in a layer which expose a minimal set of the api, but use the same api in the background. But maybe this API must not support all operations.
Questions I would aks my self are:
1. Who is allowed to see which information
2. Which capabilities do my consumers have (maybe they work with a legacy system)
3. What are the costs of operation in the future if specific APIs have to be maintained
4. Who want's to have an information and for what reason
Regards
Daniel
------------------------------
Daniel Lauxtermann
Glasfaser NordWest GmbH & Co .KG
------------------------------
Original Message:
Sent: Sep 30, 2020 01:58
From: Girish Gajria
Subject: Adapting TMF655 Change management API
Hello Kalpana,
Based on my limited knowledge, I can see this going down two ways.
Approach 1: Separate APIs, depending on the backend application
From your example, if you use a different change management application for a products vs service requests, you may be able to create separate change management APIs for each, with their own individual mapping information
Approach 2: Same APIs, with a canonical Microservice model
Create a single API for consumer exposure. This API invokes an internal Microservices layer in the canonical TMF format. Based on the request type and/or entity, the MS transforms the canonical model into the appropriate backend format
Hope that helps.
Regards,
------------------------------
Girish Gajria
Torry Harris Integration Solutions
Original Message:
Sent: Sep 25, 2020 01:49
From: Kalpana HV
Subject: Adapting TMF655 Change management API
Hi,
We have a requirement to expose change management API for planned network maintenance. As per eTOM, change management process affects entities related to resources, services, products and partners. The change management API's resource model supports all these entities. I am thinking of creating separate change management API for each of these entities. Entity specific resource model simplifies the design, maintainability & monetisation of API - entity specific API to be touched only when there is change in the particular entity. Also, reduces the chattiness of the API. Would like to know forum's thoughts on it and the practical approach to implement the API.
@Adrienne Walcott, @Marcello Borzi
Could you please help.
Thank you.
Best regards,
------------------------------
Kalpana HV
Colt Technology Services
------------------------------