This document will illustrate avenues for modules to answer two questions

Is this tenant in a consortium?
What is the central tenant id of the consortium?

There are two avenues to be able to deduce enough information to answer the questions above.

HTTP
Kafka

HTTP

If /user-tenants 's response is not empty, the tenant is in a consortium.

Modules can call /user-tenants which is handled by mod-users, a core FOLIO module, to get list of user tenant associations. If the response to this endpoint is empty, then the scoped tenant is not in a consortium.

If /user-tenants 's response is not empty, the tenant is in a consortium. The central tenant identifier can be derived from user-tenants response or from /consortia-configuration which is handled by mod-consortia.

When a new tenant is added to a consortium, mod-consortia will create a dummy user with an affiliation in the tenant. So for every tenant /user-tenants will be populated with at least one user in its response. /user-tenants in the central tenant will contain the true list for the consortium.

URL	Method	Response
/user-tenants?limit=1	GET	{ "userTenants":[ { "id":"uuid", "userId":"uuid", "username":"dummy_user", "tenantId":"member_tenant", "centralTenantId": "mobius", "consortiumId": "uuid } ], "totalRecords":1 }

Kafka

Modules can subscribe to the CONSORTIUM_TENANTS Kafka topic to get a list of tenants that belong to a consortium. Each record will have its central tenant id embedded as well. Each module instance should be in its own consumer group.

Consortium awareness will be supported by a new topic called CONSORTIUM_TENANTS. Consumers to this topic will be able to retrieve a list of tenants in a consortium. A special characteristic with this Kafka topic is that it will be log compacted. This means that, eventually, only the latest version of each tenant data will be present in the topic. Messages will be produced into this topic with the tenant id as its message key. Kafka will keep the latest version of each message by its key(tenant identifier). Consumers to this topic should be able to handle duplicate messages for the same key. Kafka will ensure that the duplicate message will be in order, the last received message for a key will be its latest version.

Each message should contain the central tenant identifier & consortium identifier for each tenant.

Every module instance consuming from CONSORTIUM_TENANTS must be in their own Kafka consumer group if there are no manipulations of offsets. This will allow independent consumption of information for each running instance of a module.

Upon startup mod-consortia will produce messages to CONSORTIUM_TENANTS containing all tenants of a consortium

Browser not supported