Multi-tenancy

The IDK employs concepts like dependency injections, and also has a notion of multi-tenancy.

Even if your app does not use multi-tenancy, you still need to initialize a tenant when calling into IDK exposed services. This is because the dependency injection framework relies on the scopes explained shortly below and in more detail in the Dependency Injection section.

The IDK defines three scopes in every single application. To execute commands, you need to set these three scopes at all times. Fortunately, you can define yourself what the input values for the scopes should be.

• App scope and component. This scope is typically a singleton in your app. It describes your app and makes properties you set on the component available for dependency injection. It serves as the main scope.

• User context scope and component. This scope contains the tenant and principal (user or system-user) context information. It is initialized by providing a tenant and principal input string. How you obtain this information is up to you. The SDK does not care about that; it only uses the information to provide a separate context.

• Session scope and component. This scope represents a single session for a principal and tenant. Any related actions belong to the same session. It is up to you whether you use a long-lived session per tenant across your entire app, or a short-lived session per request/response, for example. This scope is merely used to separate units of work together. It also provides facilities to automatically group coroutines (similar to threads) together.

note

Most injected implementations are bound to the session scope, meaning they only exist in that particular session, but they do have access to the app and user context scopes.