@Jonathan Goldberg thank you for your answer.
Using the 3rd option has some risks in regards to synchronization/dependency/orchestration(API call order) - I'll explain with an example:When a new Customer is buying a product the calls towards the charging system should be synchronized as well as ordered: first a new customer details needs to be provisioned to the charging system and only then the the product/services provisioning can be done to the charging system.
If the TMF629 POST into charging would fail or be delayed due to some issue the TMF622 POST will fail validation as the customer will not be recognized by the charging system.option 1 & 2 can overcome this risk as they should enable a single call that will provision the entire customer & order data into the charging system in a single API call.
This will also make sense in regards to the orchestration of the provisioning to several systems (Charging, billing ...) as it is easier to orchestrate 1 call per system rather than several.HAs anyone has actual experience with such charging OpenAPI integration?
Thank you @Vance Shipley
The source you shared present very interesting use cases.Yet my question still remains - how was the provisioning carried out? which API/APIs where used to convey customer/order information to the 5G chargers.?
It seems that TMF637 is the API you used for provisioning of product instances - this is very interesting and useful
Thanks @Jonathan Goldberg - indeed a lot to consider
Subscribing to events will also delay the flow as the charging system will not be able to authorize services (e.g. data session) until the provisioning information is accepted and processed.
In such cases using orchestrated APIs can be a better solution.