Hi Rephael,
Kindly elaborate on the issue you are trying to solve?
Are you thriving to achieve a better architecture or want to minimize the number of used TMF APIs?
Generally your fulfilment / integration architecture defines how the systems should interact.
And based on the architecture you design the service and its lifecycle.
If the agent is eligible to interact with federated inventory directly it should use TMF-638 API for resources inquiry / reservation.
If the federated inventory is abstracted from an agent and it interracts only with COM/SOM/Orchestration it can be subscribed to service notifications (e.g. state change notification) in order to get updates asynchronously.
Even federated inventory can be organized in multiple ways. It can either replicate the resources from domains and used in RO mode for reporting, planning, etc or can paly a role of a master inventory across all resources.
So there is not right or wrong approach and the solution always depends on various factors.
------------------------------
Mikhail Mamaev
Netcracker Technology
------------------------------
Original Message:
Sent: Aug 15, 2022 07:19
From: Rephael Benhamo
Subject: TMF640 and TMF638
TMF640, service activation and configuration API, while TMF638 is service inventory API.
We are using TMF640 to provision 5G mobile subscribers.
For each of the processing steps of the provisioning stages, we populate a federated inventory DB to register the various provisioning steps that were completed.
This way, an agent can query the federated DB to find out the provisioning steps that were performed for each order (subscriber).
The question is whether I can use a POST and GET of TMF640 to populate and query the federated inventory DB respectively?
This way I'd not need to use the TMF638 to POST and GET to populate and query the federated inventory DB using a second API, TMF638.
Is my thinking correct or I'm messing something up here.
I thank you
Rephael
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.