Conversation
|
|
||
| Mendix recommends storing the user’s email address in the `UserCommons.NamedUserIdentifier.value`; this ensures usage of a pairwise unique identifier in the `system.user.name` does not affect metering. | ||
|
|
||
| Within your application portfolio, the possibility to prevent cross-app user correlation is probably not needed; instead, you do want the Mendix metering system to correlate users and recognize multi-app users. Microsoft’s Entra ID uses pairwise identifiers in the OIDC `sub` claim. It is, however, possible to include the `oid` claim, which contains the same value for a given multi-app user across all applications; Entra ID’s `object-id`. Mendix recommends storing the `oid` claim in the `system.user.name` if you are using the OIDC SSO module with Entra ID. |
There was a problem hiding this comment.
Jaap, which one is correct? object-id or objectId? I believe 'objectId'.
There was a problem hiding this comment.
Microsoft calls it 'user object ID'.
See https://learn.microsoft.com/en-us/partner-center/account-settings/find-ids-and-domain-names as example.
|
|
||
| ## Introduction | ||
|
|
||
| End-user metering is the process Mendix uses to determine the number and type of users accessing applications in accordance with license agreements. Proper user classification ensures accurate reporting, optimal licensing costs, and transparency for both customers and Mendix. Customers can access Usage Report through the Control Center application on the Mendix Platform. <!-- Link Usage Report from the Control Center doc --> |
There was a problem hiding this comment.
"transparency for both customers and Mendix. Custpomers can ...platform." - if we decide to postpone the availability of the usage report for customers, this sentence needs to be in seperate PR for later publication. See also my remark in our slack channel.
| End-user metering is the process Mendix uses to determine the number and type of users accessing applications in accordance with license agreements. Proper user classification ensures accurate reporting, optimal licensing costs, and transparency for both customers and Mendix. Customers can access Usage Report through the Control Center application on the Mendix Platform. <!-- Link Usage Report from the Control Center doc --> | ||
|
|
||
| {{% alert color="info" %}} | ||
| End-user metering is currently available for applications deployed to Mendix Cloud and Mendix Cloud Dedicated environments. |
There was a problem hiding this comment.
Maybe say "End-user metering is currently applied to applications..."
Especially given the decision on the report, customers may not 'get' metering. It's something Mendix applies.
There was a problem hiding this comment.
Maybe this restriction should not be here at all.
This is the top-level document that describes metering principles.
Even though we may not (yet) apply on all deployments, the principles and mechanisms still apply from contrcatual perspective.
There was a problem hiding this comment.
they do, but this is simply an alert so that we do not set false expectations with our customers on other dpeloyments.
| ### Key Features | ||
|
|
||
| * Automatic tracking – User consumption is automatically tracked from the moment your app is deployed to production and becomes functional, ensuring real-time tracking. | ||
| * Monthly reporting – Usage data is collected regularly, processed monthly, and is available in the Control Center. |
There was a problem hiding this comment.
As per my previous comment - maybe not yet in Control Center - 2nd PR?
There was a problem hiding this comment.
We should remove reference to Control Center in this section.
Irrespective of the control center visibility, we do data collection, processing and deduplication
|
|
||
| * Automatic tracking – User consumption is automatically tracked from the moment your app is deployed to production and becomes functional, ensuring real-time tracking. | ||
| * Monthly reporting – Usage data is collected regularly, processed monthly, and is available in the Control Center. | ||
| * Application-level visibility – you get the detailed insights into named user counts for each application, helping you to identify optimization opportunities. |
There was a problem hiding this comment.
?!>?
As far as i know we don't have visibility on application level.
Please check with Satyam.
There was a problem hiding this comment.
again, this is specific to control center. We can remove this point from this generic section here.
| * Automatic tracking – User consumption is automatically tracked from the moment your app is deployed to production and becomes functional, ensuring real-time tracking. | ||
| * Monthly reporting – Usage data is collected regularly, processed monthly, and is available in the Control Center. | ||
| * Application-level visibility – you get the detailed insights into named user counts for each application, helping you to identify optimization opportunities. | ||
| * License type classification – Users are classified by license type as External, Multi-App Internal, or Single-App Internal. This classification gives you accurate license tracking and helps optimize licensing costs. |
There was a problem hiding this comment.
"gives you" --> "yields" if we don't make the report available yet.
| * Application-level visibility – you get the detailed insights into named user counts for each application, helping you to identify optimization opportunities. | ||
| * License type classification – Users are classified by license type as External, Multi-App Internal, or Single-App Internal. This classification gives you accurate license tracking and helps optimize licensing costs. | ||
| * Historical data – User metering provides you with access to usage data for all months since user metering was enabled. | ||
|
|
There was a problem hiding this comment.
Maybe the remark about deployments should be added here.
"End-user metering is currently applied to applications deployed to Mendix Cloud and Mendix Cloud Dedicated environments."
There was a problem hiding this comment.
historical data section is also relevant for control center.
| ## How User Metering Works | ||
|
|
||
| User metering in the Mendix cloud operates through a three-stage automated process, and it is enabled by default for apps deployed in Mendix Cloud environments. | ||
|
|
There was a problem hiding this comment.
Since this is the top-level document, I think the additional step "in-app data generation" should be added here as well.
I know we discussed this before and may have decided to not include that step here, I find myself disagreeing (again).
|
|
||
| ### Data Collection | ||
|
|
||
| Once users are classified as `Internal` or `External`, all applications on the Mendix Cloud and Mendix Cloud Dedicated automatically send user data back to the Mendix platform. The data is collected throughout the month from the production environment only. PII information (username and other user identifiers) is hashed at source before transmission to ensure data privacy. |
There was a problem hiding this comment.
"Once ...." - this kinda strange since this page hasn't m,entioned that before - also because the data generation section is currently lacking.
There was a problem hiding this comment.
Suggestion:
"All applications on the Mendix Cloud and Mendix Cloud Dedicated automatically send user data back to the Mendix platform. The data is collected throughout the month from the production environment only. PII information (username and other user identifiers) is hashed at source before transmission to ensure data privacy."
There was a problem hiding this comment.
"Once users are classified as Internal or External, "
this phrase is technically incorrect.
Irrespective of user classification, all applications send user data back to the platform.
There was a problem hiding this comment.
"The data is collected throughout the month only from the production environment"
No. We collect data from all environments, but data collected from Production env is relevant for conusmption numbers and billing purpose
|
|
||
| End-of-month usage reports are generated at the beginning of each month and are made available via the Control Center dashboard. The reports are generally available on the 1st of each month and reflect the previous month's usage. | ||
|
|
||
| ## How User Aggregation and Deduplication Work |
There was a problem hiding this comment.
I think this should say "How user classification and deduplication works".
Not sure if Satyam agrees, but the scope of what this section describes includes classification definiately.
There was a problem hiding this comment.
- can we try to remove mentions of Control Center dashboard in this generic section.
| ## How User Aggregation and Deduplication Work | ||
|
|
||
| The user aggregation and deduplication process determines which user pack is consumed when a user accesses one or more of your applications. The process evaluates users in a sequence so that each user is counted according to the correct license pack without duplication. The classification follows the steps below: | ||
|
|
There was a problem hiding this comment.
The headings says "deduplication" but the contents don't say anything about deduplication. I think it should be added as a first step.
Suggestion:
"Users are deduplicated based on common identifier values. A real-life person who has different identifier values in the aggregated data cannot be recognized as same user, so will be counted as multiple users. The deduplication mechanism evaluates 2 user attributes, see [section xyz]" (the section where we talk about system.user.name and userCommons.nameduseridentifier.value, etc,..
|
|
||
| Once classified, the user is licensed under the External User Pack and excluded from further classification steps. For more information, see the [User classification](/developerportal/deploy/implementing-user-metering/#user-classification) section of *Implementing Metering*. | ||
|
|
||
| All remaining users are classified as `Internal` Users and further classified as described in the sections below. |
There was a problem hiding this comment.
Let's add:
"A multi-app user that is marked as internal in one app and is marked as external in another app will be counted as an internal user."
There was a problem hiding this comment.
@JaapF I'd say this is internal logic. Why do we want to write it here and confuse the audience?
| If the application is associated with a Single-App Internal User Pack, the user of the app will be classified as a single-app internal user. This user will be counted against the single-app internal user pack for that application. | ||
|
|
||
| For more details on how to assign single-app user packs to your apps, refer to the Assigning Single-App Internal User Packs section of the Control Center. <!-- Link from the Control Center doc --> | ||
|
|
There was a problem hiding this comment.
I think we should add:
"An internal user that is using multiple apps, one of which being an app with a single-app user pack, will be counted as a single-app user and will be counted as another user for the other apps as well."
Satyam to confirm.
There was a problem hiding this comment.
It can be a good note to add as an "info panel", after simplifying this sentence.
|
|
||
| User metering is automatically enabled for all Mendix Cloud and Mendix Cloud Dedicated applications without requiring any configuration or setup for usage data collection. Data collection begins as soon as your application is deployed to a production environment. | ||
|
|
||
| ### Where Can I View My User Consumption Data? |
| Navigate to the **Control Center** > **Entitlements** > **End-Users** > **Usage Report**. | ||
| For more information, refer to the Usage Report Tab section of *End-Users*. <!-- Link from the Control Center doc --> | ||
|
|
||
| ### When Can I See My Monthly Usage Data? |
| If you exceed your licensed entitlements: | ||
|
|
||
| * No immediate service disruption: Your applications continue to run normally. | ||
| * Alert displayed: A warning icon appears in the end-of-month Usage Report on the Control Center. |
| * Optimizing user classification | ||
| * Adjusting your license agreement | ||
|
|
||
| Mendix recommends that you monitor your usage regularly and purchase additional capacity before reaching your limit. |
|
|
||
| Mendix recommends that you monitor your usage regularly and purchase additional capacity before reaching your limit. | ||
|
|
||
| ### Can I View Usage Data From Previous Months? |
|
|
||
| ## Questions on User Classification | ||
|
|
||
| ### How Are Users Classified If I Do Not Configure User Classification? |
There was a problem hiding this comment.
Both question and answer are fuzzy to me - as it doesn't mention external users.
Maybe the question should be "How are users classified If I don't assign single-user license to an app?"
| ### I Have External Users in My Applications. How Do I Ensure They Are Counted Correctly? | ||
|
|
||
| Explicitly mark users as `External` in your application to ensure they are counted correctly under your External User pack. If you do not have an External User pack, these users will be classified as `Internal`, even if they are marked as `External` users. | ||
|
|
There was a problem hiding this comment.
Also a multi-app user that is marked as internal in one app, but as external in another app, will be counted as an internal multi-app user.
|
|
||
| Technically, you can deactivate or remove users to optimize license costs. | ||
|
|
||
| To optimise license cost, you may choose to delete records in the `system.user` object, while maintaining data in custom user objects. |
There was a problem hiding this comment.
Please add:
"You may also choose to deactivate users by using SCIM integration between your app and your IdP. This requires you to include the SCIM module in your application. See [link to SCIM]"
|
|
||
| ### User Classification and Reporting | ||
|
|
||
| Users are thereafter automatically classified in the following sequence: |
There was a problem hiding this comment.
Users are thereafter automatically classified in the following sequence:
i'd have said in the following user licensing buckets based on your user licenses.. or something like that
| @@ -49,7 +49,7 @@ | |||
| 2. Single-App Users | |||
| ### Choosing a Cross-App User Identifier: | ||
|
|
||
| User metering may not have been considered when your application was originally designed. As a result, different applications may store different identifier values for the same multi-app user in the `system.user.name`. Additionally, all apps in your portfolio may use different user-provisioning logic. Some apps use standard identity modules (Administration, SAML, OIDC SSO, SCIM, or LDAP) while others rely on proprietary modules or app logic to create users. This can lead to inconsistent identifiers. | ||
| Even when all apps use the same solution, for example, OIDC SSO, the technical identifier value for a multi-app user may still differ. |
There was a problem hiding this comment.
@JaapF @Karuna-Mendix the whole section somehow sounds very apologetic and guessing why you could have done it wrong. Documentation should be more directive IMO.
We ought to be first telling - "you are supposed to do xyz... ". These usecases when a customer might have done it wrong might be best suited for a Q&A or FAQ IMO.
What do you think?
| Even if all your apps are using the same user onboarding (provisioning) logic, this does not guarantee a user gets the same (technical) identifier value in all your applications. | ||
| The OpenID Connect specifications incorporate the concept of [pairwise user identifiers](https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg). The general idea of pairwise identifiers is to prevent user correlation across apps owned by different service providers. A user gets a different value in each app when using pairwise user identifiers. | ||
|
|
||
| Mendix recommends storing the user’s email address in the `UserCommons.NamedUserIdentifier.value`; this ensures usage of a pairwise unique identifier in the `system.user.name` does not affect metering. |
There was a problem hiding this comment.
@JaapF Since we do not support UserCommons.Nam.... yet from a User Metering perspective, is it wise to call this out OR should we skip?
| ### Keeping the Existing Logic and Extending | ||
|
|
||
| If your apps are not consistently storing the same identifier for a multi-app user in `system.user.name`, you can start using a new user attribute, new `UserCommons.namedUserIdentifier.value`.You can keep the existing application logic as it is, and in addition, store the selected user identifier value for a multi-app user in this new attribute. | ||
| If your apps are not consistently storing the same identifier for a multi-app user in `system.user.name`, you can start using a new user attribute, a new `UserCommons.namedUserIdentifier.value`.You can keep the existing application logic as it is, and in addition, store the selected user identifier value for a multi-app user in this new attribute. |
There was a problem hiding this comment.
@JaapF - this is not a supported entity from a User Metering perspective yet. Will lead to loss of usage data, if csutomers start implementing it.
How do you propose we move forward, considering supporting this additional attribute is not foreseen in the short term.
|
|
||
| ## User Classification | ||
|
|
||
| For accurate user metering, `External` users must be correctly classified. If they are not, your company may exceed the licensed capacity for `Internal` users, and Mendix may require you to acquire additional internal user licenses. |
There was a problem hiding this comment.
@Karuna-Mendix also important to add... If you do not classify your external users, they will treated as Internal Users by default.
| 1. `User`: Every Mendix app has a system module containing an entity `User`. | ||
|
|
||
| * `system.user.name`: This field is used to identify users, unless a UserCommons.namedUserIdentifier.value is available for the same user. | ||
| * `system.user.name`: This field is used to identify users, unless a `UserCommons.namedUserIdentifier.value` is available for the same user. |
There was a problem hiding this comment.
@JaapF @Karuna-Mendix
UserCommons.namedUserIdentifier.value
should we refer to this attricbute since this is not yet supported by the Metering sidecar and the metering stack overall?
3 participants
https://mendix.atlassian.net/browse/TW-2769