Hi
@Jonathan Goldberg /
@Vance ShipleyWhen I am looking at TMF622, TMF641 & TMF637 holistically.
In all these APIs, Product Order/Service Order or even the Product Inventory has been associated with an Account or has a related party defined.
Also as
@Jonathan Goldberg, pointed out that charging functions are split into Core Commerce Management & Production.
Considering all of this, the question comes is for the charging system, which is the right entity for modeling i.e. Customer or Account.
Customer sounds right entity, but In case we consider Customer, should it be considered as a related party to create the association.
Secondly, as per the customer Management Interface, there is no customer reference to create a hierarchy in the system.
This drives to consider Account as right entity from a charging perspective then.
------------------------------
Alok Chhatry
------------------------------
Original Message:
Sent: Nov 24, 2021 10:53
From: Jacob Bensaid
Subject: What APIS a charging application needs to expose for provisioning from customer mgmt, order mgmt. etc.
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.
------------------------------
Jacob Bensaid
Original Message:
Sent: Nov 24, 2021 10:04
From: Jonathan Goldberg
Subject: What APIS a charging application needs to expose for provisioning from customer mgmt, order mgmt. etc.
I think that what Vance is saying is that as a result of TMF637 activity in the master product inventory, events are raised. Your charging application could listen to these events to update its internal representation of the product (and similarly for the customer).
That's certainly a feasible approach, but you need to be aware of what can go wrong (e.g. events were not raised, or not consumed), and have a strategy for reconciliation.
The advantage of an explicit update API for charging (or any other downstream system) is that you get positive confirmation of the data acceptance, rather than implicit choreography via the events.
A lot to think about.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Nov 24, 2021 09:27
From: Jacob Bensaid
Subject: What APIS a charging application needs to expose for provisioning from customer mgmt, order mgmt. etc.
Thank you @Vance Shipley
It seems that TMF637 is the API you used for provisioning of product instances - this is very interesting and useful
------------------------------
Jacob Bensaid
Original Message:
Sent: Nov 24, 2021 06:53
From: Vance Shipley
Subject: What APIS a charging application needs to expose for provisioning from customer mgmt, order mgmt. etc.
The premise is federation of Catalogues and Inventories as described in IG1222 ODA Technical Architecture ODA Patterns: Part 4. The just of which is that it uses mechanisms defined in Open APIs (i.e. TMF620, TMF637) for import/export and subscription/notification to synchronized your internal data with external sources.
------------------------------
Vance Shipley
SigScale
Original Message:
Sent: Nov 24, 2021 06:08
From: Jacob Bensaid
Subject: What APIS a charging application needs to expose for provisioning from customer mgmt, order mgmt. etc.
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.?
------------------------------
Jacob Bensaid
Original Message:
Sent: Nov 22, 2021 10:30
From: Vance Shipley
Subject: What APIS a charging application needs to expose for provisioning from customer mgmt, order mgmt. etc.
You might look at what we presented in the 5G Chargers Catalyst project, although that may become unavailable in a week or so. See this video for a description of the Catalog Driven Design we showcased. The tldr; of which is that an OCS/CCS "federates" with the Product Catalog, Product Inventory, etc. in order to allow the business policy and rules to be in the catalog while being used in real time rating and charging.
------------------------------
Vance Shipley
SigScale
Original Message:
Sent: Nov 22, 2021 04:46
From: Jacob Bensaid
Subject: What APIS a charging application needs to expose for provisioning from customer mgmt, order mgmt. etc.
Hi,
We are in out journey of adopting TMF OpenAPIs in a stand alone charging application.
We wish to expose OpenAPI/s for provisioning Customer data, order information etc. towards the charging application.
Currently there are 3 options we consider:
1. Create a dedicated OpenAPI (Currently not defining by TMF) that will be exposed to external application (Customer mgmt., order mgmt. etc.) and will be used to provision all relevant information.
2. Use TMF 641 - Service Ordering Management API hat will be exposed to external application (Customer mgmt., order mgmt. etc.) and will be used to provision all relevant information.
3. Towards each external application expose aspecific OpenAPI:
* TMF622 -Product Ordering API or TMF 641 - Service Ordering Management API - towards the order mgmt. application
* TMF 629 - Customer Management API - towards the Customer mgmt. application
* TMF 637 Product Inventory Management API for relevant inventory information
...
What is the option that best fits TMF best practices
------------------------------
Jacob Bensaid
------------------------------