Guide: Enterprise Resource Planning

The bwCloud-OS provides an RESTful API that allows our customers to overview and manage the accounting data and resources of their members. Mainly, this means to manage entitlements and eligibilities.

Motivation

The bwCloud-OS negotiated only contracts with institutions (customers) but not with individual members (users). This is a crucial difference compared to other known cloud providers. Further, there are several different types of sponsors (e.g., faculties, research projects) located at the institutes that need to be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty).

Access Control

For registration to the bwCloud-OS several Condition of use need to be fulfilled. By rolling out the access entitlement home organizations can manage by themselves who is allowed to access the bwCloud-OS.

Automated resource provisioning

Registration is streamlined through entitlements:

• Entitlements are automatically evaluated during registration.
• Users receive immediate access and resources (project quota) once their entitlement is confirmed. No manual activation is required.

Charging

All consumptions within the bwCloud-OS, within projects, are charged. Hence, for each project, a customer is required, which differs from the user or owner.

Charging will be based on the projects booking units (BEH) and will be addressed to the project owner's home organization.

Delegating resposibility

The institutes can define an internal process so their members can set entitlements in the home IdP.

Reimbursement

Entitlements also help define who is financially responsible for producing BEH.

• Defining cost centers to separate costs into different cost positions, allowing institutions to reimburse the costs internally.

• bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.

Budget

Sometimes resources should only be consumed up to a certain level or amount of time.

• Constraints can be used to manage the valid period for eligibility.
• After reaching an eligibility constraint, no more costs can be produced within the associated project.

Central eligibility platform

The gimmic with the eligibility enhances (later) the bwCloud-OS local support to manage quota privileges within the bwCloud-OS environment. Such a central service could simplify local processes within the customers.

Entitlement

Entitlement validation

⚠️ Please Note: This endpoint is in a late testing phase and will be available soon.

This endpoint can be used for validating syntax and checking the interpretation of an entitlement string.

Entitlement validation example 2

JSON Data: {"entitlement": "urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2"}

Return: {'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2025-12-19', 'last_day_of_validation': 'inf', 'max_number_of_booking_units': 'inf'}

Entitlement validation example 2

JSON Data: {"entitlement": "urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2"}

Return: {'quota_flavor': 'xtiny_1', 'cost_center_id': 'hfu_netze2', 'first_day_of_validation': '2026-02-01', 'last_day_of_validation': '2027-01-31', 'max_number_of_booking_units': 'inf'}

Entitlement validation example 3

JSON Data: {"entitlement": "urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null"}

Return: Error parsing eligibility. Invalid last day of validation format: 2027-01-32.

Eligibility

Eligibility rules

⚠️ Please Note: Providing this functionalities is optional and still to plan.

This endpoint may be extended to allow customers to manage eligibility. By defining rules that can be applied to bwCloud-OS users when matching certain criteria. E.g. If the user is a member of the medicine faculty, grant the small quota flavor. However, the use cases and requirements for this are yet not cleare.

• As a customer, I want a service where my local support can define rules for rolling out eligibility, such that new users from my organization gain automatic quotas.
• As a customer, I want to control who is allowed to manage and see cost centers, user groups, and personal information, such that only privileged people can grant quotas.
• As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)
• As a user, I want to see the eligibilities I am owning, such that I can plan how to debit these.

There are plenty of questions the bwCloud-OS needs to address to their customers before it gets clear what kind of centralized service actually is needed and weather it will be accepted.

Eligibility validation

⚠️ Please Note: This endpoint is in a late testing phase and will be available soon.

This endpoint can be used for validating syntax and checking the interpretation of eligibility data.

Eligibility validation example 1

JSON Data: {"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}

Return: {'quota_flavor': 'large_1', 'cost_center_id': 'student', 'first_day_of_validation': '2026-01-01', 'last_day_of_validation': '2026-12-31', 'max_number_of_booking_units': 5000}

Eligibility validation example 2

JSON Data: {"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}

Return: Error parsing eligibility. Invalid last day of validation format: 2027-01-32.