Guide: Enterprise Resource Planning: Difference between revisions

From bwCloud-OS
Jump to navigation Jump to search
← Older edit
VisualWikitext
As1844 (talk | contribs)
intern, Administrators
215 edits
No edit summary
As1844 (talk | contribs)
intern, Administrators
215 edits
No edit summary
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
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 [[Guide: Entitlement & Eligibility|entitlements and eligibilities]].


== Entitlement ==
➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].'''


=== Entitlement validation ===
The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] for overview and management of the [[Guide: Entitlement & Eligibility|entitlements and eligibilities]]. Hence, for managing accounting data and resources of members.
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" |'''⚠️ 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 ====
__TOC__
JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>


Return: <code>{'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'}</code>
== Motivation ==
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|negotiated only contracts with institutions (customers)]] but not with individual members (users). This is a crucial [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|difference compared to other known cloud providers]].


'''Entitlement validation example 2'''
=== Automated resource provisioning ===
[[Registration]] is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.


JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2</nowiki>"}</code>
=== Shared resources ===
All resources in the bwCloud-OS are shared between all users. Since everyone should be able to access them, project quota limits are set. However, not every user group (e.g., teacher and student) requires the same [[Guide: Project and Quota#List of quota flavors|quota flavor]].


Return: <code>{'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'}</code>
=== Charging ===
All consumption within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. Charging will be based on the projects [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|project owner]]'s home organization.


'''Entitlement validation example 3'''
=== Delegating resposibility ===
The institutes can define an internal process so their members can set entitlements in the home IdP. There are several different types of sponsors (e.g., faculties, research projects) located at the institutes that should be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty).  With access to their internal data (e.g., from the local IdP), different eligibilities can be assigned.


JSON Data: <code>{"entitlement": "<nowiki>urn:geant:dfn.de:bwidm:bwcloud-os:group:xtiny_1:hfu_netze2:null:2027-01-32:null</nowiki>"}</code>
=== Reimbursement ===
Entitlements also help define who is financially responsible for producing BEH.
* Defining [[Guide: Entitlement & Eligibility#Cost centers|cost centers]] to separate costs into [[Guide: Entitlement & Eligibility#Example eligibility 1|different cost positions]], allowing institutions to reimburse the costs internally. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.


Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>
* bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.


== Eligibility ==
=== Budget (Not supported yet) ===
Sometimes resources should only be consumed up to a certain level or amount of time.


=== Eligibility rules ===
* [[Guide: Entitlement & Eligibility#Constraints|Constraints]] can be used to manage the valid period for the eligibility.
{| class="mw-message-box mw-message-box-warning"
* After reaching an eligibility constraint, no more costs can be produced within the associated project.
| style="vertical-align:middle;" |'''⚠️ 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 memer 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.
==== Paidafter ====
* 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.
This may be seen as a 'paidafter' credit  (analog to 'prepaid'). Institutes grant their members an amount of BEH to consume. Members can freely choose how to consume those, but not more. After the [[Guide: Charging|payment period]], the institute will only be charged for the consumed BEH.
* As a customer, I forward (all?) information of my stuff to this external service, such that I can define precise rules.(?)


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.
=== 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 [[Guide: REST-API for accounting and resource management#Eligibility rules|central service]] could simplify local processes within the customers.


=== Eligibility validation ===
== Contract relationship bwCloud-OS ==
{| class="mw-message-box mw-message-box-warning"
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]]
| style="vertical-align:middle;" |'''⚠️ 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: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2026-12-31", "max_booking_units": 5000}</code>
 
Return:  <code>{'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}</code>
 
'''Eligibility validation example 2'''
 
JSON Data: <code>{"quota_flavor": "large_1", "cost_center_id": "student", "first_day": "2026-01-01", "last_day": "2027-12-32", "max_booking_units": 5000}</code>
 
Return: <code>Error parsing eligibility. Invalid last day of validation format: 2027-01-32.</code>

Latest revision as of 15:02, 3 March 2026

➡️ To the ERP-API.

The bwCloud-OS provides an ERP with a RESTful API for overview and management of the entitlements and eligibilities. Hence, for managing accounting data and resources of members.

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.

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.

Shared resources

All resources in the bwCloud-OS are shared between all users. Since everyone should be able to access them, project quota limits are set. However, not every user group (e.g., teacher and student) requires the same quota flavor.

Charging

All consumption within the bwCloud-OS, within projects, are charged. 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. There are several different types of sponsors (e.g., faculties, research projects) located at the institutes that should be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty). With access to their internal data (e.g., from the local IdP), different eligibilities can be assigned.

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. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.
  • bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.

Budget (Not supported yet)

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 the eligibility.
  • After reaching an eligibility constraint, no more costs can be produced within the associated project.

Paidafter

This may be seen as a 'paidafter' credit (analog to 'prepaid'). Institutes grant their members an amount of BEH to consume. Members can freely choose how to consume those, but not more. After the payment period, the institute will only be charged for the consumed BEH.

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.

Contract relationship bwCloud-OS

The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.

Contract relationship compared between bwCloud-OS and other IaaS providers
Retrieved from "https://wiki.bwcloud-os.de/index.php?title=Guide:_Enterprise_Resource_Planning&oldid=1924"