Ends in:
4 DAYS
9 HRS
16 MIN
59 SEC
Ends in:
4 D
9 H
16 M
59 S
Open Closed

Background Worker in Microservices Project #2007


User avatar
0
chris.tune@gmail.com created

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)
  • User Avatar
    0
    enisn created
    Support Team .NET Developer

    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.

  • User Avatar
    0
    hikalkan created
    Support Team Co-Founder

    Hi,

    ICurrentTenant.Change is 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.

  • User Avatar
    0
    chris.tune@gmail.com created

    Hi,

    ICurrentTenant.Change is 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!

Made with ❤️ on ABP v9.1.0-preview. Updated on December 02, 2024, 12:35