You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Current »

Billing flow

Billing Flow
  1. The user logs in to the service (meetingtools in this case). In the login context we find the usual attributes but also an attribute that both sais that the users is permitted to use phone-bridge functions aswell as what costCenter is associated with this function for billing purposes. This part (costCenter) could be an option and if missing all the costs are sent to the default sequencenumber for that customer.
  2. Meetingtools upon finding the "pgi" flag for the user provisions a PGIConnect account and stores the PGIConnect-id (which will turn up later in the CDR records) in the user-profile in meetingtools along with the departmentNumber. Later we'll see how this can be generalized a little bit. Now we know that the user is authorized for phone-bridge and what the costCenter for phone-bridge-costs for this user is.
  3. User creates a meeting and the PGI system starts a CDR record for that meeting.
  4. Each month (or some other periodicity) we receive a set of CDR records from PGI. Each record (a line in an excel-file) contains a PGIConnect-id for the user that incurred the cost. We use the mapping from user to costCenter to emit an aggregated record (for that user) to the SUNET billing system with the customerid, sequencenumber and total cost (i.e we sum over all phone bridge-meetings created by that user in PGI).

Caveats:

  • costCenter in meetingtools only changes when the user logs in. If the user has a bridge which is always available (which is probably a sensible default) those bills will go to the same costCenter until the user logs in again. We can mitigate that problem by requiring that the user re-authenticate periodically to validate that their account in the IdP is still valid.
  • The entitlements used can be served either directly from the IdP or from COIP. This is exactly how the VHS and Wisum use-cases work today.

Implementation

There are two simple ways to do this:

  • A drop-in django-app that allows any django-application to use billing wo having to code anything.
  • A service with its own WS that we call from our various applications.

The difference is basically where the data is stored - in one place or each service stores its own
user-to-costCenter table.

  • No labels