Hi
I'm looking for the best practice to add a background worker to a multitenant microservices architecture. Our background job is part of a service which goes through a collection of entities and processes them, accross each tenant.
In terms of processing I was thinking using (_currentTenant.Change(TenantId)) would be the best way. BUT we need the tenants, which is part of the SaaS service.
Get could potentially turn off the tenant filter. using (_dataFilter.Disable<IMultiTenant>()) We could get the list of tenants from the client service and use change. We could add these to a shared project which has access to everything, for example ITenantRepository
Any recomendations for teh prefered way would be great.
Thanks
3 Answer(s)
-
0
Changing CurrentTenant and disabling IMultiTenant filter are ok in dataseeder. That is what we do also actually.
Also we're currently developing a micro-service example with ABP which is eShopOnAbp. It's still under development but we have implemented a background worker for Db Migrations. You may want to review that project.
-
0
Hi,
ICurrentTenant.Changeis the only way to operate on a specific tenant in a background worker. I can recommend to create a separate console application for the background workers and run only a single instance of that application. Otherwise, if you make it a part of a service, you should care when you run multiple instances of that service - the worker may work on the same data which may cause duplications.Disabling the tenancy filter is needed if you want to query from all tenants. It can only work for "shared database" approach. It can't work if a tenant has a seperate database. However, if you want to query a list of tenants (from the AbpTenants table), no need to disable the tenancy filter, because the Tenant entity is not multi-tenant.
In your background worker app, you can add a reference to the Volo.SaaS.EntityFrameworkCore and set the connection string for the saas database. Alternatively, you can perform a call to the SaaS service if you don't want to access the SaaS db from the worker app. But, I suggest to use the db.
-
0
Hi,
ICurrentTenant.Changeis the only way to operate on a specific tenant in a background worker. I can recommend to create a separate console application for the background workers and run only a single instance of that application. Otherwise, if you make it a part of a service, you should care when you run multiple instances of that service - the worker may work on the same data which may cause duplications.Disabling the tenancy filter is needed if you want to query from all tenants. It can only work for "shared database" approach. It can't work if a tenant has a seperate database. However, if you want to query a list of tenants (from the AbpTenants table), no need to disable the tenancy filter, because the Tenant entity is not multi-tenant.
In your background worker app, you can add a reference to the Volo.SaaS.EntityFrameworkCore and set the connection string for the saas database. Alternatively, you can perform a call to the SaaS service if you don't want to access the SaaS db from the worker app. But, I suggest to use the db.
Thanks for the info, that makes a lot of sense!
