Activities of "marco@iwell.nl"

Ahh thank you, that might be something I can work with. Coworkers of mine are actually right in the middle of upgrading to version 7.4 which I expect to be finished any time soon!

Still pretty strange to me that the BackgroundWorker doesn't run and the PeriodicBackgroundWorkerBase does run in our current situation. If you can shed any light on this, that would be great!

Right now, to continue the feature, I'm implementing the periodic version. Since it's a singleton I've implemented the 'isRunning' solution so we actually only have it running once. And also enables some kind of auto-recovery option in case the process crashes.

  • ABP Framework version: v5.2
  • UI Type: Angular
  • Database System: EF Core (SQL Server)
  • Tiered (for MVC) or Auth Server Separated (for Angular): angular..
  • Exception message and full stack trace: none
  • What am I trying to achieve: I need a background worker process that runs once and keeps running (polling an Azure queue and processing messages).
  • Steps to reproduce the issue:

Setup

We're running two instances of our backend:

  1. The 'default' ABP project that provides the REST API for our frontend (Angular) and to provide an interface to our customers.
  2. Another instance that only runs periodic tasks. (implementations of AsyncPeriodicBackgroundWorkerBase) This instance is stripped off running any web middle ware or providing the REST endpoints.

These instances run in different Azure App Services, so they are not aware of each other. It's NOT a clustered environment.

Goal

In the 'worker' instance I need a new BackgroundWorker that runs once and keeps running until the application stops. Basically: while (!stoppingToken.IsCancellationRequested) { ... }

If I understand the documentation correct, that can be achieved by implementing the BackgroundWorkerBase class like this:

This works fine when I register the Worker on the rest API instance on the HttpApiHostModule.cs like this: await context.AddBackgroundWorkerAsync<IotMessageWorker>();

When I debug the restAPI instance of my application, all is okay. The debugger stops on the worker class. However, when I register my worker in the worker instance, the debugger won't hit any breakpoints. (besides a constructor, so the class is loaded)

Troubleshooting and questions

Clearly, before writing this post, I've been trying to get this to work myself. No cigar though.

AsyncPeriodicBackgroundWorkerBase We already run this setup on production for our current background workers. The commonality between these, is they are all implementations of the AsyncPeriodicBackgroundWorkerBase. These run just fine. Which dazzles me, because this is just another implementation of the BackgroundWorkerBase.

Dependencies or services My guess is, that I need another dependency in my WorkerModule. I tried a couple of obvious ones, but that doesn't seem to help. Also an option is that I miss some service registration in the DI container. I tried to match the things with the restAPI instance, but that didn't help either.

Clearly we probably stripped too much off on our worker instance, but I can not figure out what is missing. That's also my question: What makes the BackgroundWorkerBase run (and why is that different from the AsyncPeriodBackgroundWorkerBase)?

implementation of the WorkerService PortalWorkerModule

Entrypoint of Program.cs

Startup class of the WorkerService:

I hope anyone can give me a pointer on how to achieve this the correct and supported way :)

  • ABP Framework version: v4.3.0
  • UI type: Angular
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): tiered solution
  • Exception message and stack trace:
Exception has occurred: CLR/System.ArgumentNullException
Exception thrown: 'System.ArgumentNullException' in System.Linq.dll: 'Value cannot be null.'
   at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
   at Volo.Abp.Identity.IdentityUser.IsInOrganizationUnit(Guid organizationUnitId)
   at Volo.Abp.Identity.IdentityUser.AddOrganizationUnit(Guid organizationUnitId)
   at Iwell.Cloud.Portal.IdentityServer.UserDataSeedContributor.<SeedAsync>d__8.MoveNext() in /app/aspnet-core/src/Iwell.Cloud.Portal.Domain/IdentityServer/UserDataSeedContributor.cs:line 67
  • Steps to reproduce the issue:

When we seed a fresh (development) database we do a few things in a specific order (order managed by a single DataSeedContributor):

  1. Roles and permissions (using the IdentityRoleManager + IPermissionManager)
  2. OrganizationUnits: (using the OrganizationUnitManager, all OU's seeded in seperate units of work)
Customers
 |
 -- Customer A
  1. Users + add users to OU's + add users to roles

The problem occures in the userseeder when trying to add a user to an existing OU: (all checks and other code left out for readability)

var customerAOU = await _organizationUnitRepository.FirstOrDefaultAsync(ou => ou.DisplayName == IdentityServerConsts.GetCustomerAOUDisplayName());            
var customer = await _identityUserManager.FindByNameAsync(IdentityServerConsts.GetCustomerUserName());
customer.AddOrganizationUnit(customerAOU.Id);

The ArgumentNullException happens on the customer.AddOrganizationUnit(..) call.

As you can see in the attached picture the 'customerAOU' is an existing OrganizationUnit object and the 'customer' is an existing IdentityUser object.

The exact same thing happens when trying to add a role to a user using this code:

var adminRole = await _identityRoleManager.FindByNameAsync("admin");
customer.AddRole(adminRole.Id); 

I wonder if this is the way to add users to OU's (+ roles to users) or am I missing something here? Is there by any chance some more (technical or reference) documentation available on this topic?

If you need more information, or pieces of code, just let me know.

Any help would be appreciated!

Best regards,

Marco

Showing 1 to 3 of 3 entries
Made with ❤️ on ABP v8.2.0-preview Updated on March 25, 2024, 15:11