How Yaas Seems To Structure Organizations And Projects
Updated 548 Days AgoPublic

Looking at the builder GUI and the (undocumented) APIs used it seems as if following internal data structure is used to model users, organizations, accounts and projects (where apparently "project" is used as synonym for "tenant" - quite confusing...)

Note: Before throwing into Visio or similar:

  • "–" as short UML notation for one-to-one
  • "–<" for one-to-many
  • ">–" as many-to-one
  • ">–<" as many-to-many

Naming Convention

  • Account = User (uniquely identified system-wide by email): Named User
  • Project = Tenant (uniquely identified system-wide by tenantId): Logical YAAS project. Unclear if Hybris is recommending to use multiple "Projects" to support environments like DEV, QA, STAGING or PRODUCTION. Given the current data model this seems to be recommended, i.e. "MyShop_QA" and "MyShop_Prod"
  • Organization: Seems to relate to functional grouping of "projects", ideally aligned with a "business organization" owning the project. Primary role here seems to be to group projects for billing purposes.
  • Client: Technical consumer of API. Examples: The "Builder" tool, a custom "Builder Module" like YAAS-SCULPTOR

Data Model

  • Account –< Organization (as "owns" organization). It seems an "account" can be assigned to multiple "projects" even across "account"!
  • Account >–< Organization (implicitly via Project (?) as "related" or "affiliated" organization)
  • Organization –< Project
  • Project >–< Account (however, security seems to limit some "members=" filtering!)

API Examples

Account

curl -H "Authorization: Bearer 023-xxxxx" https://api.eu.yaas.io/hybris/account/v1/accounts/yaas1@brainbo___ue.de
{
  "email" : "yaas1@bra___utique.de",
  "status" : "ACTIVE",
  "limits" : {
    "maxAmountOfOrganizations" : 2
  },
}

Note that the limit "maxAmountOfOrganizations" seems to apply to "owned" organizations only!

Organizations

It seems as if "member" query required and must use the account (i.e. email) of the user matching the issued authorization token. From response, it seems as if we cannot infer if the organization is "owned" or just "related" to the account.

curl -H "Authorization: Bearer 023-xxxx" https://api.eu.yaas.io/hybris/account/v1/organizations?member=yaas1@___inboutique.de

[ {
  "id" : "58a412xxx",
  "account" : "yaas1@bra___utique.de",
  "name" : "bbSample1",
  "address" : {
    "postalCode" : "32107",
    "state" : ""
  },
...

Hint: May append `&transitive=true` to query... It seems as if without "transitive=true" only the "owned" organizations are returned. "transitive=true" also returns organizations the account (user) is affiliated with by being assigned to a project. This may result in a different "account" exposed:

curl -H "Authorization: Bearer 023-xxxx" "https://api.eu.yaas.io/hybris/account/v1/organizations?member=yaas1%40heinco___ing.com&transitive=true"
[ {
  "id" : "5857a55fbxxx",
  "account" : "wilko.hein@___consulting.com",
...
}, {
   "id" : "5898d4989xxx",
  "account" : "yaas1@___consulting.com",
...
} ]

Projects

curl -H "Authorization: Bearer 023-xxxxx" https://api.eu.yaas.io/hybris/account/v1/projects?member=yaas1@___inboutique.de

[ {
  "id" : "bbsampleproject1",
  "account" : "yaas1@____boutique.de",
  "type" : "COMPANY",
  "name" : "bbSampleProject1",
  "description" : "This is the project description. You change this in the Administration view.",
  "organization" : "58a412xxxx",
  "members" : [ "yaas1@brain__utique.de" ],
...
} ]

Unlike the "organizations" service this seems to return transitive list of projects all the time. Exposed "account" / "organization" paired attribute indicates the "owning" entity.

Last Author
whein
Projects
None
Subscribers
None