3.6.3.
Custom Metric URI
Up one level
In some situations the service provider may wish to charge or constrain differently for different databases or database roles. For example, he may want to make read-only access to a database free while charging for read/write access.
This can be implemented through the use of custom metric URIs. There are two places where a custom URI can be entered:
- When adding a new role.
- When creating a new database (the automatically generated roles get assigned metric URIs based on the one provided).
When a user subscribes to a database role that uses custom metric URIs he generates one usage report for the standard subscription metric (http://www.gria.org/sla/metric/activity/ogsadai/subscription) and one for the custom metric. This is different from subscribing to a role without a custom metric URI, where the user would only generate a usage report for the standard subscription metric.
Providing a custom metric URI when creating a new database will assign similar metric URIs to the three automatically generated database roles. These URIs are generated using the same rules as username generation - the three postfixes are appended onto the end of the metric URI for each of the three roles.
For example, supposing you keep the default values for the username postfixes (eg, ".a" for the administrative role and ".r" for the read-only role), and specify a metric URI http://www.test.com/metric/test_database, the following metric URIs would be generated for the three roles:
- Administrative role: http://www.test.com/metric/test_database.a
- Read/write role: http://www.test.com/metric/test_database.w
- Read Only role: http://www.test.com/metric/test_database.r
